I have added a workaround to Kleopatra: rKLEOPATRA57cf71b043d198f85270eb3b8782de6277b8b889

I observed that the card reader's going erroneous state when I removed a card during its communication.
In this state, it never reports the card removal by the interrupt transfer.
I applied rG920f258eb601: scd: Internal CCID driver: More fix for SPR532. for this problem.

The patch rG684a52dffa8b: scd: Change handling of SPR532 card reader. makes me happier. It is more stable.

This is also what I found out with my tests with the libvirt usb: removing and redirecting back the device got it working again.

Testing more, I managed to encounter failure with physical usb.
Once in this failure mode, I need to remove the card reader from USB and reinsert again.
I need to figure out a sequence to avoid this situation and to reset the card reader correctly.

I tested with physical usb, did multiple operations with external events (insert/remove/etc. for card). I haven't seen any problem (if so, I were doing more fixes), so far.

Ok. Tried to test this with master, but failed. I got it compiled and installed, and it actually detected the first removal after reboot/suspend/reader attach/whatever reason, but after that when I inserted the card back, it didn't function anymore. I suppose you also tried that? I mean that's the use case, I suppose: to be able to remove/insert the card reliably all day long.

Currently, yes. After some testing, I'll backport it to 2.2.

Nice, thanks! If I want to try this fix, should I just compile the master tree?

This is everything lsusb knows about the device:

And please report the output of lsusb -d 04e6:e003 for the information of the card reader.

@turkja Thanks for your information.
May I ask you one thing?
Please show me the usb VID:PID of your card reader.
Is it 04e6:e003?
You can examine a line of the output by lsusb.

Just wanted to add to my initial findings:

• I was not using proprietary drivers (libscmccid.so.5.0.35), because the installer script fails to install on default CentOS 8 pcsc-lite. So the distribution pcsc-lite also doesn't have this issue.
• Fastest way to test this condition is to just detach/attach the reader device.
• Proprietary drivers doesn't support secure pin entry!

Thanks for sending.

Here is the output for an SCM SPR532

Bus 001 Device 123: ID 04e6:e003 SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader

Is it an alias of SPR532? Please show me the USB vendor ID and product ID.

Okay, I have the same problem at my office and thus I should be able to figure out the reason. I have ignored the problem until now because the wokraround is easy enough and in most cases I authenticate with my token anyway. But yes, this needs to be fixed.

Thanks for prompt answer!

Thanks for the detailed report. Does the green LED blink fast when it does not work?

The data object 0x00FA is now supported. And other changes are not needed.

I am the worst. I totally forgot about this.

No more information, can't proceed, thus, closed.

We won't do such a interface now.

Well, it is now defined. We use a CMS object containing an OpenPGP keyblock container. Right, there is no open standard for it but with OIDs you don't really need them. it is a bit of a hack but it works with the majority of deployed cards and the overhead is quite small.

@wener But it uses undefined data structure of "certificate" DO, IIUC. My point is defining DOs for OpenPGP, so that host side can construct OpenPGP object from those DOs.

Item 2 and 3 have already been solved by allowing to store a minimal key.

That could also be the reason for some strange behaviour I have sometimes with my bunch or readers. I have not had the time to look into this and thus opted for a gpgconf --kill scdaemon which fixes things quickly but of course this is a bad workaround.

I am happy that your use case will be supported, and the bug was fixed before the release.
It's me who say "thank you" to you!

46d185f60 doesn't segfault and does prints the YubiKey card information, even without reader-port configured. Perfect! That will fix the issue for me. Looking forward to seeing it released. Thanks again @gniibe!

Thanks a lot.
I pushed a fix as rG46d185f60397: scd: PC/SC: Don't release the context when it's in use..

Thanks again @gniibe! In case it's still useful, I bisected to 1080e91ef. The output with --debug-all --debug-level guru is:

Ah, I identified an issue.
While it's in a loop of trying readers (in select_application in scd/app.c), it should not deallocate resources to access readers, even if reference count == 0.
I'll fix.

Thanks for your testing.

Thanks for the detailed explanation, I'm glad to hear it! Out of curiosity, I tried running echo 'serialno openpgp' | ./scd/scdaemon --log-file - -v --server built from 43000b043 and it printed:

Thanks for your report.
Major reason was multiple card readers/tokens were not supported by PC/SC handling of scdaemon, only a single reader was assumed, so, user had to specify one if it's not the first one.
Multiple reader by PC/SC support was added in master (to be 2.3), so, I think the problem is solved in master.

I agree.
It (only) fixed a regression where a user can specify a fingerprint to select a card (rarely used feature in the scdaemon protocol).

Ok. However, I don't think that the fingerprint is really important. We can compute it anyway as long as we have the creation date. The keygrip is meanwhile more important but that is also easy to compute.

Perhaps, no change would be required.
My major concern is that: the data object for fingerprints C5 and C6 were defined as fixed-size 60-byte objects (and actually _is_ defined still in the current specification of 3.4), but it's 80-byte (newer Yubikey), which might cause problem(s).

Why do you think that we need to care about the attestation key? Where possible I take in new code in account that we will have more OpenPGP keys, but right now I don't think that is makes sense to replace our data structures for that the 3 element arrays we currently use are okay for the 3 standard keys. We can latter see how to replace them. At one place I already introduced something new:

