Trusted execution environment

A trusted execution environment (TEE) is a secure area of a main processor. It guarantees code and data loaded inside to be protected with respect to confidentiality and integrity.[1] A TEE as an isolated execution environment provides security features such as isolated execution, integrity of applications executing with the TEE, along with confidentiality of their assets.[2] In general terms, the TEE offers an execution space that provides a higher level of security for trusted applications running on the device than a rich operating system (OS) and more functionality than a 'secure element' (SE).

History

The Open Mobile Terminal Platform (OMTP) first defined TEE in their "Advanced Trusted Environment:OMTP TR1" standard, defining it as a "set of hardware and software components providing facilities necessary to support Applications" which had to meet the requirements of one of two defined security levels. The first security level, Profile 1, was targeted against only software attacks and while Profile 2, was targeted against both software and hardware attacks.[3]

Commercial TEE solutions based on ARM TrustZone technology, conforming to the TR1 standard, were later launched, such as Trusted Foundations developed by Trusted Logic.[4]

Work on the OMTP standards ended in mid 2010 when the group transitioned into the Wholesale Applications Community (WAC).[5]

The OMTP standards, including those defining a TEE, are hosted by GSMA.[6]

Details

The TEE is a standard which creates an isolated environment that runs in parallel with the operating system, providing security for the rich environment. It is intended to be more secure than the User-facing OS. ARM TrustZone TEE is an implementation of the TEE standard. TrustZone TEE is a hybrid approach that utilizes both hardware and software to protect data.[7][8] It therefore offers a level of security sufficient for many applications. Only trusted applications running in a TEE have access to the full power of a device's main processor, peripherals and memory, while hardware isolation protects these from user installed apps running in a main operating system. Software and cryptographic isolation inside the TEE protect the trusted applications contained within from each other.[9]

Service providers, mobile network operators (MNO), operating system developers, application developers, device manufacturers, platform providers and silicon vendors are the main stakeholders contributing to the standardization efforts around the TEE.

To prevent simulation of hardware with user-controlled software, a so-called "hardware root of trust" is used. This is a set of private keys (so-called "endorsement keys" or "provisioned secrets") which are embedded directly into the chip during manufacturing (one-time programmable memory such as eFuses are usually used, despite the large area on the chip they take), cannot be changed, and whose public counterparts reside in a manufacturer database, together with a non-secret hash of a public key belonging to the trusted party (usually a chip vendor) which is used to sign trusted firmware alongside the circuits doing cryptographic operations and controlling access. The hardware is designed in a way which prevents all software not signed by the trusted party's key from accessing the privileged features. The public key of the vendor is provided at runtime and hashed; this hash is then compared to the one embedded in the chip. If the hash matches, the public key is used to verify a digital signature of trusted vendor-controlled firmware (such as a chain of bootloaders on Android devices or 'architectural enclaves' in SGX). The trusted firmware is then used to implement remote attestation.[10]

An untrusted component of an application required to be attested loads the trusted one into memory. The trusted application is protected from modification by untrusted components with hardware. A nonce is requested by the untrusted party from verifier's server, and is used as a part of a cryptographic authentication protocol, proving integrity of the trusted application. The proof is passed to the verifier, which verifies it. A valid proof cannot be computed in a simulated hardware (i.e. QEMU) because in order to construct it, access to the keys baked into hardware is required; only trusted firmware has access to these keys and/or the keys derived from them or obtained using them. Because only the platform owner is meant to have access to the data recorded in the foundry, the verifying party must interact with the service set up by the vendor. If the scheme is implemented improperly, the chip vendor can track which applications are used on which chip and selectively deny service by returning a message indicating that authentication has not passed.

To simulate hardware in a way which enables it to pass remote authentication, an attacker would have to extract keys from the hardware, which is costly because of equipment and reverse-engineering skills required (focused ion beam, scanning electron microscope, microprobing, decapsulation) [11][12][13][14][15][16] or even impossible, if the hardware is designed in such a way that reverse-engineering destroys the keys. In some cases, the keys are unique for each piece of hardware, so that a key extracted from one chip is useless for another ones (for example physically unclonable functions[17][18]).

