Cet article est aussi disponible en français.

Wat als je systeembeheerders toegang zouden hebben tot je gevoelige data zonder dat je het weet? Vertrouwelijke IT (confidential computing) biedt een oplossing: data isoleren, zelfs voor degenen die de infrastructuur beheren. Maar hoe?

Vertrouwelijke IT omvat een geheel van technologieën waarmee gevoelige data zodanig worden beschermd dat ze niet hoeven te worden ontsleuteld om te worden verwerkt. Hoewel sommige technologieën, zoals homomorfe versleuteling, nog steeds erg complex zijn om te implementeren, zijn Trusted Execution Environments (TEE’s) inmiddels zo ver ontwikkeld dat ze kunnen worden beschouwd als belanggrijke technologie bij databescherming.

Het belangrijkste doel van TEE’s is om een buffer te vormen tegen de nieuwsgierigheid van de entiteiten die de infrastructuur beheren. Technische bescherming lost echter niet alles op. Extraterritoriale wetten [1-5] en het gebruik van eigen softwarelibrary’s die door sommige IT-infrastructuurproviders worden opgelegd, kunnen deze isolatie ondermijnen.

In deze en de volgende blogpost kijken we naar de mogelijkheid om TEE’s op onze eigen infrastructuur (on-premise) te gebruiken. Het doel is drieledig: gebruikmaken van de kracht van vertrouwelijke computing om data te beschermen en nieuwe toepassingen mogelijk te maken, terwijl we een zekere controle behouden over de software- en hardwarestack, en zo het vertrouwen van onze klanten versterken.

Scheiding van rollen

Laten we beginnen met een overzicht van de verschillende spelers die betrokken zijn bij de implementatie van een toepassing op een IT-infrastructuur. Hun rollen moeten strikt gescheiden zijn om de integriteit van het systeem te garanderen.

• De infrastructure operator beheert de hardware en infrastructuur (computing, storage, network) en onderhoudt de beveiligde runtime-omgevingen. Hij controleert de firmware-updates en de toewijzing van middelen, maar mag geen toegang hebben tot de data of de workloads die in de TEE’s worden uitgevoerd.
• De orchestration operator, die dezelfde kan zijn als de infrastructure operator, is verantwoordelijk voor het beheer van de serverclusters en de implementatie van de workloads. Hij configureert de benodigde middelen voor de toepassing en houdt toezicht op de bijbehorende diensten (logging, monitoring). Zijn rechten moeten ook strikt beperkt zijn om te voorkomen dat hij in de TEE’s komt, zonder dat dit ten koste gaat van de essentiële orkestratie.
• De workload provider (de toepassing) ontwerpt de specificaties van de toepassingen en kiest de juiste container images, waarbij hij de conformiteit en integriteit ervan garandeert. Hij moet aan de data owners (zie hieronder) laten zien dat de gebruikte code veilig is en de privacy respecteert, zonder direct toegang te geven tot gevoelige data.
• De container image provider bouwt, ondertekent en versleutelt de container images, zodat hun herkomst en veiligheid gegarandeerd zijn. Hij verstrekt de verificatie en decryptiesleutel. Zijn samenwerking met de toepassingsprovider is cruciaal om de softwareketen te garanderen en ervoor te zorgen dat de geïmplementeerde code precies dezelfde is als de geauditeerde code.
• Ten slotte bezit de data owner de data die door de toepassingen worden verwerkt en eist hij de vertrouwelijkheid en integriteit ervan. Hij vertrouwt op de code van de toepassing (de container) en de cryptografische bewijzen die door de microprocessor worden geleverd, waardoor infrastructure en orchestration operators buiten zijn vertrouwensbereik vallen. Hij kan extra controles opleggen om ervoor te zorgen dat zijn data niet zichtbaar zijn voor of gemanipuleerd worden door onbevoegde personen.

De relaties tussen deze spelers brengen specifieke uitdagingen met zich mee: de data owner moet bijvoorbeeld kunnen vertrouwen op de code van de containers (geleverd door de workload provider) om zijn data te verwerken, terwijl hij deze tegelijkertijd moet beschermen tegen andere spelers, zoals de infrastructure of orchestration operator. Met name de beheerders van deze operators mogen in geen geval toegang hebben tot de data die door de containers worden verwerkt.

Betrouwbare runtime-omgeving

