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.

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

adding TEE to threat model #33

Merged
merged 10 commits into from
Apr 10, 2024
22 changes: 22 additions & 0 deletions threat-model/readme.md
Original file line number Diff line number Diff line change
Expand Up @@ -213,6 +213,28 @@ TODO
#### 1.9.2 Mitigations
TODO

### 1.10 TEE

TEEs are hardware supported environments for computations that isolate associated processes from other processed on the host machine. TEEs are intended to provide confidentiality, integrity, and authenticity for computations against a, possibly malicious, operator of the host machine.

#### 1.10.1 Assets

1. Private attestation/identity key(s) embedded in TEEs by the manufacturer of the TEE. The TEE must maintain confidentiality for the attestation/identity key(s) in order to maintain authenticity of the TEE. That is, if the confidentiality of attestation/identity key(s) is compromised, then a TEE may be impersonated and not provide the expected guarantees.
2. The computation to be performed. This computation must be correct in that it produces the expected output on given input data and does not leak any input data outside of the TEE. This computation if part of the trusted code/computing base and the TEE cannot provide confidentiality for a computation that directly or indirectly reveals information about its inputs. The TEE is designed to provide integrity for the computation in that it will execute the attested computation as specified. Integrity is based on trust in the manufacturer constructing the TEE hardware according to specification and in integrity checking for any interactions with the host system, e.g. via memory.
3. Confidential inputs/outputs of the computation.

#### 1.10.2 Capabilities

1. Generate a signature, or "attestation", on the computation using the private attestation/identity key.
2. Execute the computation as specified with integrity and confidentiality against other processes and the operator.
3. Maintain a confidential and integrity checked communication channel between the TEE and the owner of the computation.

#### 1.10.3 Mitigations

1. Confidentiality of attestation/identity key: the TEE's private key(s) should never be accessible from outside the TEE and any operations involving them must be performed obliviously (independently of the key) to avoid leaking bits of the key via side channels.
3. Integrity of computation: any TEE assets leaving the TEE, e.g. to DRAM, must be integrity checked by the TEE upon return. This includes the initial inputs and final output of the computation over its communication channel with the computation owner.
4. Confidentiality of computation and its inputs/outputs: guaranteed based on confidentiality of the key(s) associated with the communication channel and resistance to side channel leakage (see 1.9 on TEE operators)
5. Authenticity of the computation: guaranteed based on confidentiality of the attestation/identity key.

### 1.10 TEE Manufacturers
Copy link
Collaborator

Choose a reason for hiding this comment

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

For other editors: time to renumber? Or maybe we just drop numbers entirely. This is where the limitations of the format stand out.

(Note that the "TEE Manufacturers" section includes subsection 1.9.1.

Copy link
Collaborator

Choose a reason for hiding this comment

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

fixed


Expand Down