Mailing List Archive

Can’t set new PIN using Reset Code
Hello,

Today gnupg suddenly refused to accept the PIN code of my YubiKey and
it got blocked. I am not exactly sure what happened, but it does not
matter now anyway.

I am trying to unblock the PIN using a Reset Code.

```
$ gpg --edit-card

Reader ...........: Yubico YubiKey FIDO CCID 00 00
Application ID ...: D2760001240103040006117659560000
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: Yubico
Serial number ....: 11765956
Name of cardholder: Kirill Elagin
Language prefs ...: en
Salutation .......:
URL of public key : https://bruna.kir.elagin.me/kirelagin.asc
Login data .......: kirelagin
Signature PIN ....: not forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 3 0
Signature counter : 3
KDF setting ......: on
Signature key ....: CC5E B1EF E671 C418 33CC 318B FA66 ABF3 CFA3 569C
created ....: 2021-01-27 16:37:47
keygrip ....: AD296DDA5EB86005A83ABCCC57046D9E64007C10
Encryption key....: 047A 7B2F B0E9 6F07 F9C2 16DC B3D9 F87D 907D C8B1
created ....: 2021-01-27 16:38:41
keygrip ....: B0960250674C237FF7D7979C8871684392B84F9C
Authentication key: 8039 572F A015 0862 CB26 7A65 6D74 9968 B8E9 D1FE
created ....: 2021-01-27 16:39:33
keygrip ....: C9CAE2108556320815105E1D528B62D081965835
General key info..:
sub rsa2048/FA66ABF3CFA3569C 2021-01-27 Kirill Elagin <kirelagin@gmail.com>
sec> rsa4096/90D516249B728BE6 created: 2017-11-30 expires: never
card-no: 0006 05764872
ssb> rsa2048/FA66ABF3CFA3569C created: 2021-01-27 expires: 2022-01-01
card-no: 0006 11765956
ssb> rsa2048/B3D9F87D907DC8B1 created: 2021-01-27 expires: 2022-01-01
card-no: 0006 11765956
ssb> rsa2048/6D749968B8E9D1FE created: 2021-01-27 expires: 2022-01-01
card-no: 0006 11765956
ssb> rsa4096/85D128E1B30E1931 created: 2017-11-30 expires: never
card-no: 0006 05764872
ssb> rsa4096/435BC889600C52F1 created: 2017-11-30 expires: never
card-no: 0006 05764872

gpg/card> unblock
gpg: OpenPGP card no. D2760001240103040006117659560000 detected
PIN changed.

gpg/card>
```

It says that the PIN was changed, however when I try to use the card
with the new PIN, it keeps saying that it’s wrong.

Note that the admin pin is blocked (which, ugh, is a different story –
I got it blocked months ago during the initial setup and I was so
tired of that process that I decided not to start over). Also note
that the first and the second retry counters are different (I have no
idea why; I always assumed that gnupg was supposed to keep them in
sync). And also note that KDF is enabled (which, I think, might be
contributing to the issue – all my problems with e.g. the admin PIN
getting blocked started after I enabled KDF).

I’m pretty sure that at this point the easiest option is just to wipe
the card and start over, but, I thought, I would still give it a try,
so I’m looking for tips on how to debug this issue. And has anyone
seen anything like that before?

This all started with gnupg 2.2.23, I have now upgraded to 2.2.27 and
it’s still the same.

Cheers,
Kirill

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can’t set new PIN using Reset Code [ In reply to ]
For anyone interested, I was able to get my card back in order. I am
85% confident that there is a bug in GnuPG that causes it to compute
the KDF in the reset command incorrectly.

Here is what I did.

Step 1 was to figure out how to tap into the communication with the
card. After a bit of searching I found out that `scdaemon` is
responsible for communicating with the card.
I ended up writing:

```
debug-level 8
debug-ccid-driver
debug-ccid-driver
log-file /tmp/scdaemon.log
```

into `$HOME/.gnupg/scdaemon.conf`. I did not really try any other
options, my understanding is that `debug-ccid-driver` (twice!) is what
makes it dump raw APDUs, but I have also thrown `debug-level` in just
for good measure.

Then I did `gpg --edit-card` and, as described in my previous email,
used the `unblock` command to set PIN to 123456789.
Immediately after that I used the `passwd` command entering both the
old and the new PIN as 123456789.

Then I inspected the log.
The first APDU of interest is RESET RETRY COUNTER (00 2C ...). I took
notice of the last 32 bytes, which are supposed to be the salted hash
of the PIN. I kinda inspected to find the unhashed PIN there, but,
not, the bytes looked pretty arbitrary.
The second APDU of interest is CHANGE REFERENCE DATA (00 24 ...). Its
payload is old hash followed by new hash. In my case they both were
the same, but they both were different from what I found in the
previous APDU.

I simply took the first APDU and replaced the hash of the new PIN with
the correct one from the second APDU. I sent it manually using
`gpg-connect-agent --hex`, and – tada! – my card works again.

I haven’t looked at the code yet, but my theory is that either a wrong
salt is used or the hash calculation is incorrect in some other way.

