Nitrokey hmac-secret blocked after use of openpgp

[fira959]

I use my NK3 mainly for local authentication of my linux user through systemd-homed (which uses the fido2 hmac-secret extension if I am not mistaken) as well as for managing my openpgp keys.

After updating to firmware version 1.7.0 I noticed that every time I accessed my pgp keys, I was afterwards unable to use my nitrokey for local authentication. Running something like sudo would result in the pin being requested only to then switch to password authentication as a fallback. This only happens after the pgp keys on the nitrokey are used. Removing the nitrokey and plugging it back in does not help. So far only rebooting seems to solve the issue. Unplugging the nitrokey and plugging it back in does resolve the issue. Rebooting the system without unplugging the nk3 however did not always fix it

Updating to 1.7.1 and 1.7.2 has not resolved the issue either.

[tlaurion]

I think the bug you're referring to is not linked to nk3 firmwqre, but heads firmware not being updated?

Have you upgraded firmware for your machine, not only the USB security dongle?

[fira959]

Not using heads

[sosthene-nitrokey]

Hi,

Thank you for the report.

Can you pleas give me the following details:

Which device are you using:

• NK3 A Mini
• NK3 NFC 

What tool are you using to use PGP? (I suppose GPG, if yes, which version).

Are you using the secure element backend? (You can get this information through: nitropy nk3 get-config opcard.use_se050_backend).

[fira959]

The device is a NK3 A Mini The gpg version is: GnuPG 2.4.5, libgcrypt 1.11.0 nitropy nk3 get-config opcard.use_se050_backend returns Command line tool to interact with Nitrokey devices 0.4.47 true

If I recall correctly, the secure element is used by default after version 1.7.0 and I did not set specific options during deployment.

In case it is relevant: The private pgp keys were created outside the nitrokey and imported afterwards, keytype is ed25519

[robin-nitrokey]

This sounds like you imported the keys after the update. Is that correct? Did you already use both OpenPGP (with the same device) and systemd-homed before the update?

[fira959]

I completely reset and updated the nk3 to version 1.7.0 before importing the private pgp keys. Afterwards I setup systemd-homed again with the nk3 as authenticator (and fscrypt key)

Before the reset/update I already used the same setup with the same pgp keys and the same nk3 but on firmware version 1.6.x The issue only started after updating to firmware version 1.7.0

[robin-nitrokey]

I see. And I understand that authentication works before using the OpenPGP keys. Are there any log messages related to the FIDO authentication for the failed attempts? You can change the log level using the SYSTEMD_LOG_LEVEL environment variable , e. g. when running homectl authenticate. Feel free to send us the log via mail if you don’t want to share it publicly.

[fira959]

Without changing the loglevel, I didn't notice any relevant log entries in the journal when the authentication failed.

However, when I run homectl authenticate (without first triggering the bug by using the pgp keys) it also fails with Too frequent login attempts for user user, try again later. The normal login works though (until pgp is used). This commands works just fine for any homed use that only uses a password for authentication though. I will look into this a bit more tomorrow and file a bug against systemd if this turns out to be a different issue.

A small correction of the original post: Removing the nk3 and plugging it back in does fix the issue as well.

I am going to try to get the debug log during login

[fira959]

Here are some relevant log entries I found after triggering the bug:

systemd-homework[3056]: libfido2: fido_hid_open: flock timeout
systemd-homework[3056]: libfido2: fido_dev_open_tx: dev->io.open
systemd-homework[3056]: Failed to open FIDO2 device /dev/hidraw2: FIDO_ERR_INTERNAL
systemd-homework[3056]: Token returned error during pre-flight: Input/output error
login[3045]: pam_systemd_home(login:auth): Failed to acquire home for user fira: Failed to execute operation: Input/output error
systemd-homed[693]: Got notify message lacking both ERRNO= and SYSTEMD_LUKS_LOCK_FD= field, ignoring.
systemd-homed[693]: Worker reported error code EIO.
systemd-homed[693]: Activation failed: Input/output error
systemd-homed[693]: Sent message type=error sender=n/a destination=:1.22 path=n/a interface=n/a member=n/a cookie=97 reply_cookie=4 signature=s error-name=org.freedesktop.DBus.Error.IOError error-message=Failed to execute operation: Input/output error
systemd-homed[693]: changing state activating-for-acquire → inactive

If you also want the entire log with mostly libfido entries, I can try to setup a testsystem and send that to you if required.

I also noticed that the bugs behavior has slightly changed (possibly after the last firmware update). When I tried to authenticate with the nk3 after triggering the bug, the login shell would switch to password authentication right away as if it noticed that the fido2 device is no longer reachable. Currently the PIN is still requested but the shell does not fallback to password authentication. When authentication is requested in a normal shell like bash e.g. running sudo, the above behavior can be observed in that the Pin is requested but nothing happens and the authentication is stuck. When the login is done on a tty, it falls back to password authentication after the PIN is entered.

[fira959]

Another observation of the bug:

After using the pgp keys, I can still use webauthn, e.g. to login to Github. But if I try to login locally first and then try to authenticate to github using its passkeys method, it fails after entereing the pin (but before requesting touch verification) with Authentication failed and the following in the browser console log:

Uncaught (in promise) DOMException: The request is not allowed by the user agent or the platform in the current >
    prompt webauthn-get-element.ts:186
    AsyncFunctionThrow self-hosted:803
    (Async: async)
    handleWebauthnSubtle webauthn-get-element.ts:75
    prompt webauthn-subtle-element.ts:12
    s bind.js:73

[fira959]

Update:

I tried to reproduce the issue on another system with a different nk3 and the issue did not reappear.

The first system is running arch and the nitrokey was reset and private keys imported after upgrading to firmware 1.7.2 The second system is running Debian Bookworm and the nitrokey was not reset.

Potential triggers would be:

• system configuration
• different software versions
• hardware issue

Since both nitrokeys were bought together they should be from the same batch, therefore I think it is unlikely related to the hardware.

[fira959]

I reproduced the issue on the first nk3 with both a vanilla Arch Linux iso and Debian Bookworm, therefore it does not seem to be related to software version or configuration.

Unlike a few month ago, I do get a different output when using homectl authenticatethough:

Operation on home user failed: Failed to execute operation: Input/output error

When using SYSTEMD_LOG_LEVEL=debug I can reproduce the attached log file. Note that while the first time I run homectl authenticate (after triggering the bug by using a secret pgp key stored on the nk3) I am asked for my pin before the command fails (see log1). When I try the command again (even in a different shell) I am not asked for my pin and it just fails with mostly the same error message (see log2)

To summarize:

• The issue is unrelated to operating system or version
• The issue did not appear on another nk3 that was not reset and had its pgp keys imported before firmware version 1.7.2
• Potential sources of the issue seem to be either the specific hardware token or the imported keys (the private pgp keys were imported the same way on both devices, using opgpcard)
• The only way to recover from the issue is to unplug the nk3

Please find attached the requested log files log1.txt log2.txt