I'm going to go point-by-point on this; response inline. Arno Wagner wrote: > 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 This, I am in complete agreement on... for closed hardware. However, I firmly believe that "the perfect is the enemy of the good". An open-hardware device doing something similar to a TPM (even over the same APIs, perhaps) would resolve the above, and would be a useful tool - and while no software- based encryption will be able to conceal the key as completely as hardware- based encryption, hybrid approaches can increase the cost metric. > 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. Yes and no. It may not provide the full benefit of fully hardware-based encryption (as long as that is open-hardware, or it's _just as bad_ by your above point), but it _can_ improve some properties over purely-software approaches. Hybrid techniques can be valuable because an incremental improvement is still an improvement. 'Perfect' isn't a goal; it's a strawman. 'Better' is a goal. >> 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...) The "trusted keys" API means that the key is never seen in an unsealed state by userspace - that mitigates a various avenues to obtain it. See below regarding "incompatible with LUKS" for further explanation. >> 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. Um, keyslots. There's always the flexibility to kick out the TPM key, and even resolve the old "can't move TPM-encrypted drives between machines" issue by creating a new keyslot, sealed with the new machine's TPM. Heck, also add a completely non-TPM one you keep on a thumb drive in a safe deposit box for unexpected machine failure. >> 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. Not wholly correct - in the presence of virtualization, particularly container-based virtualization, this has long been untrue. In addition, your wireless card is almost certainly running an RTOS on an embedded ARM and your motherboard may have IPMI in which case it also has its own OS (The one on an ASUS board I have is a tiny Linux system on a cramfs, in fact. It has SSH running.). So if your assertion is wholly true, it's rather thoroughly compromised already. The distinction made with the trusted keys/trusted kernel stuff is between root (which may be anyone who can manage a privilege escalation attack) and owner-with-physical-access. >> 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 really. There are a number of ways to integrate it - Currently, we derive the slot key, and use it to decrypt a copy of the master key. If the _copy which the slot key decrypts_ is sealed, you load it into the kernel's keyring and reference it on the dmsetup line. That permits it to be per- keyslot, work with passphrases and keyfiles without a care in the world, and still prevent the master key from ever being exposed to userspace in the clear during normal operation. Even adding another TPM-locked keyslot wouldn't need the raw key, since the kernel permits exporting trusted keys in their sealed form - you just do that, encrypt with the new slot key, and you're golden. Making a new _non_-tpm-locked slot would require the key be in the clear, but that's a pretty obvious consequence of it being non-tpm- locked. >> 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. I suppose we'll just have to disagree there. >> 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. Yes, but the above that I describe can also be used as such. After all: what I describe isn't "just use the TPM"; it's "use the TPM as _a second factor_". The first factor - the keyfile needed to even get at the sealed copy of the master key - can use such a system if you want. Besides, since what I described _is_ compatible with keyslots, you're still not subject to lock-in. >> 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. A hardwired smartcard with the ability to chain assertions is useful for a good deal more than that. >> > 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. I hope my above points show that the restrictions, reliability, and security model can be somewhat better than that. >> 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 > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
