Debian buster is almost released, and today I celebrate midsummer by installing (a pre-release) of it on my Lenovo X201 laptop. Everything went smooth, except for the usual issues with smartcards under GNOME. I use a FST-01G running Gnuk, but the same issue apply to all OpenPGP cards including YubiKeys. I wrote about this problem for earlier releases, read Smartcards on Debian 9 Stretch and Smartcards on Debian 8 Jessie. Some things have changed – now GnuPG‘s internal ccid support works, and dirmngr is installed by default when you install Debian with GNOME. I thought I’d write a new post for the new release.
After installing Debian and logging into GNOME, I start a terminal and attempt to use the smartcard as follows.
jas@latte:~$ gpg --card-status gpg: error getting version from 'scdaemon': No SmartCard daemon gpg: OpenPGP card not available: No SmartCard daemon jas@latte:~$
The reason is that the scdaemon package is not installed. Install it as follows.
jas@latte:~$ sudo apt-get install scdaemon
After this, gpg --card-status works. It is now using GnuPG’s internal CCID library, which appears to be working. The pcscd package is not required to get things working any more — however installing it also works, and you might need pcscd if you use other applications that talks to the smartcard.
jas@latte:~$ gpg --card-status
Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.2.14-67252015) 00 00
Application ID ...: D276000124010200FFFE672520150000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 67252015
Name of cardholder: Simon Josefsson
Language prefs ...: sv
Sex ..............: man
URL of public key : https://josefsson.org/key-20190320.txt
Login data .......: jas
Signature PIN ....: inte tvingad
Key attributes ...: ed25519 cv25519 ed25519
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 710
KDF setting ......: off
Signature key ....: A3CC 9C87 0B9D 310A BAD4 CF2F 5172 2B08 FE47 45A2
created ....: 2019-03-20 23:40:49
Encryption key....: A9EC 8F4D 7F1E 50ED 3DEF 49A9 0292 3D7E E76E BD60
created ....: 2019-03-20 23:40:26
Authentication key: CA7E 3716 4342 DF31 33DF 3497 8026 0EE8 A9B9 2B2B
created ....: 2019-03-20 23:40:37
General key info..: [none]
jas@latte:~$
As before, using the key does not work right away:
jas@latte:~$ echo foo|gpg -a --sign gpg: no default secret key: No public key gpg: signing failed: No public key jas@latte:~$
This is because GnuPG does not have the public key that correspond to the private key inside the smartcard.
jas@latte:~$ gpg --list-keys jas@latte:~$ gpg --list-secret-keys jas@latte:~$
You may retrieve your public key from the clouds as follows. With Debian Buster, the dirmngr package is installed by default so there is no need to install it. Alternatively, if you configured your smartcard with a public key URL that works, you may type “retrieve” into the gpg --card-edit interactive interface. This could be considered slightly more reliable (at least from a self-hosting point of view), because it uses your configured URL for retrieving the public key rather than trusting clouds.
jas@latte:~$ gpg --recv-keys "A3CC 9C87 0B9D 310A BAD4 CF2F 5172 2B08 FE47 45A2" gpg: key D73CF638C53C06BE: public key "Simon Josefsson <simon@josefsson.org>" imported gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u gpg: next trustdb check due at 2019-10-22 gpg: Total number processed: 1 gpg: imported: 1 jas@latte:~$
Now signing with the smart card works! Yay! Btw: compare the output size with the output size in the previous post to understand the size advantage with Ed25519 over RSA.
jas@latte:~$ echo foo|gpg -a --sign -----BEGIN PGP MESSAGE----- owGbwMvMwCEWWKTN8c/ddRHjaa4khlieP//S8vO5OkpZGMQ4GGTFFFkWn5nTzj3X kGvXlfP6MLWsTCCFDFycAjARscUM/5MnXTF9aSG4ScVa3sDiB2//nPSVz13Mkpbo nlzSezowRZrhn+Ky7/O6M7XljzzJvtJhfPvOyS+rpyqJlD+buumL+/eOPywA =+WN7 -----END PGP MESSAGE-----
As before, encrypting to myself does not work smoothly because of the trust setting on the public key. Witness the problem here:
jas@latte:~$ echo foo|gpg -a --encrypt -r simon@josefsson.org
gpg: 02923D7EE76EBD60: There is no assurance this key belongs to the named user
sub cv25519/02923D7EE76EBD60 2019-03-20 Simon Josefsson <simon@josefsson.org>
Primary key fingerprint: B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE
Subkey fingerprint: A9EC 8F4D 7F1E 50ED 3DEF 49A9 0292 3D7E E76E BD60
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N)
gpg: signal Interrupt caught ... exiting
jas@latte:~$
You update the trust setting with the gpg --edit-key command. Take note that this is not the general way of getting rid of the “There is no assurance this key belongs to the named user” warning — using a ultimate trust setting is normally only relevant for your own keys, which is the case here.
jas@latte:~$ gpg --edit-key simon@josefsson.org
gpg (GnuPG) 2.2.12; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret subkeys are available.
pub ed25519/D73CF638C53C06BE
created: 2019-03-20 expires: 2019-10-22 usage: SC
trust: unknown validity: unknown
ssb cv25519/02923D7EE76EBD60
created: 2019-03-20 expires: 2019-10-22 usage: E
card-no: FFFE 67252015
ssb ed25519/80260EE8A9B92B2B
created: 2019-03-20 expires: 2019-10-22 usage: A
card-no: FFFE 67252015
ssb ed25519/51722B08FE4745A2
created: 2019-03-20 expires: 2019-10-22 usage: S
card-no: FFFE 67252015
[ unknown] (1). Simon Josefsson <simon@josefsson.org>
gpg> trust
pub ed25519/D73CF638C53C06BE
created: 2019-03-20 expires: 2019-10-22 usage: SC
trust: unknown validity: unknown
ssb cv25519/02923D7EE76EBD60
created: 2019-03-20 expires: 2019-10-22 usage: E
card-no: FFFE 67252015
ssb ed25519/80260EE8A9B92B2B
created: 2019-03-20 expires: 2019-10-22 usage: A
card-no: FFFE 67252015
ssb ed25519/51722B08FE4745A2
created: 2019-03-20 expires: 2019-10-22 usage: S
card-no: FFFE 67252015
[ unknown] (1). Simon Josefsson <simon@josefsson.org>
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
pub ed25519/D73CF638C53C06BE
created: 2019-03-20 expires: 2019-10-22 usage: SC
trust: ultimate validity: unknown
ssb cv25519/02923D7EE76EBD60
created: 2019-03-20 expires: 2019-10-22 usage: E
card-no: FFFE 67252015
ssb ed25519/80260EE8A9B92B2B
created: 2019-03-20 expires: 2019-10-22 usage: A
card-no: FFFE 67252015
ssb ed25519/51722B08FE4745A2
created: 2019-03-20 expires: 2019-10-22 usage: S
card-no: FFFE 67252015
[ unknown] (1). Simon Josefsson <simon@josefsson.org>
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg> quit
jas@latte:~$
Confirm gpg --list-keys indicate that the key is now trusted, and encrypting to yourself should work.
jas@latte:~$ gpg --list-keys
/home/jas/.gnupg/pubring.kbx
----------------------------
pub ed25519 2019-03-20 [SC] [expires: 2019-10-22]
B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE
uid [ultimate] Simon Josefsson <simon@josefsson.org>
sub ed25519 2019-03-20 [A] [expires: 2019-10-22]
sub ed25519 2019-03-20 [S] [expires: 2019-10-22]
sub cv25519 2019-03-20 [E] [expires: 2019-10-22]
jas@latte:~$ gpg --list-secret-keys
/home/jas/.gnupg/pubring.kbx
----------------------------
sec# ed25519 2019-03-20 [SC] [expires: 2019-10-22]
B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE
uid [ultimate] Simon Josefsson <simon@josefsson.org>
ssb> ed25519 2019-03-20 [A] [expires: 2019-10-22]
ssb> ed25519 2019-03-20 [S] [expires: 2019-10-22]
ssb> cv25519 2019-03-20 [E] [expires: 2019-10-22]
jas@latte:~$ echo foo|gpg -a --encrypt -r simon@josefsson.org
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2019-10-22
-----BEGIN PGP MESSAGE-----
hF4DApI9fuduvWASAQdA4FIwM27EFqNK1I5eZERaZVDAXJDmYLZQHjZD8TexT3gw
7SDaeTLm7s0QSyKtsRugRpex6eSVhfA3WG8fUOyzbNv4o7AC/TQdhZ2TDtXZGFtY
0j8BRYIjVDbYOIp1NM3kHnMGHWEJRsTbtLCitMWmLdp4C98DE/uVkwjw98xEJauR
/9ZNmmvzuWpaHuEJNiFjORA=
=tAXh
-----END PGP MESSAGE-----
jas@latte:~$
The issue with OpenSSH and GNOME Keyring still exists as in previous releases.
jas@latte:~$ ssh-add -L The agent has no identities. jas@latte:~$ echo $SSH_AUTH_SOCK /run/user/1000/keyring/ssh jas@latte:~$
The trick we used last time still works, and as far as I can tell, it is still the only recommended method to disable the gnome-keyring ssh component. Notice how we also configure GnuPG’s gpg-agent to enable SSH daemon support.
jas@latte:~$ mkdir ~/.config/autostart jas@latte:~$ cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/ jas@latte:~$ echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-ssh.desktop jas@latte:~$ echo enable-ssh-support >> ~/.gnupg/gpg-agent.conf
Log out of GNOME and log in again. Now the environment variable points to gpg-agent’s socket, and SSH authentication using the smartcard works.
jas@latte:~$ echo $SSH_AUTH_SOCK /run/user/1000/gnupg/S.gpg-agent.ssh jas@latte:~$ ssh-add -L ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE cardno:FFFE67252015 jas@latte:~$
Topics for further discussion and research this time around includes:
- Should
scdaemon(and possiblypcscd) be pre-installed on Debian desktop systems? - Could
gpg --card-statusattempt to import the public key and secret key stub automatically? Alternatively, some new command that automate the bootstrapping of a new smartcard. - Should GNOME keyring support smartcards?
- Why is GNOME keyring used by default for SSH rather than
gpg-agent? - Should gpg-agent default to enable the SSH daemon?
- What could be done to automatically infer the trust setting for a smartcard based private key?
Thanks for reading and happy smartcarding!
