]>
Commit | Line | Data |
---|---|---|
cf1e172d LP |
1 | <?xml version="1.0"?> |
2 | <!--*-nxml-*--> | |
3 | <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" | |
eea10b26 | 4 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> |
cf1e172d LP |
5 | <!-- SPDX-License-Identifier: LGPL-2.1-or-later --> |
6 | <refentry id="systemd-cryptenroll" xmlns:xi="http://www.w3.org/2001/XInclude" conditional='HAVE_LIBCRYPTSETUP'> | |
7 | ||
8 | <refentryinfo> | |
9 | <title>systemd-cryptenroll</title> | |
10 | <productname>systemd</productname> | |
11 | </refentryinfo> | |
12 | ||
13 | <refmeta> | |
14 | <refentrytitle>systemd-cryptenroll</refentrytitle> | |
15 | <manvolnum>1</manvolnum> | |
16 | </refmeta> | |
17 | ||
18 | <refnamediv> | |
19 | <refname>systemd-cryptenroll</refname> | |
20 | <refpurpose>Enroll PKCS#11, FIDO2, TPM2 token/devices to LUKS2 encrypted volumes</refpurpose> | |
21 | </refnamediv> | |
22 | ||
23 | <refsynopsisdiv> | |
24 | <cmdsynopsis> | |
38e3c61d ZJS |
25 | <command>systemd-cryptenroll</command> |
26 | <arg choice="opt" rep="repeat">OPTIONS</arg> | |
27 | <arg choice="opt">DEVICE</arg> | |
cf1e172d LP |
28 | </cmdsynopsis> |
29 | </refsynopsisdiv> | |
30 | ||
31 | <refsect1> | |
32 | <title>Description</title> | |
33 | ||
880e1e07 ZJS |
34 | <para><command>systemd-cryptenroll</command> is a tool for enrolling hardware security tokens and devices |
35 | into a LUKS2 encrypted volume, which may then be used to unlock the volume during boot. Specifically, it | |
36 | supports tokens and credentials of the following kind to be enrolled:</para> | |
cf1e172d LP |
37 | |
38 | <orderedlist> | |
3d05c058 VS |
39 | <listitem><para>PKCS#11 security tokens and smartcards that may carry an RSA or EC key pair (e.g. |
40 | various YubiKeys)</para></listitem> | |
cf1e172d | 41 | |
880e1e07 ZJS |
42 | <listitem><para>FIDO2 security tokens that implement the <literal>hmac-secret</literal> extension (most |
43 | FIDO2 keys, including YubiKeys)</para></listitem> | |
cf1e172d LP |
44 | |
45 | <listitem><para>TPM2 security devices</para></listitem> | |
46 | ||
a587a16a ZJS |
47 | <listitem><para>Regular passphrases</para></listitem> |
48 | ||
cf1e172d | 49 | <listitem><para>Recovery keys. These are similar to regular passphrases, however are randomly generated |
880e1e07 | 50 | on the computer and thus generally have higher entropy than user-chosen passphrases. Their character |
cf1e172d LP |
51 | set has been designed to ensure they are easy to type in, while having high entropy. They may also be |
52 | scanned off screen using QR codes. Recovery keys may be used for unlocking LUKS2 volumes wherever | |
53 | passphrases are accepted. They are intended to be used in combination with an enrolled hardware | |
54 | security token, as a recovery option when the token is lost.</para></listitem> | |
cf1e172d LP |
55 | </orderedlist> |
56 | ||
57 | <para>In addition, the tool may be used to enumerate currently enrolled security tokens and wipe a subset | |
58 | of them. The latter may be combined with the enrollment operation of a new security token, in order to | |
59 | update or replace enrollments.</para> | |
60 | ||
61 | <para>The tool supports only LUKS2 volumes, as it stores token meta-information in the LUKS2 JSON token | |
62 | area, which is not available in other encryption formats.</para> | |
10fa7251 | 63 | |
8518f4a8 LP |
64 | <para><command>systemd-cryptsetup</command> operates on the device backing <filename>/var/</filename> if |
65 | no device is specified explicitly, and no wipe operation is requested. (Note that in the typical case | |
66 | where <filename>/var/</filename> is on the same file system as the root file system, this hence enrolls a | |
67 | key into the backing device of the root file system.)</para> | |
1df4b21a | 68 | |
10fa7251 ZJS |
69 | <refsect2> |
70 | <title>TPM2 PCRs and policies</title> | |
71 | ||
72 | <para>PCRs allow binding of the encryption of secrets to specific software versions and system state, | |
73 | so that the enrolled key is only accessible (may be "unsealed") if specific trusted software and/or | |
74 | configuration is used. Such bindings may be created with the option <option>--tpm2-pcrs=</option> | |
75 | described below.</para> | |
76 | ||
77 | <para>Secrets may also be bound indirectly: a signed policy for a state of some combination of PCR | |
78 | values is provided, and the secret is bound to the public part of the key used to sign this policy. | |
79 | This means that the owner of a key can generate a sequence of signed policies, for specific software | |
80 | versions and system states, and the secret can be decrypted as long as the machine state matches one of | |
81 | those policies. For example, a vendor may provide such a policy for each kernel+initrd update, allowing | |
82 | users to encrypt secrets so that they can be decrypted when running any kernel+initrd signed by the | |
83 | vendor. Such bindings may be created with the options <option>--tpm2-public-key=</option>, | |
84 | <option>--tpm2-public-key-pcrs=</option>, <option>--tpm2-signature=</option> described below. | |
85 | </para> | |
86 | ||
87 | <para>See <ulink url="https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/">Linux TPM | |
88 | PCR Registry</ulink> for an authoritative list of PCRs and how they are updated. The table below | |
89 | contains a quick reference, describing in particular the PCRs modified by systemd.</para> | |
90 | ||
91 | <table> | |
92 | <title>Well-known PCR Definitions</title> | |
93 | ||
94 | <!-- See: https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/ --> | |
95 | <!-- See: https://github.com/rhboot/shim/blob/main/README.tpm --> | |
96 | <!-- See: https://www.gnu.org/software/grub/manual/grub/html_node/Measured-Boot.html --> | |
97 | <!-- See: https://sourceforge.net/p/linux-ima/wiki/Home/ --> | |
98 | <!-- See: https://github.com/tianocore-docs/edk2-TrustedBootChain/blob/main/4_Other_Trusted_Boot_Chains.md --> | |
99 | <!-- See: https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers --> | |
100 | ||
101 | <tgroup cols='3' align='left' colsep='1' rowsep='1'> | |
102 | <colspec colname="pcr" /> | |
103 | <colspec colname="name" /> | |
104 | <colspec colname="definition" /> | |
105 | ||
106 | <thead> | |
107 | <row> | |
108 | <entry>PCR</entry> | |
109 | <entry>name</entry> | |
110 | <entry>Explanation</entry> | |
111 | </row> | |
112 | </thead> | |
113 | ||
114 | <tbody> | |
115 | <row> | |
116 | <entry>0</entry> | |
117 | <entry>platform-code</entry> | |
118 | <entry>Core system firmware executable code; changes on firmware updates</entry> | |
119 | </row> | |
120 | ||
121 | <row> | |
122 | <entry>1</entry> | |
123 | <entry>platform-config</entry> | |
124 | <entry>Core system firmware data/host platform configuration; typically contains serial and model numbers, changes on basic hardware/CPU/RAM replacements</entry> | |
125 | </row> | |
126 | ||
127 | <row> | |
128 | <entry>2</entry> | |
129 | <entry>external-code</entry> | |
130 | <entry>Extended or pluggable executable code; includes option ROMs on pluggable hardware</entry> | |
131 | </row> | |
132 | ||
133 | <row> | |
134 | <entry>3</entry> | |
135 | <entry>external-config</entry> | |
136 | <entry>Extended or pluggable firmware data; includes information about pluggable hardware</entry> | |
137 | </row> | |
138 | ||
139 | <row> | |
140 | <entry>4</entry> | |
141 | <entry>boot-loader-code</entry> | |
142 | <entry>Boot loader and additional drivers, PE binaries invoked by the boot loader; changes on boot loader updates. <citerefentry><refentrytitle>sd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures system extension images read from the ESP here too (see <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry>).</entry> | |
143 | </row> | |
144 | ||
145 | <row> | |
146 | <entry>5</entry> | |
147 | <entry>boot-loader-config</entry> | |
148 | <entry>GPT/Partition table; changes when the partitions are added, modified, or removed</entry> | |
149 | </row> | |
150 | ||
151 | <row> | |
152 | <entry>7</entry> | |
153 | <entry>secure-boot-policy</entry> | |
154 | <entry>Secure Boot state; changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) changes.</entry> | |
155 | </row> | |
156 | ||
157 | <row> | |
158 | <entry>9</entry> | |
159 | <entry>kernel-initrd</entry> | |
160 | <entry>The Linux kernel measures all initrds it receives into this PCR.</entry> | |
161 | <!-- Strictly speaking only Linux >= 5.17 using the LOAD_FILE2 protocol, see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f046fff8bc4c4d8f8a478022e76e40b818f692df --> | |
162 | </row> | |
163 | ||
164 | <row> | |
165 | <entry>10</entry> | |
166 | <entry>ima</entry> | |
167 | <entry>The IMA project measures its runtime state into this PCR.</entry> | |
168 | </row> | |
169 | ||
170 | <row> | |
171 | <entry>11</entry> | |
172 | <entry>kernel-boot</entry> | |
173 | <entry><citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures the ELF kernel image, embedded initrd and other payload of the PE image it is placed in into this PCR. <citerefentry><refentrytitle>systemd-pcrphase.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> measures boot phase strings into this PCR at various milestones of the boot process.</entry> | |
174 | </row> | |
175 | ||
176 | <row> | |
177 | <entry>12</entry> | |
178 | <entry>kernel-config</entry> | |
179 | <entry><citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures the kernel command line into this PCR. <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures any manually specified kernel command line (i.e. a kernel command line that overrides the one embedded in the unified PE image) and loaded credentials into this PCR.</entry> | |
180 | </row> | |
181 | ||
182 | <row> | |
183 | <entry>13</entry> | |
184 | <entry>sysexts</entry> | |
185 | <entry><citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures any <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry> images it passes to the booted kernel into this PCR.</entry> | |
186 | </row> | |
187 | ||
188 | <row> | |
189 | <entry>14</entry> | |
190 | <entry>shim-policy</entry> | |
191 | <entry>The shim project measures its "MOK" certificates and hashes into this PCR.</entry> | |
192 | </row> | |
193 | ||
194 | <row> | |
195 | <entry>15</entry> | |
196 | <entry>system-identity</entry> | |
94d82b59 | 197 | <entry><citerefentry><refentrytitle>systemd-cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> optionally measures the volume key of activated LUKS volumes into this PCR. <citerefentry><refentrytitle>systemd-pcrmachine.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> measures the <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> into this PCR. <citerefentry><refentrytitle>systemd-pcrfs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> measures mount points, file system UUIDs, labels, partition UUIDs of the root and <filename>/var/</filename> filesystems into this PCR.</entry> |
10fa7251 ZJS |
198 | </row> |
199 | ||
200 | <row> | |
201 | <entry>16</entry> | |
202 | <entry>debug</entry> | |
203 | <entry>Debug</entry> | |
204 | </row> | |
205 | ||
206 | <row> | |
207 | <entry>23</entry> | |
208 | <entry>application-support</entry> | |
209 | <entry>Application Support</entry> | |
210 | </row> | |
211 | </tbody> | |
212 | </tgroup> | |
213 | </table> | |
214 | ||
215 | <para>In general, encrypted volumes would be bound to some combination of PCRs 7, 11, and 14 (if | |
216 | shim/MOK is used). In order to allow firmware and OS version updates, it is typically not advisable to | |
217 | use PCRs such as 0 and 2, since the program code they cover should already be covered indirectly | |
218 | through the certificates measured into PCR 7. Validation through certificates hashes is typically | |
219 | preferable over validation through direct measurements as it is less brittle in context of OS/firmware | |
220 | updates: the measurements will change on every update, but signatures should remain unchanged. See the | |
221 | <ulink url="https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/">Linux TPM PCR | |
222 | Registry</ulink> for more discussion.</para> | |
223 | </refsect2> | |
cf1e172d | 224 | </refsect1> |
0bada3f8 LP |
225 | |
226 | <refsect1> | |
227 | <title>Limitations</title> | |
228 | ||
229 | <para>Note that currently when enrolling a new key of one of the five supported types listed above, it is | |
631cf7f0 GAP |
230 | required to first provide a passphrase, a recovery key, a FIDO2 token, or a TPM2 key. It's currently not |
231 | supported to unlock a device with a PKCS#11 key in order to enroll a new PKCS#11 key. Thus, if in future | |
232 | key roll-over is desired it's generally recommended to ensure a passphrase, a recovery key, a FIDO2 | |
233 | token, or a TPM2 key is always enrolled.</para> | |
820c66dc PC |
234 | |
235 | <para>Also note that support for enrolling multiple FIDO2 tokens is currently limited. When multiple FIDO2 | |
1df4b21a | 236 | tokens are enrolled, <command>systemd-cryptsetup</command> will perform pre-flight requests to attempt to |
820c66dc PC |
237 | identify which of the enrolled tokens are currently plugged in. However, this is not possible for FIDO2 |
238 | tokens with user verification (UV, usually via biometrics), in which case it will fall back to attempting | |
239 | each enrolled token one by one. This will result in multiple prompts for PIN and user verification. This | |
240 | limitation does not apply to PKCS#11 tokens.</para> | |
0bada3f8 | 241 | </refsect1> |
cf1e172d | 242 | |
24410187 LP |
243 | <refsect1> |
244 | <title>Compatibility</title> | |
245 | ||
246 | <para>Security technology both in systemd and in the general industry constantly evolves. In order to | |
247 | provide best security guarantees, the way TPM2, FIDO2, PKCS#11 devices are enrolled is regularly updated | |
248 | in newer versions of systemd. Whenever this happens the following compatibility guarantees are given:</para> | |
249 | ||
250 | <itemizedlist> | |
251 | <listitem><para>Old enrollments continue to be supported and may be unlocked with newer versions of | |
252 | <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem> | |
253 | ||
254 | <listitem><para>The opposite is not guaranteed however: it might not be possible to unlock volumes with | |
255 | enrollments done with a newer version of <command>systemd-cryptenroll</command> with an older version | |
256 | of <command>systemd-cryptsetup</command>.</para></listitem> | |
257 | </itemizedlist> | |
258 | ||
259 | <para>That said, it is generally recommended to use matching versions of | |
260 | <command>systemd-cryptenroll</command> and <command>systemd-cryptsetup</command>, since this is best | |
261 | tested and supported.</para> | |
262 | ||
263 | <para>It might be advisable to re-enroll existing enrollments to take benefit of newer security features, | |
264 | as they are added to systemd.</para> | |
265 | </refsect1> | |
266 | ||
cf1e172d LP |
267 | <refsect1> |
268 | <title>Options</title> | |
269 | ||
270 | <para>The following options are understood:</para> | |
271 | ||
272 | <variablelist> | |
273 | <varlistentry> | |
274 | <term><option>--password</option></term> | |
275 | ||
276 | <listitem><para>Enroll a regular password/passphrase. This command is mostly equivalent to | |
277 | <command>cryptsetup luksAddKey</command>, however may be combined with | |
ec07c3c8 AK |
278 | <option>--wipe-slot=</option> in one call, see below.</para> |
279 | ||
280 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
cf1e172d LP |
281 | </varlistentry> |
282 | ||
283 | <varlistentry> | |
284 | <term><option>--recovery-key</option></term> | |
285 | ||
880e1e07 ZJS |
286 | <listitem><para>Enroll a recovery key. Recovery keys are mostly identical to passphrases, but are |
287 | computer-generated instead of being chosen by a human, and thus have a guaranteed high entropy. The | |
288 | key uses a character set that is easy to type in, and may be scanned off screen via a QR code. | |
ec07c3c8 AK |
289 | </para> |
290 | ||
291 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
cf1e172d LP |
292 | </varlistentry> |
293 | ||
1f419024 | 294 | <varlistentry> |
9bfabe14 | 295 | <term><option>--unlock-key-file=<replaceable>PATH</replaceable></option></term> |
1f419024 J |
296 | |
297 | <listitem><para>Use a file instead of a password/passphrase read from stdin to unlock the volume. | |
298 | Expects the PATH to the file containing your key to unlock the volume. Currently there is nothing like | |
299 | <option>--key-file-offset=</option> or <option>--key-file-size=</option> so this file has to only | |
ec07c3c8 AK |
300 | contain the full key.</para> |
301 | ||
302 | <xi:include href="version-info.xml" xpointer="v252"/></listitem> | |
1f419024 J |
303 | </varlistentry> |
304 | ||
d8c5bd04 | 305 | <varlistentry> |
9bfabe14 | 306 | <term><option>--unlock-fido2-device=<replaceable>PATH</replaceable></option></term> |
d8c5bd04 AAF |
307 | |
308 | <listitem><para>Use a FIDO2 device instead of a password/passphrase read from stdin to unlock the | |
309 | volume. Expects a <filename>hidraw</filename> device referring to the FIDO2 device (e.g. | |
310 | <filename>/dev/hidraw1</filename>). Alternatively the special value <literal>auto</literal> may be | |
311 | specified, in order to automatically determine the device node of a currently plugged in security | |
312 | token (of which there must be exactly one). This automatic discovery is unsupported if | |
e262205e KS |
313 | <option>--fido2-device=</option> option is also specified. Note that currently FIDO2 devices |
314 | enrolled without an accompanying LUKS2 token (i.e. <option>--fido2-parameters-in-header=no</option>) | |
315 | cannot be used for unlocking.</para> | |
ec07c3c8 AK |
316 | |
317 | <xi:include href="version-info.xml" xpointer="v253"/></listitem> | |
d8c5bd04 AAF |
318 | </varlistentry> |
319 | ||
631cf7f0 | 320 | <varlistentry> |
9bfabe14 | 321 | <term><option>--unlock-tpm2-device=<replaceable>PATH</replaceable></option></term> |
631cf7f0 | 322 | |
d2eb27eb | 323 | <listitem><para>Use a TPM2 device instead of a password/passhprase read from stdin to unlock the |
631cf7f0 GAP |
324 | volume. Expects a device node path referring to the TPM2 chip (e.g. <filename>/dev/tpmrm0</filename>). |
325 | Alternatively the special value <literal>auto</literal> may be specified, in order to automatically | |
326 | determine the device node of a currently discovered TPM2 device (of which there must be exactly one). | |
327 | </para> | |
328 | ||
329 | <xi:include href="version-info.xml" xpointer="v256"/></listitem> | |
330 | </varlistentry> | |
331 | ||
cf1e172d | 332 | <varlistentry> |
9bfabe14 | 333 | <term><option>--pkcs11-token-uri=<replaceable>URI</replaceable></option></term> |
cf1e172d | 334 | |
85828ef9 | 335 | <listitem><para>Enroll a PKCS#11 security token or smartcard (e.g. a YubiKey). Expects a PKCS#11 URI |
93df5217 | 336 | that allows finding an X.509 certificate or a public key on the token. The URI must also be suitable |
85686b37 VS |
337 | to find a related private key after changing the type of object in it. Alternatively the special |
338 | value <literal>auto</literal> may be specified, in order to automatically determine the suitable URI | |
339 | if a single security token containing a single key pair is plugged in. The special value | |
85828ef9 VS |
340 | <literal>list</literal> may be used to enumerate all suitable PKCS#11 tokens currently plugged in. |
341 | </para> | |
3d05c058 VS |
342 | |
343 | <para>The PKCS#11 token must contain an RSA or EC key pair which will be used to unlock a LUKS2 volume. | |
344 | For RSA, a randomly generated volume key is encrypted with a public key in the token, and stored in | |
345 | the LUKS2 JSON token header area. To unlock a volume, the stored encrypted volume key will be decrypted | |
346 | with a private key in the token. For ECC, ECDH algorithm is used: we generate a pair of EC keys in | |
347 | the same EC group, then derive a shared secret using the generated private key and the public key | |
348 | in the token. The derived shared secret is used as a volume key. The generated public key is | |
349 | stored in the LUKS2 JSON token header area. The generated private key is erased. To unlock a volume, | |
350 | we derive the shared secret with the stored public key and a private key in the token.</para> | |
cf1e172d LP |
351 | |
352 | <para>In order to unlock a LUKS2 volume with an enrolled PKCS#11 security token, specify the | |
353 | <option>pkcs11-uri=</option> option in the respective <filename>/etc/crypttab</filename> line:</para> | |
354 | ||
355 | <programlisting>myvolume /dev/sda1 - pkcs11-uri=auto</programlisting> | |
356 | ||
357 | <para>See | |
358 | <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a | |
359 | more comprehensive example of a <command>systemd-cryptenroll</command> invocation and its matching | |
ec07c3c8 AK |
360 | <filename>/etc/crypttab</filename> line.</para> |
361 | ||
362 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
cf1e172d LP |
363 | </varlistentry> |
364 | ||
70e723c0 | 365 | <varlistentry> |
9bfabe14 | 366 | <term><option>--fido2-credential-algorithm=<replaceable>STRING</replaceable></option></term> |
70e723c0 M |
367 | <listitem><para>Specify COSE algorithm used in credential generation. The default value is |
368 | <literal>es256</literal>. Supported values are <literal>es256</literal>, <literal>rs256</literal> | |
369 | and <literal>eddsa</literal>.</para> | |
370 | ||
371 | <para><literal>es256</literal> denotes ECDSA over NIST P-256 with SHA-256. <literal>rs256</literal> | |
372 | denotes 2048-bit RSA with PKCS#1.5 padding and SHA-256. <literal>eddsa</literal> denotes | |
373 | EDDSA over Curve25519 with SHA-512.</para> | |
374 | ||
566491c9 | 375 | <para>Note that your authenticator may choose not to support some algorithms.</para> |
ec07c3c8 AK |
376 | |
377 | <xi:include href="version-info.xml" xpointer="v251"/></listitem> | |
70e723c0 M |
378 | </varlistentry> |
379 | ||
cf1e172d | 380 | <varlistentry> |
9bfabe14 | 381 | <term><option>--fido2-device=<replaceable>PATH</replaceable></option></term> |
cf1e172d LP |
382 | |
383 | <listitem><para>Enroll a FIDO2 security token that implements the <literal>hmac-secret</literal> | |
384 | extension (e.g. a YubiKey). Expects a <filename>hidraw</filename> device referring to the FIDO2 | |
385 | device (e.g. <filename>/dev/hidraw1</filename>). Alternatively the special value | |
386 | <literal>auto</literal> may be specified, in order to automatically determine the device node of a | |
d8c5bd04 AAF |
387 | currently plugged in security token (of which there must be exactly one). This automatic discovery |
388 | is unsupported if <option>--unlock-fido2-device=</option> option is also specified. The special value | |
cf1e172d LP |
389 | <literal>list</literal> may be used to enumerate all suitable FIDO2 tokens currently plugged in. Note |
390 | that many hardware security tokens that implement FIDO2 also implement the older PKCS#11 | |
391 | standard. Typically FIDO2 is preferable, given it's simpler to use and more modern.</para> | |
392 | ||
393 | <para>In order to unlock a LUKS2 volume with an enrolled FIDO2 security token, specify the | |
394 | <option>fido2-device=</option> option in the respective <filename>/etc/crypttab</filename> line:</para> | |
395 | ||
396 | <programlisting>myvolume /dev/sda1 - fido2-device=auto</programlisting> | |
397 | ||
398 | <para>See | |
399 | <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a | |
400 | more comprehensive example of a <command>systemd-cryptenroll</command> invocation and its matching | |
ec07c3c8 AK |
401 | <filename>/etc/crypttab</filename> line.</para> |
402 | ||
403 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
cf1e172d LP |
404 | </varlistentry> |
405 | ||
e262205e KS |
406 | <varlistentry> |
407 | <term><option>--fido2-salt-file=<replaceable>PATH</replaceable></option></term> | |
408 | ||
409 | <listitem><para>When enrolling a FIDO2 security token, specifies the path to a file or an | |
410 | <constant>AF_UNIX</constant> socket from which we should read the salt value to be used in the | |
411 | HMAC operation performed by the FIDO2 security token. If this option is not specified, the salt | |
412 | will be randomly generated.</para> | |
413 | ||
414 | <xi:include href="version-info.xml" xpointer="v257"/></listitem> | |
415 | </varlistentry> | |
416 | ||
417 | <varlistentry> | |
418 | <term><option>--fido2-parameters-in-header=<replaceable>BOOL</replaceable></option></term> | |
419 | ||
420 | <listitem><para>When enrolling a FIDO2 security token, controls whether to store FIDO2 | |
421 | parameters in a token in the LUKS2 superblock. Defaults to <literal>yes</literal>. | |
422 | If set to <literal>no</literal>, the <option>fido2-cid=</option> option has to be specified manually | |
423 | in the respective <filename>/etc/crypttab</filename> line along with a key file. See | |
424 | <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> | |
425 | for details.</para> | |
426 | ||
427 | <xi:include href="version-info.xml" xpointer="v257"/></listitem> | |
428 | </varlistentry> | |
429 | ||
cde2f860 | 430 | <varlistentry> |
9bfabe14 | 431 | <term><option>--fido2-with-client-pin=<replaceable>BOOL</replaceable></option></term> |
cde2f860 | 432 | |
72c15422 LP |
433 | <listitem><para>When enrolling a FIDO2 security token, controls whether to require the user to enter |
434 | a PIN when unlocking the volume (the FIDO2 <literal>clientPin</literal> feature). Defaults to | |
435 | <literal>yes</literal>. (Note: this setting is without effect if the security token does not support | |
436 | the <literal>clientPin</literal> feature at all, or does not allow enabling or disabling | |
ec07c3c8 AK |
437 | it.)</para> |
438 | ||
439 | <xi:include href="version-info.xml" xpointer="v249"/></listitem> | |
cde2f860 LB |
440 | </varlistentry> |
441 | ||
06f08719 | 442 | <varlistentry> |
9bfabe14 | 443 | <term><option>--fido2-with-user-presence=<replaceable>BOOL</replaceable></option></term> |
06f08719 LB |
444 | |
445 | <listitem><para>When enrolling a FIDO2 security token, controls whether to require the user to | |
446 | verify presence (tap the token, the FIDO2 <literal>up</literal> feature) when unlocking the volume. | |
72c15422 LP |
447 | Defaults to <literal>yes</literal>. (Note: this setting is without effect if the security token does not support |
448 | the <literal>up</literal> feature at all, or does not allow enabling or disabling it.) | |
ec07c3c8 AK |
449 | </para> |
450 | ||
451 | <xi:include href="version-info.xml" xpointer="v249"/></listitem> | |
06f08719 LB |
452 | </varlistentry> |
453 | ||
896cc0da | 454 | <varlistentry> |
9bfabe14 | 455 | <term><option>--fido2-with-user-verification=<replaceable>BOOL</replaceable></option></term> |
896cc0da LB |
456 | |
457 | <listitem><para>When enrolling a FIDO2 security token, controls whether to require user verification | |
72c15422 LP |
458 | when unlocking the volume (the FIDO2 <literal>uv</literal> feature). Defaults to |
459 | <literal>no</literal>. (Note: this setting is without effect if the security token does not support | |
ec07c3c8 AK |
460 | the <literal>uv</literal> feature at all, or does not allow enabling or disabling it.)</para> |
461 | ||
462 | <xi:include href="version-info.xml" xpointer="v249"/></listitem> | |
896cc0da LB |
463 | </varlistentry> |
464 | ||
cf1e172d | 465 | <varlistentry> |
9bfabe14 | 466 | <term><option>--tpm2-device=<replaceable>PATH</replaceable></option></term> |
cf1e172d LP |
467 | |
468 | <listitem><para>Enroll a TPM2 security chip. Expects a device node path referring to the TPM2 chip | |
469 | (e.g. <filename>/dev/tpmrm0</filename>). Alternatively the special value <literal>auto</literal> may | |
470 | be specified, in order to automatically determine the device node of a currently discovered TPM2 | |
471 | device (of which there must be exactly one). The special value <literal>list</literal> may be used to | |
472 | enumerate all suitable TPM2 devices currently discovered.</para> | |
473 | ||
474 | <para>In order to unlock a LUKS2 volume with an enrolled TPM2 security chip, specify the | |
475 | <option>tpm2-device=</option> option in the respective <filename>/etc/crypttab</filename> line:</para> | |
476 | ||
477 | <programlisting>myvolume /dev/sda1 - tpm2-device=auto</programlisting> | |
478 | ||
479 | <para>See | |
480 | <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a | |
481 | more comprehensive example of a <command>systemd-cryptenroll</command> invocation and its matching | |
482 | <filename>/etc/crypttab</filename> line.</para> | |
483 | ||
484 | <para>Use <option>--tpm2-pcrs=</option> (see below) to configure which TPM2 PCR indexes to bind the | |
ec07c3c8 AK |
485 | enrollment to.</para> |
486 | ||
487 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
cf1e172d LP |
488 | </varlistentry> |
489 | ||
c3a2a681 | 490 | <varlistentry> |
9bfabe14 | 491 | <term><option>--tpm2-device-key=<replaceable>PATH</replaceable></option></term> |
c3a2a681 DS |
492 | |
493 | <listitem><para>Enroll a TPM2 security chip using its public key. Expects a path referring to the | |
494 | TPM2 public key in TPM2B_PUBLIC format. This cannot be used with <option>--tpm2-device=</option>, as | |
495 | it performs the same operation, but without connecting to the TPM2 security chip; instead the | |
496 | enrollment is calculated using the provided TPM2 key. This is useful in situations where the TPM2 | |
497 | security chip is not available at the time of enrollment.</para> | |
498 | ||
342c70da LP |
499 | <para>The key, in most cases, should be the Storage Root Key (SRK) from a local TPM2 security |
500 | chip. If a key from a different handle (not the SRK) is used, you must specify its handle index using | |
c3a2a681 DS |
501 | <option>--tpm2-seal-key-handle=</option>.</para> |
502 | ||
342c70da LP |
503 | <para>The |
504 | <citerefentry><refentrytitle>systemd-tpm2-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> | |
505 | service writes the SRK to <filename>/run/systemd/tpm2-srk-public-key.tpm2b_public</filename> | |
506 | automatically during boot, in the correct format.</para> | |
c3a2a681 | 507 | |
342c70da LP |
508 | <para>Alternatively, you may use <command>systemd-analyze srk</command> to retrieve the SRK from the |
509 | TPM2 security chip explicitly. See | |
510 | <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
511 | for details. Example:</para> | |
512 | ||
513 | <programlisting>systemd-analyze srk > srk.tpm2b_public</programlisting> | |
c3a2a681 DS |
514 | |
515 | <xi:include href="version-info.xml" xpointer="v255"/></listitem> | |
516 | </varlistentry> | |
517 | ||
382bfd90 | 518 | <varlistentry> |
9bfabe14 | 519 | <term><option>--tpm2-seal-key-handle=<replaceable>HANDLE</replaceable></option></term> |
382bfd90 DS |
520 | |
521 | <listitem><para>Configures which parent key to use for sealing, using the TPM handle (index) of the | |
522 | key. This is used to "seal" (encrypt) a secret and must be used later to "unseal" (decrypt) the | |
523 | secret. Expects a hexadecimal 32bit integer, optionally prefixed with | |
524 | <literal>0x</literal>. Allowable values are any handle index in the persistent | |
525 | (<literal>0x81000000</literal>-<literal>0x81ffffff</literal>) or transient | |
526 | (<literal>0x80000000</literal>-<literal>0x80ffffff</literal>) ranges. Since transient handles are | |
527 | lost after a TPM reset, and may be flushed during TPM context switching, they should not be used | |
528 | except for very specific use cases, e.g. testing.</para> | |
529 | ||
530 | <para>The default is the Storage Root Key (SRK) handle index <literal>0x81000001</literal>. A value | |
531 | of 0 will use the default. For the SRK handle, a new key will be created and stored in the TPM if one | |
532 | does not already exist; for any other handle, the key must already exist in the TPM at the specified | |
533 | handle index.</para> | |
534 | ||
535 | <para>This should not be changed unless you know what you are doing.</para> | |
536 | ||
537 | <xi:include href="version-info.xml" xpointer="v255"/></listitem> | |
538 | </varlistentry> | |
539 | ||
cf1e172d | 540 | <varlistentry> |
9bfabe14 | 541 | <term><option>--tpm2-pcrs=<replaceable>PCR<optional>+PCR...</optional></replaceable></option></term> |
cf1e172d | 542 | |
10fa7251 | 543 | <listitem><para>Configures the TPM2 PCRs (Platform Configuration Registers) to bind to when |
1782b0b8 DS |
544 | enrollment is requested via <option>--tpm2-device=</option>. Takes a list of PCR entries, where each |
545 | entry starts with a name or numeric index in the range 0…23, optionally followed by | |
546 | <literal>:</literal> and a hash algorithm name (specifying the PCR bank), optionally followed by | |
547 | <literal>=</literal> and a hash digest value. Multiple PCR entries are separated by | |
548 | <literal>+</literal>. If not specified, the default is to use PCR 7 only. If an empty string is | |
549 | specified, binds the enrollment to no PCRs at all. See the table above for a list of available | |
550 | PCRs.</para> | |
10fa7251 ZJS |
551 | |
552 | <para>Example: <option>--tpm2-pcrs=boot-loader-code+platform-config+boot-loader-config</option> | |
553 | specifies that PCR registers 4, 1, and 5 should be used.</para> | |
1782b0b8 DS |
554 | <para>Example: <option>--tpm2-pcrs=7:sha256</option> specifies that PCR register 7 from the SHA256 |
555 | bank should be used.</para> | |
a11a2e05 | 556 | <para>Example: <option>--tpm2-pcrs=4:sha1=3a3f780f11a4b49969fcaa80cd6e3957c33b2275</option> |
1782b0b8 | 557 | specifies that PCR register 4 from the SHA1 bank should be used, and a hash digest value of |
a11a2e05 | 558 | 3a3f780f11a4b49969fcaa80cd6e3957c33b2275 will be used instead of reading the current PCR |
1782b0b8 | 559 | value.</para> |
ec07c3c8 AK |
560 | |
561 | <xi:include href="version-info.xml" xpointer="v248"/> | |
10fa7251 | 562 | </listitem> |
cf1e172d LP |
563 | </varlistentry> |
564 | ||
caeb5604 | 565 | <varlistentry> |
9bfabe14 | 566 | <term><option>--tpm2-with-pin=<replaceable>BOOL</replaceable></option></term> |
caeb5604 GG |
567 | |
568 | <listitem><para>When enrolling a TPM2 device, controls whether to require the user to enter a PIN | |
569 | when unlocking the volume in addition to PCR binding, based on TPM2 policy authentication. Defaults | |
570 | to <literal>no</literal>. Despite being called PIN, any character can be used, not just numbers. | |
571 | </para> | |
572 | ||
f0f4fcae LP |
573 | <para>Note that incorrect PIN entry when unlocking increments the TPM dictionary attack lockout |
574 | mechanism, and may lock out users for a prolonged time, depending on its configuration. The lockout | |
575 | mechanism is a global property of the TPM, <command>systemd-cryptenroll</command> does not control or | |
576 | configure the lockout mechanism. You may use tpm2-tss tools to inspect or configure the dictionary | |
577 | attack lockout, with <citerefentry | |
578 | project='mankier'><refentrytitle>tpm2_getcap</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
579 | and <citerefentry | |
580 | project='mankier'><refentrytitle>tpm2_dictionarylockout</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
ec07c3c8 AK |
581 | commands, respectively.</para> |
582 | ||
583 | <xi:include href="version-info.xml" xpointer="v251"/></listitem> | |
caeb5604 GG |
584 | </varlistentry> |
585 | ||
f0f4fcae | 586 | <varlistentry> |
9bfabe14 SL |
587 | <term><option>--tpm2-public-key=<replaceable>PATH</replaceable></option></term> |
588 | <term><option>--tpm2-public-key-pcrs=<replaceable>PCR<optional>+PCR...</optional></replaceable></option></term> | |
589 | <term><option>--tpm2-signature=<replaceable>PATH</replaceable></option></term> | |
f0f4fcae LP |
590 | |
591 | <listitem><para>Configures a TPM2 signed PCR policy to bind encryption to. The | |
592 | <option>--tpm2-public-key=</option> option accepts a path to a PEM encoded RSA public key, to bind | |
593 | the encryption to. If this is not specified explicitly, but a file | |
594 | <filename>tpm2-pcr-public-key.pem</filename> exists in one of the directories | |
595 | <filename>/etc/systemd/</filename>, <filename>/run/systemd/</filename>, | |
596 | <filename>/usr/lib/systemd/</filename> (searched in this order), it is automatically used. The | |
597 | <option>--tpm2-public-key-pcrs=</option> option takes a list of TPM2 PCR indexes to bind to (same | |
598 | syntax as <option>--tpm2-pcrs=</option> described above). If not specified defaults to 11 (i.e. this | |
599 | binds the policy to any unified kernel image for which a PCR signature can be provided).</para> | |
600 | ||
601 | <para>Note the difference between <option>--tpm2-pcrs=</option> and | |
602 | <option>--tpm2-public-key-pcrs=</option>: the former binds decryption to the current, specific PCR | |
603 | values; the latter binds decryption to any set of PCR values for which a signature by the specified | |
604 | public key can be provided. The latter is hence more useful in scenarios where software updates shell | |
10fa7251 ZJS |
605 | be possible without losing access to all previously encrypted LUKS2 volumes. Like with |
606 | <option>--tpm2-pcrs=</option>, names defined in the table above can also be used to specify the | |
607 | registers, for instance | |
608 | <option>--tpm2-public-key-pcrs=boot-loader-code+system-identity</option>.</para> | |
f0f4fcae | 609 | |
10fa7251 ZJS |
610 | <para>The <option>--tpm2-signature=</option> option takes a path to a TPM2 PCR signature file as |
611 | generated by the | |
f0f4fcae | 612 | <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry> |
10fa7251 | 613 | tool. If this is not specified explicitly, a suitable signature file |
f0f4fcae | 614 | <filename>tpm2-pcr-signature.json</filename> is searched for in <filename>/etc/systemd/</filename>, |
10fa7251 ZJS |
615 | <filename>/run/systemd/</filename>, <filename>/usr/lib/systemd/</filename> (in this order) and used. |
616 | If a signature file is specified or found it is used to verify if the volume can be unlocked with it | |
617 | given the current PCR state, before the new slot is written to disk. This is intended as safety net | |
618 | to ensure that access to a volume is not lost if a public key is enrolled for which no valid | |
619 | signature for the current PCR state is available. If the supplied signature does not unlock the | |
f0f4fcae | 620 | current PCR state and public key combination, no slot is enrolled and the operation will fail. If no |
ec07c3c8 AK |
621 | signature file is specified or found no such safety verification is done.</para> |
622 | ||
623 | <xi:include href="version-info.xml" xpointer="v252"/></listitem> | |
f0f4fcae LP |
624 | </varlistentry> |
625 | ||
e2062109 | 626 | <varlistentry> |
9bfabe14 | 627 | <term><option>--tpm2-pcrlock=<replaceable>PATH</replaceable></option></term> |
e2062109 LP |
628 | |
629 | <listitem><para>Configures a TPM2 pcrlock policy to bind encryption to. Expects a path to a pcrlock | |
630 | policy file as generated by the | |
631 | <citerefentry><refentrytitle>systemd-pcrlock</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
632 | tool. If a TPM2 device is enrolled and this option is not used but a file | |
633 | <filename>pcrlock.json</filename> is found in <filename>/run/systemd/</filename> or | |
634 | <filename>/var/lib/systemd/</filename> it is automatically used. Assign an empty string to turn this | |
635 | behaviour off.</para> | |
636 | ||
637 | <xi:include href="version-info.xml" xpointer="v255"/></listitem> | |
638 | </varlistentry> | |
639 | ||
cf1e172d | 640 | <varlistentry> |
9bfabe14 | 641 | <term><option>--wipe-slot=<replaceable>SLOT<optional>,SLOT...</optional></replaceable></option></term> |
cf1e172d LP |
642 | |
643 | <listitem><para>Wipes one or more LUKS2 key slots. Takes a comma separated list of numeric slot | |
644 | indexes, or the special strings <literal>all</literal> (for wiping all key slots), | |
645 | <literal>empty</literal> (for wiping all key slots that are unlocked by an empty passphrase), | |
646 | <literal>password</literal> (for wiping all key slots that are unlocked by a traditional passphrase), | |
647 | <literal>recovery</literal> (for wiping all key slots that are unlocked by a recovery key), | |
648 | <literal>pkcs11</literal> (for wiping all key slots that are unlocked by a PKCS#11 token), | |
649 | <literal>fido2</literal> (for wiping all key slots that are unlocked by a FIDO2 token), | |
650 | <literal>tpm2</literal> (for wiping all key slots that are unlocked by a TPM2 chip), or any | |
651 | combination of these strings or numeric indexes, in which case all slots matching either are | |
652 | wiped. As safety precaution an operation that wipes all slots without exception (so that the volume | |
653 | cannot be unlocked at all anymore, unless the volume key is known) is refused.</para> | |
654 | ||
655 | <para>This switch may be used alone, in which case only the requested wipe operation is executed. It | |
656 | may also be used in combination with any of the enrollment options listed above, in which case the | |
657 | enrollment is completed first, and only when successful the wipe operation executed — and the newly | |
658 | added slot is always excluded from the wiping. Combining enrollment and slot wiping may thus be used to | |
659 | update existing enrollments:</para> | |
660 | ||
661 | <programlisting>systemd-cryptenroll /dev/sda1 --wipe-slot=tpm2 --tpm2-device=auto</programlisting> | |
662 | ||
45861042 | 663 | <para>The above command will enroll the TPM2 chip, and then wipe all previously created TPM2 |
cf1e172d LP |
664 | enrollments on the LUKS2 volume, leaving only the newly created one. Combining wiping and enrollment |
665 | may also be used to replace enrollments of different types, for example for changing from a PKCS#11 | |
666 | enrollment to a FIDO2 one:</para> | |
667 | ||
668 | <programlisting>systemd-cryptenroll /dev/sda1 --wipe-slot=pkcs11 --fido2-device=auto</programlisting> | |
669 | ||
670 | <para>Or for replacing an enrolled empty password by TPM2:</para> | |
671 | ||
672 | <programlisting>systemd-cryptenroll /dev/sda1 --wipe-slot=empty --tpm2-device=auto</programlisting> | |
ec07c3c8 AK |
673 | |
674 | <xi:include href="version-info.xml" xpointer="v248"/> | |
cf1e172d LP |
675 | </listitem> |
676 | </varlistentry> | |
677 | ||
e742c999 LP |
678 | <varlistentry> |
679 | <term><option>--list-devices</option></term> | |
680 | ||
681 | <listitem><para>Show a list of candidate block devices this command may operate on. Specifically, | |
682 | this enumerates block devices currently present that contain a LUKS superblock, and shows their device | |
683 | node paths along with any of their symlinks.</para> | |
684 | ||
685 | <xi:include href="version-info.xml" xpointer="v257"/></listitem> | |
686 | </varlistentry> | |
687 | ||
cf1e172d LP |
688 | <xi:include href="standard-options.xml" xpointer="help" /> |
689 | <xi:include href="standard-options.xml" xpointer="version" /> | |
690 | </variablelist> | |
691 | ||
692 | </refsect1> | |
693 | ||
0fceb553 LP |
694 | <refsect1> |
695 | <title>Credentials</title> | |
696 | ||
697 | <para><command>systemd-cryptenroll</command> supports the service credentials logic as implemented by | |
698 | <varname>ImportCredential=</varname>/<varname>LoadCredential=</varname>/<varname>SetCredential=</varname> | |
699 | (see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for | |
700 | details). The following credentials are used when passed in:</para> | |
701 | ||
702 | <variablelist class='system-credentials'> | |
703 | <varlistentry> | |
704 | <term><varname>cryptenroll.passphrase</varname></term> | |
705 | <term><varname>cryptenroll.new-passphrase</varname></term> | |
706 | ||
707 | <listitem><para>May contain the passphrase to unlock the volume with/to newly enroll.</para> | |
708 | ||
709 | <xi:include href="version-info.xml" xpointer="v256"/></listitem> | |
710 | </varlistentry> | |
711 | ||
712 | <varlistentry> | |
713 | <term><varname>cryptenroll.tpm2-pin</varname></term> | |
714 | <term><varname>cryptenroll.new-tpm2-pin</varname></term> | |
715 | ||
716 | <listitem><para>May contain the TPM2 PIN to unlock the volume with/to newly enroll.</para> | |
717 | ||
718 | <xi:include href="version-info.xml" xpointer="v256"/></listitem> | |
719 | </varlistentry> | |
720 | ||
721 | <varlistentry> | |
722 | <term><varname>cryptenroll.fido2-pin</varname></term> | |
723 | ||
724 | <listitem><para>If a FIDO2 token is enrolled this may contain the PIN of the token.</para> | |
725 | ||
726 | <xi:include href="version-info.xml" xpointer="v256"/></listitem> | |
727 | </varlistentry> | |
728 | ||
729 | <varlistentry> | |
730 | <term><varname>cryptenroll.pkcs11-pin</varname></term> | |
731 | ||
732 | <listitem><para>If a PKCS#11 token is enrolled this may contain the PIN of the token.</para> | |
733 | ||
734 | <xi:include href="version-info.xml" xpointer="v256"/></listitem> | |
735 | </varlistentry> | |
736 | </variablelist> | |
737 | </refsect1> | |
738 | ||
cf1e172d LP |
739 | <refsect1> |
740 | <title>Exit status</title> | |
741 | ||
742 | <para>On success, 0 is returned, a non-zero failure code otherwise.</para> | |
743 | </refsect1> | |
744 | ||
38e3c61d ZJS |
745 | <refsect1> |
746 | <title>Examples</title> | |
747 | ||
748 | <para><citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> and | |
749 | <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
750 | contain various examples employing <command>systemd-cryptenroll</command>.</para> | |
751 | </refsect1> | |
752 | ||
cf1e172d LP |
753 | <refsect1> |
754 | <title>See Also</title> | |
13a69c12 DT |
755 | <para><simplelist type="inline"> |
756 | <member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member> | |
757 | <member><citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
758 | <member><citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry></member> | |
759 | <member><citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
760 | <member><citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry></member> | |
761 | </simplelist></para> | |
cf1e172d LP |
762 | </refsect1> |
763 | ||
764 | </refentry> |