2.2.22 regression: Nitrokey Pro 2 is no longer recognized automatically, requires --card-status
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	mgorny
	Aug 31 2020, 8:26 AM

Description

After upgrading to 2.2.22, my Nitrokey stopped being recognized by GnuPG automatically. If I attempt e.g. to decrypt a file, I get:

gpg: encrypted with 4096-bit RSA key, ID 580C5E1242C5AD46, created 2013-02-20
      "Michał Górny (Gentoo) <mgorny@gentoo.org>"
gpg: public key decryption failed: End of file
gpg: decryption failed: No secret key

Running gpg --card-status causes it to find the Nitrokey and start working correctly. However, in previous versions this worked out of the box.

I've been able to bisect this to the following commit:

commit d2f1a0a791db3eb03c003365cbcd010bd8066edb (HEAD, refs/bisect/bad)
Author: NIIBE Yutaka <gniibe@fsij.org>
Date:   2020-08-27 03:41:51 +0200

    scd: Add condition for VERIFY with 0x82.
    
    * scd/app-openpgp.c (verify_chv2): Check availability of keys in
    question.
    
    --
    
    Backport master commit of:
            af189be481df02a77e088aa0a60a1fc02dfa12bf
    
    With buggy Gnuk (<= 1.2.15), when no encr/auth keys are available,
    it fails decrementing the signature error counter.  This change
    can avoid the issue.
    
    Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>

This is Gentoo Linux. Problem reproduced with 2.2.22 and git STABLE-BRANCH-2-2.

The seemingly non-privacy-infringing portion of card-status:

Reader ...........: 20A0:4108:000000000000000000008655:0
Application ID ...: D2760001240103030005000086550000
Application type .: OpenPGP
Version ..........: 3.3
Manufacturer .....: ZeitControl

Details

Version: 2.2.22

Revisions and Commits

rG GnuPG
	rG0a9665187a7c scd: Fix a regression for OpenPGP card.

Related Objects

Mentioned In: T5045: Release GnuPG 2.2.23
T5030: Release GnuPG 2.2.22
Mentioned Here: rG1049f06c6d2e: scd:openpgp: Allow keygrip to be used to reference a key
rG84020385be19: scd:openpgp: Public keys should be available for check_keyidstr.
rG0a9665187a7c: scd: Fix a regression for OpenPGP card.

Event Timeline

mgorny created this task.Aug 31 2020, 8:26 AM

mgorny added a subscriber: • gniibe.

• werner mentioned this in T5030: Release GnuPG 2.2.22 .Aug 31 2020, 9:22 AM

Do you have a signing key in your card or not?

Ah, I see the situation of the regression.
When the token is not yet accessed at all, scdaemon misunderstood as no signing key.

Yes, I do have a signing key (that is distinct from the primary key, primary key I don't store on the smartcard).

• werner added a project: gnupg (gpg22).Aug 31 2020, 12:54 PM

I think that following patch can solve the issue:

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 8a1d30d5b..ccc360fc8 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -2357,10 +2357,15 @@ verify_chv2 (app_t app,
   int rc;
   char *pinvalue;
   int pinlen;
+  int i;
 
   if (app->did_chv2)
     return 0;  /* We already verified CHV2.  */
 
+  /* Make sure we have load the public keys.  */
+  for (i = 0; i < 3; i++)
+    get_public_key (app, i);
+
   if (app->app_local->pk[1].key || app->app_local->pk[2].key)
     {
       rc = verify_a_chv (app, pincb, pincb_arg, 2, 0, &pinvalue, &pinlen);

My excuses:
In master branch of GnuPG development, public keys are always available.
I introduced the workaround change with the assumption of available key information, and
I was not careful enough when I backport the workaround to 2.2 branch.

• gniibe triaged this task as High priority.Sep 1 2020, 7:11 AM

I can confirm that the patch seems to resolve the issue for me.

Thanks a lot. Applied and pushed.

• gniibe added a commit: rG0a9665187a7c: scd: Fix a regression for OpenPGP card..Sep 1 2020, 8:49 AM

I should add a test with Gnuk to my Windows quick test after a release.

What are we going to do? Want a week and then release 2.2.23 ?

Hi,
I have tested a GnuPG Token with Gpg4win-3.1.12 and generating a key with Kleopatra did not work
With 2.2.23-beta4 that contains: 0a9665187a7cbf68933b7162fb5f974177684a50 I have repeated the test on Linux and first the key-attr change that Kleopatra sends fails:

Reader ...........: 234B:0000:FSIJ-1.2.15-4231806C:0
Application ID ...: D276000124010200FFFE4231806C0000
Application type .: OpenPGP
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 4231806C
Name of cardholder: [not set]
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 : 3 3 3
Signature counter : 2
KDF setting ......: off
Signature key ....: B083 7A3B 0796 C3A2 85F9  47FA 96DF 4170 D2B9 5F28
      created ....: 2020-09-02 11:10:55
Encryption key....: F3D6 81BC 6E43 32E1 78D0  35BE 0A18 6B4C 16D6 30A7
      created ....: 2020-09-02 11:10:55
Authentication key: 8D86 C037 748E CE6A 28F4  7516 7E39 4252 FA2B AB67
      created ....: 2020-09-02 11:10:55
General key info..: [none]

gpg/card> keyattr

Invalid command  (try "help")

gpg/card> admin
Admin commands are allowed

gpg/card> key-attr
Changing card key attribute for: Signature key
Please select what kind of key you want:
   (1) RSA
   (2) ECC
Your selection? 1
What keysize do you want? (2048) 3072
The card will now be re-configured to generate a key of 3072 bits
gpg: error changing key attribute for key 1: Card error

Generate without changing key-attr also fails in Kleopatra with "general error" but currently works for me on the command line, I have yet to figure out why this fails when using kleo.

Is this related or should we move this to a different issue?

It's a different issue: Gnuk doesn't support length of 3072, only 2048 and 4096.

• werner closed this task as Resolved.Sep 3 2020, 6:47 PM

• werner mentioned this in T5045: Release GnuPG 2.2.23.

The problem seems to have returned in 2.2.24.

Yes, it is due to a backport from master: rG1049f06c6d2e: scd:openpgp: Allow keygrip to be used to reference a key
Fixed in rG84020385be19: scd:openpgp: Public keys should be available for check_keyidstr..

Sorry for the trouble.

• werner moved this task from Backlog to Ready for release on the gnupg (gpg22) board.Nov 23 2020, 1:46 PM

• werner closed this task as Resolved.Nov 23 2020, 7:59 PM