Hi Arno, I appreciate to discuss about your HSM and security experiences. However, I think the discussion drifts into a wrong direction. So we discussed about HSMs; but I want to step back to focus on the where and why we started: Our goal is to never expose the effective key used to encrypt the data on disk in plain text in the operating system memory. This has value for different aspects: - Nobody can steal the key and decrypt a disk being accessed from a different system. - System dumps can be provided to service organizations without risking that a crucial secret becomes exposed. - Password protection of keys being no longer the only protection mechanism. This allows to automatically unlock/open disks. Support of not exposing keys in plain text requires hardware support. The most commonly known hardware are HSMs that is why we tried to explain our contributions using HSMs. But other implementations are conceivable including TPMs, performing encryption inside enclaves of Intel SGX, or CPU, or firmware (like it is done with z Systems protected keys). All these methods will face the same set of problems, for example, special key formats require special key generation procedures, hashes of key representation are no longer unique identifiers of the effective keys. We have solved all of these problems. Also we invite you to look at the code and let us know if you have better suggestions on how to solve these problems. On Mon, May 29, 2017 at 08:25:55PM +0200, Arno Wagner wrote: > On Mon, May 29, 2017 at 15:48:06 CEST, Hendrik Brueckner wrote: > > On Mon, May 15, 2017 at 09:28:13PM +0200, Arno Wagner wrote: > > > On Mon, May 15, 2017 at 15:56:54 CEST, Hendrik Brueckner wrote: > > > > On Fri, Apr 28, 2017 at 09:22:22AM +0200, Arno Wagner wrote: > > > > That is unless somebody uses a laughably simple passphrase that is. > > > But anybody that does that will do other things that break security > > > as well from my experience. So I have to admit I do not see the > > > point. (Well, I do see the point, because people that do these > > > stupid things may still buy a HSM and actually be a bit more > > > secure for it...) > > > > Simple passphrases are one thing and, of course, they break security. > > And a careless use of HSMs does even make the situation not better. > > > > Please do not frown on using HSMs at the first glance. They are a common > > infrastructure piece, at least in our environment. Also consider companies > > in the financial sector, that might have to use HSMs because of regulatory > > policies. Just to make clear, our focus is on the enterprise level. > > I do certainly not frown on HSM usage at a "first glance". I > am well aware of HSM uses and misuses and I have considerable > experience with enterprise IT security (and lack thereof). > But LUKS is very explicitely targetted at non-HSM scenarios. We all know there is no such thing as absolute security. All we can do is to constrain the attack vector to a manageable size: That is manageable through policies and trust and increasing the risk for the bad guys to be discovered. Disallowing to store the dm-crypt effective key in plain text in the operating system memory will just remove a few attack vectors and certainly increase the risk of stealing data without being caught. And operating system memory means not only the running instance. It also applies to dumps of the OS memory that are handed over to other parties for service. This in general exposes any contained key materials to good and bad guys and requires lots of trust. This exposure of effective key materials can be reduced with wrapped keys; so it is something that becomes manageable. > > > > > With the wrapped key support, you also get a > > > > 2-factor-authorization for free: there is something to know, > > > > that's the passphrase, and there is something you own, that's the HSM. > > > > Only if both factors are there, you can decrypt the data. > > > > > > Yes, that works. But why use LUKS here? In order to get the most > > > of the HSM, the HSM actually needs to do the decryption itself > > > and all the LUKS header and key-slot overhead is redundant or > > > may even make things less reliable. > > > > > > In particular, LUKS has this hard requirement that you need > > > header backups to be reliable. A HSM does usually have its > > > of backup-scheme (often k-out-of-n chipcards or the like) and > > > when integrating with LUKS, that suddently may not be enough > > > anymore. > > > > As for the redundant security provided by LUKS in connection with > > wrapped key we thought about that. But we came to the conclusion > > that we valued management compatibility over a bit of redundancy. > > The HSMs you use do not have management capability? Have you > thought about getting better ones? They are expensive enough > after all. On the other hand, if you want the sort-of "light > weight" management capabilities LUKS offer, you may lose most > of what the HSM gives you against internal attackers. As for HSM management: We do not suggest to let cryptsetup manage a HSM. Each HSM comes with its own management tooling. Also note that the management tooling can be located on separate management systems to prevent configuration changes from within a Linux instance. Our solution expects that a HSM or any other supportive hardware is already set up (for example, access of the Linux instance to the HSM is configured and the HSM master secrets are set). We want cryptsetup only to use a configured HSM or any other supportive hardware and tried to keep the HSM/HW-specific interfaces as small as possible. Most are hidden inside the cipher that deals with wrapped keys. Key generation, however, requires a call to a special function (e.g. kernel, device driver) - and in our solution this is encapsulated in generic callbacks where interfaces can be plugged-in. > > > Why not just implement your own tool that has a cryptsetup > > > compatible commandline syntax? That would still give you > > > the Linux integration and I think that may serve your > > > purpose better. You would also not be dependent on > > > cryptsetup for any API changes in your drivers. > > > > You are right. We could. Yet we like LUKS :-) and LUKS is the de-facto > > standard for Linux disk encryption. So our goal is to keep the > > management burden of disks encrypted with a wrapped key to a minimum. > > We made an effort to make the usage of such disks as similar as possible to > > existing schemes (the only difference being a new cipher name) such that it > > can without change be used in existing management frameworks /distributions. > > Besides we do not want to fork yet another management discipline. > > While I do understand that, I do not see any security > improvements for LUKS. All I see is creating compatibility > with enterprise process situations. As this increases > complexity with zero security, I am opposed, as this is a > net loss for LUKS. Just to repeat what has been said before: we think it is of great value to manage encrypted disks with a common tooling. We are trying hard to integrate a new encryption discipline in a compatible way with existing tools (cryptsetup). And we believe that the Linux _Unified_ Key Setup approach is the right direction. Anyhow, we are open to suggestions to even better integrate. > > Come to think of it, one thing you could do is maintain > a patch-set. That way, core-LUKS would not suffer and you > would still get your "HSM LUKS". It is not about an "HSM LUKS". As mentioned in the beginning, our goal is to not expose the effective key in plain text in the OS memory. We use wrapped keys to achieve this goal and it is about to manage these wrapped keys with LUKS the same way as LUKS does for keys in plain text format. Thanks and kind regards, Hendrik _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
