Non-Discoverable Credentials

Non-discoverable credentials are a slightly different beast. In contrast to the resident keys stored on the device, these credentials are not stored on the hardware token. Instead, the authenticator generates a separate key pair for each requester based on the protected, internal master key. Its public key is sent to the RP's requesting server, along with a credential ID. The RP then maps this public key with the user account. For each subsequent authentication, the authenticator uses the credential ID to derive the private key from the master key.

Because this key is stored only temporarily in the authenticator's protected memory, it is called an ephemeral key. Importantly, the authenticator itself cannot identify the non-discoverable credentials (Figure 3). It cannot search for the key from the rpID and, without the credential ID, would not even be able determine whether a matching key exists at all.

Figure 3: The schematic workflow of an authentication procedure by non-discoverable credentials, which the authenticator itself cannot identify.

Obviously, in the case of non-discoverable credentials, the RP first needs to obtain the email address, username, or telephone number. After doing so, it can send the associated credential ID back to the browser. As soon as the security key receives this credential ID from the browser, it can derive an ephemeral key by way of the master key and use it for signing.

In contrast to the discoverable credentials, you find no restrictions. The keys are not stored on the authenticator, which means you can basically have any number of keys. If you use non-resident keys, you are also not tied to specific devices. With a suitable authenticator, authentication works across any number of devices and platforms.

However, this greater flexibility also comes with a downside: You need to remember which user handle (email, username, phone number) you used for which website. Additionally, websites need to store the links reliably between user accounts and public keys. A lack of diligence can all too easily lead to serious security problems.

The question is: What does this means in relation to SSH authentication? Third parties cannot use non-discoverable credentials if they do not have the associated credential ID file – even if they know the PIN. This procedure is ideal for environments in which confidentiality must be guaranteed even if a YubiKey is lost.

In contrast, discoverable credentials are impressive in terms of their flexibility. The only way to log in from an arbitrary workstation is to touch the YubiKey and enter the FIDO2 PIN. If the PIN is known, this procedure is ideal when you require particularly simple processes.

OpenSSH and FIDO2

To set up OpenSSH with FIDO2 authentication, you need the right OpenSSH version, as mentioned earlier. A PIN for FIDO2 must also be set on the YubiKey. Once these requirements are met, you need to add a line for the PubkeyAuthOptions verify-required option to the /etc/ssh/sshd_config file on all the remote systems and then restart SSH. You can restrict this to specify credentials by adding verify-required as a suffix to the matching entries in ~/.ssh/authorized_keys.

To use discoverable credentials with a YubiKey, first insert the token; then, load a key pair on the basis of the ECDSA curve (first command) or ED25519 curve (second command):

$ ssh-keygen -t ecdsa-sk -O resident -O application=ssh:<description> -O verify-required
$ ssh-keygen -t ed25519-sk -O resident -O application=ssh:<description> -O verify-required

You need firmware version 5.2.3 or later on the YubiKey.

The <description> is simply text that describes where the key is used (e.g., a server name) to help users identify the correct discoverable credential if several are stored on the YubiKey. Although a description is optional, I highly recommend entering a meaningful text.

Although the conventional key pair I created with ssh-keygen in Figure 1 still exists, the tool in Figure 4 generates a variant optimized for security keys. You need to both enter a PIN and touch the authenticator.

Figure 4: Creating an ED25519 key pair.

After entering ssh-copy-id to transfer the public key to the target system, the next step is to check that the login works. You have to prove that you are physically present (i.e., touch the YubiKey). The SSH client then prompts for the PIN. If everything works, SSH confirms that you are present and lets you access the system.

Conclusions

If you plan to open access to SSH (possibly even to users on the Internet), you need to harden your authentication process. Both Google Authenticator (i.e., TOTP) and hardware-supported authentication by secure key offer huge security benefits with a manageable configuration overhead.