Re: [dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt

[Israel Rukshin <israelr@nvidia.com>]

On 1/18/2022 10:02 PM, Eric Biggers wrote:
> On Sun, Jan 16, 2022 at 12:15:22PM +0200, Israel Rukshin wrote:
>> Yes, I implemented your inline callbacks at nvme-rdma driver. The driver
>> communicates with
>>
>> the HW via a general ib_verbs layer, so I had to extend ib_verbs and mlx5_ib
>> drivers. Those
>>
>> patches are at internal review and I will send the nvme-rdma patches
>> afterwards.
>>
>>> Can you also elaborate on how wrapped keys work in your case?  In particular,
>>> are they compatible with the whole design which I've documented in detail in my
>>> patchset?  That would include implementing the ->import_key, ->generate_key,
>>> ->prepare_key, and ->derive_sw_secret operations.  All the different parts are
>>> important.  If something needs to be optional, that's something I can consider
>>> incorporating into the design, but it would restrict the use cases.
>> In my case, the user should create wrapped keys by himself via a user space
>> tool based
>>
>> on openssl library. Therefore, the ->import_key, ->generate_key and
>> ->prepare_key are
>>
>> not necessary at my case. Regarding ->derive_sw_secret, it is not supported
>> right now by
>>
>> ConnectX6 DX firmware (we plan to add support for this).  To test fscrypt
>> with wrapped keys,
>>
>> a temporary WA was added to the ->derive_sw_secret at nvme-rdma driver. The
>> other callbacks
>>
>> you mentioned were left empty.
> So, what we need to think about is how userspace is expected to actually use and
> test the hardware-wrapped keys feature.
>
> My patchset proposed a design where if a block device declares support for
> hardware-wrapped keys, then the BLKCRYPTOCREATEKEY and BLKCRYPTOPREPAREKEY
> ioctls are available.
>
> Additionally, a specific hardware-internal key hierarchy and KDF is assumed (due
> to the need to support ->derive_sw_secret).  While userspace doesn't need to
> know these details to use the feature normally, they *must* be known in order to
> test that it's actually working correctly.
>
> If we were to support variants of the feature, such as:
>
> * Hardware-wrapped keys must be created/prepared in some way other than
>    BLKCRYPTOCREATEKEY and BLKCRYPTOPREPAREKEY.  (Could you elaborate on
>    what this way actually is, in your case?)

We currently assume that the same entity that configured the device the first time
and pushed the first wrapping key to it is able to produce DEKs (Data Encryption keys)
which are passed to the software in a wrapped form, to be loaded to that particular
device as-is.
At our case, we produce the wrapped DEKs at a different machine which may be placed
at a more secured environment.

>
> * Hardware's key hierarchy or KDF is different, so userspace must do something
>    else when verifying the on-disk ciphertext.
>
> ... then we would need to precisely specify these other variants, and define a
> way for userspace to discover what it should do.
>
> In https://lore.kernel.org/r/20211208013534.136590-1-ebiggers@kernel.org, I'm
> proposing exposing the crypto capabilities of block devices via sysfs.  That
> could lead to a partial solution, e.g. the kernel could provide a file
>
> 	/sys/block/$disk/queue/crypto/wrapped_keys_variant
>
> ... which would allow userspace to discover the supported variant of
> hardware-wrapped keys.  I was really hoping that one variant could be
> standardized, but that is one possibility.
>
>>> Also, will your driver only support wrapped keys, or will it support standard
>>> keys too?
>> Our driver will support both modes. The first step is to support the
>> standard keys, because of
> Okay, great.  If you're adding inline encryption support to dm-crypt (or to
> dm-inline-crypt or to the block layer, depending on what people decide is the
> best approach), perhaps you should start with standard keys only, to avoid a
> dependency on the hardware-wrapped keys feature which is still being worked on?
Yes, I will do it.
>
>> the gap I mentioned above. As I understand, ->derive_sw_secret is not needed
>> for dm-crypt.
>>
>> Is that right?
> That's correct.  The larger issue is that if you don't support
> ->derive_sw_secret, then it's likely that your key hierarchy is different
> (probably you don't have a "hierarchy", but rather just one key), which would
> imply that the feature needs to be tested differently.
We plan to support also ->derive_sw_secret.
>
> As per the above, this could be accounted for in the design by allowing multiple
> variants of wrapped keys.  Of course, that would add complexity.
>
> - Eric


--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel