From: Peter Cai Date: Thu, 26 Jan 2023 01:39:17 +0000 (-0500) Subject: docs: Update crypt{enroll,setup} limitations regarding FIDO2 X-Git-Tag: v253-rc2~53^2~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=820c66dcfc4392e038c89f4702733f2f8c5cf957;p=thirdparty%2Fsystemd.git docs: Update crypt{enroll,setup} limitations regarding FIDO2 --- diff --git a/man/systemd-cryptenroll.xml b/man/systemd-cryptenroll.xml index 1e9a4457c2c..8af75d1523b 100644 --- a/man/systemd-cryptenroll.xml +++ b/man/systemd-cryptenroll.xml @@ -64,17 +64,17 @@ Limitations Note that currently when enrolling a new key of one of the five supported types listed above, it is - required to first provide a passphrase or recovery key (i.e. one of the latter two key types). For - example, it's currently not possible to unlock a device with a FIDO2 key in order to enroll a new FIDO2 - key. Instead, in order to enroll a new FIDO2 key, it is necessary to provide an already enrolled regular - passphrase or recovery key. Thus, if in future key roll-over is desired it's generally recommended to - combine TPM2, FIDO2, PKCS#11 key enrollment with enrolling a regular passphrase or recovery key. - - Also note that support for enrolling multiple FIDO2 tokens is currently not too useful, as while - unlocking systemd-cryptsetup cannot identify which token is currently plugged in and - thus does not know which authentication request to send to the device. This limitation does not apply to - tokens enrolled via PKCS#11 — because tokens of this type may be identified immediately, before - authentication. + required to first provide a passphrase, a recovery key or a FIDO2 token. It's currently not supported to + unlock a device with a TPM2/PKCS#11 key in order to enroll a new TPM2/PKCS#11 key. Thus, if in future key + roll-over is desired it's generally recommended to ensure a passphrase, a recovery key or a FIDO2 token + is always enrolled. + + Also note that support for enrolling multiple FIDO2 tokens is currently limited. When multiple FIDO2 + tokens are enrolled, systemd-cryptseup will perform pre-flight requests to attempt to + identify which of the enrolled tokens are currently plugged in. However, this is not possible for FIDO2 + tokens with user verification (UV, usually via biometrics), in which case it will fall back to attempting + each enrolled token one by one. This will result in multiple prompts for PIN and user verification. This + limitation does not apply to PKCS#11 tokens.