Et si vos administrateurs système pouvaient accéder à vos données sensibles sans que vous le sachiez ? L’informatique confidentielle propose une solution : isoler les données, même de ceux qui gèrent l’infrastructure. Mais comment ?

L’informatique confidentielle regroupe un ensemble de technologies permettant de protéger les données sensibles de telle sorte qu’il n’est pas nécessaire de les déchiffrer pour les traiter. Alors que certaines, comme le chiffrement homomorphe, sont encore très complexes à mettre en œuvre, les environnements d’exécution de confiance (EEC aussi appelés « trusted execution environment (TEE) » en anglais) ont atteint une bonne maturité, permettant de les considérer comme des composants importants dans la protection des données.

L’objectif premier des EEC est de dresser un rempart contre la curiosité des entités contrôlant l’infrastructure. Toutefois la protection technique ne résout pas tout. Les lois extraterritoriales [1-5] et l’usage de bibliothèques logicielles propriétaires imposées par certains fournisseurs d’infrastructure informatique peuvent fragiliser cette isolation.

Dans cet article et le suivant, nous nous penchons sur la possibilité de déployer des EEC sur notre propre infrastructure (on-premise). L’objectif est triple : bénéficier de la puissance de l’informatique confidentielle pour protéger les données et permettre de nouveaux cas d’usage, tout en gardant un certain contrôle sur la pile logicielle et matérielle, et ainsi renforcer la confiance de nos clients.

Séparation des rôles

Commençons par rappeler les différents acteurs qui interviennent lors du déploiement d’une application sur une infrastructure informatique. Leurs rôles doivent être hermétiquement séparés pour garantir l’intégrité du système.

• L’opérateur d’infrastructure gère le matériel et les infrastructures (calcul, stockage, réseau), incluant la maintenance des environnements d’exécution de confiance. Il contrôle les mises à jour des micrologiciels et l’allocation des ressources, mais ne devrait pas pouvoir accéder aux données ou aux charges de travail exécutées.
• L’opérateur d’orchestration, qui peut être le même que l’opérateur d’infrastructure, est responsable de la gestion des grappes de serveurs et du déploiement des charges de travail. Il configure les ressources nécessaires aux applications et supervise les services associés (journalisation, surveillance). Ses privilèges devraient aussi être strictement limités afin d’éviter toute intrusion dans l’application, tout en permettant l’orchestration essentielle.
• Le fournisseur de la charge de travail conçoit les spécifications des applications et choisit les images de conteneurs adaptées, en garantissant leur conformité et leur intégrité. Il doit prouver aux propriétaires de données (voir ci-dessous) que le code utilisé est sécurisé et respectueux de la confidentialité, sans pour autant accéder directement aux données sensibles.
• Le fournisseur d’images de conteneurs construit, signe et chiffre les images conteneurs, assurant leur provenance et leur sécurité. Il fournit les clés de vérification et de déchiffrement. Sa collaboration avec le fournisseur de l’application est cruciale pour garantir la chaîne d’approvisionnement logicielle et assurer que le code déployé est exactement celui qui a été audité.
• Enfin, le propriétaire des données détient les données traitées par les applications et exige leur confidentialité et leur intégrité. Il accorde sa confiance au code de l’application (le conteneur) et aux preuves cryptographiques fournies par le microprocesseur, excluant de fait les opérateurs d’infrastructure et d’orchestration de son périmètre de confiance. Il peut imposer des vérifications supplémentaires pour s’assurer que ses données ne sont ni visibles ni manipulées par des personnes non autorisées.

Les relations entre ces acteurs soulèvent des enjeux spécifiques : le propriétaire des données, par exemple, doit pouvoir faire confiance au code des conteneurs (fournis par le fournisseur de la charge de travail) pour traiter ses données, tout en protégeant celles-ci contre les autres acteurs comme l’opérateur d’infrastructure ou l’opérateur d’orchestration. Notamment les administrateurs de ces opérateurs ne devraient en aucun cas pouvoir avoir accès aux données traitées par les conteneurs.

Environnement d’exécution de confiance

Les EEC permettent de créer une barrière technique renforçant la confiance du propriétaire des données dans le conteneur applicatif. Nous avons déjà expliqué en détail leur fonctionnement ainsi que leurs avantages et inconvénients dans un rapport technique [6] et des articles de blogues [7], [8]. Dans cette section nous en rappelons les points clés avant de présenter des choix technologiques pour une mise en œuvre sur notre infrastructure de recherche.

Le bon fonctionnement des EEC réside dans le matériel. Certains micro-processeurs modernes permettent de réserver et de chiffrer une portion de la mémoire vive (RAM) dédiée à une machine virtuelle (VM) spécifique. Ainsi, un administrateur de la machine hôte, même avec les privilèges les plus élevés, ne verra que des données chiffrées s’il tente d’inspecter cette zone mémoire. Bien que des attaques par canaux auxiliaires existent (e.g., [9]), leur complexité nécessite généralement un accès physique prolongé et l’ajout de composants matériels malveillants, ce qui les rend extrêmement difficiles à exécuter.

Pour que le propriétaire des données soit certain que son application s’exécute dans un environnement sain, il utilise le mécanisme d’attestation. Ce processus génère une signature cryptographique du contenu de la mémoire de la VM au moment de son lancement. Cette signature est certifiée par le fabricant du micro-processeur.

Ce processus a des limites notamment dans le cas où l’opérateur d’infrastructure est une société étrangère (e.g., Amazon AWS, Google Cloud ou Microsoft Azure) qui impose ses bibliothèques propriétaires dans la VM afin, par exemple, de fournir la bonne couche d’abstraction matérielle.

Cela nous a conduit à vouloir tester ce type de technologie dans notre laboratoire de recherche sur notre propre matériel, anticipant la possibilité de le faire un jour sur G-Cloud. L’intérêt est de permettre à un client de SMALS de faire fonctionner un conteneur applicatif de manière sécurisée, sans qu’un administrateur de SMALS puisse accéder au contenu du conteneur.

Mais l’utilité des EEC dépasse la simple protection contre les administrateurs. Elle ouvre la voie à d’autres cas d’usage.

Cas d’usage

Un premier exemple se trouve dans le cadre de l’infrastructure européenne de services numériques de santé en ligne (eHDSI). Là, les professionnels de santé d’un pays de traitement peuvent demander les données de santé pertinentes du patient au pays d’affiliation de celui-ci. D’un point de vue technique, la demande est transmise par la passerelle du point de contact national pour la santé (NCPeH) du pays où l’événement de santé imprévu se produit, au pays d’affiliation. Les informations demandées doivent ensuite être récupérées auprès de l’infrastructure nationale du pays d’affiliation, traduites en anglais et transcodées (les données de santé sont transformées du système de codification national vers le système de codification communément accepté, par exemple du format FHIR ou KMEHR vers CDA), puis renvoyées et présentées au professionnel de santé du pays de traitement. Compte tenu du caractère sensible des données, les données devraient être chiffrées de bout en bout, depuis la source de données sur l’infrastructure du pays d’affiliation jusqu’au prestataire de soins de santé dans le pays de traitement. Dans la pratique, cela n’est pas encore possible en raison des différences importantes entre les pays européens. Cependant, il devrait être possible, au minimum, de garantir que les données restent chiffrées et inaccessibles à tout utilisateur ou administrateur entre la source des données et la sortie de la passerelle NCPeH. Une possibilité consiste alors à utiliser des EEC pour effectuer la traduction et le transcodage des données.

Un autre exemple d’utilisation des EEC est la collaboration sécurisée entre entités ne souhaitant pas partager leurs données brutes. Dans le secteur de l’éducation et de l’emploi, une expérience menée par Bogdanov et al en Estonie [10] a montré la puissance des techniques d’informatique confidentielle. Les auteurs de cette étude ont cherché à déterminer si le fait de travailler pendant les études supérieures était corrélé à un échec d’obtention du diplôme dans les délais impartis – une question particulièrement cruciale pour le secteur des technologies de l’information et de la communication en Estonie. Pour répondre à cette problématique sans compromettre la confidentialité des données personnelles, les chercheurs ont combiné les registres d’éducation du ministère de l’Éducation et de la Recherche avec les données de paiements d’impôts du Conseil des taxes et des douanes, grâce à une technique particulière d’informatique confidentielle. Mais une variante plus simple avec un EEC eût été tout aussi efficace pour l’analyse tout en respectant le secret fiscal et la protection des données.

CoCo

Plusieurs solutions logicielles sont disponibles pour mettre à profit les EEC sur notre propre infrastructure de recherche. Nous avons choisi d’utiliser le projet « Confidential Containers (CoCo) » dont le code source est ouvert. Il permet en effet une bonne isolation des conteneurs applicatifs et prend en charge le mécanisme d’attestation de manière transparente, tout en préservant la flexibilité de déploiement et la compatibilité avec la plateforme Kubernetes sur laquelle il s’appuie. Chaque capsule Kubernetes est isolée dans une machine virtuelle confidentielle très légère, de manière à garantir que seules les applications autorisées peuvent accéder aux données sensibles.

Les conteneurs CoCo contiennent quelques composants logiciels nécessaires en plus de l’application elle-même. Ceux-ci permettent de télécharger l’image du conteneur à exécuter, de faciliter la vérification de l’attestation et d’appliquer certaines politiques de sécurité. Leur interface de programmation est relativement petite, notamment par rapport à une solution où tout un nœud Kubernetes serait mis à l’intérieur d’une machine virtuelle confidentielle. En outre, l’image de la machine virtuelle invitée est statique et générique sur toutes les charges de travail et même les plateformes, permettant ainsi d’assurer plus simplement des garanties de sécurité. En même temps, le partage entre les conteneurs dans la même capsule Kubernetes est aisé. Par exemple, l’espace de noms du réseau de la capsule ne quitte pas la machine virtuelle confidentielle, autorisant ainsi les conteneurs qu’elle contient à communiquer de manière confidentielle sans coût supplémentaire.

CoCo s’appuie sur les conteneurs Kata, un autre projet de logiciel libre, qui permet de faire fonctionner des capsules Kubernetes à l’intérieur de machines virtuelles confidentielles très légères (voir Figure 1). CoCo ajoute cependant deux composants cruciaux afin d’assurer confidentialité et sécurité (voir Figure 2).

• Le premier concerne la récupération des images des conteneurs : celles-ci sont habituellement téléchargées par le nœud principal Kubernetes avec l’aide d’une interface d’exécution de conteneur (CRI) comme « containerd, » exposant ainsi les images à la machine hôte à travers le système de fichiers. Avec CoCo, les images sont déchiffrées, et décompactées à l’intérieur de la machine virtuelle confidentielle, d’où la nécessité des composants susmentionnés.
• Le second est l’attestation qui est, comme nous l’avons déjà vu, indispensable à l’établissement d’un environnement d’exécution de confiance. Par exemple, afin de déchiffrer une image, l’invité doit pouvoir obtenir la clé secrète de déchiffrement, mais celle-ci n’est fournie que si l’invité peut prouver son authenticité. C’est le rôle de deux composants qui s’appuient sur un système appelé « Trustee, » extérieur à la machine virtuelle et composé de deux services : un service d’attestation permettant de valider la base d’exécution de confiance et un service de médiation de clés permettant de fournir les ressources secrètes nécessaires à la machine virtuelle et à l’application.

