Page MenuHome GnuPG

Using Yubikey with GnuPG+scdaemon and PKCS11 over pcscd errors
Open, NormalPublic

Description

TL;DR: Using Yubikey as SSH key, or decrypting PGP text, with GnuPG fails after Yubikey has been used by another PKCS11 program through pcscd.

I'm using a Yubikey 5C with on my Devuan machine running latest daedalus (testing).

The machine uses Yubikey as PKCS11 token with PCSCd, pam_pkcs11, Firefox etc, but also uses it as a "smart card" for GnuPG with scdaemon.

All pkcs11 operations works as normal (as long as no program locks the key on usage)

gpg-agent can use the key for GPG+SSH after it has been plugged in, but if some other program uses the key through pcscd, the key cannot be used with gpg-agent or scdaemon
until the key has been unplugged and plugged in again.

gpg-agent.conf

default-cache-ttl 300
enable-ssh-support
no-grab
max-cache-ttl 999999
allow-emacs-pinentry

scdaemon.conf

verbose
debug-level expert
log-file /home/mkj/.gnupg/scdaemon.log
pcsc-shared

gpg-agent log exhibit after error:

2022-09-25 18:13:38 gpg-agent[3152] new connection to SCdaemon established (reusing)
2022-09-25 18:13:38 gpg-agent[3152] DBG: chan_11 -> SERIALNO --demand=....
2022-09-25 18:13:38 gpg-agent[3152] DBG: chan_11 <- S SERIALNO ....
2022-09-25 18:13:38 gpg-agent[3152] DBG: chan_11 <- OK
2022-09-25 18:13:38 gpg-agent[3152] detected card with S/N ....
2022-09-25 18:13:38 gpg-agent[3152] DBG: chan_11 -> SETDATA ....
2022-09-25 18:13:38 gpg-agent[3152] DBG: chan_11 <- OK
2022-09-25 18:13:38 gpg-agent[3152] DBG: chan_11 -> PKDECRYPT ....
2022-09-25 18:13:38 gpg-agent[3152] DBG: chan_11 <- ERR 100663404 Card error <SCD>
2022-09-25 18:13:38 gpg-agent[3152] smartcard decryption failed: Card error
2022-09-25 18:13:38 gpg-agent[3152] command 'PKDECRYPT' failed: Card error <SCD>
2022-09-25 18:13:38 gpg-agent[3152] DBG: chan_10 -> ERR 100663404 Card error <SCD>
2022-09-25 18:13:38 gpg-agent[3152] DBG: chan_10 <- [eof]
2022-09-25 18:13:38 gpg-agent[3152] DBG: chan_11 -> RESTART
2022-09-25 18:13:38 gpg-agent[3152] DBG: chan_11 <- OK

scdamon log exhibit after error:

2022-09-25 18:13:38 scdaemon[5793] DBG: chan_7 <- SERIALNO --demand=....
2022-09-25 18:13:38 scdaemon[5793] ccid open error: skip
2022-09-25 18:13:38 scdaemon[5793] DBG: chan_7 -> S SERIALNO .....
2022-09-25 18:13:38 scdaemon[5793] DBG: chan_7 -> OK
2022-09-25 18:13:38 scdaemon[5793] DBG: chan_7 <- SETDATA ....
2022-09-25 18:13:38 scdaemon[5793] DBG: chan_7 -> OK
2022-09-25 18:13:38 scdaemon[5793] DBG: chan_7 <- PKDECRYPT ....
2022-09-25 18:13:38 scdaemon[5793] DBG: send apdu: c=00 i=2A p1=80 p2=86 lc=39 le=256 em=0
2022-09-25 18:13:38 scdaemon[5793] DBG:   PCSC_data: ....
2022-09-25 18:13:38 scdaemon[5793] DBG:  response: sw=6D00  datalen=0
2022-09-25 18:13:38 scdaemon[5793] operation decipher result: Card error
2022-09-25 18:13:38 scdaemon[5793] app_decipher failed: Card error
2022-09-25 18:13:38 scdaemon[5793] DBG: chan_7 -> ERR 100663404 Card error <SCD>
2022-09-25 18:13:38 scdaemon[5793] DBG: chan_7 <- RESTART
2022-09-25 18:13:38 scdaemon[5793] DBG: chan_7 -> OK

I have deliberately replaced some data with dots. Not sure if its relevant...

Details

Version
2.2.39

Related Objects

Event Timeline

werner triaged this task as Normal priority.Sep 26 2022, 8:14 AM
werner edited projects, added gnupg (gpg23), scd, scute; removed gnupg (gpg22).
werner added a subscriber: werner.

There is a reason why pcsc-shared is not the default ;-). Please try using Scute (best the t6002 branch until it has been merged) as pkcs#11 provider instead of pam_pkcs11. And you should of course use the stable version of GnuPG and not the LTS (2.2).

I'm not sure what you mean with using Scute as PKCS#11 provider instead of pam_pkcs11, as pam_pkcs11 is not a provider but a user of PKCS#11

I think Werner may have confused pam_pkcs11 with gnupg-pkcs11-scd. :)

But you can indeed try to use Scute, not as replacement of pam_pkcs11, but as the PKCS#11 module that pam_pkcs11 should use.

I can’t help much with that as I have never used pam_pkcs11, but from a quick look at the documentation that would mean editing /etc/pam_pkcs11/pam_pkcs11.conf to instruct pam_pkcs11 to use the Scute module (scute.so) instead of the OpenSC one (opensc-pkcs11.so).

Yes, I meant to use Scute as pkcsc11 module for pam_pkcs11. Thanks for explaining more verbosely what I meant.

Using Scute as a drop-in replacement doesn't currently work. Perhaps my config needs more adjustments than just:

module = /usr/lib/x86_64-linux-gnu/scute/scute.so
$ su -l
Smartcard authentication starts
DEBUG:pam_pkcs11.c:335: username = [root]
DEBUG:pam_pkcs11.c:346: loading pkcs #11 module...
DEBUG:pkcs11_lib.c:1000: PKCS #11 module = [/usr/lib/x86_64-linux-gnu/scute/scute.so]
DEBUG:pkcs11_lib.c:1016: module permissions: uid = 0, gid = 0, mode = 644
DEBUG:pkcs11_lib.c:1026: loading module /usr/lib/x86_64-linux-gnu/scute/scute.so
DEBUG:pkcs11_lib.c:1034: getting function list
DEBUG:pam_pkcs11.c:361: initialising pkcs #11 module...
DEBUG:pkcs11_lib.c:1180: module information:
DEBUG:pkcs11_lib.c:1181: - version: 2.20
DEBUG:pkcs11_lib.c:1182: - manufacturer: g10 Code GmbH                   
DEBUG:pkcs11_lib.c:1183: - flags: 0000
DEBUG:pkcs11_lib.c:1184: - library description: Cryptoki for SCDaemon           
DEBUG:pkcs11_lib.c:1185: - library version: 1.0
DEBUG:pkcs11_lib.c:1077: number of slots (a): 1
DEBUG:pkcs11_lib.c:1100: number of slots (b): 1
DEBUG:pkcs11_lib.c:1112: slot 1:
DEBUG:pkcs11_lib.c:1122: - description: GnuPG Smart Card Daemon                                         
DEBUG:pkcs11_lib.c:1123: - manufacturer: g10 Code GmbH                   
DEBUG:pkcs11_lib.c:1124: - flags: 0007
DEBUG:pkcs11_lib.c:1126: - token:
DEBUG:pkcs11_lib.c:1132:   - label: ....
DEBUG:pkcs11_lib.c:1133:   - manufacturer: unknown                         
DEBUG:pkcs11_lib.c:1134:   - model: OpenPGP         
DEBUG:pkcs11_lib.c:1135:   - serial: ....        
DEBUG:pkcs11_lib.c:1136:   - flags: 050b
ERROR:pam_pkcs11.c:384: no suitable token available
Error 2306: No suitable token available

Anyway, I still want to use the PIV features of the key alongside with PGP. I have a separate RSA key and X509 certificate loaded onto the key that I want to use for login, and other tasks.
For this it seems to me I need to make gpg+scdaemon coexists with pcscd ...

Which version of Scute are you using?

Devuan deadalus is apparently providing Scute-1.5.0. If that’s what you are using, it’s already 5 years old. You should try to use at least the last released version (1.7.0), or even better (as Werner suggested) the t6002 branch, which contains many improvements.

I was indeed using version 1.5.0 for testing, but I wish to clarify the purpose of Scute in my setup before proceeding.

I understand Scute emulates PGP keys as PKCS11 objects. I already have PIV objects stored (cert + privkey) that I wish to use alongside PGP. If I understand Scute correctly then Scute is not what I want in this setup.

Actually we developed PIV support to allow the use of PIV X.509 certificates and OpenPGP keys with Yubikeys. In fact, GnuPG is able to switch between the Yubikey PIV and OpenPGP applications on-the-fly while keeping their PIN verification states.

That sounds quite cool.

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work? I probably need Scute to work in an early OS boot stage, but that's another problem to solve for me ...

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

Yes. Scute relies on those to interact with the token.

I probably need Scute to work in an early OS boot stage, but that's another problem to solve for me ...

Are you aiming to use your token to authenticate yourself when logging onto your system? If so, you might want to have a look at the work being done in T5862.

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

Yes. Scute relies on those to interact with the token.

Then it might be problematic during OS boot... or maybe not. Not sure, haven't experimented yet.

I probably need Scute to work in an early OS boot stage, but that's another problem to solve for me ...

Are you aiming to use your token to authenticate yourself when logging onto your system? If so, you might want to have a look at the work being done in T5862.

No I'm not interested in login using GPG keys yet. I'm only using GPG keys for git commit signing and email. I use PKCS11/PIV keys for other tasks, like decrypting files, partitions, signing, and login on servers.