yubikey not locked after removal (CAPI)

[DonEstefan]

When removing an unlocked yubikey from the USB-Slot, I'd expect the key to lock itself and ask for another PIN verification before next use. With putty-cac this does not happen. Yubikey is still unlocked after re-insertion. I have to restart putty-cac in order to get a new PIN unlock prompt.

• Putty-cac 0.81 and "Force PIN Caching" is disabled
• Windows 11
• Yubikey Firmware 5.7.1
• YubiKeySmartCardMinidriver 4.6.3.252

Is this a bug in putty-cac? Maybe some strange CAPI session handling?

Steps to reproduce;

1. configure yubikey for CAPI authentication
2. add yubikey to pageant via CAPI
3. start ssh session and authenticate via yubikey. Note that yubikey asks for PIN unlock on first use.
4. close ssh session (but not pageant)
5. remove yubikey from USB
6. re-instert yubikey
7. start the same ssh session from step 3. Note that yubikey authentication works fine without PIN verification prompt being shown.

[NoMoreFood]

Can you provide a screenshot of the PIN prompt you receive when you are initially prompted? I just want to make sure it absolutely isn't going through PuTTY CACs PIN caching code. I believe the behavior you are seeing is an artifact of the caching that can occur at the minidriver / OS level that's usually per-process based. It's possible this is triggered by an unintentional leftover CAPI handle on the PuTTY CAC side, but we've been pretty good about handle tracking.

[DonEstefan]

This is the PIN prompt I see:

I found this note on the yubikey website:
"Windows will cache a valid PIN per process per logon ID (PinCacheNormal); this means a process can re-use a PIN without prompting the user, but once the process ends, or if a new process is started in parallel, the user must supply the PIN again. Due to these behaviors on Windows, the PIN policy defined on the YubiKey is often not enforced as expected." (Source)

This could explain the behavior. But it does not explicitly mention how physical key removal is handled.

I noticed that my TCOS 3 card has different CAPI behavior and enforces a PIN prompt after removal. So it does not seem to be a general windows issue, either. So, this would leave the minidriver to blame...

[NoMoreFood]

Yeah, so that's definitely the Windows-controlled PIN dialog box (i.e. out of PuTTY CAC's control). I suspect what you found explains the behavior you are seeing. I cannot find a way to override this behavior generically. I agree it really ought to invalidate the cache when the key is removed. It seems like under Windows 10, that would be the responsibility of the Yubikey minidriver.

[DonEstefan]

I contacted yubico support and they cited a Microsoft article:

Transaction Management

• A card minidriver should assume that transactions are handled by the caller, if it uses SCRM to access the card.
• [...]
• Handling the authentication state of the card is also the responsibility of the caller, not the card minidriver.

So, the minidriver is not allowed to open or close any handles to the card. The session is invalidated when the device power cycles, the handles to the card are closed by the smart card service and BaseCSP, but the BaseCSP will keep the pin cached at its discretion.

They suggest there might be a timeout limit in the agent, which could be responsible for the behavior. I only suspect they mean CAPI session timeout - not ssh session timeout. But I don't see how a general timeout setting could cause different behavior for yubikey and TCOS cards.

I'm running out of ideas....

[NoMoreFood]

They suggest there might be a timeout limit in the agent

If by "agent" they mean Pageant, this is certainly not the case. I'll see if I can reproduce this behavior with a smaller test case. In Pageant, we really don't do anything directly with the card; we interact with the certificate APIs which, in turn, communicate with the CSP and minidriver.