CoCo fournit donc les bases pour construire des conteneurs applicatifs confidentiels en permettant d’exécuter ces conteneurs à l’intérieur de machines virtuelles confidentielles, gérant les images chiffrées et signées des conteneurs, les secrets scellés, et d’autres caractéristiques. Chaque conteneur ou groupe de conteneurs de la même application peut être assigné à une machine virtuelle confidentielle, incluant non seulement la charge de travail, mais aussi des processus permettant à l’application d’appeler certains services de sécurité.

Tout ce qui se trouve en dehors de la machine virtuelle confidentielle sur l’hôte est considéré comme non fiable, y compris l’outil kubelet, l’interface d’exécution de conteneurs et le noyau du système d’exploitation de l’hôte. Les échanges d’informations entre les contextes de confiance et non fiables sont strictement contrôlés, notamment via des politiques de sécurité dynamiques et configurables. Enfin, l’orchestration Kubernetes elle-même est considérée comme non fiable, limitant les garanties sur le planning ou l’ordre d’exécution des charges de travail, à l’exception de leur déploiement dans une enclave authentifiée.

Conclusion

Les conteneurs confidentiels s’inscrivent dans une démarche globale de sécurité, combinant attestation, vérification des images et bonnes pratiques de la chaîne d’approvisionnement logicielle. Ils permettent de traiter des cas d’usage plus simplement que la cryptographie avancée (collaboration confidentielle, intersection privée d’ensemble, pseudonymisation avancée, etc.). Certes les puristes argueront qu’une solution basée sur des conteneurs confidentiels est moins sûre, mais dans la pratique, elle sera probablement suffisante dans un cadre « on-premise », d’autant plus qu’elle simplifie beaucoup d’aspect une fois qu’elle est mise en place.

Dans l’article suivant, nous entrerons plus en détails dans l’installation et l’utilisation des conteneurs confidentiels CoCo.

Références

[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. Consulté le: 9 février 2026. [En ligne]. Disponible sur: https://www.irsem.fr/en/strategic-brief-no-70-2024

[2]        D. Michels, « Europeans, forget the US Cloud Act… worry about FISA instead (!) ». Consulté le: 1 juillet 2025. [En ligne]. Disponible sur: https://www.linkedin.com/pulse/europeans-forget-us-cloud-act-worry-fisa-instead-dave-michels-anjze

[3]        M. Rochefort, « Microsoft face au Sénat : l’aveu qui fait vaciller la souveraineté numérique française », clubic.com. Consulté le: 9 février 2026. [En ligne]. Disponible sur: https://www.clubic.com/actualite-573438-microsoft-face-au-senat-l-aveu-qui-fait-vaciller-la-souverainete-numerique-francaise.html

[4]        D. Deridder, « Understanding Sovereignty: Who Rules your Cloud? », Dirk Deridder. Consulté le: 1 juillet 2025. [En ligne]. Disponible sur: https://dirkderidder.wordpress.com/2025/03/13/understanding-sovereignty-who-rules-your-cloud/

[5]        P. Kunert, « Microsoft exec admits it “cannot guarantee” data sovereignty », The Register. Consulté le: 28 juillet 2025. [En ligne]. Disponible sur: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/

[6]        F. A. P. Petitcolas, « Informatique confidentielle – État de l’art », Smals Research, juill. 2023. [En ligne]. Disponible sur: https://www.smalsresearch.be/publications/document?docid=269

[7]        F. A. P. Petitcolas, « Introduction à l’informatique confidentielle », Smals Research. Consulté le: 9 janvier 2026. [En ligne]. Disponible sur: https://www.smalsresearch.be/introduction-a-l-informatique-confidentielle/

[8]        F. A. P. Petitcolas, « Outils pour l’informatique confidentielle », Smals Research. Consulté le: 9 janvier 2026. [En ligne]. Disponible sur: https://www.smalsresearch.be/outils-pour-linformatique-confidentielle/

[9]        J. De Meulemeester, D. Oswald, I. Verbauwhede, et J. V. Bulck, « Battering RAM: Low-cost interposer attacks on confidential computing via dynamic memory aliasing », présenté à 47th IEEE Symposium on Security and Privacy (S&P), mai 2026.

[10]      D. Bogdanov, L. Kamm, B. Kubo, R. Rebane, V. Sokk, et R. Talviste, « Students and taxes: a Privacy-preserving study using secure computation », Proc. Priv. Enhancing Technol., vol. 2016, n^o 3, p. 117‑135, juill. 2016, doi: 10.1515/popets-2016-0019.

Wat als je systeembeheerders toegang zouden hebben tot je gevoelige data zonder dat je het weet? Confidential Computing biedt een oplossing: data isoleren, zelfs voor degenen die de infrastructuur beheren. Maar hoe?

Confidential Computing 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 belangrijke 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 confidential 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 beheert de firmware-updates en de toewijzing van middelen, maar zou geen toegang mogen hebben tot de data of de uitgevoerde workloads.
• 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). Ook zijn rechten zouden strikt beperkt moeten blijven om elke vorm van inbreuk op de toepassing te voorkomen, terwijl de noodzakelijke orchestratie wel mogelijk blijft.
• De workload provider 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 in de praktijk uiterst moeilijk uit te voeren zijn.

Opdat 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 binnen het onderzoekslabo 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 confidential 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 confidential computing. 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-pod is geïsoleerd in een zeer lichte Confidential Virtual Machine, om te garanderen dat alleen geautoriseerde applicaties toegang hebben tot gevoelige gegevens.

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 Confidential Virtual 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-pod. De naamruimte van het netwerk van de pod blijft bijvoorbeeld binnen de confidential 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-pods kunnen worden uitgevoerd binnen zeer lichte Confidential Virtual 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. Met CoCo worden de images binnen de Confidential Virtual Machine ontsleuteld en uitgepakt, vandaar de noodzaak van de bovengenoemde componenten.
• 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 confidential toepassingscontainers door het mogelijk te maken deze containers binnen confidential virtuel 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 confidential virtuele machine, waarbij niet alleen de werklast wordt meegenomen, maar ook processen waarmee de toepassing bepaalde beveiligingsdiensten kan aanroepen.

Alles buiten de confidential 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

Confidential 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, geavanceerde pseudonimisering, enz.). Puristen kunnen natuurlijk aanvoeren dat een oplossing op basis van confidential containers minder veilig is, maar in de praktijk zal deze waarschijnlijk volstaan in een on-premise omgeving, des te meer omdat het veel aspecten vereenvoudigt zodra het eenmaal is geïmplementeerd.

In de volgende blogpost gaan we dieper in op de installatie en het gebruik van confidential 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://www.smalsresearch.be/publications/document?docid=269

[7]        F. A. P. Petitcolas, “Introduction à l’informatique confidentielle”, Smals Research. Geraadpleegd: 9 januari 2026. [Online]. Beschikbaar op: https://www.smalsresearch.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://www.smalsresearch.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.

Om te voldoen aan de eisen van hun klanten die met gevoelige gegevens omgaan, of om nieuwe klanten aan te trekken, verrichten leveranciers van publieke IT-infrastructuren inspanningen om hun beveiliging te verbeteren en met name om de gegevens van hun klanten beter te beschermen.  Microsoft, bijvoorbeeld, zegt elk jaar ongeveer een miljard dollar te investeren in de beveiliging van zijn infrastructuren [1]. Sinds halfweg 2010 investeren deze infrastructuurleveranciers in een aanbod van confidential computing. Voornamelijk gebaseerd op Trusted Execution Environments (TEE), vermindert dit in principe het vereiste vertrouwen van de klant in de infrastructuurleverancier.

In een vorig artikel (in het Frans) gaven we een algemeen overzicht van deze TEE’s en het nut ervan. In dit artikel gaan we dieper in op hoe de belangrijkste commerciële implementaties werken. Het is echter belangrijk om in gedachten te houden dat de definities van confidential computing en TEE verschillen en soms onvolledig zijn. Dit kan leiden tot een vals gevoel van veiligheid, juridische onzekerheden en maakt het vergelijken moeilijk [2]. Als reactie op dit gebrek aan standaardisatie en interoperabiliteit tussen de verschillende benaderingen van confidential computing is het Confidential Computing Consortium opgericht door grote spelers in de sector, waaronder AMD, Google, Intel en Microsoft. Daarbij moeten we opmerken dat Amazon geen deel uitmaakt van dit consortium en dat zijn Nitro-systeem (zie hier) sterk afwijkt van de andere benaderingen¹.

Een uitgebreidere versie van dit artikel, voorbehouden aan de klanten van Smals, is op aanvraag beschikbaar.

Fabrikanten van microprocessors

AMD en Intel zijn de twee voornaamste fabrikanten van microprocessors die noodzakelijke functionaliteiten bieden voor de confidential computing in grote data centers². Terwijl Intels TDX en AMD’s SEV-SNP-technologieën ontwikkeld zijn om complete virtual machines (VM’s) te beschermen, is de SGX-technologie erg verschillend en heeft deze een kleiner attack surface. Figuur 1 toont de elementen die de Trusted Computing Base (TCB) vormen voor deze drie technologieën die we in de volgende paragrafen beschrijven.

AMD’s SEV-SNP-technologie

In 2016 introduceerde AMD de technologie Secure Encrypted Virtualisation (SEV) om VM’s op hardwareniveau te isoleren van de hypervisor [3], [4]. Elke VM ontvangt zijn eigen AES-coderingssleutel voor geheugenversleuteling. De status van de microprocessorregisters van elke VM wordt ook versleuteld, waardoor de hypervisor de gegevens in de VM niet kan lezen. Later voegde AMD de technologie Secure Nested Paging (SNP) toe om geheugenintegriteit te beschermen en aanvallen door een schadelijke hypervisor te voorkomen (bijv. replay-aanvallen, herconfiguratie van het virtuele geheugenvertaalmechanisme, corruptie van geheugengegevens) [5]. Het fundamentele principe van SEV-SNP is dat als een VM een geheugenpagina kan lezen die voor haar is gereserveerd (en daarom is versleuteld), ze altijd de laatste waarde moet lezen die ze zelf heeft geschreven. Verder vormen in het beveiligingsmodel dat voor SNP wordt gebruikt alleen de VM van de klant en de AMD-microprocessor onderdeel van de trusted base. Dit omvat niet de hypervisor, BIOS, andere VM’s, enzovoort (zie Figuur 1). Tot slot stelt een SEV-SNP-optie VM’s in staat om hun virtuele geheugen op te delen in vier Virtual Machine Privilege Levels (VMPL’s) op een vergelijkbare manier als de beschermingsringen in de x86-architectuur.

AMD’s attestatiemechanisme op afstand verifieert dat de hostmachine een AMD-processor is die de SEV-SNP-technologie ondersteunt en dat een VM is geïmplementeerd met SEV-SNP-bescherming. Elke AMD-processor bevat een beveiligde coprocessor die een paar dedicated sleutels genereert (“Platform Endorsement Key (PEK)”), zelf ondertekend door een unieke sleutel die is afgeleid van geheimen opgeslagen met behulp van eenmalig programmeerbare zekeringen in de chip zelf. Deze PEK wordt ook indirect gebruikt om een gedeeld geheim te creëren tussen het SEV-platform en de klant [6]. Wanneer de beveiligde VM door de hypervisor op het SEV-platform wordt gestart, berekent de SEV-firmware de meting (waarde van de cryptografische hash) van het geheugen van de VM. Deze meting kan veilig worden doorgegeven aan de klant, zodat deze kan controleren of de gedeployde VM niet is gewijzigd.

