Manual Full System Encryption has been updated and simplified

[Paddy Landau]

I have updated the documentation for Manual Full System Encryption, and vastly simplified it in the process.

For those who don't know, this allows you to encrypt everything including /boot, excluding the EFI System Partition for obvious reasons, and it plays nicely with other systems, e.g. Windows.

If you choose to try it, please let me know (in this thread) if it works for you and if you find any bugs in the documentation or the process.

Whether or not it works, it would be helpful to know which flavour and version you use.

Please read the warnings and caveats before deciding whether or not to use it. Ignoring them could leave you disappointed.

If you like it, and want Canonical to officially implement it or something like it in the Installer, please support the request (log in and select the green writing at the top left).

Thank you

EDIT: Jernej Jakob has created instructions to convert an unencrypted installation to an encrypted one. I have not tested it, but Jernej says that it works on Ubuntu.

EDIT: Tj has created an alternative how-to that might supersede this method (I haven't tested it, but it looks good).

[DuckHook]

Wow Paddy,

You put a ton of work into this. Thank you.

[tpa76000]

Hi Paddy,

Congratulations for such a huge work! You help us so much.

Just want to submit a (little) bug on your script. Modern laptops (SSD with PCIExpress) have their partitions named /dev/nvme* (and not /dev/sd* anymore).

I think you should only require "/dev/" on your prompt, and not "/dev/sd"

Thanks again for all this work!
Paul

[Paddy Landau]

Thanks for the report, Paul. I had thought that Ubuntu was fixed in the matter, but clearly I had thought wrong!

Would the equivalent of, say, /dev/sda2 be /dev/nmvea2? I need to be clear on the syntax for error-checking.

[shelln00b]

The guide explains how to encrypt the boot partition, but EFI is still unencrypted and it looks like there's no difference in pwning the OS, as explained at https://twopointfouristan.wordpress....sk-encryption/: instead of working on /boot beacuse it's encrypted, work on EFI to maliciously changing it, right?

You commented there confirming that EFI should be signed to prevent this. Is this the final solution to prevent this type of attacks? How about other Distro that have not a signed bootloader to enforce Secure Boot, like Debian?
(I know this forum is for Ubuntu only, but I will apreciate any help, especially beacuse this is the only guide on the topic.)

A big thanks for your work,
shelln00b

[j.folwer]

The guide explains how to encrypt the boot partition, but EFI is still unencrypted and it looks like there's no difference in pwning the OS, as explained at https://twopointfouristan.wordpress....sk-encryption/: instead of working on /boot beacuse it's encrypted, work on EFI to maliciously changing it, right?

You commented there confirming that EFI should be signed to prevent this. Is this the final solution to prevent this type of attacks? How about other Distro that have not a signed bootloader to enforce Secure Boot, like Debian?

The EFI partition must be left unencrypted and it's used for other systems too. The efi is protected by SecureBoot: That is, every boot loader is signed and verified by the UEFI boot process before being launched. Also, each bootloader verifies in turn the files it loads in something like a "chain of trust" where each additional piece (boot loader -> kernel -> initramfs) is verified by the previous piece.

Now, the keys used to verify each piece come from various places. There's a built-in key from Microsoft in all new computers. There's also a secondary key, still owned by Microsoft, but which is used to sign third party loaders.

The common way of booting linux on a secureboot system is using the shim bootloader, which loads grub2 (verifying that it has been signed itself). In ubuntu, the installer will create and "enroll" what is known as MOK (machine owner keys). These keys can be generated and verified by the computer owner and once installed they can be used to sign bootloaders, kernels and, more importantly, third part drivers (like nvidia) which would never be available without (i.e. you cannot install a third party driver and load it into the kernel if it's not signed).

Speaking of which, I'm still having issues booting my full disk encrypted dual-booting (Win+Ubuntu) notebook when I enable secureboot enforcing in the bios. This means somewhere in the chain of command something is not properly signed and it just won't boot. If I disable the secureboot eforcement, everything is OK and ubuntu boots.

The whole point of signing the efi binaries (and rest) is to prevent that somebody can modify the efi and trick the owner into typing their password in a keylogger.

[j.folwer]

Thanks for the report, Paul. I had thought that Ubuntu was fixed in the matter, but clearly I had thought wrong!

Would the equivalent of, say, /dev/sda2 be /dev/nmvea2? I need to be clear on the syntax for error-checking.

I can answer that. The naming scheme is a little more complex. The tipical disk is named /dev/nvmeXnYpZ where eX is the nvme channel (supposedly) starting from 0, nY is the number of nvme disk on that channel and pZ is the partition. Nvme channel start at 0 and disk and partition both start at 1 (that is the first nvme disk is /dev/nvme0n1 and the first partition is /dev/nvme0n1p1). My EFI partition is /dev/nvme0n1p1 (not sure if efi is fixed by some agreed standard or not).

[Paddy Landau]

The guide explains how to encrypt the boot partition, but EFI is still unencrypted…

The EFI partition must be left unencrypted…

@j.fowler, thank you for answering the question far more competently than I could have! I'm not terribly technically au fait, having put together the process through sheer dogged persistence and plenty of help from others.

I can answer that…

Thank you. I shall change the process to be as flexible as possible. It will, unfortunately, remove some of the robustness, which I had wanted for the newcomers, but that's the price we pay for lack of standards, I suppose.

I'll update this thread once I have succeeded; today, I hope, but cannot promise.

[Paddy Landau]

I have updated the process and the documentation to allow for other naming conventions, so if you use (say) /dev/nvme0…, you can use it.

The change was good, because it has also made the scripts more robust against errors.

Thank you for your behind-the-scenes help and for your patience.

[j.folwer]

I have updated the process and the documentation to allow for other naming conventions, so if you use (say) /dev/nvme0…, you can use it.
The change was good, because it has also made the scripts more robust against errors.
Thank you for your behind-the-scenes help and for your patience.

I apologize, I stand corrected. I wrote the disk details from memory, but memory is not good as it used to be. I've updated my post with the nvme numbering, and precisely: "The tipical disk is named /dev/nvmeXnYpZ where eX is the nvme channel (supposedly) starting from 0, nY is the number of nvme disk on that channel and pZ is the partition". BTW, I see you caught that mistake

j.fowler

PS: I'm now digging in the details of shim loading / mok signing and grub signing it's own config and modules via openpgp. I found some documents about signing initrd and grub.cfg with opengpg keys (not mok keys) and perhaps enabling custom keys in the secureboot env, which could enable us to have the boot unencrypted but still signed and checked, in case unlocking boot/lvm with cryptomount is not a viable option. I was really hoping not to have to read shim's and grub's source code and hoping to understand how to debug the key validation, and why GRUB_CRYPTED_DISK=y loads cryptomount module only with secureboot disabled. No eta on that tough.