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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