De SEV-SNP-technologie is beschikbaar op AMD EPYC-processors van 3^e (serie 7003) en 4^e generatie (serie 9004). Deze processors zijn verkrijgbaar bij verschillende leveranciers, waaronder Dell (‘PowerEdge‘-servers), Lenovo en HP. De prijzen variëren van enkele duizenden tot enkele tienduizenden euro’s, afhankelijk van de configuratie.

Intels SGX- en TDX-technologieën

Met Intels systeem Software Guard eXtensions (SGX), dat in 2015 werd geïntroduceerd, kan een software beschermde geheugengebieden definiëren voor beveiligde ‘enclaves’ die geïsoleerd zijn van andere processen die op dezelfde machine draaien (kernels van besturingssystemen, hypervisor, enz.) en waartoe randapparatuur ook rechtstreeks toegang heeft. De processor zorgt ervoor dat elke enclave zijn eigen speciale, versleutelde geheugengebied heeft en registreert elke allocatie door het besturingssysteem [7]. Een enclave wordt gegenereerd als een dynamisch gedeelde bibliotheek met behulp van standaard compilatietools. Wanneer een enclave wordt geïnitialiseerd, vraagt het besturingssysteem de processor om de toepassing te kopiëren naar geheugenpagina’s in de versleutelde beschermde ruimte. Wanneer dan de toepassing in het geheugen is geladen, berekent de processor een meting van de toepassing. Hiermee kan vervolgens de integriteit van de toepassing gecontroleerd worden met behulp van een attestatiemechanisme. In 2020 introduceerde Intel de technologie Trusted Domain Extensions (TDX), een ondertekende softwaremodule uitgevoerd in een nieuwe processormodus die kan worden gebruikt om virtuele machines te beschermen en cryptografisch te isoleren. Meer details over de werking en architectuur van TDX zijn te vinden in [8].

Er zijn twee soorten attestatie op afstand beschikbaar met SGX: Enhanced Privacy ID (EPID) en Data Centre Attestation Primitives (DCAP). De eerste is een attestatiemodus waarbij de Intel-attestatieserver moet worden gecontacteerd om informatie te verkrijgen over de aanvragende enclave. De tweede vereist geen contact met de Intel-attestatieserver. Tijdens het bouwen van een enclave worden er twee metingen gedaan. MRENCLAVE is de cryptografische hashwaarde van de virtuele geheugenlayout die aan de enclave wordt toegewezen wanneer deze wordt gestart. De andere meting, MRSIGNER, is de cryptografische hashwaarde van de publieke sleutel van de auteur van de toepassing die in de enclave draait [9].

Hoewel SGX-technologie is verwijderd uit Intels 12^e generatie Core-processors, blijft deze beschikbaar op 3^e generatie Xeon-processors [10]. Xeon-processors van de 4^e generatie ondersteunen TDX-technologie en zijn verkrijgbaar bij Intels erkende partners en verdelers.

We merken op dat het gebruik van SGX-technologie een grote herschrijving vereist van de bestaande toepassingen³. Het is noodzakelijk om de toepassing te partitioneren door te bepalen welk deel van de code toegang moet hebben tot gevoelige gegevens. Hoewel deze essentiële stap complex is, verbetert het in principe de veiligheid van de toepassing, omdat algemeen wordt aangenomen dat een kleine toepassing – in dit geval een toepassing die in de enclave draait – minder kans heeft op fouten en gemakkelijker te verifiëren is dan een grote. Communicatie tussen het beveiligde deel van de toepassing (binnen de enclave) en de rest van de toepassing (buiten de enclave) vindt plaats via aanroepen van functies die gedeclareerd moeten worden voordat de enclave wordt gelanceerd. Tenslotte kunnen toepassingen die geschreven zijn voor het SGX-platform niet gebruikt worden op andere platformen.

Leveranciers van IT-infrastructuren

Meerdere leveranciers van publieke IT-infrastructuren bieden vandaag oplossingen voor confidential computing gebaseerd op TEE’s. Hier beschrijven we de drie belangrijkste⁴.

AWS

Amazon definieert confidential computing als het gebruik van gespecialiseerde hardware en bijbehorende firmware om de code en gegevens van de klant tijdens de verwerking te beschermen tegen toegang van buitenaf. Amazon vertaalt dit in twee dimensies:

• Bescherming tegen de beheerder van de onderliggende IT-infrastructuur, in dit geval AWS;
• De mogelijkheid voor klanten om hun eigen workloads op te delen in meer of minder betrouwbare componenten, of om multi-agentsystemen te ontwerpen.

Amazon legt de nadruk op de architectuur van het Nitro-systeem, niet op de beschikbaarheid van een bepaalde microprocessor om een TEE te leveren. Sinds april 2023 biedt AWS echter ook de mogelijkheid om EC2-instanties te maken met AMD’s SEV-SNP-technologie (zie hier).

Het Nitro-systeem biedt volgens AWS geen enkel mechanisme waarmee systemen of personen verbinding kunnen maken met EC2-servers, het geheugen van EC2-instanties kunnen lezen of toegang kunnen krijgen tot opgeslagen gegevens. Onderhoudswerk kan alleen worden verricht via beperkte API’s.

Het AWS Nitro-systeem (Figuur 2) is onderdeel van een herziening van Amazons infrastructuur voor EC2-servicevirtualisatie, inclusief het minimaliseren van de onderdelen van de hypervisor die op het moederbord draait. Het AWS Nitro-systeem is een combinatie van servers, processors, beheercomponenten en gespecialiseerde firmware die het onderliggende platform vormt voor alle Amazon EC2-instanties. Het bestaat uit drie hoofdcomponenten:

• Specifieke Nitro Cards – Hardwareonderdelen ontworpen door AWS die zorgen voor algehele systeemcontrole en I/O-virtualisatie onafhankelijk van het moederbordvan het systeem met zijn processors en geheugen;
• Nitro-beveiligingschip – Deze is geïntegreerd in het moederbordvan de server en maakt veilig opstarten mogelijk op basis van een hardware root of trust, maakt het mogelijk om bare metal instances aan te bieden (waardoor de AWS-hypervisor overbodig wordt) en zorgt voor de bescherming van de server tegen ongeoorloofde wijzigingen in de firmware van het systeem;
• Nitro-hypervisor – Een geminimaliseerde, firmwareachtige hypervisor ontworpen om resource- en performance-isolatie te bieden.

Beveiligingsoverwegingen voor dit systeem staan gedetailleerd in [12].

Nitro enclaves daarentegen zijn geïsoleerde virtuele machines die draaien op een klassieke EC2-instantie, een zogenaamde ‘parent instance’ (Figuur 3).

Volgens AWS biedt de Nitro enclave geen extra beveiliging ten aanzien van een AWS-operator [13], maar kan wel worden voorkomen dat een client-side administrator toegang krijgt tot de inhoud van de enclave (code en gegevens).

De belangrijkste beperking van Nitro enclaves is dat de toepassing die in de enclave draait geen verbinding heeft met het netwerk. Ze kan alleen communiceren met de parent instance via een point-to-point interface genaamd ‘vsock’, die wordt gedefinieerd door een context identifier en een poortnummer⁵. Een eenvoudige ‘lift and shift’ is daarom niet mogelijk.

Wanneer het is aangemaakt, kan de toepassing die in de enclave draait een asymmetrisch sleutelpaar genereren en de publieke sleutel in het certificaat laten opnemen. Hierdoor kan de client-side applicatie die het attest verifieert deze sleutel gebruiken om beveiligde communicatie met de enclave tot stand te brengen.

Microsoft Azure

Microsoft Azure stelt drie types confidential computing voor gebaseerd op TEE’s:

• De toepassingsenclaves zijn gebaseerd op de SGX-technologie van Intel. Zoals eerder vermeld, is het noodzakelijk om de bestaande toepassingen grondig te wijzigen om ze aan te passen. Dit vereist veel denkwerk over welke delen van de toepassing beveiligd moeten worden en hun interactie met andere delen, maar het voordeel van deze aanpak is dat slechts een beknopte hoeveelheid code vertrouwd moet worden. Het nadeel is natuurlijk de complexiteit van de implementatie, die speciale training vereist voor analisten, architecten en programmeurs;
• De confidential virtual machines gebruiken AMD’s SEV-SNP-technologie (zie hier) en Microsoft kondigde in april 2023 aan dat ze binnenkort Intels TDX-technologie beschikbaar zou stellen (zie hier) [14]. Azure stelt tevens een ‘trusted platform module’ (TPM) voor, die met name wordt gebruikt voor het attesteren van virtual machines;
• De confidential containers geven de klant een preciezere mate van controle over de TCB dan virtuele machines. In principe maakt dit verpakkingsmodel het mogelijk om bestaande containers in een SGX enclave te draaien zonder dat de software aangepast of opnieuw gecompileerd hoeft te worden (“lift and shift”).

De optie om meerdere threads parallel te laten draaien (“hyper threading”-technologie) binnen dezelfde processor is uitgeschakeld op alle SGX instances. Dit voorkomt aanvallen die leiden tot datalekken tussen toepassingen die dezelfde processor delen.

Google

Google stelt verschillende manieren voor om confidential computing op zijn infrastructuur te implementeren:

• Confidential virtual machines maken gebruik van AMD’s technologie;
• Confidential Kubernetes nodes zijn ook gebaseerd op AMD’s SEV-technologie. De Kubernetes engine van Google kan het gebruik van confidential virtual machines voor alle Kubernetes nodes afdwingen.

Terwijl alle confidential virtual machines virtuele TPM’s bevatten die de integriteit van een virtuele machine valideren bij een gemeten opstart, bieden confidential virtual machines met SEV-SNP-technologie ook hardware cryptografisch ondertekende attestrapporten. SEV-SNP-technologie is echter nog niet algemeen beschikbaar op de infrastructuur van Google.

Praktische limiet van attesten

Zoals uitgelegd in ons vorige artikel, is een belangrijk punt bij het gebruik van TEE’s het verkrijgen van een garantie dat de software die draait op de gehuurde infrastructuur echt de software is die de klant verwacht en dat de gegevens die hij verwerkt niet kunnen worden gelezen door andere software. Deze garantie, een attest genoemd en verkregen via een betrouwbaar mechanisme, moet volledige, recente en semantisch expliciete informatie bevatten [15].

Ervan uitgaande dat we de fysieke veiligheid van de microprocessor of gespecialiseerde chip vertrouwen, dat bekende aanvallen zijn afgeweerd en dat de enclavecode niet kwetsbaar is voor side channel attacks, hoe kunnen we er dan zeker van zijn dat de output van een enclave betrouwbaar is?

Er moet voor gezorgd worden dat:

• De binary file die in de enclave wordt uitgevoerd, gebouwd is met de verwachte code. Hiervoor kan de klant zijn toepassing compileren op een vertrouwde machine (bijvoorbeeld een machine die hij bezit) en vervolgens de binary veilig kopiëren naar het confidential IT-platform. Een andere methode is om een reproducible build system⁶ te gebruiken;
• De binary file die wordt uitgevoerd overeenkomt met het verwachte binary. Een attestsysteem gebruikt cryptografische sleutels afgeleid van vaste geheimen in de vertrouwde microprocessor om een bewijs te ondertekenen dat de binary zich in een bepaalde toestand bevindt op echte hardware (geen simulatie). Het bewijs bevat een meting (cryptografische hashwaarde) van de binary;
• De staat van de toepassing bij het starten is de verwachte staat: het meten van het uitvoerbare deel van de binary is niet voldoende om het toekomstige gedrag te voorspellen;
• Het attest is ondertekend door een vertrouwde entiteit, in principe de fabrikant van de microprocessor of de beveiligde chip.

