[dm-crypt] LUKS/cryptsetup with HSM
arno at wagner.name
Sun Mar 9 22:57:36 CET 2014
On Sun, Mar 09, 2014 at 21:45:38 CET, Alex Elsayed wrote:
> That may not be strictly true going forward - in particular, the combination
> of the keyctl API (see "trusted keys") and the "trusted kernel" work
> (or possibly whatever name Phoronix comes up with if someone thinks Matthew
> Garrett is bluffing) mean that "known to the kernel" == "accessible to root"
> may not always hold.
True, but doing that would be exceedingly stupid.
For one thing, unless you have hardware-based encryption that does not
allow reading of the key-setup and keys are transported in there in
encrypted form only, root _can_ get the keys, it would just be a little
more effort. (Backgroung: A TPM is not a high-performance encryption
module that you could pass all your HDD accessses through...)
Second, a key generated and protected by a TPM does not allow backup.
(Or if it does, security is lost in a single-user scenario.) Suddenly
access to all your data depends on your TPM surviving. It dies, all
your data is lost. (Who here had a mainboard die? Right.) Not even
remotely professional. Also, if you do not have a TPM, you just need
to patch your kernel to get full access, and the protection-level
without TPM is laughable. Do not even get me started on what is wrong
with requiring vendor-signed kernel binaries.
Third, the single system security perimeter in a UNIX system is the
protection of root. Comprimising root's ability to get at everything
compromises the UNIX protection model.
It also does not work with LUKS, as the master-key is in the header.
If you insist shooting yourself in the foot by having a single-device
dependency for access to your crypto-keys, LUKS does not support you
Not that I have not seen a lot of utter stupidity going on in the
Linux space recently. This is just one more instance of people
that do not get it.
Now, what does a proper HSM do here to prevent the single-device
dependency (which is an absolute faux pas in professional IT)?
Simple: It can store the key on secure smartcards with a threshold
scheme. For example, you have 8 smartcards, and 5 are needed to
reconstruct the key on a different instance of a HSM from the same
vendor. (Still a single-vendor dependency, but at least you can
put 2 or so HSMs in storage for use in emergency data recovery, and
this is being done in practice.) The 8 smartcards get into safes
under the authority of different people in different places and
knowledge who has these smartcards gets restricted. This gives
you a pretty good key backup. Note that the distribution of the
key over several people is absolutely critical for security.
Also note that nothing of the distribution goes over the net
or via software. The 8 smartcards all have to go into a smartcard
reader that is part of the protected HSM.
The take-away message is that hardware-based security is neither
cheap nor easy to do and that a TPM is basically only suitable to
enforce DRM and the like, but is not a real HSM at all.
> An alternate dmsetup syntax that uses a key in a kernel-side keyring might
> be all that's needed for such a thing.
"may". With great restrictions and an unacceptable reliability and
>  http://thread.gmane.org/gmane.linux.kernel/1656312
> Arno Wagner wrote:
> > Hi,
> > you cannot protect the encryption keys in an HSM. To be effective,
> > they need to be known to the kernel and are hence exposed to
> > root, see also FAQ Item 6.10. This is a fundamental limitation
> > of software-nased encryption.
> > Or maybe you want to _store_ the _passphrases_ in an HSM when not
> > in use? In that case youmay want to feed them to cryptsetup via
> > stdin, as described in the man-page.
> > Arno
> > On Thu, Mar 06, 2014 at 08:17:59 CET, Sharma, Manjari wrote:
> >> Hi Cryptsetup team,
> >> This is Manjari Sharma from SafeNet. SafeNet is the largest company
> >> exclusively focused on the protection of high-value information assets.
> >> I'm trying to integrate our HSM with LUKS so that the encryption keys are
> >> protected in an HSM.
> >> Could you please help to provide some pointer. I could not find anything
> >> relevant after searching for hours, all I can be assured of is that it
> >> can be done.
> >> Your help would be highly appreciated.
> >> Thanks,
> >> Kind Regards,
> >> Manjari
> >> The information contained in this electronic mail transmission
> >> may be privileged and confidential, and therefore, protected
> >> from disclosure. If you have received this communication in
> >> error, please notify us immediately by replying to this
> >> message and deleting it from your computer without copying
> >> or disclosing it.
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt at saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> dm-crypt mailing list
> dm-crypt at saout.de
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
A good decision is based on knowledge and not on numbers. - Plato
More information about the dm-crypt