shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-01-23 02:04:32 +03:00
Code

man: document cryptenroll limitations

Browse Source 
Let's document this for now. We should be able to lift these limitations
sooner or later, at which point we can drop this documentation again.

These two limitations are a pitfall that people should be aware of,
before going FIDO2-only.

See: #20230 #19208
This commit is contained in:
Lennart Poettering 2021-11-02 13:37:27 +01:00 committed by Luca Boccassi
parent c7448e741a
commit 0bada3f8b7
1 changed files with 17 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
man/systemd-cryptenroll.xml
View File

@ -60,6 +60,23 @@
area, which is not available in other encryption formats.</para>
</refsect1>
<refsect1>
<title>Limitations</title>
<para>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.</para>
<para>Also note that support for enrolling multiple FIDO2 tokens is currently not too useful, as while
unlocking <command>systemd-cryptsetup</command> 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.</para>
</refsect1>
<refsect1>
<title>Options</title>