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. > > 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. > > > 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. 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. 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. > > 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. Kind regards, Hendrik _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
