Qubes luks is not using the TPM for disk keys about heads HOT 7 CLOSED

My concern with not tying the disk key to the TPM is the ease of surreptitiously cloning the disk on the x230 -- one phillips screw and the SSD slides out -- followed by an offline (or shoulder-surfing) attack on the passphrase. If the key is derived from both the user passphrase and the TPM, then the attacker would need possession of the machine and the TPM can enforce rate limiting, etc.

from heads.

Once the kernel has been rebuilt, add the keys as before. Then check that it can be mounted with:

cryptsetup --keyfile /secret.key luksOpen /dev/dm-1 qubes-root
mount -o ro /dev/dm-3 /root

The key can be sealed and the stored in the NVRAM. The NVRAM space with the key should be password protected, which will require the user to input a password before the key can be unlocked. This will provide rate limiting.

On boot up the official initramfs can be copied to Heads' /tmp, the key can be retrieved from the NVRAM (with the password) and unsealed (based on the PCRs). This can be put into a cpio file and appended to the official initramfs -- http://unix.stackexchange.com/questions/243657/appending-files-to-initramfs-image-reliable

The kernel boot parameters need to be amended to specify the rd.luks.keyfile= for the partitions. This didn't work the first time; need to try again.

from heads.

Not sure about this. The Luks container should be verified against
tampering. The disk shouldn't be bound to a single computer.

from heads.

Hackish way to test it out -- extract Qubes initrd into /tmp/, chroot into it and activate the disk:

chroot /tmp/initrd
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devtmpfs none /dev
lvm lvchange -a y qubes_dom0
lvm lvscan
cryptsetup luksDump /dev/dm-0
cryptsetup luksAddKey /dev/dm-0 /secret.key

The setup fails since the Heads kernel doesn't have aes-xts-plain64 cipher support. (Issue #44)

The secret key is not the right size since sealfile2 fails on larger than 128 byte files. (Issue #45)

from heads.

The initramfs file doesn't seem to be handled the way that I had hoped -- it doesn't decompress all of the pieces, so it is necessary to append to it. The wrap-cpio program will merge multiple cpio files to install the ones that we want, but the other parts still need to be written.

from heads.

The keyfile parameter might be fixed in systemd: systemd/systemd@c802a73

from heads.

The systemd fix doesn't actually work -- only the root partition is decrypted with that parameter. Instead I've modified /boot/boot.sh to generate /etc/crypttab on every boot with a reference to /secret.key. This is slow but effective.

from heads.