Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture

[Dave Thaler <[e-mail]>]

[...]

a) It is not clear from the Introduction how TEE is different from a Closed OS like Google Chromebook or Windows 10S ?

[...]



[DT] The document (intentionally) makes no statement about whether a "close OS" as you put it, is or is not a TEE.   The question is really about whether such an OS prevents code injection attacks (e.g., due to buffer overruns or whatever else), prevents data modification attacks, etc.



[TR] Closed OS prevent the above attacks, a malicious app cannot read/modify the data of the other apps (e.g., ransomware attack is not possible, see https://support.google.com/chromebook/answer/3438631?hl=en<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.google.com%2Fchromebook%2Fanswer%2F3438631%3Fhl%3Den&data=02%7C01%7Cdthaler%40microsoft.com%7C4a1e761bc5b7412883c508d794d8f70d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637141531903517840&sdata=AqPSd3PJDgbfJRXfJMRIg7EiK8GYWqGY3XNaFQJj5tQ%3D&reserved=0>).



That link contains insufficient information to say whether a ransomware attack is possible, or whether the environment meets the other criteria of a TEE.  For example, the page mentions verified boot, which checks at boot time, but contains no statements about whether code modifications or additions are prevented post-boot.   The Sandboxing section implies (especially the part about "app" in there) that code can be added after boot, without requiring a security protocol equivalent to the TEEP protocol.  As such, I suspect it is inherently weaker than a TEE, and it would be an REE with classic security techniques.



It is not, however, the intent of this document to state whether such an OS is, or is not, a TEE.   The intent is to state the criteria for what is a TEE, and then provide an architecture for provisioning one, in a way that is sufficient for a reader to draw their own conclusions.



Dave