On 20.08.2024 17:56, Mikulas Patocka wrote: > > > On Fri, 16 Aug 2024, Ingo Franzki wrote: > >> For the MAC based integrity operation, the integrity key size (i.e. >> key_mac_size) is currently set to the digest size of the used digest. >> >> For wrapped key HMAC algorithms, the key size is independent of the >> cryptographic key size. So there is no known size of the mac key in >> such cases. The desired key size can optionally be specified as argument >> when the dm-crypt device is configured via 'integrity_key_size:%u'. >> If no integrity_key_size argument is specified, the mac key size >> is still set to the digest size, as before. >> >> Increase version number to 1.28.0 so that support for the new >> argument can be detected by user space (i.e. cryptsetup). > > Hi > > I know you already discussed it with Milan. I'd like to ask, what's the > reason for this patch? Milan said that you need it for mainframes - > please, describe the specific configuration when this patch is needed. > > Mikulas Hi Mikulas, thanks for looking into this. In short: Yes, we need it for a new function on Linux on IBM Z platform (aka s390x), but the general concept of using wrapped keys is not limited to that platform but can be used by other platforms as well. Furthermore, the proposed change can also be beneficial for clear key HMAC integrity protection, to allow choosing the size of the integrity key. As a little background: Quite some time ago I worked with Milan to add support for using HSM (Hardware Security Module) protected keys (or in general wrapped keys) with dm-crypt and cryptsetup. HSM protected keys are keys that are wrapped (i.e. encrypted) by an HSM master key. This increases security because such keys can only be used with the proper HSM being available, and the clear key values of such keys are never revealed in clear outside of the HSM. LUKS does a very good job in protecting the volume keys, but once the volume has been opened the key appears in clear in kernel memory. When using HSM protected keys, only the wrapped key appears in memory, but never the clear key value. Such HSM protected keys usually have a physical size that is much larger than a clear key. We usually speak about a key blob here, because only the HSM really understands how to use that key blob, for anything outside of the HSM it is just an opaque key blob. The point is, that the physical size of such HSM protected keys are not directly related to the cryptographic size of the key they contain. For the Linux on IBM Z platform (aka s390x) we provide a special kernel cipher named 'PAES' that implements the AES algorithm but takes such HSM protected key blobs as argument. While this works transparently with dm-crypt, it needed some changes in the cprytpsetup tooling, because cryptsetup assumed that the physical size of a key relates directly to its cryptographic size, which is not true for such HSM protected keys. Milan was so kind to make the required changes back then in cryptsetup to make this work. So, with this, one can now setup an encrypted disk using plain or LUKS2 by specifying a cipher like 'paes-xts-plain64' to benefit from the added security of HSM protected keys. If you like, you can read more about this here: https://public.dhe.ibm.com/software/dw/linux390/docu/l5n3dc04.pdf Reasons for the proposed change in dm-crypt: We now want to provide a similar functionality for integrity protected volumes. Similar to PAES, we provide a kernel HMAC cipher named 'PHMAC' that implements the HMAC algorithm but takes HSM protected key blobs as argument. So, one would use a cipher like 'phmac-sha256' to setup an integrity protected disk to benefit from the added security of HSM protected keys. The use of such HSM protected HMAC keys work transparently with the dm-integrity target (only needs some changes in the user space tooling). However, there is also the combined encrypt and integrity protection capability of dm-crypt, either using HMAC or AEAD. We focus on HMAC based integrity protection here. And for that, we do need the proposed change in dm-crypt. In case of combined encryption and HMAC based integrity, dm-crypt gets a single key blob and needs to split it into two parts. The first part is the encryption key, the second part is the integrity key. Currently, dm-crypt assumes that the size of the integrity key part is the digest-size of the HMAC algorithm. With this, the integrity key size is known, and the 2nd part of the key blob can be split off and used as integrity key. The remaining first part is used as encryption key. While with this logic, the encryption key can already be an opaque key blob (i.e. a HSM protected key blob) of any length, the integrity key part can not, because its size is assumed to be directly related to the HAMC digest used. To support opaque integrity key blobs as well, the size of the integrity key must be passed to dm-crypt from user space. This needs changes in the cryptsetup tool as well, I am working with Milan on this. If an integrity key size is specified in the dm-crypt parameters, it uses that size to split the key into the 2 parts, otherwise it uses the digest size as before. With this, both, the encryption key as well as the integrity key can then be opaque HSM protected key blobs of arbitrary sizes. So one can use a command like the following to format a encrypted and integrity protected volume using HSM protected keys: # cryptsetup luksFormat --type luks2 --master-key-file <volume-key> --key-size <encrypt-key-size-in-bits> --cipher paes-xts-plain64 --integrity phmac-sha256 <device> As mentioned above, the proposed change is not directly related to a specific platform, although Linux on IBM Z (s390x) is the first to exploit this. It could be utilized by any platform for wrapped key ciphers. It can also be used for clear key HMAC integrity when one wants to use an HMAC key size that is different from the digest size. I hope this answers your questions. Kind regards, Ingo [snip] -- Ingo Franzki eMail: ifranzki@xxxxxxxxxxxxx Tel: ++49 (0)7031-16-4648 Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Gregor Pillen Geschäftsführung: David Faller Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/