Though deprivation of ownership is not an inherent property of TEEs (it is possible to design the system in a way that allows only the user who has obtained ownership of the device first to control the system), in practice all such systems in consumer electronics are intentionally designed so as to allow chip manufacturers to control access to attestation and its algorithms. It allows manufacturers to grant access to TEEs only to software developers who have a (usually commercial) business agreement with the manufacturer, and to enable such use cases as tivoization and DRM.

Uses

There are a number of use cases for the TEE. Though not all possible use cases exploit the deprivation of ownership, TEE is usually used exactly for this.

Premium Content Protection/Digital Rights Management

Note: Much TEE literature covers this topic under the definition "premium content protection" which is the preferred nomenclature of many copyright holders. Premium content protection is a specific use case of Digital Rights Management (DRM), and is controversial among some communities, such as the Free Software Foundation.[19] It is widely used by copyrights holders to restrict the ways in which end users can consume content such as 4K high definition films.

The TEE is a suitable environment for protecting digitally encoded information (for example, HD films or audio) on connected devices such as smart phones, tablets and HD televisions. This suitability comes from the ability of the TEE to deprive owner of the device from reading stored secrets, and the fact that there is often a protected hardware path between the TEE and the display and/or subsystems on devices.

The TEE is used to protect the content once it is on the device: while the content is protected during transmission or streaming by the use of encryption, the TEE protects the content once it has been decrypted on the device by ensuring that decrypted content is not exposed to the environment not approved by app developer OR platform vendor.

Mobile financial services

Mobile Commerce applications such as: mobile wallets, peer-to-peer payments, contactless payments or using a mobile device as a point of sale (POS) terminal often have well-defined security requirements. TEEs can be used, often in conjunction with near field communication (NFC), SEs and trusted backend systems to provide the security required to enable financial transactions to take place.

In some scenarios, interaction with the end user is required, and this may require the user to expose sensitive information such as a PIN, password or biometric identifier to the mobile OS as a means of authenticating the user. The TEE optionally offers a trusted user interface which can be used to construct user authentication on a mobile device.

Authentication

The TEE is well-suited for supporting biometric ID methods (facial recognition, fingerprint sensor and voice authorization), which may be easier to use and harder to steal than PINs and passwords. The authentication process is generally split into three main stages:

  • Storing a reference "template" identifier on the device for comparison with the "image" extracted in next stage.
  • Extracting an "image" (scanning the fingerprint or capturing a voice sample, for example).
  • Using a matching engine to compare the "image" and the "template".

A TEE is a good area within a mobile device to house the matching engine and the associated processing required to authenticate the user. The environment is designed to protect the data and establish a buffer against the non-secure apps located in mobile OS. This additional security may help to satisfy the security needs of service providers in addition to keeping the costs low for handset developers.

Enterprise, government, and cloud

The TEE can be used by governments, enterprises, and cloud service providers to enable the secure handling of confidential information on mobile devices and on server infrastructure. The TEE offers a level of protection against software attacks generated in the mobile OS and assists in the control of access rights. It achieves this by housing sensitive, ‘trusted’ applications that need to be isolated and protected from the mobile OS and any malicious malware that may be present. Through utilizing the functionality and security levels offered by the TEE, governments and enterprises can be assured that employees using their own devices are doing so in a secure and trusted manner. Likewise, server-based TEEs help defend against internal and external attacks against backend infrastructure.

Secure modular programming

With the rise of software assets and reuses, modular programming is the most productive process to design software architecture, by decoupling the functionalities into small independent modules. As each module contains everything necessary to execute its desired functionality, the TEE allows to organize the complete system featuring a high level of reliability and security, while preventing each module from vulnerabilities of the others.

In order for the modules to communicate and share data, TEE provide means to securely have payloads sent/received between the modules, using mechanisms such as objects serialization, in conjunction with proxies.

See Component-based software engineering

Hardware support

The following hardware technologies can be used to support TEE implementations:

See also

