Back when I was still using GnuPG to store my keys there was this feature where you could make it remember the passphrase for a given amount of time since its last usage. But after a while of inactivity, the backend would forget the cached passphrase and the user would have to re-enter the key password in order to be able to use PGP again.
I was hoping something like this could be added to Nitrokey 3. Currently the device is unlocked on its first use, but then it stays unlocked for the duration. As a potential security enhancement, the key could be programmed to lock itself after a while of inactivity. Perhaps this could be configured via the admin interface like pynitrokey (or was it nitropy?). Add an option to enable/disable it and an option where timeout is specified e.g. in seconds. This shall apply to the smartcard (OpenPGP) key storage, but may potentially apply to other parts that are unlocked only once.
AFAIK the token can’t really count down, it receives requests, processes as fast as possible, responds and is inactive until the next request comes in. I imagine there is a lot that can go wrong, if it would continue processing a tick counter and another request comes in. I’d be happy to be corrected on this.
The feature would have to be via the controlling device software (e.g. nitropy, nitrokey-app2), which is OK but exposes to other manipulation risks - which arguably have to be pretty targeted.
Some you can already do, like activate caching of the token PIN via the nitropy python software which will then remain unlocked until you pull and replug the token. A usage habit change.
Another work-around on Linux is available when you use a software like usbguard to enable/disable usb-devices. While usbguard does not have a time-out feature yet, you can surely use a custom user-service to disable a token after a timeout (e.g. 120 seconds). What I do is have a short bash alias for deactivating a specific token, so i type something like a short “off” in the terminal and that deactivates the token. I use it, for example, to stop web-browsers enumerating the token when I don’t want to log-in to, say, google but still visit their search engine. This method theoretically caries the same inherent risks to misuse than the software controlling the token (e.g. nitrokey-app2), but otherwise works flawless already.
