Hi Sven, On Thu, Apr 27, 2017 at 10:06:35PM +0200, Sven Eschenberg wrote: > > The protability of the on disk format includes, that I can basicly > reimplement cryptsetup from scratch, without relying on the current > status quo. Moreover I even don't need to use kernel crypto stuff at > all to i.e. create a decrypted image of the data. Let' me first explain a bit about the differences of wrapped key and clear key: - The cipher implementation is different because it must handle wrapped keys. - The key generation (and derivation) is different because the clear key must be exposed only in its wrapped format. - Particular clear key handling needs to be adapted to also work with wrapped keys. For example, this becomes necessary when computing a hash over the clear key. To distinguish between clear and wrapped keys, you can use the name of the cipher. That will be the indication for different key handling. Then, you can think of two different cipher types: clear key cipher and wrapped key cipher, each having its own key handling/management functions. In the patches for crypsetup, we introduced the crypt_is_wrapped_key_cipher() function to test for a wrapped key cipher and, then, perform some "wrapped key specifics". The "wrapped key specifics" are a set of callback functions that must be implemented to support a wrapped key cipher. For example, we added callback functions, crypt_generate_wrapped_volume_key() or crypt_validate_wrapped_volume_key(). So you can provide any kind of wrapped-key cipher implementation which can be platform-independent. With the paes wrapped key cipher, we then simply provided the callback implementation. The callback implementation might use a kernel or library or whatever interface. For the paes reference implementation, we decided to use a kernel interface which abstracts and wraps all the stuff that one might consider HSM-specific. > Your HSM specific changes would be tied into cryptsetup, but if I > followed the current specification, and had the corresponding HSM, I > still would need the 'specifics' regarding the HSM and how to use > it, to set up the actual mapping. [...] > Now, in contrast, if you hack the HSM supprt into cryptsetup, > there's no on disk indication and that is not really portable > anymore. As mentioned above, we focussed on a generic wrapped key cipher concept, to abstract the HSM-specifics from cryptsetup, making them depend on the wrapped key cipher. The portability of the existing functionality is not affected because there is distinction between clear and wrapped key ciphers. The LUKS on-disk-format structure is not touched by adding or changing any members. The indication that a wrapped key instead of a clear key is used for decryption is solely based on the name of the cipher. So if one would write cryptsetup from scratch, it then needs to take care to handle the wrapped key specifics. Of course, to decrypt the data using the wrapped key, the platform must support the wrapped key cipher and a HSM must be available. But I do not think that this is a portability issue of cryptsetup in general, it is rather an environment issue or requirement. Because a driver is required to access the disk, the cipher (aes, blowfish, ...) must be available to actually decrypt data. With wrapped key ciphers, particular environment requirements are added. Thanks and kind regards, Hendrik -- Hendrik Brueckner brueckner@xxxxxxxxxxxxxxxxxx | IBM Deutschland Research & Development GmbH Linux on z Systems Development | Schoenaicher Str. 220, 71032 Boeblingen _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
