Possible bug or opportunity for user error with admin/user password

[Mike Tsao]

Jeremy, I believe you're running into a common issue that adding a PIN to
an empty device is not supported, or at least is a no-op. The reason, I
think, is that the PIN is implemented as symmetric encryption of the
secrets it's protecting, so if no keys have been added, then there's
nothing to encrypt, so the PIN effectively vanishes into thin air.

Since everyone appreciates armchair quarterbacking, I wonder whether it
could have been done as a tagged structure of some sort that contains the
keys, but also is > 0 bytes in length when empty. Then the PIN would have
something to encrypt, and a way for the system to know whether an asserted
PIN is valid.

On Wed, Jan 30, 2019 at 11:41 AM Jeremy Drake <
jeremydrake+gnuk at eacceleration.com> wrote:

> On a related note, I have found that the process of setting PINs and
> loading keys (whether importing or generating) is highly order dependent,
> and if I do not do things in exactly the right order, unexpected things
> happen and I wind up having to start over.  It looks like the order
> followed here is almost the same as the order I wrote down to follow that
> works for me, except I would have changed the admin pin before importing
> the key.
>
>
>
> On Tue, 29 Jan 2019, Mike Tsao wrote:
>
> > This is on FSIJ-1.2.13 running on an ST_DONGLE.
> >
> >   1. Flash using standard method.
> >   2. gpg --card-edit
> >   3. factory-reset, y, yes
> >   4. rm -rf .gnupg, kill gpg-connect-agent, etc. so GnuPG is fresh
> >   5. gpg --import my-secret-subkeys.gpg
> >   6. gpg --edit-key myname
> >   7. key 1
> >   8. keytocard
> >   9. (answer menu for encryption key)
> >   10. when asked for admin PIN, enter 12345678
> >   11. when asked again for admin PIN, enter 12345678
> >   12. exit
> >   13. gpg --card-edit
> >   14. admin
> >   15. passwd
> >   16. enter 1 for user PIN
> >   17. *enter 12345678*
> >   18. when asked for new password, enter thisismypassword
> >   19. when asked again for new password, enter thisismypassword
> >   20. exit
> >   21. gpg --card-status to confirm that the gnuk device is now loaded
> with
> >   the key
> >   22. gpg -d something-encrypted-with-this-key.asc
> >   23. when prompted, enter thisismypassword
> >   24. get "no decryption key"
> >   25. try again
> >   26. try again
> >   27. device is locked
> >
> > Do you see what I did wrong? At step 17 I entered 12345678 instead of
> > 123456. I forgot that the default admin PIN is different from the default
> > user PIN. But the messages that GnuPG printed suggested that the password
> > change succeeded! (See transcript below.)
> >
> > Moreover, I went back to step 25 and tried entering 123456. Nope -- the
> > password is indeed changed, but it's changed to neither 123456, 12345678,
> > or thisismypassword.
> >
> > The bug I'm reporting is that I don't understand why GnuPG accepted the
> > wrong initial user PIN. Why didn't it report that the password change
> > failed? Aside from it being obviously frustrating because the only way to
> > fix it is to factory-reset and do the whole process over again. But it
> > could be a serious issue if a user believes the device is correctly set
> up,
> > and then (foolishly) discards other copies of the secret subkey.
> >
> > I hope this is something within gnuk's control. If it's just GnuPG being
> > silly, then there isn't much this team can do about it.
> >
> > (transcript of session follows)
> >> admin
> > Admin commands are allowed
> >
> > gpg/card> passwd
> > gpg: OpenPGP card no. D2760001xxxxxxxx detected
> >
> > 1 - change PIN
> > 2 - unblock PIN
> > 3 - change Admin PIN
> > 4 - set the Reset Code
> > Q - quit
> >
> > Your selection? 1 [entered 12345678, then thisismypassword twice]
> >
> > *PIN changed.    <===== NOTE REPORT OF SUCCESS*
> >
> > 1 - change PIN
> > 2 - unblock PIN
> > 3 - change Admin PIN
> > 4 - set the Reset Code
> > Q - quit
> >
> > Your selection? q
> >
> > gpg/card> verify [entered thisismypassword]
> >
> > Reader ...........: 234B:0000:FSIJ-1.2.13-xxxxx
> > Application ID ...: D2760001xxxxxxx
> > Version ..........: 2.0
> > Manufacturer .....: unmanaged S/N range
> > Serial number ....: xxxxxx
> > Name of cardholder: [not set]
> > Language prefs ...: [not set]
> > Sex ..............: unspecified
> > URL of public key : [not set]
> > Login data .......: [not set]
> > Signature PIN ....: forced
> > Key attributes ...: ed25519 rsa2048 rsa2048
> > Max. PIN lengths .: 127 127 127
> > *PIN retry counter : 2 3 3                 <===== NOTE DECREMENT*
> >
> > (end transcript)
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190130/0cffb575/attachment.html>