Official NixOS Wiki

Full Disk Encryption: Difference between revisions

← Older edit
Pigeon (talk | contribs)
24 edits
VisualWikitext
imported>Ulinja
move "LVM on LUKS" to relevant section
Pigeon (talk | contribs)
24 edits
m fix consistency with wording "USB stick" and minor typos
 
(17 intermediate revisions by 12 users not shown)
Line 1: Line 1:
There are a few options for full disk encryption.
There are a few options for full disk encryption. The easiest way is to use the graphical installer and choose "encrypt" while doing the installation.


= Enter password on Boot (LVM on LUKS) =
= LVM on LUKS =


In this example, everything except for the <code>/boot</code> partition is encrypted.
In this example, everything except for the <code>/boot</code> partition is encrypted.
Line 22: Line 22:
     └─vg-root 254:2    0 225.3G  0 lvm  /
     └─vg-root 254:2    0 225.3G  0 lvm  /
</syntaxhighlight>
</syntaxhighlight>
== Enter password on Boot ==


The initrd needs to be configured to unlock the encrypted <code>/dev/sda2</code> partition during stage 1 of the boot process.
The initrd needs to be configured to unlock the encrypted <code>/dev/sda2</code> partition during stage 1 of the boot process.
Line 29: Line 31:
     boot = {
     boot = {
       loader = {
       loader = {
         canTouchEfiVariables = true;
         efi.canTouchEfiVariables = true;
         grub = {
         grub = {
           enable = true;
           enable = true;
Line 42: Line 44:
With <code lang="nix">initrd.luks.devices.cryptroot.device = "/dev/disk/by-uuid/UUID-OF-SDA2";</code>, the initrd knows it must unlock <code>/dev/sda2</code> before activating LVM and proceeding with the boot process.
With <code lang="nix">initrd.luks.devices.cryptroot.device = "/dev/disk/by-uuid/UUID-OF-SDA2";</code>, the initrd knows it must unlock <code>/dev/sda2</code> before activating LVM and proceeding with the boot process.


= Unattended Boot via USB =
== Unattended Boot via USB ==


Sometimes it is necessary to boot a system without needing an keyboard and monitor. You will create a secret key, add it to a key slot and put it onto an USB stick.
Sometimes it is necessary to boot a system without needing a keyboard and monitor. You will create a secret key, add it to a key slot and put it onto a USB stick.


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
dd if=/dev/random of=hdd.key bs=4096 count=1
dd if=/dev/random of=hdd.key bs=4096 count=1
cryptsetup luksAddKey /dev/sda1 ./hdd.key
cryptsetup luksAddKey /dev/sda1 ./hdd.key
</syntaxhighlight>
</syntaxhighlight>You can enable fallback to password (in case the USB stick is lost or corrupted) by setting the <code>boot.initrd.luks.devices.<name>.fallbackToPassword</code> option to <code>true</code>. By default, this option is <code>false</code> so you will have to perform a manual recovery if the USB stick becomes unavailable (which you may prefer, depending on your use case).
== Option 1: Write key onto the start of the stick ==
 
=== Option 1: Write key onto the start of the stick ===


This will make the usb-stick unusable for any other operations than being used for decryption. Write they key onto the stick:
This will make the USB stick unusable for any other operations than being used for decryption. Write the key onto the stick:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
Line 73: Line 76:
         # pinning to /dev/disk/by-id/usbkey works
         # pinning to /dev/disk/by-id/usbkey works
         keyFile = "/dev/sdb";
         keyFile = "/dev/sdb";
        # optionally enable fallback to password in case USB is lost
        fallbackToPassword = true;
       };
       };
   };
   };
}</syntaxhighlight>
}</syntaxhighlight>


== Option 2: Copy Key as file onto a vfat usb stick ==
=== Option 2: Copy Key as file onto a vfat USB stick ===


