On Wed, Aug 11, 2021 at 07:34:18AM -0400, Mimi Zohar wrote:

On Wed, 2021-08-11 at 03:17 +0300, Jarkko Sakkinen wrote:

quoted

On Tue, Aug 10, 2021 at 02:27:24PM -0700, Eric Biggers wrote:

quoted

On Wed, Aug 11, 2021 at 12:21:40AM +0300, Jarkko Sakkinen wrote:

quoted

On Tue, Aug 10, 2021 at 11:46:49AM -0700, Eric Biggers wrote:

quoted

On Tue, Aug 10, 2021 at 09:06:36PM +0300, Jarkko Sakkinen wrote:

quoted

quoted

quoted

I don't think this is right, or at least it does not follow the pattern
in [*]. I.e. you should rather use trusted key to seal your fscrypt key.

What's the benefit of the extra layer of indirection over just using a "trusted"
key directly?  The use case for "encrypted" keys is not at all clear to me.

Because it is more robust to be able to use small amount of trusted keys,
which are not entirely software based.

And since it's also a pattern on existing kernel features utilizing trusted
keys, the pressure here to explain why break the pattern, should be on the
side of the one who breaks it.

This is a new feature, so it's on the person proposing the feature to explain
why it's useful.  The purpose of "encrypted" keys is not at all clear, and the
documentation for them is heavily misleading.  E.g.:

    "user space sees, stores, and loads only encrypted blobs"
    (Not necessarily true, as I've explained previously.)

    "Encrypted keys do not depend on a trust source" ...  "The main disadvantage
    of encrypted keys is that if they are not rooted in a trusted key"
    (Not necessarily true, and in fact it seems they're only useful when they
    *do* depend on a trust source.  At least that's the use case that is being
    proposed here, IIUC.)

I do see a possible use for the layer of indirection that "encrypted" keys are,
which is that it would reduce the overhead of having lots of keys be directly
encrypted by the TPM/TEE/CAAM.  Is this the use case?  If so, it needs to be
explained.

If trusted keys are used directly, it's an introduction of a bottleneck.
If they are used indirectly, you can still choose to have one trusted
key per fscrypt key.

Thus, it's obviously a bad idea to use them directly.

So actually explain that in the documentation.  It's not obvious at all.  And
does this imply that the support for trusted keys in dm-crypt is a mistake?

Looking at dm-crypt implementation, you can choose to use 'encrypted' key
type, which you can seal with a trusted key.

Note: I have not been involved when the feature was added to dm-crypt.

At least for TPM 1.2,  "trusted" keys may be sealed to a PCR and then
extended to prevent subsequent usage.  For example, in the initramfs
all of the "encrypted" keys could be decrypted by a single "trusted"
key, before extending the PCR.

Mimi

Neither of you actually answered my question, which is whether the support for
trusted keys in dm-crypt is a mistake.  I think you're saying that it is?  That
would imply that fscrypt shouldn't support trusted keys, but rather encrypted
keys -- which conflicts with Ahmad's patch which is adding support for trusted
keys.  Note that your reasoning for this is not documented at all in the
trusted-encrypted keys documentation; it needs to be (email threads don't really
matter), otherwise how would anyone know when/how to use this feature?

- Eric