Dit artikel is ook beschikbaar in het Nederlands.

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.