Cet article est aussi disponible en français.

Over het algemeen wordt aangenomen dat data zich in drie toestanden kunnen bevinden. Data die zijn opgeslagen, bijvoorbeeld op een harde schijf of in een database, worden ‘in rust’ genoemd, data die van de ene computer naar de andere worden verzonden, bijvoorbeeld via een netwerk, zijn ‘in beweging’ en data die door de microprocessor worden verwerkt, zijn ‘in gebruik’.

Tegenwoordig worden cryptografische primitieven op grote schaal ingezet om data in de eerste twee toestanden te beschermen en zo de integriteit en vertrouwelijkheid te waarborgen. Door de strengere regelgeving op het gebied van gegevensbescherming en privacy en de toename van langdurige cyberdreigingen is echter de noodzaak ontstaan om data die in gebruik zijn te beschermen.

Helaas blijft deze bescherming van data in gebruik moeilijk, vooral in de context van gedeelde IT-infrastructuren: het gaat namelijk om het uitvoeren van software met bepaalde veiligheidsgaranties op een externe computer die eigendom kan zijn van en beheerd kan worden door een onbetrouwbare of zelfs kwaadwillende partij.

Talrijke aanvallen

De mogelijke aanvallen zijn talrijk.

Op softwareniveau gaat het om alle aanvallen waarmee de integriteit van het systeem kan worden aangetast, of het nu gaat om het besturingssysteem, de hypervisor of de firmware. Deze aanvallen worden mogelijk gemaakt door verschillende soorten ransomware of hacktools, door gecompromitteerde apparaatstuurprogramma’s, door het misbruik van een zero-day-kwetsbaarheid, door het injecteren van logische fouten, of zelfs door kwaadwillende werknemers of slechte productiepraktijken, enzovoort. [1]-[8] Daarnaast is er ook toegang tot data via hulpkanalen (“side-channel attacks”) of als gevolg van configuratiefouten of fouten in de systeeminstellingen. Ten slotte zijn er, hoewel zeldzamer, cryptografische aanvallen mogelijk, na een grondige analyse van een algoritme of door misbruik te maken van een wiskundige doorbraak.

Op fysiek niveau is het denkbaar dat een systeembeheerder of een externe dienstverlener zonder toestemming toegang krijgt tot de hardware, waardoor hij rechtstreeks verbinding kan maken met de printplaat en informatie kan kopiëren via direct RAM-memory access (DIMM DMA), de double data rate (DDR) kan bespioneren, de computerbus en de cache kan controleren, enzovoort.

Voornaamste technologieën

Confidential computing heeft tot doel een technologische oplossing voor deze problemen te bieden door middel van drie belangrijke methoden:

• Trusted execution environments (TEE’s) zijn gebaseerd op een combinatie van secure hardware-componenten, authenticatiemechanismen en software die is ontworpen om deze hardwarefuncties te benutten¹.
• Homomorphic encryption (HE) heeft betrekking op directe berekeningen op versleutelde data [11] en kan voor bepaalde soorten problemen nuttig zijn, maar brengt kosten met zich mee door de extra rekenkracht die nodig is voor de specifieke encryptie [12].
• Secure multiparty computation [13] (SMC) is een klasse van cryptografische methoden waarmee wederzijds wantrouwende partijen gezamenlijk functies op hun data kunnen berekenen zonder deze aan andere partijen te onthullen. Dit type berekeningis al beschreven in deze blogpost.

Uiteraard is het mogelijk om deze technologieën te combineren, zoals bijvoorbeeld TEE’s met homomorphic encryption (bijv. [14]).

Hieronder concentreren we ons op het eerste type confidential computing: trusted execution environments.

Vermindering van de blootstelling aan aanvallen

Over het algemeen bestaat de volledige stack van een informatica-platform uit verschillende technologieën van talrijke verschillende leveranciers, wat leidt tot een gebrek aan coherente implementatie van de veiligheidscontroles.

