[dm-crypt] Managing wrapped key ciphers with cryptsetup
brueckner at linux.vnet.ibm.com
Wed May 31 16:01:09 CEST 2017
I appreciate to discuss about your HSM and security experiences.
However, I think the discussion drifts into a wrong direction.
So we discussed about HSMs; but I want to step back to focus on
the where and why we started:
Our goal is to never expose the effective key used to encrypt the data
on disk in plain text in the operating system memory.
This has value for different aspects:
- Nobody can steal the key and decrypt a disk being accessed from a
- System dumps can be provided to service organizations without risking
that a crucial secret becomes exposed.
- Password protection of keys being no longer the only protection mechanism.
This allows to automatically unlock/open disks.
Support of not exposing keys in plain text requires hardware support. The
most commonly known hardware are HSMs that is why we tried to explain our
contributions using HSMs.
But other implementations are conceivable including TPMs, performing
encryption inside enclaves of Intel SGX, or CPU, or firmware (like it
is done with z Systems protected keys).
All these methods will face the same set of problems, for example, special
key formats require special key generation procedures, hashes of key
representation are no longer unique identifiers of the effective keys.
We have solved all of these problems.
Also we invite you to look at the code and let us know if you have better
suggestions on how to solve these problems.
On Mon, May 29, 2017 at 08:25:55PM +0200, Arno Wagner wrote:
> On Mon, May 29, 2017 at 15:48:06 CEST, Hendrik Brueckner wrote:
> > On Mon, May 15, 2017 at 09:28:13PM +0200, Arno Wagner 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:
> > > 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...)
> > Simple passphrases are one thing and, of course, they break security.
> > And a careless use of HSMs does even make the situation not better.
> > Please do not frown on using HSMs at the first glance. They are a common
> > infrastructure piece, at least in our environment. Also consider companies
> > in the financial sector, that might have to use HSMs because of regulatory
> > policies. Just to make clear, our focus is on the enterprise level.
> I do certainly not frown on HSM usage at a "first glance". I
> am well aware of HSM uses and misuses and I have considerable
> experience with enterprise IT security (and lack thereof).
> But LUKS is very explicitely targetted at non-HSM scenarios.
We all know there is no such thing as absolute security. All we can do is to
constrain the attack vector to a manageable size: That is manageable through
policies and trust and increasing the risk for the bad guys to be discovered.
Disallowing to store the dm-crypt effective key in plain text in the operating
system memory will just remove a few attack vectors and certainly increase
the risk of stealing data without being caught.
And operating system memory means not only the running instance. It also
applies to dumps of the OS memory that are handed over to other parties
for service. This in general exposes any contained key materials to good
and bad guys and requires lots of trust. This exposure of effective key materials
can be reduced with wrapped keys; so it is something that becomes manageable.
> > > > 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.
> > As for the redundant security provided by LUKS in connection with
> > wrapped key we thought about that. But we came to the conclusion
> > that we valued management compatibility over a bit of redundancy.
> The HSMs you use do not have management capability? Have you
> thought about getting better ones? They are expensive enough
> after all. On the other hand, if you want the sort-of "light
> weight" management capabilities LUKS offer, you may lose most
> of what the HSM gives you against internal attackers.
As for HSM management: We do not suggest to let cryptsetup manage a HSM.
Each HSM comes with its own management tooling. Also note that the management
tooling can be located on separate management systems to prevent configuration
changes from within a Linux instance.
Our solution expects that a HSM or any other supportive hardware is already
set up (for example, access of the Linux instance to the HSM is configured
and the HSM master secrets are set). We want cryptsetup only to use a
configured HSM or any other supportive hardware and tried to keep the
HSM/HW-specific interfaces as small as possible. Most are hidden inside
the cipher that deals with wrapped keys. Key generation, however, requires a
call to a special function (e.g. kernel, device driver) - and in our solution
this is encapsulated in generic callbacks where interfaces can be plugged-in.
> > > 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.
> > You are right. We could. Yet we like LUKS :-) and LUKS is the de-facto
> > standard for Linux disk encryption. So our goal is to keep the
> > management burden of disks encrypted with a wrapped key to a minimum.
> > We made an effort to make the usage of such disks as similar as possible to
> > existing schemes (the only difference being a new cipher name) such that it
> > can without change be used in existing management frameworks /distributions.
> > Besides we do not want to fork yet another management discipline.
> While I do understand that, I do not see any security
> improvements for LUKS. All I see is creating compatibility
> with enterprise process situations. As this increases
> complexity with zero security, I am opposed, as this is a
> net loss for LUKS.
Just to repeat what has been said before: we think it is of great value
to manage encrypted disks with a common tooling. We are trying hard to
integrate a new encryption discipline in a compatible way with existing
tools (cryptsetup). And we believe that the Linux _Unified_ Key Setup
approach is the right direction. Anyhow, we are open to suggestions to
even better integrate.
> Come to think of it, one thing you could do is maintain
> a patch-set. That way, core-LUKS would not suffer and you
> would still get your "HSM LUKS".
It is not about an "HSM LUKS". As mentioned in the beginning, our goal is
to not expose the effective key in plain text in the OS memory. We use
wrapped keys to achieve this goal and it is about to manage these wrapped
keys with LUKS the same way as LUKS does for keys in plain text format.
Thanks and kind regards,
More information about the dm-crypt