On 1/13/21 4:23 PM, Jarkko Sakkinen wrote:

On Tue, Jan 12, 2021 at 10:55:44AM +0530, Sumit Garg wrote:

quoted

On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen [off-list ref] wrote:

quoted

On Mon, Jan 04, 2021 at 06:06:33PM +0530, Sumit Garg wrote:

quoted

Hi Jarkko, On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen 
[off-list ref] wrote:

quoted

On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:

quoted

From: Elaine Palmer <redacted> Update trusted key 
documentation with additional comparisons between discrete TPMs 
and TEE. Signed-off-by: Elaine Palmer [off-list ref] 

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.

quoted

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