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?

Stanimir Stoyanov
  • 221
  • 2
  • 6

3 Answers3

15

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.

Justin
  • 151
  • 1
  • 3
  • 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 07 '18 at 19:50
  • You can just stop and restart your `gpg-agent` every x # of mins to force pin re-entry. – user196817 Jan 14 '19 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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
user3037237
  • 101
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.

Cybernaut
  • 21
  • 3