In de bestudeerde oplossingen, met uitzondering van SGX enclaves, wordt het attest echter ofwel ondertekend door de leverancier van de infrastructuur (en niet door de hardwarefabrikant), ofwel is het niet mogelijk om de meting van de beveiligde software te verifiëren omdat deze proprietary libraries bevat. Het risico bestaat dus dat de gecertificeerde entiteit liegt over haar status.

Conclusie

Tien jaar na de onthullingen van Edward Snowden in juni 2013, betreffende de Amerikaanse surveillancemethoden, moeten we ervan uitgaan dat informatie bemachtigd kan worden als deze voldoende waardevol is. De indruk dat nationale IT-infrastructuren veiliger zijn, kan daarom misleidend zijn⁷. Er bestaat namelijk een spanningsveld tussen het verlangen naar onafhankelijkheid van de IT-diensten van de Staat en het vermogen om het niveau van middelen (hardware, personeel, R&D), redundantie en beveiliging te evenaren dat aangeboden wordt door de dominante bedrijven in de sector⁸. Confidential computing gebaseerd op TEE’s brengt een nieuw argument ten voordele van publieke IT-infrastructuren.

Als ze correct worden geïmplementeerd, en alle andere zaken onveranderd blijven, kunnen TEE’s op basis van fysieke componenten het niveau van gegevensbescherming binnen een IT-infrastructuur aanzienlijk verhogen, met name ten opzichte van derden en in het bijzonder cybercriminelen⁹. Ze maken het in feite mogelijk om de meeste logische aanvallen te vermijden die conventionele systemen treffen, dankzij verbeterde procesisolatie, geheugenversleuteling via de hardwarelaag, veilig opstarten, controlemechanismen voor firmware-updates en, in het algemeen, een vermindering van de omvang van de trusted computing base. Met andere woorden, de veiligheidsmaatregelen opgenomen in de TEE’s maken een aanval aanzienlijk complexer en duurder.

Het aanbod van op TEE-gebaseerde confidential computing varieert tussen leveranciers, afhankelijk van het type abstractie dat wordt aangeboden: software library, container, virtuele machine. De keuze van deze opties leidt tot verschillen in de omvang van de trusted code base (en dus het oppervlak dat blootgesteld wordt aan aanvallen), maar ook in de inspanning die nodig is om bestaande toepassingen aan te passen aan deze nieuwe omgevingen.

Bij het kiezen van een op TEE-gebaseerde oplossing voor confidential computing moeten daarom de volgende punten worden gecontroleerd:

• Bescherming moet verankerd zijn in de fysieke laag van het systeem en elk apparaat moet een unieke identiteit hebben;
• Het attestmechanisme moet het mogelijk maken om de inhoud¹⁰ te verifiëren van de TEE op onafhankelijke wijze van de infrastructuurleverancier¹¹;
• Het attest moet ten minste ondertekend worden door de fabrikant van de fysieke component en niet alleen door de infrastructuurleverancier¹²;
• De dienst stelt ten minste in staat om eigen crypotografische sleutels te importeren in een toegewijde hardware-beveiligingsmodule (HSM), en in het beste geval om een eigen HSM te gebruiken;
• Het moet mogelijk zijn om de source code van de critical libraries die in de trust base zijn opgenomen door de infrastructuurleverancier te controleren op de goede werking van de klanttoepassing;
• De infrastructuurleverancier moet de klant een dienst ter beschikking stellen waarmee de verschillende software dependencies, compilatieomgevingen en binaries die voor de TEE worden gebruikt, kunnen worden getraceerd.

Tot slot is de gegevensbescherming aangeboden door confidential computing tijdens gebruik slechts één van de vele technische aspecten die in overweging moeten worden genomen met betrekking tot de vertrouwelijkheid van gevoelige gegevens (om nog maar te zwijgen van de juridische, economische en politieke aspecten). Net zoals het beste slot op de voordeur van een huis het probleem van een wijd openstaande achterdeur niet oplost, gaat het gebruik van confidential computing ervan uit dat gegevens in rust en in transit effectief worden beschermd, maar vereist het ook specifieke training voor de mensen die verantwoordelijk zijn voor het aanpassen (in meer of mindere mate afhankelijk van het gekozen type confidential computing) en migreren van bestaande toepassingen, in het bijzonder analisten, architecten en programmeurs.

Bibliografie

[1]        A. Linn, ‘Securing the cloud | Microsoft Story Labs’, Securing the cloud | Microsoft Story Labs, 2017. http://news.microsoft.com/stories/cloud-security (geraadpleegd 6 juni 2023).

[2]        M. U. Sardar en C. Fetzer, ‘Confidential computing and related technologies: a critical review’, Cybersecurity, vol. 6, nr. 1, p. 10, mei 2023, doi: 10.1186/s42400-023-00144-1.

[3]        D. Kaplan, ‘AMD x86 Memory Encryption Technologies’, augustus 2016. Geraadpleegd: 11 mei 2023. [Online]. Beschikbaar op: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kaplan

[4]        D. Kaplan, J. Powell, en T. Woller, ‘AMD Memory Encryption’, White Paper, okt. 2021. Geraadpleegd: 1 mei 2023. [Online]. Beschikbaar op: https://www.amd.com/system/files/TechDocs/memory-encryption-white-paper.pdf

[5]        ‘AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More’, AMD, jan. 2020.

[6]        ‘Secure Encrypted Virtualisation API Version 0.24’, Specification, apr. 2020. [Online]. Beschikbaar op: https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf

[7]        Victor Costan en Srinivas Devadas, ‘Intel SGX Explained’. Cryptology ePrint Archive, 2016. [Online]. Beschikbaar op: https://eprint.iacr.org/2016/086

[8]        P.-C. Cheng e.a., ‘Intel TDX Demystified: A Top-Down Approach’. arXiv, 27 maart 2023. Geraadpleegd: 23 mei 2023. [Online]. Beschikbaar op: http://arxiv.org/abs/2303.15540

[9]        ‘Intel 64 and IA-32 Architectures Software Developer’s Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4’. Intel Corporation, maart 2023. [Online]. Beschikbaar op: https://cdrdv2.intel.com/v1/dl/getContent/671200

[10]       A. Rao, ‘Rising to the Challenge — Data Security with Intel Confidential Computing’, 20 januari 2022. https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/Rising-to-the-Challenge-Data-Security-with-Intel-Confidential/post/1353141 (geraadpleegd 17 mei 2023).

[11]       G. Steer, ‘Finance’s big tech problem’, Financial Times, 6 juli 2022. Geraadpleegd: 10 juli 2023. [Online]. Beschikbaar op: https://www.ft.com/content/41f400b6-f83f-4fa1-8dac-731acddcf8f2

[12]       ‘The Security Design of the AWS Nitro System – AWS Whitepaper’. AWS, 18 november 2022. [Online]. Beschikbaar op: https://docs.aws.amazon.com/fr_fr/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html

[13]       ‘Confidential computing: an AWS perspective | AWS Security Blog’, 24 augustus 2021. https://aws.amazon.com/blogs/security/confidential-computing-an-aws-perspective/ (geraadpleegd 18 april 2023).

[14]       M. McReynolds, ‘Preview: Introducing DCesv5 and ECesv5-series Confidential VMs with Intel TDX’, 24 april 2023. https://techcommunity.microsoft.com/t5/azure-confidential-computing/preview-introducing-dcesv5-and-ecesv5-series-confidential-vms/ba-p/3800718 (geraadpleegd 16 mei 2023).

[15]       G. Coker e.a., ‘Principles of remote attestation’, Int. J. Inf. Secur., vol. 10, nr. 2, pp. 63-81, jun. 2011, doi: 10.1007/s10207-011-0124-7.

[16]       ‘Nix & NixOS | Reproducible builds and deployments’. https://nixos.org/ (geraadpleegd 6 juni 2023).

[17]       R. Gallagher, ‘The Inside Story of How British Spies Hacked Belgium’s Largest Telco’, The Intercept, 13 december 2014. https://theintercept.com/2014/12/13/belgacom-hack-gchq-inside-story/ (geraadpleegd 8 juni 2023).

[18]       R. Gallagher, ‘How U.K. Spies Hacked a European Ally and Got Away With It’, The Intercept, 17 februari 2018. https://theintercept.com/2018/02/17/gchq-belgacom-investigation-europe-hack/ (geraadpleegd 8 juni 2023).

[19]       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

[20]       R. Koppel en C. Kuziemsky, ‘Healthcare Data Are Remarkably Vulnerable to Hacking: Connected Healthcare Delivery Increases the Risks’, Stud. Health Technol. Inf., vol. 257, pp. 218-222, 2019.

Noten

¹   Bijvoorbeeld: de term “enclave” heeft een compleet andere betekenis bij Amazon en Intel. Waar “Nitro Enclaves” volledig virtuele machines zijn, zijn de “SGX Enclaves” bibliotheken die bepaalde API’s beschikbaar stellen.

²   We moeten opmerken dat NVIDIA onlangs een grafische processor heeft aangeboden (A100 Tensor Core met de technologie Ampere Protected Memory (APM)) die een vertrouwelijke uitvoeringsmodus introduceert in de grafische processor. Deze maakt het mogelijk om datasets te gebruiken en zo modellen voor machine learning op een vertrouwelijke manier te trainen en in te zetten, met name op een publieke IT-infrastructuur. Deze processors zijn beschikbaar op de Azure-cataloog van Microsoft.

³   Dit is niet het geval met TDX, die een hele virtuele machine kan beschermen.

⁴   Volgens de Financial Times waren de drie belangrijkste leveranciers van IT-infrastructuur in 2021 Amazon, Microsoft en Google [11].

⁵   Deze ‘vsock’ gebruikt dezelfde API als POSIX ‘sockets’.

⁶   Bijvoorbeeld Nix [16].

⁷   In 2014 kwamen we te weten dat GCHQ, de Britse surveillanceagentschap, een gevoelig systeem van Belgacom had gehackt [17], [18].

⁸   Cybercriminele groepen aarzelen niet langer om de veiligheid van IT-services te ondermijnen door nieuwe soorten aanvallen uit te zetten. Het voorbeeld van hacking van SolarWind is in dit opzicht symptomatisch [19]. Een nationaal onafhankelijke, maar onvoldoende beveiligde dienst zou een single point of failure vormen die een kritiek risico inhoudt.

⁹   “Gezondheidsgegevens zijn aantrekkelijk voor cybercriminelen omdat ze financiële en persoonlijke gegevens bevatten, die gebruikt kunnen worden voor chantage en bovenal ideaal zijn voor frauduleuze facturering” [20].

¹⁰   Deze inhoud omvat, in het geval van confidential virtual machines, ook het besturingssysteem dat een minimale grootte moet hebben.

¹¹ Als de infrastructuurleverancier gedeeltelijk de inhoud controleert van de confidential virtual machine of de confidential container en dat de klant geen mechanisme heeft om dit te verifiëren, dan blijft het vertrouwen in de leverancier ongeschonden.

¹² Indien de infrastructuurleverancier het attest ondertekent, dan blijft het vertrouwen in deze leverancier totaal.

_________________________
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.

