Page MenuHome GnuPG
Create Task
Maniphest T6218

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

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

mkjmkj created this task.Sep 25 2022, 6:26 PM
• 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).

mkjmkj added a comment.Sep 26 2022, 10:08 AM

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

gouttegd added a subscriber: gouttegd.Sep 26 2022, 4:26 PM

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

• werner added a comment.Sep 26 2022, 7:59 PM

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

mkjmkj added a comment.Sep 27 2022, 9:20 AM

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

gouttegd added a comment.Sep 27 2022, 11:42 PM

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.

mkjmkj added a comment.Sep 28 2022, 10:04 AM

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.

• werner added a comment.Sep 28 2022, 10:22 AM

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.

mkjmkj added a comment.Sep 28 2022, 10:27 AM

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

gouttegd added a comment.Sep 30 2022, 4:58 PM

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.

mkjmkj added a comment.Oct 1 2022, 2:49 PM
In T6218#163787, @gouttegd wrote:

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.

• canti59 added a commit: rG8046fcac63db: po: Update Czech translation..Oct 14 2022, 2:10 AM
• gniibe removed a commit: rG8046fcac63db: po: Update Czech translation..Oct 14 2022, 2:50 AM
AlynxZhou added a subscriber: AlynxZhou.EditedDec 9 2022, 9:34 AM

I also reproduced this bug. I am using a PIV configured YubiKey 5C NFC for GNOME Smartcard login, which uses pam_pkcs11, and pam_pkcs11 uses opensc to read it via pcscd.

I found that if I have browsers or thunderbird opening, GnuPG will report error on reading card, as PIV is also supported by browser, they will also try to read card info via pcscd (However, they do not really use card in my system).

I checked Arch Wiki that it tells me I can use pcsc-shared to let GnuPG read card via pcscd in shared mode, so I have the following content in ~/.gnupg/scdaemon.conf:

card-timeout 5
disable-ccid
pcsc-shared

debug-level expert
verbose

However, I still needs to close browsers and thunderbird to use gpg --card-status, otherwise it reports error, I am wondering is this by-design or just a bug, because no document says that it cannot work with other program running with pcsc-shared.

When it reports error, I always got following debug log with journalctl -b 0 | rg scdaemon (I didn't set any info on this card yet because of this problem):

Dec 08 18:37:33 camelot gpg-agent[85885]: scdaemon[85885]: DBG: chan_6 -> S DISP-NAME
Dec 08 18:37:33 camelot gpg-agent[85885]: scdaemon[85885]: DBG: chan_6 -> S DISP-LANG
Dec 08 18:37:33 camelot gpg-agent[85885]: scdaemon[85885]: DBG: chan_6 -> S DISP-SEX 9
Dec 08 18:37:33 camelot gpg-agent[85885]: scdaemon[85885]: DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0
Dec 08 18:37:33 camelot gpg-agent[85885]: scdaemon[85885]: DBG:   PCSC_data: 00 CA 00 C4 00
Dec 08 18:37:33 camelot gpg-agent[85885]: scdaemon[85885]: DBG:  response: sw=6D00  datalen=0
Dec 08 18:37:33 camelot gpg-agent[85885]: scdaemon[85885]: DBG: chan_6 -> ERR 100663404 Card error <SCD>
Dec 08 18:37:33 camelot gpg-agent[85885]: scdaemon[85885]: DBG: chan_6 <- RESTART
Dec 08 18:37:33 camelot gpg-agent[85885]: scdaemon[85885]: DBG: chan_6 -> OK

Also, disable pcscd and use scute is not an optional for me, because I really need PIV for GNOME smartcard login, I already tried to replace opensc with scute in pam_pkcs11's config, but I cannot find document on how to configure scute, so pam_pkcs11 just failed to use it. I also suspect that it is unable to use scute to do smartcard login, because when logging in the pam is running as GDM user or root, and after login I use GnuPG with my own account, and now I have more then one scdaemon that using the same card, except they really support shared mode, I assume they will conflict?

Please tell me if you need more info, I'd like to help solve this. BTW I am using GnuPG 2.2.40 from Arch Linux's official repo.

• werner added a project: gnupg24.Dec 13 2022, 11:21 AM
• werner removed a project: gnupg (gpg23).Jan 19 2023, 4:44 PM