De fysieke hardwarelaag waarop het hele systeem is gebouwd, blijft echter de eerste beschermingslaag. Een manier om de algehele veiligheid van een systeem te verbeteren – onder meer door toegang tot data te verhinderen – is dan ook het verhogen van de veiligheid van het fysieke gedeelte.

Dit is het uitgangspunt van TEE’s, die tot doel hebben de uitvoering van toepassingscode te beschermen tegen bevoorrechte code-aanvallen en bepaalde fysieke aanvallen door de vertrouwensbasis en het aanvalsoppervlak te verkleinen (Figuur 1:).

In sommige gevallen maakt de kleine omvang van de TEE de toepassing van formele methoden (gebaseerd op wiskundige constructies) mogelijk en zorgt voor de controle van de conformiteit van de implementatie met de specificaties. Dit versterkt het vertrouwen in de TEE.

TEE’s

TEE’s zijn beveiligingssystemen die parallel aan reguliere uitvoeringsomgevingen (waaronder besturingssystemen zoals Linux of Windows) worden uitgevoerd. Ze zorgen voor een beveiligde zone om activa te beschermen (bijv. gevoelige geheimen, authenticatiesleutels) en dienen ook om ervoor te zorgen dat de bewerkingen die daarbinnen worden uitgevoerd en de bijbehorende data niet van buitenaf kunnen worden geraadpleegd, zelfs niet door bevoorrechte software (bijv. hypervisor, besturingssysteem) of een debugger. In combinatie met een certificeringsmechanisme (zie hieronder) zorgen ze ervoor dat de code die ze uitvoeren niet kan worden gewijzigd of vervangen zonder toestemming van de user.

Een TEE kan worden gebruikt om geheugenisolatie te bieden, waardoor wordt voorkomen dat toepassingen die dezelfde onderliggende hardware delen, het geheugen kunnen lezen dat aan anderen is toegewezen. Sommige TEE’s maken het mogelijk om volledige toepassingen in hun eigen enclaves te isoleren in plaats van alleen specifieke bewerkingen of geheugen te beschermen.

De toepassing van de bovengenoemde eigenschappen is gebaseerd op specifieke fysieke hardware, waarbij alle of een deel van de middelen die nodig zijn voor de goede werking van de TEE in dezelfde houder worden geïntegreerd, of door gebruik te maken van middelen die worden gedeeld met andere componenten op de printplaat van het apparaat
(bijvoorbeeld het RAM-geheugen). In het laatste geval is isolatie door middel van versleuteling noodzakelijk.

Niet alle TEE’s zijn identiek en verschillende fabrikanten kunnen verschillende TEE-implementaties aanbieden met verschillende beveiligingseigenschappen, verschillende functionaliteiten en verschillende controlemechanismen om op beveiligde toepassingen te werken [2]. Sommige TEE’s zijn eerder bedoeld voor telefoons (bijv. de TrustZone-technologie van ARM), terwijl andere zijn bedoeld voor bureau-pc’s of computers die deel uitmaken van een gedeelde IT-infrastructuur (bijv. de SGX-technologie van Intel of de SEV-technologie van AMD).

Meerdere leveranciers van openbare IT-infrastructuur stellen deze technologieën beschikbaar aan zij die niet over deze hardware beschikken. Microsoft biedt bijvoorbeeld het product Azure Confidential Computing aan, dat SGX en SEV ondersteunt. Amazon implementeert zijn eigen TEE-technologie, Nitro genaamd, op zijn AWS-infrastructuur.

Veiligheidsvereisten

TEE’s zijn ontworpen om een breed scala aan softwarebedreigingen van het standaardbesturingssysteem te weerstaan, waaronder bedreigingen op kernelniveau (bijv. [16]) afkomstig van een rooted toestel, evenals bepaalde fysieke aanvallen. TEE’s worden onderworpen aan een grondige veiligheidsanalyse in het kader van de ‘Common Criteria’ [17], [18], maar over het algemeen ontbreekt het hen nog aan verdedigingsmechanismen tegen complexe hardware-aanvallen. Aanvallen die “doorgaans langdurige en/of invasieve toegang tot de hardware vereisen, waaronder chip-scrapingtechnieken en elektronenmicroscoopprobes”, vallen bijvoorbeeld expliciet buiten de toepassing van de vereisten van het Confidential Computing Consortium [19].

