Mailing List Archive

Presetting passphrases when using scdaemon
Greetings,

I am trying to use the gpg-connect-agent tool to preset passphrases for
private keys that are stored on a GnuPG smart card.

My current workflow to test this process works like this:

(the "[...]" is where the passphrase should go as a hex string)

$ gpgconf --kill gpg-agent # scdaemon also killed
$ gpg-connect-agent # starts gpg-agent and connects
> PRESET_PASSPHRASE 73B8E934293926BA494E280D11E8B9EA2926A723 -1 [...]
OK
> PRESET_PASSPHRASE 671CB3A7B36410552D08BABA2300C27142714DAB -1 [...]
OK
> PRESET_PASSPHRASE 49773C7DC8414E61642B3BBAE2C8E489AAA3837B -1 [...]
OK
> PRESET_PASSPHRASE 410D756490AA179AC5D94D3870108CC90C7A3500 -1 [...]
OK
> /bye
$ gpg --encrypt foo # encrypt a file
$ gpg -o foo.out -d foo.gpg # decrypt to test access to key from card

At this point, I get a pinentry prompt. Having preset the passphrase
already, I would have expected that the encrypt/decrypt operations would
have worked just fine without requiring me to enter my PIN.

Why am I not able to preset passphrases for keys that are stored on the
smart card? What am I missing?

--
Jason Franklin
Re: Presetting passphrases when using scdaemon [ In reply to ]
On Wed, 11 Dec 2019 13:00, Franklin, Jason said:

> Why am I not able to preset passphrases for keys that are stored on the
> smart card? What am I missing?

Right. There is no cache for the PINs of smartcards in GnuPG. What
might look like a cache is that a smartcard usually requires the PIN
only once and then keeps the key unlocked until the card is powered down
or reset.

In case you use an OpenPGP card, there is a hack to disable the PIN
requirement for a card. You need to put this sequence into the login
data (gpg --card-edit):

arbitrary data up to a linefeed<LF><DC4>F=02<LF>

It is best to create a file with that data:

$ printf "foobar\n\x14F=03\n" >foo.inp

Then make sure that the default PIN is set for the card (i.e. 123456)
and use:

$ gpg --card-edit
gpg/card> admin
gpg/card> login <foo.inp
gpg/card> quit

to put the magic spell into the login data object. From now on you
should not anymore be asked for the PIN but the default PIN is passed
internally to the card. This does not work for the Admin key.

Please test this procedure first with a test card so that you don't
accidently brick your real on-card keys. The code takes some
precautions but it is just too easy to get things wrong.


Shalom-Salam,

Werner


ps.
Here is the description of the login hack:
/* GnuPG makes special use of the login-data DO, this function parses
the login data to store the flags for later use. It may be called
at any time and should be called after changing the login-data DO.

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.

*/
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.