Pour répondre à la demande de leurs clients traitant des données sensibles ou attirer de nouveaux clients, les fournisseurs d’infrastructures informatiques publiques mettent d’importants moyens en œuvre afin d’améliorer leur sécurité et notamment de mieux protéger les données de leurs clients. Microsoft, par exemple, déclare investir environ un milliard de dollars chaque année dans la sécurité de ses infrastructures [1]. Depuis le milieu des années 2010, ces fournisseurs d’infrastructures investissent notamment dans une offre d’informatique confidentielle. Principalement basée sur des environnements d’exécution de confiance (« Trusted Execution Environments (TEE) »), celle-ci permet en principe de réduire la confiance accordée par le client au fournisseur d’infrastructure.

Dans un article précédent, nous avons présenté de manière générale ce qu’étaient ces TEE et leur utilité. Dans cet article nous regardons plus en détail le fonctionnement des principales mises en œuvre commerciales. Cependant, il convient de garder à l’esprit que les définitions d’informatique confidentielle et de TEE diffèrent et sont parfois incomplètes. Cela peut conduire à un faux sens de sécurité, à des incertitudes légales et à rendre les comparaisons difficiles [2]. Afin de répondre à ce manque de standardisation et d’interopérabilité entre les différentes approches d’informatique confidentielle, le « Confidential Computing Consortium » a été créé par des acteurs importants du secteur, dont AMD, Google, Intel, et Microsoft. Il est à noter qu’Amazon ne fait pas partie de ce regroupement et que son système Nitro (voir ici) est très différent des autres approches¹.

Une version plus approfondie de cet article, réservée aux clients de Smals, est disponible sur demande.

Fabricants de microprocesseurs

AMD et Intel sont les deux principaux fabricants de microprocesseurs offrant des fonctionnalités nécessaires à l’informatique confidentielle dans de larges centres informatiques². Alors que les techniques TDX d’Intel et SEV-SNP d’AMD ont pour but de protéger des machines virtuelles (VM) entières, la techniques SGX est très différente et sa surface d’exposition aux attaques plus faible. La Figure 1 montre les éléments faisant partie de la base informatique de confiance (« Trusted Computing Base (TCB) ») pour ces trois techniques que nous décrivons dans les paragraphes suivants.

Technique SEV-SNP d’AMD

En 2016, AMD a introduit la technique de virtualisation sécurisée par chiffrement (« Secure Encrypted Virtualisation (SEV) ») afin d’isoler les VM de l’hyperviseur au niveau matériel [3], [4]. Chaque VM reçoit sa propre clé de chiffrement AES pour le chiffrement de la mémoire. L’état des registres du microprocesseur de chaque VM est également chiffré, empêchant l’hyperviseur de lire les données contenues dans la VM. Par la suite, AMD a ajouté une technique de pagination imbriquée sécurisée (« Secure Nested Paging (SNP) ») offrant une protection de l’intégrité de la mémoire, et permettant d’empêcher les attaques d’un hyperviseur malicieux (par ex. attaques par rejeu, reconfiguration du mécanisme de traduction de mémoire virtuelle, corruption des données mémoires) [5]. Le principe fondamental de SEV-SNP est que si une VM est en mesure de lire une page mémoire lui étant réservée (et donc chiffrée), alors elle doit toujours lire la dernière valeur qu’elle a elle-même écrite. Par ailleurs dans le modèle de sécurité utilisé pour SNP, seule la VM du client et le microprocesseur AMD font partie de la base de confiance. N’en font donc pas partie l’hyperviseur, le BIOS, les autres VM, etc. (voir Figure 1). Enfin, une option de SEV-SNP permet aux VM de diviser, d’une manière similaire aux anneaux de protection dans l’architecture x86, leur mémoire virtuelle en quatre niveaux de privilèges (« Virtual Machine Privilege Levels (VMPL) »).

Le mécanisme d’attestation à distance d’AMD, permet de vérifier que la machine hôte est bien un processeur AMD qui prend en charge la technique SEV-SNP et qu’une VM a bien été déployée avec la protection SEV-SNP. Chaque processeur AMD, contient un coprocesseur sécurisé qui permet de générer une paire de clés dédiées (« Platform Endorsement Key (PEK) »), elle-même signée par une clé unique dérivée de secrets enregistrés grâce à des fusibles dans la puce elle-même. Cette PEK est également indirectement utilisée pour établir un secret partagé entre la plate-forme SEV et le client [6]. Au moment du lancement par l’hyperviseur de la VM sécurisée sur la plate-forme SEV, le micrologiciel (« firmware ») SEV calcule la mesure (valeur du hachage cryptographique) de la mémoire de la VM. Cette mesure peut être communiquée de manière sécurisée au client afin qu’il vérifie que la VM déployée n’a pas été altérée.

La technique SEV-SNP est disponible sur les processeurs AMD EPYC de 3^e génération (série 7003) et 4^e génération (série 9004). On peut trouver ces processeurs chez différents fournisseurs comme Dell (serveurs « PowerEdge »), Lenovo ou HP. Les prix varient de quelques milliers à plusieurs dizaines de milliers d’euros en fonction de la configuration.

Technique SGX et TDX d’Intel

Introduit en 2015, le système « Software Guard eXtensions (SGX) » d’Intel permet à un logiciel de définir des zones de mémoire protégées pour des « enclaves » sécurisées isolées des autres processus fonctionnant sur la même machine (noyaux du système d’exploitation, hyperviseur, etc.) ainsi que des accès directs par des périphériques. Le processeur s’assure que chaque enclave a sa zone mémoire dédiée et chiffrée, enregistrant chaque allocation par le système d’exploitation [7]. Une enclave est générée en tant que bibliothèque partagée dynamiquement à l’aide d’outils de compilation standards. Lors de l’initialisation d’une enclave, le système d’exploitation demande au processeur de copier l’application dans des pages mémoire de la zone protégée chiffrée. Lors de ce chargement en mémoire, le processeur calcule une mesure de l’application. Cela permet par la suite de vérifier l’intégrité de l’application par un mécanisme d’attestation. Intel a introduit en 2020, la technique « Trusted Domain Extensions (TDX), » qui est un module logiciel signé, exécuté dans un nouveau mode du processeur et qui permet de protéger et d’isoler cryptographiquement des machines virtuelles. Plus de détails sur le fonctionnement et l’architecture de TDX peuvent être trouvés dans [8].

Deux types d’attestation à distance sont disponibles avec SGX « Enhanced Privacy ID (EPID) » et « Data Centre Attestation Primitives (DCAP). » Le premier est un mode d’attestation dans lequel le serveur d’attestation d’Intel doit être contacté pour obtenir des informations sur l’enclave requérante. Le second ne nécessite pas de contacter le serveur d’attestation d’Intel. Durant le processus de construction d’une enclave, deux mesures sont faites. MRENCLAVE est la valeur de hachage cryptographique de la disposition de la mémoire virtuelle assignée à l’enclave au moment de son lancement. L’autre mesure, MRSIGNER, est la valeur de hachage cryptographique de la clé publique de l’auteur de l’application fonctionnant dans l’enclave [9].

Alors que la technique SGX a été retirée de la 12^e génération des processeurs Core d’Intel, elle reste disponible sur la 3^e génération de processeurs Xeon [10]. Les processeurs Xeon de 4^e génération prennent en charge la technique TDX et sont disponibles chez les partenaires et distributeurs agréés d’Intel.

Notons que l’utilisation de la technique SGX demande une réécriture importante des applications existantes³. Il est en effet nécessaire de partitionner l’application en identifiant quelle partie du code doit pouvoir avoir accès aux données sensibles. Bien que cette étape essentielle soit complexe, elle permet en principe d’améliorer la sécurité de l’application étant donné qu’il est généralement accepté qu’une application de petite taille – en l’occurrence celle fonctionnant dans l’enclave – a moins de chances d’avoir des défauts tout en étant plus facilement vérifiable qu’une application de grande taille. La communication entre la partie sécurisée de l’application (dans l’enclave) et le reste de l’application (en dehors de l’enclave) se fait via des appels à des fonctions devant être déclarées avant le lancement de l’enclave. Enfin, les applications écrites pour la plate-forme SGX ne peuvent pas être utilisées sur d’autres plates-formes.

Fournisseurs d’infrastructures informatique

Plusieurs fournisseurs d’infrastructures informatiques publiques proposent aujourd’hui des solutions d’informatique confidentielle basées sur les TEE. Nous décrivons ici les trois principaux⁴.

AWS

Amazon définit l’informatique confidentielle comme l’utilisation de matériel spécialisé et de micrologiciels associés pour protéger le code et les données du client pendant le traitement contre tout accès extérieur. Amazon traduit cela selon deux dimensions :

• La protection vis-à-vis de de l’opérateur de l’infrastructure informatique sous-jacente, en l’occurrence AWS ;
• La capacité des clients à diviser leurs propres charges de travail en composants plus ou moins fiables, ou à concevoir des systèmes multi-agents.

L’accent est mis par Amazon sur l’architecture du système Nitro, plutôt que sur la disponibilité d’un microprocesseur particulier en charge de fournir un TEE. Cependant, depuis avril 2023, AWS offre aussi la possibilité de créer des instances EC2 avec la technique SEV-SNP d’AMD (voir ici).

Dans sa conception, selon AWS, le système Nitro n’offre aucun mécanisme permettant à un système ou à une personne de se connecter aux serveurs EC2, de lire la mémoire des instances EC2 ou d’accéder aux données stockées. Les travaux de maintenance ne peuvent se faire qu’à travers des API limitées.

Le système AWS Nitro (Figure 2) s’inscrit dans une refonte de l’infrastructure de virtualisation du service EC2 d’Amazon, notamment réduire au maximum les parties de l’hyperviseur fonctionnant sur la carte mère. Le système AWS Nitro est une combinaison de serveurs, de processeurs, de composants de gestion et de micrologiciels spécialisés qui fournissent la plate-forme sous-jacente pour toutes les instances Amazon EC2. Il se compose de trois éléments principaux :

• Cartes Nitro spécifiques – Dispositifs matériels conçus par AWS qui assurent le contrôle global du système et la virtualisation des entrées/sorties indépendamment de la carte mère du système avec ses processeurs et sa mémoire ;
• La puce de sécurité Nitro – Celle-ci est intégrée à la carte mère du serveur et permet un démarrage sécurisé basé sur une racine de confiance matérielle, la capacité d’offrir des instances « bare metal » (permettant de se passer de l’hyperviseur d’AWS), ainsi qu’une protection du serveur contre les modifications non autorisées du micrologiciel du système ;
• L’hyperviseur Nitro – Un hyperviseur minimisé, semblable à un micrologiciel, conçu pour fournir une isolation des ressources et des performances.

Les considérations de sécurité de ce système sont détaillées dans [12].

Les enclaves Nitro, quant à elles, sont des machines virtuelles isolées fonctionnant avec une instance EC2 classique, appelée instance « parent » (Figure 3).

Selon AWS, l’enclave Nitro n’offre pas de sécurité supplémentaire vis-à-vis d’une opératrice d’AWS [13], mais permet en revanche d’empêcher un administrateur du client d’accéder au contenu de l’enclave (code et données).

La contrainte principale imposée par les enclaves Nitro est que l’application fonctionnant dans l’enclave n’a pas de connexion au réseau. Elle peut seulement communiquer avec l’instance parent via une interface point à point appelée « vsock » qui est définie par un identifiant de contexte et un numéro de port⁵. Un simple « lift and shift » n’est donc pas possible.

Au moment de sa création, l’application fonctionnant dans l’enclave peut générer une paire de clés asymétriques et faire inclure la clé publique dans l’attestation. Par conséquent l’application client vérifiant l’attestation peut utiliser cette clé afin d’établir une communication sécurisée avec l’enclave.

