Re: cache-timeout not working with smartcard
Werner Koch wrote:
On Wed, 16 Dec 2009 16:27:29 +0100, Marco Steinacher wrote:
option (scdaemon) seem to work. I have set all timeouts to very low
values but the PIN is still cached forever (by the card?), as long as
There is no cache for a PIN. A card is usually unlocked after the PIN
as been given until the card is powered down. Thus is seems that
there is a cache.
OK, so my question is about powering down the card and not about caching.
You can power down the card using the option
@item --card-timeout @var{n}
As I wrote in my posting I have tried to use this option but it does not
work. I added 'card-timeout 15' to my scdaemon.conf and nothing happens
15 seconds after accessing the card. The card remains unlocked as long
as scdaemon is running. Nothing is written to the logfile after 15
seconds, even when the 'guru' debugging level is set. What could prevent
this from working properly? BTW, I'm using the following versions:
scdaemon (GnuPG) 2.0.13
libgcrypt 1.4.1
libksba 1.0.3
Another thing, which is probably connected to the cache problem, is that
I have to kill the scdaemon (with SIGKILL) after disconnecting and
Better use gpgconf --reload scdaemon.
OK, thanks for that hint. This leads me to some (maybe naïve?) thoughts:
1. Couldn't gpg-agent reload scdaemon in the same way when
default/max-cache-ttl is exceeded? This would provide the same
functionality for unlocked smartcards as for cached passphrases, which
would make sense since both are affected by the same security risk
(agent hijacking).
2. Couldn't scdaemon be configured to also access the signature key on
the card every time, even if only the authentication or encryption key
is needed? Then, entering the PIN would be required also every time for
e.g. ssh authentication (if the force-sig flag is set on the card). This
would basically provide the same functionality as 'card-timeout 1'
(provided that it works) without the trouble of powering down and up the
card.
Marco
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: cache-timeout not working with smartcard
Olav Seyfarth wrote: Hi Marco, I'm using gnupg with an OpenPGP smartcard since a few days now and basically it works very well. However, one thing bothers me a bit: Neither the cache-timeout options (gpg-agent) nor the card-timeout option (scdaemon) seem to work. I have set all timeouts to very low values but the PIN is still cached forever (by the card?), as long as the card is not removed and scdaemon is running. Sending SIGHUP to scdaemon does not work either although the manpage is suggesting this. Only killing scdaemon with SIGKILL helps. The LED on the card reader (SCR-335) remains always on after using it for the first time. For keys that are not on the smartcard the cache-timeout works correctly. in --card-status, what's the setting of Signature PIN : ? You may alter it to forced using --card-edit admin forcesig Thanks, Olav, for this hint. Unfortunately it does not help in my case. I forgot to mention that I'm referring mainly to ssh-authentication through gpg-agent. In that case (and also for decryption) the 'Signature PIN' setting doesn't have an effect (it works perfectly for signatures, though). My main concern is that the probability that the hijacking of the gpg-agent/ssh-agent is successful is much higher when the PIN is cached for a long time than it would be with short cache-timeout settings. Marco ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: cache-timeout not working with smartcard
Werner Koch wrote: On Thu, 17 Dec 2009 11:27:53 +0100, marco+gn...@websource.ch wrote: As I wrote in my posting I have tried to use this option but it does not work. I added 'card-timeout 15' to my scdaemon.conf and nothing happens 15 seconds after accessing the card. The card remains unlocked as long Actually it should release the card immediatley after use. It is only a boolean switch for now. I forgot to mention that this feature is only available with pcsc and not with the internal driver. That's it. I was using the internal driver. Thanks for pointing this out! 1. Couldn't gpg-agent reload scdaemon in the same way when default/max-cache-ttl is exceeded? This would provide the same functionality for unlocked smartcards as for cached passphrases, which would make sense since both are affected by the same security risk (agent hijacking). If you are talking about malware on your box, nothing will help you. You don't have any control anymore on your box. The only advantage you have is that the bot needs to wait until you enter the PIN the next time and then it can replay the PIN as needed. Oh, you are using a pinpad reader - well in this case the malware just et you sign something it is interested in and not what you assume. I agree that this would not completely prevent malware from hijacking the agent for ssh authentication on a remote host. But at least it would make it more difficult, and, more importantly, the chances that I would notice the break-in are much bigger. In contrast, when the card is unlocked all the time it is sufficient for a user with superuser privileges to set some environment variables to be able to connect to a remote host using my authentication key at any time and I have no chance to notice it. BTW: Doesn't your argument also apply to cached passphrases? Why would you use max-cache-ttl when you assume that you are lost anyway once you lose control over your box? In any case, what I was suggesting can easily be done by a script that regularly checks the gpg-agent log and resets the card if the last access is older than default/max-cache-ttl. So it doesn't need to be built into gpg-agent/scdaemon. Marco ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
