View previous topic :: View next topic |
Author |
Message |
L1NTHALO n00b
Joined: 27 Aug 2024 Posts: 29
|
Posted: Wed Dec 04, 2024 12:09 pm Post subject: Question about Full Disk Encryption wiki entry |
|
|
Hey,
trying to encrypt my laptop with FDE and I'm currently following the wiki entry for FDE (https://wiki.gentoo.org/wiki/Full_Disk_Encryption_From_Scratch).
I'm confused by some parts:
1. I want to create a detached header on an USB drive with which to encrypt the disk. I've created that header but if I now create a key file for that disk, it says it isn't encrypted (/dev/nvme0n1p1 is not a valid LUKS device).
2. The wiki says to create all your headers, key files etc but then after that you should format your disks? What am I missing?
3. What do I need an Extended Boot Partition for? Is it only for MBR? Will putting the detached header, key files, initramfs and kernel image on the EFI drive work with grub?
4. Do I need GRUB or can you also do the whole process with EFISTUB?
Thank in advance! |
|
Back to top |
|
|
GDH-gentoo Veteran
Joined: 20 Jul 2019 Posts: 1735 Location: South America
|
Posted: Wed Dec 04, 2024 2:13 pm Post subject: |
|
|
L1NTHALO wrote: | 1. I want to create a detached header on an USB drive with which to encrypt the disk. I've created that header but if I now create a key file for that disk, it says it isn't encrypted (/dev/nvme0n1p1 is not a valid LUKS device). |
Creating the key file comes first, it must exist before you create the LUKS container, because you need to tell cryptsetup luksFormat about it.
L1NTHALO wrote: | 2. The wiki says to create all your headers, key files etc but then after that you should format your disks? What am I missing? |
After you create the LUKS container, you must open it with cryptsetup open and create a filesystem. That's section 6 of the Wiki article.
L1NTHALO wrote: | 3. What do I need an Extended Boot Partition for? Is it only for MBR? Will putting the detached header, key files, initramfs and kernel image on the EFI drive work with grub? |
No, the Wiki article talks about an EFI System Partition (ESP), so it assumes a UEFI installation. The Extended Boot Partition is mounted at /boot and holds kernel, initramfs and GRUB stuff (including its configuration file). I suppose that the article chose that partition layout to make it easier to do the installation of GRUB, kernel and initramfs according to the Handbook.
Yes, all those could be in the ESP I believe.
L1NTHALO wrote: | 4. Do I need GRUB or can you also do the whole process with EFISTUB? |
You could in theory, but if you are using a separate initramfs, you rely heavily on the UEFI firmware's ability to correctly handle Boot#### variables and pass an initrd= kernel parameter to the EFI stub.
Otherwise, you have to embed the initramfs in the kernel, and that requires customizing the kernel's configuration, as shown in section 7.3 of that Wiki article. _________________
NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer |
Ionen wrote: | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
Last edited by GDH-gentoo on Wed Dec 04, 2024 2:34 pm; edited 2 times in total |
|
Back to top |
|
|
zen_desu n00b
Joined: 25 Oct 2024 Posts: 41
|
Posted: Wed Dec 04, 2024 2:20 pm Post subject: |
|
|
Everything stated above is accurate and true. there are multiple partition schemes shown on the rootfs encryption page, I plan to do something similar with the FDE page. A /boot partition if you have an ESP is entirely optional. Some people prefer this because it means you can use fancier filesystem things (fancier than fat32 at least).
Concerning header files and key files, those could be stored on an ESP but it's worth noting that ESPs are generally easily readable. _________________ µgRD dev
Wiki writer |
|
Back to top |
|
|
sMueggli Guru
Joined: 03 Sep 2022 Posts: 503
|
Posted: Wed Dec 04, 2024 5:29 pm Post subject: |
|
|
What is your definition of FDE? Do you want to encrypt kernel and initramfs also? |
|
Back to top |
|
|
L1NTHALO n00b
Joined: 27 Aug 2024 Posts: 29
|
Posted: Thu Dec 05, 2024 12:10 am Post subject: |
|
|
Want to encrypt the whole drive and store the kernel and initramfs on a seperate unencrypted USB drive.
I've got it mostly working now but I'm not sure if I set it up correctly for a swap partition.
Currently I have an encrypted root partition and encrypted swap partition, both with seperate headers and one shared key file on the usb stick. Is that how you would do it? |
|
Back to top |
|
|
zen_desu n00b
Joined: 25 Oct 2024 Posts: 41
|
Posted: Thu Dec 05, 2024 12:13 am Post subject: |
|
|
L1NTHALO wrote: | Want to encrypt the whole drive and store the kernel and initramfs on a seperate unencrypted USB drive.
I've got it mostly working now but I'm not sure if I set it up correctly for a swap partition.
Currently I have an encrypted root partition and encrypted swap partition, both with seperate headers and one shared key file on the usb stick. Is that how you would do it? |
I would not share a key file, you can have a separate one and possibly store it on the rootfs, where it's used later. If you use the dm-crypt service, it can setup a swap partition with a random key at every boot. This is nice if you don't plan to hibernate. _________________ µgRD dev
Wiki writer |
|
Back to top |
|
|
L1NTHALO n00b
Joined: 27 Aug 2024 Posts: 29
|
Posted: Thu Dec 05, 2024 12:17 am Post subject: |
|
|
I do plan to hibernate so unfortunately that's not an option. How would your suggestion work? If I hibernate does both the rootfs and swap partition get encrypted and I decrypt rootfs and then swap? |
|
Back to top |
|
|
L1NTHALO n00b
Joined: 27 Aug 2024 Posts: 29
|
Posted: Thu Dec 05, 2024 12:25 am Post subject: |
|
|
Hey, since you're an ugRD dev, when doing make install I get an ugRD error that I miss the kernel module uas.
Not exactly sure what that module is, the nearest module I found was USB_UAS which I enabled.
Was planning on doing a new thread, but maybe you've got an idea? |
|
Back to top |
|
|
zen_desu n00b
Joined: 25 Oct 2024 Posts: 41
|
Posted: Thu Dec 05, 2024 12:28 am Post subject: |
|
|
L1NTHALO wrote: | I do plan to hibernate so unfortunately that's not an option. How would your suggestion work? If I hibernate does both the rootfs and swap partition get encrypted and I decrypt rootfs and then swap? |
If you hibernate, you technically only need to decrypt the swap, and then that restores RAM and whatnot and the root is already mounted.
"resuming" is literally doing echo -n "/path/to/swap/dev" > /sys/power/resume
which restores the ram to the state it was in when you hibernated.
LVM is often used with encrypted swap so it can be under the same LUKS container as the root, and only one key needs to be used. There isn't too much wrong with sharing a key between the two, but I generally avoid reusing keys in any way if possible. _________________ µgRD dev
Wiki writer
Last edited by zen_desu on Thu Dec 05, 2024 1:11 am; edited 1 time in total |
|
Back to top |
|
|
zen_desu n00b
Joined: 25 Oct 2024 Posts: 41
|
Posted: Thu Dec 05, 2024 12:29 am Post subject: |
|
|
L1NTHALO wrote: | Hey, since you're an ugRD dev, when doing make install I get an ugRD error that I miss the kernel module uas.
Not exactly sure what that module is, the nearest module I found was USB_UAS which I enabled.
Was planning on doing a new thread, but maybe you've got an idea? |
You could start a new thread, open an issue, ask in the discord, or ask in the irc. If you're running it directly, it reads kmods from the current running kernel version, sometimes this causes issues and another kernel version can be specified with --kver, you can read possible kernels from /usr/lib/modules
Checking on my system now, I have ugrd configured to look for the module named "uas", which corresponds to "CONFIG_USB_UAS", if you have it builtin, it won't be able to find the kmod so that's fine, but I would expect modinfo to say it's builtin when "uas" is queried. Ugrd more or less parses "modinfo -k <kver> modname", and builtin modules are generally put in modules.builtin.
It's also worth noting that ugrd doesn't currently support resuming from encrypted swap, there is a PR here which makes it possible.
https://github.com/desultory/ugrd/pull/139
I'm hesitating to add this and the person who made that PR has been testing it more thoroughly, but I'm paranoid about somehow accidentally writing to disks before resuming: https://www.kernel.org/doc/html/latest/power/swsusp.html _________________ µgRD dev
Wiki writer
Last edited by zen_desu on Thu Dec 05, 2024 12:41 am; edited 1 time in total |
|
Back to top |
|
|
L1NTHALO n00b
Joined: 27 Aug 2024 Posts: 29
|
Posted: Thu Dec 05, 2024 12:35 am Post subject: |
|
|
Thanks! If I'd still like to use hibernate, would using dracut be more beneficial?
Also if only the swap gets encrypted during hibernate, can't you tamper with the unencrypted rootfs and either get the data from there or get the key for the encrypted swap? |
|
Back to top |
|
|
zen_desu n00b
Joined: 25 Oct 2024 Posts: 41
|
Posted: Thu Dec 05, 2024 12:46 am Post subject: |
|
|
L1NTHALO wrote: | Thanks! If I'd still like to use hibernate, would using dracut be more beneficial?
Also if only the swap gets encrypted during hibernate, can't you tamper with the unencrypted rootfs and either get the data from there or get the key for the encrypted swap? |
I think dracut should currently support this, you're welcome to try that PR/truffle0's branch as well. The way it is implemented seems fine, but I'm not sure if it's worth taking extra measures to absolutely ensure nothing is written. AFAICT dracut and other systems do not take any extra measures, so I don't think it is as much of a risk as the kernel docs suggest.
fwiw the patches simply make it run the resume procedure a bit later, normally it would run after initial mounts, but this makes it run after luks/lvm actions. If you want to do this yourself, you can do a small edit to the init file in the initramfs. By default ugrd mounts everything 'ro' unless you take manual measures to make it 'rw', but im not sure if this is enough to ensure not a single bit is written, even to metadata portions, across any fs type.
If the root and swap use the same key, someone would need that key to meaningfully tamper with the data on either the swap or root. If they are somehow able to decrypt the swap, and the root has a different key, I think they may be able to derive the root key.
No matter how it's stored, if someone is able to properly modify your swap, they can make the system do whatever they want when it's resumed. A large part of why I have not added resume support to ugrd is it spooks me a bit so I do not use it. I've only added it and tested it as much as it's been requested. _________________ µgRD dev
Wiki writer |
|
Back to top |
|
|
L1NTHALO n00b
Joined: 27 Aug 2024 Posts: 29
|
Posted: Thu Dec 05, 2024 12:51 am Post subject: |
|
|
Okay, thanks for the support!! |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22771
|
Posted: Thu Dec 05, 2024 1:10 am Post subject: |
|
|
L1NTHALO, you seem to misunderstand how the encryption wrapping works. When using an encrypted drive, the drive is never decrypted in place. This would be slow and expensive. Instead, the data is encrypted before writing it to the drive. When you unlock the drive, you give the kernel the ability to decrypt the data into memory as it is read from the drive - but the data on the drive remains encrypted at all times. Therefore, when using hibernation with an encrypted rootfs and encrypted swap, your root remains encrypted whether the system is halted, active, or in hibernation. As zen_desu alluded to, the key to decrypt data from the rootfs is in memory while the rootfs is unlocked, and thus that key is written into the hibernation image. For that reason, if you use an encrypted rootfs, you should not hibernate to non-encrypted swap, since that would leave your valuable rootfs decryption key vulnerable in the unencrypted hibernation data. Instead, either do not hibernate at all or hibernate to an encrypted swap.
The kernel documentation contains strong warnings about not mounting rootfs during the resume kernel, before transferring control to the hibernated kernel. One common way of protecting against that mistake is to unlock swap and root separately, and to unlock root only after failing to resume from hibernation. This way, if the system was hibernated, the first thing the resume kernel does is unlock hibernation and transfer control. It cannot accidentally mount rootfs, because it does not yet have the rootfs decryption key. |
|
Back to top |
|
|
zen_desu n00b
Joined: 25 Oct 2024 Posts: 41
|
Posted: Thu Dec 05, 2024 1:16 am Post subject: |
|
|
Yes, hibernation has to be handled carefully if you have an encrypted root. That PR's implementation runs the resume before the root is mounted, immediately after the LUKS volume is opened and LVM groups are activated. This should just be enough to enumerate the UUID and resume, without affecting data, but it doesn't prevent the rootfs from being altered within the initramfs if a recovery shell is opened.
If you have a single LUKS partition with the root under a LVM volume, and the swap as a separate one, this should work.
It's also possible to use a swap file, unlock the root volume, then resume from that file offset. _________________ µgRD dev
Wiki writer |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|