[Teep] TEEP charter, attestation, and HW assurance

[Chris Inacio <[e-mail]>]

I have a question with regards to the chartering document:  Can we define the bounds of what we mean by “attestation” within the charter?

As a researcher at Carnegie-Mellon we’re also interested in the topic of trusting the hardware and understanding the supply chain from inception to delivery of product to the end user.  Taking into consideration the simply case, an Intel processor, there are still a lot of different “hands” that the device must pass through before I receive it and can make use of it.  ARM, being fabless, is almost too complicated to discuss here.  So the “attestation”, unless I’m particularly foolish (which is fairly likely) has its limits to what you can trust.

Probably out of scope, but might help refine the charter statement:
Are there any hardware devices with a PUF tied to their TEE that can be signed by the silicon manufacturer?  Is there any design of a PUF that can provide enough coverage of the TEE implementation to generate a good level of assurance?

If those aren’t out of scope - how would they be communicated in the protocol to understand the different levels of assurance that might be provided by the TEE?  Is it possible to have varying levels of TEE assurance communicated in the protocol for the various parties leveraging the TEE to make risk decisions on their usage?

REALLY OUT OF SCOPE:  Ideally for me, I would like to understand how to leverage a protocol like this to gain some type of assurance on an FPGA.  Granted the TEE on that device would like tremendously different, but I would like to be able to negotiate what that assurance could be that way.  Especially when it comes to things like having reconfigurable fabric on my desktop processor – Xeon anyone?

Thanks,
--
Chris Inacio
[e-mail]<mailto:[e-mail]>