Met TEE’s kan een technische barrière worden gecreëerd die het vertrouwen van de data owner in de toepassingscontainer versterkt. We hebben al uitvoerig uitgelegd hoe ze werken en wat hun voor- en nadelen zijn in een technisch rapport [6] en blogposts [7], [8]. Hier gaan we even de belangrijkste punten herhalen alvorens we de technologische keuzes voor een implementatie op onze onderzoeksinfrastructuur voorstellen.

Het goed functioneren van TEE’s hangt af van de hardware. Sommige moderne microprocessors maken het mogelijk om een deel van het RAM-geheugen dat is toegewezen aan een specifieke virtuele machine (VM) te reserveren en te versleutelen. Zo zal een beheerder van de hostmachine, zelfs met de hoogste privileges, alleen versleutelde data zien als hij dit geheugengebied probeert te inspecteren. Hoewel er aanvallen via side-channels bestaan (bijv. [9]), vereisen deze vanwege hun complexiteit doorgaans langdurige fysieke toegang en de toevoeging van kwaadaardige hardwarecomponenten, waardoor ze uiterst moeilijk uit te voeren zijn.

Zodat de data owner er zeker van kan zijn dat zijn toepassing in een veilige omgeving draait, gebruikt hij het certificeringsmechanisme. Dit proces genereert een cryptografische handtekening van de inhoud van het geheugen van de VM op het moment dat deze wordt opgestart. Deze handtekening wordt gecertificeerd door de fabrikant van de microprocessor.

Dit proces heeft zijn beperkingen, vooral als de infrastructure operator een buitenlandse onderneming is (bijvoorbeeld Amazon AWS, Google Cloud of Microsoft Azure) die zijn eigen libraries in de VM oplegt om bijvoorbeeld de juiste hardware-abstractielaag te bieden.

Dit heeft ons ertoe aangezet om dit soort hardware op onze eigen infrastructuur te testen, in afwachting van de mogelijkheid om dit op een dag op G-Cloud toe te passen. Het voordeel hiervan is dat een klant van SMALS een toepassingscontainer op een veilige manier kan gebruiken, zonder dat een beheerder van SMALS toegang heeft tot de inhoud van de container.

Maar het nut van TEE’s gaat verder dan alleen bescherming tegen beheerders. Het opent de deur naar andere toepassingen.

Use case

Een eerste voorbeeld is te vinden in de Europese infrastructuur voor digitale gezondheidsdiensten (eHDSI). Daar kunnen zorgverleners in het land waar de behandeling plaatsvindt de relevante gezondheidsdata van de patiënt opvragen in het land waar de patiënt is aangesloten. Technisch gezien wordt de aanvraag via de gateway van het nationale contactpunt voor gezondheidszorg (NCPeH) van het land waar de onverwachte gezondheidsgebeurtenis plaatsvindt, doorgestuurd naar het land waar de patiënt is aangesloten. De gevraagde info moet dan worden opgehaald uit de nationale infrastructuur van het land van aansluiting, vertaald naar het Engels en getranscodeerd (de gezondheidsdata worden omgezet van het nationale coderingssysteem naar het algemeen aanvaarde coderingssysteem, bijvoorbeeld van het FHIR– of KMEHR-formaat naar CDA), en vervolgens teruggestuurd en gepresenteerd worden aan de zorgverlener in het land van behandeling. Vanwege het gevoelige karakter van de data moeten deze van begin tot eind worden versleuteld, vanaf de gegevensbron op de infrastructuur van het land van aansluiting tot aan de zorgverlener in het land van behandeling. In de praktijk is dit nog niet mogelijk vanwege de grote verschillen tussen de Europese landen. Het zou echter op zijn minst mogelijk moeten zijn om te garanderen dat de data versleuteld en ontoegankelijk blijven voor alle gebruikers of beheerders tussen de bron van de data en de uitgang van de NCPeH-gateway. Een mogelijkheid is dan om TEE’s te gebruiken voor het vertalen en transcoderen van de data.

Een ander voorbeeld van het gebruik van TEE’s is de beveiligde samenwerking tussen entiteiten die hun ruwe data niet willen delen. In de onderwijs- en werkgelegenheidssector heeft een experiment van Bogdanov et al. in Estland [10] de kracht van vertrouwelijke computertechnieken aangetoond. De auteurs van deze studie wilden achterhalen of werken naast een hogere opleiding ertoe leidt dat je je diploma niet op tijd behaalt – een vraag die vooral belangrijk is voor de sector van de informatie- en communicatietechnologie (ICT) in Estland. Om deze probleemstelling te beantwoorden zonder de privacy van persoonlijke data in gevaar te brengen, hebben de onderzoekers de onderwijsregisters van het ministerie van Onderwijs en Onderzoek gecombineerd met de data van de belastingdienst, dankzij een speciale techniek van vertrouwelijke informatica. Maar een simpelere variant met een TEE zou net zo goed hebben gewerkt voor de analyse, terwijl de fiscale vertrouwelijkheid en databescherming gewaarborgd bleven.

CoCo

Om TEE’s te gebruiken in onze eigen onderzoeksinfrastructuur bestaan er verschillende softwareoplossingen. We hebben gekozen voor het project “Confidential Containers (CoCo)“, waarvan de broncode vrij toegankelijk is. Dit project zorgt voor een goede isolatie van de toepassingscontainers en ondersteunt het certificeringsmechanisme op een transparante manier, terwijl de flexibiliteit van de implementatie en de compatibiliteit met het Kubernetes-platform waarop het is gebaseerd, behouden blijven. Elke Kubernetes-capsule wordt geïsoleerd in een zeer lichte vertrouwelijke virtuele machine, zodat alleen geautoriseerde toepassingen toegang hebben tot gevoelige data.

CoCo’s bevatten naast de toepassing zelf enkele noodzakelijke softwarecomponenten. Deze maken het mogelijk om de uit te voeren containerimage te downloaden, de verificatie van de certificering te vergemakkelijken en bepaalde beveiligingsbeleidsregels toe te passen. Hun programmeerinterface is relatief klein, vooral vergeleken met een oplossing waarbij een hele Kubernetes-node in een vertrouwelijke virtuele machine wordt geplaatst. Bovendien is de image van de guest-VM statisch en generiek voor alle workloads en zelfs platforms, waardoor het eenvoudiger is om veiligheidsgaranties te bieden. Tegelijkertijd is het makkelijk om dingen te delen tussen containers in dezelfde Kubernetes-capsule. De naamruimte van het netwerk van de capsule blijft bijvoorbeeld binnen de vertrouwelijke VM, waardoor de containers daarin zonder extra kosten vertrouwelijk met elkaar kunnen communiceren.

CoCo is gebaseerd op Kata-containers, een ander open source-project, waarmee Kubernetes-capsules kunnen worden uitgevoerd binnen zeer lichte vertrouwelijke virtuele machines (zie Figuur 1). CoCo voegt echter twee cruciale componenten toe om vertrouwelijkheid en veiligheid te garanderen (zie Figuur 2).

• De eerste heeft te maken met het ophalen van containerimages: deze worden meestal gedownload door de Kubernetes-hoofdnode met behulp van een Container Runtime Interface (CRI) zoals “containerd”, waardoor de images via het bestandssysteem zichtbaar worden voor de hostmachine. CoCo ontcijfert de images en pakt ze uit in de vertrouwelijke VM, en daarom zijn die componenten nodig.
• Het tweede onderdeel is het certificaat, dat, zoals we al hebben gezien, essentieel is voor het opzetten van een betrouwbare uitvoeringsomgeving. Om bijvoorbeeld een image te ontsleutelen, dient de guest de geheime ontsleutelingssleutel te kunnen verkrijgen, maar deze wordt alleen verstrekt als de guest zijn authenticiteit kan aantonen. Dit is de rol van twee componenten die steunen op een zogenaamd “Trustee”-systeem, dat buiten de virtuele machine staat en uit twee diensten bestaat: een certificeringsdienst om de vertrouwde runtime te valideren en een key mediation-dienst om de geheime middelen te leveren die de virtuele machine en de toepassing nodig hebben.

CoCo levert dus de basis voor het bouwen van vertrouwelijke toepassingscontainers door het mogelijk te maken deze containers binnen vertrouwelijke virtuele machines uit te voeren, waarbij de geëncrypteerde en ondertekende images van de containers, de verzegelde geheimen en andere kenmerken worden beheerd. Elke container of groep containers van dezelfde toepassing kan worden toegewezen aan een vertrouwelijke virtuele machine, waarbij niet alleen de werklast wordt meegenomen, maar ook processen waarmee de toepassing bepaalde beveiligingsdiensten kan aanroepen.

