mirror of
https://github.com/systemd/systemd-stable.git
synced 2024-12-25 23:21:33 +03:00
a587a16af2
We said that recovery keys are "similar to regular passphrases" before intorducing "regular passphrases".
361 lines
19 KiB
XML
361 lines
19 KiB
XML
<?xml version="1.0"?>
|
|
<!--*-nxml-*-->
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
|
<refentry id="systemd-cryptenroll" xmlns:xi="http://www.w3.org/2001/XInclude" conditional='HAVE_LIBCRYPTSETUP'>
|
|
|
|
<refentryinfo>
|
|
<title>systemd-cryptenroll</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>systemd-cryptenroll</refentrytitle>
|
|
<manvolnum>1</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>systemd-cryptenroll</refname>
|
|
<refpurpose>Enroll PKCS#11, FIDO2, TPM2 token/devices to LUKS2 encrypted volumes</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>systemd-cryptenroll <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="opt">DEVICE</arg></command>
|
|
</cmdsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para><command>systemd-cryptenroll</command> is a tool for enrolling hardware security tokens and devices
|
|
into a LUKS2 encrypted volume, which may then be used to unlock the volume during boot. Specifically, it
|
|
supports tokens and credentials of the following kind to be enrolled:</para>
|
|
|
|
<orderedlist>
|
|
<listitem><para>PKCS#11 security tokens and smartcards that may carry an RSA key pair (e.g. various
|
|
YubiKeys)</para></listitem>
|
|
|
|
<listitem><para>FIDO2 security tokens that implement the <literal>hmac-secret</literal> extension (most
|
|
FIDO2 keys, including YubiKeys)</para></listitem>
|
|
|
|
<listitem><para>TPM2 security devices</para></listitem>
|
|
|
|
<listitem><para>Regular passphrases</para></listitem>
|
|
|
|
<listitem><para>Recovery keys. These are similar to regular passphrases, however are randomly generated
|
|
on the computer and thus generally have higher entropy than user-chosen passphrases. Their character
|
|
set has been designed to ensure they are easy to type in, while having high entropy. They may also be
|
|
scanned off screen using QR codes. Recovery keys may be used for unlocking LUKS2 volumes wherever
|
|
passphrases are accepted. They are intended to be used in combination with an enrolled hardware
|
|
security token, as a recovery option when the token is lost.</para></listitem>
|
|
</orderedlist>
|
|
|
|
<para>In addition, the tool may be used to enumerate currently enrolled security tokens and wipe a subset
|
|
of them. The latter may be combined with the enrollment operation of a new security token, in order to
|
|
update or replace enrollments.</para>
|
|
|
|
<para>The tool supports only LUKS2 volumes, as it stores token meta-information in the LUKS2 JSON token
|
|
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>
|
|
|
|
<para>The following options are understood:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><option>--password</option></term>
|
|
|
|
<listitem><para>Enroll a regular password/passphrase. This command is mostly equivalent to
|
|
<command>cryptsetup luksAddKey</command>, however may be combined with
|
|
<option>--wipe-slot=</option> in one call, see below.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--recovery-key</option></term>
|
|
|
|
<listitem><para>Enroll a recovery key. Recovery keys are mostly identical to passphrases, but are
|
|
computer-generated instead of being chosen by a human, and thus have a guaranteed high entropy. The
|
|
key uses a character set that is easy to type in, and may be scanned off screen via a QR code.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--pkcs11-token-uri=</option><replaceable>URI</replaceable></term>
|
|
|
|
<listitem><para>Enroll a PKCS#11 security token or smartcard (e.g. a YubiKey). Expects a PKCS#11
|
|
smartcard URI referring to the token. Alternatively the special value <literal>auto</literal> may
|
|
be specified, in order to automatically determine the URI of a currently plugged in security token
|
|
(of which there must be exactly one). The special value <literal>list</literal> may be used to
|
|
enumerate all suitable PKCS#11 tokens currently plugged in. The security token must contain an RSA
|
|
key pair which is used to encrypt the randomly generated key that is used to unlock the LUKS2
|
|
volume. The encrypted key is then stored in the LUKS2 JSON token header area.</para>
|
|
|
|
<para>In order to unlock a LUKS2 volume with an enrolled PKCS#11 security token, specify the
|
|
<option>pkcs11-uri=</option> option in the respective <filename>/etc/crypttab</filename> line:</para>
|
|
|
|
<programlisting>myvolume /dev/sda1 - pkcs11-uri=auto</programlisting>
|
|
|
|
<para>See
|
|
<citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
|
|
more comprehensive example of a <command>systemd-cryptenroll</command> invocation and its matching
|
|
<filename>/etc/crypttab</filename> line.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--fido2-device=</option><replaceable>PATH</replaceable></term>
|
|
|
|
<listitem><para>Enroll a FIDO2 security token that implements the <literal>hmac-secret</literal>
|
|
extension (e.g. a YubiKey). Expects a <filename>hidraw</filename> device referring to the FIDO2
|
|
device (e.g. <filename>/dev/hidraw1</filename>). Alternatively the special value
|
|
<literal>auto</literal> may be specified, in order to automatically determine the device node of a
|
|
currently plugged in security token (of which there must be exactly one). The special value
|
|
<literal>list</literal> may be used to enumerate all suitable FIDO2 tokens currently plugged in. Note
|
|
that many hardware security tokens that implement FIDO2 also implement the older PKCS#11
|
|
standard. Typically FIDO2 is preferable, given it's simpler to use and more modern.</para>
|
|
|
|
<para>In order to unlock a LUKS2 volume with an enrolled FIDO2 security token, specify the
|
|
<option>fido2-device=</option> option in the respective <filename>/etc/crypttab</filename> line:</para>
|
|
|
|
<programlisting>myvolume /dev/sda1 - fido2-device=auto</programlisting>
|
|
|
|
<para>See
|
|
<citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
|
|
more comprehensive example of a <command>systemd-cryptenroll</command> invocation and its matching
|
|
<filename>/etc/crypttab</filename> line.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--fido2-with-client-pin=</option><replaceable>BOOL</replaceable></term>
|
|
|
|
<listitem><para>When enrolling a FIDO2 security token, controls whether to require the user to enter
|
|
a PIN when unlocking the volume (the FIDO2 <literal>clientPin</literal> feature). Defaults to
|
|
<literal>yes</literal>. (Note: this setting is without effect if the security token does not support
|
|
the <literal>clientPin</literal> feature at all, or does not allow enabling or disabling
|
|
it.)</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--fido2-with-user-presence=</option><replaceable>BOOL</replaceable></term>
|
|
|
|
<listitem><para>When enrolling a FIDO2 security token, controls whether to require the user to
|
|
verify presence (tap the token, the FIDO2 <literal>up</literal> feature) when unlocking the volume.
|
|
Defaults to <literal>yes</literal>. (Note: this setting is without effect if the security token does not support
|
|
the <literal>up</literal> feature at all, or does not allow enabling or disabling it.)
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--fido2-with-user-verification=</option><replaceable>BOOL</replaceable></term>
|
|
|
|
<listitem><para>When enrolling a FIDO2 security token, controls whether to require user verification
|
|
when unlocking the volume (the FIDO2 <literal>uv</literal> feature). Defaults to
|
|
<literal>no</literal>. (Note: this setting is without effect if the security token does not support
|
|
the <literal>uv</literal> feature at all, or does not allow enabling or disabling it.)</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--tpm2-device=</option><replaceable>PATH</replaceable></term>
|
|
|
|
<listitem><para>Enroll a TPM2 security chip. Expects a device node path referring to the TPM2 chip
|
|
(e.g. <filename>/dev/tpmrm0</filename>). Alternatively the special value <literal>auto</literal> may
|
|
be specified, in order to automatically determine the device node of a currently discovered TPM2
|
|
device (of which there must be exactly one). The special value <literal>list</literal> may be used to
|
|
enumerate all suitable TPM2 devices currently discovered.</para>
|
|
|
|
<para>In order to unlock a LUKS2 volume with an enrolled TPM2 security chip, specify the
|
|
<option>tpm2-device=</option> option in the respective <filename>/etc/crypttab</filename> line:</para>
|
|
|
|
<programlisting>myvolume /dev/sda1 - tpm2-device=auto</programlisting>
|
|
|
|
<para>See
|
|
<citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
|
|
more comprehensive example of a <command>systemd-cryptenroll</command> invocation and its matching
|
|
<filename>/etc/crypttab</filename> line.</para>
|
|
|
|
<para>Use <option>--tpm2-pcrs=</option> (see below) to configure which TPM2 PCR indexes to bind the
|
|
enrollment to.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--tpm2-pcrs=</option><arg rep="repeat">PCR</arg></term>
|
|
|
|
<listitem><para>Configures the TPM2 PCRs (Platform Configuration Registers) to bind the enrollment
|
|
requested via <option>--tpm2-device=</option> to. Takes a <literal>+</literal> separated list of
|
|
numeric PCR indexes in the range 0…23. If not used, defaults to PCR 7 only. If an empty string is
|
|
specified, binds the enrollment to no PCRs at all. PCRs allow binding the enrollment to specific
|
|
software versions and system state, so that the enrolled unlocking key is only accessible (may be
|
|
"unsealed") if specific trusted software and/or configuration is used.</para>
|
|
|
|
<table>
|
|
<title>Well-known PCR Definitions</title>
|
|
|
|
<!-- See: https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/ -->
|
|
<!-- See: https://github.com/rhboot/shim/blob/main/README.tpm -->
|
|
<!-- See: https://www.gnu.org/software/grub/manual/grub/html_node/Measured-Boot.html -->
|
|
<!-- See: https://sourceforge.net/p/linux-ima/wiki/Home/ -->
|
|
|
|
<tgroup cols='2' align='left' colsep='1' rowsep='1'>
|
|
<colspec colname="pcr" />
|
|
<colspec colname="definition" />
|
|
|
|
<thead>
|
|
<row>
|
|
<entry>PCR</entry>
|
|
<entry>Explanation</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>0</entry>
|
|
<entry>Core system firmware executable code; changes on firmware updates</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1</entry>
|
|
<entry>Core system firmware data/host platform configuration; typically contains serial and model numbers, changes on basic hardware/CPU/RAM replacements</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>2</entry>
|
|
<entry>Extended or pluggable executable code; includes option ROMs on pluggable hardware</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>3</entry>
|
|
<entry>Extended or pluggable firmware data; includes information about pluggable hardware</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>4</entry>
|
|
<entry>Boot loader; changes on boot loader updates. The shim project will measure the PE binary it chain loads into this PCR.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>5</entry>
|
|
<entry>GPT/Partition table; changes when the partitions are added, modified or removed</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>6</entry>
|
|
<entry>Power state events; changes on system suspend/sleep</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>7</entry>
|
|
<entry>Secure boot state; changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) changes. The shim project will measure most of its (non-MOK) certificates and SBAT data into this PCR.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>8</entry>
|
|
<entry><citerefentry><refentrytitle>sd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures the kernel command line into this PCR.</entry>
|
|
<!-- Grub measures all its commands and the kernel command line into PCR 8 too… -->
|
|
</row>
|
|
|
|
<!-- Grub measures all files it reads (including kernel image, initrd, …) into PCR 9… -->
|
|
|
|
<row>
|
|
<entry>10</entry>
|
|
<entry>The IMA project measures its runtime state into this PCR.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>14</entry>
|
|
<entry>The shim project measures its "MOK" certificates and hashes into this PCR.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>For most applications it should be sufficient to bind against PCR 7 (and possibly PCR 14, if
|
|
shim/MOK is desired), as this includes measurements of the trusted certificates (and possibly hashes)
|
|
that are used to validate all components of the boot process up to and including the OS kernel. In
|
|
order to simplify firmware and OS version updates it's typically not advisable to include PCRs such
|
|
as 0 and 2 in the binding of the enrollment, since the program code they cover should already be
|
|
protected indirectly through the certificates measured into PCR 7. Validation through these
|
|
certificates is typically preferable over validation through direct measurements as it is less
|
|
brittle in context of OS/firmware updates: the measurements will change on every update, but code
|
|
signatures likely will validate against pre-existing certificates.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--wipe-slot=</option><arg rep="repeat">SLOT</arg></term>
|
|
|
|
<listitem><para>Wipes one or more LUKS2 key slots. Takes a comma separated list of numeric slot
|
|
indexes, or the special strings <literal>all</literal> (for wiping all key slots),
|
|
<literal>empty</literal> (for wiping all key slots that are unlocked by an empty passphrase),
|
|
<literal>password</literal> (for wiping all key slots that are unlocked by a traditional passphrase),
|
|
<literal>recovery</literal> (for wiping all key slots that are unlocked by a recovery key),
|
|
<literal>pkcs11</literal> (for wiping all key slots that are unlocked by a PKCS#11 token),
|
|
<literal>fido2</literal> (for wiping all key slots that are unlocked by a FIDO2 token),
|
|
<literal>tpm2</literal> (for wiping all key slots that are unlocked by a TPM2 chip), or any
|
|
combination of these strings or numeric indexes, in which case all slots matching either are
|
|
wiped. As safety precaution an operation that wipes all slots without exception (so that the volume
|
|
cannot be unlocked at all anymore, unless the volume key is known) is refused.</para>
|
|
|
|
<para>This switch may be used alone, in which case only the requested wipe operation is executed. It
|
|
may also be used in combination with any of the enrollment options listed above, in which case the
|
|
enrollment is completed first, and only when successful the wipe operation executed — and the newly
|
|
added slot is always excluded from the wiping. Combining enrollment and slot wiping may thus be used to
|
|
update existing enrollments:</para>
|
|
|
|
<programlisting>systemd-cryptenroll /dev/sda1 --wipe-slot=tpm2 --tpm2-device=auto</programlisting>
|
|
|
|
<para>The above command will enroll the TPM2 chip, and then wipe all previously created TPM2
|
|
enrollments on the LUKS2 volume, leaving only the newly created one. Combining wiping and enrollment
|
|
may also be used to replace enrollments of different types, for example for changing from a PKCS#11
|
|
enrollment to a FIDO2 one:</para>
|
|
|
|
<programlisting>systemd-cryptenroll /dev/sda1 --wipe-slot=pkcs11 --fido2-device=auto</programlisting>
|
|
|
|
<para>Or for replacing an enrolled empty password by TPM2:</para>
|
|
|
|
<programlisting>systemd-cryptenroll /dev/sda1 --wipe-slot=empty --tpm2-device=auto</programlisting>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<xi:include href="standard-options.xml" xpointer="help" />
|
|
<xi:include href="standard-options.xml" xpointer="version" />
|
|
</variablelist>
|
|
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Exit status</title>
|
|
|
|
<para>On success, 0 is returned, a non-zero failure code otherwise.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
<para>
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|