[dm-crypt] Managing wrapped key ciphers with cryptsetup

Hendrik Brueckner brueckner at linux.vnet.ibm.com
Thu Apr 27 17:09:02 CEST 2017


Hi Milan,

thanks for your thoughts.  Let's start a new thread here and
keep some facts from the old one.

On Wed, Apr 26, 2017 at 08:46:38PM +0200, Milan Broz wrote:
> On 04/26/2017 04:45 PM, Hendrik Brueckner wrote:
> > On Tue, Apr 25, 2017 at 07:09:35PM +0200, Sven Eschenberg wrote:
> >> Am 25.04.2017 um 18:30 schrieb Milan Broz:
> >>> On 04/25/2017 06:16 PM, Sven Eschenberg wrote:
> >>>
> >>> Crypto API stores the key in memory as well (even the round keys etc), obviously.
> >>>
> >>> We have already support for kernel keyring in dm-crypt (so the key will
> >>> not be directly visible in dmsetup table), this will be supported in next major
> >>> version of cryptsetup/LUKS.
> >>>
> >>> But as you said, if you have access to the kernel memory, it is there anyway...
> > 
> > a colleague of mine and I investigated in this kind of topic. For strong
> > security, having the clear key accessible in the memory is not an option.
> > Of course, the alternative, is to deal with hardware security modules (HSM)
> > to perform the cryptographic operations by having the clear never leaving
> > the HSM.
> > 
> > We worked on this area and provided some cryptsetup enhancements to support
> > wrapped keys for disk encryption to prevent having keys in clear text in the
> > memory of the operating system.  Recently, we submitted this merge request:
> > https://gitlab.com/cryptsetup/cryptsetup/merge_requests/19
> 
> Anyway, I will handle that merge request later but in short - your
> approach works only IBM zSystem (no other system implements this
> wrapped encryption, so it is very platform specific).

The approach depends on a cipher that supports secure keys where a
"secure key" is a key that is wrapped by the master key of a hardware
security module (HSM).
The merge request introduces a generic interface for dealing and using
these "wrapped key ciphers".  This is not specific to IBM z Systems.

The protected key AES implementation provided by the paes kernel module
is, of course, specific to a HSM: the CryptoExpress cards and some
performance improvements provided by z Systems.  But a paes like module
that uses secure/wrapped keys could be written for any HSM.

> 
> LUKS1 is portable format, we cannot bind the format to specific hardware.

We considered that point in the merge request.  It keeps LUKS1 as a
portable format, there are no changes on the LUKS1 format or header.
Of course, there are some differences when using wrapped keys, but these
have been addressed without affecting the on-disk-format structure.

> 
> So do not expect this to be merged as it is and specifically not to
> LUKS1 format I consider stable and where it major advantage is
> portability among all possible Linux distributions and architectures.

I think that it is necessary to take some time for review and to have
constructive feedback discussions.  Regarding the portability, the
changes do not affect the portability because we had that in mind from
the beginning.

> 
> Anyway the discussion could be interesting.

Of course, I think it is and I would be glad when we can work together
on a solution.

> But I do not think
> the mainframe approach can be applied to low-end systems where this kind
> of FDE is mostly used. The FDE threat model is also usually focused
> to offline systems (stolen disk) so here we do not need to care
> if key is in memory when system is online.

Trying to obtain the key (in its clear text format) from memory is just
one case. The other case, you already mentioned, is about offline disks.
The approach we pursued with wrapped keys is that the wrapped volume
encryption key is stored on the disk instead of its clear text form.
For stolen disks, even if the volume encryption key could be accessed,
it is still wrapped by the HSM's master key.  Hence, access to the HSM
is required to decrypt disk data.


Thanks and kind regards,
   Hendrik

-- 
Hendrik Brueckner
brueckner at linux.vnet.ibm.com      | IBM Deutschland Research & Development GmbH
Linux on z Systems Development    | Schoenaicher Str. 220, 71032 Boeblingen


IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294



More information about the dm-crypt mailing list