UX: Length of PIV session

[olivervogel]

trafficstars

What were you trying to do

I am trying to find out if the behaviour of the PIN once policy is intentional or if it can be configured more in line with my ideas.

What happened

I have the following setup.

• Apple M1 Pro 2021 (macOS 14)
• Yubikey 5C (Firmware 5.7.1)
• age-plugin-yubikey 0.5.0

The age key has been successfully stored on the Yubikey in Slot 82 (RETIRED1) with PIN policy once and touch policy cached.

When I decrypt files, I notice that I expect a different behavior from the PIN policy once than actually occurs.

My expectation here is that I enter the PIN once and then don't have to enter the PIN again for the foreseeable future.

This is the case, but only for a very short time of perhaps 10 seconds. During this time, the LED on the Yubikey remains lit and I am not asked for the PIN again. When I keep decrypting in this short period of time the LED remains on and I do not have to enter the PIN again. When I stop decrypting the LED goes out after a few seconds and then I have to enter the PIN again.

I therefore asked myself how long a PIV session actually lasts.

As described in this issue comment and in the readme, the first PIN input with the once policy is cached in the Yubikey itself and only reset on the following events.

• Unplugging the YubiKey
• Using a different applet
• Generating a new age identity via age-plugin-yubikey --generate or the CLI interface.

I would therefore imply that the session runs indefinitely until one of the things described happen.

As I think I have not triggered any of the events described (all applets except PIV are deactivated), I am wondering whether there might be something wrong with my configuration. My unverified suspicion is, for example, a possible power-saving function of the Macbook, which could switch off the USB ports and therefore terminate the session. I have tried to configure the power management with pmset but with no success.

I also had the thought that this might have something to do with the “Touch Eject” configuration of the Yubikey. However, I'm not sure about this.

Do you have any ideas? Or are my expectation about the once policy simply different?

PS: Thank you for this great tool.

[dxmh]

I am experiencing the same behaviour. I enter the PIN and tap the YubiKey; the PIN seems to remain cached for only 5-seconds while the YubiKey LED is illuminated. The PIN is required again once the YubiKey LED goes out.

• ThinkPad T480 running NixOS 24.11
• YubiKey 5 Nano with firmware version 5.2.4
• age-plugin-yubikey version 0.5.0
  • PIN policy: Once (A PIN is required once per session, if set)
  • Touch policy: Always (A physical touch is required for every decryption)

[brianmcgee]

Myself and @pinpox spent some time digging into this today.

The setup is:

• Desktop running NixOS 25.05 (unstable)
• Yubikey 5C with firmware 5.4.3
• age-plugin-yubikey version 0.5.0

What we found is that pcscd is powering off the Yubikey:

May 09 11:56:52 saturn pcscd[143605]: 00000002 ../src/winscard_svc.c:630:ContextThread() END_TRANSACTION for client 15, rv=SCARD_S_SUCCESS
May 09 11:56:52 saturn pcscd[143605]: 00000028 ../src/winscard_svc.c:383:ContextThread() Received command: DISCONNECT from client 15
May 09 11:56:52 saturn pcscd[143605]: 00000005 ../src/readerfactory.c:871:RFReaderInfoById() RefReader() count was: 1
May 09 11:56:52 saturn pcscd[143605]: 00000002 ../src/winscard.c:883:SCardDisconnect() Active Contexts: 1
May 09 11:56:52 saturn pcscd[143605]: 00000002 ../src/winscard.c:884:SCardDisconnect() dwDisposition: 0
May 09 11:56:52 saturn pcscd[143605]: 00000002 ../src/winscard.c:1019:SCardDisconnect() powerState: POWER_STATE_GRACE_PERIOD
May 09 11:56:52 saturn pcscd[143605]: 00000002 ../src/ifdhandler.c:367:IFDHGetCapabilities() tag: 0xFB2, usb:1050/0407:libudev:2:/dev/bus/usb/001/025 (lun: 0)
May 09 11:56:52 saturn pcscd[143605]: 00000002 ../src/winscard.c:1032:SCardDisconnect() Stopping polling thread
May 09 11:56:52 saturn pcscd[143605]: 00000002 ../src/ifdhandler.c:332:IFDHStopPolling() usb:1050/0407:libudev:2:/dev/bus/usb/001/025 (lun: 0)
May 09 11:56:52 saturn pcscd[143605]: 00000002 ../src/winscard.c:1045:SCardDisconnect() UnrefReader() count was: 2
May 09 11:56:52 saturn pcscd[143605]: 00000002 ../src/winscard_svc.c:599:ContextThread() DISCONNECT for client 15, rv=SCARD_S_SUCCESS
May 09 11:56:52 saturn pcscd[143605]: 00365347 ../src/eventhandler.c:492:EHStatusHandlerThread() powerState: POWER_STATE_POWERED
May 09 11:56:53 saturn pcscd[143605]: 00400447 ../src/ifdhandler.c:1208:IFDHPowerICC() action: PowerDown, usb:1050/0407:libudev:2:/dev/bus/usb/001/025 (lun: 0)
May 09 11:56:53 saturn pcscd[143605]: 00000774 ../src/eventhandler.c:480:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED
May 09 11:56:53 saturn pcscd[143605]: 00495847 ../src/winscard_svc.c:376:ContextThread() Client die: 15
May 09 11:56:53 saturn pcscd[143605]: 00000027 ../src/winscard.c:224:SCardReleaseContext() Releasing Context: 0x45E86E10
May 09 11:56:53 saturn pcscd[143605]: 00000006 ../src/winscard_svc.c:1112:MSGCleanupClient() Thread is stopping: dwClientID=15, threadContext @0x451e610
May 09 11:56:53 saturn pcscd[143605]: 00000004 ../src/winscard_svc.c:1120:MSGCleanupClient() Freeing SCONTEXT @0x451e610

Looking through its source, by default, a card is powered off after 5 seconds:

https://github.com/LudovicRousseau/PCSC/blob/3e734d76270ed661dd7234671479cf464fa0bdce/src/pcscd.h.in#L61-L77

This resets the PIN caching. Interestingly, though, touch caching isn't affected; it will time out after 15 seconds as described in the README (this is hardcoded into the Yubikey, I believe).

I created a patch that sets #define DISABLE_ON_DEMAND_POWER_ON and stops pcscd from powering off the card.

Testing revealed the PIN caching was now persisting indefinitely, with touch needing to be applied periodically due to the 15 second timeout.

I don't know if this is the right approach. I would like to understand the implications of the card not being automatically powered off. Feels like a quick way to burn out a Yubikey potentially.