A comparison of cryptographic keycards

Posted Oct 17, 2017 20:40 UTC (Tue) by nix (subscriber, #2304)
Parent article: A comparison of cryptographic keycards

So far, I have created a signing subkey and moved that and my authentication key to the YubiKey NEO, because it's a device I physically trust to keep itself together in my pockets and I was already using it. It has served me well so far, especially with its extra features like U2F and HOTP support, which I use frequently.

For a long time, this was impossible: the Neo is really three keys in one, and disconnects and reconnects from the USB bus as appropriate, morphing from OTP to U2F to CCID on demand. libccid / pcsc-lite couldn't cope with this and failed after the first disconnection, so in effect the first time you did a U2F or OTP/HMAC-SHA1 authentication after something launched pcscd and did a CCID operation, pcscd would fail and you'd lose access to the CCID element

Has this been fixed now? (or are you just using a Mac? My understanding is that MacOS X's smartcard daemon doesn't have this problem.)

A comparison of cryptographic keycards

Posted Oct 17, 2017 21:50 UTC (Tue) by anarcat (subscriber, #66354) [Link] (5 responses)

For a long time, this was impossible: the Neo is really three keys in one, and disconnects and reconnects from the USB bus as appropriate, morphing from OTP to U2F to CCID on demand.

Really? I don't see this behavior here.

libccid / pcsc-lite couldn't cope with this and failed after the first disconnection, so in effect the first time you did a U2F or OTP/HMAC-SHA1 authentication after something launched pcscd and did a CCID operation, pcscd would fail and you'd lose access to the CCID element Has this been fixed now? (or are you just using a Mac? My understanding is that MacOS X's smartcard daemon doesn't have this problem.)

I do *not* use a mac, of course. :p This is what I see when the NEO is connected:

oct 17 17:45:08 curie kernel: input: Yubico Yubikey NEO OTP+U2F+CCID as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:1050:0116.0015/input/input24 
oct 17 17:45:08 curie kernel: hid-generic 0003:1050:0116.0015: input,hidraw2: USB HID v1.10 Keyboard [Yubico Yubikey NEO OTP+U2F+CCID] on usb-0000:00:14.0-2/input0 
oct 17 17:45:08 curie kernel: hid-generic 0003:1050:0116.0016: hiddev0,hidraw3: USB HID v1.10 Device [Yubico Yubikey NEO OTP+U2F+CCID] on usb-0000:00:14.0-2/input1

It accurately shows up as two devices: an input device (a fake keyboard) and a generic input device, which is presumably used by GPG. I *did* have trouble with pcsscd with the upgrade to Debian stretch, as I documented here. With GnuPG and scdaemon 2.1.18, things are very smooth, although I need the U2F Firefox plugin for that part to work.

A comparison of cryptographic keycards

Posted Oct 17, 2017 22:22 UTC (Tue) by karkhaz (subscriber, #99844) [Link] (3 responses)

A somewhat related question, which I haven't been able to find the answer to elsewhere. Does scdaemon and/or gpg-agent support the use of multiple of these devices at the same time---possibly with a different encryption key on each of them, or possibly one containing GPG keys and the other used for Unix authentication with HOTP?

A use case I'm interested in is leaving a NitroKey plugged into an internal USB port of my workstation permanently, holding GPG keys, and carrying a Yubikey on my person to authenticate via PAM. There are various other advantages here...for example, the OpenSSH daemon now supports requiring two forms of authentication (including two separate SSH keys), so having a "workstation smartcard" and "personal smartcard" means that having physical access to my workstation is not enough to SSH into my other machines, and neither is stealing my personal smartcard---you need both.

Has anybody tried something like this? Asking because I'm a student and can't justify buying several of these if it can't work. I'm also not sure exactly which software is responsible for this, i.e. whether it's scdaemon that needs to be able to talk to two cards, or gpg-agent that needs to know to try decrypting with each smartcard in sequence until one works, or what.

A comparison of cryptographic keycards

Posted Oct 17, 2017 22:34 UTC (Tue) by anarcat (subscriber, #66354) [Link] (1 responses)

I think this could work: i played around with multiple keycards while writing this article, and would sometimes need my "real" key to do things. GnuPG would dutifully ask me for the key with a given serial number when it needed it, so presumably it has a way of addressing each card individually.

A comparison of cryptographic keycards

Posted Oct 18, 2017 6:01 UTC (Wed) by dd9jn (✭ supporter ✭, #4459) [Link]

Right, this works with 2.2. I really like that because my release process requires 2 smartcards, one to sign commits and one to sign tarballs, tags, and version info. Before that change I had to swap cards several times. One drawback ist that you need to look closer at the PIN prompt to enter the right one.

A comparison of cryptographic keycards

Posted Oct 18, 2017 3:02 UTC (Wed) by chder (subscriber, #96621) [Link]

I know on Fedora 26 at least, I can have multiple yubikeys neo's detected in the output of ssh-add -L with gpg-agent.

A comparison of cryptographic keycards

Posted Oct 17, 2017 23:38 UTC (Tue) by nix (subscriber, #2304) [Link]

> For a long time, this was impossible: the Neo is really three keys in one, and disconnects and reconnects from the USB bus as appropriate, morphing from OTP to U2F to CCID on demand.
Really? I don't see this behavior here.

Hmmm. I saw this in older kernels, but not any more. Since this is clearly kernel-specific, it can't be anything to do with the behaviour of the key: so I must be wrong.

I *did* have trouble with pcsscd with the upgrade to Debian stretch, as I documented here

Those bugs are bang in the time window when I tried this last (and gave up), so I guess the problem was indeed solved because you had more determination than me.

Indeed, removing disable-ccid now makes scdaemon work fine for me, even when generating OTPs and doing HMAC challenges at the same time. I can't use PIV keys because scdaemon is still an unspeakable pile that sprays incomprehensible error messages rather than working, but I frankly don't care much (and forgot all my PINs long ago, and lost the piece of paper I wrote them down on). At least I can use GPG smartcard keys now, which means I can migrate to SSH keys on my smartcard via gpg-agent, as long as I can convince it to work across multiple chains of sshes (a very frequent use case for me, but since the agent connection is part of SSH, not GnuPG, I already know that part works).