Gegevens in de cloud beveiligen met Confidential Computing

Dat is vooral problematisch bij cloudomgevingen omdat er veel lagen zijn tussen de applicatie en de hardware: het host-besturingssysteem, de hypervisor, beheersoftware en geprivilegieerde gebruikers. Zodra één van die lagen gecompromitteerd wordt, lopen de gevoelige gegevens gevaar. Confidential computing minimaliseert dat aanvalsoppervlak.

De technische basis van confidential computing is een Trusted Execution Environment (TEE). Dat is een beschermd uitvoeringsgebied dat door de hardware wordt afgeschermd van de rest van het platform. Binnen dat gebied draait een workload met extra veiligheidsgaranties.

Het doel is niet om alle risico’s uit te sluiten, maar om de vertrouwensgrens te verscherpen: weg van het besturingssysteem, de hypervisor en de infrastructuurbeheerder en in de richting van de onderliggende hardware.

De verwijzing naar de hardware is daarbij cruciaal. Als de beschermende functie alleen in software geïmplementeerd zou zijn, zou een gecompromitteerd besturingssysteem of een gemanipuleerde hypervisor in bepaalde gevallen die beschermende laag zelf kunnen opheffen. Confidential computing verschuift de veiligheidsgaranties daarom zo ver mogelijk naar beneden, oftewel naar de processor en de platformhardware.

Confidential computing bestaat uit drie basisbouwstenen, waarvan de eerste runtime-encryptie is. Dat betekent dat gegevens van een beschermde workload worden versleuteld in het werkgeheugen (RAM). Iedereen die het RAM leest buiten de beschermde uitvoeringsomgeving ziet geen platte tekst – zelfs niet als de toegang verloopt via de hypervisor van een virtuele machine of een snapshot daarvan. Zelfs fysieke toegang tot het RAM en de geheugenbus laat geen platte tekst zien, hoewel er in dergelijke gevallen aanvallen bekend zijn die de versleuteling breken [2].

Confidential computing is in principe ook gevoelig voor sidechannel-aanvallen (zoals Spectre en Meltdown) en hardwaremanipulatie. Die zijn niet direct gericht op beveiligd geheugen, maar maken gebruik van timingeffecten en kwetsbaarheden in de microarchitectuur en caches.

Eenvoudig gezegd werkt de geheugenversleuteling via een hardware-element in de CPU of geheugencontroller dat gegevens automatisch versleutelt als ze naar het RAM worden geschreven en weer ontsleutelt als ze worden gelezen.

Het sleutelmateriaal komt niet van het besturingssysteem – dat wordt niet beschouwd als vertrouwd – maar van een in de hardware verankerde vertrouwensbasis, die tijdens de productie wordt toegevoegd (root of trust). De hardware ontleent de eigenlijke sleutels voor geheugenversleuteling aan die root en beheert ze intern.

Het volgende is belangrijk om risico’s in te schatten: de gegevens blijven niet altijd volledig versleuteld. Om de CPU te kunnen laten rekenen, moeten de gegevens tijdelijk in platte tekst beschikbaar zijn binnen de processor, bijvoorbeeld in registers, caches en uitvoeringseenheden. Versleuteld is in wezen het geheugen buiten die beschermde uitvoeringsomgeving, in het bijzonder de geheugenmodules, en het gegevenstransport tussen uitvoeringsomgeving en geheugen.

De tweede bouwsteen die nodig is voor confidential computing is isolation. Dat zorgt ervoor dat een beschermde workload niet gewoon een ander proces in het systeem is waar het besturingssysteem of de hypervisor toegang toe heeft als dat nodig is. In plaats daarvan trekt de hardware een grens rond de uitvoering. Vanuit het perspectief van het platform draait de beschermde workload in een apart gebied waar zelfs geprivilegieerde software op een normale manier geen toegang toe heeft.

Runtime-encryptie beschermt voornamelijk het beschermde geheugen tegen het lezen van platte tekst buiten de uitvoeringsomgeving. Isolation betekent dat de processor softwarematige toegang van buitenaf tot de beschermde uitvoeringsomgeving voorkomt. Uitwisseling met de buitenwereld vindt alleen plaats via gedefinieerde interfaces. Je kunt dat zien als een duidelijk gedefinieerde API. De beschermde omgeving specificeert zelf welke externe aanroepen het toestaat.

