12

I've found today, that enigmail is decrypting a message without asking me for the smart card's PIN. It is asking only once, and then not ask at all.

this is my gpg-agent.conf:

default-cache-ttl 0
max-cache-ttl 0
no-allow-external-cache
ignore-cache-for-signing

scdaemon.conf:

card-timeout 0
deny-admin

gpg.conf is empty

gpg (GnuPG) 2.1.16

libgcrypt 1.7.3-beta

Gnome keyring is stopped. What am I missing here?

Improve this question
1
  • Does setting the timeout to 1 second not prompt you for every attempt?
    – dragon788
    Nov 8, 2017 at 17:14

3 Answers 3

Reset to default
16

I've been looking into this myself. I want to be prompted to enter my PIN every time I request my smart card (Yubikey in my case) to do a sign/encrypt/auth operation. It is possible to enable this behaviour for signing by enabling forcesig through gpg2 --card-edit (see GnuPG documentation):

forcesig   toggle the signature force PIN flag

but not for encryption and authentication operations.

This post on the GnuPG mailing list by Werner Koch himself seems to imply that the smart card itself is caching the PIN.

I will look into this further (perhaps send an email to the GnuPG mailing list) and update this answer if I find any more information.

Improve this answer
2
  • I suggest enabling touch verification (a yubikey setting) on all operations. That seems to provide better security, since it cannot be remembered or phished.
    – Scott
    Feb 7, 2018 at 19:50
  • You can just stop and restart your gpg-agent every x # of mins to force pin re-entry.
    – user196817
    Jan 14, 2019 at 22:53
0

An easy workaround I found is to run a bash script in the background that reloads the gpg-agent every X second. Specifically, append this to ~/.bashrc:

while true; do gpgconf --kill gpg-agent; sleep X; done &

where X denotes how long, in seconds, you want the pin to be stored for. Note that this script will also kill any other gpg related processes, so it's only a quick fix if you use gpg mostly for pinentry processes.

This will run in the background, but it can be accessed by using the jobscommand, and similarly stopped using the kill command.

Improve this answer
0

Based on my research card-timeout is a dummy parameter and was never meant to force a time limit on caching the smartcard pin.

Some interesting quotes from this bug report.

Let me explain the situation.

In scdaemon manual, it explained as scdaemon will be powering down the smartcard by the value specified. But, it never has been implemented as described.

In 2.0, it was a variable to control scdaemon to allow DISCONNECT command. In 2.1, scdaemon has been improved to allow DISCONNECT command always.

Thus, it is true, this variable has no effect in 2.1.

and

It has been a dummy option for years (since GnuPG 2.1). For the record, I write more detail here.

It never worked as these bug reporter expected (directly control access from scdaemon to card by time out), it only changed the behavior of DISCONNECT command. A user required to issue DISCONNECT command anyway and the option could change how DISCONNECT was done. <-- This is 2.0.

Since 2.1, DISCONNECT command works well always, regardless of this option.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .