‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 21, 2021 4:13 PM, ken <gebser@xxxxxxxxxxxx> wrote:
> A new laptop is on the way and I'm considering using dm-crypt 2 secure the whole SSD. I have some basic questions though.
>
> Is it possible to encrypt the entire Drive, including all the system files?
>
> dm-crypt mailing list -- dm-crypt@xxxxxxxx
> To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
This is a complex topic because there are several ways to encrypt entire drive (which is called FDE - full disk ecnryption) and because it depends on several tools (dmcrypt, cryptsetup, initrd, bootloader, file system, possibly lvm) working together. This topic is further complicated because initrd, filesystem, bootloader may vary (which means this question is beyond of scope of dmcrypt).
First of all, encrypting 'entire drive' can mean two things: literally encrypting entire drive (#1) or leaving bootloader (residing on such drive) unencrypted (#2). Since neither BIOS nor EFI support decrypting bootloaders, some part of bootloader must be left unencrypted anyway. This means if you encrypt entire drive (#1), you must also have the second drive during boot because no BIOS/EFI firmware can decrypt partitions/drives. But if you do not need the second drive in boot process per se, you can move bootloader to unencrypted partition and have a single drive (scenario #2). So basically scenario #2 results in having encrypted as much as possible (including all system files, which you mentioned in the question), taking into account technical limitations of BIOS/EFI firmware.
Assuming scenario #2 and EFI machine there are several 'schemes' to do FDE.
1. Leaving unencrypted only portion of bootloader on EFI partition. AFAIK, only grub supports that. It can embed some minimal crypto modules in its core image in efi file which resides in EFI partition. During boot the core image ('efi file') asks password, decrypts the partition where the rest of grub bootloader code resides and loads its. Probably systemd bootloader also supports this scheme, but I am not sure (I use grub). In this scenario initrd or LUKS keyfiles can reside inside encrypted partitions with no security concers during boot process (except that these keyfiles can be compromised when system is booted - if an attacker gains root access it can read any file, including keyfiles).
Example of such setup: grub resides in EFI partition and on root partition. Root partition resides on LVM volume on top of LUKS/plain dm-crypt real GPT (sda/sdb/sdx) partition. During boot grub asks password for decrypting LUKS partition. In this case initrd image either asks password during boot (for the second time) or keyfile is embeded into initrd image (this depends on which initrd is used). In the latter case when system is booted an attacker which gained root access can read initrd image and get the keyfile.
2. Leaving bootloader fully unencrypted. Theoreticaly anyone which has psysical access to your drive can compromise the bootloader, but this is extremely theoretical scenario. In this case during boot you must provide passphase to decrypt root partition (possibly LVM partition which contains root/home/other partitions). In general, this case is similar to 1.
3. Leaving bootloader and initrd/linux image unencrypted. This means during boot initrd will ask the password (or keyfile on special drive) to decrypt root partition - in this case only once (if all partitions reside on LVM which resides on top of LUKS/plain dm-crypt partition). In this scenario not only bootloader, but also initrd and linux image can be theoretically compromised.
Actually, there are more configurations which were mentioned. Technically kernel image can be located in encrypted location while initrd left on unencrypted partition (and vice versa) - although such configuration has little sense. Swap partition can be located on LVM volume or on separate partition. Bootloader can be located on EFI partition or partially on some secondary partition. Initrd and kernel image can be located on encrypted root partition or on a separate partition. Initrd can be configured via crypttab to decrypt root partition with password prompt or via keyfile. Well, keyfiles can be located on separate drive which must be plugged in order to boot machine. Or they can be placed in root partition and marked as read-root-only (hoping attacker will not have root access). Or keyfiles can be located on some separate encryption partition which protects them after boot.
More information can be found in archlinux wiki (https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system) which contains quite decent manual for entire drive encryption. Gentoo also has some information (https://wiki.gentoo.org/wiki/Full_Disk_Encryption_From_Scratch_Simplified) but it is more limited. It should be noted that both wiki contain distro-specific information which is likely is not applicable to your distribution.
* Regarding compromising bootloader or initrd/linux image. These are theoretical threats - I have not heard any public case when some entity (for example, government) hacked someone through bootloader/initrd/linux image. This means some tools allow to protect them, but this is probably overkill.
** Regarding choice between LVM and several GPT partitions. If you have several GPT partitions, you must provide passwords for all of them and keep entries in /etc/cryptab for each partition. So, if you have root and home partitions (not counting boot partition), you have to type (at least) two passwords during boot (possibly two times for root partition - to unlock initrd/linux image if it is located in encrypted root). If you have encrypted root, home and swap partition - you have to type three passwords for each partition. LVM can simplify things here - you can have LVM volumes on top of single real (GPT) partition which is encrypted (LUKS or dm-crypt). In this case you type password only once - for the single LUKS/plain dm-crypt partition. Once it is decrypted, initrd can activate LVM partitions and mount them according to /etc/fstab entries without asking password (keyfiles) for each lvm volume (which acts as virtual volume).
*** Encrypted drive/partition can contain several partitions/LVM volumes which can complicate boot process, but some technical considerations should be taken into account: 1) EFI firmware can load bootloader only from unencrypted real (GPT) partition, 2) bootloader must support encryption and file system where initrd/linux image is located, 3) initrd image must be configured to unlock root partition - either by asking password or by reading keyfile from some place which is accessible to initrd during boot process.
Best regards,
Maxim Fomin
_______________________________________________
dm-crypt mailing list -- dm-crypt@xxxxxxxx
To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
