Hello,
As a research project, we have modified the LUKS header (and cryptsetup
CLI) to allow encrypting the master key with something stronger than a
password namely a cryptographic token. We also use NSS for
cryptographic operations where possible for easier time going through
FIPS 140 compliance (following Linux System Base and Fedora and derived
distributions such as Red Hat).
Basically, a public key is used to encrypt the master key and the
private key which never leaves the PKCS11 device is used to decrypt the
master key. This works great for partitions other than the boot
partition since the kernel and NSS are needed for our code to work. The
actual dm-crypt stuff has not changed at all.
What is the process for sending our code upstream?
How would you deal with encrypting the boot partition? If you have any
ideas and feel like sharing, please contact me. Thanks!
Idea 1: Have a little kernel possibly on a password protected
partition with NSS that can encrypt the real kernel. Yikes.
Idea 2: Use a hypervisor and do the encryption there. Oye.
Idea 3: Put a key file in the TPM and hope that it is FIPS
compliant and secure enough (and is secured by a decent password). Huh.
Idea 4: Use hardware based full disk encryption to solve that
(which almost certainly puts us back to a password). Why bother.
Idea 5: Write something at the BIOS or bootloader level (in
coreboot/GRUB2 for example). Drug policy violation, but sounds nice.
As you can see, the ideas are not very promising. The token we use is
not capable of holding the key file.
Kind regards,
Vlad
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
