Empty lines and lines starting with the "#" character are ignored. Each of the remaining lines describes one encrypted block device. Fields are delimited by white space.
Each line is in the form
volume-name encrypted-device key-file options
The first two fields are mandatory, the remaining two are optional.
Setting up encrypted block devices using this file supports three encryption modes: LUKS, TrueCrypt and plain. See cryptsetup(8) for more information about each mode. When no mode is specified in the options field and the block device contains a LUKS signature, it is opened as a LUKS device; otherwise, it is assumed to be in raw dm-crypt (plain mode) format.
The first field contains the name of the resulting encrypted volume; its block device is set up below /dev/mapper/.
The second field contains a path to the underlying block device or file, or a specification of a block device via "UUID=" followed by the UUID.
The third field specifies an absolute path to a file with the encryption key. Optionally, the path may be followed by ":" and an fstab device specification (e.g. starting with "LABEL=" or similar); in which case the path is taken relative to the device file system root. If the field is not present or is "none" or "-", a key file named after the volume to unlock (i.e. the first column of the line), suffixed with .key is automatically loaded from the /etc/cryptsetup-keys.d/ and /run/cryptsetup-keys.d/ directories, if present. Otherwise, the password has to be manually entered during system boot. For swap encryption, /dev/urandom may be used as key file.
The fourth field, if present, is a comma-delimited list of options. The following options are recognized:
Optionally, the path may be followed by ":" and an fstab device specification (e.g. starting with "UUID=" or similar); in which case, the path is relative to the device file system root. The device gets mounted automatically for LUKS device activation duration only.
Hint: if this device is used for a mount point that is specified in fstab(5), the _netdev option should also be used for the mount point. Otherwise, a dependency loop might be created where the mount point will be pulled in by local-fs.target, while the service to configure the network is usually only started after the local file system has been mounted.
This requires kernel 4.0 or newer.
This requires kernel 4.0 or newer.
This requires kernel 5.9 or newer.
This requires kernel 5.9 or newer.
This option is only relevant for plain devices.
WARNING: Using the swap option will destroy the contents of the named partition during every boot, so make sure the underlying block device is specified correctly.
When this mode is used, the passphrase is read from the key file given in the third field. Only the first line of this file is read, excluding the new line character.
Note that the TrueCrypt format uses both passphrase and key files to derive a password for the volume. Therefore, the passphrase and all key files need to be provided. Use tcrypt-keyfile= to provide the absolute path to all key files. When using an empty passphrase in combination with one or more key files, use "/dev/null" as the password file in the third field.
This will map the hidden volume that is inside of the volume provided in the second field. Please note that there is no protection for the hidden volume if the outer volume is mounted instead. See cryptsetup(8) for more information on this limitation.
See the entry for tcrypt on the behavior of the passphrase and key files when using TrueCrypt encryption mode.
WARNING: Using the tmp option will destroy the contents of the named partition during every boot, so make sure the underlying block device is specified correctly.
Although it's not necessary to mark the mount entry for the root file system with x-initrd.mount, x-initrd.attach is still recommended with the encrypted block device containing the root file system as otherwise systemd will attempt to detach the device during the regular system shutdown while it's still in use. With this option the device will still be detached but later after the root file system is unmounted.
All other encrypted block devices that contain file systems mounted in the initramfs should use this option.
At early boot and when the system manager configuration is reloaded, this file is translated into native systemd units by systemd-cryptsetup-generator(8).
Set up four encrypted block devices. One using LUKS for normal storage, another one for usage as a swap device and two TrueCrypt volumes. For the fourth device, the option string is interpreted as two options "cipher=xchacha12,aes-adiantum-plain64", "keyfile-timeout=10s".
luks UUID=2505567a-9e27-4efe-a4d5-15ad146c258b swap /dev/sda7 /dev/urandom swap truecrypt /dev/sda2 /etc/container_password tcrypt hidden /mnt/tc_hidden /dev/null tcrypt-hidden,tcrypt-keyfile=/etc/keyfile external /dev/sda3 keyfile:LABEL=keydev keyfile-timeout=10s,cipher=xchacha12\,aes-adiantum-plain64
Example 2. Yubikey-based Volume Unlocking Example
The PKCS#11 logic allows hooking up any compatible security token that is capable of storing RSA decryption keys. Here's an example how to set up a Yubikey security token for this purpose, using ykmap(1) from the yubikey-manager project:
# Make sure no one can read the files we generate but us umask 077 # Destroy any old key on the Yubikey (careful!) ykman piv reset # Generate a new private/public key pair on the device, store the public key in 'pubkey.pem'. ykman piv generate-key -a RSA2048 9d pubkey.pem # Create a self-signed certificate from this public key, and store it on the # device. The "subject" should be an arbitrary string to identify the token in # the p11tool output below. ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem # Check if the newly create key on the Yubikey shows up as token in PKCS#11. Have a look at the output, and # copy the resulting token URI to the clipboard. p11tool --list-tokens # Generate a (secret) random key to use as LUKS decryption key. dd if=/dev/urandom of=plaintext.bin bs=128 count=1 # Encode the secret key also as base64 text (with all whitespace removed) base64 < plaintext.bin | tr -d '\n\r\t ' > plaintext.base64 # Encrypt this newly generated (binary) LUKS decryption key using the public key whose private key is on the # Yubikey, store the result in /etc/cryptsetup-keys.d/mytest.key, where we'll look for it during boot. mkdir -p /etc/cryptsetup-keys.d sudo openssl rsautl -encrypt -pubin -inkey pubkey.pem -in plaintext.bin -out /etc/cryptsetup-keys.d/mytest.key # Configure the LUKS decryption key on the LUKS device. We use very low pbkdf settings since the key already # has quite a high quality (it comes directly from /dev/urandom after all), and thus we don't need to do much # key derivation. Replace /dev/sdXn by the partition to use (e.g. sda1) sudo cryptsetup luksAddKey /dev/sdXn plaintext.base64 --pbkdf=pbkdf2 --pbkdf-force-iterations=1000 # Now securely delete the plain text LUKS key, we don't need it anymore, and since it contains secret key # material it should be removed from disk thoroughly. shred -u plaintext.bin plaintext.base64 # We don't need the public key anymore either, let's remove it too. Since this one is not security # sensitive we just do a regular "rm" here. rm pubkey.pem # Test: Let's run systemd-cryptsetup to test if this all worked. The option string should contain the full # PKCS#11 URI we have in the clipboard; it tells the tool how to decipher the encrypted LUKS key. Note that # systemd-cryptsetup automatically searches for the encrypted key in /etc/cryptsetup-keys.d/, hence we do # not need to specify the key file path explicitly here. sudo systemd-cryptsetup attach mytest /dev/sdXn - 'pkcs11-uri=pkcs11:...' # If that worked, let's now add the same line persistently to /etc/crypttab, for the future. sudo bash -c 'echo "mytest /dev/sdXn - \'pkcs11-uri=pkcs11:...\'" >> /etc/crypttab'
A few notes on the above:
- RFC7512 PKCS#11 URI
- see documentation