[dm-crypt] LUKS header recovery attempt, bruteforce detection of AF-keyslot bit errors
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...
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.
More information about the dm-crypt