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

Sven Eschenberg sven at eschenberg.eu
Tue Apr 25 19:09:35 CEST 2017



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...
>
> Milan

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.

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)

And yes, I know, it would increase the IO Latency a bit, but offload the 
CPU at the same time.

Regards

-Sven



More information about the dm-crypt mailing list