References
  1. "Trusted Execution Environment, millions of users have one, do you have yours?". Poulpita. 2014-02-18. Retrieved 2017-05-17.
  2. Ram Kumar Koppu (26 October 2013). "The benefits of Trusted Execution Environment (TEE)". YouTube.
  3. "Omtp Hardware Requirements And Defragmentation" (PDF). Gsma.org. Retrieved 2017-05-17.
  5. "OMTP announces final documents prior to transition into Wholesale Application Community". Mobileeurope.co.uk.
  6. "OMTP documents". Gsma.com. May 2012. Retrieved 12 September 2014.
  7. Sabt, M; Achemlal, M; Bouabdallah, A (2015). "Trusted Execution Environment: What It Is, and What It Is Not". 2015 IEEE Trustcom/BigDataSE/ISPA (PDF). IEEE. IEEE. pp. 57–64. doi:10.1109/Trustcom.2015.357. ISBN 978-1-4673-7952-6. S2CID 206775888.
  8. Lee, S; Lee, JH (2018). "TEE based session key establishment protocol for secure infotainment systems". Design Automation for Embedded Systems. Springer. 22 (3): 215–224. doi:10.1007/s10617-018-9212-5. S2CID 52081114.
  9. "Solutions - Trustonic- Securing Smart Devices & Mobile Applications". Trustonic.com.
  10. "Towards Formalization of Enhanced Privacy ID (EPID)-based Remote Attestation in Intel SGX".
  11. https://hackaday.com/2014/04/01/editing-circuits-with-focused-ion-beams/
  12. https://www.blackhat.com/docs/us-15/materials/us-15-Thomas-Advanced-IC-Reverse-Engineering-Techniques-In-Depth-Analysis-Of-A-Modern-Smart-Card.pdf
  13. Finding the AES Bits in the Haystack: Reverse Engineering and SCA Using Voltage Contrast by Christian Kison, Ju ̈rgen Frinken, and Christof Paar - https://www.iacr.org/archive/ches2015/92930620/92930620.pdf
  14. How codebreakers cracked the secrets of the smart card - https://www.theguardian.com/technology/2002/mar/13/media.citynews
  15. https://spectrum.ieee.org/nanoclast/semiconductors/design/xray-tech-lays-chip-secrets-bare
  16. Design Principles for Tamper-Resistant Smartcard Processors by Oliver Kömmerling Advanced Digital Security and Markus G. Kuhn University of Cambridge https://www.usenix.org/legacy/events/smartcard99/full_papers/kommerling/kommerling.pdf
  17. https://semiengineering.com/knowledge_centers/semiconductor-security/physically-unclonable-functions/
  18. Areno, Matthew & Plusquellic, J.. (2012). Securing Trusted Execution Environments with PUF Generated Secret Keys. 1188-1193. 10.1109/TrustCom.2012.255.
  19. "Digital Restrictions Management and Treacherous Computing Free Software Foundation working together for free software". Retrieved 2019-08-20.
  20. "AMD Secure Processor (Built-in technology)". Amd.com.
  21. "Secure Hardware and the Creation of an Open Trusted Ecosystem" (PDF). Classic.regonline.com. Retrieved 2017-05-17.
  22. Chiappetta, Marco (2014-04-29). "AMD Beema and Mullins Low Power 2014 APUs Tested - Page 2". HotHardware. Retrieved 2017-05-17.
  23. "AMD MEMORY ENCRYPTION" (PDF). developer.amd.com. April 21, 2016. |first= missing |last= (help)
  24. "AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More" (PDF). January 2020.
  25. "GlobalPlatform based Trusted Execution Environment and TrustZone Ready" (PDF). Arm.com.
  26. "IBM Secure Service Container". ibm.com.
  27. "Family 2965+01 IBM z13s Models N10 and N20". ibm.com.
  28. "Technical overview of Secure Execution for Linux on IBM Z". ibm.com.
  29. "The Trusted Execution Environments on Mobile Devices" (PDF). Cs.helsinki.fi. Retrieved 2017-05-17.
  30. "WW46_2014_MCG_Tablet_Roadmap_图文_百度文库". Wenku.baidu.com.
  31. "CyanogenMod/android_device_asus_mofd-common". GitHub.
  32. "heidiao/sfp_m2_bt". GitHub.
  33. "Hex Five Security Adds MultiZone™ Trusted Execution Environment to the SiFive Software Ecosystem". hex-five.com. Retrieved 2018-09-13.
  34. "Keystone Paper and Customizable TEEs". keystone-enclave.org. Retrieved 2020-05-17.
  35. "Penglai Enclave". penglai-enclave.systems/. Retrieved 2020-10-04.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.