Trusted execution environment: Difference between revisions

Revision as of 15:37, 23 May 2024

Revision as of 20:03, 25 May 2024

Line 1:

A trusted '''trusted execution environment''' ('''TEE''') is a secure area of a [[Central processing unit|main processor]]. It helps the code and data loaded inside it to be protected with respect to [[Information security#Confidentiality|confidentiality and integrity]]. Data confidentiality prevents unauthorized entities from outside the TEE from reading data, while code integrity prevents code in the TEE from being replaced or modified by unauthorized entities, which may also be the computer owner itself as in certain [[Digital_rights_management|DRM]] schemes described in [[Software_Guard_Extensions|SGX]].

{{Advert|date=November 2022}}

This is done by implementing unique, immutable, and confidential architectural security such as [[Software Guard Extensions|Intel Software Guard Extensions]] (Intel SGX), which offers hardware-based memory encryption that isolates specific application code and data in memory. Intel SGX allows user-level code to allocate private regions of memory, called enclaves, which are designed to be protected from processes running at higher privilege levels.<ref>{{cite web | url=https://blog.quarkslab.com/introduction-to-trusted-execution-environment-arms-trustzone.html | title=Introduction to Trusted Execution Environment: ARM's TrustZone }}</ref><ref>{{cite web| url=https://globalplatform.org/wp-content/uploads/2018/04/131023-3-TLabs-livre_blanc.pdf | title=Security evaluation of Trusted execution environments: Why and how? | access-date=2024-02-15}}</ref><ref name="oulpita.com">{{cite web |url=https://poulpita.com/2014/02/18/trusted-execution-environment-do-you-have-yours/ |title=Trusted Execution Environment, millions of users have one, do you have yours? |website=Poulpita |date=2014-02-18 |access-date=2017-05-17 |archive-date=2021-01-27 |archive-url=https://web.archive.org/web/20210127231827/https://poulpita.com/2014/02/18/trusted-execution-environment-do-you-have-yours/ |url-status=live }}</ref> A TEE as an isolated execution environment provides security features such as isolated execution, integrity of applications executing with the TEE, alongand confidentiality of their assets.<ref>{{cite web|url=https://www.youtube.com/watch?v=PmtQtWpfW3w|title=The benefits of Trusted Execution Environment (TEE)|last=Ram Kumar Koppu|date=26 October 2013|publisher=[[YouTube]]|access-date=31 July 2014|archive-date=1 September 2020|archive-url=https://web.archive.org/web/20200901094254/https://www.youtube.com/watch?v=PmtQtWpfW3w|url-status=live}}</ref> 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).

{{Short description|Secure area of a main processor}}

A '''trusted execution environment''' ('''TEE''') is a secure area of a [[Central processing unit|main processor]]. It helps code and data loaded inside it to be protected with respect to [[Information security#Confidentiality|confidentiality and integrity]]. Data confidentiality prevents unauthorized entities from outside the TEE from reading data, while code integrity prevents code in the TEE from being replaced or modified by unauthorized entities, which may also be the computer owner itself as in certain [[Digital_rights_management|DRM]] schemes described in [[Software_Guard_Extensions|SGX]].

This is done by implementing unique, immutable, and confidential architectural security such as [[Software Guard Extensions|Intel Software Guard Extensions]] (Intel SGX) which offers hardware-based memory encryption that isolates specific application code and data in memory. Intel SGX allows user-level code to allocate private regions of memory, called enclaves, which are designed to be protected from processes running at higher privilege levels.<ref>{{cite web | url=https://blog.quarkslab.com/introduction-to-trusted-execution-environment-arms-trustzone.html | title=Introduction to Trusted Execution Environment: ARM's TrustZone }}</ref><ref>{{cite web| url=https://globalplatform.org/wp-content/uploads/2018/04/131023-3-TLabs-livre_blanc.pdf | title=Security evaluation of Trusted execution environments: Why and how? | access-date=2024-02-15}}</ref><ref name="oulpita.com">{{cite web |url=https://poulpita.com/2014/02/18/trusted-execution-environment-do-you-have-yours/ |title=Trusted Execution Environment, millions of users have one, do you have yours? |website=Poulpita |date=2014-02-18 |access-date=2017-05-17 |archive-date=2021-01-27 |archive-url=https://web.archive.org/web/20210127231827/https://poulpita.com/2014/02/18/trusted-execution-environment-do-you-have-yours/ |url-status=live }}</ref> A TEE as an isolated execution environment provides security features such as isolated execution, integrity of applications executing with the TEE, along confidentiality of their assets.<ref>{{cite web|url=https://www.youtube.com/watch?v=PmtQtWpfW3w|title=The benefits of Trusted Execution Environment (TEE)|last=Ram Kumar Koppu|date=26 October 2013|publisher=[[YouTube]]|access-date=31 July 2014|archive-date=1 September 2020|archive-url=https://web.archive.org/web/20200901094254/https://www.youtube.com/watch?v=PmtQtWpfW3w|url-status=live}}</ref> 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 Applicationsapplications," 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.<ref>{{cite web |url=http://www.gsma.com/newsroom/wp-content/uploads/2012/03/omtpadvancedtrustedenvironmentomtptr1v11.pdf |title=Omtp Hardware Requirements And Defragmentation |website=Gsma.org |date= |access-date=2017-05-17 |archive-date=2018-12-14 |archive-url=https://web.archive.org/web/20181214114609/https://www.gsma.com/newsroom/wp-content/uploads/2012/03/omtpadvancedtrustedenvironmentomtptr1v11.pdf |url-status=live }}</ref>

Commercial TEE solutions based on ARM [[TrustZone]] technology, conforming to the TR1 standard, were later launched, such as Trusted Foundations developed by Trusted Logic.<ref>{{Cite web|url=http://www.trusted-logic.com/IMG/pdf/TRUSTED_LOGIC_TRUSTED_FOUNDATIONS_OMTP_FINAL.pdf|archive-url = https://web.archive.org/web/20140903041544/http://www.trusted-logic.com/IMG/pdf/TRUSTED_LOGIC_TRUSTED_FOUNDATIONS_OMTP_FINAL.pdf|archive-date = 2014-09-03|title = Gemalto's website has moved to Thales}}</ref>

Line 16 ⟶ 13:

==Details==

The TEE typically consists of a hardware isolation mechanism, plus a secure operating system running on top of that isolation mechanism –, although the term has been used more generally to mean a protected solution.<ref>{{cite book |last1=Sabt |first1=M |title=2015 IEEE Trustcom/BigDataSE/ISPA |pages=57–64 |last2=Achemlal |first2=M |last3=Bouabdallah |first3=A |chapter=Trusted Execution Environment: What It is, and What It is Not |publisher=IEEE |doi=10.1109/Trustcom.2015.357 |year=2015 |isbn=978-1-4673-7952-6 |s2cid=206775888 |url=https://hal.archives-ouvertes.fr/hal-01246364/file/trustcom_2015_tee_what_it_is_what_it_is_not.pdf |access-date=2020-04-19 |archive-date=2020-07-18 |archive-url=https://web.archive.org/web/20200718094655/https://hal.archives-ouvertes.fr/hal-01246364/file/trustcom_2015_tee_what_it_is_what_it_is_not.pdf |url-status=live }}</ref><ref>{{cite journal |last1=Pinto |first1=S. |last2=Santos |first2=N. |date=2019 |title=Demystifying Arm TrustZone: A Comprehensive Survey |url=https://doi.org/10.1145/3291047 |journal=ACM Computing Surveys |volume=51 |pages=1–36 | doi=10.1145/3291047|s2cid=59337370 }}</ref><ref>{{cite journal |last1=Lee |first1=S |last2=Lee |first2=JH |title=TEE based session key establishment protocol for secure infotainment systems |journal=Design Automation for Embedded Systems |volume=22 |issue=3 |pages=215–224 |publisher=Springer |doi=10.1007/s10617-018-9212-5 |year=2018 |s2cid=52081114 }}</ref><ref>{{cite book |last1=Shepherd |first1=C |title=2016 IEEE Trustcom/BigDataSE/ISPA |pages=168–177 |last2=Arfaoui |first2=G |last3=Gurulian |first3=I |last4=Lee |first4=R |last5=Markantonakis |first5=K |last6=Akram |first6=R |last7=Sauveron |first7=D |last8=Conchon |first8=E |chapter=Secure and Trusted Execution: Past, Present, and Future - A Critical Review in the Context of the Internet of Things and Cyber-Physical Systems |publisher=IEEE |doi=10.1109/TrustCom.2016.0060 |year=2016 |isbn=978-1-5090-3205-1 |s2cid=8717045 |url=https://core.ac.uk/download/pdf/77298166.pdf |access-date=2021-05-14 |archive-date=2021-05-14 |archive-url=https://web.archive.org/web/20210514194356/https://core.ac.uk/download/pdf/77298166.pdf |url-status=live }}</ref> Whilst a GlobalPlatform TEE requires hardware isolation, others, such as EMVCo, use the term TEE to refer to both hardware/software and only software-based solutions.<ref>{{cite web |title=Software-Based Mobile Payment Evaluation Process |url=https://www.emvco.com/processes-forms/product-approval/mobile/sbmp |publisher=EMVCo |access-date=2021-10-13 |archive-date=2021-03-02 |archive-url=https://web.archive.org/web/20210302083210/https://www.emvco.com/processes-forms/product-approval/mobile/sbmp/ |url-status=live }}</ref> FIDO uses the concept of TEE in the restricted operating environment for TEEs based on hardware isolation.<ref>{{cite web |title=FIDO Authenticator Allowed Restricted Operating Environments List |url=https://fidoalliance.org/specs/fido-security-requirements-v1.0-fd-20170524/fido-authenticator-allowed-restricted-operating-environments-list_20170524.html |publisher=FIDO Alliance |access-date=2021-10-13 |archive-date=2021-07-13 |archive-url=https://web.archive.org/web/20210713153906/https://fidoalliance.org/specs/fido-security-requirements-v1.0-fd-20170524/fido-authenticator-allowed-restricted-operating-environments-list_20170524.html |url-status=live }}</ref> 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 isolationcryptogaphic inside the TEE protect the trusted applications contained within from each other.<ref>{{cite web|url=https://www.trustonic.com/products-services/trusted-execution-environment|title=Solutions - Trustonic- Securing Smart Devices & Mobile Applications|website=Trustonic.com|access-date=2014-07-31|archive-date=2014-08-10|archive-url=https://web.archive.org/web/20140810221846/https://www.trustonic.com/products-services/trusted-execution-environment|url-status=live}}</ref>

Service providers, [[mobile network operator]]s (MNO), operating system developers, [[Mobile Application Development|application developers]], device manufacturers, platform providers, and silicon vendors are the main stakeholders contributing to the standardization efforts around the TEE.

Line 24 ⟶ 21:

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.<ref>{{Cite web|url=https://www.researchgate.net/publication/342833256|title=Towards Formalization of Enhanced Privacy ID (EPID)-based Remote Attestation in Intel SGX}}</ref>

When an application is attested, its untrusted components loads its trusted component into memory; the trusted application is protected from modification by untrusted components with hardware. A [[Cryptographic nonce|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.<ref>{{cite web | url=https://optee.readthedocs.io/en/latest/building/devices/qemu.html | title=QEMU v7 — OP-TEE documentation documentation }}</ref>

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 the equipment and technical skill required to execute it. For example, using [[Focused ion beam|focused ion beams]], [[scanning electron microscopes]], [[microprobing]], and chip [[decapping|decapsulation]]<ref>{{Cite web|url=https://hackaday.com/2014/04/01/editing-circuits-with-focused-ion-beams/|title=Editing Circuits with Focused Ion Beams|date=April 2014|access-date=2020-11-14|archive-date=2020-11-28|archive-url=https://web.archive.org/web/20201128163919/https://hackaday.com/2014/04/01/editing-circuits-with-focused-ion-beams/|url-status=live}}</ref><ref>{{Cite web |url=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 |title=Advanced IC reverse engineering techniques: in depth analysis of a modern smart card |access-date=2020-11-14 |archive-date=2020-11-14 |archive-url=https://web.archive.org/web/20201114133949/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 |url-status=live }}</ref><ref>Finding the AES Bits in the Haystack: Reverse Engineering and SCA Using Voltage Contrast by

Christian Kison, Jürgen Frinken, and Christof Paar - https://www.iacr.org/archive/ches2015/92930620/92930620.pdf {{Webarchive|url=https://web.archive.org/web/20201116132154/https://www.iacr.org/archive/ches2015/92930620/92930620.pdf |date=2020-11-16 }}</ref><ref>{{Cite news |last1=Cassy |first1=John |last2=Murphy |first2=Paul |date=2002-03-13 |title=How codebreakers cracked the secrets of the smart card |language=en-GB |work=The Guardian |url=https://www.theguardian.com/technology/2002/mar/13/media.citynews |access-date=2023-08-09 |issn=0261-3077}}</ref><ref>{{Cite web |url=https://spectrum.ieee.org/nanoclast/semiconductors/design/xray-tech-lays-chip-secrets-bare |title=X-Ray Tech Lays Chip Secrets Bare - IEEE Spectrum<!-- Bot generated title --> |date=7 October 2019 |access-date=2020-11-14 |archive-date=2020-12-08 |archive-url=https://web.archive.org/web/20201208180315/https://spectrum.ieee.org/nanoclast/semiconductors/design/xray-tech-lays-chip-secrets-bare |url-status=live }}</ref><ref>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 {{Webarchive|url=https://web.archive.org/web/20210121185937/https://www.usenix.org/legacy/events/smartcard99/full_papers/kommerling/kommerling.pdf |date=2021-01-21 }}</ref> is difficult, or even impossible, if the hardware is designed in such a way that reverse-engineering destroys the keys. In most cases, the keys are unique for each piece of hardware, so that a key extracted from one chip cannot be used by others (for example [[Physical unclonable function|physically unclonable functions]]<ref>{{Cite web|url=https://semiengineering.com/knowledge_centers/semiconductor-security/physically-unclonable-functions/|title=Physically Unclonable Functions (PUFs)|website=Semiconductor Engineering|access-date=2020-11-15|archive-date=2020-11-16|archive-url=https://web.archive.org/web/20201116222448/https://semiengineering.com/knowledge_centers/semiconductor-security/physically-unclonable-functions/|url-status=live}}</ref><ref>Areno, Matthew & Plusquellic, J.. (2012). Securing Trusted Execution Environments with PUF Generated Secret Keys. 1188-1193. 10.1109/TrustCom.2012.255.</ref>).

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, by burning a hash of antheir own key into e-fuses), 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, this way [[monetization|monetizing]] the user base of the hardware, to enable such use cases as [[tivoization]] and DRM and to allow certain hardware features to be used only with vendor-supplied software, forcing users to use it despite of its [[antifeature]]s, like [[Advertising|ads]], tracking and use case restriction for [[market segmentation]].

==Uses==

Line 35 ⟶ 32:

===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]].<ref>{{Cite web | title = Digital Restrictions Management and Treacherous Computing Free Software Foundation working together for free software | access-date = 2019-08-20 | url = https://www.fsf.org/campaigns/drm.html | archive-date = 2018-07-05 | archive-url = https://web.archive.org/web/20180705233004/https://www.fsf.org/campaigns/drm.html | url-status = live }}</ref> It is widely used by copyright 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 smartphones, tablets, and HD televisions. This suitability comes from the ability of the TEE to deprive the owner of the device fromof readingaccess 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:. whileWhile 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 the app developer or platform vendor.

===Mobile financial services===