tee manufacturer draft #34
Conversation
threat-model/readme.md
Outdated
|
|
||
| #### 1.9.1 Assets | ||
|
|
||
| 1. Private keys embedded in TEEs and their corresponding public keys. | ||
| 1. Private keys embedded in TEEs. These mush be confidential and known only to the TEE. | ||
| 2. List of public keys corresponding to valid attestation/identity private keys embedded in TEEs. This list must be correct in that it contains only the public keys corresponding to private keys embedded in the hardware of TEEs that were manufactured according to the desired specification. If this is not the case, then valid attestations may be provided by hardware that does have the expected properties or guarantees. It must also be public so that parties other than the manufacturer are able to recognize valid TEE hardware. |
There was a problem hiding this comment.
Is it really the case that this is a list? There are a bunch of ways of formulating this, but I believe that the public information is generally abstracted in some way, if only because it is easier to move a small set of intermediate certificates (or equivalent) than a whole list.
Maybe a different way to approach this is to just say:
Information about the current set of public keys that are deployed in TEEs that are considered valid. A TEE is considered valid if it provides the properties or guarantees required of an application. Over time, the set of TEEs that are considered valid will change as new hardware is manufactured or attacks are discovered that disqualify specific TEE implementations. A TEE manufacturer needs to provide information or services that can enable users of TEEs to determine whether a given public key corresponds to a private key that is deployed in a TEE that is considered valid. In practice, TEE manufacturers generally use a public key infrastructure (PKI) system for this purpose.
There was a problem hiding this comment.
Yep, list is not correct. I like your suggestion.
There was a problem hiding this comment.
made an attempt at incorporating in 09aa86c
| 1. Private keys embedded in TEEs and their corresponding public keys. | ||
| 1. Private keys embedded in TEEs. These mush be confidential and known only to the TEE. | ||
| 2. List of public keys corresponding to valid attestation/identity private keys embedded in TEEs. This list must be correct in that it contains only the public keys corresponding to private keys embedded in the hardware of TEEs that were manufactured according to the desired specification. If this is not the case, then valid attestations may be provided by hardware that does have the expected properties or guarantees. It must also be public so that parties other than the manufacturer are able to recognize valid TEE hardware. | ||
| 3. TEE hardware |
There was a problem hiding this comment.
Is this "Access to TEE hardware during manufacture. As manufacture includes the provision of private keys into TEE hardware, the TEE manufacturer potentially knows, and could use, private keys to generate attestations."
...or is that a capability?
There was a problem hiding this comment.
For "TEE hardware" I was more going for that they can literally construct whatever they want, according to spec or not.
I do think It's worth mentioning that the manufacturer probably knew the private keys at some point and is expected to do a good job forgetting about them (though might not). Trying to construct enclaves where the key is not known at any point (potentially via a PUF) is an interesting problem.
threat-model/readme.md
Outdated
| 1. If an attacker controls both the cloud provider and the TEE manufacturer, decrypt all data within the TEE. | ||
| 1. Construct TEEs | ||
| 2. Embed private attestation/identity keys in TEEs | ||
| 3. Maintain PKI for TEEs |
There was a problem hiding this comment.
Given the framing above, this is more about moving public keys in or out of the set of those that are considered valid. That a PKI is used for this is detail.
There was a problem hiding this comment.
Agreed, but doesn't calling it a PKI still work here? However it's implemented it will still need to map public keys to valid identities.
There was a problem hiding this comment.
My understanding is that "PKI" has very specific connotations for most people.
There was a problem hiding this comment.
changed to "Act as authority on which keys are considered valid TEE attestation/identity keys" in f01ced2
threat-model/readme.md
Outdated
| 1. Collusion between the TEE manufacturer and TEE operator: not resolvable through technical means. The manufacturer could publish a fake public key such that the corresponding private key is known to the TEE operator, allowing it to provide valid attestations without any of the guarantees of a TEE. | ||
| 2. Confidentiality of TEE private keys: The manufacturer should not store private attestation/identity keys beyond what was required to embed them in the TEE hardware. Otherwise, a data breach at the manufacturer would allow impersonation of existing TEEs, compromising authenticity. | ||
| 3. PKI: The manufacturer should maintain their TEE PKI according to best practices. In particular they must maintain confidentiality of their root key and provide a mechanism for revocation. Compromise of the root key necessarily compromises authenticity of all associated TEEs. | ||
| 4. Construction of TEEs: If a TEE is not constructed according to specification then it may not provide the expected confidentiality, authenticity, and integrity guarantees for computations. This can be somewhat mitigated by open source specifications and independent verification of the TEE hardware. |
There was a problem hiding this comment.
The construction of the specification also needs to meet requirements. (That's what your point about open specification relates to.)
There was a problem hiding this comment.
Should the specification be listed as an asset then? That feels more correct.
There was a problem hiding this comment.
made more explicit in f01ced2
AramZS
added
the
call-for-consensus
AramZS
added
Threat Model Document
AramZS
added
the
needs-work
Draft for the TEE manufacturer. Should it have references?
Also see: #32 which adds the TEE operator and #33 which adds the TEE itself.