Content deleted Content added
→Details: Added link. Tags: Mobile edit Mobile app edit Android app edit App select source |
|||
| (37 intermediate revisions by 31 users not shown) | |||
Line 1:
{{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 the code and data loaded inside it
This is done by implementing unique, immutable, and confidential architectural security ==History==
The
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>
Work on the OMTP standards ended in mid
The OMTP standards, including those defining a TEE, are hosted by [[GSMA]].<ref>{{cite web|url=http://www.gsma.com/newsroom/gsmadocuments/omtp-documents/|title=OMTP documents|last=|first=|date=May 2012|website=Gsma.com|access-date=12 September 2014|archive-date=19 February 2015|archive-url=https://web.archive.org/web/20150219080703/http://www.gsma.com/newsroom/gsmadocuments/omtp-documents/|url-status=live}}</ref>
==Details==
The TEE typically consists of a hardware isolation mechanism
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.
To prevent the simulation of hardware with user-controlled software, a so-called "hardware root of trust" is used. This is a [[Trusted_computing#Endorsement_key|set of private keys that are embedded directly into the chip during manufacturing]]; one-time programmable memory such as [[eFuse]]s
The hardware is designed in a way that 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 [[Booting process of Android devices|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 component 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>▼
▲When an application is attested, its untrusted
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 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=Archived copy |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>).▼
▲To simulate hardware in a way
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 an 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]].▼
▲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 |archive-date=2021-04-07 |archive-url=https://web.archive.org/web/20210407025459/https://www.theguardian.com/technology/2002/mar/13/media.citynews |url-status=live }}</ref><ref>{{Cite web |url=https://spectrum.ieee.org
▲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
==Uses==
Line 31 ⟶ 33:
===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)
The TEE is a suitable environment for protecting digitally encoded information (for example, HD films or audio) on connected devices such as
The TEE is used to protect the content once it is on the device
===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 operating system|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.
With the rise of cryptocurrency, TEEs are increasingly used to implement crypto-wallets, as they offer the ability to store tokens more securely than regular operating systems, and can provide the necessary computation and authentication applications.<ref>{{cite web |title=Ethereum Wallet in a Trusted Execution Environment / Secure Enclave |date=7 June 2018 |url=https://medium.com/weeves-world/ethereum-wallet-in-a-trusted-execution-environment-secure-enclave-b200b4df9f5f |publisher=Medium |access-date=2021-10-13 |archive-date=2021-07-15 |archive-url=https://web.archive.org/web/20210715233259/https://medium.com/weeves-world/ethereum-wallet-in-a-trusted-execution-environment-secure-enclave-b200b4df9f5f |url-status=live }}</ref>
===Authentication===
The TEE is well-suited for supporting biometric identification 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 the next stage.
* Extracting an "image" (scanning the fingerprint or capturing a voice sample
* Using a matching engine to compare the "image" and the "template".
Line 54 ⟶ 56:
===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 operating system|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
In order for the modules to communicate and share data, TEE
See [[Component-based software engineering]]
Line 76 ⟶ 78:
| Cloud Link TEE
|
| [[GlobalPlatform|GlobalPlatform]]
| Full
| <ref>{{cite web |title=Alibaba Cloud Link Tee V1.1.3 |url=https://globalplatform.org/certified-products/alibaba-cloud-link-tee-pro-edition-v113/ |publisher=GlobalPlatform |access-date=2021-10-13 |archive-date=2021-10-26 |archive-url=https://web.archive.org/web/20211026232042/https://globalplatform.org/certified-products/alibaba-cloud-link-tee-pro-edition-v113/ |url-status=live }}</ref>
Line 107 ⟶ 109:
|
| <ref>{{cite web |title=Trusty TEE |url=https://source.android.com/security/trusty |publisher=Google Android |access-date=2021-10-13 |archive-date=2021-10-14 |archive-url=https://web.archive.org/web/20211014154123/https://source.android.com/security/trusty |url-status=live }}</ref>
|-▼
|▼
|-
| [[Linaro]]
Line 121 ⟶ 116:
|
| <ref>{{cite web |title=Security, Trustzone and OP-TEE |url=https://www.linaro.org/services/security/ |publisher=[[Linaro]] |access-date=2021-10-13 |archive-date=2021-02-27 |archive-url=https://web.archive.org/web/20210227094924/https://www.linaro.org/services/security/ |url-status=live }}</ref>
▲|-
| ProvenRun
| ProvenCore
| ARM TrustZone
|
▲|
|-
| [[Qualcomm]]
Line 130 ⟶ 132:
|-
| [[Samsung]]
| TEEgris and [[Samsung Knox|Knox]]
| ARM TrustZone
| GlobalPlatform
Line 141 ⟶ 143:
| GlobalPlatform
|
| <ref>{{cite web |title=Enhance Device Security With T6 |url=https://www.trustkernel.com/en/products/tee/t6.html |publisher=TrustKernel |access-date=2021-10-13 |archive-date=2021-10-29 |archive-url=https://web.archive.org/web/20211029203221/https://www.trustkernel.com/en/products/tee/t6.html |url-status=live }}</ref>
|-
| Trustonic
Line 148 ⟶ 150:
| GlobalPlatform
| Full
| <ref name=kinibi>{{cite web |title=Certificate of Security Evaluation - Kinibi 410A |url=https://globalplatform.org/wp-content/uploads/2019/12/GP-TEE-2019_03-CR-1.0_GP190005-Certificate-and-Certification-Report_20191203.pdf |publisher=GlobalPlatform |access-date=2021-10-13 |archive-date=2021-10-26 |archive-url=https://web.archive.org/web/20211026232004/https://globalplatform.org/wp-content/uploads/2019/12/GP-TEE-2019_03-CR-1.0_GP190005-Certificate-and-Certification-Report_20191203.pdf |url-status=live }}</ref>
|-
| Trustonic
Line 170 ⟶ 172:
| GlobalPlatform
| Full
| <ref>{{cite web |title=WatchTrust 2.1.1 on SC9860 |url=https://globalplatform.org/wp-content/uploads/2018/09/GP-TEE-2018_01-CR-1.0_GP170003-Certificate-Certification-Report_20180904-signed-1.pdf |publisher=GlobalPlatform |access-date=2021-10-13 |archive-date=2021-10-26 |archive-url=https://web.archive.org/web/20211026232006/https://globalplatform.org/wp-content/uploads/2018/09/GP-TEE-2018_01-CR-1.0_GP170003-Certificate-Certification-Report_20180904-signed-1.pdf |url-status=live }}</ref>
|}
Line 177 ⟶ 179:
* [[AMD]]:
** [[AMD Platform Security Processor|Platform Security Processor]] (PSP)<ref name="amd.com">{{cite web|url=https://www.amd.com/en-us/innovations/software-technologies/security|title=AMD Secure Processor (Built-in technology)|website=Amd.com|access-date=2017-09-17|archive-date=2017-09-19|archive-url=https://web.archive.org/web/20170919154841/http://www.amd.com/en-us/innovations/software-technologies/security|url-status=live}}</ref><ref>{{cite web |url=https://classic.regonline.com/custImages/360000/369552/TCC%20PPTs/TCC2013_VanDoorn.pdf |title=Secure Hardware and the Creation of an Open Trusted Ecosystem |website=Classic.regonline.com |access-date=2017-05-17 |archive-date=2017-01-15 |archive-url=https://web.archive.org/web/20170115011459/https://classic.regonline.com/custImages/360000/369552/TCC%20PPTs/TCC2013_VanDoorn.pdf |url-status=live }}</ref><ref>{{cite web |last=Chiappetta |first=Marco |url=http://hothardware.com/Reviews/AMD-Beema-and-Mullins-Mainstream-and-LowPower-2014-APUs-Tested/?page=2#!bFIw4K |title=AMD Beema and Mullins Low Power 2014 APUs Tested - Page 2 |publisher=HotHardware |date=2014-04-29 |access-date=2017-05-17 |archive-date=2017-04-07 |archive-url=https://web.archive.org/web/20170407031130/http://hothardware.com/reviews/amd-beema-and-mullins-mainstream-and-lowpower-2014-apus-tested?page=2#!bFIw4K |url-status=dead }}</ref>
** AMD Secure Encrypted Virtualization (SEV)<ref name="OpenVirtualization">{{cite web|date=April 21, 2016|title=AMD MEMORY ENCRYPTION|url=https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf|
* [[ARM architecture|ARM]]:
** [[TrustZone]]<ref>{{cite web|url=https://community.arm.com/cfs-file/__key/telligent-evolution-components-attachments/01-2142-00-00-00-00-51-36/GlobalPlatform-based-Trusted-Execution-Environment-and-TrustZone-R.pdf|title=GlobalPlatform based Trusted Execution Environment and TrustZone Ready|website=Arm.com|access-date=2020-04-24|archive-date=2020-07-04|archive-url=https://web.archive.org/web/20200704081700/https://community.arm.com/cfs-file/__key/telligent-evolution-components-attachments/01-2142-00-00-00-00-51-36/GlobalPlatform-based-Trusted-Execution-Environment-and-TrustZone-R.pdf|url-status=live}}</ref>
Line 185 ⟶ 187:
** [[IBM Secure Execution]],<ref>{{cite web|url=https://developer.ibm.com/blogs/technical-overview-of-secure-execution-for-linux-on-ibm-z/|title=Technical overview of Secure Execution for Linux on IBM Z|website=ibm.com|access-date=2020-04-15|archive-date=2020-04-15|archive-url=https://web.archive.org/web/20200415005646/https://developer.ibm.com/blogs/technical-overview-of-secure-execution-for-linux-on-ibm-z/|url-status=live}}</ref> introduced in IBM z15 and LinuxONE III generation machines on April 14, 2020.
* [[Intel]]:
** [[
*** [[Trusted Execution Technology]] (TXT)
*** [[Software Guard Extensions]] (SGX)<ref>{{cite web |url=http://www.cs.helsinki.fi/group/secures/CCS-tutorial/tutorial-slides.pdf |title=The Trusted Execution Environments on Mobile Devices |website=Cs.helsinki.fi |access-date=2017-05-17 |archive-date=2016-04-18 |archive-url=https://web.archive.org/web/20160418104838/https://www.cs.helsinki.fi/group/secures/CCS-tutorial/tutorial-slides.pdf |url-status=live }}</ref>
*** "Silent Lake" (available on Atom processors)<ref>{{cite web|url=http://wenku.baidu.com/view/cb01a885c8d376eeaeaa31a9.html|title=WW46_2014_MCG_Tablet_Roadmap_图文_百度文库|website=Wenku.baidu.com|access-date=2017-01-04|archive-date=2017-02-27|archive-url=https://web.archive.org/web/20170227010510/http://wenku.baidu.com/view/cb01a885c8d376eeaeaa31a9.html|url-status=live}}</ref><ref>{{cite web|url=https://github.com/CyanogenMod/android_device_asus_mofd-common/blob/b52bb27be47485df8646340b43a97f2dda974385/sepolicy/file.te|title=CyanogenMod/android_device_asus_mofd-common|website=GitHub|access-date=2017-01-04|archive-date=2017-03-24|archive-url=https://web.archive.org/web/20170324095520/https://github.com/CyanogenMod/android_device_asus_mofd-common/blob/b52bb27be47485df8646340b43a97f2dda974385/sepolicy/file.te|url-status=live}}</ref><ref>{{cite web|url=https://github.com/heidiao/sfp_m2_bt/blob/master/source/device/intel/cherrytrail/cht_cr_rvp/init.rc|title=heidiao/sfp_m2_bt|website=GitHub|access-date=2017-01-04|archive-date=2017-03-24|archive-url=https://web.archive.org/web/20170324095926/https://github.com/heidiao/sfp_m2_bt/blob/master/source/device/intel/cherrytrail/cht_cr_rvp/init.rc|url-status=live}}</ref> * [[RISC-V]]:
**
▲** Penglai Scalable TEE for RISC-V <ref>{{cite web |url= https://penglai-enclave.systems |title= Penglai Enclave |website= penglai-enclave.systems/ |access-date= 2021-06-10 |archive-date= 2021-05-06 |archive-url= https://web.archive.org/web/20210506151417/https://penglai-enclave.systems/ |url-status= live }}</ref>
==See also==
| |||