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!
> 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.
You could also do: gpg –recv-key SIGNATURE_KEY_FPR. Since the signature key contains a backsig, you are guaranteed to get the right primary. So, modulo availability, using this approach doesn’t require the user to trust the clouds.
Interesting, are you saying using SIGNATURE_KEY_FPR could be considered more secure than gpg –recv-key MASTER_KEY_FPR? The master key contains a self-signature, doesn’t it? Although in my case, my master key is also a signature key, so maybe it amounts to the same thing?
I was mostly thinking of the self-hosted vs clouds trust concern though. Key servers you don’t trust could try to exploit a bug in dirmngr too — which a self-hosted trusted server wouldn’t do.
They should be equally secure. But, the primary fingerprint is not available on the smartcard whereas the signature subkey’s fingerprint is available (look at the output of gpg –card-status). As such, using the signature subkey’s fingerprint is more convenient.
With respect to key server exploiting a bug: I guess. But, if you are accessing a web site, there is also potential for abuse there.
Ah right. I updated the shell snippets slightly, I noticed I had used –card-status output from a version when the key was already received. It makes more sense to use –recv-keys with the fingerprint from the –card-status output. Thank you!
You should probably explain in the following paragraph why you choose that particular fingerprint, e.g., “… there is no need to install it, just run gpg –recv-key ‘SIGNATURE_FPR’ using the fingerprint of the signature key printed in the output of ‘gpg –card-status’.
> 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.
> As before, encrypting to myself does not work smoothly because of the trust setting on the public key.
Can you please point out that the ‘ultimate’ trust setting makes the selected key a trust anchor and as such should only be used for the user’s own keys. In other words, this is not the correct way to get rid of the “There is no assurance this key belongs to the named user” warning.
Thanks
Thanks Neal! I modified the text a bit to inform the reader about this.
Thanks!
When setting up to use the smartcard on a new system, if you’ve set the URL when creating the key to point to a known valid source to retrieve your public key then you can simply perform a ‘gpg –card-edit` and issue the `fetch` command to import it. You shouldn’t use a URL you don’t trust anyway when setting it on the card. I personally put it on my website behind an HTTPS URL.
As well another option rather than going into `–card-edit` and setting the validity to `ultimate` is to add `trusted-key ` to your gpg.conf with the long key ID of the primary key. I do this and gpg is able to know that the smartcard subkey is to be trusted.
Hi. Thanks for comments. Indeed, the ‘fetch’ command is what I settled on for my new Debian bullseye setup: https://blog.josefsson.org/2021/05/01/openpgp-smartcard-with-gnome-on-debian-11-bullseye/
Thanks for the trusted-key idea! I’m going to try this for a while and see if I notice any usability differences. It is indeed simpler, and works better when I sometimes remove my secret key stub and re-import it.
Cheers,
Simon
Pingback: OpenPGP smartcard with GNOME on Debian 11 Bullseye – Simon Josefsson's blog