]>
Commit | Line | Data |
---|---|---|
45ae1a05 LP |
1 | <?xml version="1.0"?> |
2 | <!--*-nxml-*--> | |
3a54a157 | 3 | <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" |
eea10b26 | 4 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> |
45ae1a05 | 5 | <!-- |
db9ecf05 | 6 | SPDX-License-Identifier: LGPL-2.1-or-later |
572eb058 | 7 | |
45ae1a05 LP |
8 | This is based on crypttab(5) from Fedora's initscripts package, which in |
9 | turn is based on Debian's version. | |
10 | ||
11 | The Red Hat version has been written by Miloslav Trmac <mitr@redhat.com>. | |
45ae1a05 | 12 | --> |
c2d54475 | 13 | <refentry id="crypttab" conditional='HAVE_LIBCRYPTSETUP' xmlns:xi="http://www.w3.org/2001/XInclude"> |
45ae1a05 | 14 | |
798d3a52 ZJS |
15 | <refentryinfo> |
16 | <title>crypttab</title> | |
17 | <productname>systemd</productname> | |
798d3a52 ZJS |
18 | </refentryinfo> |
19 | ||
20 | <refmeta> | |
21 | <refentrytitle>crypttab</refentrytitle> | |
22 | <manvolnum>5</manvolnum> | |
23 | </refmeta> | |
24 | ||
25 | <refnamediv> | |
26 | <refname>crypttab</refname> | |
27 | <refpurpose>Configuration for encrypted block devices</refpurpose> | |
28 | </refnamediv> | |
29 | ||
30 | <refsynopsisdiv> | |
31 | <para><filename>/etc/crypttab</filename></para> | |
32 | </refsynopsisdiv> | |
33 | ||
34 | <refsect1> | |
35 | <title>Description</title> | |
36 | ||
37 | <para>The <filename>/etc/crypttab</filename> file describes | |
38 | encrypted block devices that are set up during system boot.</para> | |
39 | ||
40 | <para>Empty lines and lines starting with the <literal>#</literal> | |
41 | character are ignored. Each of the remaining lines describes one | |
ed3657d5 | 42 | encrypted block device. Fields are delimited by white space.</para> |
b2a1a5c7 | 43 | |
6e41f4dd | 44 | <para>Each line is in the form<programlisting><replaceable>volume-name</replaceable> <replaceable>encrypted-device</replaceable> <replaceable>key-file</replaceable> <replaceable>options</replaceable></programlisting> |
b2a1a5c7 | 45 | The first two fields are mandatory, the remaining two are |
798d3a52 ZJS |
46 | optional.</para> |
47 | ||
cf1e172d LP |
48 | <para>Setting up encrypted block devices using this file supports four encryption modes: LUKS, TrueCrypt, |
49 | BitLocker and plain. See <citerefentry | |
50 | project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> for | |
51 | more information about each mode. When no mode is specified in the options field and the block device | |
52 | contains a LUKS signature, it is opened as a LUKS device; otherwise, it is assumed to be in raw dm-crypt | |
53 | (plain mode) format.</para> | |
798d3a52 | 54 | |
96e9a9a4 LP |
55 | <para>The four fields of <filename>/etc/crypttab</filename> are defined as follows:</para> |
56 | ||
57 | <orderedlist> | |
58 | ||
59 | <listitem><para>The first field contains the name of the resulting volume with decrypted data; its | |
60 | block device is set up below <filename>/dev/mapper/</filename>.</para></listitem> | |
61 | ||
62 | <listitem><para>The second field contains a path to the underlying block | |
63 | device or file, or a specification of a block device via | |
64 | <literal>UUID=</literal> followed by the UUID.</para></listitem> | |
65 | ||
66 | <listitem><para>The third field specifies an absolute path to a file with the encryption | |
cf1e172d LP |
67 | key. Optionally, the path may be followed by <literal>:</literal> and an |
68 | <filename>/etc/fstab</filename> style device specification (e.g. starting with | |
69 | <literal>LABEL=</literal> or similar); in which case the path is taken relative to the specified | |
70 | device's file system root. If the field is not present or is <literal>none</literal> or | |
96e9a9a4 LP |
71 | <literal>-</literal>, a key file named after the volume to unlock (i.e. the first column of the line), |
72 | suffixed with <filename>.key</filename> is automatically loaded from the | |
73 | <filename>/etc/cryptsetup-keys.d/</filename> and <filename>/run/cryptsetup-keys.d/</filename> | |
74 | directories, if present. Otherwise, the password has to be manually entered during system boot. For | |
75 | swap encryption, <filename>/dev/urandom</filename> may be used as key file, resulting in a randomized | |
76 | key.</para> | |
77 | ||
78 | <para>If the specified key file path refers to an <constant>AF_UNIX</constant> stream socket in the | |
79 | file system, the key is acquired by connecting to the socket and reading it from the connection. This | |
80 | allows the implementation of a service to provide key information dynamically, at the moment when it is | |
81 | needed. For details see below.</para></listitem> | |
82 | ||
da115b93 | 83 | <listitem><para>The fourth field, if present, is a comma-delimited list of options. The supported |
96e9a9a4 LP |
84 | options are listed below.</para></listitem> |
85 | </orderedlist> | |
cf1e172d LP |
86 | </refsect1> |
87 | ||
88 | <refsect1> | |
89 | <title>Key Acquisition</title> | |
90 | ||
91 | <para>Six different mechanisms for acquiring the decryption key or passphrase unlocking the encrypted | |
92 | volume are supported. Specifically:</para> | |
93 | ||
94 | <orderedlist> | |
95 | ||
96 | <listitem><para>Most prominently, the user may be queried interactively during volume activation | |
0923b425 | 97 | (i.e. typically at boot), asking them to type in the necessary passphrases.</para></listitem> |
cf1e172d LP |
98 | |
99 | <listitem><para>The (unencrypted) key may be read from a file on disk, possibly on removable media. The third field | |
100 | of each line encodes the location, for details see above.</para></listitem> | |
101 | ||
102 | <listitem><para>The (unencrypted) key may be requested from another service, by specifying an | |
103 | <constant>AF_UNIX</constant> file system socket in place of a key file in the third field. For details | |
104 | see above and below.</para></listitem> | |
105 | ||
106 | <listitem><para>The key may be acquired via a PKCS#11 compatible hardware security token or | |
3d05c058 VS |
107 | smartcard. In this case a saved key used in unlock process is stored on disk/removable media, acquired via |
108 | <constant>AF_UNIX</constant>, or stored in the LUKS2 JSON token metadata header. For RSA, the saved key | |
109 | is an encrypted volume key. The encrypted volume key is then decrypted by the PKCS#11 token with an RSA | |
110 | private key stored on it, and used to unlock the encrypted volume. For elliptic-curve (EC) cryptography, | |
111 | the saved key is the public key generated in enrollment process. The public key is then used to derive | |
112 | a shared secret with a private key stored in the PKCS#11 token. The derived shared secret is then used | |
113 | to unlock the volume. Use the <option>pkcs11-uri=</option> option described below to use this mechanism. | |
114 | </para></listitem> | |
cf1e172d | 115 | |
6163dac4 ZJS |
116 | <listitem><para>Similarly, the key may be acquired via a FIDO2 compatible hardware security token |
117 | (which must implement the "hmac-secret" extension). In this case a key generated randomly during | |
118 | enrollment is stored on disk/removable media, acquired via <constant>AF_UNIX</constant>, or stored in | |
119 | the LUKS2 JSON token metadata header. The random key is hashed via a keyed hash function (HMAC) on the | |
120 | FIDO2 token, using a secret key stored on the token that never leaves it. The resulting hash value is | |
121 | then used as key to unlock the encrypted volume. Use the <option>fido2-device=</option> option | |
122 | described below to use this mechanism.</para></listitem> | |
123 | ||
124 | <listitem><para>Similarly, the key may be acquired via a TPM2 security chip. In this case a (during | |
cf1e172d LP |
125 | enrollment) randomly generated key — encrypted by an asymmetric key derived from the TPM2 chip's seed |
126 | key — is stored on disk/removable media, acquired via <constant>AF_UNIX</constant>, or stored in the | |
127 | LUKS2 JSON token metadata header. Use the <option>tpm2-device=</option> option described below to use | |
128 | this mechanism.</para></listitem> | |
129 | </orderedlist> | |
130 | ||
131 | <para>For the latter five mechanisms the source for the key material used for unlocking the volume is | |
132 | primarily configured in the third field of each <filename>/etc/crypttab</filename> line, but may also | |
133 | configured in <filename>/etc/cryptsetup-keys.d/</filename> and | |
134 | <filename>/run/cryptsetup-keys.d/</filename> (see above) or in the LUKS2 JSON token header (in case of | |
135 | the latter three). Use the | |
136 | <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
137 | tool to enroll PKCS#11, FIDO2 and TPM2 devices in LUKS2 volumes.</para> | |
138 | </refsect1> | |
139 | ||
140 | <refsect1> | |
141 | <title>Supported Options</title> | |
142 | ||
143 | <para>The following options may be used in the fourth field of each line:</para> | |
798d3a52 ZJS |
144 | |
145 | <variablelist class='fstab-options'> | |
146 | ||
798d3a52 ZJS |
147 | <varlistentry> |
148 | <term><option>cipher=</option></term> | |
149 | ||
b12bd993 ZJS |
150 | <listitem><para>Specifies the cipher to use. See <citerefentry |
151 | project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> | |
152 | for possible values and the default value of this option. A cipher with unpredictable IV values, such | |
153 | as <literal>aes-cbc-essiv:sha256</literal>, is recommended. Embedded commas in the cipher | |
154 | specification need to be escaped by preceding them with a backslash, see example below.</para> | |
aefdc112 AK |
155 | |
156 | <xi:include href="version-info.xml" xpointer="v186"/> | |
b12bd993 | 157 | </listitem> |
798d3a52 ZJS |
158 | </varlistentry> |
159 | ||
ed3657d5 ZJS |
160 | <varlistentry> |
161 | <term><option>discard</option></term> | |
162 | ||
163 | <listitem><para>Allow discard requests to be passed through the encrypted block | |
164 | device. This improves performance on SSD storage but has security implications. | |
aefdc112 AK |
165 | </para> |
166 | ||
167 | <xi:include href="version-info.xml" xpointer="v207"/></listitem> | |
ed3657d5 ZJS |
168 | </varlistentry> |
169 | ||
798d3a52 ZJS |
170 | <varlistentry> |
171 | <term><option>hash=</option></term> | |
172 | ||
173 | <listitem><para>Specifies the hash to use for password | |
174 | hashing. See | |
3ba3a79d | 175 | <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
798d3a52 | 176 | for possible values and the default value of this |
aefdc112 AK |
177 | option.</para> |
178 | ||
179 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
798d3a52 ZJS |
180 | </varlistentry> |
181 | ||
182 | <varlistentry> | |
183 | <term><option>header=</option></term> | |
184 | ||
70390240 KZ |
185 | <listitem><para>Use a detached (separated) metadata device or file |
186 | where the header containing the master key(s) is stored. This | |
187 | option is only relevant for LUKS and TrueCrypt/VeraCrypt devices. See | |
3ba3a79d | 188 | <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
70390240 | 189 | for possible values and the default value of this option.</para> |
13445d97 | 190 | |
cf1e172d LP |
191 | <para>Optionally, the path may be followed by <literal>:</literal> and an |
192 | <filename>/etc/fstab</filename> device specification (e.g. starting with <literal>UUID=</literal> or | |
193 | similar); in which case, the path is relative to the device file system root. The device gets mounted | |
aefdc112 AK |
194 | automatically for LUKS device activation duration only.</para> |
195 | ||
196 | <xi:include href="version-info.xml" xpointer="v219"/></listitem> | |
798d3a52 ZJS |
197 | </varlistentry> |
198 | ||
199 | <varlistentry> | |
200 | <term><option>keyfile-offset=</option></term> | |
201 | ||
202 | <listitem><para>Specifies the number of bytes to skip at the | |
203 | start of the key file. See | |
3ba3a79d | 204 | <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
798d3a52 | 205 | for possible values and the default value of this |
aefdc112 AK |
206 | option.</para> |
207 | ||
208 | <xi:include href="version-info.xml" xpointer="v187"/></listitem> | |
798d3a52 ZJS |
209 | </varlistentry> |
210 | ||
211 | <varlistentry> | |
212 | <term><option>keyfile-size=</option></term> | |
213 | ||
214 | <listitem><para>Specifies the maximum number of bytes to read | |
215 | from the key file. See | |
3ba3a79d | 216 | <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
798d3a52 ZJS |
217 | for possible values and the default value of this option. This |
218 | option is ignored in plain encryption mode, as the key file | |
aefdc112 AK |
219 | size is then given by the key size.</para> |
220 | ||
221 | <xi:include href="version-info.xml" xpointer="v188"/></listitem> | |
798d3a52 ZJS |
222 | </varlistentry> |
223 | ||
6e41f4dd LP |
224 | <varlistentry> |
225 | <term><option>keyfile-erase</option></term> | |
226 | ||
227 | <listitem><para>If enabled, the specified key file is erased after the volume is activated or when | |
228 | activation fails. This is in particular useful when the key file is only acquired transiently before | |
229 | activation (e.g. via a file in <filename>/run/</filename>, generated by a service running before | |
aefdc112 AK |
230 | activation), and shall be removed after use. Defaults to off.</para> |
231 | ||
232 | <xi:include href="version-info.xml" xpointer="v246"/></listitem> | |
6e41f4dd LP |
233 | </varlistentry> |
234 | ||
798d3a52 ZJS |
235 | <varlistentry> |
236 | <term><option>key-slot=</option></term> | |
237 | ||
238 | <listitem><para>Specifies the key slot to compare the | |
239 | passphrase or key against. If the key slot does not match the | |
240 | given passphrase or key, but another would, the setup of the | |
241 | device will fail regardless. This option implies | |
242 | <option>luks</option>. See | |
3ba3a79d | 243 | <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
798d3a52 | 244 | for possible values. The default is to try all key slots in |
aefdc112 AK |
245 | sequential order.</para> |
246 | ||
247 | <xi:include href="version-info.xml" xpointer="v209"/></listitem> | |
798d3a52 ZJS |
248 | </varlistentry> |
249 | ||
4e133451 | 250 | <varlistentry> |
251 | <term><option>keyfile-timeout=</option></term> | |
252 | ||
253 | <listitem><para> Specifies the timeout for the device on | |
7aa0b012 CHY |
254 | which the key file resides or the device used as the key file, |
255 | and falls back to a password if it could not be accessed. See | |
4e133451 | 256 | <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
257 | for key files on external devices. | |
aefdc112 AK |
258 | </para> |
259 | ||
260 | <xi:include href="version-info.xml" xpointer="v243"/></listitem> | |
4e133451 | 261 | </varlistentry> |
262 | ||
798d3a52 ZJS |
263 | <varlistentry> |
264 | <term><option>luks</option></term> | |
265 | ||
266 | <listitem><para>Force LUKS mode. When this mode is used, the | |
267 | following options are ignored since they are provided by the | |
268 | LUKS header on the device: <option>cipher=</option>, | |
269 | <option>hash=</option>, | |
aefdc112 AK |
270 | <option>size=</option>.</para> |
271 | ||
272 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
798d3a52 ZJS |
273 | </varlistentry> |
274 | ||
6cc27c29 MF |
275 | <varlistentry> |
276 | <term><option>bitlk</option></term> | |
277 | ||
cf1e172d | 278 | <listitem><para>Decrypt BitLocker drive. Encryption parameters |
aefdc112 AK |
279 | are deduced by cryptsetup from BitLocker header.</para> |
280 | ||
281 | <xi:include href="version-info.xml" xpointer="v246"/></listitem> | |
6cc27c29 MF |
282 | </varlistentry> |
283 | ||
b001ad61 ZJS |
284 | <varlistentry> |
285 | <term><option>_netdev</option></term> | |
286 | ||
287 | <listitem><para>Marks this cryptsetup device as requiring network. It will be | |
288 | started after the network is available, similarly to | |
289 | <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> | |
290 | units marked with <option>_netdev</option>. The service unit to set up this device | |
a0dd2097 | 291 | will be ordered between <filename>remote-fs-pre.target</filename> and |
b001ad61 ZJS |
292 | <filename>remote-cryptsetup.target</filename>, instead of |
293 | <filename>cryptsetup-pre.target</filename> and | |
288c2616 ZJS |
294 | <filename>cryptsetup.target</filename>.</para> |
295 | ||
296 | <para>Hint: if this device is used for a mount point that is specified in | |
297 | <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, | |
298 | the <option>_netdev</option> option should also be used for the mount | |
299 | point. Otherwise, a dependency loop might be created where the mount point | |
300 | will be pulled in by <filename>local-fs.target</filename>, while the | |
301 | service to configure the network is usually only started <emphasis>after</emphasis> | |
302 | the local file system has been mounted.</para> | |
aefdc112 AK |
303 | |
304 | <xi:include href="version-info.xml" xpointer="v235"/> | |
288c2616 | 305 | </listitem> |
b001ad61 ZJS |
306 | </varlistentry> |
307 | ||
798d3a52 ZJS |
308 | <varlistentry> |
309 | <term><option>noauto</option></term> | |
310 | ||
5d0e4851 ZJS |
311 | <listitem><para>This device will not be added to <filename>cryptsetup.target</filename>. |
312 | This means that it will not be automatically unlocked on boot, unless something else pulls | |
313 | it in. In particular, if the device is used for a mount point, it'll be unlocked | |
314 | automatically during boot, unless the mount point itself is also disabled with | |
aefdc112 AK |
315 | <option>noauto</option>.</para> |
316 | ||
317 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
798d3a52 ZJS |
318 | </varlistentry> |
319 | ||
320 | <varlistentry> | |
321 | <term><option>nofail</option></term> | |
322 | ||
5d0e4851 | 323 | <listitem><para>This device will not be a hard dependency of |
7792d9cd | 324 | <filename>cryptsetup.target</filename>. It'll still be pulled in and started, but the system |
5d0e4851 ZJS |
325 | will not wait for the device to show up and be unlocked, and boot will not fail if this is |
326 | unsuccessful. Note that other units that depend on the unlocked device may still fail. In | |
7792d9cd AZ |
327 | particular, if the device is used for a mount point, the mount point itself also needs to |
328 | have the <option>nofail</option> option, or the boot will fail if the device is not unlocked | |
c9be8e42 LB |
329 | successfully. If a keyfile and/or a <option>header</option> are specified, the dependencies on |
330 | their respective directories will also not be fatal, so that umounting said directories will | |
331 | not cause the generated cryptset unit to be deactivated.</para> | |
aefdc112 AK |
332 | |
333 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
798d3a52 ZJS |
334 | </varlistentry> |
335 | ||
ed3657d5 ZJS |
336 | <varlistentry> |
337 | <term><option>offset=</option></term> | |
338 | ||
339 | <listitem><para>Start offset in the backend device, in 512-byte sectors. This | |
aefdc112 AK |
340 | option is only relevant for plain devices.</para> |
341 | ||
342 | <xi:include href="version-info.xml" xpointer="v220"/></listitem> | |
ed3657d5 ZJS |
343 | </varlistentry> |
344 | ||
798d3a52 ZJS |
345 | <varlistentry> |
346 | <term><option>plain</option></term> | |
347 | ||
aefdc112 AK |
348 | <listitem><para>Force plain encryption mode.</para> |
349 | ||
350 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
798d3a52 ZJS |
351 | </varlistentry> |
352 | ||
353 | <varlistentry> | |
354 | <term><option>read-only</option></term><term><option>readonly</option></term> | |
355 | ||
356 | <listitem><para>Set up the encrypted block device in read-only | |
aefdc112 AK |
357 | mode.</para> |
358 | ||
359 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
798d3a52 ZJS |
360 | </varlistentry> |
361 | ||
2c65512e YW |
362 | <varlistentry> |
363 | <term><option>same-cpu-crypt</option></term> | |
364 | ||
cf1e172d | 365 | <listitem><para>Perform encryption using the same CPU that IO was submitted on. The default is to use |
2c65512e | 366 | an unbound workqueue so that encryption work is automatically balanced between available CPUs.</para> |
e9dd6984 | 367 | |
2c65512e | 368 | <para>This requires kernel 4.0 or newer.</para> |
aefdc112 AK |
369 | |
370 | <xi:include href="version-info.xml" xpointer="v242"/> | |
2c65512e YW |
371 | </listitem> |
372 | </varlistentry> | |
373 | ||
374 | <varlistentry> | |
375 | <term><option>submit-from-crypt-cpus</option></term> | |
376 | ||
377 | <listitem><para>Disable offloading writes to a separate thread after encryption. There are some | |
e9dd6984 ZJS |
378 | situations where offloading write requests from the encryption threads to a dedicated thread degrades |
379 | performance significantly. The default is to offload write requests to a dedicated thread because it | |
380 | benefits the CFQ scheduler to have writes submitted using the same context.</para> | |
381 | ||
2c65512e | 382 | <para>This requires kernel 4.0 or newer.</para> |
aefdc112 AK |
383 | |
384 | <xi:include href="version-info.xml" xpointer="v242"/> | |
2c65512e YW |
385 | </listitem> |
386 | </varlistentry> | |
387 | ||
227acf00 JU |
388 | <varlistentry> |
389 | <term><option>no-read-workqueue</option></term> | |
390 | ||
391 | <listitem><para>Bypass dm-crypt internal workqueue and process read requests synchronously. The | |
392 | default is to queue these requests and process them asynchronously.</para> | |
393 | ||
394 | <para>This requires kernel 5.9 or newer.</para> | |
ec07c3c8 AK |
395 | |
396 | <xi:include href="version-info.xml" xpointer="v248"/> | |
227acf00 JU |
397 | </listitem> |
398 | </varlistentry> | |
399 | <varlistentry> | |
400 | <term><option>no-write-workqueue</option></term> | |
401 | ||
402 | <listitem><para>Bypass dm-crypt internal workqueue and process write requests synchronously. The | |
403 | default is to queue these requests and process them asynchronously.</para> | |
404 | ||
405 | <para>This requires kernel 5.9 or newer.</para> | |
ec07c3c8 AK |
406 | |
407 | <xi:include href="version-info.xml" xpointer="v248"/> | |
227acf00 JU |
408 | </listitem> |
409 | </varlistentry> | |
410 | ||
ed3657d5 ZJS |
411 | <varlistentry> |
412 | <term><option>skip=</option></term> | |
413 | ||
414 | <listitem><para>How many 512-byte sectors of the encrypted data to skip at the | |
415 | beginning. This is different from the <option>offset=</option> option with respect | |
416 | to the sector numbers used in initialization vector (IV) calculation. Using | |
417 | <option>offset=</option> will shift the IV calculation by the same negative | |
418 | amount. Hence, if <option>offset=<replaceable>n</replaceable></option> is given, | |
419 | sector <replaceable>n</replaceable> will get a sector number of 0 for the IV | |
420 | calculation. Using <option>skip=</option> causes sector | |
421 | <replaceable>n</replaceable> to also be the first sector of the mapped device, but | |
422 | with its number for IV generation being <replaceable>n</replaceable>.</para> | |
423 | ||
424 | <para>This option is only relevant for plain devices.</para> | |
aefdc112 AK |
425 | |
426 | <xi:include href="version-info.xml" xpointer="v220"/> | |
ed3657d5 ZJS |
427 | </listitem> |
428 | </varlistentry> | |
429 | ||
798d3a52 ZJS |
430 | <varlistentry> |
431 | <term><option>size=</option></term> | |
432 | ||
433 | <listitem><para>Specifies the key size in bits. See | |
3ba3a79d | 434 | <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
798d3a52 | 435 | for possible values and the default value of this |
aefdc112 AK |
436 | option.</para> |
437 | ||
438 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
798d3a52 ZJS |
439 | </varlistentry> |
440 | ||
a9fc6406 DJL |
441 | <varlistentry> |
442 | <term><option>sector-size=</option></term> | |
443 | ||
444 | <listitem><para>Specifies the sector size in bytes. See | |
445 | <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> | |
446 | for possible values and the default value of this | |
aefdc112 AK |
447 | option.</para> |
448 | ||
449 | <xi:include href="version-info.xml" xpointer="v240"/></listitem> | |
a9fc6406 DJL |
450 | </varlistentry> |
451 | ||
798d3a52 ZJS |
452 | <varlistentry> |
453 | <term><option>swap</option></term> | |
454 | ||
455 | <listitem><para>The encrypted block device will be used as a | |
456 | swap device, and will be formatted accordingly after setting | |
457 | up the encrypted block device, with | |
458 | <citerefentry project='man-pages'><refentrytitle>mkswap</refentrytitle><manvolnum>8</manvolnum></citerefentry>. | |
459 | This option implies <option>plain</option>.</para> | |
460 | ||
617b85d1 DT |
461 | <warning> |
462 | <para>Using the <option>swap</option> option will | |
463 | destroy the contents of the named partition during every boot, | |
464 | so make sure the underlying block device is specified | |
465 | correctly.</para> | |
466 | </warning> | |
aefdc112 AK |
467 | |
468 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
798d3a52 ZJS |
469 | </varlistentry> |
470 | ||
471 | <varlistentry> | |
472 | <term><option>tcrypt</option></term> | |
473 | ||
474 | <listitem><para>Use TrueCrypt encryption mode. When this mode | |
475 | is used, the following options are ignored since they are | |
476 | provided by the TrueCrypt header on the device or do not | |
477 | apply: | |
478 | <option>cipher=</option>, | |
479 | <option>hash=</option>, | |
480 | <option>keyfile-offset=</option>, | |
481 | <option>keyfile-size=</option>, | |
482 | <option>size=</option>.</para> | |
483 | ||
484 | <para>When this mode is used, the passphrase is read from the | |
485 | key file given in the third field. Only the first line of this | |
486 | file is read, excluding the new line character.</para> | |
487 | ||
488 | <para>Note that the TrueCrypt format uses both passphrase and | |
489 | key files to derive a password for the volume. Therefore, the | |
490 | passphrase and all key files need to be provided. Use | |
491 | <option>tcrypt-keyfile=</option> to provide the absolute path | |
492 | to all key files. When using an empty passphrase in | |
493 | combination with one or more key files, use | |
494 | <literal>/dev/null</literal> as the password file in the third | |
aefdc112 AK |
495 | field.</para> |
496 | ||
497 | <xi:include href="version-info.xml" xpointer="v206"/></listitem> | |
798d3a52 ZJS |
498 | </varlistentry> |
499 | ||
500 | <varlistentry> | |
501 | <term><option>tcrypt-hidden</option></term> | |
502 | ||
503 | <listitem><para>Use the hidden TrueCrypt volume. This option | |
504 | implies <option>tcrypt</option>.</para> | |
505 | ||
506 | <para>This will map the hidden volume that is inside of the | |
507 | volume provided in the second field. Please note that there is | |
508 | no protection for the hidden volume if the outer volume is | |
509 | mounted instead. See | |
3ba3a79d | 510 | <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
aefdc112 AK |
511 | for more information on this limitation.</para> |
512 | ||
513 | <xi:include href="version-info.xml" xpointer="v206"/></listitem> | |
798d3a52 ZJS |
514 | </varlistentry> |
515 | ||
516 | <varlistentry> | |
517 | <term><option>tcrypt-keyfile=</option></term> | |
518 | ||
519 | <listitem><para>Specifies the absolute path to a key file to | |
520 | use for a TrueCrypt volume. This implies | |
521 | <option>tcrypt</option> and can be used more than once to | |
522 | provide several key files.</para> | |
523 | ||
524 | <para>See the entry for <option>tcrypt</option> on the | |
525 | behavior of the passphrase and key files when using TrueCrypt | |
aefdc112 AK |
526 | encryption mode.</para> |
527 | ||
528 | <xi:include href="version-info.xml" xpointer="v206"/></listitem> | |
798d3a52 ZJS |
529 | </varlistentry> |
530 | ||
531 | <varlistentry> | |
532 | <term><option>tcrypt-system</option></term> | |
533 | ||
534 | <listitem><para>Use TrueCrypt in system encryption mode. This | |
aefdc112 AK |
535 | option implies <option>tcrypt</option>.</para> |
536 | ||
537 | <xi:include href="version-info.xml" xpointer="v206"/></listitem> | |
798d3a52 ZJS |
538 | </varlistentry> |
539 | ||
52028838 GH |
540 | <varlistentry> |
541 | <term><option>tcrypt-veracrypt</option></term> | |
542 | ||
543 | <listitem><para>Check for a VeraCrypt volume. VeraCrypt is a fork of | |
544 | TrueCrypt that is mostly compatible, but uses different, stronger key | |
545 | derivation algorithms that cannot be detected without this flag. | |
546 | Enabling this option could substantially slow down unlocking, because | |
547 | VeraCrypt's key derivation takes much longer than TrueCrypt's. This | |
aefdc112 AK |
548 | option implies <option>tcrypt</option>.</para> |
549 | ||
550 | <xi:include href="version-info.xml" xpointer="v232"/></listitem> | |
52028838 GH |
551 | </varlistentry> |
552 | ||
70390240 KZ |
553 | <varlistentry> |
554 | <term><option>veracrypt-pim=</option></term> | |
555 | ||
556 | <listitem><para>Specifies a custom Personal Iteration Multiplier (PIM) | |
557 | value, which can range from 0..2147468 for standard veracrypt volumes | |
558 | and 0..65535 for veracrypt system volumes. A value of 0 will imply the | |
559 | VeraCrypt default. | |
560 | ||
561 | This option is only effective when <option>tcrypt-veracrypt</option> is | |
562 | set.</para> | |
563 | ||
564 | <para>Note that VeraCrypt enforces a minimal allowed PIM value depending on the | |
565 | password strength and the hash algorithm used for key derivation, however | |
566 | <option>veracrypt-pim=</option> is not checked against these bounds. | |
c8cd6d7b ZJS |
567 | See |
568 | <ulink url="https://www.veracrypt.fr/en/Personal%20Iterations%20Multiplier%20%28PIM%29.html">Veracrypt Personal Iterations Multiplier</ulink> | |
569 | documentation for more information.</para> | |
ec07c3c8 AK |
570 | |
571 | <xi:include href="version-info.xml" xpointer="v254"/> | |
70390240 KZ |
572 | </listitem> |
573 | </varlistentry> | |
574 | ||
798d3a52 ZJS |
575 | <varlistentry> |
576 | <term><option>timeout=</option></term> | |
577 | ||
578 | <listitem><para>Specifies the timeout for querying for a | |
579 | password. If no unit is specified, seconds is used. Supported | |
580 | units are s, ms, us, min, h, d. A timeout of 0 waits | |
aefdc112 AK |
581 | indefinitely (which is the default).</para> |
582 | ||
583 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
798d3a52 ZJS |
584 | </varlistentry> |
585 | ||
798d3a52 | 586 | <varlistentry> |
53ac130b | 587 | <term><option>tmp=</option></term> |
798d3a52 | 588 | |
53ac130b LP |
589 | <listitem><para>The encrypted block device will be prepared for using it as |
590 | <filename>/tmp/</filename>; it will be formatted using <citerefentry | |
591 | project='man-pages'><refentrytitle>mkfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Takes | |
592 | a file system type as argument, such as <literal>ext4</literal>, <literal>xfs</literal> or | |
593 | <literal>btrfs</literal>. If no argument is specified defaults to <literal>ext4</literal>. This | |
594 | option implies <option>plain</option>.</para> | |
798d3a52 | 595 | |
617b85d1 DT |
596 | <warning> |
597 | <para>Using the <option>tmp</option> option will destroy the contents of the named partition | |
598 | during every boot, so make sure the underlying block device is specified correctly.</para> | |
599 | </warning> | |
aefdc112 AK |
600 | |
601 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
798d3a52 ZJS |
602 | </varlistentry> |
603 | ||
604 | <varlistentry> | |
605 | <term><option>tries=</option></term> | |
606 | ||
607 | <listitem><para>Specifies the maximum number of times the user | |
608 | is queried for a password. The default is 3. If set to 0, the | |
aefdc112 AK |
609 | user is queried for a password indefinitely.</para> |
610 | ||
611 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
798d3a52 ZJS |
612 | </varlistentry> |
613 | ||
cd5f57bd LB |
614 | <varlistentry> |
615 | <term><option>headless=</option></term> | |
616 | ||
617 | <listitem><para>Takes a boolean argument, defaults to false. If true, never query interactively | |
ec07c3c8 AK |
618 | for the password/PIN. Useful for headless systems.</para> |
619 | ||
620 | <xi:include href="version-info.xml" xpointer="v249"/></listitem> | |
cd5f57bd LB |
621 | </varlistentry> |
622 | ||
798d3a52 ZJS |
623 | <varlistentry> |
624 | <term><option>verify</option></term> | |
625 | ||
c2d54475 | 626 | <listitem><para>If the encryption password is read from console, it has to be entered twice to |
aefdc112 AK |
627 | prevent typos.</para> |
628 | ||
629 | <xi:include href="version-info.xml" xpointer="v186"/></listitem> | |
c2d54475 LP |
630 | </varlistentry> |
631 | ||
1fa94a31 | 632 | <varlistentry> |
2cbca51a SB |
633 | <term><option>password-echo=yes|no|masked</option></term> |
634 | ||
635 | <listitem><para>Controls whether to echo passwords or security token PINs | |
636 | that are read from console. Takes a boolean or the special string <literal>masked</literal>. | |
637 | The default is <option>password-echo=masked</option>.</para> | |
638 | ||
639 | <para>If enabled, the typed characters are echoed literally. If disabled, | |
640 | the typed characters are not echoed in any form, the user will not get | |
641 | feedback on their input. If set to <literal>masked</literal>, an asterisk | |
642 | (<literal>*</literal>) is echoed for each character typed. Regardless of | |
643 | which mode is chosen, if the user hits the tabulator key (<literal>↹</literal>) | |
644 | at any time, or the backspace key (<literal>⌫</literal>) before any other | |
ec07c3c8 AK |
645 | data has been entered, then echo is turned off.</para> |
646 | ||
647 | <xi:include href="version-info.xml" xpointer="v249"/></listitem> | |
1fa94a31 SB |
648 | </varlistentry> |
649 | ||
c2d54475 LP |
650 | <varlistentry> |
651 | <term><option>pkcs11-uri=</option></term> | |
652 | ||
cf1e172d | 653 | <listitem><para>Takes either the special value <literal>auto</literal> or an <ulink |
3d05c058 | 654 | url="https://tools.ietf.org/html/rfc7512">RFC7512 PKCS#11 URI</ulink> pointing to a private key |
cf1e172d LP |
655 | which is used to decrypt the encrypted key specified in the third column of the line. This is useful |
656 | for unlocking encrypted volumes through PKCS#11 compatible security tokens or smartcards. See below | |
657 | for an example how to set up this mechanism for unlocking a LUKS2 volume with a YubiKey security | |
658 | token.</para> | |
659 | ||
660 | <para>If specified as <literal>auto</literal> the volume must be of type LUKS2 and must carry PKCS#11 | |
661 | security token metadata in its LUKS2 JSON token section. In this mode the URI and the encrypted key | |
662 | are automatically read from the LUKS2 JSON token header. Use | |
663 | <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
3d05c058 | 664 | as a simple tool for enrolling PKCS#11 security tokens or smartcards in a way compatible with |
cf1e172d LP |
665 | <literal>auto</literal>. In this mode the third column of the line should remain empty (that is, |
666 | specified as <literal>-</literal>).</para> | |
667 | ||
3d05c058 VS |
668 | <para>The specified URI can refer directly to a private key stored on a token or alternatively |
669 | just to a slot or token, in which case a search for a suitable private key will be performed. In | |
670 | this case if multiple suitable objects are found the token is refused. The keyfile configured | |
671 | in the third column of the line is used as is (i.e. in binary form, unprocessed). The resulting | |
672 | decrypted key (for RSA) or derived shared secret (for ECC) is then Base64 encoded before it is used | |
673 | to unlock the LUKS volume.</para> | |
cf1e172d LP |
674 | |
675 | <para>Use <command>systemd-cryptenroll --pkcs11-token-uri=list</command> to list all suitable PKCS#11 | |
676 | security tokens currently plugged in, along with their URIs.</para> | |
677 | ||
678 | <para>Note that many newer security tokens that may be used as PKCS#11 security token typically also | |
679 | implement the newer and simpler FIDO2 standard. Consider using <option>fido2-device=</option> | |
680 | (described below) to enroll it via FIDO2 instead. Note that a security token enrolled via PKCS#11 | |
681 | cannot be used to unlock the volume via FIDO2, unless also enrolled via FIDO2, and vice | |
aefdc112 AK |
682 | versa.</para> |
683 | ||
684 | <xi:include href="version-info.xml" xpointer="v245"/></listitem> | |
cf1e172d LP |
685 | </varlistentry> |
686 | ||
687 | <varlistentry> | |
688 | <term><option>fido2-device=</option></term> | |
689 | ||
690 | <listitem><para>Takes either the special value <literal>auto</literal> or the path to a | |
691 | <literal>hidraw</literal> device node (e.g. <filename>/dev/hidraw1</filename>) referring to a FIDO2 | |
692 | security token that implements the <literal>hmac-secret</literal> extension (most current hardware | |
693 | security tokens do). See below for an example how to set up this mechanism for unlocking an encrypted | |
694 | volume with a FIDO2 security token.</para> | |
695 | ||
696 | <para>If specified as <literal>auto</literal> the FIDO2 token device is automatically discovered, as | |
697 | it is plugged in.</para> | |
698 | ||
699 | <para>FIDO2 volume unlocking requires a client ID hash (CID) to be configured via | |
700 | <option>fido2-cid=</option> (see below) and a key to pass to the security token's HMAC functionality | |
701 | (configured in the line's third column) to operate. If not configured and the volume is of type | |
702 | LUKS2, the CID and the key are read from LUKS2 JSON token metadata instead. Use | |
703 | <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
704 | as simple tool for enrolling FIDO2 security tokens, compatible with this automatic mode, which is | |
705 | only available for LUKS2 volumes.</para> | |
706 | ||
707 | <para>Use <command>systemd-cryptenroll --fido2-device=list</command> to list all suitable FIDO2 | |
708 | security tokens currently plugged in, along with their device nodes.</para> | |
709 | ||
710 | <para>This option implements the following mechanism: the configured key is hashed via they HMAC | |
711 | keyed hash function the FIDO2 device implements, keyed by a secret key embedded on the device. The | |
712 | resulting hash value is Base64 encoded and used to unlock the LUKS2 volume. As it should not be | |
713 | possible to extract the secret from the hardware token, it should not be possible to retrieve the | |
714 | hashed key given the configured key — without possessing the hardware token.</para> | |
715 | ||
716 | <para>Note that many security tokens that implement FIDO2 also implement PKCS#11, suitable for | |
717 | unlocking volumes via the <option>pkcs11-uri=</option> option described above. Typically the newer, | |
ec07c3c8 AK |
718 | simpler FIDO2 standard is preferable.</para> |
719 | ||
720 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
cf1e172d LP |
721 | </varlistentry> |
722 | ||
723 | <varlistentry> | |
724 | <term><option>fido2-cid=</option></term> | |
725 | ||
726 | <listitem><para>Takes a Base64 encoded FIDO2 client ID to use for the FIDO2 unlock operation. If | |
727 | specified, but <option>fido2-device=</option> is not, <option>fido2-device=auto</option> is | |
728 | implied. If <option>fido2-device=</option> is used but <option>fido2-cid=</option> is not, the volume | |
729 | must be of LUKS2 type, and the CID is read from the LUKS2 JSON token header. Use | |
730 | <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
731 | for enrolling a FIDO2 token in the LUKS2 header compatible with this automatic | |
ec07c3c8 AK |
732 | mode.</para> |
733 | ||
734 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
cf1e172d LP |
735 | </varlistentry> |
736 | ||
737 | <varlistentry> | |
738 | <term><option>fido2-rp=</option></term> | |
739 | ||
740 | <listitem><para>Takes a string, configuring the FIDO2 Relying Party (rp) for the FIDO2 unlock | |
3d62af7d | 741 | operation. If not specified <literal>io.systemd.cryptsetup</literal> is used, except if the LUKS2 |
cf1e172d | 742 | JSON token header contains a different value. It should normally not be necessary to override |
ec07c3c8 AK |
743 | this.</para> |
744 | ||
745 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
cf1e172d LP |
746 | </varlistentry> |
747 | ||
748 | <varlistentry> | |
749 | <term><option>tpm2-device=</option></term> | |
750 | ||
751 | <listitem><para>Takes either the special value <literal>auto</literal> or the path to a device node | |
752 | (e.g. <filename>/dev/tpmrm0</filename>) referring to a TPM2 security chip. See below for an example | |
753 | how to set up this mechanism for unlocking an encrypted volume with a TPM2 chip.</para> | |
754 | ||
755 | <para>Use <option>tpm2-pcrs=</option> (see below) to configure the set of TPM2 PCRs to bind the | |
756 | volume unlocking to. Use | |
757 | <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
758 | as simple tool for enrolling TPM2 security chips in LUKS2 volumes.</para> | |
759 | ||
760 | <para>If specified as <literal>auto</literal> the TPM2 device is automatically discovered. Use | |
761 | <command>systemd-cryptenroll --tpm2-device=list</command> to list all suitable TPM2 devices currently | |
762 | available, along with their device nodes.</para> | |
763 | ||
764 | <para>This option implements the following mechanism: when enrolling a TPM2 device via | |
765 | <command>systemd-cryptenroll</command> on a LUKS2 volume, a randomized key unlocking the volume is | |
766 | generated on the host and loaded into the TPM2 chip where it is encrypted with an asymmetric | |
767 | "primary" key pair derived from the TPM2's internal "seed" key. Neither the seed key nor the primary | |
768 | key are permitted to ever leave the TPM2 chip — however, the now encrypted randomized key may. It is | |
769 | saved in the LUKS2 volume JSON token header. When unlocking the encrypted volume, the primary key | |
770 | pair is generated on the TPM2 chip again (which works as long as the chip's seed key is correctly | |
771 | maintained by the TPM2 chip), which is then used to decrypt (on the TPM2 chip) the encrypted key from | |
772 | the LUKS2 volume JSON token header saved there during enrollment. The resulting decrypted key is then | |
773 | used to unlock the volume. When the randomized key is encrypted the current values of the selected | |
774 | PCRs (see below) are included in the operation, so that different PCR state results in different | |
775 | encrypted keys and the decrypted key can only be recovered if the same PCR state is | |
ec07c3c8 AK |
776 | reproduced.</para> |
777 | ||
778 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
cf1e172d LP |
779 | </varlistentry> |
780 | ||
781 | <varlistentry> | |
782 | <term><option>tpm2-pcrs=</option></term> | |
783 | ||
a1788a69 LP |
784 | <listitem><para>Takes a <literal>+</literal> separated list of numeric TPM2 PCR (i.e. "Platform |
785 | Configuration Register") indexes to bind the TPM2 volume unlocking to. This option is only useful | |
786 | when TPM2 enrollment metadata is not available in the LUKS2 JSON token header already, the way | |
cf1e172d LP |
787 | <command>systemd-cryptenroll</command> writes it there. If not used (and no metadata in the LUKS2 |
788 | JSON token header defines it), defaults to a list of a single entry: PCR 7. Assign an empty string to | |
789 | encode a policy that binds the key to no PCRs, making the key accessible to local programs regardless | |
ec07c3c8 AK |
790 | of the current PCR state.</para> |
791 | ||
792 | <xi:include href="version-info.xml" xpointer="v248"/></listitem> | |
798d3a52 ZJS |
793 | </varlistentry> |
794 | ||
4005d41e GG |
795 | <varlistentry> |
796 | <term><option>tpm2-pin=</option></term> | |
797 | ||
798 | <listitem><para>Takes a boolean argument, defaults to <literal>false</literal>. Controls whether | |
799 | TPM2 volume unlocking is bound to a PIN in addition to PCRs. Similarly, this option is only useful | |
ec07c3c8 AK |
800 | when TPM2 enrollment metadata is not available.</para> |
801 | ||
802 | <xi:include href="version-info.xml" xpointer="v251"/></listitem> | |
4005d41e GG |
803 | </varlistentry> |
804 | ||
dc63b2c9 LP |
805 | <varlistentry> |
806 | <term><option>tpm2-signature=</option></term> | |
807 | ||
808 | <listitem><para>Takes an absolute path to a TPM2 PCR JSON signature file, as produced by the | |
809 | <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
810 | tool. This permits locking LUKS2 volumes to any PCR values for which a valid signature matching a | |
811 | public key specified at key enrollment time can be provided. See | |
812 | <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
813 | for details on enrolling TPM2 PCR public keys. If this option is not specified but it is attempted to | |
814 | unlock a LUKS2 volume with a signed TPM2 PCR enrollment a suitable signature file | |
815 | <filename>tpm2-pcr-signature.json</filename> is searched for in <filename>/etc/systemd/</filename>, | |
816 | <filename>/run/systemd/</filename>, <filename>/usr/lib/systemd/</filename> (in this | |
ec07c3c8 AK |
817 | order).</para> |
818 | ||
819 | <xi:include href="version-info.xml" xpointer="v252"/></listitem> | |
dc63b2c9 | 820 | </varlistentry> |
e2062109 LP |
821 | |
822 | <varlistentry> | |
823 | <term><option>tpm2-pcrlock=</option></term> | |
824 | ||
825 | <listitem><para>Takes an absolute path to a TPM2 pcrlock policy file, as produced by the | |
826 | <citerefentry><refentrytitle>systemd-pcrlock</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
827 | tool. This permits locking LUKS2 volumes to a local policy of allowed PCR values with | |
828 | variants. See | |
829 | <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
830 | for details on enrolling TPM2 pcrlock policies. If this option is not specified but it is attempted | |
831 | to unlock a LUKS2 volume with a TPM2 pcrlock enrollment a suitable signature file | |
832 | <filename>pcrlock.json</filename> is searched for in <filename>/run/systemd/</filename> and | |
833 | <filename>/var/lib/systemd/</filename> (in this order).</para> | |
834 | ||
835 | <xi:include href="version-info.xml" xpointer="v255"/></listitem> | |
836 | </varlistentry> | |
dc63b2c9 | 837 | |
572f7876 LP |
838 | <varlistentry> |
839 | <term><option>tpm2-measure-pcr=</option></term> | |
840 | ||
841 | <listitem><para>Controls whether to measure the volume key of the encrypted volume to a TPM2 PCR. If | |
842 | set to "no" (which is the default) no PCR extension is done. If set to "yes" the volume key is | |
843 | measured into PCR 15. If set to a decimal integer in the range 0…23 the volume key is measured into | |
844 | the specified PCR. The volume key is measured along with the activated volume name and its UUID. This | |
845 | functionality is particularly useful for the encrypted volume backing the root file system, as it | |
846 | then allows later TPM objects to be securely bound to the root file system and hence the specific | |
ec07c3c8 AK |
847 | installation.</para> |
848 | ||
849 | <xi:include href="version-info.xml" xpointer="v253"/></listitem> | |
572f7876 LP |
850 | </varlistentry> |
851 | ||
852 | <varlistentry> | |
853 | <term><option>tpm2-measure-bank=</option></term> | |
854 | ||
855 | <listitem><para>Selects one or more TPM2 PCR banks to measure the volume key into, as configured with | |
856 | <option>tpm2-measure-pcr=</option> above. Multiple banks may be specified, separated by a colon | |
857 | character. If not specified automatically determines available and used banks. Expects a message | |
858 | digest name (e.g. <literal>sha1</literal>, <literal>sha256</literal>, …) as argument, to identify the | |
ec07c3c8 AK |
859 | bank.</para> |
860 | ||
861 | <xi:include href="version-info.xml" xpointer="v253"/></listitem> | |
572f7876 LP |
862 | </varlistentry> |
863 | ||
2c7ec820 LP |
864 | <varlistentry> |
865 | <term><option>token-timeout=</option></term> | |
866 | ||
867 | <listitem><para>Specifies how long to wait at most for configured security devices (i.e. FIDO2, | |
868 | PKCS#11, TPM2) to show up. Takes a time value in seconds (but other time units may be specified too, | |
869 | see <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> | |
870 | for supported formats). Defaults to 30s. Once the specified timeout elapsed authentication via | |
871 | password is attempted. Note that this timeout applies to waiting for the security device to show up — | |
872 | it does not apply to the PIN prompt for the device (should one be needed) or similar. Pass 0 to turn | |
ec07c3c8 AK |
873 | off the time-out and wait forever.</para> |
874 | ||
875 | <xi:include href="version-info.xml" xpointer="v250"/></listitem> | |
2c7ec820 LP |
876 | </varlistentry> |
877 | ||
6e41f4dd LP |
878 | <varlistentry> |
879 | <term><option>try-empty-password=</option></term> | |
880 | ||
881 | <listitem><para>Takes a boolean argument. If enabled, right before asking the user for a password it | |
882 | is first attempted to unlock the volume with an empty password. This is useful for systems that are | |
883 | initialized with an encrypted volume with only an empty password set, which shall be replaced with a | |
aefdc112 AK |
884 | suitable password during first boot, but after activation.</para> |
885 | ||
886 | <xi:include href="version-info.xml" xpointer="v246"/></listitem> | |
6e41f4dd LP |
887 | </varlistentry> |
888 | ||
ed3657d5 ZJS |
889 | <varlistentry> |
890 | <term><option>x-systemd.device-timeout=</option></term> | |
891 | ||
2c7ec820 LP |
892 | <listitem><para>Specifies how long systemd should wait for a block device to show up before |
893 | giving up on the entry. The argument is a time in seconds or explicitly specified units of | |
894 | <literal>s</literal>, <literal>min</literal>, <literal>h</literal>, <literal>ms</literal>. | |
aefdc112 AK |
895 | </para> |
896 | ||
897 | <xi:include href="version-info.xml" xpointer="v216"/></listitem> | |
ed3657d5 ZJS |
898 | </varlistentry> |
899 | ||
1dc85eff FB |
900 | <varlistentry> |
901 | <term><option>x-initrd.attach</option></term> | |
902 | ||
32e27670 | 903 | <listitem><para>Setup this encrypted block device in the initrd, similarly to |
1dc85eff FB |
904 | <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> |
905 | units marked with <option>x-initrd.mount</option>.</para> | |
906 | ||
907 | <para>Although it's not necessary to mark the mount entry for the root file system with | |
908 | <option>x-initrd.mount</option>, <option>x-initrd.attach</option> is still recommended with | |
909 | the encrypted block device containing the root file system as otherwise systemd will | |
910 | attempt to detach the device during the regular system shutdown while it's still in | |
911 | use. With this option the device will still be detached but later after the root file | |
912 | system is unmounted.</para> | |
913 | ||
32e27670 LP |
914 | <para>All other encrypted block devices that contain file systems mounted in the initrd should use |
915 | this option.</para> | |
aefdc112 AK |
916 | |
917 | <xi:include href="version-info.xml" xpointer="v245"/> | |
1dc85eff FB |
918 | </listitem> |
919 | </varlistentry> | |
920 | ||
798d3a52 ZJS |
921 | </variablelist> |
922 | ||
923 | <para>At early boot and when the system manager configuration is | |
924 | reloaded, this file is translated into native systemd units by | |
925 | <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> | |
926 | </refsect1> | |
927 | ||
96e9a9a4 LP |
928 | <refsect1> |
929 | <title><constant>AF_UNIX</constant> Key Files</title> | |
930 | ||
931 | <para>If the key file path (as specified in the third column of <filename>/etc/crypttab</filename> | |
932 | entries, see above) refers to an <constant>AF_UNIX</constant> stream socket in the file system, the key | |
933 | is acquired by connecting to the socket and reading the key from the connection. The connection is made | |
934 | from an <constant>AF_UNIX</constant> socket name in the abstract namespace, see <citerefentry | |
935 | project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry> for | |
936 | details. The source socket name is chosen according the following format:</para> | |
937 | ||
6163dac4 | 938 | <programlisting><constant>NUL</constant> <replaceable>RANDOM</replaceable> /cryptsetup/ <replaceable>VOLUME</replaceable></programlisting> |
96e9a9a4 LP |
939 | |
940 | <para>In other words: a <constant>NUL</constant> byte (as required for abstract namespace sockets), | |
cf1e172d | 941 | followed by a random string (consisting of alphanumeric characters only), followed by the literal |
96e9a9a4 | 942 | string <literal>/cryptsetup/</literal>, followed by the name of the volume to acquire they key |
6163dac4 | 943 | for. For example, for the volume <literal>myvol</literal>:</para> |
96e9a9a4 | 944 | |
6163dac4 | 945 | <programlisting>\0d7067f78d9827418/cryptsetup/myvol</programlisting> |
96e9a9a4 LP |
946 | |
947 | <para>Services listening on the <constant>AF_UNIX</constant> stream socket may query the source socket | |
948 | name with <citerefentry | |
949 | project='man-pages'><refentrytitle>getpeername</refentrytitle><manvolnum>2</manvolnum></citerefentry>, | |
6163dac4 ZJS |
950 | and use this to determine which key to send, allowing a single listening socket to serve keys for |
951 | multiple volumes. If the PKCS#11 logic is used (see above), the socket source name is picked in similar | |
952 | fashion, except that the literal string <literal>/cryptsetup-pkcs11/</literal> is used. And similarly for | |
6c2d70ce | 953 | FIDO2 (<literal>/cryptsetup-fido2/</literal>) and TPM2 (<literal>/cryptsetup-tpm2/</literal>). A different |
6163dac4 ZJS |
954 | path component is used so that services providing key material know that the secret key was not requested |
955 | directly, but instead an encrypted key that will be decrypted via the PKCS#11/FIDO2/TPM2 logic to acquire | |
956 | the final secret key.</para> | |
96e9a9a4 | 957 | </refsect1> |
cf1e172d | 958 | |
798d3a52 | 959 | <refsect1> |
c2d54475 | 960 | <title>Examples</title> |
798d3a52 ZJS |
961 | <example> |
962 | <title>/etc/crypttab example</title> | |
b12bd993 ZJS |
963 | <para>Set up four encrypted block devices. One using LUKS for normal storage, another one for usage as |
964 | a swap device and two TrueCrypt volumes. For the fourth device, the option string is interpreted as two | |
965 | options <literal>cipher=xchacha12,aes-adiantum-plain64</literal>, | |
966 | <literal>keyfile-timeout=10s</literal>.</para> | |
798d3a52 ZJS |
967 | |
968 | <programlisting>luks UUID=2505567a-9e27-4efe-a4d5-15ad146c258b | |
969 | swap /dev/sda7 /dev/urandom swap | |
8cf3ca80 | 970 | truecrypt /dev/sda2 /etc/container_password tcrypt |
4e133451 | 971 | hidden /mnt/tc_hidden /dev/null tcrypt-hidden,tcrypt-keyfile=/etc/keyfile |
b12bd993 ZJS |
972 | external /dev/sda3 keyfile:LABEL=keydev keyfile-timeout=10s,cipher=xchacha12\,aes-adiantum-plain64 |
973 | </programlisting> | |
798d3a52 | 974 | </example> |
c2d54475 LP |
975 | |
976 | <example> | |
cf1e172d | 977 | <title>Yubikey-based PKCS#11 Volume Unlocking Example</title> |
c2d54475 LP |
978 | |
979 | <para>The PKCS#11 logic allows hooking up any compatible security token that is capable of storing RSA | |
3d05c058 VS |
980 | or EC cryptographic keys for unlocking an encrypted volume. Here's an example how to set up a Yubikey |
981 | security token for this purpose on a LUKS2 volume, using <citerefentry | |
cf1e172d LP |
982 | project='debian'><refentrytitle>ykmap</refentrytitle><manvolnum>1</manvolnum></citerefentry> from the |
983 | yubikey-manager project to initialize the token and | |
984 | <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry> | |
985 | to add it in the LUKS2 volume:</para> | |
c2d54475 | 986 | |
5f5f1ba1 | 987 | <programlisting><xi:include href="yubikey-crypttab.sh" parse="text" /></programlisting> |
c2d54475 | 988 | |
cf1e172d LP |
989 | <para>A few notes on the above:</para> |
990 | ||
991 | <itemizedlist> | |
992 | <listitem><para>We use RSA2048, which is the longest key size current Yubikeys support</para></listitem> | |
993 | <listitem><para>We use Yubikey key slot 9d, since that's apparently the keyslot to use for decryption purposes, | |
c8cd6d7b ZJS |
994 | see |
995 | <ulink url="https://developers.yubico.com/PIV/Introduction/Certificate_slots.html">Yubico PIV certificate slots</ulink>. | |
996 | </para></listitem> | |
cf1e172d LP |
997 | </itemizedlist> |
998 | </example> | |
999 | ||
1000 | <example> | |
1001 | <title>FIDO2 Volume Unlocking Example</title> | |
1002 | ||
1003 | <para>The FIDO2 logic allows using any compatible FIDO2 security token that implements the | |
1004 | <literal>hmac-secret</literal> extension for unlocking an encrypted volume. Here's an example how to | |
1005 | set up a FIDO2 security token for this purpose for a LUKS2 volume, using | |
1006 | <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>:</para> | |
1007 | ||
5f5f1ba1 | 1008 | <programlisting><xi:include href="fido2-crypttab.sh" parse="text" /></programlisting> |
cf1e172d LP |
1009 | </example> |
1010 | ||
1011 | <example> | |
1012 | <title>TPM2 Volume Unlocking Example</title> | |
c2d54475 | 1013 | |
cf1e172d LP |
1014 | <para>The TPM2 logic allows using any TPM2 chip supported by the Linux kernel for unlocking an |
1015 | encrypted volume. Here's an example how to set up a TPM2 chip for this purpose for a LUKS2 volume, | |
1016 | using | |
1017 | <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>:</para> | |
c2d54475 | 1018 | |
5f5f1ba1 | 1019 | <programlisting><xi:include href="tpm2-crypttab.sh" parse="text" /></programlisting> |
c2d54475 | 1020 | </example> |
798d3a52 ZJS |
1021 | </refsect1> |
1022 | ||
1023 | <refsect1> | |
1024 | <title>See Also</title> | |
13a69c12 DT |
1025 | <para><simplelist type="inline"> |
1026 | <member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member> | |
1027 | <member><citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
1028 | <member><citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
1029 | <member><citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry></member> | |
1030 | <member><citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry></member> | |
1031 | <member><citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
1032 | <member><citerefentry project='man-pages'><refentrytitle>mkswap</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
1033 | <member><citerefentry project='man-pages'><refentrytitle>mke2fs</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
1034 | </simplelist></para> | |
798d3a52 | 1035 | </refsect1> |
45ae1a05 LP |
1036 | |
1037 | </refentry> |