I have another yubikey neo but its clean. Can it help it?

In T5167#139964, @gbschenkel wrote:

Changing modes will I lose/change my OTP and FIDO codes?

Changing modes will I lose/change my OTP and FIDO codes?

Following device (a bit older than yours, I guess) works well:

DBG: ccid-driver: idVendor: 1050  idProduct: 0112  bcdDevice: 0334

When I configure it to OTP+FIDO+CCID, it also works for me, it is:

DBG: ccid-driver: idVendor: 1050  idProduct: 0116  bcdDevice: 0334

Thanks a lot.
Let me explain the situation.

Hi, I changed the PIN, killed the gpg-agent and scdaemon, edited the scdaemon.conf to include your instruction, after, I run the following commands:

Thank you for the information.
In the log, the driver detects removal of card wrongly.
That's the cause of this problem.

In T5167#139880, @gniibe wrote:

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

Backported.

We need another patch, because there are two places for gpg --card-edit and gpg-card to check OpenPGPcard's version number if it's >= 2 or not.

There is no caching for smardcard PINs. Once a key (or group of keys) on a hard has been used (i.e. PIN entered). that key can be used as long as the card has not been reset or powered-down. No rule without exception: Some cards may require that a PIN entry is required for each crypto operation. For example the OpenPGP card (which is implemented on a Yubikey) does this for the signing key but not for the authentication (ssh) key. To disable this for the signing key you use the "forcesig" command of gpg --card-edit.

I think that T5150 was also not fixed completely.

I found a bug which resulted "Not Found <SCD>" when "SCD KEYINFO" is used with "--data" or "--".
It is fixed in rG54b88ae46062: scd: Fix KEYINFO command with --data option..

Fixed in master. I will backport to 2.2.

I was wrong. Patch is being updated...

I can't see how it occurs. "SCE KEYINFO" and "SCD READKEY" with keygrip both goes exactly same code path (the difference is only the "action" argument).

In T5163#139750, @werner wrote:

You better wipe ecc_d_padded or use xtrymalloc_secure.

You better wipe ecc_d_padded or use xtrymalloc_secure.

Here is a patch:

In future, please try to minimize your log. Your log actually includes information of the session of keytocard before setting key attributes correctly.

Seems to work now. I'm not sure whether I should close this issue because it's marked for backport.

Works now. Thanks.

Regarding a backport I think that I will eventually backport all app-*c to stable by source copying them. We have a quite stable internal API and thus it is easier to keep at least the card specific code in sync. I did some local work in this directory some time ago.

Finally, with the physical device, I figure out what's going on.
The error handling in bulk_in in ccid-driver.c is not good for pinpad input.
It doesn't return an error when it is cancelled or timeout (for the user interaction).
And it calls libusb_clear_hald which causes screwed up situation.

You are right, the new 3.4 cards support brainpool curves in addition to the nist curves.

Sorry, I realized this myself this morning and did couple of fixes. rG7113263a00d8 does this all however I forgot to mention the bug number.

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..

For the first issue, I pushed the change in rGc3a20c88fb30: scd: Fix an error return for READKEY..

Fixed in rG006944b856ee: scd,nks: Fix SEGV for learn for older card..

Great. Please apply the patch.

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!

This was fixed in 2.2.24 with commit rG7f765a98fd662

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?

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.

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.

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 ....:

For SPR532, we need following.

We should find a way to figure out the OpenPGP S/N even if OpenPGP is disabled. I'll ask Yubico.

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.

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.

SCD commands:

• DEVINFO
  • returns app apecific serialno
• SERIALNO
  • returns app specific serialno
• LEARN
  • returns canonical serialno

Pushed the change.

I created this patch D509: Yubikey supports two (or more) apps, serial number problem.

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.)

This doesn't help. I think that's because after

flush_cached_data (app, dobj->tag);

do_writecert does

do_readkey (...)

which fills the cache again.