Sorry, I realized this myself this morning and did couple of fixes. rG7113263a00d8 does this all however I forgot to mention the bug number.
Nov 26 2020
Argh. The following patch replaces the previous patch. It fixes the calculation of the display serial number.
I think the calculation of the OpenPGP s/n is not correct. As you write, "Yubico seems to use the decimalized version of their S/N as the OpenPGP card S/N." This matches my observation for my Yubikey:
s/n printed on Yubikey: 9074582
Yubikey s/n (with our prefix): FF020001008A7796
OpenPGP AID: D2760001240102010006090745820000
If you mean OpenPGP Card v3 standard, no it did not support cv25519 ed25519, but some other curves up until v3.4. So if there is a specific specification bringing this feature, can you might refer to the specific version? Otherwise, I think this task is still valid.
I remember the problem being the card manufacturers that are not interesting in cv25519 (yet).
Support was added in version 3 card.
Applied and push the change above in rG920154370834: scd,nks: Fix caching keygrip..
Nov 25 2020
For the first issue, I pushed the change in rGc3a20c88fb30: scd: Fix an error return for READKEY..
Great. Please apply the patch.
Nov 24 2020
Okay, I now got such a patch:
I found a good enough solution: I changed the code to compute the OpenPGP s/n from the Yubikey s/n right after a Yubikey has been detected. Later, and if OpenPGP enabled on the YK, the S/N is already there but we use the S/N from the 0x4f DO. That is needed because we can't compute the OpenPGP version number ahead and use 0.0 in the S/N.
Stable now and works as expected. Thank you!
Nov 23 2020
This was fixed in 2.2.24 with commit rG7f765a98fd662
Nov 20 2020
The above workaround may not be necessary because another code path sets the algorithm string as seen in
$ gpg-connect-agent "SCD READKEY --info -- NKS-NKS3.4531" /bye S KEYPAIRINFO 39400430E38BB96F105B740A7119FE113578B59D NKS-NKS3.4531 - - rsa2048
The following patch fixes the crash:
diff --git a/scd/app-nks.c b/scd/app-nks.c index 47be7cd85..4d925dccd 100644 --- a/scd/app-nks.c +++ b/scd/app-nks.c @@ -871,7 +871,7 @@ do_learn_status_core (app_t app, ctrl_t ctrl, unsigned int flags, id_buf, strlen (id_buf), usagebuf, strlen (usagebuf), "-", (size_t)1, - algostr, strlen (algostr), + algostr, algostr ? strlen (algostr) : (size_t)0, NULL, (size_t)0); } xfree (algostr);
How about distinguishing CARDNO and application specific SERIALNO?
Nov 19 2020
Thanks again for your report.
I'm still having problems with 2.2.24. Now the card removal is detected correctly, but the initialization fails.
Nov 18 2020
Nov 17 2020
Nov 12 2020
BTW, the idea is to fade out support for gpg --card-status and --card-edit. Thus no new features there. New features shall only go into gpg-card.
Fixing --card-status is definitely a good idea. gpg-card shows almost the same information as gpg --card-status except that it shows the correct "Version" and "Serial number". It would probably make sense to unify the code of --card-status and gpg-card's list command.
Let me describe current situation.
Nov 11 2020
I just noticed that gpg --card-status now prints a bogus OpenPGP version number for my Yubikey. And it prints an empty serial number.
# gpg --card-status Reader ...........: 1050:0407:X:0 Application ID ...: FF020001008A7796 Application type .: OpenPGP Version ..........: 77.96 Manufacturer .....: Yubico Serial number ....:
Nov 10 2020
Nov 9 2020
Nov 5 2020
For SPR532, we need following.
Nov 2 2020
We should find a way to figure out the OpenPGP S/N even if OpenPGP is disabled. I'll ask Yubico.
Oct 29 2020
I forgot that we have LOCK and UNLOCK commands in scdaemon. This was implemented around 2005 but there are no more users in gpg meanwhile.
Oct 28 2020
I have tested this with Kleopatra. The good news is that SCD GETATTR $DISPSERIALNO now works for the piv app even if the openpgp app is enabled.
Oct 27 2020
- returns app apecific serialno
- returns app specific serialno
- returns canonical serialno
Oct 26 2020
Pushed the change.
Oct 21 2020
I created this patch D509: Yubikey supports two (or more) apps, serial number problem.
Oct 19 2020
But changing just the displayed S/N should not disturb anything.
No, the above patch makes OpenPGP app stop working.
(I don't know well about Yubikey specific serial number.)
Oct 13 2020
This doesn't help. I think that's because after
flush_cached_data (app, dobj->tag);
which fills the cache again.
Caching issue. do_writecert in app-piv flushes the cache but may be the wrong DO. Can you try to
Oct 12 2020
Oct 9 2020
Oct 8 2020
I have added a workaround to Kleopatra: rKLEOPATRA57cf71b043d198f85270eb3b8782de6277b8b889
Sep 30 2020
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.
Sep 29 2020
Sep 28 2020
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.
Sep 26 2020
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.
Sep 25 2020
Currently, yes. After some testing, I'll backport it to 2.2.
Sep 24 2020
Nice, thanks! If I want to try this fix, should I just compile the master tree?
Sep 17 2020
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!
Sep 16 2020
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.
Sep 15 2020
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.
Sep 14 2020
Thanks for prompt answer!
Thanks for the detailed report. Does the green LED blink fast when it does not work?
Sep 11 2020
The data object 0x00FA is now supported. And other changes are not needed.
Sep 1 2020
Aug 28 2020
Aug 19 2020
I am the worst. I totally forgot about this.
No more information, can't proceed, thus, closed.
Aug 13 2020
We won't do such a interface now.
Jul 28 2020
Jul 27 2020
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.