Hi Elaine, On Sat, 16 Jan 2021 at 04:45, Elaine Palmer <erpalmerny@xxxxxxxxx> wrote: > > > > 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. > Sure, I will update documentation to mention this as a recommendation. > 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. Similar is the case with TEEs which can have varying hardware realizations. Have a look at "Figure 2-3: Example Hardware Realizations of TEE" from TEE system architecture specification [1]. [1] https://globalplatform.org/specs-library/tee-system-architecture-v1-2/ > > 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. > Agree. -Sumit > -Elaine > >