Alles buiten de vertrouwelijke VM op de host wordt als onbetrouwbaar beschouwd, inclusief de kubelet-tool, de runtime-interface van de containers en de kernel van het besturingssysteem van de host. De uitwisseling van informatie tussen vertrouwde en niet-vertrouwde contexten wordt streng gecontroleerd, met name via dynamische en configureerbare beveiligingsbeleidsregels. Ten slotte wordt de Kubernetes-orkestratie zelf als niet-vertrouwd beschouwd, waardoor de garanties met betrekking tot de planning of de volgorde van uitvoering van de workloads beperkt zijn, met uitzondering van de implementatie ervan in een geauthenticeerde enclave.

Conclusie

Vertrouwelijke containers maken deel uit van een algemene beveiligingsaanpak, waarbij certificering, verificatie van images en best practices in de softwaretoeleveringsketen worden gecombineerd. Ze maken het mogelijk om use cases eenvoudiger te verwerken dan geavanceerde cryptografie (confidential collaboration, private set intersection, oblivious transfer, oblivious joints, geavanceerde pseudonimisering, enz.). Puristen kunnen natuurlijk aanvoeren dat een oplossing op basis van vertrouwelijke containers minder veilig is, maar in de praktijk zal deze waarschijnlijk voldoende in en ‘on-premise’-omgeving zijn, des te meer omdat deze de zaken aanzienlijk vereenvoudigt zodra deze is geïmplementeerd.

In de volgende blogpost gaan we dieper in op de installatie en het gebruik van vertrouwelijke CoCo’s.

Referenties

[1]        C. Bômont, “Strategic Brief no.70 – 2024 – Extension of the FISA Law European ‘digital sovereignty’ far from American concerns – IRSEM”, Institut de Recherche Stratégique de l’Ecole Militaire. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.irsem.fr/en/strategic-brief-no-70-2024

[2]        D. Michels, “Europeans, forget the US Cloud Act… worry about FISA instead (!)”. Geraadpleegd: 1 juli 2025. [Online]. Beschikbaar op: https://www.linkedin.com/pulse/europeans-forget-us-cloud-act-worry-fisa-instead-dave-michels-anjze

[3]        Paul Kunert, “Microsoft exec admits it ‘cannot guarantee’ data sovereignty”. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/

[4]        M. Rochefort, “Microsoft face au Sénat : l’aveu qui fait vaciller la souveraineté numérique française”, clubic.com. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.clubic.com/actualite-573438-microsoft-face-au-senat-l-aveu-qui-fait-vaciller-la-souverainete-numerique-francaise.html

[5]        D. Deridder, “Understanding Sovereignty: Who Rules your Cloud?”, Dirk Deridder. Geraadpleegd: 1 juli 2025. [Online]. Beschikbaar op: https://dirkderidder.wordpress.com/2025/03/13/understanding-sovereignty-who-rules-your-cloud/

[6]        F. A. P. Petitcolas, “Informatique confidentielle – État de l’art”, Smals Research, jul. 2023. [Online]. Beschikbaar op: https://staging.smalresearch.be/publications/document?docid=269

[7]        F. A. P. Petitcolas, “Introduction à l’informatique confidentielle”, Smals Research. Geraadpleegd: 9 januari 2026. [Online]. Beschikbaar op: https://staging.smalresearch.be/introduction-a-l-informatique-confidentielle/

[8]        F. A. P. Petitcolas, “Outils pour l’informatique confidentielle”, Smals Research. Geraadpleegd: 9 januari 2026. [Online]. Beschikbaar op: https://staging.smalresearch.be/outils-pour-linformatique-confidentielle/

[9]        J. De Meulemeester, D. Oswald, I. Verbauwhede, en J. V. Bulck, “Battering RAM: Low-cost interposer attacks on confidential computing via dynamic memory aliasing”, gepresenteerd bij 47th IEEE Symposium on Security and Privacy (S&P), mei 2026.

[10]      D. Bogdanov, L. Kamm, B. Kubo, R. Rebane, V. Sokk, en R. Talviste, “Students and taxes: a Privacy-preserving study using secure computation”, Proc. Priv. Enhancing Technol., vol. 2016, nr. 3, pp. 117-135, jul. 2016, doi: 10.1515/popets-2016-0019.