Page MenuHome GnuPG

gpg should not proceed with the key import from the smartcard if no valid SCD READKEY information is received
Closed, ResolvedPublic

Description

I am experimenting with the scdaemon protocol and I just noticed that gpg - when asked to import the key from card - does not notice that the underlying smart card daemon crashed and accepts bogus data like this:

$ gpg2 --expert --full-generate-key
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC (sign and encrypt) *default*
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card
Your selection? 14
Serial number of the card: D2760001240111503131D5E113711111
Available keys:
<---- the crash happens here ----->
   (1) 63F8859168EC09711B4C16A163198FA04ECFED6F fe67bb79d35d2535_broken_broken_broken
_¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥ (null)
Your selection?

Here is how it looks like in the gpg-agent debug log:

2024-09-28 02:52:39 gpg-agent[61370] DBG: chan_8 <- SCD READKEY --info -- fe67bb79d35
d2535_broken_broken_broken_\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\x
a5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa
5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5    
2024-09-28 02:52:39 gpg-agent[61370] DBG: chan_9 -> READKEY --info -- fe67bb79d35d253
5_broken_broken_broken_\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\x
a5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa
5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5\xa5
2024-09-28 02:52:39 gpg-agent[61370] DBG: chan_9 <- [eof]
2024-09-28 02:52:39 gpg-agent[61370] DBG: chan_8 -> ERR 67125247 End of file <GPG Age
nt>
2024-09-28 02:52:39 gpg-agent[61370] daemon /usr/local/bin/my-broken-scdaemon killed
by signal 6

I believe it would be better (safer?) if gpg noticed it receives bogus data from the agent.

Event Timeline

Please send an excerpt from the scdaemon debug output to evaluate why you get somewhat strange looking data. Is this an experimental card? 0xa5 is a common test pattern.

scdaemon in this case was a broken experiment of mine (trying to see if I can get SoftHSM to work as the OpenPGP card). So this was not a normal, released scdaemon code.

What I really mean here is key algorithm selection code from GnuPG with --full-generate-key - probably the code after this line - https://dev.gnupg.org/source/gnupg/browse/master/g10/keygen.c;gnupg-2.4.5$2371, more precisely something around here https://dev.gnupg.org/source/gnupg/browse/master/g10/keygen.c;gnupg-2.4.5$2397 happily accepts the READKEY as valid even if it cannot tell what kind of key type it was, displaying (none).

Does that help a bit?

I don't know if gnupg can figure out the scdaemon crashed (as it did for me) but I am pretty sure it should not proceed if it did not receive a proper SCD READKEY response.

saper renamed this task from gpg should notice if scdaemon crashes to gpg should not proceed with the key import from the smartcard if no valid SCD READKEY information is received.Sep 30 2024, 11:54 AM
werner triaged this task as Normal priority.Sep 30 2024, 4:06 PM

Some would say it is a bug if keys are not shown - even if the algo is not known ;-)