Re: [dm-crypt] Managing wrapped key ciphers with cryptsetup

[Hendrik Brueckner <brueckner@linux.vnet.ibm.com>]

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@linux.vnet.ibm.com      | IBM Deutschland Research & Development GmbH
Linux on z Systems Development    | Schoenaicher Str. 220, 71032 Boeblingen