De beveiligingsvereisten van een TEE kunnen als volgt worden samengevat (zie [9] voor meer details):

• Het belangrijkste doel van een TEE is het beschermen van zijn activa tegen aanvallen vanuit de rest van de uitvoeringsomgeving. Dit wordt bereikt door middel van hardwaremechanismen die deze andere omgevingen niet kunnen controleren.
• De TEE biedt bescherming tegen bepaalde fysieke aanvallen. Invasieve aanvallen die de fysieke structuur van de geïntegreerde schakeling fysiek beschadigen, worden niet in aanmerking genomen.
• De uitvoeringsomgeving van het vertrouwde besturingssysteem wordt gestart vanuit een root of trust (RoT) binnen de TEE via een beveiligd opstartproces.
• De TEE biedt veilige opslag van data en cryptografische sleutels. Deze opslag is gekoppeld aan deze specifieke TEE op een specifiek apparaat.
• Software buiten de TEE kunnen de functionaliteiten die door de interne interfaces van de TEE worden blootgesteld niet rechtstreeks aanroepen en moeten via specifieke communicatieprotocollen werken, waardoor het vertrouwde besturingssysteem de aanvaardbaarheid van de gevraagde niet-TEE-bewerking kan controleren.

Integriteitscontrole

Een belangrijk concept van TEE’s is de mogelijkheid voor de user om de integriteit van het onderliggende platform te controleren. Dit wordt doorgaans gerealiseerd door middel van twee componenten: het hashen van de verschillende softwaremodules en de verificatie van de firmware. In het kader van gedeelde IT-infrastructuren is het noodzakelijk om deze controle op afstand te kunnen uitvoeren.

Hash en handtekening van modules

Cryptografische hashes (in de context van TEE’s ook vaak ‘metingen’ genoemd) van de software, de firmware en de bijbehorende configuratiebestanden vormen de basis voor het creëren van een vertrouwensketen. Elk van deze vertrouwensketens begint met een vertrouwde rootmodule die zo klein mogelijk moet zijn. Deze kan de vorm aannemen van een impliciet betrouwbaar bootblock (bijv. opgeslagen in alleen-lezen geheugen) van het Basic Input/Output System (BIOS), dat eerst zijn eigen integriteit meet en vervolgens de meting uitbreidt naar het gehele BIOS. Vervolgens wordt elke extra firmware of software die moet worden uitgevoerd, eerst gemeten voordat deze wordt uitgevoerd, en dit gaat door tot het besturingssysteem volgens een klassiek opstartproces [20].

