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

adding tee operator. too much side channel? #32

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

adding tee operator. too much side channel? #32

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
3f5d2da
adding tee operator. too much side channel?
kylehogan Feb 21, 2023
8b01bf2
Update threat-model/readme.md
kylehogan Feb 22, 2023
ecc99ee
Update threat-model/readme.md
kylehogan Feb 22, 2023
52cea4f
Update threat-model/readme.md
kylehogan Feb 22, 2023
f05b5e7
add tag
kylehogan Feb 22, 2023
581b229
split out cold boot attacks
kylehogan Feb 22, 2023
80fa02e
rm manufacturer tag
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
15 changes: 11 additions & 4 deletions threat-model/readme.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -200,18 +200,25 @@ Helper parties may run either on physical machines owned by directly by the aggr

### 1.9 Operators of TEEs

As a piece of hardware, TEEs will have an operator with access to the machine. Most commonly, this will be a cloud provider. Depending on the specific hardware, there may be known vulnerabilities in which an attacker who only controls the operator can violate the obliviousness of client/user data. These attacks are outside this threat model, but are likely to inform specific web platform decisions about which instantiations of private computation to support.
Trusted Execution Environments (TEEs) offer hardware supported confidential computing.
The operator of a TEE is the entity who controls the physical host machine on which this hardware is installed.
Most commonly, the operator will be a cloud provider.

#### 1.9.1 Assets
TODO
1. The host machine with the TEE hardware installed.


#### 1.9.2 Capabilities
TODO
1. The ability to run arbitrary processes on the host machine. TEEs are designed to provide confidentiality and integrity despite this, but, in practice may be vulnerable to side channel leakage via, e.g., the cache or memory access patterns or speculative/transient execution attacks like Spectre. (see Section 1.10 for more on the capabilities of a TEE.)
kylehogan marked this conversation as resolved.
Show resolved Hide resolved
2. Physical access to the host machine. The operator typically has physical access to the machine that hosts the TEE. Thus, it may attempt to compromise confidentiality via a cold boot attack or side channels using power consumption, acoustics, or temperature.
3. Ability to deny service by restricting access to the TEE. Denial of service can present an issue if the operator is able *selectively* restrict operation of the TEE based on the output of its computation.


#### 1.9.2 Mitigations
TODO
1. Microarchitectural side channel mitigations: microarchitectural side channels arise due to resource sharing between the TEE processes and other processes on the host machine. They can be mitigated by ensuring spatial and temporal isolation of the TEE processes though this has proved challenging in practice and no existing TEE is free of side channel leakage.
kylehogan marked this conversation as resolved.
Show resolved Hide resolved
2. Speculative/transient execution mitigations: turn off speculative execution.
3. Physical access mitigations: To mitigate cold boot attacks any TEE assets stored off the trusted hardware, e.g. in DRAM, must be encrypted and integrity checked. Defending against power/acoustic/temperature side channels requires preventing the operator from observing these features or by executing TEE processes obliviously (execution is fully independent of the confidential input data).
Copy link
Collaborator

Choose a reason for hiding this comment

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

This might be split:

Suggested change
3. Physical access mitigations: To mitigate cold boot attacks any TEE assets stored off the trusted hardware, e.g. in DRAM, must be encrypted and integrity checked. Defending against power/acoustic/temperature side channels requires preventing the operator from observing these features or by executing TEE processes obliviously (execution is fully independent of the confidential input data).
3. To mitigate cold boot attacks any TEE assets stored off the trusted hardware, e.g. in DRAM, must be encrypted and integrity checked.
4. Defending against power/acoustic/temperature side channels requires preventing the operator from observing these features or by executing TEE processes obliviously (execution is fully independent of the confidential input data).

Though I think that the latter could be:

Defending against attacks that use power/acoustic/temperature side channels requires either preventing the operator from observing these features by limiting physical access in some way or by executing TEE processes obliviously (that is, eliminating any potential for side channel information by using computation that does not depend on the content of any confidential data).

Out of curiosity, what is the state of the art as it relates to timing side channels? You don't mention them, but these no doubt exist as well and leak information to more than just those with physical access to the machine.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think this section in particular is quite rough and needs to be workshopped a bit.

I separated side channels out into microarchitectural, speculative (a special kind of microarchitectural really), and physical where this is the means an adversary uses to observe something about the program execution. The something observed is very often a timing difference. Maybe there is a better way to describe side channels that makes this more clear? Especially because some of the more traditionally physical attacks can be executed remotely now: Hertzbleed

It might also make sense to pull oblivious execution out into its own mitigation as it really applies more generally (but isn't typically a viable option due to the performance).

(agreed on splitting cold boot attacks out)

4. Denial of service: ensure that the inputs and outputs of the computation remain confidential so that the operator cannot selectively deny service.


### 1.10 TEE Manufacturers
kylehogan marked this conversation as resolved.
Show resolved Hide resolved
Expand Down