If you want to use your stick for other stuff or it already has other keys on it you can use the following method by Tzanko Matev. Add this to your <code>configuration.nix</code>:
If you want to use your stick for other stuff or it already has other keys on it you can use the following method by Tzanko Matev. Add this to your <code>configuration.nix</code>:
Line 95: Line 100:
   boot.initrd.postDeviceCommands = pkgs.lib.mkBefore ''
   boot.initrd.postDeviceCommands = pkgs.lib.mkBefore ''
     mkdir -m 0755 -p /key
     mkdir -m 0755 -p /key
     sleep 2 # To make sure the usb key has been loaded
     sleep 2 # To make sure the USB key has been loaded
     mount -n -t vfat -o ro `findfs UUID=${PRIMARYUSBID}` /key || mount -n -t vfat -o ro `findfs UUID=${BACKUPUSBID}` /key
     mount -n -t vfat -o ro `findfs UUID=${PRIMARYUSBID}` /key || mount -n -t vfat -o ro `findfs UUID=${BACKUPUSBID}` /key
   '';
   '';
Line 105: Line 110:
}
}
</syntaxhighlight>
</syntaxhighlight>
== Unattended Boot via keyfile ==
A simpler but insecure option for unattended boots is to copy the keyfile into the initrd itself.
{{warning|1=This method is not generally recommended as anyone with physical access to your boot partition will be able to retrieve the key file and use it to decrypt your luks partition. Make sure you understand the security implications.}}
First move the key to a safe location.
<syntaxhighlight lang="bash">
mkdir /var/lib/secrets
chown root:root /var/lib/secrets
chmod 700 /var/lib/secrets
mv -v hdd.key /var/lib/secrets/
chmod 600 /var/lib/secrets/hdd.key
</syntaxhighlight>
Then add the key to the initrd.
<syntaxhighlight lang="nix">
let
  keyFile = "hdd.key";