Dit mechanisme van de vertrouwensketen, samengevat in de Figuur 2, biedt een betrouwbaar beeld van de huidige toestand van het systeem. Elke library, module of toepassing, al dan niet onderdeel van het besturingssysteem, heeft een integriteitsmeting opgeslagen in een beveiligde hardwareopslag. In principe zijn deze metingen ondertekend om replay-aanvallen of man-in-the-middle-aanvallen (bijv [21] te voorkomen.

Hardwarebeveiligingen zorgen ervoor dat zodra een enclave is gestart, er geen wijzigingen in de code of statische data kunnen worden aangebracht van buiten de enclave. Nadat ze zijn gestart, kunnen processen buiten de enclave een cryptografisch certificaat ontvangen dat een handtekening van de code binnen de enclave bevat, zodat het externe proces verzekerd is van de juistheid van alle code die in de enclave kan worden uitgevoerd.

Controle van de firmware en de configuratie ervan

Lokale of externe certificering houdt, zoals hierboven vermeld, in dat er een handtekening van de maatregelen wordt gegenereerd, en met name die van de root of trust voor de meting³ (CRTM) met specifieke certificeringssleutels. Het mechanisme maakt het mogelijk om op afstand te controleren of de gewenste firmware, het besturingssysteem en de toepassing daadwerkelijk worden uitgevoerd. Het maakt ook de toepassing van specifieke beveiligingsbeleidsregels mogelijk.

Opgemerkt moet worden dat in een complexe moderne architectuur de fabrikant van de CRTM mogelijk niet lang de vertrouwde autoriteit blijft in het bootproces en dat de keten van opgeslagen hashwaarden moet worden gecontroleerd om de autoriteit van de huidige systeemstatus te bepalen. Bovendien kunnen er in een typisch datacenter duizenden machines met hun eigen CRTM staan, waardoor het bijhouden ervan een complexe taak is, zodat er vaak speciale diensten voor verificatie op afstand ter beschikking worden gesteld aan de user van een gedeelde IT-infrastructuur.

Tot slot moet worden opgemerkt dat een vertrouwensbasis met fysieke hardwarebeveiligingen moeilijker te wijzigen is dan een basis die uitsluitend in de firmware is ingebouwd. Maar onveranderlijke root of trust-hardware kan niet worden bijgewerkt.

Certificering op afstand

Certificering is een fundamenteel element om de betrouwbaarheid van een TEE te verifiëren en vervolgens te beslissen of deze al dan niet kan worden vertrouwd. Hiermee kan een softwareomgeving aantonen dat een specifiek programma door specifieke hardware wordt uitgevoerd. Lokale certificering kan worden gebruikt tussen twee softwareomgevingen die dezelfde hardware delen, maar wat voor de meeste users van systemen met TEE van belang is, is certificering op afstand, waarbij de twee softwareomgevingen op verschillende hardware draaien.

Over het algemeen is deze certificering gebaseerd op een trusted platform module (TPM), maar er bestaan ook andere methoden, zoals het gebruik van physical unclonable functions (PUF) of geheimen die in de geïntegreerde schakeling zijn ingebed.

De meeste TEE’s kunnen verifieerbare cryptografische bewijzen genereren, die naar een gebruiker (bijvoorbeeld het apparaat van de user of de serviceprovider) kunnen worden verzonden, die vervolgens de handtekening van het bewijs kan valideren. Als de handtekening geldig is, concludeert de vertrouwende partij dat de verwachte code wordt uitgevoerd in een authentieke TEE. Het bewijs is gebaseerd op de meting van de TEE en kan ook een openbare sleutel van de TEE bevatten.

Figuur 3 toont een algemeen certificeringsproces. De gebruiker van de TEE moet de verwachte meting kennen, niet alleen van de toepassing die hij wil implementeren, maar ook van de firmware van de TEE. De verificatie kan worden uitgevoerd met behulp van een challenge-response-mechanisme. Op deze manier overtuigt de certificering de user ervan dat de certificering daadwerkelijk is gegenereerd door specifieke software binnen specifieke hardware, zonder externe interferentie. Meer data en variaties worden gegeven in [23].

Het certificeringssysteem moet het mogelijk maken om de TEE in te trekken indien blijkt dat de veiligheid ervan is aangetast.

Conclusie

De combinatie van beveiligde hardwarecomponenten en technieken voor verificatie op afstand vormt de basis van vertrouwde uitvoeringsomgevingen die tot doel hebben gevoelige of geheime data en de uitgevoerde code te beschermen tegen steeds frequentere aanvallen op data die worden verwerkt.

Deze omgevingen zijn a priori veelbelovend in het kader van gedeelde IT-infrastructuren. Ten eerste maken ze het mogelijk om het beveiligingsniveau van een privé-infrastructuur of gemeenschappelijke infrastructuur te verhogen door toepassingen beter van elkaar te isoleren, waardoor bijvoorbeeld wordt voorkomen dat een gecompromitteerde toepassing toegang krijgt tot de data van een andere. Ten tweede kunnen ze het vertrouwensniveau in een openbare infrastructuur voor de verwerking van bepaalde data verhogen, op voorwaarde dat de user de controle behoudt over het beheer van de versleutelings- en ontsleutelingssleutels die binnen de vertrouwde omgeving worden gebruikt.

Voor de enduser wordt de risicobeoordeling met betrekking tot het gebruik van het systeem vereenvoudigd, in die zin dat het vertrouwen wordt gesteld in een specifieke hardwarecomponent en op afstand verifieerbare firmware, die beide een verwacht gedrag vertonen, in plaats van in de computer als geheel. Er worden echter ook andere risico’s geïntroduceerd, zoals bijvoorbeeld de mogelijkheid van een lock-in bij een bepaalde TEE-technologie.

In een volgend artikel zullen we nader ingaan op de werking van bepaalde commerciële implementaties.

Referenties

[1]        A. Greenberg, “A Peek Into the Toolkit of the Dangerous Triton Hackers”, Wired, 10 april 2019. Geraadpleegd: 4 januari 2023. [Online]. Beschikbaar op: https://www.wired.com/story/triton-hacker-toolkit-fireeye/

[2]        K. Zetter, “Inside the Cunning, Unprecedented Hack of Ukraine’s Power Grid”, Wired, 3 maart 2016. Geraadpleegd: 4 januari 2023. [Online]. Beschikbaar op: https://www.wired.com/2016/03/inside-cunning-unprecedented-hack-ukraines-power-grid/

[3]        R. Lakshmanan, “New Malware Families Found Targeting VMware ESXi Hypervisors”, The Hacker News, 30 september 2022. Geraadpleegd: 9 januari 2023. [Online]. Beschikbaar op: https://thehackernews.com/2022/09/new-malware-families-found-targeting.html

[4]        R. Naraine, “Stuxnet attackers used 4 Windows zero-day exploits”, ZDNET, 14 september 2010. Geraadpleegd: 9 januari 2023. [Online]. Beschikbaar op: https://www.zdnet.com/article/stuxnet-attackers-used-4-windows-zero-day-exploits/

[5]        C. Zhao, “SolarWinds, Probably Hacked by Russia, Serves White House, Pentagon, NASA”, Newsweek, 14 december 2020. Geraadpleegd: 9 januari 2023. [Online]. Beschikbaar op: https://www.newsweek.com/solar-winds-probably-hacked-russia-serves-white-house-pentagon-nasa-1554447

[6]        B. Barrett, “Russia’s Elite Hackers Have a Clever New Trick That’s Very Hard to Fix”, Wired, 27 september 2018. Geraadpleegd: 4 januari 2023. [Online]. Beschikbaar op: https://www.wired.com/story/fancy-bear-hackers-uefi-rootkit/

[7]        T. Bletsch, X. Jiang, V. W. Freeh, en Z. Liang, “Jump-oriented programming: a new class of code-reuse attack”, in Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security, Hong Kong China: ACM, mrt. 2011, pp. 30-40. doi: 10.1145/1966913.1966919.

[8]        T. Claburn, “MSI motherboards found to have insecure Secure Boot”, The Register, 17 januari 2023. Geraadpleegd: 18 januari 2023. [Online]. Beschikbaar op: https://www.theregister.com/2023/01/17/msi_motherboards_secure_boot/

[9]        “TEE System Architecture v1.3”. GlobalPlatform, mei 2022. [Online]. Beschikbaar op: https://globalplatform.org/specs-library/tee-system-architecture/

[10]      M. Sabt, M. Achemlal, en A. Bouabdallah, “Trusted Execution Environment: What It is, and What It is Not”, in 2015 IEEE Trustcom/BigDataSE/ISPA, Helsinki, Finland: IEEE, aug. 2015, pp. 57-64. doi: 10.1109/Trustcom.2015.357.

[11]      C. Gentry, “Fully homomorphic encryption using ideal lattices”, in Proceedings of the 41st annual ACM symposium on Theory of computing, Bethesda MD USA: ACM, mei 2009, pp. 169-178. doi: 10.1145/1536414.1536440.

[12]      M. Naehrig, K. Lauter, en V. Vaikuntanathan, “Can homomorphic encryption be practical?”, in Proceedings of the 3rd ACM workshop on Cloud computing security workshop – CCSW ’11, Chicago, Illinois, USA: ACM Press, 2011, p. 113. doi: 10.1145/2046660.2046682.

[13]      A. C. Yao, « Protocols for Secure Computations », présenté à 23rd Annual Symposium on Foundations of Computer Science, Chicago, Illinois, USA, nov. 1982. doi: 10.1109/SFCS.1982.38.

[14]      N. Drucker en S. Gueron, “Combining Homomorphic Encryption with Trusted Execution Environment: A Demonstration with Paillier Encryption and SGX”, in Proceedings of the 2017 International Workshop on Managing Insider Security Threats, Dallas Texas USA: ACM, okt. 2017, pp. 85-88. doi: 10.1145/3139923.3139933.

[15]      M. Pei, H. Tschofenig, D. Thaler, en D. Wheeler, “Trusted Execution Environment Provisioning (TEEP) Architecture”, Internet Engineering Task Force, Internet Draft draft-ietf-teep-architecture-19, okt. 2022. Geraadpleegd: 30 januari 2023. [Online]. Beschikbaar op: https://datatracker.ietf.org/doc/draft-ietf-teep-architecture-19

[16]      S. Checkoway en H. Shacham, “Iago Attacks: Why the System Call API is a Bad Untrusted RPC Interface”.

[17]      “Common Criteria for Information Technology Security Evaluation”. november 2022. [Online]. Beschikbaar op: https://www.commoncriteriaportal.org/cc/

[18]      “TEE Protection Profile – Version 1.3”. GlobalPlatform, 4 juni 2020.

[19]      “A Technical Analysis of Confidential Computing”. Confidential Computing Consortium, oktober 2021. [Online]. Beschikbaar op: https://confidentialcomputing.io/wp-content/uploads/sites/85/2022/11/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.2_updated_2022-11-02.pdf

[20]      D. A. Cooper, W. T. Polk, A. R. Regenscheid, en M. P. Souppaya, “BIOS protection guidelines”, National Institute of Standards and Technology, Gaithersburg, MD, NIST SP 800-147, 2011. doi: 10.6028/NIST.SP.800-147.

[21]      D. Challener en K. Goldman, “Trusted Platform Module (TPM)”, Trusted Computing Group (TCG). [Online]. Beschikbaar op: https://trustedcomputinggroup.org/work-groups/trusted-platform-module/

[22]      C. Shepherd e.a., “Secure and Trusted Execution: Past, Present, and Future – A Critical Review in the Context of the Internet of Things and Cyber-Physical Systems”, in 2016 IEEE Trustcom/BigDataSE/ISPA, Tianjin, China: IEEE, aug. 2016, pp. 168-177. doi: 10.1109/TrustCom.2016.0060.

[23]      H. Birkholz, D. Thaler, M. Richardson, N. Smith, en W. Pan, “Remote ATtestation procedureS (RATS) Architecture”, Internet Engineering Task Force, Request for Comments RFC 9334, jan. 2023. doi: 10.17487/RFC9334.

---

¹ Er zijn verschillende definities gegeven van trusted execution environments (TEE’s) of secure execution environments (SEE’s), die soms onderling tegenstrijdig zijn. In dit artikel baseren wij ons voornamelijk op de specificaties van het Confidential Computing Consortium en GlobalPlatform [9]. Verschillende definities worden vergeleken en een formele beschrijving van deze omgevingen wordt voorgesteld in [10].

² Er zijn voorstellen om het werk van programmeurs van beveiligde toepassingen te vereenvoudigen, bijvoorbeeld met een interoperabel protocol voor het beheer van dergelijke toepassingen die op verschillende TEE’s draaien [15].

³ De “Core Root of Trust for Measurement” is de allereerste BIOS-code die bij het opstarten in de hoofdmicroprocessor wordt uitgevoerd. Deze wordt vaak opgeslagen in een betrouwbare platformmodule.

---

Dit is een ingezonden bijdrage van Fabien A. P. Petitcolas, IT-beveiligingsspecialist bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.