linux-kernel - Re: [PATCH v5 0/4] Introduce TEE based Trusted Keys support

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, 02 Jun 2020 07:43:01 -0700
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Sumit Garg <sumit.garg@...aro.org>,
        jarkko.sakkinen@...ux.intel.com, zohar@...ux.ibm.com
Cc:     dhowells@...hat.com, jens.wiklander@...aro.org, corbet@....net,
        jmorris@...ei.org, serge@...lyn.com, casey@...aufler-ca.com,
        janne.karhunen@...il.com, daniel.thompson@...aro.org,
        Markus.Wamser@...ed-mode.de, keyrings@...r.kernel.org,
        linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        op-tee@...ts.trustedfirmware.org, tee-dev@...ts.linaro.org
Subject: Re: [PATCH v5 0/4] Introduce TEE based Trusted Keys support

On Tue, 2020-06-02 at 19:48 +0530, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the
> functionality to seal and unseal trusted keys using hardware unique
> key. Also, this is an alternative in case platform doesn't possess a
> TPM device.

So here's a meta problem: in the case when the platform possesses both
TEE and TPM  what should it do?  Things like this:

> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -25,6 +25,8 @@
>  
>  #if defined(CONFIG_TRUSTED_TPM)
>  static struct trusted_key_ops *trusted_key_ops =
> &tpm_trusted_key_ops;
> +#elif defined(CONFIG_TRUSTED_TEE)
> +static struct trusted_key_ops *trusted_key_ops =
> &tee_trusted_key_ops;
>  #else

Say it's either/or at a Kconfig level: so if you select both TEE and
TPM based trusted keys at compile time, we intall the TPM ops and
ignore the TEE ops, is that right?  Surely this should be runtime
selectable based on what the platform has ... perhaps it should even be
selectable per key?

Once it is runtime selectable, what should be selected in the both
case?  Or should we allow the user to decide, if so, how?

when you pipe a trusted key, I think the subtype (TEE or TPM) should be
part of the piped information, so it loads again seamlessly.  This
would actually be fixed by something like the ASN.1 scheme I'm trying
to upstream, at least for TPM keys, but do TEE keys have a recognized
ASN.1 format?

James