Page MenuHome GnuPG

Gpg4win - Yubikey failure after generating an OTP
Open, NormalPublic

Description

I use a Yubikey as a smartcard for SSH authentication. Worked fine in GPG4WIN 2.x on a number of PCs. After upgrading to 3 on a new PC there's an interesting issue:

  • Boot PC with Yubikey connected.
  • Start GPG-agent.
  • SSH authentication works fine.

However, after using the Yubikey for generation of a OTP, things go wrong. According to Windows 10, the USB device is inserted. According to gpg --card-status there is 'No such device'. Sometimes removing and inserting the key for a couple of times fixes this issue. In most cases I need to reboot the OS. Any clues about what's going on?

Details

Version
GPG4WIN 3

Event Timeline

Mmhmhm. No.

Can you give me the exact steps what you are doing?
"Generation of an OTP" is strange to me. I have an FST-1 hardware token that runs the same software as a yubikey (GNUK) but I'm not so well versed in all the windows use cases. But I am interested to fix them.

aheinecke renamed this task from (GPG4WIN) to Gpg4win - Yubikey failure after generating an OTP.Oct 24 2018, 7:04 PM

Can you give me the exact steps what you are doing?
"Generation of an OTP" is strange to me. I have an FST-1 hardware token that runs the same software as a yubikey (GNUK) but I'm not so well versed in all the windows use cases. But I am interested to fix them.

  • Boot Windows 10 PC with Yubikey connected.
  • Start GPG-agent.
  • SSH authentication: works fine. As many times as I want (after initial PIN entry).
  • Generate OTP by touching / tapping the 'button' on the Yubikey.
  • SSH authentication: fails. gpg --card-status return "No such device". Windows tells me that "Yubikey NEO OTP+CCID" is connected. Also works fine to e.g. generate additional OTPs.

Sorry, there is no good way, but only workaround in this case, because it is complicated and it is basically wrong thing to do it by composite device (in my opinion). I'll describe detail in this comment.
I'm not Windows user, so, I don't have an idea how to recover from such a situation.

On GNU/Linux, gpgconf --reload scdaemon stops scdaemon and it may recover from this situation, with no OS reboot.

Well, here is the story.

Yubikey device supports multiple protocols by offering multiple interfaces in a single device. It is called "composite" device.
By configuring the device it can support OTP (one-time-password), U2F (authentication by public-key crypto), and CCID (smartcard).
It sounds great, but in fact, since it shares a control pipe (of number 0) among interfaces, interfaces cannot be 100% independent.

  • GnuPG scdaemon only cares about CCID protocol
  • I think that OTP (and U2F) is handled by system driver, as a device like keyboard (it's HID interface).

More specifically, there are two fundamental problems when a device offers multiple interfaces in this way:

  • some protocol, including CCID protocol, defines it's own use of control pipe, which relates to packets sent to an interface specific endpoints.
    • Shared control pipe among interfaces can interfere and interference may result undefined behavior.
  • an interface can be handled by a driver, and another interface can be handled by another driver. One can be system one, another can be user-space one. Permission to allow access to the device is difficult thing.
    • this can be only solved serving by a single driver for multiple interfaces (in my opinion)

So, by its (wrong) design, users have to use the device only in a way something like interchangeably (sorry, my English is not good, far from perfect).
I mean, you should switch between OTP use and CCID use alternatively, and you should be aware of which interface you are using. Don't mix your usage between one and another.

gniibe triaged this task as Normal priority.
gniibe added a project: Documentation.

I think that all that we can do is to improve documentation.