Prevent Smartcard from caching PIN when cache-ttl is set accordingly
Open, WishlistPublic


One can configure gpg-agent to stop caching of passphrases after some time (max-chache-ttl etc.).

As this does not apply for smartcards yet, it would be nice to add this feature. The smartcard is caching the PIN by itself until it is powered down. Therefore a possible solution would be to power down the card after the time specified in max-cache-ttl to make sure, that the PIN is not cached anymore. At least this is the behaviour a user would probably expect when setting this configuration.

See for problem description.


gpg (GnuPG) 2.1.23
werner triaged this task as Wishlist priority.Aug 23 2017, 10:52 AM
werner added a subscriber: werner.

Smartcards and on-disk keys are very different things and handled by different processes.

You may use "card-timeout" in scdaemon.conf to achieve. However we would need to fully implement that option. Thus I change this to a feature request. Please be so kind and explain your use case for this request.

jans added a subscriber: jans.Aug 23 2017, 8:33 PM

Using a smartcard it should be possible to set a cache-ttl value so that not only on-disk keys but also the PIN used for unlocking the key on the smartcard is not cached longer than the given period in cache-ttl. Until now you have to plug out and in the card by yourself to get this working. Alternatively you theoretically could set a config in scdaemon to power off the card after some time ("card-timeout). It could be a solution to set this config automatically if cache-ttl option is used.

Please note that the card-timeout value in scdaemon.conf does not seem to work as once intended ("the current version of Scdaemon the card is powered down immediately at the next timer tick for any value of n other than 0. ") so that this may is not the best option other than stated above.

I am not sure if this is really a good explanation, sorry. I hope it helps anyway.

gniibe added a subscriber: gniibe.EditedSep 5 2017, 3:55 AM

Unfortunately, not all OpenPGPcard implementations support command to unauthorize use of keys.

Gnuk supports that with VERIFY command with NULL. I proposed this feature for newer OpenPGPcard (>= 3.x).
So, for some OpenPGPcard implementations, scdaemon can support this feature.

To support this feature for other OpenPGP implementations, all that we can do is reset the card (power-off + power-on), perhaps.

The problem of power-off/power-on is that it is somehow risky operation for physical smartcard. For virtual card (like Gnuk or JavaCard implementation), it works always. For physical smartcard + card reader, it has a possibility to fail. That's difficult.

werner added a comment.Sep 5 2017, 8:48 AM

The idea with the smartcard is that you can limit the time of exposure
of the key. Leaving the card accessible to the host is thus not a good
idea. Malware can simply snoop the PIN from the last operation and
then, at its own discretion, use the keys of the card. This can only be
avoided by using a smartcard reader equipped with a pinpad and able to
filter commands so that it is not possible to bypass the pinpad (which
is easy for the host).

gniibe added a comment.Sep 5 2017, 8:55 AM

Yes. For the use case of GnuPG, it is better to support disabling (unauthorize) use of keys.
On the other hand, IIUC, the original OpenPGPcard implementation is designed/implemented under the influence of other smartcard usages.

In a typical usage of smartcard for PC, which is also used for login authentication, once it is authenticated, it keeps that state until a user remove it to lock the screen.

If we can focus on (major) use case of GnuPG, I think that gpg-agent compatible timeout of authentication state is better, and easier to understand for GnuPG user.

gniibe added a comment.Sep 5 2017, 8:58 AM

For the record, the authentication status reset by VERIFY command was introduced in OpenPGPcard specification V2.2.
I think V3 card supports that.
Gnuk 1.2 supports this reset feature.

So, this is VERIFY reset allows the host to implement the "force" flag we always had in the card for the first key. At least kind of, because malware can still suppress the VERIFY reset ;-). The integrated "force" flag requires the admin PIN, which is malware should have more problems to snoop.

aa added a subscriber: aa.Sep 5 2017, 2:41 PM
gniibe added a comment.Sep 8 2017, 2:17 AM

@werner , I understand your poiont.

So, the best approach would be:
(1) Define some DO (Data-Object) or attribute/flag per key to control timeout or "force" by the card itself.
(2) Modify scdaemon so that it always ask authentication state to the card before doing crypto operation.
(3) Modify gpg frontend so that it shows those attribute/flag and setup.

Then, it is the card itself to control timeout or "force".

georg added a subscriber: georg.Sep 7 2018, 4:15 PM
Alex77 added a subscriber: Alex77.Oct 15 2018, 9:54 PM

I hope I did not choose inappropriate action in commenting here that I also would highly appreciate a cache timeout for OpenPGP Cards to reduce the exposure time of already unlocked card's keys. Would be great to get such an option

mrloop added a subscriber: mrloop.Oct 22 2018, 9:49 PM
gfa added a subscriber: gfa.May 20 2019, 4:53 AM