Re: [dm-crypt] LUKS header modifications

[Milan Broz <mbroz@redhat.com>]

Hi,

Vladimir Giszpenc wrote:
>  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).  

I see no problem problem with libgcrypt & FIPS140. Both NSS & gcrypt are
providing needed FIPS mode (at least patches exist).

One problem is in internal cryptsetup implementation of sha1, which is
already removed in devel trunk (using libgcrypt now).


> 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.

Ok, so your header-unlocking key is safe in hw, but dm-crypt volume
key still need to be sent from userspace to kernel dm-crypt using ioctl
and is still fully visible to root user.
(IOW: You can still decrypt volume with only volume key knowledge.)

What's the (security) difference from using keyfile store on some token?
Or wrapper script which prepare keyfile using public/private key
and similar token you are using?
(No need to modify LUKS header for this, just use some wrapper script,
some distros provide similar scripts by default.)


> What is the process for sending our code upstream?
Best create issue in googlecode cryptsetup page or send patch here.

> How would you deal with encrypting the boot partition?  If you have any
> ideas and feel like sharing, please contact me.  Thanks!

IIRC there are experimental patches for GRUB2 & LUKS, check grub2-devel list.


>        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.

I would like to see dm-crypt in future to use TPM somehow, but there are
still some issues which causes the design will not provide more secure
operation than current mode with directly provided key...

(Anyway, only full trusted boot path avoids an attack to grab passphrase
or volume key... TPM is just part of solution)


Milan
--
mbroz@redhat.com