Microsoft Azure

Microsoft Azure propose trois types d’informatique confidentielle basée sur les TEE :

• Les enclaves d’applications sont basées sur la technique SGX d’Intel. Comme indiqué précédemment, il est nécessaire de modifier en profondeur les applications existantes afin de les adapter. Cela impose une réflexion importante sur le choix des parties de l’application à sécuriser et de leur interaction avec les autres parties, mais l’avantage de cette approche est de réduire la quantité de code auquel il faut faire confiance. L’inconvénient est bien évidemment la complexité de la mise en œuvre, requérant notamment une formation particulière des analystes, architectes et programmeurs ;
• Les machines virtuelles confidentielles utilisent la technique SEV-SNP d’AMD (voir ici) et Microsoft a annoncé en avril 2023, la mise à disposition prochaine de la technique TDX d’Intel (voir ici) [14]. Azure met également à disposition un module de plate-forme fiable (« trusted platform module (TPM) ») utilisé notamment pour l’attestation des machines virtuelles ;
• Les conteneurs confidentiels permettent au client d’avoir un niveau de contrôle plus fin que les machines virtuelles sur la TCB. Ce modèle d’empaquetage permet en principe d’exécuter des conteneurs existants dans une enclave SGX sans devoir modifier ou recompiler le logiciel (« lift-and-shift »).

L’option permettant l’existence de plusieurs fils d’exécution en parallèle (technique « hyper-threading ») au sein du même processeur est désactivée sur toutes les instances SGX. Cela permet d’éviter des attaques conduisant à des fuites de données entre applications partageant le même processeur.

Google

Google propose différentes façons de mettre en œuvre l’informatique confidentielle sur son infrastructure :

• Les machines virtuelles confidentielles utilisent la technique d’AMD ;
• Les nœuds Kubernetes confidentiels reposent également sur la technique SEV d’AMD. Le moteur Kubernetes de Google peut imposer l’utilisation de machines virtuelles confidentielles pour tous les nœuds Kubernetes.

Alors que toutes les machines virtuelles confidentielles contiennent des TPM virtuels qui valident l’intégrité d’une machine virtuelle avec le démarrage mesuré, les machines virtuelles confidentielles avec la technique SEV-SNP offrent également des rapports d’attestation signés cryptographiquement par le matériel. Cependant la technique SEV-SNP n’est pas encore disponible de manière généralisée sur l’infrastructure de Google.

Limite pratique des attestations

Comme nous l’expliquions dans notre article précédent, un point essentiel de l’utilisation des TEE est d’obtenir la garantie que le logiciel fonctionnant sur l’infrastructure louée est réellement le logiciel auquel s’attend le client et que les données qu’il traite ne peuvent être lues par aucun autre logiciel. Cette garantie, appelée attestation et obtenue à travers un mécanisme fiable, devrait contenir des informations complètes, récentes et explicites sur le plan sémantique [15].

En supposant que l’on fasse confiance à la sécurité physique du microprocesseur ou de la puce spécialisée, que les attaques connues ont été atténuées et que le code de l’enclave n’est pas vulnérable aux attaques par canaux auxiliaires (« side-channel attacks »), comment peut-on être certain que la sortie d’une enclave est fiable?

Il faut s’assurer que :

• Le fichier binaire exécuté dans l’enclave a bien été construit avec le code attendu. Pour ce faire le client peut compiler son application sur une machine de confiance (par ex. lui appartenant), puis copier le binaire de manière sécurisée sur la plate-forme d’informatique confidentielle. Une autre méthode est d’utiliser un outil de compilation reproductible⁶ ;
• Le fichier binaire en cours d’exécution correspond bien au binaire attendu. Un système d’attestation utilise des clés cryptographiques dérivées de secrets figés dans le microprocesseur de confiance pour signer une preuve que le binaire est dans un état donné sur un véritable matériel (pas une simulation). La preuve contient une mesure (valeur de hachage cryptographique) du binaire ;
• L’état de l’application au moment de son démarrage est celui attendu ” la mesure de la partie exécutable du binaire n’est pas suffisante pour prédire son comportement futur ;
• L’attestation est signée par une entité de confiance, en principe par le fabricant du microprocesseur ou de la puce sécurisée.

Pourtant dans les solutions étudiées, à l’exception des enclaves SGX, soit l’attestation est signée par le fournisseur de l’infrastructure (et non par le fabricant du matériel), soit il n’est pas possible de vérifier la mesure du logiciel sécurisé car il inclut des bibliothèques propriétaires. Le risque est donc que l’entité attestée mente sur son état.

Conclusion

Dix ans après les révélations d’Edward Snowden en juin 2013, concernant les méthodes de surveillance des États-Unis, nous devons partir du principe que des informations pourront être obtenues si elles sont suffisamment précieuses. L’impression de plus grande sécurité des infrastructures informatiques nationales peut alors être trompeuse⁷. Il existe en effet une tension entre une volonté d’indépendance des services informatiques étatiques et la capacité à égaler les niveaux de ressources (matérielles, humaines, R&D), de redondance et de sécurité qu’offrent les entreprises dominantes du secteur⁸. L’ajout de l’informatique confidentielle basée sur des TEE ajoute un nouvel argument en faveur des infrastructures informatiques publiques.

Lorsqu’ils sont mis en œuvre correctement, et toutes autres choses égales par elles-mêmes, les TEE fondés sur des composants physiques permettent d’augmenter significativement le niveau de protection des données au sein d’une infrastructure informatique, en particulier vis-à-vis de tiers, et notamment de cybercriminels⁹. En effet ils permettent d’éviter la plupart des attaques logiques affectant les systèmes habituels, et ce, grâce à une meilleure isolation des processus, un chiffrement de la mémoire par la couche matérielle, un démarrage sécurisé, des mécanismes de contrôle de mise à jour du micrologiciel, et, d’une manière générale à une réduction de la taille de la base informatique de confiance. En d’autres termes les mesures de sécurité mises en place dans les TEE rendent une attaque beaucoup plus complexe et coûteuse.

Les offres d’informatiques confidentielles basées sur des TEE varient entre les fournisseurs, notamment en fonction du type d’abstraction offert : librairie logicielle, conteneur, machine virtuelle. Le choix de ces options conduit à des différences dans la taille du code de la base de confiance (et donc de la surface exposée aux attaques), mais également dans l’effort d’adaptation nécessaire des applications existantes à ces nouveaux environnements.

Lors du choix d’une solution d’informatique confidentielle basée sur les TEE, il conviendra donc de vérifier les points suivants :

• La protection doit être ancrée dans la couche physique du système et chaque appareil doit avoir une identité unique ;
• Le mécanisme d’attestation doit permettre de pouvoir vérifier le contenu¹⁰ du TEE de manière indépendante du fournisseur d’infrastructure¹¹;
• L’attestation doit être signée au moins par le fabricant du composant physique et pas uniquement par le fournisseur d’infrastructure¹²;
• Le service permet au minimum d’importer ses propres clés cryptographiques dans une boîte noire transactionnelle (HSM) dédiée, et au mieux d’utiliser sa propre boîte ;
• Il devrait être possible de vérifier le code source des librairies critiques incluses par le fournisseur d’infrastructure dans la base de confiance pour le bon fonctionnement de l’application du client ;
• Un service permettant de traquer les différentes dépendances logicielles, d’environnement de compilation, et des binaires utilisés pour le TEE devrait être mis à disposition du client par le fournisseur d’infrastructure.

Finalement, la protection des données en cours d’utilisation permise par l’informatique confidentielle ne représente qu’un des multiples aspects techniques à considérer concernant la confidentialité des données sensibles (sans compter les aspects juridiques, économiques et politiques). Tout comme la meilleure serrure sur la porte d’entrée principale d’une maison ne résout pas le problème d’une porte secondaire grande ouverte, l’utilisation de l’informatique confidentielle suppose que les données sont effectivement protégées au repos et en mouvement, mais requiert également une formation spécifique des personnes en charge de l’adaptation (plus ou moins importantes en fonction du type d’informatique confidentielle choisie) et du transfert des applications existantes, notamment les analystes, architectes, et programmeurs.

Bibliographie

[1]        A. Linn, « Securing the cloud | Microsoft Story Labs », Securing the cloud | Microsoft Story Labs, 2017. http://news.microsoft.com/stories/cloud-security (consulté le 6 juin 2023).

[2]        M. U. Sardar et C. Fetzer, « Confidential computing and related technologies: a critical review », Cybersecurity, vol. 6, n^o 1, p. 10, mai 2023, doi: 10.1186/s42400-023-00144-1.

[3]        D. Kaplan, « AMD x86 Memory Encryption Technologies », août 2016. Consulté le: 11 mai 2023. [En ligne]. Disponible sur: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kaplan

[4]        D. Kaplan, J. Powell, et T. Woller, « AMD Memory Encryption », White Paper, oct. 2021. Consulté le: 1 mai 2023. [En ligne]. Disponible sur: https://www.amd.com/system/files/TechDocs/memory-encryption-white-paper.pdf

[5]        « AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More », AMD, janv. 2020.

[6]        « Secure Encrypted Virtualisation API Version 0.24 », Specification, avr. 2020. [En ligne]. Disponible sur: https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf

[7]        Victor Costan et Srinivas Devadas, « Intel SGX Explained ». Cryptology ePrint Archive, 2016. [En ligne]. Disponible sur: https://eprint.iacr.org/2016/086

[8]        P.-C. Cheng et al., « Intel TDX Demystified: A Top-Down Approach ». arXiv, 27 mars 2023. Consulté le: 23 mai 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2303.15540

[9]        « Intel 64 and IA-32 Architectures Software Developer’s Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4 ». Intel Corporation, mars 2023. [En ligne]. Disponible sur: https://cdrdv2.intel.com/v1/dl/getContent/671200

[10]       A. Rao, « Rising to the Challenge — Data Security with Intel Confidential Computing », 20 janvier 2022. https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/Rising-to-the-Challenge-Data-Security-with-Intel-Confidential/post/1353141 (consulté le 17 mai 2023).

[11]       G. Steer, « Finance’s big tech problem », Financial Times, 6 juillet 2022. Consulté le: 10 juillet 2023. [En ligne]. Disponible sur: https://www.ft.com/content/41f400b6-f83f-4fa1-8dac-731acddcf8f2

[12]       « The Security Design of the AWS Nitro System – AWS Whitepaper ». AWS, 18 novembre 2022. [En ligne]. Disponible sur: https://docs.aws.amazon.com/fr_fr/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html

[13]       « Confidential computing: an AWS perspective | AWS Security Blog », 24 août 2021. https://aws.amazon.com/blogs/security/confidential-computing-an-aws-perspective/ (consulté le 18 avril 2023).

[14]       M. McReynolds, « Preview: Introducing DCesv5 and ECesv5-series Confidential VMs with Intel TDX », 24 avril 2023. https://techcommunity.microsoft.com/t5/azure-confidential-computing/preview-introducing-dcesv5-and-ecesv5-series-confidential-vms/ba-p/3800718 (consulté le 16 mai 2023).

[15]       G. Coker et al., « Principles of remote attestation », Int. J. Inf. Secur., vol. 10, n^o 2, p. 63‑81, juin 2011, doi: 10.1007/s10207-011-0124-7.

[16]       « Nix & NixOS | Reproducible builds and deployments ». https://nixos.org/ (consulté le 6 juin 2023).

