Re: [dm-crypt] LUKS header recovery attempt, bruteforce detection of AF-keyslot bit errors

[Hendrik Brueckner <brueckner@linux.vnet.ibm.com>]

Hi Sven,

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:
> >>
> >>Furthermore, everyone who had access to /dev/mem and was able to locate
> >>the keys knows, them. On second thought, this holds certainly true for
> >>the 'new central kernel key storage' (Forgot the name), depending on the
> >>allover kernel configuration and userspace, that is.
> >>
> >>At the end of the day dm-crypt (etc.) needs to store the key somewhere,
> >>where it can be accessed at all times when an IO-Request comes in. There
> >>is not that many options for that ;-).
> >
> >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...
> >
> 
> Ah, thanks Milan, kernel keyring it is called. Anyhow, the only
> solution would be, to store the key in some device and retrieve it
> for IO-Ops, but then again, it would make more sense, to pass the io
> blocks to that (secured blackbox) device. Which would in turn mean
> that such a device needs computational power and massive
> IO-bandwidth.

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

Basically, it seamlessly integrates support for ciphers that can use wrapped
keys instead of clear keys.

For Linux on z Systems (our background), there is a tamper-safe hardware
security module (HSM) that provides "secure keys".  Secure keys are BLOBs
containing the clear key wrapped with a master key of the HSM. Of course,
the overhead is typically considerable because each cryptographic operation
comes at the cost of an I/O operation to the HSM.  However, the z Systems
firmware provides acceleration for this by re-wrapping a secure key to a
protected key (that is valid for the Linux instance (LPAR) only).  Then,
you can use some special instructions to perform, for example, AES with a
protected key at CPU speed. In both cases, the clear key resides in the
HSM/firmware only and is exposed to the OS in a wrapped form only.

The merge request above, also introduces this protected-AES (paes) as
sample for a wrapped key cipher. (paes itself is an in-kernel crypto module).

> 
> Maybe crypto acceleration cards with PCIe3 and 8+ Lanes would be an
> option, if they provide a secured keyring storage etc. . I am
> thinking of something like the Intel QA 8950 with respects to the
> concept. (The QA 8950 aims rather at communication streams, AFAIK, I
> am not sure how keys are handled, i.e. if they are passed into the
> adapter during engine initialization or if an additional permanent
> secured keyring service is offered, or if the key needs to be passed
> in for every block together with the data)

I am not familiar with the QA 8950, but there might be a similar approach
possible as we did with paes. Perhaps, another kind of wrapped key cipher
that fits into concept.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueckner@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