linux-kernel - Re: [PATCH v2] fscrypt: support trusted keys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Aug 2021 11:46:49 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Jarkko Sakkinen <jarkko@...nel.org>
Cc:     Ahmad Fatoum <a.fatoum@...gutronix.de>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>, kernel@...gutronix.de,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        James Bottomley <jejb@...ux.ibm.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Sumit Garg <sumit.garg@...aro.org>,
        David Howells <dhowells@...hat.com>,
        linux-fscrypt@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] fscrypt: support trusted keys

On Tue, Aug 10, 2021 at 09:06:36PM +0300, Jarkko Sakkinen wrote:
> > > 
> > > 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.

- Eric