A Trusted Execution Environment (TEE) is an environment for executing code, in which those executing the code can have high levels of trust in that surrounding environment, because it can ignore threats from the rest of the device.
What is wrong with my phone?
At one level, nothing. It is a superb device that can do hundreds of tasks that once upon a time you needed multiple devices to achieve… but therein lies a problem.
With that ability to do many tasks comes masses of software. The more software, the larger the number of places where there may be a security issue (a larger “attack surface”) and the higher the likelihood that vulnerabilities will be found. To work around that issue, the Trusted Execution Environment (TEE) was developed by a consortium of concerned parties; from network operators, through manufacturers, to OS vendors.
What is a Trusted Execution Environment (TEE)?
A Trusted Execution Environment (TEE) is an environment for executing code, in which those executing the code can have high levels of trust in the asset management of that surrounding environment because it can ignore threats from the “unknown” rest of the devicei. Hence TEE stands for Trusted Execution Environment and to distinguish them from the uncertain nature of applications in the REE (REE? Wait a second…), applications in the TEE are known as Trusted Applications (TAs). Generally, the rest of the device hosts a feature Rich OS like Android™, and so is generically known in this context as the REE (Rich Operating System Execution Environment).
Trust in a Trusted Execution Environment (TEE)
There are many interpretations of what is meant by Trust. In the TEE it is used to imply that you may have a higher level of trust in validity, isolation and access control in items (assets) stored in this space, when compared to more general purpose software environments. This then ripples down to an assertion that the Trusted OS and Trusted Applications executing inside that space are more trustworthy.
Why is a Trusted Execution Environment more Trustworthy?
Secure start-up
In the TEE, that Trust requires that all TEE related assets, code, the underlying Trusted OS and its support code, have been installed and started through a methodology that requires its initial state to be as expected by the designers (i.e. EVERYTHING is signature checked, immutable, or held in isolation).
TEEs only accept code for execution that has been:
- Appropriately authorized
- And where that authorization has been checked by other authorized code
- And that includes everything from after ROMii boot
- (you can consider the ROM code authorized by its presence).
TA’s can only directly access their own data (including key) assets:
- There is no method for a TA to directly access assets of other TAs or other components of the TEE.
In an ideal world:
- A sample TEE is tested by some lab that you could trust (maybe because the lab was itself certified by other labs and the government)
- The TEE is able to attest to its current trustworthy state in some manner
- And you trust the device manufacturer to have reproduced the test sample TEE in production devices so that the attestation is valid.
In the real world, few users want to pay sufficiently for that ideal, so we get:
- The TEE attests through the services it offers that it is in a trustworthy state.
- If the TEE boot or service signature checks fail, the TEE must not offer that service or dependent services.
And you trust the device manufacturer to have built the TEE correctly, so that such TEE or Service attestation is valid.
Note this is quite different from the original Trusted Computing model, where any code could execute, but that code was potentially verifiable after booting by remote entities. That model doesn’t work so well in devices where some trust is wanted by the local user, without reference to an external entity.
Runtime Isolation
Signature checking during installation, booting, and loading of material is great but
… what happened 1 second later?
To maintain the Trust we must stop interference with the executing code and its assets at run-time. To do this the hardware TEE is isolated from the rest of the device, and TEE provides isolation between the Trusted Applications and other assets inside the TEE.
- A given Trusted Application (TA) in the TEE only has to trust the Trusted OS and doesn’t have to care what other TAs are present in the TEE.
- And it also means a TA’s assets are isolated from all other environments in the device.
- The user of the TEE based software knows they can have confidence that their assets cannot be exposed, modified or deleted without authorization (within the isolation profile of the particular TEEiii).
Isolation example: A TA has no method to open a file owned by another TA:
- If TA1 creates a file called “Secrets”, TA2 can also create a file called “Secrets”, but the Trusted OS treats them as two different files. TA2 can do what it likes with its file and it can make no changes to TA1s file.
- And nothing in the REE can access the contents of either TAs file.
It is worth noting that an attacker cannot even manually copy a TA’s assets between devices to try and defeat TEE security, TEE storage is all bound to the device.
Some Trusted Execution Environments are better than others
Trustonic’s Kinibi OS for the TEE is a Microkernel design. This provides more isolation and so reduces the risk if something goes wrong in part of the Trusted OS.
In addition,
- The cryptographic parts of Kinibi are resistant to execution unit utilization, branch predictor, timing and cache-based side channel attacks.
- Kinibi also makes use of ASLR and stack protection to reduce the risk of unauthorized execution through buffer overruns and similar attacks.
- And (predictably) yes… Kinibi’s code is vetted for Spectre and uses methodologies to guard against Meltdown
Remote Management
Some TEEs are designed to restrict themselves to a limited use case, meeting the needs of a specific manufacturer. However, because of the quality of the internal isolation, TEEs that we care about here are designed to enable a devices best security to be leveraged by developers beyond the initial production-line installers. To securely install code and assets after production requires a trustworthy remote management infrastructure, where operations are controlled through secure channels or cryptographically secured tokens. Key management provides isolation of assets, and asset control, to all but the direct owners.
Following the TEE isolation philosophy, TEE remote management is designed such that specific remote managers can be given control of a subset of applications but have no ability to interfere with the rest of those in the TEE. For example, an OEM may manage its TAs, and a bank may be able to manage its TAs, but neither could interfere with the other’s TAs.
What else makes an execution environment become “a TEE”?
Not all devices host a Trusted Execution Environment that is open to non-OEM applications, and not all devices host the same TEE. Not all code running in Arm® TrustZone® technology isolated environment conforms to the above ideals of a TEE, though it is a great place to build a TEE.
If you are interested in using more than one model of a device, then compliance with standards will widen the potential list of targets that will safely run your software. GlobalPlatform (well known for its work in the Secure Element standards behind UICCs, bank cards and e-passports) also defines standards for TEE isolation, manageability, and functionality. Specifically, they describe the overall architecture expected of a TEE and have a consistency compliance requirement (with associated testing lab-based testing) defined in documents such as:
- GPD TEE Internal Core API (Originally published in 2011)
- GPD TEE Client API (Still as published in 2010)
Along with defining an internationally recognized Common Criteria Protection Profile to certify the security properties of the TEE against:
If you wish to remotely manage a TEE and its Trusted Applications, then there is also a standard to help you with that:
- GPD TEE Management Framework (Originally published in 2018)
It could be argued that if the TEE doesn’t meet these standards then it is not a TEE, but it would be more correct to say it is not a GlobalPlatform certifiable TEE, and so you are placing your Trust in a particular Manufacturers’ ideas, rather than the combination of:
- A manufacturer,
- Their compliance to standards defined by a consortium of security experts,
- And (optionally as noted) the ability of test houses to certify against that standard.
Luckily most manufacturers in the Android space (i.e. all the top 10 by volume in 2018) support GlobalPlatform functionality in their TEEs, allowing security critical components of service provider software to be rolled out across that generic smartphone space.
Where is a TEE?
So, the above generally describes the usage model that is as found in Smartphones and Tablets.
TEEs appear in Smartwatches, Set-top boxes, and (prepare yourself for a huge shock) even constrained Internet of Things (IoT) devices.
In simple IoT devices, the REE and the TEE may not have a full OS but rather suites of software libraries. While such simple devices do not generally have end-user installed software, they go through a chain of manufacturing where each entity may not entirely trust the next entity. A well-managed TEE can enable those entities to work together even without that trust.
Conclusion
Trusted Execution Environment (TEE) technology enables modern devices to provide a massive range of functionality, while at the same time meeting the requirements of software developers and service providers who care about privacy, attestation, authentication, validation, manageability and all the other aspects of security.
References
http://globalplatform.org/specs-library/tee-management-framework-v1/
http://globalplatform.org/specs-library/tee-client-api-specification/
http://globalplatform.org/specs-library/tee-protection-profile-v1-2-1/
http://globalplatform.org/specs-library/globalplatform-technology-tee-trusted-user-interface-low-level-api-v1-0-1/
http://globalplatform.org/specs-library/tee-internal-core-api-specification-v1-2/
http://globalplatform.org/specs-library/tee-system-architecture-v1-2/
Footnotes
iExcept for those threats that the application exposes itself too! If you write your Trusted Application software badly the TEE cannot stop you (though it will stop you exposing someone else’s secrets)
iiROM – when we say ROM we mean ROM (Read Only Memory) and not any form of reprogrammable storage such as FLASH. ROM code is set during the design of the SOC and cannot be modified later. For this reason, it is very simple but for the TEE it has to be able to perform signature checking in some manner.
iiiSorry but these weasel words are required in security. A well-designed TEE can be VERY hard to break into, just look at the trouble one caused the FBI: https://9to5mac.com/2016/04/07/fbi-iphone-hack-method-secure-enclave/.
Terms & Abbreviations – Trusted Execution Environment & TrustZone
2FA
2 Factor Authentication—an extra layer of security that requires you to supply at least two proofs of identity when attempting to access an asset; for example, a password AND access to a mobile phone on a particular account.
ASLR
Address Space Layout Randomisation—a form of obfuscation commonly employed to prevent an attacker making unauthorised function calls inside code.
Closed TEE
A TEE that is under the control of the ODM or OEM such that no other parties can install TAs. A closed TEE provides only a restricted set of services, much like an HSM.
Device
A combination of one or more platforms (and potentially one or more devices) in one discrete physical object. For example, a mobile SIM card is a SE platform in a device, and that device is inserted into the mobile phone device that may also contain the TEE platform and the REE platform(S).
DFA
Differential Fault Analysis—a “side channel” method to discover secrets by monitoring changes caused by induced faults in the electronic signals inside a device. For example, a fault causes a secret to be written to screen memory rather than its normal location.
DPA
Differential Power Analysis – A “side channel” method to discover secrets by monitoring changes in power usage of a device.
DRAM
Dynamic Random Access Memory – A form of memory that can be written and read at high speed. It requires a periodic update to keep its contents valid.
FLASH
Silicon-based, non-volatile memory (NVM) that has no moving parts. The technology behind this is typically 3 or 4 generations behind the technology for making processor cores and SoCs, so Flash cannot be integrated directly onto the same silicon as processing cores.
KISS
Keep It Simple Stupid—a design philosophy that recognises that with increased complexity comes more potential for bugs and security holes. From a security point of view, this results in putting the security critical pieces of code in a separate isolated silo to reduce this risk.
MMU
Memory Management Unit – A silicon component that restricts and maps the memory access of a process.
NFC
Near Field Communications. – A limited range radio technology that can be used as a method of indicating close presence as well as establishing data communication.
NVM
Non Volatile Memory – Memory that retains its contents when power is turned off.
ODM
Original Design Manufacturer – typically refers to a manufacturer that does not make a consumer product but produces something that other manufacturers use as a component in a product. This may include Whitebox manufacturers whose product is then “branded” by a retailer.
OEM
Original Equipment Manufacturer—typically refers to a manufacturer that produces final consumer products.
Open TEE
A TEE that is open to the installation of 3rd-party service provider TAs.
Operator Card Set
A set of chip (SE) containing cards with HSM-wrapped secrets and potentially keys, that allow the HSM to associate a specific card with a particular operation or operations that the HSM may provide. The use of an SE makes it harder to generate unauthorised copies.
OTP
One-time Programable—a form of memory that may be written to once, commonly used for small data assets including keys and hashes. Note that some forms of OTP should be considered OTP on a per bit basis. These start with a value 0xFF that can be written to become 0xF0. They cannot then be changed to 0xFF again but may be changed to 0x00. To prevent this, a second piece of OTP memory must be used to “”Lock values”” and prevent further changes.
Platform
A single execution environment that can be thought of as a single domain of trust isolated from any other domains. Examples of a platform in a mobile phone might be; • The REE running a Rich SO such as Android or IOS • The UICC running JavaCard applications • The TEE running GP-compliant Trusted Applications • The Base Band OS running dedicated telephony-related services Note this is the use defined in GlobalPlatform but other definitions exist.
REE
Rich Operating System Execution Environment – Originally considered to hold the Rich OS(s). Now, due to the deployment of TEE technology in IoT environments where the “”other OS”” may not be consider feature-rich, the REE may also be described as holding the Device OS(s). In one sense, it should be considered “everything else” inside the device that is not part of the current TEE and hence capable of attacking the TEE. In terms of security, the REE should include components such as Secure Elements and other TEEs if present, but for simplicity, these are kept separate.
Rich OS
The “main” operating system inside a device. Such an OS is designed to provide the users access to the general software functionality of a device and is considered “feature rich”. Typical examples are Linux, Android, iOS, Windows. In a TEE-enabled device, this Rich OS runs in the REE, alongside the TEE and may make use of some services offered by TA’s. In IOT devices, this may not be an OS as such, but a set of generic services, such as an internet access stack.
Root of Trust
Root of Trust (RoT) – GlobalPlatform have a detailed document defining root Root of Trust [GP_RoT] which is the basis for our usage here. A Root of Trust is a combination of software, hardware and data, providing a service, for which no other combination of software, hardware and data is capable of attesting the initial state.
SE
Secure Element – A Secure Element (SE) is a microprocessor chip that can store sensitive data and run secure apps such as payment. It is the secure computing device found in places such as UICC’s, microSD cards, HSM Operator Card Sets and Bank Cards.
Service Provider
A generic term in TEE and SE circles for the application developer or the entity that makes use of applications to provide a service. While often focused on the TA Developer, in the TEE case the service provider may be linking Cloud Services, Rich OS applications and/or Trusted Applications.
SiP
Silicon Provider – The organisation that fabricates and packages the silicon. It may also be defined as the organisation responsible for the hardware aspects of the chip security, along with (in some cases) the first layer of ROM RoT software to run on the chip. The SiP product is typically taken and used by ODM, if needed, and finally OEM to make a final product.
SoC
System On Chip—the technique of taking all the discrete components found in a traditional PC and integrating them into a single piece of silicon. This has advantages because the connection between those components can run much faster and/or at much lower power consumption. There is also a security advantage in that it becomes much harder to probe communications between those integrated components.
SRAM
Static Random Access Memory—a form of memory that can be written and read at high speed. It does not require a periodic update to keep its contents valid, but takes up a larger amount of silicon space compared to DRAM.
SRW
Short Range Wireless—the generic term for low-power wireless communication definitions such as BlueTooth, ZigBee, or NFC. A method of indicating close presence as well as establishing communication.
TEE
Trusted Execution Environment—an environment that is isolated from other environments, has gone through a boot process that has signature-checked all loadable components of its boot- and run-time environment, and into which only signature-checked application software is loaded. Technically, a TEE can be instigated in something like a Secure Element but, typically, is implemented using technology such as ARM TrustZone Technology [ARM_TZ].
TPM
Trusted Platform Module—a hardware security module dedicated to recording the power-up boot state of a single platform in a series of registers called PCRs, and providing a signed attestation to that state to external parties.
Trusted OS
A TEE is composed of software and hardware components. The Trusted OS is the component that exposes run-time capabilities to enable and manage Trusted Applications. In IOT devices, this may not be an OS as such, but a set of generic services, such as a TLS stack enabling secure communications to off-device entities.
