On Mon, 15 May 2017 21:28:13 +0200 Arno Wagner <arno@xxxxxxxxxxx> 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. > > 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...) > > > > 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. > > 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. > > Regards, > Arno So, 1. User enters actual key 2. HSM gets actual key 3. HSM sends fake key to kernel 4. kernel gets fake key 5. kernel sends (de|en)cryption request (key, data) 6. HSM preforms verification of key 7.a. HSM returns key error 7.b. HSM (en|de)crypts data 8. HSM sends data to kernel (data) Or, even better, esp. for long uptime machines! 8. HSM sends data to kernel with *new* fake key (key, data) Sincerely, David _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
