See if cached PIN signing is possible without requiring a PS/SC transaction

[ericchiang]

Based off my testing, releasing the transaction wipes the PIN.

[FiloSottile]

Alternatively, the same high-level use case would be served by having a "weak" lock on the token, by somehow letting other instances take over. This could be a PCSC option, a takeover method, a notification of other pending transactions, or even just a way to find out what process has an open transaction, letting the applications sort it out with signals.

[ericchiang]

#51 now marks the smartcard context as exclusive so other applications that try to access the card will fail instead of hang.

Did a little looking into SCardGetStatusChange to see if we can detect when another application attempts to access the card. That might be a way to implement a "weak" lock.

https://ludovicrousseau.blogspot.com/2018/02/how-to-use-scardgetstatuschange.html

[tv42]

Would it be possible to release the USB device, as a whole?

I have a Chromebook with multiple LXD containers ("crostini") where I would like to be able to SSH out from different containers using the same yubikey (and use the yubikey for encryption, too, outside of ssh). They're system containers, so each container runs its own systemd, and in this case, pcscd and yubikey-agent. As long as I make one stop using the USB device, another one can start using it; automatically releasing the USB device on idle would make that mostly happen without user action.

[tv42]

Others working on pretty much the same problem (more in the context of letting go of the USB device than between clients of one pcscd): GoogleChromeLabs/chromeos_smart_card_connector#122

[ericchiang]

Releasing the smart card context can already be done by calling YubiKey.Close(), right? It's probably better for applications to define what "idle" is instead of this package.

https://pkg.go.dev/github.com/go-piv/piv-go/piv?tab=doc#YubiKey.Close

On a less related note, I'd be happy to add an option to this library to use a SCARD_SHARE_SHARED connection instead of SCARD_SHARE_EXCLUSIVE at the cost of cached PINs. But I think that'll only help multiple applications connecting to the same pcscd.

[markomitranic]

Any update on this front guys? :)

[ericchiang]

If anyone wants to add a client option to opt into SCARD_SHARE_SHARED I'm happy to review.

https://github.com/go-piv/piv-go/blob/v1.8.0/piv/piv.go#L135

[FStelzer]

as far as i understand even with shared access a new transaction will be needed and a new transaction will need a new pin to unlock. i'm not 100% sure about the pin part but every tool i have seen that gracefully handles concurrent card access is caching the card pin itself (tools like pivy-agent, pagentcac and i think p11-kit/opensc as well). or alternatively people will always have their unlocked keychain enter the pin for them on every operation.

i played around a bit with this in yubikey-agent which i'd like to use as a replacement for pivy-agent but since the pin passes through several variables/functions into piv-go it doesen't really help if i secure it correctly within yubikey-agent since it is scattered in memory anyway.
I think piv-go should allow for a pin caching option and also use something like https://github.com/awnumar/memguard to securely store the pin in memory (even when not caching it!)
I'd be happy to help with this if you are open to it.