Cheers,
Kirill

On Fri, Apr 23, 2021 at 3:58 PM Kirill Elagin <kirelagin@gmail.com> wrote:
>
> Hello,
>
> Today gnupg suddenly refused to accept the PIN code of my YubiKey and
> it got blocked. I am not exactly sure what happened, but it does not
> matter now anyway.
>
> I am trying to unblock the PIN using a Reset Code.
>
> ```
> $ gpg --edit-card
>
> Reader ...........: Yubico YubiKey FIDO CCID 00 00
> Application ID ...: D2760001240103040006117659560000
> Application type .: OpenPGP
> Version ..........: 3.4
> Manufacturer .....: Yubico
> Serial number ....: 11765956
> Name of cardholder: Kirill Elagin
> Language prefs ...: en
> Salutation .......:
> URL of public key : https://bruna.kir.elagin.me/kirelagin.asc
> Login data .......: kirelagin
> Signature PIN ....: not forced
> Key attributes ...: rsa2048 rsa2048 rsa2048
> Max. PIN lengths .: 127 127 127
> PIN retry counter : 0 3 0
> Signature counter : 3
> KDF setting ......: on
> Signature key ....: CC5E B1EF E671 C418 33CC 318B FA66 ABF3 CFA3 569C
> created ....: 2021-01-27 16:37:47
> keygrip ....: AD296DDA5EB86005A83ABCCC57046D9E64007C10
> Encryption key....: 047A 7B2F B0E9 6F07 F9C2 16DC B3D9 F87D 907D C8B1
> created ....: 2021-01-27 16:38:41
> keygrip ....: B0960250674C237FF7D7979C8871684392B84F9C
> Authentication key: 8039 572F A015 0862 CB26 7A65 6D74 9968 B8E9 D1FE
> created ....: 2021-01-27 16:39:33
> keygrip ....: C9CAE2108556320815105E1D528B62D081965835
> General key info..:
> sub rsa2048/FA66ABF3CFA3569C 2021-01-27 Kirill Elagin <kirelagin@gmail.com>
> sec> rsa4096/90D516249B728BE6 created: 2017-11-30 expires: never
> card-no: 0006 05764872
> ssb> rsa2048/FA66ABF3CFA3569C created: 2021-01-27 expires: 2022-01-01
> card-no: 0006 11765956
> ssb> rsa2048/B3D9F87D907DC8B1 created: 2021-01-27 expires: 2022-01-01
> card-no: 0006 11765956
> ssb> rsa2048/6D749968B8E9D1FE created: 2021-01-27 expires: 2022-01-01
> card-no: 0006 11765956
> ssb> rsa4096/85D128E1B30E1931 created: 2017-11-30 expires: never
> card-no: 0006 05764872
> ssb> rsa4096/435BC889600C52F1 created: 2017-11-30 expires: never
> card-no: 0006 05764872
>
> gpg/card> unblock
> gpg: OpenPGP card no. D2760001240103040006117659560000 detected
> PIN changed.
>
> gpg/card>
> ```
>
> It says that the PIN was changed, however when I try to use the card
> with the new PIN, it keeps saying that it’s wrong.
>
> Note that the admin pin is blocked (which, ugh, is a different story –
> I got it blocked months ago during the initial setup and I was so
> tired of that process that I decided not to start over). Also note
> that the first and the second retry counters are different (I have no
> idea why; I always assumed that gnupg was supposed to keep them in
> sync). And also note that KDF is enabled (which, I think, might be
> contributing to the issue – all my problems with e.g. the admin PIN
> getting blocked started after I enabled KDF).
>
> I’m pretty sure that at this point the easiest option is just to wipe
> the card and start over, but, I thought, I would still give it a try,
> so I’m looking for tips on how to debug this issue. And has anyone
> seen anything like that before?
>
> This all started with gnupg 2.2.23, I have now upgraded to 2.2.27 and
> it’s still the same.
>
> Cheers,
> Kirill

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can’t set new PIN using Reset Code [ In reply to ]
On Sun, 25 Apr 2021 22:07, Kirill Elagin said:

> into `$HOME/.gnupg/scdaemon.conf`. I did not really try any other
> options, my understanding is that `debug-ccid-driver` (twice!) is what

Nope, that is todebug the low-level ccid driver. The best way to debug
the APDUs is

verbose
debug ipc,cardio

instead of the legacy debug-level cruft. "ipc" is just a helper to see
the IPC I/O.

> I haven’t looked at the code yet, but my theory is that either a wrong
> salt is used or the hash calculation is incorrect in some other way.

You may want to open a bug report at dev.gnupg.org so that we don't
forget about this.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Can’t set new PIN using Reset Code [ In reply to ]
On Mon, Apr 26, 2021 at 12:05 PM Werner Koch <wk@gnupg.org> wrote:

> You may want to open a bug report at dev.gnupg.org so that we don't
> forget about this.

Thanks for the tip, I’ll be sure to do so next time!

However in this case I have already submitted a patch to gnupg-devel yesterday.
I hope you don’t forget about it :).

Cheers,
Kirill

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users