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

[Jeremy Drake]

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)
>