[17]       R. Gallagher, « The Inside Story of How British Spies Hacked Belgium’s Largest Telco », The Intercept, 13 décembre 2014. https://theintercept.com/2014/12/13/belgacom-hack-gchq-inside-story/ (consulté le 8 juin 2023).

[18]       R. Gallagher, « How U.K. Spies Hacked a European Ally and Got Away With It », The Intercept, 17 février 2018. https://theintercept.com/2018/02/17/gchq-belgacom-investigation-europe-hack/ (consulté le 8 juin 2023).

[19]       C. Zhao, « SolarWinds, Probably Hacked by Russia, Serves White House, Pentagon, NASA », Newsweek, 14 décembre 2020. Consulté le: 9 janvier 2023. [En ligne]. Disponible sur: https://www.newsweek.com/solar-winds-probably-hacked-russia-serves-white-house-pentagon-nasa-1554447

[20]       R. Koppel et C. Kuziemsky, « Healthcare Data Are Remarkably Vulnerable to Hacking: Connected Healthcare Delivery Increases the Risks », Stud. Health Technol. Inf., vol. 257, p. 218‑222, 2019.

Notes

¹   Par exemple le terme « enclave » n’a pas du tout le même sens chez Amazon et Intel. Alors que les « Nitro Enclaves » sont des machines virtuelles entières, les « SGX Enclaves » sont des bibliothèques exposant certaines API.

²   Notons que NVIDIA offre depuis peu un processeur graphique (A100 Tensor Core avec la technique « Ampere Protected Memory (APM) ») qui introduit un mode d’exécution confidentielle dans le processeur graphique et permet ainsi d’utiliser des ensembles des données pour former et déployer des modèles d’apprentissage automatique (« machine learning ») de manière confidentielle, notamment sur une infrastructure informatique publique. Ces processeurs sont disponibles sur l’offre Azure de Microsoft.

³   Ce n’est pas le cas avec TDX qui permet de protéger une machine virtuelle entière.

⁴   Selon le Financial Times, les trois fournisseurs d’infrastructure informatique les plus importants en 2021 étaient Amazon, Microsoft et Google [11].

⁵   Cette « vsock » utilise la même API que les « sockets » POSIX.

⁶   Par exemple Nix [16].

⁷   Nous avons appris en 2014 que l’agence de surveillance britannique GCHQ avait piraté un système sensible de Belgacom [17], [18].

⁸   Les groupes cybercriminels n’hésitent plus à compromettre la sécurité de services informatiques en mettant en œuvre de nouveaux types d’attaques. L’exemple du piratage de SolarWind est symptomatique à cet égard [19]. Un service indépendant national mais insuffisamment sécurisé pourrait représenter un point de défaillance unique posant un risque crucial.

⁹   « Les données de santé sont attrayantes pour les cybercriminels car elles contiennent des données financières et personnelles, peuvent être utilisées pour le chantage et, surtout, sont idéales pour la facturation frauduleuse » [20].

¹⁰ Ce contenu, dans le cas de machines virtuelles confidentielles, inclut également le système d’exploitation que l’on préférera de taille minimale.

¹¹ Si le fournisseur d’infrastructure contrôle en partie le contenu de la machine virtuelle confidentielle ou du conteneur confidentiel et que le client n’a pas de mécanisme pour le vérifier, alors la confiance dans le fournisseur reste totale.

¹² Si le fournisseur d’infrastructure signe l’attestation, alors la confiance dans ce fournisseur reste totale.

_________________________

Ce post est une contribution individuelle de Fabien A. P. Petitcolas, spécialisé en sécurité informatique chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

On considère généralement que les données peuvent être dans trois états. Celles stockées, par exemple sur un disque dur ou dans une base de données, sont dites « au repos », celles envoyées d’un ordinateur à un autre, par exemple via un réseau, sont « en mouvement, » et les données traitées par le microprocesseur sont « en cours d’utilisation  ».

Aujourd’hui, des primitives cryptographiques sont largement déployées pour protéger les données dans les deux premiers états, assurant intégrité et confidentialité. Cependant, le renforcement des réglementations sur la protection des données et de la vie privée et l’augmentation des cyber-menaces de longue durée a fait naître le besoin de protéger les données en cours d’utilisation.

Malheureusement cette protection des données en cours d’utilisation reste difficile, en particulier dans le contexte d’infrastructures informatiques partagées : il s’agit en effet d’exécuter un logiciel avec certaines garanties de sécurité sur un ordinateur distant qui peut être détenu et géré par une partie non fiable voire malintentionnée.

De nombreuses attaques

Les attaques possibles sont nombreuses.

Au niveau logiciel on compte toutes les attaques permettant de compromettre l’intégrité du système, que ce soit le système d’exploitation, l’hyperviseur ou le micrologiciel (« firmware »). Celles-ci sont rendues possibles via divers types de rançongiciels ou d’outils de piratage, via des pilotes de périphériques compromis, via l’exploitation d’une vulnérabilité du jour zéro, de l’injection d’erreurs logiques, ou encore, à cause d’employés malveillants ou de mauvaises pratiques de fabrication, etc. [1]–[8]. On compte également l’accès aux données à l’aide de canaux auxiliaires (« side-channel attacks »), ou celui dû à des erreurs de configuration ou de paramétrage du système. Enfin, plus rares, les attaques cryptographiques, suite à une analyse poussée d’un algorithme ou à l’exploitation d’une percée mathématique sont possibles.

Au niveau physique, on peut envisager une administratrice système ou un prestataire externe accédant sans autorisation au matériel, pouvant alors se connecter directement au circuit imprimé et copier des informations par accès direct à la mémoire vive (DIMM DMA), espionner le lien à débit de données double (DDR), surveiller le bus informatique et du cache, etc.

Techniques principales

L’informatique confidentielle (« confidential computing ») vise à apporter une solution technique à ces problèmes à travers trois méthodes principales :

• Les environnements d’exécution de confiance (« trusted execution environments » – TEE) s’appuient sur une combinaison de composants matériels sécurisés, de mécanismes d’attestation et de logiciels conçus pour utiliser ces fonctionnalités matérielles¹.
• Le chiffrement homomorphe (« homomorphic encryption » – HE), partiel ou total, concerne le calcul direct sur des données chiffrées [11] et peut aider pour certaines classes de problèmes, mais engendre un coût de par la surcharge de calcul liée au chiffrement spécifique [12].
• Le calcul multipartite sécurisé [13] (« secure multiparty computation » – MPC) est une classe de méthodes cryptographiques qui permet à des parties mutuellement méfiantes de calculer conjointement des fonctions sur leurs données d’entrée sans révéler celles-ci à d’autres parties. Ce type de calcul a déjà été décrit sur cet article de blog.

Bien entendu, il est possible de combiner ces techniques comme par exemple les environnements d’exécution de confiance avec le chiffrement homomorphe (par ex. [14]).

Dans la suite nous nous concentrerons sur le premier type d’informatique confidentielle : les environnements d’exécution de confiance.

Réduction de la surface d’exposition aux attaques

En règle générale, la pile complète d’une plateforme informatique est composée de plusieurs techniques provenant de nombreux fournisseurs différents, ce qui entraîne un manque de mise en œuvre cohérente des contrôles de sécurité.

Cependant, la couche physique matérielle sur laquelle l’ensemble du système est construit reste la première couche de protection. Par conséquent une façon d’améliorer la sécurité globale d’un système – y compris en empêchant l’accès aux données – est d’augmenter la sécurité de la partie physique.

C’est sur cet argument que se basent les TEE qui visent à protéger l’exécution du code des applications contre les attaques de code privilégié et certaines attaques physiques en réduisant la base d’information de confiance et la surface d’exposition aux attaques (Figure 1).

Dans certains cas, la petitesse du TEE permet l’application de méthodes formelles (basées sur des constructions mathématiques) et la vérification de la conformité de la mise en œuvre par rapport aux spécifications. Cela permet de renforcer le niveau de confiance placé dans le TEE.

Les TEE

Les TEE sont des systèmes de sécurité qui s’exécutent parallèlement aux environnements d’exécution réguliers (y compris le système d’exploitation comme Linux ou Windows). Ils fournissent une zone sûre pour protéger les actifs (par ex., les secrets sensibles, les chaînes d’authentification) et ont également pour but d’assurer que les opérations effectuées en leur sein et les données associées ne peuvent pas être visualisées à l’extérieur, pas même par un logiciel privilégié (par ex., hyperviseur, système d’exploitation) ou un débogueur. Combinés à un mécanisme d’attestation (voir ci-dessous) ils assurent que le code qu’ils exécutent ne peut pas être modifié ou remplacé sans l’autorisation de l’utilisateur.

Un TEE peut être utilisé pour fournir une isolation de mémoire, empêchant les applications partageant le même matériel sous-jacent de lire la mémoire allouée aux autres. Certains TEE permettent d’isoler des applications entières dans leurs propres enclaves plutôt que de protéger uniquement des opérations ou de la mémoire spécifique.

L’application des propriétés mentionnées ci-dessus est basée sur un matériel physique spécifique, en intégrant tout ou une partie des ressources nécessaires au bon fonctionnement du TEE dans un même boitier, ou en utilisant des ressources partagées par les autres composants disponibles sur le circuit imprimé de la machine (par ex. la mémoire vive). Dans ce dernier cas une isolation par chiffrement est nécessaire.

Tous les TEE ne sont pas identiques et différents fabricants peuvent proposer différentes mise en œuvre de TEE avec différentes propriétés de sécurité, différentes fonctionnalités et différents mécanismes de contrôle pour fonctionner sur les application sécurisées². En effet certains TEE s’adressent plutôt à des téléphones (par ex. la technique TrustZone d’ARM) tandis que d’autres à des ordinateurs de bureau ou des ordinateurs formant une infrastructure informatique partagée (par ex. les techniques SGX d’Intel ou SEV d’AMD).

Plusieurs fournisseurs d’infrastructure informatique publiques offrent la possibilité d’utiliser ces techniques à celles ou ceux ne disposant pas de ce matériel. Par exemple, Microsoft a le produit Azure Confidential Computing offrant SGX et SEV. Amazon, met en œuvre sa propre technique TEE appelée Nitro sur son infrastructure AWS.

Exigences de sécurité

Les TEE sont conçus pour résister à un large éventail de menaces logicielles du système d’exploitation standard, y compris les menaces au niveau du noyau (par ex. [16]) provenant d’un périphérique rooté ainsi qu’à certaines attaques physiques. Les TEE font l’objet d’une analyse de sécurité rigoureuse dans le cadre des « Critères communs » [17], [18], mais ils manquent encore généralement de défenses contre les attaques matérielles complexes. Par exemple, les attaques qui « nécessitent généralement un accès à long terme et/ou invasif au matériel, y compris les techniques de grattage de puces et les sondes de microscope électronique » sont explicitement hors du champ d’application des exigences du Confidential Computing Consortium [19].

Les exigences de sécurité d’un TEE se résument ainsi (voir [9] pour plus de détails) :

• L’objectif principal d’un TEE est de protéger ses actifs contre les attaques à travers le reste de l’environnement d’exécution. Ceci est réalisé grâce à des mécanismes matériels que ces autres environnements ne peuvent pas contrôler.
• Le TEE offre une protection contre certaines attaques physiques. Les attaques intrusives qui brisent physiquement la structure physique du circuit intégré ne sont pas considérées.
• L’environnement d’exécution du système d’exploitation de confiance est démarré à partir d’une racine de confiance (RoT) à l’intérieur du TEE via un processus de démarrage sécurisé.
• Le TEE fournit un stockage sécurisé des données et des clés cryptographiques. Ce stockage est lié à ce TEE particulier sur un appareil particulier.
• Les logiciels extérieurs au TEE ne peuvent pas appeler directement les fonctionnalités exposées par les interfaces internes du TEE et doivent passer par des protocoles de communication spécifiques permettant au système d’exploitation de confiance de vérifier l’acceptabilité de l’opération non-TEE demandée.

