On 04/26/2017 04:45 PM, Hendrik Brueckner wrote: > 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 It would be better if you start new thread here about this because this thread is really about something else. 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). LUKS1 is portable format, we cannot bind the format to specific hardware. 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. Anyway the discussion could be interesting. 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. Milan > > 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 > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
