On Mon, May 29, 2017 at 15:48:06 CEST, Hendrik Brueckner wrote: > Hi Arno, > > 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: > > > > I think hardware-specific stuff has no place in cryptsetup. > > > > Get a kernel-driver and then create a wrapper that feeds > > > > the key to cryptsetup, anything else is a bad design. > > > > > > That's actually what we did with the paes reference implementation. > > > There are kernel drivers that abstract the HSM-specifics. From a > > > user perspective, for example, cryptsetup, the secure (wrapped) key > > > is passed to the paes cipher (in-kernel crypto API). The paes cipher > > > uses information from the secure key to find a HSM that is capable > > > to perform crypto operations with that key. There is no need for the > > > user to perform any HSM action. > > > > > > I am about to reply on Sven's mail, covering some more details that > > > I do not want to repeat here. > > > > Ok, I will try to answer to that one then. > > > > > > And if you want a system that is secure against root, then > > > > do not use Linux. Seriously. > > > > > > Of course, if users becomes root (or gain superuser capabilities), > > > they are able to access the data and obtain the wrapped key. > > > Secure keys (the wrapped keys with that we deal) cannot be un-wrapped. > > > That means, at least, root cannot obtain the inner clear key. > > > > > > So with the wrapped key concept, you can harden your environment against > > > offline attacks. > > > > I don't think so. LUKS does that pretty well already and unless > > there is some major flaw in it, offline attacks should be infeasible. > > By off-line attacks we mean off-line attacks with a stolen key. Your terminology is a bit off here: If an attacker has the key and uses it, that is not actually an attack. An attacker is perfectly allowed to present a key, just as anybody else is. The only authorization here is whether somebody has the key, and hence an attacker with the key is authorized. > > 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. > > > 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. > But also keep in mind, that there is and must be a separation of > concerns: security operators managing the HSM and system administrators > taking care of the Linux instances. The security operator has to take > care for installing, backing up, and recovering of HSM master-keys > (that is the k-out-of-n chipcards stuff). The system administrator has > to take care to backup and recovery the wrapped key. The wrapped > key is not stored on the HSM. The effective key can be just obtained > with a master key on the HSM. Well, that one is basically worthless, except for fulfilling the process. I do understand that sometimes you have to do that. But the fact of the matter is that you have neither security against the security operator nor against the system administrator if they are even marginally competent. That one can not be avoided, no matter what you do, except for some very expensive solutions. I am well aware that many enterprise security people try very hard to ignore that little fact. But I really do not think that LUKS should start to do "wishful thinking security", even if that one is quite common in the enterprise space. > Besides that, "redundancy" provides 2-factor authentication - which is > nice. And those who do not care about 2FA can use a standard passphrase > or can store it in a not so secure file (e.g. in the boot partition) and > enjoy that the disk can be automatically opened on systems where the HSM > is available. Aehm, a 2FA that you can circumvent is not a 2FA. > > 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. 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". Regards, Arno -- 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 If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
