[dm-crypt] Managing wrapped key ciphers with cryptsetup

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


More information about the dm-crypt mailing list