GNOME keyring unlock when using password-less login to Fedora Linux Workstation

While I detailed how to use the YubiKey security token for a variety of things I want to revisit hardware token usage as login factor for GNOME sessions as those pose an additional challenge.

When using a security token with U2F as sole login factor we are entering zero-knowledge authentication territory which poses a problem with GNOME/GDM logins if you use the GNOME keyring daemon. By default (at least on Fedora Linux) the login keyring is encrypted using the users account passphrase. So if the user enters this passphrase PAM uses it to also unlock the keyring. You might already see what this means in case of using a security key as sole login factor. There is no passphrase for PAM to decrypt the keyring.

How to go about this

Until now I did not find an elegant, well-known approach to unlocking gnome-keyring-daemon automatically without entering a passphrase. I came up with some ideas to go about this. Overall I decoupled the encryption passphrase of the login keyring from my login passphrase and configured the login flow to use a password storage to automatically pass a passphrase to the daemon upon login. As I see it there could be three approaches to retrieve a secret for the keyring:

• using a TPM2 chip to decrypt a secret stored in e.g. ~/.config/gnome-keyring-tpm-unlock/secret.tpm2
• using a GPG key on the security key
• using an X.509 certificate stored on the security key

An alternative to all of the above is to omit the keyring passphrase and store it unencrypted. One can argue that on a LUKS encrypted disk in a single-user setup this should be safe, as the keyring is encrypted within the file system anyway. As it is unlocked upon login and any user level process should be able to access its contents I don’t see much benefit in additional encryption. On a multi-user system however the extra encryption is necessary. I’m no security expert so take this line of thought with a grain of salt.

If one is using LUKS encryption and is entering the passphrase at this step, or in other words does not use a security key to unlock the LUKS partition too, it is possible to then use this passphrase to unlock the gnome keyring. How to do this is detailed in the ArchWiki. This is not feasible in my case as I unlock the LUKS partition either with the TPM2 or a security key.

At first I used TPM2 and clevis with an encrypted file on the disk holding the secret for the keyring. As this does not seem to provide any benefit to an unencrypted keyring I don’t recommend this. Apart from that one problem with this approach is that every user on the successfully booted system has access to the keyring passphrase and hence is able to decrypt the keyring of another user. As I’m not running a multi-user setup I can safely ignore this. I also have to add my user to the tss group so it may access the TPM2 chip without requiring root privileges, which could be a security problem - I don’t know.

Using the gpg keyring with a gpg key on the security key or X.509 certificates does not really solve the issue at hand - at least not if both features are protected by an additional verification step. In that case PAM would have to handle the verification for unlocking the keyring together with the login flow as it is currently implemented with the users passphrase. However if no further protection apart from requiring ownership of the key, aka. it has to be slotted into the machine, the keyring could be encrypted with a fair level of security I guess. At least for multi-user setups this could be viable.

Unencrypted keyring

The passphrase of the GNOME “Login” keyring can be reset using the “Passwords and Keys” or “Seahorse” GNOME desktop application on Fedora Linux Workstation.

Keyring encryption via TPM2 and clevis

As I first spent some time in getting the keyring decoupled from my login passphrase and unlocking it using the TPM2 chip I’ll go about how I did that now. As I detailed earlier I don’t do this any more as it does not seem to provide any benefit over an unencrypted keyring. That being said it’s a good small use-case to talk about file based encryption/decryption using clevis and TPM2.

Prerequisites

For the TPM2 method I need a tool to encrypt/decrypt files on the disk using the TPM2 chip. I figure that clevis does exactly that with an easy to use CLI interface.

sudo dnf install -y clevis

Apart from the tool the user has to be part of the tss group to access the TPM without sudo.

sudo usermod -aG tss w4tsn

Encrypting the gnome-keyring secret with TPM2

Store the gnome-keyring passphrase in a file /tmp/secret.txt. Then use clevis to generate an encrypted file. Delete the unencrypted file afterwards.

$ mkdir -p ~/.config/gnome-keyring-tpm-unlock
$ clevis encrypt tpm2 '{"pcrs":"7"}' < /tmp/secret.txt > ~/.config/gnome-keyring-tpm-unlock/secret.tpm2
$ shred -uz /tmp/secret.txt

I opted to use PCR 7 only out of convenience as I don’t want to rebind this on every change of the initramfs.

Unlocking the gnome-keyring

The gnome-keyring unlock is triggered by a short command in .gnomerc which is sourced at every shell login. The following command first decrypts the secret using the TPM2 and pipes this as stdin into gnome-keyring-daemon.

clevis decrypt tpm2 '{"pcrs":"7"}' < ~/.config/gnome-keyring-tpm-unlock/secret.tpm2 | gnome-keyring-daemon --replace --unlock

Instead of using clevis here any other secure source of a passphrase may be used. E.g. pass using GPG keys.

Usually if a security token or smart card is used as sole login factor to a GDM session PAM is configured to request a decryption passphrase for the gnome-keyring-daemon. Add the following line right above postlogin to tell the gnome session that it can expect a keyring unlock to happen:

auth	    optional	  pam_gnome_keyring.so