Here is a dump of my token (Yubikey 5.2.6). I used the new apdu command of gpg-card along with "undump | dumpasn1 -", which saves quite some time:

Hand parsing the data object content:

fa 82 01 e2
   c1 06
      010800001100
   c1 06
      010c00001100
   c1 06
      011000001100
   c1 09
      132a8648ce3d030107
   c1 06
      132b81040022
   c1 06
      132b81040023
   c1 06
      132b8104000a
   c1 0a
      132b2403030208010107
   c1 0a
      132b240303020801010b
   c1 0a
      132b240303020801010d
   c1 0a
      162b06010401da470f01
   c1 0b
      162b060104019755010501
   c2 06
      010800001100
   c2 06
      010c00001100
   c2 06
      011000001100
   c2 09
      122a8648ce3d030107
   c2 06
      122b81040022
   c2 06
      122b81040023
   c2 06
      122b8104000a
   c2 0a
      122b2403030208010107
   c2 0a
      122b240303020801010b
   c2 0a
      122b240303020801010d
   c2 0a
      162b06010401da470f01
   c2 0b
      162b060104019755010501
   c3 06
      010800001100
   c3 06
      010c00001100
   c3 06
      011000001100
   c3 09
      132a8648ce3d030107
   c3 06
      132b81040022
   c3 06
      132b81040023
   c3 06
      132b8104000a
   c3 0a
      132b2403030208010107
   c3 0a
      132b240303020801010b
   c3 0a
      132b240303020801010d
   c3 0a
      162b06010401da470f01
   c3 0b
      162b060104019755010501
   da 06
      010800001100
   da 06
      010c00001100
   da 06
      011000001100
   da 09
      132a8648ce3d030107
   da 06
      132b81040022
   da 06
      132b81040023
   da 06
      132b8104000a
   da 0a
      132b2403030208010107
   da 0a
      132b240303020801010b
   da 0a
      132b240303020801010d
   da 0a
      162b06010401da470f01
   da 0b
      162b060104019755010501

And here is (raw) dump of the data object FA:

Here is the dump of "Application Related Data" (6E):

6e 82 01 47
   4f 10
      d2760001240103040006106160490000
   5f 52 08
      00730000e0059000
   7f 74 03
      810120
   73 82 01 20
      c0 0a
         7d000bfe080000ff0000
      c1 0b
         162b06010401da470f0100
      c2 0c
         122b06010401975501050100
      c3 0b
         162b06010401da470f0100
      da 06  <-------------------------------------- This is algorithm attributes for Attestation key (Yubikey specific)
         010800001100
      c4 07
         ff7f7f7f030003
      c5 50
         eeeed1b50b1b1d9c669033fe019e94a27992b44c
         d00b630fdcb5c4397d5ffbd69aa68a3ff9f8ed10
         1b2a3d46f4f0c5afd0115e7eb858d476daf64cdb
         0000000000000000000000000000000000000000  <--- This appears to be fingerprint of Attestation key
      c6 50
         0000000000000000000000000000000000000000
         0000000000000000000000000000000000000000
         0000000000000000000000000000000000000000
         0000000000000000000000000000000000000000  <--- This appears to be fingerprint of some key related to Attestation key???
      cd 10
         5e58b1e65e58b1c55e58b1f900000000
      de 08
         0102020203028102
   7f 66 08
      02020bfe02020bfe
   d6 02
      0020
   d7 02
      0020
   d8 02
      0020
   d9 02
      0020

It runs like:

$ gpg-connect-agent "scd devinfo --watch" /bye
S DEVINFO_START
S DEVINFO_END
S DEVINFO_STATUS new
S DEVINFO_START
S DEVICE generic D276000124010200F517000000010000 openpgp
S DEVINFO_END
S DEVINFO_STATUS removal
S DEVINFO_START
S DEVINFO_END
OK
$ 

Push the change to master.

The return value that was mapped to invalid value was "SW_WRONG_LENGTH" so I tested using the codepath for the SW_EXACT_LENGTH sw return value, too and it worked for readcert.

Created https://dev.gnupg.org/source/gnupg/history/gniibe%252Fscd-watch/

Backported to 2.2

I pushed the change to master.

Fixed in master.

I would prefer to have a procedure that do not reset PINs to their default values, but as long as all PINs are set to known and valid values when KDF is setup it will not make the token unusable after that, so it seems reasonable to me.

Or, #5 would be:

@Amaud, I read your code in Python. IIUC, it asks users PW1, Reset Code, and PW3 to setup, just before registering KDF DO (as you describe in https://dev.gnupg.org/T3891#114950).

Thanks for concrete cases. Sorry, not responding earlier. It was an experimental feature, firstly only available in Gnuk Token.

I implemented the script described previsouly (https://dev.gnupg.org/T3891#114950) in the smartpgp-cli utility provided in the SmartPGP repository (see commit https://github.com/ANSSI-FR/SmartPGP/commit/4be0fa442b43c2bafd5f0171417ff68fd88cbe2d).

Some users of ours wanted to use KDF with their OpenPGP smart cards. Could you tell when solution to this issue could be expected?
Additionally, is there any workaround for the current state? Perhaps based on T3823, or on derived [1]? To which values the PINs had to be set?

There is no use cases for $SIGNKEYID.

$ENCRKEYID use case have been removed.

Caching of the OpenPGP PIN while switching to and from PIV does now work in master