Het derde en laatste ingrediënt van confidential computing is attestatie op afstand. Dat is het vertrouwde bewijs dat de verwachte beschermde omgeving en de verwachte software daadwerkelijk draaien en dat de te beschermen gegevens niet worden toevertrouwd aan gemanipuleerde software.

Om dat te bewerkstelligen creëert de hardware een cryptografisch ondertekend document over de status en identiteit van de workload, meestal op basis van measurements, oftewel een hash van de code en configuratie.

Dat bewijs wordt niet ondertekend door de applicatie zelf, maar door de hardware. De vertrouwensketen gaat helemaal terug tot aan de fabrikant van de processor. Zijn certificaten dienen als een vertrouwensanker dat kan worden gebruikt om de handtekening van de specifieke processor te verifiëren.

In de praktijk werkt het meestal als volgt: een client of een andere dienst maakt niet meteen verbinding met de workload, maar controleert eerst het attestatiecertificaat. Pas als die keten klopt en de measurements overeenkomen met de verwachte software en de confidential-computing-omgeving, worden vertrouwelijke data of secrets zoals sleutels, tokens of certificaten overgedragen aan de werklastworkload.

Zonder attestatie zou een aanvaller eenvoudig kunnen beweren dat hij een beschermd systeem gebruikt en gegevens kunnen onderscheppen bij de start van de communicatie.

Confidential computing vereist nog steeds vertrouwen, maar op een ander gebied. In het klassieke cloudmodel moet je de cloudaanbieder, diens beheerders, de hypervisor en grote delen van de softwarestack vertrouwen.

Confidential computing is ontworpen om die lijst te beperken. Alleen de CPU, delen van de firmware en de attestatieketen van de hardwarefabrikant moeten worden vertrouwd. De vertrouwensgrens wordt daarmee beperkt tot die fabrikant en sluit de cloudoperator expliciet uit.

In die context wordt vaak de term Trusted Computing Base (TCB) gebruikt. Dat verwijst naar het aantal componenten waarvan wordt aangenomen dat ze correct en goed zijn voor het beveiligingsdoel. Hoe kleiner die TCB, des te beter.

Om het explicieter te zeggen: elke extra component in de TCB is een extra potentieel aanvalsoppervlak dat vertrouwd moet worden en dat de belofte van bescherming kan ondermijnen in het geval van een fout.

Bovendien moet ook de code van de workload vertrouwd worden. Dat vertrouwen kan beter worden gewaarborgd door open broncode en reproduceerbare builds: klanten kunnen de code dan zelf controleren, er identieke artefacten van bouwen en hun measurements vergelijken met het bewijs van attestatie op afstand.

De bekendste vroege systemen voor confidential computing waren secure enclaves, met name Intels Software Guard Extensions (Intel SGX). Met dergelijke enclaves wordt alleen een afgebakend, bijzonder kritisch deel van een applicatie verplaatst naar het beschermde uitvoeringsgebied.

Het model is technisch elegant, maar complex voor ontwikkelaars. Applicaties moeten meestal worden verdeeld in een beschermd deel en een onbeveiligde host. Het beschermde deel bevat de gevoelige logica, terwijl de host bijvoorbeeld de netwerk- en bestandstoegang afhandelt.

Confidential VM’s, waarbij de beschermingsmechanismen van confidential computing worden uitgebreid naar volledige virtuele machines, zijn eenvoudiger voor ontwikkelaars. In dat geval blijft de geheugenversleuteling vaak grotendeels onopgemerkt door applicaties binnen de virtuele machine.

De hypervisor van de virtuele machine kan het geheugen nog steeds beheren, maar kan de inhoud in platte tekst niet lezen.

Confidential VM’s zijn vaak makkelijker te gebruiken voor ontwikkelaars omdat bestaande applicaties niet opnieuw ontworpen hoeven te worden rond de scheiding tussen het beveiligde gebied en de onveilige host. In plaats daarvan kunnen ze met relatief weinig aanpassingen volledig worden ingepast in een confidential VM.

