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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
