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

TEE Definition #68

Closed
hannestschofenig opened this issue Sep 23, 2019 · 6 comments
Closed

TEE Definition #68

hannestschofenig opened this issue Sep 23, 2019 · 6 comments
Assignees
Labels
ready to close Ready for WG chairs to verify and close

Comments

@hannestschofenig
Copy link
Collaborator

We use the following term:

"

  • Trusted Execution Environment (TEE): An execution environment that
    runs alongside of, but is isolated from, an REE.
    "

Cristofaro Mune suggested to use the following definition instead:

"

  • Trusted Execution Environment (TEE): An execution environment that
    runs alongside of, but is separated from, an REE.
    "

Argument: Isolated means that the TEE and the REE do not communicate

@hannestschofenig
Copy link
Collaborator Author

He also suggests to add extra language to point out that there is a HW / SW cooperation.

Trusted Execution Environment (TEE): An execution environment that
runs alongside of, but is separated from, an REE by means of strong HW and SW cooperation.

@hannestschofenig
Copy link
Collaborator Author

Additionally, it might be useful to highlight that the TEE needs to provide separation between (a) REE and TEE, (b) provide isolation between TAs, and (c) prevent TAs from subverting the TEE OS.

@hannestschofenig
Copy link
Collaborator Author

It may be worthwhile to note that there is, in the general case, no protection of the REE from the TEE side.

@dthaler
Copy link
Collaborator

dthaler commented Sep 24, 2019

I think I disagree with most of those suggestions. To me a TEE is anything that provides hardware enforcement that: (1) only authorized code can execute within the TEE, and (2) data used by that code cannot be read or tampered with by code outside the TEE.

There may or may not be any such thing as a TEE OS, a TEE may or may not support multiple TAs (and hence provide isolation between them), there may or may not be an REE on the same device, so none of those topics should be part of the "definition" in my view.

@hannestschofenig
Copy link
Collaborator Author

I agree with the second part of your statement because it is specific to TrustZone. Maybe it would, however, be worthwhile in the appendix to talk about the security guarantees provided by different TEEs to indicate the differences.

Regarding the first point I thought the remarks are good because the point out that a TEE is a system-wide concept is not just a hardware-based mechanism.

dthaler added a commit that referenced this issue Nov 12, 2019
Also removes "Client" App duplication with "Untrusted" App,
where the latter is preferred since the app may be the server
side of some protocol like HTTP, and so Client is confusing.

Signed-off-by: Dave Thaler <dthaler@microsoft.com>
@dthaler
Copy link
Collaborator

dthaler commented Nov 12, 2019

See proposed changes in #71

dthaler added a commit that referenced this issue Nov 27, 2019
Addresses issue #68

Problems were:
* "isolated" implied that TEE<->REE can't communicate
* some TEEs have no REE on the same device
* avoid question as to whether hypervisor based environments are TEEs
  or not by removing the word "hardware" from the strict definition

Signed-off-by: Dave Thaler <dthaler@microsoft.com>
@dthaler dthaler mentioned this issue Nov 27, 2019
@dthaler dthaler self-assigned this Nov 27, 2019
@dthaler dthaler added have proposed text Ready for other editors to review and merge if ok ready to close Ready for WG chairs to verify and close and removed have proposed text Ready for other editors to review and merge if ok labels Nov 27, 2019
@dthaler dthaler assigned ncamwing and unassigned dthaler Dec 3, 2019
dthaler added a commit that referenced this issue Dec 7, 2019
Proposed fixes for issues #53, #54, #55, and #68
@dthaler dthaler added ready to close Ready for WG chairs to verify and close and removed ready to close Ready for WG chairs to verify and close labels Dec 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready to close Ready for WG chairs to verify and close
Projects
None yet
Development

No branches or pull requests

4 participants