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 -- 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
