Trusted execution environment: Difference between revisions

Revision as of 21:15, 23 July 2024

Revision as of 05:13, 31 July 2024

Line 25:

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 their 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, [[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 its [[antifeature]]s, like [[Advertising|ads]], tracking and use case restriction for [[market segmentation]].

Line 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|archive-url=|archive-date=|access-date=|website=developer.amd.com}}</ref> and the Secure Nested Paging extension<ref>{{Cite web|last=|first=|date=January 2020|title=AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More|url=https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf|url-status=live|archive-url=https://web.archive.org/web/20201105002318/https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf|archive-date=2020-11-05|access-date=|website=}}</ref>

* [[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>