Oh, and before I forget: With a TPM as key-storage, you are completely at the mercy of the hardware manufacturer. How bad an idea that is can be nicely seen in the recent discussion of Intel trying to forece use of RDRAND as the only randomness source in the Linux kernel: https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J Arno On Sun, Mar 09, 2014 at 22:57:36 CET, Arno Wagner wrote: > 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"[1]) and the "trusted kernel" work[2] > > (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 > in that. > > 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 > security model. > > Arno > > > [1] > > https://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/tree/Documentation/security/keys-trusted-encrypted.txt > > [2] 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@xxxxxxxx > > >> http://www.saout.de/mailman/listinfo/dm-crypt > > > > > > > > > > _______________________________________________ > > dm-crypt mailing list > > dm-crypt@xxxxxxxx > > http://www.saout.de/mailman/listinfo/dm-crypt > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > 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 > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
