[dm-crypt] Managing wrapped key ciphers with cryptsetup
doark at mail.com
Thu May 18 19:41:15 CEST 2017
On Mon, 15 May 2017 21:28:13 +0200
Arno Wagner <arno at wagner.name> 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
> 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.
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)
More information about the dm-crypt