在 Fedora Linux 上使用 FIDO U2F 安全密钥
FIDO YubiKey 密钥
![](/data/attachment/album/202308/13/233953yhs6626j866q2iqw.jpg)


FIDO U2F 安全密钥是一种小型的基于 USB/NFC 的设备。它是一种硬件安全令牌，具有多个安全相关的用途模块。FIDO U2F 标准兼容的密钥品牌有多种，包括 NitroKey、SoloKey v2 和 YubiKey。与类似 Yubico OTP 的专有协议相比，FIDO 协议是不依赖特定硬件令牌的，并且使用的工具也不依赖特定制造商。


本文介绍了 FIDO 协议，并展示了如何安装和启用 FIDO U2F 安全密钥作为替代身份验证因素，以用于登录终端、GDM 或进行 sudo 认证。


对于 YubiKey，特别是其不支持 FIDO2/U2F 的旧版设备，请参阅之前的文章：



> 
> **[如何在 Fedora Linux 上使用 YubiKey](https://fedoramagazine.org/how-to-use-a-yubikey-with-fedora-linux/)**
> 
> 
> 


本文不涵盖存储 OpenPGP 密钥或 X.509 证书的操作，因为这些功能与硬件相关，不属于 FIDO U2F 标准的一部分。


### 保留备用安全密钥


一旦你开始使用安全令牌，就必须考虑到自己可能会被锁定在与这些令牌相关联的账户之外的情况。由于硬件安全令牌是独特的，并且被设计为非常难以复制，你不能像在使用 KeePass 或 AndOTP 等软件保险库时那样制作备份。因此，你使用主要密钥进行的所有注册都应立即使用第二个备份密钥重复进行，并将其存储在安全的位置，甚至可能是保险箱中。


在实践中，这意味着你需要将两个硬件令牌注册到你的 Linux 和 Web 账户中，并生成两份 OpenSSH 私钥，并将这两份 OpenSSH 公钥上传到你使用的服务器和服务（例如 GitHub）中。


如果你丢失了一个密钥，你将需要使用第二个密钥登录与密钥注册的每个服务，删除丢失的密钥，并注册一个新密钥。对于使用 FIDO2 协议的无密码登录尤其如此。


### FIDO2、U2F 和 FIDO 联盟


FIDO2 是由 [FIDO 联盟](https://fidoalliance.org) 维护的一系列标准。FIDO 联盟希望最终完全摒弃密码，并提供通过多个因素安全验证用户身份的过程，而无需使用密码。


该标准包括万维网联盟（W3C）的 <ruby> 网页认证 <rt>  Web Authentication </rt></ruby>（WebAuthn）和 FIDO 联盟的 <ruby> 客户端到认证器协议 <rt>  Client-to-Authenticator Protocol </rt></ruby>（CTAP）。WebAuthn 是一种用于请求和处理公钥挑战进行认证的标准 API。通过这个标准，浏览器会向客户端发送一个 <ruby> 挑战 <rt>  challenge </rt></ruby>，然后客户端使用私钥生成一个 <ruby> 响应 <rt>  response </rt></ruby>，挑战者再使用之前交换的公钥进行验证。如何生成挑战答案对于服务来说是不可知的，而是由 CTAP 控制。用户可能会被要求使用多种验证方法，如生物识别、PIN 或存在性检查（或这些方法的组合）。这些验证方式在认证时与注册密钥时的方式相同。


为了保护与硬件令牌的任何交互，可以选择设置一个访问 PIN，并且默认情况下未设置。大多数密钥在连续八次输入访问 PIN 失败后将自动失效。恢复失效的密钥并设置新 PIN 的唯一方法是重置密钥。然而，当密钥重置时，所有其服务注册将丢失！


FIDO2 密钥还支持 FIDO U2F 协议（现已更名为 CTAP1）。该协议旨在提供第二或多因素（但非无密码）认证。Linux 的 PAM 认证系统也可以配置为使用 U2F 协议。虽然 FIDO U2F 不是为无密码认证设计的，但 U2F PAM 模块允许无密码认证。


### 安全影响


FIDO2 / U2F 通过将安全密钥与用户账户绑定来工作。大多数密钥默认启用/使用基本的存在性检查。它们通常通过点亮并提示你触摸密钥来进行存在性检查。FIDO2 PIN 是可选的，默认情况下未设置。当密钥用于登录 Linux 帐户或用于使用 sudo 时，只需确保设备和密钥物理上存在即可。FIDO2 PIN 是一个重要的附加验证步骤，用于确保只有你才能使用密钥进行身份验证。



> 
> 等一下！现在我还要记住额外的 PIN 吗？这不就是一个更短的密码吗？
> 
> 
> —— 担心的读者
> 
> 
> 


FIDO2 PIN 不是密码，它是一个简短、容易记住的短语。这并不是一个问题，因为：


1. 你需要物理访问密钥 *且* 需要知道 PIN。
2. 输入 PIN 错误达到八次会使密钥失效，这使得暴力破解变得困难。


相反地，现在你可以使用存储在密码管理器中的安全密码，而无需记住它。


谷歌在 2016 年进行的一项案例研究，题为 《安全密钥：现代网络的实用密码学第二因素》，显示了安全密钥有效地保护用户免受密码重用、钓鱼和中间人攻击的影响。


### 使用 PAM 进行用户认证


本地系统认证使用 [可插拔认证模块（PAM）](https://www.redhat.com/sysadmin/pluggable-authentication-modules-pam)。U2F 设备的 PAM 模块（因此进行认证）是 `pam_u2f`。你的密钥是否支持 FIDO2 或 FIDO U2F 取决于其固件版本和硬件型号。


设置如下：


1. 安装 PAM 模块。
2. 将密钥注册到你的用户账户上。
3. 使用 `authselect` 在 PAM 中激活智能卡支持。


[authselect](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel) 是一个用于配置带有可重现配置文件的 PAM 的工具。使用 `authselect` 的配置文件可以避免手动修改 `/etc/pam.d` 目录下的配置文件。


### 依赖项


所需的软件包可在官方仓库中获取。



```
[…]$ sudo dnf install pam-u2f pamu2fcfg fido2-tools

```

#### 在密钥上设置 FIDO2 PIN


FIDO2 标准定义了一种用于访问保护的可选 PIN。如果 PIN 丢失或失效，没有 PUK 或其他恢复方式，请确保你有一种备用的身份验证方法。如果通过连续输入无效的 PIN 使 PIN 失效，恢复的唯一方法是重置密钥。然而，重置密钥会删除其所有凭据，并将其与以前注册的所有服务断开连接。


`fido2-tools` 包含一个用于设置密钥的 FIDO2 PIN 的工具： `fido2-token`。使用 `fido2-token -L` 获取当前连接的 FIDO2 设备列表，并使用 `fido2-token -C </path/to/device>` 设置一个新的 PIN：



```
[…]$ fido2-token -L
/dev/hidraw1: vendor=0x1050, product=0x0407 (Yubico YubiKey OTP+FIDO+CCID)
[…]$ fido2-token -C /dev/hidraw1
Enter current PIN for /dev/hidraw1:
Enter new PIN for /dev/hidraw1:

```

#### 将安全密钥注册到本地账户


使用工具 `pamu2fcfg` 检索一个配置行，该行将放入 `~/.config/Yubico/u2f_keys` 中。`pam_u2f` 是由 Yubico 提供的通用 U2F 密钥模块，因此使用 Yubico 特定的默认配置路径。该文件中的每个配置行由用户名和密钥特定的凭据/配置部分以冒号分隔。确保每个用户仅使用一行。



```
fedora-user:owBYtPIH2yzjlSQaRrVcxB...Pg==,es256,+presence+pin[:该用户另外的密钥]

```

如果密钥受 PIN 保护，你将被要求输入 PIN 来进行此操作。对于第一个密钥的初始注册，请使用以下命令：



```
[…]$ mkdir -p ~/.config/Yubico
[…]$ pamu2fcfg --pin-verification > ~/.config/Yubico/u2f_keys

```

要将另一个密钥（例如备份密钥）添加到此单用户配置中，请使用以下命令：



```
[…]$ pamu2fcfg --nouser --pin-verification >> ~/.config/Yubico/u2f_keys

```

`pam_u2f` 还支持使用一个中心身份验证文件。在这种情况下，请确保每个用户使用一行，并将给定用户的所有密钥保持在同一行上。如果两行引用相同的用户名，那么只有最后一行将被使用！请参阅 [pam\_u2f 手册页](https://manpages.org/pam_u2f/8) 获取所有可用选项的详细信息。


### 使用 authselect 配置 PAM


[authselect](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel) 是一个用于控制系统 PAM 配置的工具。它引入了配置文件作为额外的抽象层。一个 `authselect` 配置文件可以更改多个 PAM 配置文件。配置文件具有控制附加功能和行为的参数，例如启用 FIDO U2F 安全密钥。有关 `authselect` 的详细介绍计划在未来的文章中进行。


显示当前活动的 `authselect` 配置文件。如果选择了 SSSD（系统安全服务守护程序）配置文件并启用了 U2F 支持，则输出可能类似于以下内容：



```
[…]$ authselect current
Profile ID: sssd
Enabled features:
- with-pam-u2f

```

使用 `authselect` 和 `with-pam-u2f` 标志，在 PAM 中激活 FIDO U2F 支持：



```
[…]$ sudo authselect select sssd with-pam-u2f

```

如果你还想使用指纹读取器，必须同时启用这两个功能：



```
[…]$ sudo authselect select sssd with-pam-u2f with-fingerprint

```

这会在 PAM 中激活具有 `pam_u2f` 和指纹读取器支持的 SSSD 配置文件。例如，当使用上述 `authselect` 配置文件在终端上使用 sudo 时，首先会要求你提供指纹，如果指纹识别失败，则使用 U2F 密钥。然而，GDM 将首先使用 U2F 密钥。


### 解锁 GNOME 钥匙环守护程序


当使用生物识别、U2F 密钥或任何其他不需要密码短语登录 GNOME 的方法时，无法自动解锁“登录”钥匙环。这是因为，默认情况下，钥匙环的密码短语设置为与你的登录密码短语相同。通常，PAM 将你的登录密码短语传递给钥匙环守护程序。由于你在通过生物识别或 U2F 密钥进行身份验证时不需要输入密码短语，因此 PAM 没有密码短语可以传递给钥匙环守护程序。这个问题没有简单直接的解决方法。


如果你为家目录使用 LUKS 加密并且操作的是单用户系统，你可以从钥匙环中移除密码短语。这将使你的 GNOME 钥匙环在文件级别上保持未加密。但它仍然在块级别上由 LUKS 加密，因为 LUKS 加密与单用户系统上的默认基于文件的钥匙环加密等效。由于钥匙环的加密仅旨在保护其内容免受离线访问，钥匙环在登录后将被解密/解锁，任何运行时应用程序或恶意软件在解锁后都有可能访问钥匙环的内容。由于 LUKS 也是一种离线保护机制，因此可以认为它是钥匙环正常基于文件的加密的替代选择。


如果你的系统被多个用户使用，则 LUKS 加密和钥匙环的正常基于文件的加密不是等效的。在具有只由 LUKS 保护的钥匙环的多用户系统中，具有解密磁盘和引导系统授权的任何用户都能够访问同一系统上的任何其他用户的钥匙环。


移除 GNOME “登录”钥匙环密码短语非常简单。只需设置一个新的空密码，钥匙环将被解锁，并且其内容将以未加密的方式存储在文件级别上。可以使用图形实用程序 Seahorse（也称为“密码和密钥”）来在 GNOME “登录”钥匙环上设置一个空密码。


### 警惕和其他用例


即将发布的文章将探讨如何使用 U2F Dracut 插件使用 FIDO2/U2F 密钥解锁 LUKS 加密的磁盘。


OpenSSH 8.2+ 支持使用 `ed25519-sk` 安全密钥。这个主题已经在之前的文章《[如何在 Fedora Linux 上使用 YubiKey](https://fedoramagazine.org/how-to-use-a-yubikey-with-fedora-linux/)》中涉及到。


需要注意的是，FIDO2/U2F 是一种认证标准。还有其他用于安全令牌的用例（主要由 Yubico 建立），例如 (T)OTP、PIV（用于 x509 密钥管理）或 OpenPGP，这些用例不是一般性的，而是具体硬件上的用例。


*（题图：MJ/4bd195dc-130b-4ef2-af6c-9a6ef5d54223）*




---


via: <https://fedoramagazine.org/use-fido-u2f-security-keys-with-fedora-linux/>


作者：[Alexander Wellbrock](https://fedoramagazine.org/author/w4tsn/) 选题：[lujun9972](https://github.com/lujun9972) 译者：ChatGPT 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
A FIDO U2F security key is a small USB and/or NFC based device. It is a hardware security token with modules for many security related use-cases. There are several brands of FIDO compliant keys, including NitroKey, SoloKey v2, and YubiKey. FIDO, in contrast to proprietary protocols like Yubico OTP, is hardware token agnostic and the tools used are manufacturer independent.

This post introduces the FIDO protocol(s) and shows how to install and enable a FIDO U2F security key as an alternative authentication factor for logging into a terminal, GDM, or authenticating for sudo.

For YubiKeys, especially older ones *without* FIDO2/U2F support, see the previous post titled “[How to use a YubiKey with Fedora Linux](https://fedoramagazine.org/how-to-use-a-yubikey-with-fedora-linux/)“.

This post will not cover storing OpenPGP keys or X.509 certificates because those features are hardware dependent and not part of the FIDO U2F standard.

## Keep a backup security key

As soon as you start working with security tokens you have to account for the potential to lock yourself out of accounts tied to these tokens. As hardware security tokens are unique and designed to be extremely hard to copy you cannot just make a backup of it like you can with software vaults like KeePass or AndOTP. Consequently, all registrations you make with your primary key you should immediately repeat with a second backup key that you will store in a secure location, maybe even a safe.

In practice this means you will need to register both hardware tokens with your Linux and web accounts, generate OpenSSH private keys twice, and upload both OpenSSH public keys to the servers and services you use (for example, GitHub).

Should you lose a key, you’ll want to use your second key to sign in on every service the keys are registered with, remove the lost key, and register a new one. This is especially true for password-less logins using a FIDO2 protocol.

## FIDO2, U2F and the FIDO Alliance

FIDO2 is a collection of standards maintained by the [FIDO Alliance](https://fidoalliance.org). The FIDO Alliance hopes to eventually get rid of passwords altogether and instead provide procedures to authenticate users securely through multiple factors but without the need for passwords.

The standard consists of the World Wide Web Consortium’s (W3C) Web Authentication (WebAuthn) and the FIDO Alliance’s Client-to-Authenticator Protocol (CTAP). WebAuthn is a standard API to request and process public key challenges for authentication. With this, browsers send a challenge to a client which then produces a response with a private key that the challenger then verifies using a previously exchanged public key. How the challenge answer is produced is unknown to the service and it is controlled by the CTAP. The user might be prompted for several verification methods like biometrics, PIN, or presence check (or some combination of these methods). These checks are the same for authentication as they are when registering the key with the service.

A access PIN to protect any interaction with the hardware token is optional and it is unset by default. Most keys will self-invalidate after eight sequential failed attempts at entering the access PIN. The only way to recover an invalidated key and set a new PIN is to reset the key. However, when a key is reset, all its service registrations will be lost!

A FIDO2 key also supports the FIDO U2F protocol (now renamed CTAP1). This protocol is designed for second- or multi-factor (but not password-less) authentication. Linux’s PAM authentication system can also be configured to use the U2F protocol. Although FIDO U2F is not designed for password-less authentication, the U2F PAM module does allow password-less authentication.

## Security implications

FIDO2 / U2F works by tying the security key to your user account. Most keys have a basic presence-check which is enabled / used by default. They typically perform a presence-check by lighting up and prompting you to touch the key. A FIDO2 PIN is optional and it will be unset by default. When the key is registered for signing in to your Linux account or for using sudo, it is sufficient to have the device and key physically present. A FIDO2 PIN is an important additional verification step to ensure that only you can use the key for authentication.

Wait! Now I have to keep track of an additional PIN? Isn’t this just a shorter password?

The concerned reader

A FIDO2 PIN is not a password. It is a short, easy-to-remember phrase. This is not a problem because:

- You need physical access to the key
*and*you need to know the PIN. - Failing to enter the PIN eight times will invalidate the key which makes it hard to brute-force.

On the contrary, you can now use a secure password stored in a password manager that you don’t need to remember.

A 2016 case study by Google, titled “* Security Keys: Practical Cryptographic Second Factors for the Modern Web*“, shows security keys effectively protect users from password reuse, phishing and man-in-the-middle attacks.

## User authentication using PAM

Local system authentication uses [Pluggable Authentication Modules (PAM)](https://www.redhat.com/sysadmin/pluggable-authentication-modules-pam). The PAM module for U2F devices (and hence authentication) is *pam_u2f*. Whether your key supports FIDO2 or FIDO U2F will depend on its firmware version and hardware model.

The setup is as follows:

- Install the PAM module.
- Register a key with your user account.
- Use
*authselect*to activate smart card support in PAM.

[Authselect](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel) is a tool for configuring PAM with reproducible profiles. By using authselect’s profiles, manually altering configuration files under the /etc/pam.d directory can be avoided.

## Dependencies

The required packages are available in the official repositories.

[…]$ sudo dnf install pam-u2f pamu2fcfg fido2-tools

### Set a FIDO2 PIN on your key

The FIDO2 standard defines an optional PIN for access protection. There is no PUK or other way to restore a lost or invalidated PIN so make sure you have a backup approach for authentication. If the PIN is invalidated through sequential entry of invalid PINs, the only way to recover is to reset the key. However, resetting your key removes all its credentials and disconnects it from all previously registered services.

The *fido2-tools* package contains a tool to set the FIDO2 PIN of your key: *fido2-token*. Get a list of currently connected FIDO2 devices with `fido2-token -L` and set a new pin with `fido2-token -C </path/to/device>`:

[…]$ fido2-token -L /dev/hidraw1: vendor=0x1050, product=0x0407 (Yubico YubiKey OTP+FIDO+CCID) […]$ fido2-token -C /dev/hidraw1 Enter current PIN for /dev/hidraw1: Enter new PIN for /dev/hidraw1:

**Register the security key with your local account(s)**

Use the tool *pamu2fcfg* to retrieve a configuration line that goes into ~/.config/Yubico/u2f_keys. *pam_u2f* is a Yubico-provided, generic module for U2F keys, hence the Yubico specific default configuration path. Each configuration line in this file consists of a username and a key-specific credential / config part separated by colons. Be sure to only use one line per user.

fedora-user:owBYtPIH2yzjlSQaRrVcxB...Pg==,es256,+presence+pin[:another key for this user]

If the key is PIN protected you’ll be asked to enter the PIN for this operation. Use the following for the initial registration of your first key:

[…]$ mkdir -p ~/.config/Yubico […]$ pamu2fcfg --pin-verification > ~/.config/Yubico/u2f_keys

To add another key (for example, your backup key) to this single-user configuration, use the following command:

[…]$ pamu2fcfg --nouser --pin-verification >> ~/.config/Yubico/u2f_keys

*pam_u2f* also supports the use of a central authentication file. In that case, be sure to use one line per user and to keep all the keys of a given user on the same line. If two lines reference the same username only the last one will be used! Have a look at the [pam_u2f man page](https://manpages.org/pam_u2f/8) for all available options.

## Configure PAM with authselect

** authselect** is a tool for controling your system’s PAM configuration. It introduces profiles as an additional layer of abstraction. One authselect profile can change several PAM configuration files. Profiles have parameters that control additional features and behaviors like enabling FIDO U2F security keys. A detailed tour of

*authselect*is planned for a future article.

Display the currently active *authselect* profile. With the SSSD (System Security Service Daemon) profile selected and U2F support enabled, the output might resemble the following:

[…]$ authselect current Profile ID: sssd Enabled features: - with-pam-u2f

Activate FIDO U2F support in PAM using *authselect* with the *with-pam-u2f* flag:

[…]$ sudo authselect select sssd with-pam-u2f

If you also want to use your fingerprint reader you have to enable both features:

[…]$ sudo authselect select sssd with-pam-u2f with-fingerprint

This activates the *sssd* profile with *pam_u2f* and fingerprint reader support. For example, when using sudo on a terminal with the above authselect profile configuration, you’ll first be asked for a fingerprint and if that fails for the U2F key. GDM, however, will use the U2F key first.

## Unlocking the GNOME keyring daemon

When using biometrics, a U2F key, or any other method that does not require a passphrase to sign in to GNOME, the *Login* keyring cannot be unlocked automatically. This is because, by default, the keyring passphrase is set to the same value as your login passphrase. Normally, PAM passes your login passphrase to the keyring daemon. Since you are not entering a passphrase when authenticating via methods such as biometrics or U2F keys, there is no passphrase for PAM to pass to the keyring daemon. There is no straight forward solution to this problem.

If you use LUKS encryption for your home partition and operate a single-user system, you could remove the passphrase from your keyring. This will leave your gnome keyring unencrypted at the file level. But it will still be encrypted at the block level by LUKS. LUKS encryption is equivalent to the default file-based keyring encryption on a single-user system since the keyring’s encryption is only designed to protect its contents from offline access. The keyring will be decrypted / unlocked after login either way and any runtime application or malware can potentially access the keyring’s contents after it is unlocked. Since LUKS is also an offline protection mechanism, it can be considered an equivalent alternative to the keyring’s normal file-based encryption.

LUKS encryption and the keyring’s normal file-based encryption are not equivalent if your system is used by multiple users. In the case of a multi-user system with the keyrings protected only by LUKS, any user with authorization to decrypt the disk and boot the system will be able to access any other user’s keyring on that same system.

Removing the GNOME *Login* keyring passphrase is straight forward. Just set a new empty password and the keyring will be unlocked and it will be stored unencrypted at the file level. The graphical utility *seahorse* (also called *Passwords and Keys*) can be used to set a blank password on your GNOME *Login* keyring.

## Lookout and other use-cases

Upcoming articles will explore how to use FIDO2/U2F keys for unlocking LUKS-encrypted disks using the U2F Dracut plugin.

OpenSSH 8.2+ supports the use of *ed25519-sk* security keys. This topic has already been touched upon in the previous article titled “[How to use a YubiKey with Fedora Linux](https://fedoramagazine.org/how-to-use-a-yubikey-with-fedora-linux/)“.

Note that FIDO2/U2F is an authentication standard. There are other use-cases for security tokens (primarily established by Yubico) like (T)OTP, PIV (for x509 key management) or OpenPGP which are not covered in general but on a hardware by hardware basis.

## Aaron

I think removing the password from your GNOME keyring is

alwaysa bad idea, no matter the usecase.Yes, a LUKS-encrypted drive / home partition protects against offline-attacks. But that’s it. Once you are logged in, you have no protection whatsoever.

Imagine running some bad script or malicious program in your own user context. It can read (and probably write) all your files under ~. So it can easily get a copy of your keyring file from ~/.local/share/keyrings/ and submit it to some external server or whatever. You wouldn’t even notice, as these files are so small…

This can happen no matter if you have a passphrase set or or onto the keyring file itself.

The difference is that a keyring file without any passphrase is readable by anyone, so an attacker would now have all your saved credentials. If the file itself was protected with a passphrase, so its contents being encrypted, even if someone got read access, the only way would be to brute-force the passphrase, which is considerably more work than just opening an unencrypted file.

It’s a misconception that a password-protected but already unlocked keyfile would be unencrypted and as such easily read some malicious software. The keyfile

nevergets saved unencrypted onto the drive unless you remove the passphrase. As long as it has a passphrase set, the file itself isalwaysstill encrypted, the unencrypted data itself is just stored in the RAM while the keyring is in unlocked state, never written to disk. So even if someone takes a copy of your keyring file while it was unlocked by a passphrase earlier, the file itself is still encrypted.## Alexander Wellbrock

I have to object until proven wrong. If an attacker manages to infiltrate the system and gain user-level access the unlocked keyring is available through the dbus API org.freedesktop.secrets. Any (potentially malicious) process could read secrets from an unlocked keyring that way.

## Aaron

That’s correct; that’s why I was specifically speaking about copying the keyring-file(s).

If I were to write malware, that would be the first thing I’d try, because it’s the most simple one.

Copying the file(s) will surely be unnoticed, whereas querying data from an unlocked keyring

might(depending on the way the user has configured the system) trigger some notification, or even confirmation dialog to allow access to the keyring / wallet.Yes, it’s only a different approach of a malicious software trying to steal sensitive data, but wouldn’t you want to make it as hard as possible? There is no 100% perfect security, but shouldn’t you at least try to deny as many possible ways of accessing the data as possible?

I mean, this is not the right place to propose some not very well thought out changes to the way the keyring(-access) works, I know this… But some quick thoughts would be:

1. mandatory user-confirmation (OK / Deny Buttons, nothing too fancy) each and every time some application wants to access data from the keyring. Except:

2. an option for the user to generally allow specific processes from the (several) systemwide /bin and /sbin folders to access the keyring without any kind of user-confirmation (which would minimize the impact of 1 on the user experience, as only user-programs / scripts which reside in any other location would trigger the popup). This would assume that the system itself is uncompromised; if one would get root-access to your system, you surely have bigger problems than the GNOME keyring). This way, things like your email-client or accessing a network ressource or letting the ssh client access the private key passphrase and so on would still work, but some random script from the internet would not be able to query your unlocked keyring unnoticed…

Finally, because I forgot to say it in my first comment: thanks for your article, it’s well written and very understandable.

## Alexander Wellbrock

I follow your line of thought and I’m with you that it’s best to do as much as you can. The decision to propose to unlock the keyring is based on the convenience trade-off which helps in implementing this login technology. I think the benefits of the security key with good UX outweigh the risk of an unencrypted keyring, something which is more security-by-obscurity than security-by-design. If there would be a way to still encrypt the keyring while unlocking it without an extra password prompt it would be a no-brainer to keep it encrypted – e.g. by a pam module that uses the pam_u2f authentication also for unlocking the keyring which is exactly what happens right now with the pam password prompt and gnome keyring unlock modules.

I also forgot to thank you for your constructive comment. You caught me at a bad angle by saying “it’s always a bad idea”, because I think that the concept of “principle” mostly results in unwarranted disregard of viable approaches / use-cases / trade offs

## Jason Barbier

You make a good point, but counter point, Im a malware maker, Im already on your machine, I could take the files and scrape the keys out of memory, or swipe the passkey as you logon. All of those would be as equally unnoticed as copying your keyring file.

As Alexander points out really the key ring encryption is to help with offline attacks, the only way it would help with online attacks would be to do the same thing most password managers let you do, aggressively expire your session and lock the keyring, and if youre doing that chances are you dont care your keyring doesnt automatically unlock, infact its probably a feature for you not a bug.

We could get into affirmative consent for key ring access, and keep trust lists, and all of that, and that would be a step up but ultimately we will still have a problem of this key has to be in memory some time.

But I will say, your head and heart are in the right place and thanks for being constructive.

## Gregory Bartholomew

Why couldn’t malware run a command like the following to retrieve passwords from an unlocked keyring?

The GNOME keyring seems like an absolutely horrible idea. Security keys that use public-private-key encryption and store the private key in a way that cannot be retrieved definitely seem like the way to go.

## Ernest N. Wilcox Jr.

I’d prefer that the Fedora team take steps to accommodate and simplify the implementation of passwordless authentication using FIDO0 passkeys (the coming security technology) to login securely with my fingerprint scanner at boot time as well as to use it to enable me to log into websites where I have set up passwordless login. While passwordless authentication is not yet universally adopted, it will be the most secure login option available after its implementation is completed. By setting up a passkey on my computer, and using a FIDO0 compliant biometric fingerprint scanner, I should be able to log into any website with which I have an account and with which I have configured passwordless authentication, and that should include logging into my Fedora computer, and root authentication using sudo, etc. I have read that this protocol may become broadly mainstream within the coming year and I want to be able to use it in my Fedora workstation as easily as I can in my Windows systems.

My2Cents,

Ernie

## Alexandra

You actually have made a mistake in this configuration you will fallback on “password” if the key is missing or fail and password only will allow the login.

in my case i do

sudo authselect select sssd #remove useless thing

After in both /etc/pam.d/system-auth and sudo nano /etc/pam.d/gdm-password

auth [success=done default=die] pam_u2f.so prompt cue interactive sufficient required

success=done mean if successful ignore other auth, default die mean if a user have not set it will fail, prompt cue interactive make it blink will to push enter key before starting (like that if the key is not there you have time to plug it),

sufficient also allow the log when he’s the only one, required make it mandatory if it fail it do not use password as fallback.

## Alexander Wellbrock

If I omit the option –with-pam-u2f all entries about pam_u2f disappear from /etc/pam.d and the key is not used anymore. Tested on Fedora 38 Workstation GNOME edition.

## Nikos

In my machine there are other profiles enabled. It is ok to remove them? i don’t use fingeprint reader and others don’t know why are there:

Profile ID: sssd

Enabled features:

– with-fingerprint

– with-silent-lastlog

– with-mdns4

I kept them and if i remove yubikey i can also login with my password.

## Joe

I am using a trustkey g310 for log into fedora on all my devices for as long as Lennard Poetterings article https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html was posted.

It is really only the fact that gnome-keyring does not transparently work with it that is a little anoying, but bearable.

Great stuff!