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

Description

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 https://lists.gt.net/gnupg/users/81257 for problem description.

Details

Version
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
glr added a subscriber: glr.Aug 31 2020, 12:56 PM
glr added a comment.Aug 31 2020, 1:00 PM

@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".

Is this plan going to be implemented any time soon? Implementation of this plan will definitely contribute to making smartcard usage safer.

werner added a comment.EditedAug 31 2020, 4:24 PM

There is not a lot of demand for this, thus we have not continued to think about it.

@gniibe: We could implement this on the card by extending our ugly hacks on the login-data DO, which are currently:

Everything up to a LF is considered a mailbox or account name.  If
the first LF is followed by DC4 (0x14) control sequence are
expected up to the next LF.  Control sequences are separated by FS
(0x18) and consist of key=value pairs.  There are two keys defined:

 F=<flags>

 Where FLAGS is a plain hexadecimal number representing flag values.
 The lsb is here the rightmost bit.  Defined flags bits are:

   Bit 0 = CHV1 and CHV2 are not synchronized
   Bit 1 = CHV2 has been set to the default PIN of "123456"
           (this implies that bit 0 is also set).

 P=<pinpad-request>

 Where PINPAD_REQUEST is in the format of: <n> or <n>,<m>.
 N for user PIN, M for admin PIN.  If M is missing it means M=N.
 0 means to force not to use pinpad.

A new 'C' flag maybe?

glr added a comment.EditedAug 31 2020, 5:10 PM

There is not a lot of demand for this, thus we have not continued to think about it.

@gniibe: We could implement this on the card by extending our ugly hacks on the login-data DO, which are currently:

Everything up to a LF is considered a mailbox or account name.  If
the first LF is followed by DC4 (0x14) control sequence are
expected up to the next LF.  Control sequences are separated by FS
(0x18) and consist of key=value pairs.  There are two keys defined:
 
 F=<flags>
 
 Where FLAGS is a plain hexadecimal number representing flag values.
 The lsb is here the rightmost bit.  Defined flags bits are:
 
   Bit 0 = CHV1 and CHV2 are not synchronized
   Bit 1 = CHV2 has been set to the default PIN of "123456"
           (this implies that bit 0 is also set).
 
 P=<pinpad-request>
 
 Where PINPAD_REQUEST is in the format of: <n> or <n>,<m>.
 N for user PIN, M for admin PIN.  If M is missing it means M=N.
 0 means to force not to use pinpad.

A new 'C' flag maybe?

Currently, I just disconnect my USB smartcard reader from my PC once I'm done using it. But this wears down the physical contacts for people that need to use their smartcard frequently throughout the day.

Having the ability to make sure smartcard authentication information is never cached (via a simple config option) seems like a reasonable solution to the wear issue.

The scdaemon option card-timeout (which, to my knowledge, is unimplemented) deals with powering down the card; however, I believe having a simple config option for scdaemon like never-cache-pin would be a cleaner solution because we wouldn't need to deal with smartcard reader power which can be risky (as already noted in the documentation).

There are quite a few subscribers to this issue, so there seems to be genuine interest in this matter.

Thanks for your quick reply.

turkja added a subscriber: turkja.Sep 23 2020, 6:49 AM

I also don't want to leave my card in the reader authenticated for a full day, it just doesn't sound like a good practice to me. I also very often just forget about the card, so it just sits there, keys open for use.

I resolved this with very ugly hack:

  1. Run scdaemon with debug logging (debug-level basic; log-file <path-to-log-file>)
  2. Script monitoring the scdaemon log, started by cron every 5 minutes. This script will just take the last timestamp for the log and compare it to current time
  3. Reload scdaemon if inactive for more than 30 minutes

Next time I try to use the card, it will prompt me for PIN, so in effect this is pretty much what man scdaemon says for card-timeout.