[dm-crypt] LUKS header modifications

[dm-crypt] LUKS header modifications

[Vladimir Giszpenc]

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

Re: [dm-crypt] LUKS header modifications

[Milan Broz]

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

Re: [dm-crypt] LUKS header modifications

[Vladimir Giszpenc]

Milan,

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

If Red Hat wants to continue paying for every crypto library to be FIPS
certified, that is OK with me.  However, standardizing on NSS also gives
you access to the certificate store, Certificate Status checking policy
(OCSP or CRL), tested on many architectures (and OSes) and probably
other benefits for a resource conscious company.  There is nothing wrong
with gcrypt.  It is just that Fedora, Red Hat and the Linux community
wants to move to one crypto solution and gcrypt was not chosen.  Why
fight it.  NSS was FIPS 140-2 Level 3 validated.  You can split the bill
with Mozilla, HP, Sun/Oracle, IBM, Apple, Novell and even HP.

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

Talking a little bit out of my depth: could an SELinux policy protect
the master key from the time it is decrypted and force it to go where it
needs to go and nowhere else?

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

This is not an option.  Our token cannot store keyfiles.  It stores a
few RSA key pairs with X.509 certificates, one of which is for
encryption.
The key file is separate from the LUKS header which means that if you
encrypt a USB drive, you have to pass the key file some other way which
will never be as good as the LUKS header.  The header also allows for
multiple passwords (and now public keys) to encrypt the same master key.
If you don't use the header, this sort of setup gets messy real fast.

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

Under what license if any must code be given?

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

Thank you!

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

TPM is hardware but is not an HSM.  It is probably better than nothing,
but will not work for our heavily regulated environment.

Thank you,

Vlad