Page MenuHome GnuPG

Kleopatra: Wrong error message when unblocking PIN
Open, NormalPublic

Description

How to reproduce:

  • Set a reset code / PUK for your Smart card.
  • Get the PIN counter to 0 by giving the wrong PIN repeatedly
  • Choose "Unblock PIN"
  • Enter the wrong reset code (= PUK)
  • you are asked 2x for the new PIN, enter the same twice

-> Error "Unblocking the PIN failed: wrong PIN"

Expected:
a) To get error message before being asked for new PIN
b) Error "Unblocking the PIN failed: wrong Reset Code"

In the case the PIN is unblocked with the Admin PIN instead, I'd expect "Unblocking the PIN failed: wrong Admin PIN"

I guess this is caused by gpg, not Kleopatra, as the message part behind the colon comes from gpg.

If a) is something which can be changed, I would make a separate ticket for that.

Details

Version
Gpg4win 5.0.0-beta125, Gpg4win 4.4.0

Event Timeline

With Gpg4win-Beta60 before the Gpg4win 4.4. release it was "reset code", see https://dev.gnupg.org/T5960#191665, seems there was a change after that

ebo changed Version from Gpg4win 5.0.0-beta125 (at least) to Gpg4win 5.0.0-beta125, Gpg4win 4.4.0.Fri, Feb 28, 2:22 PM
ebo renamed this task from Kleopatra: Wrong success/error messages when unblocking PIN to Kleopatra: Error messages when unblocking PIN.Fri, Feb 28, 2:41 PM
ebo renamed this task from Kleopatra: Error messages when unblocking PIN to Kleopatra: Wrong error message when unblocking PIN.

We do not have an error code for Admin PINs. The Admin PIN is also an OpenPGP card specific termm and other cards use different terms. For example a NKS has no Admin PIN at all but an alternative PIN.

Right, We had error codes for the reset code but that is because the reset code is not a PIN/PUK/.... ISO 7816 terms are interesting.

werner triaged this task as Normal priority.Tue, Mar 4, 10:51 AM

The point here is that I tried to reset with the resetting code, not with the Admin PIN.
As you said we do have an error code for the wrong reset code. Which does not come up.

I do not know if this is a gpg or a Kleopatra issue. @ikloecker?

a) and b) are both entirely gpg's responsibility. I'm using --status-fd 2 --command-fd 2 to see which messages would be passed to/parsed by gpgme.

$ gpg --version
gpg (GnuPG) 2.4.8-beta10

$ gpg --card-edit --status-fd 2 --command-fd 2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!

[GNUPG:] CARDCTRL 3 D2760001240100000006090745820000
Reader ...........: 1050:0407:X:0
Application ID ...: D2760001240100000006090745820000
Application type .: OpenPGP
Version ..........: 2.1
Manufacturer .....: Yubico
Serial number ....: 09074582
Name of cardholder: Ada Lovelace
Language prefs ...: [not set]
Salutation .......: 
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 2 3
Signature counter : 4
UIF setting ......: Sign=off Decrypt=off Auth=off
Signature key ....: CB20 3AEE 4F97 BD7B 52AD  2E8C 6605 0DE0 54A4 456D
      created ....: 2025-01-09 09:36:15
Encryption key....: 1D11 B7B0 873C A254 8A5B  4E73 D054 9496 3D20 E390
      created ....: 2025-01-09 09:36:15
Authentication key: 9756 6E61 D84D 5C82 67FF  72D0 787C 4A3F E29F 65D4
      created ....: 2025-01-09 09:36:15
General key info..: [GNUPG:] KEY_CONSIDERED CB203AEE4F97BD7B52AD2E8C66050DE054A4456D 0

pub  rsa2048/66050DE054A4456D 2025-01-09 New Card Keys <new-card-keys-with-expiration@example.net>
sec>  rsa2048/66050DE054A4456D  created: 2025-01-09  expires: 2028-01-09
                                card-no: 0006 09074582
ssb>  rsa2048/787C4A3FE29F65D4  created: 2025-01-09  expires: 2028-01-09
                                card-no: 0006 09074582
ssb>  rsa2048/D05494963D20E390  created: 2025-01-09  expires: 2028-01-09
                                card-no: 0006 09074582

[GNUPG:] GET_LINE cardedit.prompt
unblock
[GNUPG:] GOT_IT
[GNUPG:] PINENTRY_LAUNCHED 154252 qt 1.3.2-beta6 /dev/pts/12 xterm-256color :0 20600/1000/5 1000/1000 0
[GNUPG:] PINENTRY_LAUNCHED 154279 qt 1.3.2-beta6 /dev/pts/12 xterm-256color :0 20600/1000/5 1000/1000 0
[GNUPG:] PINENTRY_LAUNCHED 154304 qt 1.3.2-beta6 /dev/pts/12 xterm-256color :0 20600/1000/5 1000/1000 0
[GNUPG:] SC_OP_FAILURE 2
[GNUPG:] SC_OP_FAILURE 2
Error changing the PIN: Bad PIN

[GNUPG:] GET_LINE cardedit.prompt
[GNUPG:] GOT_IT

As you can see there are three pinentry launched after unblock (which is the command Kleopatra/gpgme sends to gpg). The following GET_LINE is where Kleopatra/gpgme is next asked for input by gpg. Everything in between happens out-of-control of Kleopatra/gpgme.

The problem with b) is that GPG_ERR_BAD_PIN and GPG_ERR_BAD_RESET_CODE are both mapped to SC_OP_FAILURE 2 by gnupg. gpgme then maps SC_OP_FAILURE 2 back to GPG_ERR_BAD_PIN (because it has no way to know if the original error code was GPG_ERR_BAD_PIN or GPG_ERR_BAD_RESET_CODE).