[dm-crypt] Managing wrapped key ciphers with cryptsetup

Arno Wagner arno at wagner.name
Mon May 15 21:28:13 CEST 2017

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.

Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
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

More information about the dm-crypt mailing list