Hi Milan, thanks for your thoughts. Let's start a new thread here and keep some facts from the old one. On Wed, Apr 26, 2017 at 08:46:38PM +0200, Milan Broz wrote: > On 04/26/2017 04:45 PM, Hendrik Brueckner wrote: > > 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: > >>> > >>> 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... > > > > 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 > > 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). The approach depends on a cipher that supports secure keys where a "secure key" is a key that is wrapped by the master key of a hardware security module (HSM). The merge request introduces a generic interface for dealing and using these "wrapped key ciphers". This is not specific to IBM z Systems. The protected key AES implementation provided by the paes kernel module is, of course, specific to a HSM: the CryptoExpress cards and some performance improvements provided by z Systems. But a paes like module that uses secure/wrapped keys could be written for any HSM. > > LUKS1 is portable format, we cannot bind the format to specific hardware. We considered that point in the merge request. It keeps LUKS1 as a portable format, there are no changes on the LUKS1 format or header. Of course, there are some differences when using wrapped keys, but these have been addressed without affecting the on-disk-format structure. > > 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. I think that it is necessary to take some time for review and to have constructive feedback discussions. Regarding the portability, the changes do not affect the portability because we had that in mind from the beginning. > > Anyway the discussion could be interesting. Of course, I think it is and I would be glad when we can work together on a solution. > 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. Trying to obtain the key (in its clear text format) from memory is just one case. The other case, you already mentioned, is about offline disks. The approach we pursued with wrapped keys is that the wrapped volume encryption key is stored on the disk instead of its clear text form. For stolen disks, even if the volume encryption key could be accessed, it is still wrapped by the HSM's master key. Hence, access to the HSM is required to decrypt disk data. Thanks and kind regards, Hendrik -- Hendrik Brueckner brueckner@xxxxxxxxxxxxxxxxxx | 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
