On Tue, Mar 11, 2014 at 00:49:11 CET, Alex Elsayed wrote: [...] > >> 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. I think that is just not true. Or rather the key is never seen by userspace if userspace does not try to see the key. That is a bit different. How are you going to protect the key-setup for software encryption (or hardware encryption where you can read the key) from root? As in "root that can do arbitrary things to the kernel image and reboot"? And don't try to sell me "trusted boot". That one is nonsense. > >> 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. True. But if you do that before your TPM dies, you have lost protection because userspcae does get so see the key when you make that non-TPM keyslot. If you do it after the TPM dies... oh, wait. Of course, if done very carefully, this can work. But it strikes me as rather hard to get it right. > >> 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. One reason why people really concerned about security do not use virtualization. Or rather are very careful that they have root on the host system and are secure there and the they can mostly trust what is going in in their VMs. I really cannot go into detail (sorry, NDAs), but virtualization offers a lot less protection than most people believe. > 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. No wireless card in any system I care to be secure and IPMI goes into a physically seperated LAN on another trusted machine. But this is a red herring: Viewed from this angle, these things break the architecture. This is why they need to be regarded separately. Saying "I have a wireless card or IPMI, so root is compromised anyways" is not the right approach, even if technically true for some scenarios. I even have a JTAG adapter lying around here somewhere (never used so far), so technically all my hardware is completely compromised. But that is the wrong model. > 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. And I think it is flawed. Root can do a lot of things that are exceedingly hard or impossible to protect against and there is a reason root can do that: It is needed. The alternative is a locked-down device, where the system administrator is just any other user and has to either beg some higher authority for access or physically go to the hardware. Not good at all. Your server is not an XBox. > >> 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. So you have a patched version that breaks the LUKS semantics. That is not LUKS anymore. > 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. Sure. > >> 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. With hacked key-slot sematics, yes. Not with LUKS key-slot semantics. > >> 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. Are you really sure? My impression is it is not even really suitable for enforcing DRM. I think the whole TPM idea has been fundamentally broken from the start as it ignores reality. Sure, locking technolocically incompetent users into something, it can do to a degree, but for real_ security? If they had put in a high-performance crypto-engine and had created a secure way to clone keys (e.g. directly attached special smart-card slot), then we would have a HSM-like device that is pretty secure as long as the attacker does not get physical access. But this is an ElCheapo chip attached via a very slow interface. AFAIK, the TPM cannot even detect when it is removed and placed into another system. Which is not that hard to do. > >> > 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. Does not convince me so far. I have admittedly seen a lot of severe stupidity in this area, up to some people claiming that a normal "secure" smartcard or even a plain NIC EEPROM was a "mini HSM" and basing the security of some really critical systems on that. So I am prejudiced here and extraordinary evidence is required to convince me. Sorry about that. Arno > >> 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 -- 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
