On 1/13/21 4:23 PM, Jarkko Sakkinen wrote:
On Tue, Jan 12, 2021 at 10:55:44AM +0530, Sumit Garg wrote:
On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote:
On Mon, Jan 04, 2021 at 06:06:33PM +0530, Sumit Garg wrote:
Hi Jarkko, On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen
<jarkko@xxxxxxxxxx> wrote:
On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:
From: Elaine Palmer <erpalmer@xxxxxxxxxx> Update trusted key
documentation with additional comparisons between discrete TPMs
and TEE. Signed-off-by: Elaine Palmer <erpalmer@xxxxxxxxxx>
Right, so OP-TEE is not the same as TEE. I did not know this and
the patch set does not underline this. I re-checked the patches
and none of them say explicitly that OP-TEE is an application
living inside TEE.
This patch-set provides a trust source based on generic TEE
interface where underlying TEE implementations like OP-TEE
(drivers/tee/optee/), AMD TEE (drivers/tee/amdtee/) etc. can easily
be hooked up. And this is similar to the TPM interface where
underlying TPM implementations like discrete TPM, virtual TPM,
firmware TPM etc. can be easily hooked up.
This essentially means that the backend needs to be renamed as
"op_tee".
I don't see any need for this, see above.
Right, TEE is a protocol standard, just like TPM, and OP-TEE is one
implementation of this interface? I.e. OP-TEE does not define API
that is hard bound to OP-TEE?
Yes, OP-TEE doesn't define a hard bound client interface API. The
client API is based on TEE client API specification [1] from
GlobalPlatform. [1]
http://globalplatform.org/specs-library/tee-client-api-specification/
-Sumit
Thanks, bookmarked. No need for name change. /Jarkko
This discussion has illustrated that even those of us who live and
breathe this stuff could use clarification. Shouldn't we recommend
that the Trust Source have a hardware root of trust? We could be
even more specific. For example, the documentation could recommend
that a TPM be evaluated under "TCG Protection Profile for PC Client
Specific TPM 2.0" or later and a TEE be evaluated under GlobalPlatform
"TEE Protection Profile v1.3, GPD_SPE_021" or later. Of course, our
recommendation would not be a requirement, but it would provide
guidance for deployment as well as precedent for future Trust Sources.
I know where I'm getting stuck is on TEEs as a concept vs
TEEs with specific hardware requirements and interfaces.
The same applies to TPMs. There are hardware TPMs that meet
the protection profile and there are other implementations
(e.g., vTPMs) that use the same interface, but aren't anchored in
hardware.
I know if I were deploying a server, mobile device, or IoT device, I'd
want to know exactly what is protecting my keys. A generic TPM or TEE
doesn't tell me enough.
-Elaine
