Leuk om eens een artikel over TEEs te zien! Wat ik alleen wel een beetje jammer vind dat het er op lijkt dat de auteur het artikel niet na heeft laten lezen door iemand bekend met de materie, want staan helaas best wel wat fouten / inaccuraatheden in...
Misschien nog wel mijn grootste probleem is op het opeen gooien van alle termen en technologieën. Hoewel er inderdaad veel overlap en onduidelijkheid is, hangt er vaak toch wel een specifiek doel of implementatie aan een bepaalde term. De definitie aan het begin is op zich nog wel goed, maar later in het artikel gaan dingen toch wel een beetje door elkaar.
Iets meer inhoudelijk:
"Sommige fabrikanten hebben bijvoorbeeld een puur softwarematige oplossing en andere kiezen juist voor een hardwarematige." Je kan geen pure software TEE hebben. Je moet ondersteuning hiervoor in je hardware hebben. Denk aan speciale execution modes (S-EL3, NS-bit in TrustZone), maar ook in je chip bus moet je ondersteuning hebben voor het kunnen doorgeven van de security state (bv AxPROT in de AXI bus) en protection controllers (TZASC, TZPC) om te regelen wie welke peripheral mag accessen, anders is het omzeilen van de TEE triviaal.
"In slechts een paar gevallen hebben de fabrikanten een eigen tee gebouwd." Valt mee, maar er zijn er veel niet publiek bekend.
"Ook als bedrijven een hardware-implementatie hebben, zoals Apples Secure Enclave, gaat het vaak gewoon om een aangepaste versie van TrustZone." Zover ik weet is de SE gewoon een kleine Cortex-A co-processor en heeft het niks met TrustZone te maken. Als ze er iets mee doen is dat zeer recent, maar zeer zeker niet de eerste 5 ofzo jaar.
"ARM Cortex-processors draaien hun eigen besturingssysteem op een aparte core.": Nope, je core (Cortex-A) switched tussen een secure en non-secure staat op basis van de NS-bit in je SCR.
"TrustZone werkt op zowel Cortex-A- als Cortex-M-cores, al zit er verschil in functionaliteit tussen die twee. Op de ARMv8-M gaat de dataoverdracht tussen de beveiligde en niet-beveiligde gedeelten via hardware." Bij Cortex-M hangt het af van waar je in je address space execute of je secure of non-secure bent. Via een Secure Gateway instructie kan je switchen. Op Cortex-A heb je een secure monitor die in Secure Exception Level 3 draait die de Non-Secure bit kan aanpassen in je Secure Configuration Register en daarmee kan switchen tussen de secure en non-secure state van de lagere ELs.
" Sinds Android 9 zit er een api in het besturingssysteem, genaamd StrongBox KeyMaster, waarmee onder andere een random number generator in de Titan-chip kan worden aangeroepen, en sleutels met rsa 2048- en aes 256-encryptie kunnen worden aangemaakt en opgeslagen." StrongBox is de naam voor het gebruik van een Secure Element als hardware-backed key storage ipv een TEE. Titan-M is een external SE, maar andere fabrikanten hebben hun eigen SEs, die ook on-die (als iSE) kan zijn. Dit draait naast je gewone TEE, die bv nog steeds in gebruik is voor DRM.
"Google heeft daarnaast een eigen microkernel geschreven voor tee's op Android. Trusty werkt ook op basis van ARM's TrustZone en is een puur softwarematige virtualisatie die Android-fabrikanten kunnen gebruiken als de soc in hun telefoon geen tee-chip heeft." Trusty is gebouwd op Little Kernel. Daarnaast zou ik virtualisatie in deze context niet willen gebruiken. Armv8.4 (of 8.5) brengt secure virtualizatie om meerdere TEE OSen naast elkaar te kunnen draaien.
"Samsung maakte altijd gebruik van Arm's TrustZone, maar gebruikt sinds de Galaxy S20 een fysieke chip als tee." De Secure Element draait naast TEEGRIS, hun TrustZone TEE die ze sinds de S10 op de Exynos chips gebruiken en ook nog steeds in gebruik is op de S20.
"Voor implementaties op basis van TrustZone heeft Arm bijvoorbeeld eigen software gemaakt, maar fabrikanten kunnen er ook zelf iets van maken." Voor Cortex-A maakt Arm eigenlijk alleen een reference implementatie van de secure monitor als onderdeel van het Arm Trusted Firmware project. Voor Cortex-M gaan ze wat verder inderdaad.
"Die kunnen ervoor kiezen er een eigen microkernel voor te schrijven of gebruik te maken van bestaande microkernels." Lang niet alle TEEs zijn microkernels. Je kan het zo klein houden als je zelf wilt en zo extreem maken als je zelf wilt. Bij Cortex-A TrustZone kan je in de Secure World alles doen (en zelfs ietsje meer) wat je ook in de Normal World kan doen.
"Er zijn daarnaast verschillende initiatieven die proberen om een open source, gratis microkernel op basis van Linux te bouwen die fabrikanten voor tee's kunnen gebruiken." OP-TEE heeft absoluut niks met Linux te maken maar is volledig vanaf scratch ontwikkeld. Oorspronkelijk door ST uit mijn hoofd, maar is nu overgedragen aan Linaro, die weer bezig is om het over te dragen aan een nieuwe foundation waar Arm ook ATF onder gaat brengen.
" Aan de andere kant zit er wel een risico aan microkernellekken dat bij gewone software lang niet altijd aanwezig is. Ze zijn bijvoorbeeld lastiger op te lossen doordat microkernel-updates een stuk moeilijker door te voeren zijn dan reguliere software-updates." Valt wel mee. Het is niet moeilijker dan bijvoorbeeld de Linux kernel upgraden. Er zijn dan ook regelmatig updates voor de TEEs in telefoons, die komen gewoon mee met je maandelijkse updates.
Secure Boot heeft trouwens heel weinig met TEEs te maken en kan prima zonder TEE. Je kan wel geen TEE hebben zonder dat je ook Secure Boot hebt (als je tenminste enige mate van veiligheid wilt).
Ik vrees dat er nog wel meer zijn, maar ik kan niet door alles heen gaan
Daarnaast had het allemaal echt wel wat meer uit elkaar getrokken en naast elkaar gezet mogen worden. TrustZone-A werkt heel anders dan SGX (wat dan weer best wel lijkt op TrustZone-M), die weer heel anders werkt dan een Secure Enclave (maar dat weer vergelijkbaar is met dat van AMD), wat weer heel anders werkt dan een Secure Element. Allemaal met hun eigen voor- en nadelen en eigenschappen.
Een heel belangrijk doel van dit soort technologie dat trouwens nog ontbreekt (eerst voor de TEE samen met het gebruik met biometric data, maar wat nu heel erg de push naar Secure Elements veroorzaakt) is mobile banking. TEEs zijn eigenlijk gewoon niet secure genoeg
En doordat je zoveel resources deelt in je chip architectuur (itt een Secure Element, zelfs als die on-die is) is het ook heel moeilijk om ze echt veilig te maken, er zijn simpelweg te veel tricks die je kan doen, ook via de hardware. Het is trouwens mijn werk om ze te breken
Er zijn trouwens vele male meer aanvallen geweest dan er nu genoemd worden. Veel zullen er nooit bekend worden ivm geheimhouding, andere kan je terug vinden in soms wat obsure papers. Een hele leuke vind ik zelf CLKSCREW:
https://www.usenix.org/sy...security17/sec17-tang.pdf maar ook bv RowHammer kan/kon je tegen TEEs gebruiken. Of wat ik bijvoorbeeld zelf vorige week nog met een collega gepresenteerd (presentatie komt over een paar maanden online) heb is hoe je een moderne Android phone kan decrypten door de TEE te breken via software implementatie bugs (en dan niet de typische buffer overflow) zonder de pincode te weten.
Hopelijk ben ik niet te kritisch, zo bedoel ik het niet. Ik zou juist graag meer van dit soort artikelen zien!
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
:strip_icc():strip_exif()/u/448966/crop62a741840cd69_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/53288/icon.jpg?f=community){kind=icon}