LUKS inside LUKS

[xennex81]

Does anyone know if it is possible to load a LUKS inside a LUKS?

I mean one outer LUKS then LVM then LUKS for individual partitions, so you can differentiate between the passwords for the extra partitions.

The idea is then to have the outer LUKS pass its password to the root partition of the inner luks.

There is a thing called decrypt_keyctl that will maintain a password between decrypted devices.

The idea would then be to have a crypttab with:

sda5_crypt       /dev/sda5   keyid   luks,keyscript=decrypt_keyctl
decrypted_root   /dev/mapper/kubuntu-cryptroot   keyid   luks,keyscript=decrypt_keyctl

so sda5 is a crypted device that opens onto sda5_crypt (mapped), which is opened by LVM which results in several partitions such as "cryptroot" in the volume group "kubuntu", this cryptroot obtains the same key as the initial sda5/sda5_crypt device (through decrypt_keyctl) allowing it to be opened without further ado.

then the final mapping is /dev/mapper/kubuntu-cryptroot unto /dev/mapper/decrypted_root which is the filesystem with ext3 on it, in my case.

This allows for several volumes to be either encrypted or not encrypted, or encrypted with different passwords, or not at all, depending on a base system that allows for a rather meagre or mediocre password.

Then you can have a differential setup in which the base system is easier to gain access to than a deeper level. This allows for several levels, or parts, to your crypt defense. The most sensitive data can then be stored on a crypt device that does not obtain access directly from your access to the main system.

This requires that at boot-up there are two rounds to the decrypting: a first round where the LVM is opened, and a second round where discovered crypto devices are opened from within the LVM.

--I believe I have seen something of the kind in the cryptroot/initramfs scripts.--

But I am unable to test it at this point.

[xennex81]

There is also a separation between the loading of the initial root (or resume) devices and later crypto devices that are not needed at boot. These later devices are loaded by /etc/init/ scripts I believe. I am not sure whether you can skip them during that phase. But these devices are not needed or loaded when the initramfs is running.

I believe. It doesn´t randomly load /all/ devices. It loads only those it needs.

It would be vital for me (or for a user friendly system) that such additional devices would be openable through a reasonably user-friendly process. For instance, a KDE applet that would prompt a device opening at login. Then you could additionally think about providing hidden volumes inside the additional devices.

[xennex81]

Another thing that is possible is to keep a keyfile inside the initramfs and to use it to decrypt the boot/root partition after the boot partition has already been decrypted by GRUB. You can have a fully encrypted boot/root partition (e.g. inside a single LVM container) by passing a keyfile to the initramfs-tools when they create the initramfs. The keyfile is hidden inside the encrypted volume, which is decrypted at boot by GRUB. The keyfile is used by the initramfs to decrypt it once more (because GRUB doesn´t pass it to the kernel) such that you only need to provide the password once. The downside is that you have the keyfile (which is a second slot for the same LUKS header) located on the decrypted boot/root device itself. An attacker could obtain the keyfile easily and thereby attain the secret for the running system that it gained access to. On the other hand it is said that the decrypted headers are easily obtainable from a running system as well.