Thread (12 messages) 12 messages, 3 authors, 2020-06-18

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

From: Sumit Garg <hidden>
Date: 2020-06-03 08:08:03
Also in: keyrings, linux-doc, linux-integrity, linux-security-module, lkml, op-tee

On Tue, 2 Jun 2020 at 20:14, James Bottomley [off-list ref] wrote:
On Tue, 2020-06-02 at 19:48 +0530, Sumit Garg wrote:
quoted
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?
IMO, trust source (either a TPM or a TEE) should be unique and
carefully chosen as per platform security policy corresponding to a
particular threat model.

And moreover TEEs have been mostly used in the embedded world where
having a hardware TPM is cumbersome given constraints regarding BoM
cost and hardware resources.
 Things like this:
quoted
--- 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 ...
This dynamic selection was already part of v4 patch-set but after
objection from Jarrko here [1], I switched to compile time mode
instead.

[1] https://lkml.org/lkml/2020/6/2/139
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?
I guess this is something which we can refine later if there are real
platforms that have a particular security requirement to support both
TPM and a TEE.

-Sumit
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help