Sorry for this noob question but I’m wondering why I’m finding so little about the topic in connection with Manjaro: I’m currently toying with the idea of encrypting my boot partition. Currently, I have encrypted / and /swap with LUKS as normal, but it is a thorn in my eye that /boot is not protected and thus, from my point of view, there are some attack vectors. I’ve already read a lot, especially GRUB - ArchWiki but I’d be very interested to know if any of you use LUKS-encrypted /boot and if you have any stumbling blocks in mind.
LUKS works on software level, and at least some application needs to run first. And that application is the Linux kernel that has been booted. So you cannot encrypt the partition mounted with “/boot”, or else you won’t be able to load the GRUB bootloader and other identified OSes like Manjaro (this is the traditional way). There’s some way (I believe it’s still rather new) to do this with LUKS, but I rather not to do it because it’s more complicated than just simple booting (something like tweaking to run a simple initial bootloader that decrypts the GRUB then the GRUB runs).
If you want to provide full disk encryption, the application that perform the disk encryption / decryption must be the one from before bootloader takes in the computer, that is the BIOS/UEFI. Modern PCs and laptops have some way to add internal disk encryption from the BIOS/UEFI setup, and like LUKS, passphrase is used as the secret.
For a further insight on security, regarding the attack vectors, you need to think further what kind of “security asset” you want to protect. Disk encryption provides confidentiality, so it make sense to do this on partition with “/home”. But if you feel you want to maintain confidentiality on how you use your GNU/Linux system, then disk encryption on partition with “/” and its subdirectories (excluding “/boot”) makes sense. And further, if you want to maintain a secret of the list of OSes you use in your computer system, then you need to use BIOS/UEFI or LUKS with some tweaks on GRUB.
Generally though, I never use disk encryption and just use GPG with my keys stored in a USB thumbdrive (I regard my USB thumbdrive as a private asset no body can use). This is because passphrase is still easy to break than encryption keys. LUKS may use encryption keys, but the keys are derived from passphrase, so the weakest link is still the passphrase. For me, I don’t mind if the content of “/” I’m using is known to adversaries, but not the home directory.
Thank you very much for this detailed answer and your thoughts about it.
I’m a remote software developer but travel sometimes by train to my company. On the train, I am ultimately less concerned with the encryption of the bootloader than with its integrity. I don’t want the bootloader to be able to be adjusted without my knowledge, for example, to have access to my data after decryption from / via it. I just want to make sure that the bootloader cannot be easily modified without it being noticed.
Thanks for mentioning that but I didn’t find something regarding my laptop, a Dell XPS 15 (7590), what is this technique called (edit: is it UEFI SecureBoot?)?
As @eugen-b said, you cannot encrypt /boot/efi which is in the EFI partition; this is where GRUB resides. The one in the /boot directory is the Linux kernel, in which disk encryption is still possible.
I can’t tell the details on how to do LUKS on GRUB (based on the Arch wiki link given) since I dont’ really know the details on how to configure GRUB to perform the disk encryption / decryption on the /boot (the traditional way is the kernel needs to run first to perform disk decryption).
As for disk encryption / decryption by BIOS/UEFI, there should be some choice “disk encryption” on the BIOS/UEFI settings. If you don’t see it, it isn’t supported by the BIOS/UEFI.
SecureBoot is a different thing. Secure boot is a generic term meaning to authenticate bootloader; not just for PC and laptop, but embedded system can have this technology.
Process:
The bootloader was signed previously by a trusted entity.
The firmware (BIOS/UEFI in PC and laptop) verifies bootloader in the system before passing its execution to it.
If the bootloader signature is verified, the bootloader is authentic (the trusted entity confirm this by signing it previously), and bootloader can run.
If it is not verified, the system won’t proceed because the bootloader is untrusted (maybe a fake one inserted by adversaries).
For UEFI/BIOS, secure boot is to authenticate that a bootloader you’re using is “approved” by Microsoft. Microsoft doesn’t want to sign GNU/Linux ecosystem, so that’s why you need to turn off secure boot (this is why many people believe Microsoft hinders the spread of GNU/Linux distro).
Your needs is in integrity check. The current stable LUKS is targeted for confidentiality, not for integrity. Even if you use disk encryption, someone may still corrupt your encrypted disk and it may go unnoticed when you decrypt your disk. I think the new LUKS (LUKS2) also support AEAD, an authenticated encryption. This can provide authenticity (implicit integrity) to your encrypted disk but I think this is still experimental. But you should see LUKS2 if you want this.
If there’s no more good options, use GPG on files you believe you want to keep confidentiality (AES-128 CBC is good for now) and integrity (SHA-256 is good for now). It’s a tradeoff between security and user-friendliness.
Encryption also provides integrity as a side effect. Because if the integrity of encrypted data is damaged then you won’t be able to decrypt them. You’ll get rubbish.
It won’t go unnoticed, the chance is very very low. Most likely you will get rubbish all over the disk. Data recovery for instance is very difficult on an encrypted disk, therefore backups are even more important.
@sailreal simply back up your data, reinstall with encrypted everithing (except /boot/efi) and copy your data back.
If you want you can try to install /boot/efi on a separate small USB stick and carry it in a secure place.
That is exactly what I’m just thinking about, encrypting /boot and putting /boot/efi on a USB stick. If I proceed this way, my system no longer have a real weak point if I haven’t overlooked anything (of course, taking into account that encryption provides integrity as a side effect not 100% but 99.x%)?
No, pure encryption only provides confidentiality. You can still decrypt damaged data. But I get your way of thinking. Your way of thinking is applicable if the original file has some syntactical structure in it. If the syntax of the structure is damaged, then you know for sure that the file has been damaged and you don’t need any integrity mechanism like hashing. This is also a valid way of preserving integrity, albeit a very weak one.
In case of the Linux filesystem itself, there’s definetely some structure in it (filesystem internal data structure). If after decrypting and it happens that there’s some invalid internal filesystem data structure parsing by the kernel, then definetly the disk has been damaged. But it’s still possible that the damage only change the values of valid data structure, that may cause say different file attributes from the original. Or it can be that the damage after decryption isn’t in the filesystem data structure itself, but in the content of regular files, which may be left unnoticed.
It’s not hard, and not easy either, to pinpoint some area of disk of interest (say possible location of a bunch of regular files) and change the bits, provided that some attackers know the possible layout of Manjaro filesystem. Current strong pure encryption and decryption algorithms like AES-CBC family work on blocks, so changing bits only affect that block (very low entropy). This is different than hashing or a signature, when a change in 1 bit means a big propagation of changes on the whole data (high entropy).
Smart, I didn’t think of this. @sailreal can follow this advice. But try see LUKS2 for any AEAD like AES-GCM or AES-CCM, but avoid AES-CBC since this is not AEAD. AEAD implicitly provides integrity.
Follow @eugen-b advice using external USB stick for /boot/efi
Keep your USB stick in a secure place or just bring it with you (not leaving it plugged into the laptop)
Use AEAD for disk encryption
Then you’ll protect confidentiality, authenticity, and integrity (implicit gain from authenticity) for your system. You’re good to go.
A reminder: this will be a trade off between userfriendliness where you need to constantly plug your USB stick then wait for the decryption and security.
To try it out, you can leave your current system intact, but indeed created the USB with a /boot/efi and LUKS encrypted /boot first. The USB needs to be bootable anyway for the grub EFI and this way you don’t even have to touch your existing /boot (just boot device priority). If it works fine, just rinse, repeat the grub-install command.
Next caveat, I’d like to add: GRUB does not support the new LUKS2 format. This does not impair on your existing system (your initramfs supports LUKS2), but the encrypted /boot. Further, you will notice the GRUB decryption (i.e. unlocking encrypted /boot) is rather slow. So, you best test what is acceptable for you to unlock the /boot. Keep in mind you can reencrypt occasionally too (very simple for a small /boot). My 2c for AEAD: skip that, for now it’ll require a full reinstallation of your machine. I also agree with @eugen-b on the point. If someone with physical maliciously messed the LUKS encrypted device, your filesystem will report problems on mount too. Of course, it’s your data, your risk evaluation, your → backup <–.