FWIW, your comments about the autostart script do not match with the running processes. Obviously, the autostart script starts gpg-agent with different command line options than the running process. My conclusion is that the autostart script isn't used. Or maybe it is started, but gpg-agent immediately terminates because it notices that another instance is already running.

If you add an autostart script then you may have to add a corresponding shutdown script as well, e.g. a script running gpgconf --kill all. You cannot expect that daemons, that you start via an autostart script, magically know when they should terminate.

Thank you for the hints!

Thank you for the explanation. (It's not related to --supervised, I suppose.)

I see the following GPG-related commands running currently (with disable-scdaemon in config file):

The issues mentioned in the previous comment have been fixed.

I had a look at the file system watcher we use to react on changes in the GnuPG home directory. It doesn't watch the private keys living in private-keys-v1.d. Moreover, it does not handle the removal of files properly.

My Yubikey (Yubico.com Yubikey 4/5 OTP+U2F+CCID) (key Ed25519) works fine with OpenSSH using kex of sntrup761x25519-sha512@openssh.com.

Please contact the Debian developers for any systemd/gnupg issues. We don't suggest the use of the --supervised option because it causes more problems than it claims to solve.

Sorry, I was confused. For RSA-4096, data is hashed by gpg-agent and hashed data is signed by a card.

We are using rsa-4096 on smartcard for quite some time; so I wonder what's the problem here. Is that that we don't use our Assuan hack for large key material with OpenPGP.3?

There is another case: RSA-4096 key. scdaemon rejects data by Invalid value. Unfortunately, there is no fix for this, as it's really too large. Even if scdaemon allows larger data, the card implementation rejects, when it conforms to PKCS #1 standard (data should not be larger than 40% of the modulus).

I confirmed that the patch above works with newer Gnuk (>= 1.2.16).

With newer Gnuk Token, following patch should work:

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 05e1f3977..439052f8c 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -5490,6 +5490,11 @@ do_auth (app_t app, ctrl_t ctrl, const char *keyidstr,
           exmode = 1;    /* Use extended length.  */
           le_value = app->app_local->keyattr[2].rsa.n_bits / 8;
         }
+      else if (app->app_local->cardcap.cmd_chaining && indatalen > 254)
+        {
+          exmode = -254; /* Command chaining with max. 254 bytes.  */
+          le_value = 0;
+        }
       else if (indatalen > 255)
         {
           if (!app->app_local->cardcap.ext_lc_le)

When we will find reproducible test case, please reopen.

And updated scd_validate2.py:

Wrote a pam module which interacts a user for auth:

I write a prototype in Python using pyassuan:

More things to be considered:

• How to connect scdaemon
• How to invoke scdaemon

BTW, there are various use cases for authentication(s), it is better to focus on the part of device and crypto (USB Token and scdaemon).

Here is an experimental shell script for testing:

It may be simpler if we can enhance scdaemon to have an option for PKAUTH, say, --challenge-response, so that it generates a challenge and verify signature internally.

In T5837#155062, @werner wrote:

Setting the management key has been implemented only for Yubikeys. So for Gemalto this won't work.

Thank you for your suggestion.

The problem was the error handling.
I didn't apply the patch directly, but improved the code paths.

Adding the check on host side, I pushed the change: rGa575b0aba542: scd:openpgp: Support longer data for INTERNAL_AUTHENTICATE.

Kleopatra now checks both keyserver options. Previously, Kleopatra checked only one of them depending on the version of gpg (< 2.3.0 vs. >= 2.3.0). Note that the automatic lookup is only done if the keyserver option specifies an LDAP server, i.e. if it starts with "ldap".

Lets downgrade the priority and keep it open in case we get reports from customers. The other option would be to replicate this here using our AD demo network. But that is a bit time consuming.

As long as we can't replicate this, it does not make sense to keep this bug open. Please re-open it if you run into it again in a replicatable way.

For 2.3, when you use PC/SC, please use the disable-ccid option in your .gnupg/scdaemon.conf.

by the way when the applet is selected, I return
D2760001240103045343000000010000
this can be used to detect the manufacturer number

Card ATR at the cool reset
Card ATR is : 3B 9C 95 81 01 50 53 43 50 2D 53 43 53 56 31 2E 30 8E
Historical Byte is 53435356312E30
CARD ATS-to-ATR is : 3B 8C 80 01 50 53 43 50 2D 53 43 53 56 31 2E 30 0A
CARD ATS is : 11 78 80 B8 02 50 53 43 50 2D 53 43 53 56 31 2E 30
Historical Byte is 53435356312E30
This can by detected for the card type.

Is there another way to to detect your card (I assume a Javacard) without relying on the openpgp card application vendor-id like we do it with the Yubikey? I want to avoid a possible early but expensive AID selection just to get the vendor-id.

Fixed in 2.3.2.

Works for a long time now (unless we broke it again;-)

This rwlock guarantees access with ctrl->card_ctx is always valid.

FWIW: We have always refused to support shared mode because we anticipated such problems. However, we have a customer using their own cards along with card maintenance software of them. For their purposes PCSC_SHARED works just fine makes and this is why I decided to add --pcsc-shared along with a warning that it is in general not a good idea.

You need to protect only 2 critical set of ADPU sequence Sign and Decrypt. All other can be done not safely and have a minor impact. Get generation and cards unlock can be profitable with the transaction mode... but is very rare user makes another use of the card in same time he start that’s command. The check external interference can protect from a bad start. I have started this ticket because my card suffer in exclusive mode render the use of openpgp not really usable. When my card is an pcsc-shared mode, all it's OK but the daemon not able to restore after external interference. The correction proposed is OK but I have made recommendations because this can cause a bad applet switch... if the state does not restore before trying to switch applet all it's OK. I am not actually able to set directly differential code but I have described in the patch the change I have made and this make my card very happy. Not problems and the pin was queried if another application makes interference.

There are multiple issues here.

OK I have finally success to test... the master version has a problem with opening pcsc readers on windows I revert back on older version to able to correct this problem. For the current patch without yubikey reference. I suggest validating the interference in the first task for the maybe_switch app function.

In fact, the trigger is not yubikey but the pcsc-shared flag... If the pcsc-shared flag is enabled, you do check for interference because you are in shared condition. It is not really a race condition because you can put the driver in transaction mode. It’s more a turn-by-turn games but you can lose the card context status between turn.
If you lock the patch only for yubikey I’m not able to test with my device. You can add my manufacturer ID in the test please.

Thank you for your explanation.

It's not a device is a card. NXP P71 security chips on the card in the 250Kb Rom with GlobalPlateform 2.1.1 It is not possible for a card to change CCID by applet. Card depends of reader CCID. When the card is on NFC readers, the FIDO applet is accessible not when it is on contact readers. But, when I am in NFC FIDO share the CCID. For the user point of view having multiple card for each applet is a bad thing to devices for one user. User search presently for multipurpose devices. DOOR, Login, Email-crypt, ledger. Actually for app is not recommended to use a reader in exclusive mode. By designs the card is stateless and for memory management deselect applet free mem from other applet. Presently in the best case the card has 144-255 KB of eeprom and 2k or ram.

If your token/card is not Yubikey and when it is possible to improve your token/card implementation, I would suggest not follow what Yubikey does for multiple applications; No multiple applications, but each feature with independent access (card+CCID, another card+different CCID, FIDO+HID, ...).

i'am not able to test... i can't build for win32. i have some trouble with my mingw32 installation and the miss match with library for build a functional version of gnupg for win32.
seem missing dll after make install folder. do you have instruction to setup dev environment for build win32 binary ? I use a ubuntu with minwg32. ntbtls seem missing ksba but libksba is already install verion 1.6.0 other project detect correctly ksba. it's seem is a little bit complicated juste for building scd project. a make it working correctly on windows environements.

Ok i have seen a problem with a double check here