in
{
  boot.initrd.luks.devices."root" = {
    device = "/dev/disk/by-uuid/<uuid>";
    keyFile = "/${keyFile}";
  };
  boot.initrd.secrets = { "/${keyFile}" = /var/lib/secrets/${keyFile}; };
}
</syntaxhighlight>
== Store key on FIDO2 device or TPM ==
Unattended boot can also happen with a FIDO2 device (e.g. Yubikey) or TPM. This cannot be performed in a fully declarative way because every such security device is unique; some manual running of <code>systemd-cryptenroll</code> is required.
For FIDO2, directly read the [https://github.com/NixOS/nixpkgs/blob/7be68f763d94cdb4c809b7980647828e3274a511/nixos/doc/manual/configuration/luks-file-systems.section.md chapter in the official manual].
For TPM, replace the crypttab and systemd-cryptsetup option <code>fido2-device=auto</code> with <code>tpm-device=auto</code> for systemd stage 1. See [https://github.com/NixOS/nixpkgs/blob/7be68f763d94cdb4c809b7980647828e3274a511/nixos/tests/systemd-initrd-luks-tpm2.nix this integration test] in the nixpkgs source code repository.
Because the TPM is attached to your computer, it provides no protection against a stolen computer when used on its own (it usually allows for setting a password, but that is it). It can only protect against a stolen drive.


= zimbatm's laptop recommendation =
= zimbatm's laptop recommendation =
Line 178: Line 221:
     "cryptd"
     "cryptd"
   ];
   ];
}
</syntaxhighlight>
= Unlocking secondary drives =
Consider the following example: a secondary hard disk <code>/dev/sdb</code> is to be LUKS-encrypted and unlocked during boot, in addition to <code>/dev/sda</code>.
Encrypt the drive and create the filesystem on it (LVM is used in this example):
<syntaxhighlight lang="bash">
cryptsetup luksFormat --label CRYPTSTORAGE /dev/sdb
cryptsetup open /dev/sdb cryptstorage
pvcreate /dev/mapper/cryptstorage
vgcreate vg-storage /dev/mapper/cryptstorage
lvcreate -l 100%FREE -n storage vg-storage
mkfs.ext4 -L STORAGE /dev/vg-storage/storage
</syntaxhighlight>
To unlock this device on boot in addition to the encrypted root filesystem, there are two options:
=== Option 1: Unlock before boot using a password ===
Set the following in <code>configuration.nix</code> (replacing <code>UUID-OF-SDB</code> with the actual UUID of <code>/dev/sdb</code>):
<syntaxhighlight lang="nix">
{
  boot.initrd.luks.devices.cryptstorage.device = "/dev/disk/by-uuid/UUID-OF-SDB";
}
</syntaxhighlight>
During boot, a password prompt for the second drive will be displayed. Passwords previously entered are tried automatically to also unlock the second drive. This means that if you use the same passwords to encrypt both your main and secondary drives, you will only have to enter it once to unlock both.
The decrypted drive will be unlocked and made available under <code>/dev/mapper/cryptstorage</code> for mounting.
One annoyance with this approach is that reusing entered passwords only happens on the initial attempt. If you mistype the password for your main drive on the first try, you will now have to re-enter it twice, once for the main drive and again for the second drive, even if the passwords are the same.
=== Option 2: Unlock after boot using crypttab and a keyfile ===
Alternatively, you can create a keyfile stored on your root partition to unlock the second drive just before booting completes. This can be done using the <code>/etc/crypttab</code> file (see manpage <code>crypttab(5)</code>).
First, create a keyfile for your secondary drive, store it safely and add it as a LUKS key:
<syntaxhighlight lang="bash">
dd bs=512 count=4 if=/dev/random of=/root/mykeyfile.key iflag=fullblock
chmod 400 /root/mykeyfile.key
cryptsetup luksAddKey /dev/sdb /root/mykeyfile.key
</syntaxhighlight>
Next, create <code>/etc/crypttab</code> in <code>configuration.nix</code> using the following option (replacing <code>UUID-OF-SDB</code> with the actual UUID of <code>/dev/sdb</code>):
<syntaxhighlight lang="nix">
{
  environment.etc.crypttab.text = ''
    cryptstorage UUID=UUID-OF-SDB /root/mykeyfile.key
  '';
}
</syntaxhighlight>
With this approach, the secondary drive is unlocked just before the boot process completes, without the need to enter its password.
Again, the secondary drive will be unlocked and made available under <code>/dev/mapper/cryptstorage</code> for mounting.
= Autologin using LUKS password =
One downside of full disk encryption is that you need to type in your password twice, once for unlocking the disk and once to log into your desktop. One approach is to skip the LUKS password, such as by using a TPM2, but is [https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/ difficult to properly secure]. The other approach is to enable autologin for your display manager:
<syntaxhighlight lang="nix">
{
  services.displayManager.autoLogin.user = "my username";
}
</syntaxhighlight>
However, this breaks software such as KWallet which uses the login password to automatically unlock its keyring. The solution is to set the LUKS password, login password, and KWallet keyring password all to the same string, and then use the LUKS password to unlock KWallet. The LUKS password is first collected by a systemd initrd, saved to the kernel keyring, read out by SDDM via a PAM module, then finally passed off to KWallet.
<syntaxhighlight lang="nix">
{
  boot.initrd.systemd.enable = true;
  systemd.services.display-manager.serviceConfig.KeyringMode = "inherit";
  security.pam.services.sddm-autologin.text = pkgs.lib.mkBefore ''
    auth optional ${pkgs.systemd}/lib/security/pam_systemd_loadkey.so
    auth include sddm
  '';
}
}
</syntaxhighlight>
</syntaxhighlight>
Line 188: Line 306:
* Have a look at https://wiki.archlinux.org/index.php/Disk_encryption to see all the possible options. This wiki page is not complete.
* Have a look at https://wiki.archlinux.org/index.php/Disk_encryption to see all the possible options. This wiki page is not complete.
* [https://gist.github.com/ladinu/bfebdd90a5afd45dec811296016b2a3f Installation with encrypted /boot]
* [https://gist.github.com/ladinu/bfebdd90a5afd45dec811296016b2a3f Installation with encrypted /boot]
* [[Remote LUKS Unlocking|Using Tor and SSH to unlock your LUKS Disk over the internet]].
* [[Remote disk unlocking|Using Tor and SSH to unlock your LUKS Disk over the internet]].
* [[Bcachefs]], filesystem which supports native encryption
* [https://discourse.nixos.org/t/full-disk-encryption-tpm2/29454/2 Automatically unlock encrypted disks using TPM2]
 
[[Category:Desktop]]
[[Category:Server]]
Retrieved from "https://wiki.nixos.org/wiki/Full_Disk_Encryption"