Content deleted Content added
Largoplazo (talk | contribs) →Hardware support: Filling in the ref |
VulcanSphere (talk | contribs) Rescuing 8 sources and tagging 0 as dead.) #IABot (v2.0.9.5 |
||
Line 22:
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 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 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 | access-date=2022-06-02 | archive-date=2022-06-25 | archive-url=https://web.archive.org/web/20220625012352/https://optee.readthedocs.io/en/latest/building/devices/qemu.html | url-status=live }}</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 |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/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 122:
|
|
| <ref>{{cite web |title=ProvenCore |url=https://provenrun.com/provencore/ |publisher=ProvenRun |access-date=2024-06-23 |archive-date=2024-02-26 |archive-url=
|-
| [[Qualcomm]]
Line 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 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 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 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|access-date=|website=developer.amd.com|archive-date=October 20, 2020|archive-url=https://web.archive.org/web/20201020150243/http://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf|url-status=live}}</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>
Line 192:
*** "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]]:
** Keystone Customizable TEE Framework<ref>{{cite web |url= https://keystone-enclave.org/2019/07/22/Keystone-Paper.html |title= Keystone Paper and Customizable TEEs |website= keystone-enclave.org |date= 22 July 2019 |access-date= 2021-06-10 |archive-date= 2020-07-14 |archive-url= https://web.archive.org/web/20200714212312/https://keystone-enclave.org/2019/07/22/Keystone-Paper.html |url-status= live }}</ref><ref>{{cite web|url=https://www.shwetashinde.org/publications/keystone_eurosys20.pdf|title=Keystone: An Open Framework for Architecting Trusted Execution Environments|date=April 2020|access-date=16 June 2025|archive-date=31 January 2025|archive-url=https://web.archive.org/web/20250131021253/https://www.shwetashinde.org/publications/keystone_eurosys20.pdf|url-status=live}}</ref>
==See also==
| |||