Bekende voorbeelden van processortechnologieën die gebruikt kunnen worden om dergelijke VM’s te maken zijn AMD’s Secure Encrypted Virtualisation – Secure Nested Paging (AMD SEV-SNP) en Intels Trust Domain Extensions (Intel TDX).

ARM’s Confidential Compute Architecture (ARM CCA) streeft een vergelijkbaar doel na met zogenaamde realms, voornamelijk in de edge en mobiele sector.

De trend verschuift van kleine, zeer geïsoleerde enclaves naar breder inzetbare infrastructuuroplossingen, die echter, afhankelijk van de implementatie, meer software binnen de beschermde vertrouwensgrens laten.

De belangrijkste toepassing voor confidential computing is het verwerken van gevoelige gegevens op externe infrastructuur. Bedrijven willen gebruik maken van de schaalbaarheid en flexibiliteit van de cloud, maar willen de betreffende operator niet automatisch volledige toegang geven tot hun gegevens.

Confidential computing creëert daar een nieuw model voor: de gegevens worden alleen overgedragen naar een geverifieerde en veilige beschermde omgeving na een succesvolle attestatie.

Dat is vooral interessant voor gereguleerde markten die naleving van beveiligingsnormen moeten aantonen, bijvoorbeeld in de gezondheidszorg of de financiële sector, maar ook voor gezamenlijke analyses door meerdere concurrerende partijen. Daar is het vaak niet voldoende om een operator gewoon organisatorisch te vertrouwen. In plaats daarvan moet technisch verifieerbaar worden gemaakt dat gevoelige gegevens alleen worden verwerkt in de bedoelde beschermde omgeving en op de bedoelde manier.

Confidential computing wordt ook steeds relevanter voor AI-workloads. Daarvoor moet het afgeschermde gebied worden uitgebreid naar GPU’s omdat dat de plek is waar de meeste AI-berekeningen meestal plaatsvinden.

Omdat moderne taalmodellen veel resources nodig hebben, is het aantrekkelijk om hun training en gegevensverwerking uit te besteden aan GPU’s in de cloud. Daarom worden GPU-ondersteunde beschermingsmechanismen ontwikkeld door bedrijven als Microsoft, Google en Nvidia en geïntegreerd in het productaanbod als confidential AI.

Confidential computing wordt daarom niet alleen gezien als een welkome beveiligingsfunctie voor bestaande workflows bij gegevensverwerking, maar ook als een kans om nieuwe workloads naar de cloud te verplaatsen die eerder waren uitgesloten om redenen van vertrouwen en compliance.

Confidential computing is geen oplossing voor algemene doeleinden, maar het dicht een gat dat traditionele encryptie lang heeft opengelaten: de bescherming van data in use. De combinatie van runtime-encryptie, isolation en attestatie op afstand creëert een model dat gevoelige gegevens tijdens de verwerking afschermt van operators, beheerders en gecompromitteerde platformlagen om de vertrouwelijkheid en integriteit te waarborgen.

De derde basisdoelstelling bij informatiebeveiliging, beschikbaarheid (availability) maakt echter geen deel uit van de bescherming die confidential computing belooft: een TEE beschermt niet tegen DoS-aanvallen.

Ook sidechannel-aanvallen en manipulatie van hardware blijven een belangrijk probleem, en als de beschermde en gecertificeerde code zelf lekken bevat, beschermt TEE die wel tegen de host, maar niet tegen zijn eigen logische fouten.

Confidential computing is niettemin een belangrijke en grote stap voorwaarts voor de cloud: weg van blind vertrouwen en naar technisch verifieerbare betrouwbaarheid.

[1] Michael Brenner en Alieke van Sommeren, Apple wil gegevens beschermen met homomorfe versleuteling, c’t 4/2025, p.70
[2] Christof Windeck en Marco den Teuling, Experts kraken Confidential Computing, c’t 3/2026, p.16

David Knichel en Marco den Teuling