Vérification de l’intégrité

Un concept clé des TEE est la capacité de l’utilisateur à vérifier l’intégrité de la plateforme sous-jacente. Cela est généralement réalisé grâce à deux composantes : le hachage des différents modules logiciels et la vérification du micrologiciel. Dans le cadre d’infrastructures informatiques partagées, il est nécessaire de pouvoir effectuer cette vérification à distance.

Hachage et signature des modules

Les hachages cryptographiques (également souvent appelés « mesures » dans le contexte des TEE) du logiciel, du micrologiciel et des fichiers de configuration associés, sous-tendent la création d’une chaîne de confiance. Chacune de ces chaînes de confiance commence par un module racine de confiance qui doit être aussi petit que possible. Il peut prendre la forme d’un bloc de démarrage implicitement fiable (par ex., stocké en mémoire à lecture seule) du système élémentaire d’entrée/sortie (BIOS) qui mesure d’abord sa propre intégrité, puis étend la mesure à l’ensemble du BIOS. Ensuite, chaque micrologiciel ou logiciel supplémentaire à exécuter est d’abord mesuré avant d’être exécuté et cela va jusqu’au système d’exploitation en suivant un processus de démarrage classique [20].

Ce mécanisme de chaîne de confiance résumé dans la Figure 2 fournit une vue fiable de l’état actuel du système. Toute bibliothèque, module, application, partie du système d’exploitation ou non, a une mesure d’intégrité stockée dans un stockage matériel sécurisé. En principe ces mesures sont signées afin d’empêcher les attaques par relecture ou par l’homme du milieu (par ex. [21]).

Les protections matérielles garantissent qu’une fois qu’une enclave est lancée, aucune modification de son code ou de ses données statiques ne peut être effectuée depuis l’extérieur de l’enclave. Une fois lancés, les processus extérieurs à l’enclave peuvent recevoir une attestation cryptographique qui inclut une signature du code à l’intérieur de l’enclave, de sorte que le processus extérieur peut être assuré de l’exactitude de tout le code pouvant s’exécuter dans l’enclave.

Vérification du micrologiciel et de sa configuration

L’attestation locale ou à distance implique, comme indiqué ci-dessus, la génération d’une signature des mesures, et en particulier celle de la racine de confiance pour la mesur³ (CRTM) avec des clés d’attestation spécifiques. Le mécanisme permet une utilisation à distance pour vérifier si le micrologiciel, le système d’exploitation et l’application souhaités sont réellement en cours d’exécution. Il permet également l’application de politiques de sécurité spécifiques.

Il convient de souligner que dans une architecture moderne complexe, le fabricant du CRTM peut ne pas rester longtemps l’autorité de confiance dans le processus de démarrage et il faut vérifier la chaîne de valeurs de hachage enregistrées pour déterminer l’autorité de l’état actuel du système. En outre, dans un centre de données typique, il peut y avoir des milliers de machines avec leur propre CRTM, ce qui rend leur suivi une tâche complexe, de sorte que des services d’attestation à distance dédiés sont souvent mis à la disposition de l’utilisateur de l’infrastructure informatique partagée.

Notons enfin qu’une construction de racine de confiance avec des protections matérielles physiques sera plus difficile à changer qu’une construction uniquement dans le micrologiciel. Mais un matériel immuable de racine de confiance ne peut pas être mis à jour.

Attestation à distance

L’attestation est un élément fondamental pour vérifier la fiabilité d’un TEE et ensuite décider de lui faire confiance ou pas. Il permet à un environnement logiciel de prouver qu’un programme spécifique est exécuté par un matériel spécifique. Une attestation locale peut être utilisée entre deux environnements logiciels partageant le même matériel, mais ce qui intéresse la plupart des utilisateurs de systèmes avec TEE, est l’attestation à distance où les deux environnements logiciels fonctionnent sur du matériel différent.

En général cette attestation se base sur un module de plateforme fiable (« trusted platform module » – TPM), mais d’autres méthodes existent comme par exemple l’utilisation de fonctions physiques non clonables (« physical unclonable function » – PUF) ou encore des secrets fusionnés dans le circuit intégré.

La plupart des TEE peuvent générer des preuves cryptographiques vérifiables, qui peuvent être envoyées à une partie utilisatrice (par ex., l’appareil utilisateur, le fournisseur de services), qui peut ensuite valider la signature de la preuve. Si la signature et la preuve sont valides, la partie de confiance conclut que le logiciel attendu est exécuté dans un TEE authentique. La preuve est basée sur la mesure du TEE et peut également inclure une clé publique du TEE.

La Figure 3 présente un processus d’attestation générique. La partie utilisatrice du TEE doit connaître la mesure attendue, non seulement de l’application qu’elle souhaite déployer mais également du micrologiciel du TEE. La vérification peut s’effectuer grâce à un mécanisme de défi-réponse. De cette façon l’attestation permet de convaincre l’utilisateur que l’attestation a bien été produite par un logiciel spécifique à l’intérieur d’un matériel spécifique sans interférences extérieures. Plus de détails ainsi que des variations sont donnés dans [23].

Le système d’attestation doit permettre de pouvoir révoquer le TEE dans le cas où il s’avère que la sécurité de ce dernier est compromise.

Conclusion

La combinaison de composants matériels sécurisés et de techniques d’attestation à distance forme l’assise des environnements d’exécution de confiance qui ont pour but de protéger les données sensibles ou secrètes ainsi que le code exécuté contre des attaques de plus en plus fréquentes visant des données en cours de calcul.

Ces environnements sont a priori prometteurs dans le cadre d’infrastructures informatiques partagées. D’abord ils permettent d’augmenter le niveau de sécurité de telles infrastructures en isolant mieux les applications les unes des autres, empêchant par exemple une application compromise d’accéder aux données d’une autre. Ensuite, ils pourraient permettre d’accroître le niveau de confiance des utilisateurs de cette infrastructure pour le traitement de certaines données, pour autant que ces utilisateurs puissent garder le contrôle de la gestion des clés de chiffrement et déchiffrement utilisées au sein de l’environnement de confiance.

Pour l’utilisateur final, l’évaluation des risques liés à l’utilisation du système est simplifiée en ce sens que la confiance est placée dans un composant matériel spécifique et un micrologiciel vérifiable à distance, tous deux avec un comportement attendu, plutôt que dans l’ensemble de l’ordinateur. Mais d’autres risquent sont introduits, comme, par exemple, la possibilité d’un enferment dans une technique TEE particulière.

Dans un prochain article nous regarderons plus en détails le fonctionnement de certaines mises en œuvre commerciales.

Références

[1]        A. Greenberg, « A Peek Into the Toolkit of the Dangerous Triton Hackers », Wired, 10 avril 2019. Consulté le: 4 janvier 2023. [En ligne]. Disponible sur: https://www.wired.com/story/triton-hacker-toolkit-fireeye/

[2]        K. Zetter, « Inside the Cunning, Unprecedented Hack of Ukraine’s Power Grid », Wired, 3 mars 2016. Consulté le: 4 janvier 2023. [En ligne]. Disponible sur: 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 septembre 2022. Consulté le: 9 janvier 2023. [En ligne]. Disponible sur: https://thehackernews.com/2022/09/new-malware-families-found-targeting.html

[4]        R. Naraine, « Stuxnet attackers used 4 Windows zero-day exploits », ZDNET, 14 septembre 2010. Consulté le: 9 janvier 2023. [En ligne]. Disponible sur: 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 décembre 2020. Consulté le: 9 janvier 2023. [En ligne]. Disponible sur: 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 septembre 2018. Consulté le: 4 janvier 2023. [En ligne]. Disponible sur: https://www.wired.com/story/fancy-bear-hackers-uefi-rootkit/

[7]        T. Bletsch, X. Jiang, V. W. Freeh, et 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, mars 2011, p. 30‑40. doi:10.1145/1966913.1966919.

[8]        T. Claburn, « MSI motherboards found to have insecure Secure Boot », The Register, 17 janvier 2023. Consulté le: 18 janvier 2023. [En ligne]. Disponible sur: https://www.theregister.com/2023/01/17/msi_motherboards_secure_boot/

[9]        « TEE System Architecture v1.3 ». GlobalPlatform, mai 2022. [En ligne]. Disponible sur: https://globalplatform.org/specs-library/tee-system-architecture/

[10]      M. Sabt, M. Achemlal, et A. Bouabdallah, « Trusted Execution Environment: What It is, and What It is Not », in 2015 IEEE Trustcom/BigDataSE/ISPA, Helsinki, Finland, août 2015, p. 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, mai 2009, p. 169‑178. doi: 10.1145/1536414.1536440.

[12]      M. Naehrig, K. Lauter, et V. Vaikuntanathan, « Can homomorphic encryption be practical? », in Proceedings of the 3rd ACM workshop on Cloud computing security workshop – CCSW ’11, Chicago, Illinois, USA, 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 et 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, oct. 2017, p. 85‑88. doi: 10.1145/3139923.3139933.

[15]      M. Pei, H. Tschofenig, D. Thaler, et D. Wheeler, « Trusted Execution Environment Provisioning (TEEP) Architecture », Internet Engineering Task Force, Internet Draft draft-ietf-teep-architecture-19, oct. 2022. Consulté le: 30 janvier 2023. [En ligne]. Disponible sur: https://datatracker.ietf.org/doc/draft-ietf-teep-architecture-19

[16]      S. Checkoway et H. Shacham, « Iago Attacks: Why the System Call API is a Bad Untrusted RPC Interface ».

[17]      « Common Criteria for Information Technology Security Evaluation ». novembre 2022. [En ligne]. Disponible sur: https://www.commoncriteriaportal.org/cc/

[18]      « TEE Protection Profile – Version 1.3 ». GlobalPlatform, 4 juin 2020.

[19]      « A Technical Analysis of Confidential Computing ». Confidential Computing Consortium, octobre 2021. [En ligne]. Disponible sur: 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, et 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 et K. Goldman, « Trusted Platform Module (TPM) », Trusted Computing Group (TCG), 2019. https://trustedcomputinggroup.org/work-groups/trusted-platform-module/

[22]      C. Shepherd et al., « 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, août 2016, p. 168‑177. doi: 10.1109/TrustCom.2016.0060.

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

Notes

¹ Plusieurs définitions des environnements d’exécution (TEE) de confiance ou des environnements d’exécution sécurisés (SEE) ont été données, parfois avec des contradictions entre elles. Dans cet article nous nous basons principalement sur les spécifications du Confidential Computing Consortium et de la GlobalPlatform [9]. Différentes définitions sont comparées et une description formelle de ces environnements est proposée dans [10].

² Il y a des propositions pour simplifier le travail des programmeurs d’applications sécurisées avec, par exemple, un protocole interopérable de gestion de telles applications fonctionnant sur différents TEE [15].

³ Le « Core Root of Trust for Measurement » est le tout premier code du BIOS qui est exécuté dans le microprocesseur principal au moment de l’allumage. Il est souvent stocké dans un module de plateforme fiable.

_________________________

Ce post est une contribution individuelle de Fabien A. P. Petitcolas, spécialisé en sécurité informatique chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

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.

[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.