Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tee manufacturer draft #34

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

tee manufacturer draft #34

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d3a4ae3
tee manufacturer draft
kylehogan Feb 21, 2023
09aa86c
fix numbering, incorporate martins suggestion
kylehogan Feb 22, 2023
f01ced2
TEE specification and PKI
kylehogan Feb 22, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 19 additions & 11 deletions threat-model/readme.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -214,38 +214,46 @@ TODO
TODO


### 1.10 TEE Manufacturers
### <a id="tee-manufacturers"></a>1.11 TEE Manufacturers

TEEs can provide "attestation" which verifies that the TEE is running in the expected state and running the expected code. These attestations are typically produced with an asymmetric key, where the private key is physically embedded into the TEE, and the public key is published via a system similar to a certificate authority.
The TEE manufacturer is responsible for constructing the physical TEE hardware according to a specification and managing the associated public key infrastructure (PKI).

#### 1.9.1 Assets
#### 1.11.1 Assets

1. Private keys embedded in TEEs and their corresponding public keys.
1. Private keys embedded in TEEs. These must be confidential and known only to the TEE.
2. Publicly available mechanism allowing users to discover and recognize valid public keys corresponding to attestation/identity private keys embedded in TEEs. In practice, TEE manufacturers generally use a public key infrastructure (PKI) system for this purpose. It is up to the manufacturer to define validity, but at a minimum such keys must not have been compromised and must belong to TEEs that were constructed correctly according to the specification. If this is not the case, then valid attestations may be provided by [hardware](#tee-hardware) that does have the expected properties or guarantees. Over time, the set of keys that are considered valid may change as keys become compromised, new TEE specifications are developed, or attacks are discovered that disqualify specific TEE specifications.
3. TEE hardware
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

4. Specification for TEE design. The specification must be for a TEE design that provides the necessary confidentialty and integrity guarantees.

#### 1.9.2 Capabilities
#### 1.11.2 Capabilities

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. Act as authority on which keys are considered valid TEE attestation/identity keys


#### 1.9.2 Mitigations
#### 1.11.2 Mitigations

1. Pick a configuration of TEE manufacturer and cloud operator where it can be assumed that an attacker cannot control both.
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: In practice, the manufacturer typically manages validity for attestation/identity keys by acting as the authority for a 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 and specification of TEEs: If a TEE is not constructed according to specification or the specification is not correct 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.


### 1.11. Attacker on the network
### 1.12. Attacker on the network

We assume the existence of attackers on the network links between various parties.


#### 1.11.1. Capabilities
#### 1.12.1. Capabilities

1. Observation of network traffic. Attackers may observe messages exchanged between parties exchanged at the IP layer.
1. Time of transmission by clients could reveal information about user activity.
2. Observation of message size could allow the attacker to learn how much input is being submitted by a specific user.
3. Tampering with network traffic. Attackers may drop messages or inject new messages into communication between parties.


#### 1.11.2. Mitigations
#### 1.12.2. Mitigations

1. All messages exchanged between parties should be encrypted / use TLS / use HTTPS.
2. All messages between aggregators and to/from first/third parties should be mutually authenticated to prevent impersonation.
Expand Down