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.

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.

Les données personnelles numériques constituent une source d’informations qui favorise l’innovation, le bien-être et la formulation de politiques. Ces données personnelles se trouvent dispersées dans de nombreuses organisations : l’une détient des données sur le cancer, une autre sur la consommation de médicaments et une autre encore sur les revenus. Dans la pratique, les données personnelles provenant de différentes organisations sont régulièrement regroupées afin de répondre à des questions spécifiques posées par des chercheurs et des décideurs politiques.

Les processus actuels garantissent que le respect de la vie privée dans ce contexte. Il s’agit malheureusement trop souvent d’une opération complexe, coûteuse et chronophage. En collaboration avec des universités de renommée internationale, Smals Research a donc travaillé à l’élaboration d’un prototype visant à simplifier considérablement ces processus à l’aide d’une cryptographie avancée.

Problématique basée sur un cas concret

Nous sommes partis d’une question de recherche concrète :

Les patients atteints de SEP (sclérose en plaques) sous traitement à base de molécules de tériflunomide ou d’alemtuzumab courent-ils un risque accru de cancer par rapport aux patients atteints de SEP traités avec d’autres médicaments ?

Pour répondre à cette question, simple en soi, il est nécessaire de croiser les données médicales relatives aux patients atteints de SEP provenant de deux organisations, à savoir le Registre belge du cancer (BCR) et l’Agence InterMutualiste (AIM).

Les deux organisations gèrent les données sous des pseudonymes distincts pour plus de confidentialité ; des codes uniques remplacent les numéros de registre national.

• Le BCR gère les données relatives au cancer concernant les personnes qui ont reçu un diagnostic de cancer. Le BCR ne sait pas quels enregistrements concernent des patients atteints de SEP.
• L’AIM dispose de données relatives aux médicaments prescrits et peut sélectionner les enregistrements des patients atteints de SEP.

Les chercheurs doivent avoir accès, dans un environnement sécurisé (SPE = Secure Processing Environment), aux données provenant du BCR et de l’AIM concernant tous les patients atteints de SEP. Les données relatives à un même patient mais issues de sources différentes doivent pouvoir être reliées entre elles sur la base d’un pseudonyme unique utilisé uniquement dans le cadre de cette question de recherche spécifique. Ceci est représenté dans l’illustration 1.

La question centrale est la suivante :

Comment le BCR peut-il fournir uniquement des enregistrements sur les patients atteints de SEP à l’environnement sécurisé sans savoir qui est atteint de SEP ou quels enregistrements qu’il gère concernent des patients atteints de SEP ?

Dans une approche classique, soit le BCR enverra trop d’informations à l’environnement sécurisé – notamment des données sur chaque patient atteint d’un cancer –, soit des informations seront divulguées au BCR – qui découvrira alors quels enregistrements concernent des patients atteints de SEP. Une dernière possibilité consiste à faire appel à une entité centrale de confiance qui, certes, aura connaissance des données à caractère personnel, mais à qui l’on peut faire confiance pour ne pas en faire un usage illicite.

Aucune de ces approches n’est idéale. Aujourd’hui, tant au niveau national qu’international, on fait appel à des intermédiaires centraux fortement réglementés ou on opte pour des solutions sur mesure coûteuses et lentes, dans lesquelles un nouveau flux est défini, validé et mis en œuvre pour chaque question de recherche afin de protéger au maximum la vie privée.

De plus, le chercheur a généralement besoin d’accéder aux données brutes, ce qui rend les solutions basées sur le secure multi-party computation inadaptées. 

Notre proposition de solution

Partons d’un scénario fictif dans lequel nous travaillons avec un intermédiaire de confiance et où, pour simplifier, l’AIM et le BCR ne gèrent pas les données à caractère personnel sous des pseudonymes, mais sous des numéros de registre national. L’AIM et le BCR envoient tous deux toutes les données potentiellement pertinentes à l’intermédiaire de confiance.

Le BCR envoie à l’intermédiaire les données identifiées relatives au cancer de tous les citoyens qui ont reçu un diagnostic de cancer, ce qui est bien sûr beaucoup plus que ce dont le chercheur a besoin. L’intermédiaire reçoit également toutes les données identifiées relatives aux médicaments prescrits aux patients atteints de SEP de l’AIM et sait ainsi, sur cette base.

L’intermédiaire reçoit également toutes les données identifiées relatives aux médicaments prescrits aux patients atteints de SEP de l’AIM. Il sait ainsi quels enregistrements fournis par le BCR concernent des patients atteints de SEP et donc quels enregistrements sont pertinents dans le cadre de la question de recherche. L’intermédiaire entreprend alors les étapes suivantes :

1. Il supprime les enregistrements non pertinents, c’est-à-dire les enregistrements concernant tous les citoyens qui ont reçu un diagnostic de cancer mais qui ne sont pas atteints de SEP.
2. Il fusionne les enregistrements concernant les mêmes citoyens et remplace les numéros de registre national par des pseudonymes uniques dans les enregistrements fusionnés.
3. Il envoie le résultat – uniquement les enregistrements fusionnés – vers l’environnement sécurisé.
4. Il supprime toutes les données reçues et dérivées.

Dans ce scénario, il n’y a pas de fuite involontaire de données vers les sources de données et l’environnement sécurisé ne reçoit que les données personnelles pseudonymisées minimales nécessaires.

Notre prototype fait exactement cela, mais sans l’intermédiaire de confiance. Le rôle de l’intermédiaire de confiance est distribué : les détenteurs de données – dans ce cas, l’AIM et le BCR – et un collecteur de données – dans ce cas, l’environnement sécurisé – interagissent pour assumer ensemble le rôle de l’intermédiaire de confiance. Les caractéristiques de sécurité mentionnées dans le paragraphe précédent sont conservées ; aucune information n’est donc divulguée involontairement aux détenteurs de données et le collecteur de données ne prend connaissance que des données pseudonymisées strictement nécessaires. La solution reste néanmoins pratique et efficace. Tout cela est possible grâce à une cryptographie avancée.

Comme nous l’avons mentionné précédemment, l’AIM et le BCR conservent les données sous des pseudonymes. Il existe des procédures permettant de les convertir de manière contrôlée en numéros de registre national. L’entité qui gère les données n’a jamais connaissance des registres nationaux et l’entité qui peut associer les pseudonymes aux numéros de registre national n’a à aucun moment accès aux données à caractère personnel proprement dites. Par souci de simplicité et pour la suite de cet article, nous partons du principe que les détenteurs de données connaissent les données identifiées par les numéros de registre national plutôt que par les pseudonymes. Notre concept peut également s’appliquer de manière sécurisée à des situations plus réalistes où ce n’est pas le cas.

Dans la pratique

Smals Research a développé ce concept en collaboration avec des partenaires universitaires. Initialement baptisé Oblivious Join, il a été renommé LetheLink dans le contexte universitaire. Lethe (Λήθη) est, dans la mythologie grecque, la déesse de l’oubli et l’un des cinq fleuves des enfers, au bord duquel les morts s’abreuvent pour oublier leur vie terrestre. Malgré cet oubli – ou plutôt ce manque de connaissance –, les entités en interaction parviennent à relier entre elles les données nécessaires. La convivialité et l’efficacité ont été au cœur du développement de ce concept.

Smals Research a développé un prototype démontrable qui donne déjà un aperçu du fonctionnement d’une solution entreprise-ready. L’utilisation du prototype est présentée dans l’illustration 2 et comprend les étapes suivantes :

1. Création d’un fichier JSON. Une organisation pouvant servir de point de contact (par exemple, la HDA ou la BCSS) reçoit une demande d’un chercheur. Lorsque la base juridique pour ce traitement de données existe, cette organisation établit un fichier JSON signé numériquement. Ce fichier JSON contient, sous une forme structurée, toutes les informations nécessaires à l’exécution correcte du protocole pour le croisement sécurisé des données des détenteurs de données : les données de connexion des clients des détenteurs de données et du collecteur de données, les paramètres cryptographiques, les clés publiques, les informations sur les données que chaque détenteur de données doit fournir, etc. Dans la pratique, on partira de templates à partir desquels on pourra dériver des fichiers JSON avec un minimum d’effort.
2. Distribution du fichier JSON. Ce fichier JSON est envoyé à la fois au collecteur de données et aux détenteurs de données. Tous vérifient la signature numérique. Toutes les entités concernées savent désormais comment exécuter le protocole et comment contacter les autres entités concernées en toute sécurité.
3. Téléchargement du client. Si ce n’est pas déjà fait, le collecteur de données et les détenteurs de données téléchargent le client LetheLink.
4. Création de fichiers CSV. Sur la base du fichier JSON, chaque détenteur de données génère un fichier CSV contenant toutes les données identifiées potentiellement pertinentes. Dans le scénario décrit précédemment, cela inclurait, pour le BCR, toutes les informations identifiées demandées concernant tous les citoyens ayant reçu un diagnostic de cancer. La création de ce fichier ne relève pas du champ d’application de LetheLink. Notre prototype ne prend en charge que les fichiers CSV, mais cette fonctionnalité peut être étendue.
5. Importation du client. Chaque participant fournit le fichier JSON à son client LetheLink local. Les détenteurs de données fournissent également leur fichier CSV généré localement à leur client. Les données sont livrées en clair et le client se charge du chiffrement.
6. Exécution du protocole. Le protocole est exécuté. Du côté du collecteur (SPE) des données, cela donne un fichier CSV qui ne contient que les données pseudonymisées et minimales nécessaires.

L’avantage de cette approche réside dans sa flexibilité d’utilisation. Certains détenteurs de données ne sont impliqués que très occasionnellement dans de tels projets croisés et tous les détenteurs de données ne disposent pas des mêmes ressources. Grâce à l’approche LetheLink, nul besoin de réaliser d’importants investissements ou préparatifs. Il suffit d’installer le client et de créer le fichier CSV.

L’illustration 3 présente un exemple fictif de tels fichiers CSV. En haut figurent des extraits de fichiers CSV que les détenteurs de données (trois dans le cas présent) fournissent chacun en entrée à leur client LetheLink. Au bas de l’illustration, un extrait du fichier CSV généré en sortie par le client du collecteur de données à la suite de l’exécution du protocole est présenté. Dans notre exemple fictif, le chercheur s’intéresse uniquement aux données transversales, c’est-à-dire aux données relatives aux 50 000 patients atteints de SEP qui ont reçu un diagnostic de cancer et présentent un profil de risque élevé. La personne dont le numéro de registre national est 60.01.05-045.05 appartient à ce groupe. Le collecteur de données voit les informations combinées sur ce citoyen, non pas sous ce numéro de registre national, mais sous le pseudonyme “153807…”.

Performance

Dans le cadre de la collaboration académique, la performance a été considérablement améliorée au cours de plusieurs itérations, tant au niveau de l’algorithme qu’au niveau de la mise en œuvre. Les principaux résultats des tests sont présentés dans le tableau 1. Quelques précisions :

• Les tests ont été effectués sur des machines virtuelles AWS EC2 r7i.8xlarge, avec 32 vCPU (Intel Xeon Platinum 8588C @ 3,2 GHz) et 256 Go de RAM.
• Une distinction est opérée entre une exécution sur un LAN à une vitesse de 1 Gbps et sur un WAN à une vitesse de 150 Mbps.
• La variable m représente le nombre d’enregistrements fournis par chacune des sources de données. Dans nos tests, elle est comprise entre un minimum de 2¹⁶= 65.536 et maximum de 2²⁴= 16.777.216. En réalité, le nombre d’enregistrements varie bien sûr selon la source de données, mais ces résultats fournissent déjà une limite supérieure.
• La variable κ (kappa) représente le niveau de sécurité computationnel. Une sécurité de 128 bits est suffisante aujourd’hui, mais une sécurité de 192 ou même de 256 bits est recommandée pour les données qui restent sensibles pendant une longue période. La variable λ (lambda) représente le paramètre de sécurité statique correspondant. 
• La variable n représente le nombre de détenteurs de données. Nous avons effectué des tests avec 3, 5 et 7 détenteurs de données, mais il n’y a aucune limitation technique pour un nombre beaucoup plus important.

Maintenant que nous savons comment interpréter ce tableau, nous constatons par exemple qu’il faut 25 secondes pour exécuter le protocole lorsque trois sources de données fournissent chacune 1 million (2²⁰) d’enregistrements sur un WAN. La quantité de données fournies a également un impact sur le temps d’exécution, mais pour cela, nous vous renvoyons au tableau 3 de notre publication commune. En résumé, tant le protocole que sa mise en œuvre sont particulièrement efficaces. Pour conclure, l’illustration 4 donne une idée générale de la réalisation des tests.

Relation avec le service de pseudonymisation à l’aveugle d’eHealth

Smals Research a développé le service de pseudonymisation à l’aveugle pour eHealth au cours de la période 2021-2022. Ce service permet de convertir les numéros de registre national en pseudonymes (codes uniques) et vice versa. Cette conversion est effectuée par un service de pseudonymisation qui est toutefois aveugle : il ne voit ni les numéros de registre national ni les pseudonymes. Ce service peut également être utilisé pour pseudonymiser et croiser des données. Quelles sont les différences ?

• Statut. Le service de pseudonymisation à l’aveugle est déjà en production, tandis que LetheLink n’est qu’un prototype.
• Fuite de données. Pour les projets de recoupement plus complexes, tels que ceux évoqués dans cet article, le service de pseudonymisation à l’aveugle ne pourra pas toujours empêcher les fuites de données. Il y aura notamment des fuites de données lorsqu’une source de données ne peut pas déterminer de manière autonome quels enregistrements sont pertinents pour répondre à la question de recherche. Selon le use case, il peut s’agir d’une fuite de données résiduelle acceptable ou de fuites de données plus substantielles, qui portent effectivement atteinte à la vie privée des personnes concernées. D’autre part, LetheLink présente des risques lorsqu’une seule entité est à la fois détentrice et collectrice de données.
• Rapidité. Le service de pseudonymisation à l’aveugle d’eHealth est certes très rapide – il peut effectuer des milliers de conversions par seconde -, mais LetheLink est ultra-rapide – il effectue des dizaines de milliers de conversions par seconde et, dans certaines circonstances, peut dépasser les cent mille. Tout dépendra bien sûr de l’infrastructure utilisée.
• Infrastructure. Le service de pseudonymisation à l’aveugle d’eHealth est dans tous les cas une entité centrale qui doit disposer d’une capacité suffisante. LetheLink, en revanche, est distribué, ce qui rend inutile une telle entité centrale : il suffit que chaque entité exécute le client LetheLink sur ses machines existantes. Il peut même s’agir d’ordinateurs portables classiques.
• Intégration. Afin d’utiliser le service de pseudonymisation à l’aveugle, une organisation doit intégrer une logique dans son application client. Nous savons par expérience que cela est relativement simple, mais cela reste néanmoins un investissement. LetheLink est un client autonome et ne nécessite donc aucun processus d’intégration.
• Types de demandes. Le service de pseudonymisation à l’aveugle d’eHealth peut traiter tant les demandes en batch que les demandes qui doivent être traitées en temps réel. LetheLink ne prend en charge que les traitements en batch.

Ce positionnement respectif de LetheLink et du service de pseudonymisation à l’aveugle d’eHealth devrait aider les organisations à déterminer la technologie la plus adaptée à leurs use cases.

Extensions

Un certain nombre d’extensions de LetheLink seront nécessaires pour pouvoir l’utiliser dans la pratique. Toutes les extensions proposées sont déjà conceptuellement possibles, mais ne sont pas toujours intégrées dans le prototype. Cela ne se fera que si une demande concrète est formulée.

• Taille minimale de l’ensemble de résultats. Si l’ensemble de résultats pseudonymisés pour le collecteur de données ne contient pas suffisamment d’enregistrements, il existe un risque pour la vie privée des personnes concernées et il est impossible de mener des recherches statistiquement pertinentes. C’est pourquoi le prototype prend déjà en charge la possibilité d’indiquer une taille minimale dans le fichier JSON.
• Réidentification contrôlée. Si les chercheurs constatent qu’un citoyen donné présente un risque élevé de développer une certaine maladie, il doit être possible d’en informer ce citoyen. De même, lorsqu’une enquête sur une fraude révèle une forte suspicion de fraude de la part de certains citoyens, il doit être possible d’en informer l’autorité compétente. Il doit donc être possible, dans des situations exceptionnelles, de vérifier l’identité d’un citoyen de manière contrôlée.
• Pseudonymes des détenteurs de données. Comme indiqué précédemment dans cet article, les détenteurs de données n’ont souvent pas eux-mêmes accès au numéro de registre national des citoyens dont ils gèrent les données. Dans de tels cas également, le protocole doit pouvoir être mis en œuvre efficacement.
• Divulgation sélective. Actuellement, le prototype se concentre sur des moyennes ; ce n’est que si tous les détenteurs de données fournissent des enregistrements sur un même citoyen que l’enregistrement composite devient visible pour le collecteur de données. Dans la pratique, une plus grande flexibilité est requise, comme l’indique l’illustration 5. Dans le cas d’utilisation présenté en introduction de cet article, le chercheur avait besoin de données pseudonymisées sur tous les patients atteints de SEP, alors que notre prototype ne fournit actuellement que des données pseudonymisées sur tous les patients atteints de SEP ayant également reçu un diagnostic de cancer.
• Transfert multi-batch. Dans certains cas, les détenteurs de données doivent fournir des données à plusieurs reprises au collecteur de données, par exemple dans le cadre d’une étude longitudinale. Le collecteur de données doit être capable de relier entre elles les données relatives à un même citoyen au fil du temps.
• Communication simplifiée. Dans le prototype, tous les détenteurs de données concernés communiquent entre eux, puis envoient individuellement des données cryptées au collecteur de données. Dans un protocole adapté, les détenteurs de données n’échangeraient des données qu’avec et via le collecteur de données, par exemple via une interface REST. Dans la pratique, cette approche est plus souhaitable.

Veuillez nous faire part de toute autre extension utile que vous pourriez envisager.

Références

Le concept initial ainsi que le prototype et les tests de performance ont été réalisés par Smals Research. Les partenaires universitaires, notamment le groupe COSIC et le groupe DistriNet de la KU Leuven, ainsi que le groupe CrySP de l’université de Waterloo au Canada, se sont concentrés sur l’élaboration théorique. Cela a donné lieu à deux publications en 2025 :

• Publication de Springer :Privacy-By-Design in the Belgian Public Sector Ce document accessible traite de deux solutions innovantes conçues par Smals Research pour la pseudonymisation et le croisement des données à caractère personnel : Lethelink et le service de pseudonymisation à l’aveugle d’eHealth.
• Publication de Springer :Privacy-By-Design in the Belgian Public Sector Ce document accessible traite de deux solutions innovantes conçues par Smals Research pour la pseudonymisation et le croisement des données à caractère personnel : Lethelink et le service de pseudonymisation à l’aveugle d’eHealth.

Je vous invite également à consulter ma contribution à la conférence Devoxx et mon webinaire de 2024 intitulé “Privacy in Practice with Smart Pseudonymisation”. LetheLink/Oblivious Join est l’une des trois techniques de pseudonymisation que j’y aborde.

Enfin, des slides sont disponibles pour ceux qui souhaitent se faire rapidement une idée intuitive des principes de base de l’Oblivious Join. Les notes correspondantes fournissent des explications supplémentaires.

Conclusion

L’utilisation secondaire des données à caractère personnel peut nous fournir de nombreuses informations qui soutiennent l’élaboration des politiques et stimulent la recherche scientifique. Pour exploiter ces informations, les données provenant de différentes sources doivent pouvoir être collectées de manière efficace, dans le respect de la vie privée. Cela signifie que seules les données à caractère personnel nécessaires sont pseudonymisées et croisées et que les autres entités participant à ce processus n’ont pas accès aux données à caractère personnel. Dans la pratique, cela était loin d’être évident.

En collaboration avec des universités de renommée internationale, Smals Research a donc élaboré un concept qui, grâce à une cryptographie avancée, permet de le faire de manière efficace. Un prototype démontrable a également été construit, ce qui constitue une première étape vers une mise en œuvre effective dans la pratique.

Au cours des dernières années, nous avons rencontré de nombreuses entités. Tout le monde considère qu’il s’agit d’un outil très utile, mais nous ne disposons pour l’instant pas de l’engagement de nos partenaires pour le mettre en pratique.

Le défi principal aujourd’hui est donc de rendre cette solution prête à la production. N’hésitez pas à nous contacter si cette solution vous intéresse et si vous souhaitez éventuellement y contribuer.

Digitale persoonsgegevens vormen binnen een overheidscontext een bron van inzichten die innovatie, welzijn en beleidsvorming ten goede komen. Die persoonsgegevens zijn over heel wat organisaties verspreid; de ene organisatie heeft informatie over kanker, de andere over medicijngebruik en nog een andere bewaart inkomensgegevens. In de praktijk worden geregeld persoonsgegevens afkomstig van verschillende organisaties samengevoegd om op specifieke vragen van onderzoekers en beleidsmakers te kunnen antwoorden.

De huidige processen garanderen dat dit met respect voor de privacy gebeurt. Helaas is het – mede daardoor – ook te vaak een complexe, dure en tijdrovende aangelegenheid. In samenwerking met internationaal toonaangevende universiteiten werkte Smals Research daarom aan een prototype om met behulp van geavanceerde cryptografie deze processen aanzienlijk te vereenvoudigen.

Probleemstellig op basis van concrete case

We vertrokken van een concrete onderzoeksvraag:

Lopen MS-patiënten die medicijnen met de moleculen teriflunomide of alemtuzumab gebruiken een verhoogd risico op kanker in vergelijking met MS-patiënten die met andere medicijnen worden behandeld?

Om die – op zich eenvoudige – vraag te kunnen beantwoorden moeten medische gegevens over MS-patiënten afkomstig van twee organisaties, met name het Belgisch Kankerregister (BCR) en het InterMutualistisch Agentschap (IMA) gekruist worden.

Beide organisaties beheren de gegevens onder aparte pseudoniemen voor meer privacy; unieke codes ter vervanging van rijksregisternummers.

• Het BCR beheert gegevens met betrekking tot kanker over mensen die een kankerdiagnose kregen. Het BCR weet niet welke records betrekking hebben op MS-patiënten.
• Het IMA kent gegevens m.b.t. voorgeschreven medicijnen en kan de records selecteren van MS-patiënten.

De onderzoekers dienen in een beveiligde omgeving (SPE = Secure Processing Environment) toegang te krijgen tot gegevens afkomstig van het BCR en het IMA, over alle MS-patiënten. Gegevens over dezelfde patiënt maar afkomstig van verschillende bronnen moeten aan elkaar gekoppeld kunnen worden op basis van een uniek pseudoniem dat enkel gebruikt wordt in het kader van die specifieke onderzoeksvraag. Dit wordt geïllustreerd in figuur 1.

De centrale vraag luidt als volgt:

Hoe kan het BCR enkel records over MS-patiënten aanleveren aan de beveiligde omgeving zonder te weten te komen wie MS heeft of welke records die het beheert betrekking hebben op MS-patiënten?

In een klassieke benadering zal ofwel het BCR te veel informatie naar de beveiligde omgeving sturen – met name gegevens over elke kankerpatiënt – ofwel lekt er informatie naar het BCR – waarbij het BCR te weten komt welke records betrekking hebben op MS-patiënten. Een laatste mogelijkheid is het inschakelen van een vertrouwde centrale partij die weliswaar persoonsgegevens te weten komt, maar vertrouwd wordt daar niets onrechtmatigs mee te doen.

Geen van deze aanpakken is ideaal. Vandaag wordt in binnen- en buitenland ofwel beroep gedaan op – sterk gereguleerde – centrale partijen ofwel is duur en traag maatwerk vereist, waarbij voor elke onderzoeksvraag een nieuwe flow uitgetekend, gevalideerd en uitgevoerd wordt om de privacy maximaal te beschermen.

We geven nog mee dat de onderzoeker doorgaans toegang nodig heeft tot de ruwe data, waardoor oplossingen gebaseerd op secure multi-party computation ongeschikt zijn. 

Ons voorstel tot oplossing

Laat ons even vertrekken van een fictief scenario waarbij gewerkt wordt met een vertrouwde intermediaire partij en het – voor de eenvoud – IMA en BCR de persoonsgegevens niet onder pseudoniemen beheren, maar onder rijksregisternummers. IMA en BCR sturen beiden alle gegevens die potentieel relevant zijn naar de vertrouwde tussenpartij.

Het BCR stuurt naar de intermediaire partij geïdentificeerde kankergegevens over alle burgers die de kankerdiagnose kregen, wat uiteraard veel meer is dan nodig voor de onderzoeker. De intermediaire partij krijgt ook alle geïdentificeerde medicatiegegevens over MS-patiënten van het IMA en weet op basis daarvan welke door het BCR aangeleverde records betrekking hebben op MS-patiënten en dus relevant zijn in het kader van de onderzoeksvraag. De intermediaire partij voert nu de volgende stappen uit:

1. Het verwijdert de niet relevante records, dus de records over alle burgers die de kankerdiagnose kregen maar geen MS hebben.
2. Het voegt records over dezelfde burgers samen en vervangt in de samengevoegde records de rijksregisternummers door unieke pseudoniemen
3. Het stuurt het resultaat – enkel samengevoegde records – naar de beveiligde omgeving.
4. Het verwijdert alle ontvangen en afgeleide gegevens.

In dit scenario zijn er geen onbedoelde datalekken naar de databronnen en ontvangt de beveiligde omgeving enkel de minimaal noodzakelijke, gepseudonimiseerde persoonsgegevens.

Ons prototype doet exact dit, maar dan zonder de vertrouwde partij. De rol van de vertrouwde partij wordt gedistribueerd: Data holders – in dit geval het IMA en het BCR – en een data collector – in dit geval de beveiligde omgeving – interageren met elkaar om samen de rol van de vertrouwde partij over te nemen. Daarbij worden de veiligheidseigenschappen uit de vorige paragraaf behouden; er lekt dus niet onbedoeld informatie naar de data holders en de data collector komt enkel de minimaal noodzakelijke gepseudonimiseerde gegevens te weten. De oplossing blijft niettemin praktisch en efficiënt. Dit alles is mogelijk dankzij geavanceerde cryptografie.

We schreven eerder dat het IMA en het BCR de data bewaren onder pseudoniemen. Er bestaan procedures om die op een gecontroleerde wijze om te zetten in rijksregisternummers. De partij die data beheert komt daarbij nooit rijksregisternummers te weten en de partij die pseudoniemen kan koppelen aan rijksregisternummers heeft op geen enkel moment toegang tot de eigenlijke persoonsgegevens. Om redenen van eenvoud gaan we er de rest van dit artikel vanuit dat de data holders de data kennen onder rijksregisternummers. Ons concept kan ook op een veilige manier overweg weg met de meer realistische situaties waarbij dit niet het geval is.

In de praktijk

Smals Research werkte samen met academische partners het concept uit. Initieel luisterde het naar de naam Oblivious Join, maar in academische context werd het herdoopt naar LetheLink. Lethe (Λήθη) is in de Griekse mythologie de godin van de vergetelheid en een van de vijf rivieren in de onderwereld, waaruit de doden drinken om hun aardse leven te vergeten. Ondanks die vergetelheid – of beter, gebrek aan kennis – slagen de interagerende partijen er toch in de noodzakelijke data aan elkaar te linken. Centraal in de ontwikkeling van dit concept stonden gebruiksvriendelijkheid en efficiëntie.

Smals Research heeft een demonstreerbaar prototype uitgewerkt dat alvast een zicht geeft op hoe een enterprise-ready oplossing zou kunnen werken. Het gebruik van het prototype wordt geïllustreerd in figuur 2 en bestaat uit de volgende stappen:

1. Creatie JSON-bestand. Een organisatie die als aanspreekpunt kan dienen (vb, de HDA of de KSZ) krijgt een vraag binnen van een onderzoeker. Wanneer de juridische basis voor deze gegevensverwerking er is, stelt deze organisatie een digitaal ondertekend JSON-bestand op. Dat bestand bevat in een gestructureerde vorm alle informatie om het protocol voor het beveiligd kruisen van de gegevens van de data holders op een correcte manier uit te kunnen voeren: connectiegegevens van de clients van zowel data holders als de data collector, de cryptografische parameters, publieke sleutels, informatie over welke data holder welke data moet aanleveren, etc. In de praktijk zal men vertrekken van templates, van waaruit met een minimale inspanning JSON-bestanden afgeleid kunnen worden.
2. Distributie JSON-bestand. Dit JSON-bestand wordt bezorgd aan zowel de data collector als de data holders. Allen verifiëren de digitale handtekening. Alle betrokken partijen weten nu hoe ze het protocol moeten uitvoeren en hoe ze de andere betrokken partijen veilig kunnen contacteren.
3. Downloaden client. Indien dit nog niet gebeurd is, downloaden de data collector en data holders de LetheLink client.
4. Creatie CSV-bestanden. Op basis van het JSON-bestand genereert elke data holder een CSV-bestand die alle potentieel relevante geïdentificeerde data bevat. In de eerder geschetste use case zou dit voor het SKR alle gevraagde geïdentificeerde informatie bevatten over alle burgers die de kankerdiagnose kregen. De creatie van dit bestand valt buiten de scope van LetheLink. In ons prototype worden enkel CSV-bestanden ondersteund, maar dit kan uitgebreid worden.
5. Invoer client. Elke participant geeft het JSON-bestand als invoer aan zijn lokale LetheLink client. De data holders geven daarnaast ook hun lokaal gegenereerde CSV-bestand aan hun client. Data worden in klaar aangeleverd en de client neemt de versleuteling op zich.
6. Uitvoering protocol. Het protocol wordt uitgevoerd. Dit resulteert aan de kant van de data collector (SPE) in een CSV bestand dat enkel de gepseudonimiseerde, minimaal noodzakelijke gegevens bevat.  

Het voordeel van deze benadering is de flexibele inzetbaarheid. Er zijn data holders die maar heel af en toe in dergelijke kruisingsprojecten betrokken zijn en niet alle data holders beschikken over evenveel middelen. Dankzij de LetheLink benadering zijn geen grote investeringen of voorbereidingen nodig. De installatie van de client en creatie van de CSV file volstaan.

Figuur 3 geeft een fictief voorbeeld van dergelijke CSV bestanden. Bovenaan staan extracten van CSV bestanden  die de – in dit geval drie – data holders elk als invoer aan hun LetheLink client geven. Onderaan de figuur is een extract te zien van het CSV bestand dat de client van de data collector als output genereert als resultaat van de protocoluitvoering. In ons fictieve voorbeeld is de onderzoeker enkel geïnteresseerd in data in de doorsnede; dus in data over de 50 000 MS-patiënten die de kankerdiagnose kregen en een hoog risicoprofiel hebben. De persoon met rijksregisternummer 60.01.05-045.05 behoort tot die groep. De data collector ziet de gecombineerde informatie over deze burger, niet onder dit rijksregisternummer, maar onder het pseudoniem “153807…”.

Performantie

In het kader van de academische samenwerking werd de performantie in meerdere iteraties grondig verbeterd, zowel op het niveau van het algoritme, als op het niveau van de implementatie. De voornaamste testresultaten zijn weergegeven in tabel 1. Een beetje duiding:

• De testen werden uitgevoerd op op AWS EC2 r7i.8xlarge VMs, met 32 vCPU’s (Intel Xeon Platinum 8588C @ 3.2 GHz) en 256 GB RAM.
• Er wordt een onderscheid gemaakt tussen een uitvoering op een LAN aan een snelheid van 1 Gbps en op een WAN aan een snelheid van 150 Mbps.
• De variable m representeert het aantal records dat door elk van de databronnen meegegeven wordt. Het is in onze testen minimaal 2¹⁶ = 65 536 en maximaal 2²⁴ = 16 777 216. In werkelijkheid is het aantal records uiteraard verschillend per databron, maar deze resultaten geven alvast een bovengrens.
• De variable κ (kappa) representeert het computationele veiligheidsniveau. 128 bit security volstaat vandaag, al wordt voor data die lange tijd gevoelig blijft toch 192 of zelfs 256 bit security aanbevolen. De variable λ (lambda) representeert de corresponderende statistische veiligheidsparameter. 
• De variabele n representeert het aantal data holders. We deden testen met 3, 5 en 7 data holders, maar er zijn geen technische beperkingen voor een veel groter aantal.

Nu we weten hoe deze tabel te interpreteren, zien we dat er bijvoorbeeld 25 seconden nodig zijn om het protocol uit te voeren waarbij drie databronnen elk 1 miljoen (2²⁰) records aanleveren over een WAN, met een veiligheidsniveau van 256 bits. De hoeveelheid meegeleverde data heeft eveneens impact op de uitvoeringstijd, maar daarvoor verwijzen we naar tabel 3 in onze gemeenschappelijke publicatie. Samengevat zijn zowel het protocol als de implementatie ervan bijzonder efficiënt. Figuur 4 geeft, ter afronding, een sfeerbeeld van het uitvoeren van de testen.

Verhouding tot eHealths Blinde Pseudonimiseringsdienst

Smals Research ontwikkelde in de periode 2021-2022 de blinde pseudonimiseringsdienst voor eHealth. Daarmee kunnen rijksregisternummers omgezet worden in pseudoniemen – unieke codes – en vice versa. Die omzetting gebeurt door een pseudonimiseringsdienst die echter blind is: het ziet rijksregisternummers noch pseudoniemen. Deze dienst kan eveneens gebruikt worden om gegevens te pseudonimiseren én te kruisen. Wat zijn dan de verschillen?

• Status. De blinde pseudonimiseringsdienst staat reeds in productie, terwijl LetheLink slechts een prototype is.
• Datalekkage. Voor complexere kruisingsprojecten, zoals diegene waar in dit artikel van vertrokken wordt, zal de blinde pseudonimiseringsdienst niet altijd kunnen verhinderen dat er datalekken optreden. Met name zal er sprake zijn van gegevenslekkage wanneer een databron niet autonoom kan bepalen welke records relevant zijn om de onderzoeksvraag te kunnen beantwoorden. Afhankelijk van de use case kan dit gaan om een aanvaardbaar residuele datalekkage, of het kan gaan over meer substantiële datalekken, die effectief de privacy van betrokkenen aantasten. Anderzijds ontstaan er bij LetheLink risico’s wanneer één entiteit zowel data holder als data collector is.
• Snelheid. eHealths blinde pseudonimiseringsdienst is weliswaar erg snel – het kan duizenden conversies per seconde aan -, maar LetheLink is bliksemsnel – het doet tienduizenden conversies per seconde en onder bepaalde omstandigheden kan het over de honderduizend gaan. Veel zal natuurlijk afhangen van de gebruikte infrastructuur.
• Infrastructuur. eHealths blinde pseudonimiseringsdienst is sowieso een centrale entiteit die over voldoende capaciteit moet beschikken. LetheLink daarentegen is gedistribueerd, waardoor een dergelijke centrale partij niet langer vereist is: het volstaat dat elke partij de LetheLink client draait op zijn bestaande machines. Dat kunnen zelfs reguliere laptops zijn.
• Integratie. Om gebruik te maken van de blinde pseudonimiseringsdienst moet een organisatie logica integreren in zijn clienttoepassing. Uit ervaring weten we dat dit gelukkig relatief eenvoudig is, maar het blijft niettemin een investering. LetheLink is een standalone client en dus is er geen integratietraject nodig.
• Type aanvragen. eHealths blinde pseudonimiseringsdienst kan overweg met zowel batch aanvragen als met aanvragen die in real-time afgehandeld moeten worden. LetheLink kan enkel overweg met verwerkingen in batch.

Deze positionering van LetheLink en eHealths blinde pseudonimiseringsdienst ten opzichte van elkaar zou organisaties moeten helpen om te bepalen welke technologie het meest geschikt is voor hun use cases.

Uitbreidingen

Er zullen een aantal uitbreidingen van LetheLink nodig zijn om het ook daadwerkelijk in de praktijk te kunnen inzetten. Alle voorgestelde uitbreidingen zijn conceptueel alvast mogelijk, maar niet steeds in het prototype geïntegreerd. Dit zal enkel gebeuren indien er een concrete vraag komt.

• Minimale grootte resultaatset. Indien de gepseudonimiseerde resultaatset voor de data collector onvoldoende records bevat is er een risico voor de privacy van de betrokkenen en is het onmogelijk om statistisch relevant onderzoek te doen. Daarom ondersteunt het prototype vandaag reeds de mogelijkheid om een minimale grootte mee te geven in het JSON bestand.
• Gecontroleerde re-identificatie. Indien onderzoekers merken dat een bepaalde burger een hoog risico heeft om een bepaalde ziekte te ontwikkelen, moet het mogelijk zijn deze burger daarvan op de hoogte te stellen. Ook wanneer bij een fraudeonderzoek er een sterk vermoeden van fraude is door bepaalde burgers, moet het mogelijk zijn de bevoegde instantie op de hoogte te brengen. Er moet dus in een mogelijkheid voorzien worden om in uitzonderlijke situaties op gecontroleerde wijze de identiteit van een burger te achterhalen.
• Data holder pseudoniemen. Zoals eerder in dit artikel aangegeven, hebben data holders vaak zelf geen toegang tot het rijksregisternummer van de burgers waarover ze data beheren. Ook in dergelijk gevallen moet het protocol efficiënt uit te voeren zijn.
• Selectieve prijsgave. Momenteel focust het prototype op doorsnedes; enkel indien alle data holders records over eenzelfde burger aanleveren, wordt het samengestelde record zichtbaar voor de data collector. In de praktijk is er meer flexibiliteit nodig, zoals aangegeven in figuur 5. In de use case waarmee we dit artikel begonnen had de onderzoeker gepseudonimiseerde gegevens nodig over alle MS-patiënten, terwijl ons protoype op dit moment enkel gepseudonimiseerde gegevens aanlevert over alle MS-patiënten die ook de kankerdiagnose kregen. 
• Multi-batch transfer. In sommige gevallen moeten data holders meermaals data aanleveren aan de data collector, bijvoorbeeld in het kader van longitudinaal onderzoek. De data collector moet in staat zijn doorheen de tijd data over eenzelfde burger aan elkaar te koppelen.
• Vereenvoudigde communicatie. In het prototype communiceren alle betrokken data holders met elkaar, om vervolgens individueel vercijferde data naar de data collector te sturen. In een aangepast protocol zouden data holders enkel data uitwisselen met en via de data collector, bijvoorbeeld via een REST-interface. In de praktijk is dit de meer wenselijke benadering.

Laat ons weten indien u andere nuttige uitbreidingen ziet.

Referenties

Het initiële concept alsook het prototype en de performantietesten werden uitgevoerd door Smals Research. De academische partners, met name de COSIC groep en de DistriNet groep aan de KU Leuven, alsook de CrySP groep aan Waterloo University in Canada, focusten zich op de theoretische uitwerking. Dit resulteerde in 2025 in twee publicaties:

• Springer publicatie – Privacy-By-Design in the Belgian Public Sector. Dit toegankelijke document bespreekt twee innovatieve oplossingen bedacht door Smals Research voor het pseudonimiseren en kruisen van persoonsgegevens; Lethelink en eHealths blinde pseudonimiseringsdienst.
• Arxiv publicatie – Labeled Delegated PSI and its Applications in the Public Sector.  Dit academisch artikel beschijft formeel LetheLink, bewijst de correctheid, bespreekt de performantie en positioneert het werkt t.o.v. bestaand academisch werk.

Daarnaast verwijs ik graag naar mijn Devoxx talk en Webinar uit 2024 getiteld “Privacy in Practice with Smart Pseudonymisation”. LetheLink/Oblivious Join is één van de drie pseudonimiseringstechnieken die ik er bespreek.

Ten slotte zijn er nog slides beschikbaar voor diegenen die graag snel een intuïtief beeld ontwikkelen over de basisprincipes van Oblivious Join. De bijhorende nota’s geven extra uitleg.

Conclusie

Secundair gebruik van persoonsgegevens kan ons heel wat inzichten verschaffen die beleidsvorming ondersteunen en wetenschappelijk onderzoek stimuleren. Om die inzichten te ontsluiten moeten gegevens afkomstig van verschillende bronnen op een efficiënte wijze verzameld kunnen worden, met respect voor de privacy. Dat wil zeggen dat enkel de noodzakelijke persoonsgegevens gepseudonimiseerd en gekruist worden en dat participerende partijen in dit proces geen persoonsgegevens te weten komen. Dit was in de praktijk verre van evident.

In samenwerking met internationaal toonaangevende universiteiten werkte Smals Research daarom een concept uit dat met behulp van geavanceerde cryptografie dit op een efficiënte wijze mogelijk maakt. Verder werd een demonstreerbaar prototype gebouwd, wat een eerste stap is om dit effectief in de praktijk te kunnen gaan inzetten.

We hebben de voorbije jaren met heel wat partijen samen gezeten. Iedereen vindt het een zeer nuttige tool, maar vooralsnog missen we de commitment van onze partners om dit in de praktijk om te zetten.

De voornaamste uitdaging vandaag is dan ook het productieklaar krijgen van deze oplossing. Neem dus zeker contact met ons op indien u interesse heeft in deze oplossing en eventueel mee uw schouders hieronder wil zetten.

Where is Wally is een bekend spel waarbij een specifiek personage – genaamd Wally – gezocht dient te worden in een tekening met veel details en andere personages. Hoe kan Paula (de prover ofwel de bewijzer) aan Victor (de verifier ofwel de verifieerder) bewijzen dat ze weet waar Wally is, zonder details over zijn positie in de figuur weer te geven? Paula kan een ondoorzichtige plaat nemen die zowel in de hoogte als in de breedte dubbel zo groot is als de figuur waarin Wally verborgen is. In het midden van de plaat is een gaatje ter grootte van Wally. Door de plaat zo te positioneren dat het gaatje enkel Wally toont, bewijst Paula aan Victor dat ze Wally gelokaliseerd heeft, zonder informatie over Wally’s locatie prijs te geven.

Dit is een voorbeeld van een zero-knowledge proof, of kortweg ZKP, wat een partij toelaat een bewering aan een andere partij te bewijzen zonder verder details over die bewering prijs te geven. Strikt genomen is het Wally-voorbeeld niet helemaal zero-knowledge, gezien ook informatie over de lichaamshouding en gezichtsexpressie van Wally prijsgegeven worden, wat kan helpen om hem te vinden.

Een ander voorbeeld, waarvoor een proof of concept gebouwd werd, bewijst aan het publiek dat het DNA van een presidentskandidaat niet voorkomt in een forensische DNA-database. De politie voert publiek beschikbare code uit op inputs die verborgen blijven voor het publiek: de DNA-database en het DNA-profiel van de presidentskandidaat. De output is “geen match”, “gedeeltelijke match” of “volledige match”. Het publiek – althans de cryptografen onder hen – is ervan overtuigd dat het resultaat de correcte uitvoering is van de code op de confidentiële inputs. De bewering die hier bewezen wordt m.b.v. een ZKP heeft betrekking tot de integriteit van berekeningen op confidentiële data.

Anonieme credentials, die in een vorig artikel besproken werden, laten daarentegen burgers toe om  eigenschappen over henzelf selectief te bewijzen, zoals meerderjarigheid, nationaliteit of bezit van een geldig rijbewijs. Anonieme credentials maken intensief gebruik van ZKPs. Ook ZKP’s op zich kunnen, zoals we verder in dit artikel zullen zien, aangewend worden voor selectieve prijsgave van persoonsgegevens.

Samengevat stellen ZKPs een partij, de prover, in staat om zonder een vertrouwde tussenpartij, aan een andere partij, de verifier, beweringen te bewijzen. Deze beweringen kunnen betrekking hebben op berekeningen op confidentiële data, maar ook op eigenschappen (attributen) van een burger (of zelfs een dier of object).

Formeel worden drie criteria gedefinieerd waar een ZKP aan moet voldoen:

1. 1. Volledigheid (completeness). Als de bewering waar is, dan zal een verifier hiervan overtuigd worden.
   2. Degelijkheid (soundness). Als de bewering onwaar is, dan kan de prover de verifier in de praktijk niet ten onrechte overtuigen van het tegendeel.
   3. Nulkennis (Zero-knowledge). Als de bewering waar is, dan leert de verifier niets meer dan die bewering.

Dit artikel bespreekt twee belangrijke use cases voor ZKPs: het verbeteren van schaalbaarheid en privacy van blockchaintoepassingen, en privacy-vriendelijk identiteitsbeheer van burgers.

Blockchain

In de literatuur werden reeds heel wat potentiële use cases gedefinieerd voor ZKPs, hoewel vandaag maar een beperkt aantal zich ook in de praktijk gerealiseerd heeft. Eén van de grote toepassingsdomeinen is Blockchain en virtuele munten (cryptocurrencies).

ZKPs worden er gebruikt om de privacy van transacties te verbeteren. In Bitcoin en enkele andere virtuele munten zijn voor elke transactie zowel het adres (het rekeningnummer) van de zender, het adres van de ontvanger, en het getransfereerd bedrag voor iedereen zichtbaar; alles wordt op de blockchain gepubliceerd. Dit is verre van ideaal vanuit privacy-perspectief.

De virtuele munt Zcash geeft gebruikers de mogelijkheid om m.b.v. ZKPs die drie zaken te verbergen. Daarvoor gebruikt het zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge), die in 2012 ontwikkeld werden en voor het eerst toegepast werden in Zcash. De S in zk-SNARKs staat voor ‘succint’, oftewel ‘beknopt’. ZKPs in Zcash kunnen ‘binnen enkele milliseconden worden geverifieerd en zijn slechts een paar honderd bytes lang’.

Naast privacy worden ZKP ook gebruikt om de schaalbaarheid van blockchains te verhogen. De beperkte capaciteit van blockchains stimuleerde de community om intensief op zoek te gaan naar manieren om beter te schalen, zonder aan veiligheid of snelheid in te boeten. Betere schaalbaarheid betekent dat een transactie minder resources vereist en dus dat de transactiekosten verlagen. Een van de meest veelbelovende aanpakken zijn zk-rollups, die op de Ethereum blockchain gebruikt worden door onder meer Starknet, ZKsync en Polygon. In plaats van elke transactie afzonderlijk op de blockchain te plaatsen, worden ze off-chain gebundeld, uitgevoerd, en wordt enkel het resultaat, samen met een ZKP van correcte uitvoering, op de blockchain geplaatst. Er worden daarbij minder bytes naar de blockchain geschreven, en het verifiëren van het ZKP gaat sneller dan het verifiëren van alle individuele transacties. Er is dus zowel minder opslag als rekenkracht vereist.

Daarnaast wordt gewerkt aan ZKP om te bewijzen dat een smart contract (code) correct uitgevoerd werd. Ook hier is de reden schaalbaarheid; telkens wanneer een functie van een smart contract (code op de blockchain) vandaag aangeroepen wordt, voert elke blockchain node exact dezelfde code uit. Het idee is dat één node het smart contract uitvoert en de correcte uitvoering bewijst. De andere nodes verifiëren het bewijs. Indien dit efficiënter kan dan het uitvoeren van een smart contract, verhogen we de schaalbaarheid.

Identiteitsbeheer

Met behulp van anonieme credentials – die beroep doen op ZKPs – kan een burger selectief eigenschappen over haarzelf prijsgeven, bijvoorbeeld meerderjarigheid. De realiteit is helaas dat anonieme credentials door geen enkel land of regio op grote schaal geadopteerd werden in identiteitsdocumenten. Recenter onderzoek verlegt daarom de focus: op basis van een bestaand identiteitsdocument wordt een ZKP gegenereerd. Recent academisch werkt focuste op het Amerikaanse paspoort en rijbewijs.

De VUB publiceerde eerder dit jaar onderzoek dat zich richtte op de Belgische identiteitskaart. Het onderzoek gebeurde in het kader van het door Innoviris gefinancierde SDM project. Het is een veelbelovend werk dat weliswaar nog een aantal uitdagingen voor de boeg heeft. Een eerste is de lage efficiëntie; het duurt op een laptop 22 seconden om een bewijs te genereren, wat verder zal toenemen op een smartphone. Een tweede uitdaging is revokatie; wanneer een eID kaart verloren gaat of gestolen wordt en als gevolg daarvan de certificaten op de kaart gerevokeerd worden, mag men niet langer in staat zijn ZKPs te genereren.  

De VUB wil nog een stap verder gaan; ZKPs gebruiken om aan te tonen dat een burger bepaalde rechten heeft, zonder verdere persoonsgegevens prijs te geven. Zo zou een burger in de toekomst kunnen bewijzen aan de voorwaarden van budgethuren te voldoen, zonder verdere details over het waarom prijs te geven.

Itsme kondigde recent haar Itsme Qualify aan, waarbij selectief persoonsgegevens prijsgegeven worden m.b.v. ZKPs. Momenteel wordt enkel leeftijdsverificatie ondersteund, maar Itsme is van plan dit verder uit te breiden. Uw auteur kon helaas geen publiek beschikbare details vinden over de werking en slaagde er niet in meer informatie van Itsme te bekomen. Hopelijk is dit gebrek aan transparantie slechts een tijdelijk gegeven, want ZKPs, net zoals alle andere cryptografie, is het veiligst indien alle details publiek zijn en door experten gevalideerd kunnen worden.

Ten slotte geven we nog mee dat er oplossingen zijn voor identiteitsbeheer die blockchain en ZKPs combineren. Privado ID is een van de meer zichtbare initiatieven en was tot voor kort gekend onder da naam Polygon ID. Een issuer bevestigt er persoonlijke attributen van een prover – waaronder bijvoorbeeld de geboortedatum – door een speciaal gevormde hashwaarde van de set van attributen op een blockchain netwerk zoals Ethereum te plaatsen. De prover kan nu aan de hand daarvan aan een verifier selectief persoonsgegevens – zoals meerderjarigheid – over haarzelf bewijzen. Bemerk dat alle ZKPs die dezelfde hashwaarde als basis gebruiken aan elkaar gelinkt kunnen worden. 

Kwantumresistentie

Zoals reeds uitvoerig in eerdere Smals Research artikels toegelicht, is er het gevaar dat krachtige kwantumcomputers in de toekomst moderne publieke sleutelcryptografie zouden kunnen breken.

Technologieën zoals zk-SNARKs en Bulletproofs, die toelaten de correctheid van berekeningen te bewijzen, zijn alvast niet kwantumresistent. Onder meer daarom werden in 2018 zk-STARKs ( Zero-Knowledge Scalable Transparent Arguments of Knowledge) geïntroduceerd. Zoals geïllustreerd in onderstaande figuur, blijft de computationele efficiëntie hoog, maar worden de bewijzen wel vele malen groter. Niettemin worden ze reeds gebruikt voor schaalbaarheid en privacy door onder meer StarkNet and StarkEx, wat beiden schalingsoplossingen voor Ethereum zijn.

Vergelijking van drie ZKP oplossingen voor het bewijzen van berekeningen (bron)

Kwantumresistente ZKPs voor berekeningen zijn dus mogelijk, al worden de bewijzen een pak groter. Hun uptake door de blockchain community blijft vooralsnog beperkt; zk-SNARKs zijn nog steeds de dominante ZKP-technologie in blockchain context. Ook het werk van de VUB rond identiteitsbeheer maakt vandaag gebruik van zk-SNARKs.

Conclusie

Zero-knowledge proofs bestaan al enkele decennia en er is sindsdien heel wat onderzoek en ontwikkeling gebeurd. We identificeerden in dit artikel de twee voornaamste use cases:

• Privacy en schaalbaarheid op blockchain netwerken. ZKP technologie laat toe te bewijzen dat een berekening op confidentiële data correct uitgevoerd is. Dit kan relatief snel gebeuren en helpt om blockchainnetwerken schaalbaarder te maken. Hoewel het in theorie ook buiten blockchain toegepast kan worden, zien we dit (nog?) niet in de praktijk. Werken met centrale partijen en wetgeving is vandaag eenvoudiger toe te passen en makkelijker uit te leggen.
• Privacy-vriendelijk identiteitsbeheer. ZKP technologie laat toe om selectief persoonsgegevens over jezelf prijs te geven. Dit kan op basis van klassieke identiteitsdocumenten, zoals de Belgische eID kaart, ofwel kunnen identiteitsdocumenten uitgegeven worden onder de vorm van anonieme credentials. De ZKPs kunnen computationeel erg zwaar worden, zeker wanneer we gebruik maken van kwantumresistente technologie en wanneer van bestaande, officiële identiteitsdocumenten vertrokken wordt. 

Het gebruik van technologie voor ZKPs en anonieme credentials om de privacy te verbeteren komt met een aantal uitdagingen. We hadden het reeds over efficiëntie, kwantumresistentie en revocatie. Verder moet rekening gehouden worden met het gebrek aan standaarden, het risico dat contextinformatie, zoals een IP adres, de privacy alsnog teniet doet, en de mogelijke impact op de gebruikservaring voor de burger doordat die met een extra venster moet afrekenen.

Wellicht onder meer daardoor stelde Gartner in 2024 dat ZKP-technologie verouderd (“obsolete”) is, wat onder cryptografen tot enige verontwaardiging leidde. Gartner verwijderde de technologie nadien uit hun hype cycles. Ondanks het gebruik van ZKPs in Web3 (blockchain) en een beperkt aantal setups voor digitale identiteit, stagneert volgens Gartner de interesse in de technologie. Dit werd eerder dit jaar bevestigd toen Sovrin haar blockchain netwerk voor SSI (self-sovereign identity) uitdoofde. De toekomst zal uitwijzen of Gartner gelijk krijgt. Dit zou tragisch zijn, gezien de kracht en veelzijdigheid van deze technologie, waar onderzoekers reeds meerdere decennia aan werken en die nochthans heel wat potentieel zou moeten hebben in de publieke sector.

Aarzel niet ons te contacteren bij interesse!

Où est Charlie ? est un jeu bien connu qui consiste à trouver un personnage spécifique – appelé Charlie – dans un dessin très détaillé où figurent de nombreux autres personnages. Comment Paula (fournisseur de preuve ou prouveur) peut-elle prouver à Victor (vérificateur) qu’elle sait où se trouve Charlie sans révéler de détails sur sa position dans l’image ? Paula peut se servir d’un cache dont la hauteur et la largeur sont deux fois plus grandes que celles de l’image dans laquelle est caché Charlie. Au centre du cache se trouve un trou de la taille de Charlie. En positionnant le cache de manière à ce que le trou laisse entrevoir Charlie uniquement, Paula prouve à Victor qu’elle a localisé Charlie sans révéler d’informations sur son emplacement.

Il s’agit là d’un exemple de preuve à divulgation nulle de connaissance (en anglais zero-knowledge proof), ou preuve ZK, qui permet à une partie de prouver une affirmation à une autre partie sans divulguer plus de détails sur cette affirmation. À strictement parler, l’exemple de Charlie n’est pas tout à fait sans divulgation de connaissance, car des informations sur la posture et l’expression faciale de Charlie sont également divulguées, ce qui peut aider à le retrouver.

Un autre exemple, pour lequel une preuve de concept a été élaborée, permettrait de prouver au public que l’ADN d’un candidat à la présidence n’est pas répertorié dans une base de données ADN médico-légale. La police exécuterait un code accessible au public sur des données qui resteraient cachées au public : la base de données ADN et le profil ADN du candidat à la présidence. Le résultat pourrait être “aucune correspondance“, “correspondance partielle” ou “correspondance complète“. Le public – du moins les cryptographes parmi eux – serait alors convaincu que le résultat est l’exécution correcte du code sur les données confidentielles. L’affirmation prouvée ici à l’aide d’une preuve ZK concerne l’intégrité des calculs sur des données confidentielles .

Les titres numériques anonymes, abordés dans un précédent article, permettent en revanche aux citoyens de prouver de manière sélective certaines caractéristiques les concernant, telles que leur majorité, leur nationalité ou la détention d’un permis de conduire valide. Les titres numériques anonymes recourent intensivement aux preuves ZK. Comme nous le verrons plus loin dans cet article, les ZKP peuvent également être utilisés pour la divulgation sélective de données à caractère personnel.

En résumé, les preuves ZK permettent à une partie, le prouveur, de prouver des affirmations à une autre partie, le vérificateur, sans intermédiaire de confiance. Ces affirmations peuvent donc porter sur des calculs sur des données confidentielles, mais aussi sur des caractéristiques (attributs) d’un citoyen (ou même d’un animal ou d’un objet).

Formellement, une preuve ZK doit répondre à trois critères :

1. Complétude (completeness). Si l’affirmation est vraie, un vérificateur en sera convaincu.
2. Robustesse (soundness). Si l’affirmation est fausse, le prouveur ne peut pas, dans la pratique, convaincre à tort le vérificateur du contraire.
3. Zéro-connaissance (zero-knowledge). Si l’affirmation est vraie, le vérificateur n’apprend rien de plus que cette affirmation.

Cet article aborde deux cas d’utilisation importants pour les ZKP : l’amélioration de l’évolutivité et de la confidentialité des applications blockchain d’une part, et la gestion de l’identité des citoyens dans le respect de la vie privée d’autre part.

Blockchain

De nombreux cas d’usage potentiels ont déjà été définis dans la littérature, même si, à ce jour, seul un nombre limité d’entre eux ont été mis en pratique. L’un des principaux domaines d’application est celui de la blockchain et des monnaies virtuelles (cryptomonnaies).

Les preuves ZK y sont utilisées pour améliorer la confidentialité des transactions. Dans le Bitcoin et quelques autres monnaies virtuelles, l’adresse (le numéro de compte) de l’expéditeur, l’adresse du destinataire et le montant transféré sont visibles par tous pour chaque transaction ; tout est publié sur la blockchain. Une situation loin d’être idéale sur le plan de la confidentialité…

La monnaie virtuelle Zcash permet aux utilisateurs de dissimuler ces trois éléments à l’aide de preuves ZK. Pour ce faire, elle recourt aux zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge), développés en 2012 et appliqués pour la première fois par Zcash. Le S dans zk-SNARKs signifie “succint“, soit “concis” en français. Les preuves ZK dans Zcash peuvent “être vérifiées en quelques millisecondes et ne font que quelques centaines d’octets”.

Outre la confidentialité, les preuves ZK sont également utilisées pour augmenter l’évolutivité des blockchains. La capacité limitée des blockchains a incité la communauté à rechercher activement des moyens d’améliorer l’évolutivité sans compromettre la sécurité ou la vitesse. Une meilleure évolutivité signifie qu’une transaction nécessite moins de ressources avec, à la clé, une baisse des coûts de transaction. L’une des approches les plus prometteuses est celle des zk-rollups, utilisés sur la blockchain Ethereum par Starknet, ZKsync et Polygon entre autres. Au lieu de placer chaque transaction séparément sur la blockchain, celles-ci sont regroupées hors chaîne, exécutées et seul le résultat, accompagné d’une preuve ZK de bonne exécution, est placé sur la blockchain. Cela permet de réduire le nombre d’octets écrits sur la blockchain, et la vérification de la preuve ZK est plus rapide que la vérification de toutes les transactions individuelles. Un espace de stockage et une puissance de calcul moindres sont donc requis.

Parallèlement, des preuves ZK sont en cours d’élaboration pour démontrer qu’un smart contrat (code) a été correctement exécuté. Là encore, la raison est l’évolutivité : chaque fois qu’une fonction d’un smart contract (code sur la blockchain) est appelée aujourd’hui, chaque nœud de la blockchain exécute exactement le même code. L’idée est qu’un seul nœud exécute le smart contract et prouve sa bonne exécution. Les autres nœuds vérifient la preuve. Si une preuve ZK est plus efficace que l’exécution du smart contract, on augmente l’évolutivité.

Gestion de l’identité

Les titres numériques anonymes – qui font appel aux preuves à divulgation nulle de connaissance (zero knowledge proof – ZKP) – permettent à un citoyen de divulguer de manière sélective des informations le concernant, par exemple sa majorité. Dans la réalité, malheureusement, aucun pays ou région n’a massivement adopté les titres numériques anonymes dans les documents d’identité. Aussi des recherches plus récentes se sont-elles penchées sur d’autres pistes, à savoir la génération d’une ZKP sur la base d’un document d’identité existant. Des travaux académiques récents se sont concentrés sur le passeport et le permis de conduire aux États-unis.

Durant l’été 2025, la VUB a publié une étude consacrée à la carte d’identité belge.
Cette étude s’inscrit dans le cadre du projet SDM financé par Innoviris. S’il s’agit d’un travail prometteur, il comporte toutefois divers défis. Un premier défi concerne la faible efficacité : il faut 22 secondes à un ordinateur portable pour générer une preuve, délai qui sera encore plus long sur un téléphone. La révocation représente un deuxième défi : lorsqu’une carte eID est perdue ou volée et que les certificats sur la carte sont révoqués en conséquence, il ne doit plus être possible de générer des ZKP.  

La VUB souhaite aller encore plus loin, à savoir utiliser les ZKP pour démontrer qu’un citoyen dispose de certains droits, sans divulguer d’autres données à caractère personnel. À l’avenir, un citoyen pourrait ainsi prouver qu’il remplit les conditions pour bénéficier d’un loyer modéré, sans avoir à donner de plus amples informations à ce sujet.

Itsme a récemment annoncé son Itsme Qualify, qui autorise une divulgation sélective de données à caractère personnel au moyen de ZKP. Actuellement, seule la vérification de l’âge est prise en charge, mais itsme prévoit d’étendre cette fonctionnalité. Malheureusement, votre auteur n’a pas pu trouver de détails accessibles au public sur cette fonctionnalité et n’est pas parvenu à obtenir plus d’informations auprès d’itsme. Il est à espérer que ce manque de transparence ne soit que temporaire, car les ZKP, comme toute autre cryptographie, sont plus sûrs lorsque tous les détails sont publics et peuvent être validés par des experts.

Enfin, sachez qu’il existe des solutions de gestion d’identité qui combinent la « blockchain » et les ZKP. Privado ID est l’une des initiatives les plus visibles qui était jusqu’à récemment connue sous le nom de Polygon ID. Un émetteur y confirme les attributs personnels d’un citoyen – par exemple la date de naissance – en plaçant une valeur de hachage spécialement formée à partir de l’ensemble des attributs sur un réseau blockchain comme Ethereum. Le citoyen peut alors s’en servir pour prouver de manière sélective à un tiers des informations à caractère personnel le concernant, telles que sa majorité. Notez que tous les ZKP qui utilisent la même valeur de hachage comme base peuvent être liés entre eux. 

Résistance quantique

Comme déjà expliqué en détail dans des articles précédents de Smals Research, il existe un risque que de puissants ordinateurs quantiques puissent à l’avenir briser la cryptographie moderne à clé publique.

Les technologies telles que zk-SNARK et Bulletproofs, qui permettent de prouver l’exactitude des calculs, ne sont pas résistantes aux ordinateurs quantiques. C’est notamment pour cette raison que les zk-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge) ont vu le jour en 2018. Comme l’illustre la figure ci-dessous, l’efficacité computationnelle reste élevée, mais les preuves sont beaucoup plus volumineuses. Néanmoins, elles sont déjà utilisées à des fins d’évolutivité et de confidentialité entre autres par StarkNet et StarkEx, qui sont tous deux des solutions d’évolutivité pour Ethereum.

Comparaison de trois solutions ZK pour prouver des calculs (source)

Des preuves ZK résistantes à l’informatique quantique pour les calculs sont donc possibles, même si les preuves deviennent beaucoup plus volumineuses. Leur adoption par la communauté blockchain reste pour l’instant limitée ; les zk-SNARKs demeurent la technologie ZK dominante dans le contexte de la blockchain. Le travail de la VUB sur la gestion d’identité utilise également aujourd’hui les zk-SNARKs.

Conclusion

Les preuves à divulgation nulle de connaissance existent depuis plusieurs décennies et ont déjà fait l’objet de nombreux développements et recherches. Dans cet article, nous avons identifié les deux principaux cas d’utilisation :

• Confidentialité et évolutivité sur les réseaux blockchain. La technologie ZKP permet de prouver qu’un calcul sur des données confidentielles a été effectué correctement. Ceci peut se faire relativement rapidement et contribue à accroître l’évolutivité des réseaux blockchain. Bien qu’elle puisse en théorie être appliquée en dehors de la blockchain, on n’y assiste pas (encore ?) dans la pratique. Travailler avec des parties centrales et la législation est aujourd’hui plus facile à mettre en œuvre et à expliquer.
• Gestion d’identité dans le respect de la vie privée. La technologie ZKP permet de divulguer de manière sélective des données à caractère personnel vous concernant. Cela peut se faire sur la base de documents d’identité classiques, tels que la carte d’identité électronique belge. De même, des documents d’identité peuvent être délivrés sous la forme de titres numériques anonymes. Les ZKP peuvent être très lourds sur le plan computationnel, surtout lorsque l’on utilise une technologie résistante à l’informatique quantique et que l’on part de documents d’identité officiels existants. 

L’utilisation de la technologie pour les ZKP et les titres numériques anonymes pour améliorer la confidentialité pose un certain nombre de défis. Nous avons déjà évoqué la performance, la résistance à l’informatique quantique et la révocation. Il faut également tenir compte de l’absence de normes, du risque que des informations contextuelles, telles qu’une adresse IP, compromettent la confidentialité, ainsi que de l’impact potentiel sur l’expérience utilisateur pour le citoyen, qui doit passer par une fenêtre supplémentaire.

C’est peut-être en partie pour cette raison que Gartner a déclaré en 2024 que la technologie ZKP était obsolète, ce qui a suscité une certaine indignation parmi les cryptographes. Malgré l’utilisation des preuves ZK dans Web3 (blockchain) et un nombre limité de configurations pour l’identité numérique, l’intérêt pour cette technologie stagne selon Gartner. Cela a été confirmé plus tôt cette année lorsque Sovrin a supprimé son réseau d’identité auto-souveraine (SSI – self-sovereign identity). L’avenir nous dira si Gartner a raison. Ce serait tragique, compte tenu de la puissance et de la polyvalence de cette technologie, sur laquelle les chercheurs travaillent depuis plusieurs décennies et qui devrait pourtant avoir un potentiel considérable dans le secteur public.

N’hésitez pas à nous contacter si vous êtes intéressé !

La politique de cryptographie en tant que code ou Crypto Policy as Code (CPaC) est un principe très récent qui permet de respecter automatiquement les recommandations en matière de cryptographie. Cet article vise à concrétiser nos idées concernant la CPaC. Une représentation des politiques cryptographiques en JSON est proposée et utilisée à titre de base pour quelques expériences. L’objectif est de rendre le potentiel de la CPaC plus tangible et plus compréhensible, et ainsi d’inspirer certains lecteurs.

« Everything as Code »

L’approche Everything as Code (tout en tant que code) vise à exprimer tous les composants d’un système informatique (infrastructure, réseau, sécurité, pipelines de déploiement…) sous forme de code. Elle autorise un haut degré d’automatisation des processus et de la gestion. Elle nous offre un meilleur aperçu et nous permet de mieux anticiper et d’intervenir en cas de besoin. Il en résulte également une cohérence et une évolutivité accrues grâce à une moindre intervention humaine. Il nous semble non seulement utile, mais aussi nécessaire à terme d’adopter cette approche dans le cadre de la gouvernance cryptographique. 

Lorsque Smals Research a débuté l’étude du CPaC début 2025, il n’existait pratiquement aucune information à ce sujet. Depuis, le CPaC semble également avoir attiré l’attention de plusieurs entreprises, notamment Garantir.

Un premier aspect de la CPaC est l’expression des actifs cryptographiques (algorithmes, clés, certificats, hardware, bibliothèques…) sous forme de code. Cela permet de gérer et d’interroger automatiquement l’inventaire des actifs cryptographiques d’une organisation. Un tel inventaire est systématiquement recommandé dans le contexte de l’état de préparation quantique et de l’agilité cryptographique.

Le modèle CBOM (Cryptography Bill of Materials ou nomenclature de cryptographie) permet d’exprimer les actifs cryptographiques d’une organisation en code JSON. Bien qu’il soit encore très récent, nous pensons qu’il sera largement adopté dans les années futures. Nous prévoyons qu’à l’avenir, les services cloud, les bibliothèques, les systèmes d’exploitation et le hardware, entre autres, seront fournis avec une description de la cryptographie appliquée et supportée, exprimée selon le modèle CBOM. Une organisation pourra ensuite importer ces descriptions dans son inventaire cryptographique.

Eu égard à cette perspective, nous intégrons autant que possible nos propositions de CPaC dans le modèle CBOM. L’illustration ci-dessous est le résultat d’une analyse statique du code et montre dans le code CBOM que RSA-2048 est utilisé à trois endroits dans une application.  

« Crypto Policy as Code »

Smals dispose d’une politique cryptographique qui indique quels algorithmes et paramètres cryptographiques sont recommandés, lesquels sont sûrs bien que non recommandés, lesquels doivent être progressivement supprimés et lesquels ne sont pas sûrs. Actuellement, ces recommandations sont exprimées de manière classique, que seuls les humains peuvent facilement comprendre. Nous nous sommes demandé comment exprimer ces recommandations sous forme de code.

Penchons-nous sur AES-128-GCM. AES est le chiffre de bloc ; il chiffre ou déchiffre des blocs de 128 bits. Le nombre 128 dans AES-128-GCM fait référence à la longueur en bits de la clé utilisée. Grâce au mode GCM, il est également possible de chiffrer et déchiffrer de plus grandes quantités de données.

Dans la partie gauche de l’illustration ci-dessous, la description de l’AES-128-GCM est présentée selon le modèle CBOM. On y trouve notamment des informations sur le niveau de sécurité classique et le niveau de sécurité quantique. Dans la partie droite de l’illustration se trouve notre proposition de formulation des recommandations sous forme de code. Nous maximisons ainsi la compatibilité avec CBOM ; la structure, la nomenclature et les clés d’identification sont conservées. Dans le même temps, nous évitons la duplication des données que nous trouvons déjà dans la description CBOM.

Les recommandations se trouvent dans le bloc recommendation. Il contient au minimum le niveau de recommandation recommended, secure, phase-out ou insecure. En outre, ce bloc peut contenir des informations supplémentaires facultatives, telles que :

• la date à laquelle le mécanisme cryptographique doit disparaître progressivement ;
• la date de la dernière révision de la recommandation ;
• les conditions d’utilisation correcte du mécanisme cryptographique ;
• les remarques, par exemple sur les raisons pour lesquelles le mécanisme cryptographique n’est plus considéré comme sûr.

À titre expérimental, l’équipe Smals Research a déjà exprimé certaines recommandations cryptographiques sous forme de code, notamment les fonctions de hachage cryptographiques, le chiffrement symétrique, les message authentication codes (MAC), les key derivation functions (KDF) et TLS. Ces recommandations cryptographiques sont relativement simples et compatibles avec CBOM. De plus, un schéma JSON a été défini afin de valider l’exactitude de la syntaxe et de la structure de nos recommandations.

Dérogations sous forme de code

Idéalement, chaque partie qui sollicite nos services, notamment les hôpitaux, les pharmaciens et les CPAS, doit mettre à jour son logiciel en temps utile afin qu’il prenne en charge la cryptographie la plus récente et la plus sûre. Dans la pratique cependant, cette opération n’est pas toujours exécutée aussi rapidement et une dérogation à la politique cryptographique doit être autorisée exceptionnellement afin de ne pas compromettre les services essentiels aux citoyens.

L’illustration ci-dessous montre un exemple fictif d’une telle dérogation (deviation), où la structure proposée par Smals Research est suivie. Elle se compose de quatre blocs :

• Scope. La dérogation peut s’appliquer à un service entier ou à certains modules spécifiques de celui-ci.
• Approval. Nous trouvons ici la référence à l’approbation par le management, ainsi que la justification et la durée de la dérogation. 
• Assessment. Il s’agit de l’évaluation du risque. Une dérogation ne peut être approuvée qu’après une estimation préalable du risque, telle que décrite dans cette section.
• Allow. Cette section énumère les algorithmes ou suites cryptographiques autorisés. La structure de ce bloc provient directement du modèle CBOM.

Scripts expérimentaux

L’équipe Smals Research a rédigé plusieurs scripts afin d’illustrer la puissance de la CPaC. Les recommandations sous forme de code, les dérogations sous forme de code et/ou les descriptions CBOM constituent l’input.

Script 1 : configuration TLS

TLS (Transport Layer Security) est un protocole populaire de communication sécurisée entre deux parties. Avant d’échanger des données, les parties conviennent de la suite cryptographique (combinaison d’algorithmes) qu’elles utiliseront à cette fin. OpenSSL est un client TLS populaire.

Notre premier script génère la configuration OpenSSL relative à la cryptographie sur la base de la politique en tant que code et, le cas échéant, d’une déviation en tant que code. Le code produit, dont vous trouverez un exemple ci-dessous, peut ensuite être intégré dans openssl.cnf, qui est le fichier de configuration openSSL. La dernière ligne de notre exemple contient la liste des suites cryptographiques ; la dernière provient d’une dérogation, les autres sont sécurisées selon la politique cryptographique. L’ordre est important ici ; la dérogation a la priorité la plus faible.

[default_conf]
ssl_conf = ssl_section

[ssl_section]
system_default = system_default_section

[system_default_section]
MinProtocol = TLSv1.3
CipherString = # Sets the ciphersuite list for TLSv1.2 and below to value. This list will be combined with any configured TLSv1.3 ciphersuites.
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_8_SHA256

À terme, cela pourrait servir de base pour maintenir à jour de manière coordonnée la configuration cryptographique pour le TLS de milliers de machines. Bien évidemment, cela nécessite la mise en place des procédures pour éviter les erreurs.

Nous proposons que la politique et les déviations en tant que code soient gérées par un service central. La politique peut être accessible à l’ensemble de l’organisation, tandis que les déviations doivent être protégées par un contrôle d’accès strict.

Script 2 : génération d’un PDF

Pour la plupart des gens, un PDF bien structuré reste plus lisible qu’un fichier JSON. À partir de fichiers JSON, il n’est pas sorcier de générer de tels documents. C’est ce que réalisent nos deux scripts suivants.

Un PDF généré à titre expérimental contenant des recommandations de chiffrement symétrique peut être téléchargé ici. Il est parti du principe policy as code, mais il est fait également appel à CBOM pour enrichir le PDF ; les niveaux de sécurité classique et quantique en sont extraits.

Un deuxième fichier PDF généré à titre expérimental peut être téléchargé ici. Il contient des recommandations pour les suites cryptographiques TLS, complétées par des informations supplémentaires issues de la politique de cryptographie en tant que code. Un exemple de ce type d’informations est la date limite à laquelle une suite cryptographique peut être utilisée. Si un tel document était partagé avec les partenaires, cela leur permettrait d’anticiper en temps utile.

Script 3 : OPA policy verification

CPaC est un concept puissant. Les scripts précédents nous permettaient de générer des fichiers PDF et des configurations TLS. CPaC nous permet également de valider les artefacts existants, en vérifiant si un chiffrement sûr est utilisé.

OPA signifie Open Policy Agent. Il s’agit d’un moteur de politiques open source qui permet de séparer la logique applicative et les politiques. OPA permet aux organisations de centraliser leurs politiques et de les appliquer en temps réel. Différents services (Kubernetes, pipelines CI/CD, API gateways…) envoient des requêtes (queries) au format JSON au moteur de politiques afin de savoir si une action demandée par un client est autorisée. Sur la base d’une politique exprimée dans le langage Rego, le moteur de politiques indique au service si la requête doit recevoir une réponse positive ou négative. Par exemple, le moteur de politiques peut recevoir la requête d’une application demandant si une personne âgée de 15 ans est autorisée à utiliser l’application, alors que la politique stipule que l’âge minimum est de 18 ans. Le moteur de règles peut également être interrogé pour déterminer si une configuration réseau est conforme à la politique OPA. Par exemple, il peut exiger que les ports Telnet ne soient jamais ouverts.

Les services peuvent également poser des questions au moteur OPA concernant la cryptographie : la valeur donnée est-elle la valeur de hachage correcte (également appelée fingerprint ou digest) d’une charge utile donnée ? Une valeur est-elle le MAC correct pour une donnée d’entrée et une clé donnés ? Un certificat est-il signé par une autorité de confiance ? Un certificat utilise-t-il une courbe elliptique sécurisée ? …

Vous trouverez ci-dessous un exemple d’une telle requête et la politique correspondante. La politique stipule que la valeur de hachage de la charge utile est calculée à l’aide de la fonction de hachage (non sécurisée) MD5.

Input by service to policy engine
{
  "payload": {
    "user": "alice",
    "action": "read",
    "resource": "/api/users"
  },
  "expected_digest": "ea99819f665c10c744cbbf8da651c37a"
}

OPA Policy (in Rego) applied by the policy engine 
package crypto_digest_verification
payload_json := json.marshal(input.payload)
computed_digest := crypto.md5(payload_json)
digest_valid := computed_digest == input.expected_digest

Une organisation souhaitant mettre en place CPaC devra vérifier que ses politiques OPA existantes sont conformes à la dernière version de la politique cryptographique. Notre script final vérifie donc si la cryptographie utilisée dans la politique OPA est conforme à notre politique cryptographique centrale. En entrée est la crypto policy as code et une politique OPA. En sortie on obtient soit un message indiquant que la politique OPA est conforme, soit, comme dans le cas ci-dessus, un avertissement précisant également quel algorithme non sécurisé a été utilisé. À long terme, nous souhaitons également pouvoir déduire directement de notre CPaC les politiques OPA relatives à la cryptographie.

Conclusions

Cet article met en lumière le potentiel d’une approche everything as code pour stimuler la maturité cryptographique d’une organisation. À l’aide d’un certain nombre de scripts relativement simples, nous montrons comment une politique cryptographique centralisée, exprimée sous forme de code, peut soutenir une organisation dans divers domaines, de l’automatisation des processus à la création de documentation, en passant par la vérification de l’utilisation de la cryptographie appropriée, par exemple dans les politiques OPA.

À terme, nous souhaitons permettre l’accès aux informations sous forme de code via des API REST. Ainsi, les informations les plus récentes seront affichées clairement sur des tableaux de bord interactifs pour les utilisateurs autorisés. Les systèmes et applications pourront également accéder aux informations en temps réel via cette API REST. Idéalement, nous travaillerons avec une politique et un inventaire unifiés sous forme de code, la cryptographie n’étant qu’un aspect de ce système.

Dans un monde idéal, une politique de cryptographie en tant que code  pourrait être proposée par une organisation nationale ou européenne faisant autorité et pourrait être utilisée tant par le secteur public que par le secteur privé. Pour l’instant, cela reste une utopie. Au cours des prochaines années, nous pouvons nous attendre à une forte évolution dans ce domaine.

N’hésitez pas à nous contacter si vous souhaitez échanger vos idées avec nous à ce sujet !

Crypto Policy as Code (CPaC) is een erg jong principe dat ons in staat stelt aanbevelingen met betrekking tot cryptografie op een automatische wijze na te leven. Dit artikel maakt onze ideeën rond CPaC meer concreet. Een representatie van cryptografische policies in JSON wordt voorgesteld en gebruikt als basis voor enkele experimenten. Het doel is om het potentieel van CPaC tastbaarder en inzichtelijker te maken, en zo enkele lezers te inspireren.

Everything as Code

Everything as Code wil alle componenten in een IT systeem (infrastructuur, netwerk, veiligheid, deployment pipelines, …) uitdrukken als code. Het laat een hoge graad van automatisering toe van processen en beheer. Het geeft ons meer inzicht en laat ons toe beter te anticiperen en in te grijpen indien nodig. Bovendien resulteert het in een verhoogde consistentie en schaalbaarheid dankzij de verminderde menselijke interventie. Het lijkt ons niet enkel nuttig maar op termijn ook noodzakelijk om dit principe te omarmen in het kader van cryptographic governance. 

Het concept crypto policy as code is vrij nieuw. Toen Smals Research begin 2025 de studie startte was hier vrijwel niets over te vinden. Ondertussen blijkt het ook op de radar te staan van onder meer het bedrijf Garantir.

Een eerste aspect richting CPaC is het uitdrukken van de cryptografische assets (algoritmes, sleutels, certificaten, hardware, libraries, …) als code. Dit laat toe om om de inventaris met de cryptografische assets van een organisatie geautomatiseerd te beheren en te bevragen. Een dergelijke inventaris wordt systematisch aangeraden in de context van quantum readiness en crypto agility.

CBOM (Cryptograhy Bill of Materials) is een model om de cryptografische assets in een organisatie uit te drukken in JSON code. CBOM is vandaag nog erg nieuw, maar zal volgens onze inschatting in de komende jaren een brede adoptie kennen. We verwachten dat onder meer cloud diensten, libraries, besturingssystemen en hardware in de toekomst geleverd zullen worden samen met een beschrijving van de gebruikte en ondersteunde cryptografie, uitgedrukt volgens het CBOM model. Die beschrijvingen kan een organisatie vervolgens in zijn crypto inventaris importeren.

Omwille van deze verwachting enten we onze CPaC voorstellen zoveel als mogelijk op CBOM. Onderstaande figuur is het resultaat van een statische scan van code en toont in CBOM code dat RSA-2048 op drie locaties in een toepassing gebruikt wordt. 

Crypto Policy as Code

Smals beschikt over een cryptografische policy, die aangeeft welke cryptografische algoritmes en parameters aanbevolen zijn, welke veilig zijn, hoewel niet aanbevolen, welke uitgefaseerd dienen te worden en welke onveilig zijn. Momenteel wordt dit nog uitgedrukt op een klassieke manier die enkel door mensen vlot te interpreteren is. We stelden ons de vraag hoe dit als code uitgedrukt zou kunnen worden.

Laat ons even kijken naar AES-128-GCM. AES is het blokcijfer; het encrypteert of decrypteert blokken van 128 bits. Het getal 128 in AES-128-GCM verwijst naar de bitlengte van de sleutel die daarbij gebruikt wordt. Dankzij de modus GCM kunnen ook grotere hoeveelheden data geëncrypteerd en gedecrypteerd worden.

Links op onderstaande figuur wordt de beschrijving van AES-128-GCM getoond volgens het CBOM model. We vinden er informatie over onder meer het klassieke en kwantum veiligheidsniveau. Ons daarop entend, toont de figuur rechts ons voorstel om de aanbevelingen te formuleren als code. We maximaliseren daarbij de compatibiliteit met CBOM; de structuur, naamgeving en identificatielsleutels worden behouden. Tegelijkertijd vermijden we duplicatie van data die we reeds in de CBOM beschrijving vinden.

De aanbevelingen zitten vervat in het recommendation blok. Het bevat minimum het aanbevelingsniveau: recommended, secure, phase-out of insecure. Daarnaast kan dit blok extra, optionele, informatie bevatten, zoals:

• de uiterste datum waarop het cryptografische mechanisme uitgefaseerd dient te worden,
• de datum dat de aanbeveling laatst gereviseerd werd,
• voorwaarden voor correct gebruikt van het cryptografische mechanisme
• opmerkingen, vb. waarom het cryptografisch mechanisme niet langer als veilig beschouwd wordt.

Bij wijze van experiment heeft Smals Research reeds enkele cryptografische aanbevelingen uitgedrukt als code; met name cryptografische hashfuncties, symmetrische vercijfering, message authentication codes (MACs), key derivation functions (KDFs) en TLS. Deze cryptografische aanbevelingen zijn relatief eenvoudig en compatibel met CBOM. Bovendien werd een JSON schema gedefineerd om de correctheid van de syntax en structuur van onze aanbevelingen te valideren. 

Afwijkingen als code

Idealiter doet elke partij die op onze diensten beroep doet, waaronder ziekenhuizen, apothekers en OCMW’s, tijdig de update van hun software zodat die de meest recente en veiligste cryptografie ondersteunen. In de praktijk gebeurt dit niet steeds even snel en moet uitzonderlijk een afwijking van de crypto policy toegestaan worden, zodat de cruciale dienstverlening aan de burgers niet in het gedrang komt.

De onderstaande figuur toont een fictief voorbeeld van een dergelijke afwijking (deviation), waarbij de door Smals Research voorgestelde structuur gevolgd wordt. Het bestaat uit vier blokken:

• Scope. De afwijking kan van toepassing zijn op een volledige dienst, of op specifieke modules ervan.
• Approval. Hier vinden we de referentie naar de goedkeuring door het management, alsook de rechtvaardiging en het tijdsvenster van de afwijking. 
• Assessment. Dit is de beoordeling van het risico. Een afwijking kan enkel goedgekeurd worden mits een voorafgaande inschatting van het risico, wat beschreven wordt in deze sectie.
• Allow. Deze sectie geeft een opsomming van de toegestane algoritmes of cipher suites. De structuur van dit blok komt rechtstreeks uit het CBOM model.

Experimentele scripts

Smals Research schreef een aantal scripts om de kracht van CPaC te illusteren. De aanbevelingen als code, afwijkingen als code en/of CBOM beschrijvingen vormen daarbij de invoer.

Script 1: TLS configuratie

TLS (Transport Layer Security) is een een populair protocol voor veilige communicatie tussen twee partijen. Alvorens data met elkaar uit te wisselen, spreken de partijen samen af welke cipher suite (combinatie van algoritmes) ze daarbij zullen gebruiken. OpenSSL is een populaire TLS client.

Ons eerste script genereert op basis van de crypto policy as code en eventueel een deviation as code de OpenSSL configuratie m.b.t. cryptografie. De uitvoer, waarvan een voorbeeld hieronder, kan vervolgens geïntegreerd worden in openssl.cnf, wat het openSSL configuratiebestand is. De laatste lijn in ons voorbeeld bevat de lijst met cipher suites; de laatste komt uit een afwijking, de anderen zijn veilig volgens de crypto policy. De volgorde is hier van belang; de afwijking krijgt de laagste prioriteit.

[default_conf]
ssl_conf = ssl_section

[ssl_section]
system_default = system_default_section

[system_default_section]
MinProtocol = TLSv1.3
CipherString = # Sets the ciphersuite list for TLSv1.2 and below to value. This list will be combined with any configured TLSv1.3 ciphersuites.
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_8_SHA256

Dit kan op termijn de basis vormen om op een gecoördineerde wijze de crypto configuratie voor TLS van duizenden machines geactualiseerd te houden. Uiteraard vereist dit de nodige procedures om fouten tegen te gaan.

Ons voorstel is om zowel de policy as code als de deviations as code door een centrale service te laten beheren. Daarbij kan de policy as code toegankelijk zijn binnen de gehele organisatie, terwijl de deviations as code beschermd dienen te worden door strikte toegangscontrole.

Script 2: PDF generatie

Voor de meeste mensen is een goed gestructureerde PDF nog steeds leesbaarder dan JSON. Vertrekkende van JSON bestanden is het geen heksenkunst om dergelijke documenten te genereren. Dit is wat onze volgende twee scripts realiseren.

Een experimenteel gegenereerde PDF met aanbevelingen voor symmetrische vercijfering is hier te downloaden. Er wordt vertrokken van policy as code, maar er wordt eveneens beroep gedaan op CBOM om de PDF verder te verrijken; zowel het klassieke als kwantumveiligheidsniveau zijn daaruit geëxtraheerd.

Een tweede experimenteel gegenereerde PDF bestand is hier te downloaden. Het bevat aanbevelingen voor TLS cipher suites, aangevuld met bijkomende informatie uit de crypto policy as code. Een voorbeeld van dergelijke informatie is de uiterlijke datum tot wanneer een cipher suite gebruikt mag worden. Indien een dergelijk document met partners gedeeld werd, zou dit hen toelaten tijdig te anticiperen.

Script 3. OPA policy verification

CPaC is een krachtig concept. Voorgaande scripts lieten ons toe om PDF bestanden en TLS configuraties te genereren. CPaC laat ook toe om bestaande artefacten te valideren; om na te gaan of veilige cryptografie gebruikt wordt.   

OPA staat voor Open Policy Agent. Het is een open source policy engine, wat toelaat een scheiding te maken tussen applicatie logica en policy. OPA stelt organisaties in staat policies te centraliseren en in real time af te dwingen. Verschillende services (Kubernetes, CI/CD pipelines, API gateways, …), sturen vragen (queries) in JSON formaat naar de policy engine om te weten of, bijvoorbeeld, een door een client gevraagde actie toegelaten is. Op basis van een policy, uitgedrukt in de taal Rego, laat de policy engine aan de service weten of de vraag positief of negatief beantwoord dient te worden. Zo kan de policy engine de vraag krijgen van een toepassing of iemand van 15 jaar de toepassing mag gebruiken, terwijl de policy bepaalt dat de minumleeftijd 18 jaar is. Of er kan gevraagd worden aan de policy engine of een netwerkconfiguratie in overeenstemming is met de OPA policy. Deze kan bijvoorbeeld eisen dat Telnet poorten nooit open mogen staan.

Services kunnen de OPA engine ook vragen stellen m.b.t. cryptografie: is de gegeven waarde de correcte hashwaarde (ook wel fingerprint of digest) van een gegeven payload? Is een waarde de correcte message authentication code (MAC) voor een gegeven input en sleutel? Is een certificaat ondertekend door een vertrouwde autoriteit? Gebruikt een certificaat een veilige elliptische kromme? …

In ons voorbeeld wordt een JSON bestand bestaande uit een payload en een verwachte hashwaarde (expected_digest) naar de policy engine gestuurd. De OPA policy bepaalt dat de policy engine de hash van de payload opnieuw berekent en dat het resultaat moet overeenkomen met de ontvangen verwachte hashwaarde. De vierde lijn van de OPA policy hieronder bepaalt dat de hashfunctie die daarbij gebruikt dient te worden het (onveilige) MD5 is.  

Input by service to policy engine
{
  "payload": {
    "user": "alice",
    "action": "read",
    "resource": "/api/users"
  },
  "expected_digest": "ea99819f665c10c744cbbf8da651c37a"
}

OPA Policy (in Rego) applied by the policy engine 
package crypto_digest_verification
payload_json := json.marshal(input.payload)
computed_digest := crypto.md5(payload_json)
digest_valid := computed_digest == input.expected_digest

Een organisatie die CPaC wil introduceren zal moeten nagaan of de bestaande OPA policies compliant zijn met de meest recente versie van de cryptografische policy. Ons laatste script gaat daarom na of de cryptografie die in de OPA policy gebruikt wordt, in overeenstemming is met onze centrale crypto policy (CPaC). De invoer is de crypto policy as code (CPaC) en een OPA policy. De output is ofwel een bericht dat de OPA policy compliant is, ofwel – zoals in bovenstaand geval – een waarschuwing, die ook aangeeft welk onveilig algoritme gebruikt werd. Op termijn willen we ook OPA policies m.b.t. cryptografie direct kunnen afleiden uit onze CPaC.  

Conclusies

Dit artikel werpt een licht op het potentieel van een everything as code benadering om de cryptografische maturiteit van een organisatie een boost te geven. Met behulp van een aantal relatief eenvoudige scripts tonen we aan hoe een centraal beheerde crypto policy, uitgedrukt als code, een organisatie op diverse vlakken kan ondersteunen, gaande van het automatiseren van processen, het creëren van documentatie en het nagaan of de correcte cryptografie gebruikt wordt, zoals in OPA policies.

Op termijn evolueren we hopelijk naar een ontsluiting van de as code informatie via REST API’s. Op basis daarvan wordt de meest actule informatie overzichtelijk in interactieve dashboards aan geautoriseerde gebruikers getoond. Ook systemen en toepassingen kunnen in real-time informatie bekomen via deze REST API. Idealiter wordt gewerkt met een eengemaakte policy as code en een eengemaakte inventaris as code, waarin cryptografie slechts één van de aspecten is. 

In een ideale wereld wordt de crypto policy as code aangeboden door een nationale of Europese gezaghebbende organisatie en kunnen zowel de publieke als private sector hier gebruik van maken. Dit is voorlopig nog toekomstmuziek. In de komende jaren mogen we ons wellicht aan een sterke evolutie verwachten in dit domein.

Aarzel niet ons te contacteren indien u hierover met ons van gedachten wilt wisselen!

Version en français

In onze laatste blogpost hebben we de werking van de “Tor”-browser beschreven, die het mogelijk maakt om vrijwel onvindbaar op het internet te surfen. Dit is een van de twee manieren om Tor te gebruiken. De tweede manier, is om deze tool te gebruiken als toegangspoort tot het “Dark Web”. De afgelopen maanden hebben we deze duistere kant van het internet verkend. Wat is het? Wat kun je daar vinden? Hoe kun je daar je weg in vinden? In deze blogpost delen we onze bescheiden ervaring met de wereld die, hoewel hij oorspronkelijk werd opgericht om een veilige expressieruimte te bieden aan dissidenten van autoritaire regimes, vandaag in wezen een paradijs voor cybercriminelen is geworden.

Laten we beginnen met een beetje woordenschat. Eerst maken we een onderscheid tussen twee concepten die maar al te vaak door elkaar worden gehaald: het internet en het web. Internet is een infrastructuur die duizenden netwerken met elkaar verbindt, waardoor elke machine die er deel van uitmaakt, waaronder het toestel waarmee je dit artikel leest, kan communiceren met (bijna) elke andere machine (bijvoorbeeld de server die onze website host). Het internet, dat sinds begin jaren 70 bestaat, heeft de ontwikkeling van een groot aantal toepassingen mogelijk gemaakt: e-mail, bestandsoverdracht (FTP), bediening op afstand (telnet, SSH en opvolgers), messaging, videoconferenties en het (World Wide) Web, dat begin jaren 90 bij CERN ontstond en het internet echt populair heeft gemaakt. Met behulp van een “browser” (de eerste was Mosaic, die zich ontwikkelde tot Netscape en nu Firefox is, maar ook Chrome, Edge of Opera) kan interactief een document worden weergegeven dat door een webserver is gegenereerd. Het web, officieel “World Wide Web” genoemd, is dus een van de vele toepassingen die gebruikmaken van de infrastructuur van het internet. Het bestaat uit een communicatieprotocol tussen de server en de browser (HTTP/HTTPS), een protocol voor het aanwijzen van een bron (URL) en een documentformaat (HTML).

Algemeen wordt aangenomen dat de inhoud van het web in drie categorieën kan worden onderverdeeld:

• Het “Oppervlakteweb” (Surface Web, Clear Web) is het gedeelte dat rechtstreeks toegankelijk is met een browser, zonder toegangsbeperkingen en geïndexeerd door zoekmachines: deze blog, de inhoud van de meeste media, Wikipedia en tal van andere bronnen;
• Het “Deep Web” is het deel van het web dat niet door zoekmachines wordt geïndexeerd. Het is toegankelijk via een klassieke browser, zolang je het adres kent of de privégegevens (gebruikersnaam, wachtwoord, enz.) die nodig zijn om het te kunnen bezoeken. De niet-publieke inhoud op sociale media, je mailbox, de inhoud van bedrijven met beperkte toegang, …
• Het “Dark Web” is het deel van het web waarvoor specifieke tools of bepaalde configuraties vereist zijn om toegang te krijgen. Meestal heb je een browser zoals Tor nodig, maar ook een ‘.onion-adres’, een reeks van 56 tekens die onmogelijk te onthouden is (bijvoorbeeld http://juhanurmihxlp77nkq76byazcldy2hlmovfu2epvl5ankdibsot4csyd.onion/).

In deze blogpost gaat onze interesse uit naar dat laatste deel. We zouden eigenlijk eerder moeten spreken van “Dark Webs”. Daar zijn er meerdere van, die elk een eigen architectuur en verschillende technologieën gebruiken. De populairste zijn Tor en, ver achterop, I2P en Freenet (nu Hyphanet). We zullen ons in deze blogpost toespitsen op Tor.

Indien we de Tor-browser gebruiken om naar een “Clear Web”-site te surfen (bijvoorbeeld https://www.smals.be), is de client zeer goed beschermd, maar de bezochte website niet: het IP-adres kan gemakkelijk worden achterhaald, en dus ook waar de website wordt gehost, en de autoriteiten van het betreffende land kunnen de website laten sluiten of zelfs veel informatie over de gebruikers verkrijgen. Dit wordt veroorzaakt doordat het Tor-netwerk geen controle heeft over de verbinding tussen het uitgangsnode en de doelserver.

Er bestaat een manier waarop de host van een website zichzelf net zo goed kan beschermen als de client, zodat zijn IP-adres nooit wordt onthuld. Het idee is om eerst een klassieke webserver op te zetten (met bijvoorbeeld NGINX of Apache) en vervolgens op dezelfde machine een “Tor-server” te installeren (minder dan 5 minuten werk). De server genereert een “publieke sleutel” van 56 alfanumerieke tekens die als adres wordt gebruikt (in de vorm <public key>.onion), en voert deze in de gedecentraliseerde mappen van het Tor-netwerk in. Zo kan de beheerder van de betreffende website een “.onion”-adres publiceren dat niet meer toegankelijk is voor gebruikers van een klassieke browser en van waaruit het erg moeilijk, zo niet onmogelijk, is om hem te traceren. Interessant voor een dissident in een autoritair land, maar ook om een criminele onderneming veilig te beheren.

Voor meer details: zowel de client als de server gebruiken een “Tor-circuit” van 3 nodes, om elkaar te vinden op een “meeting point” waardoor zowel de client als de server volledige anonimiteit gegarandeerd is. Maar in bepaalde situaties zijn er tot 6 tussenliggende nodes. Merk op dat wanneer je verbinding maakt met de Tor-browser met een “.onion”-dienst, de verbinding end-to-end versleuteld is. Het is dus niet noodzakelijk om een extra versleutelingslaag toe te voegen met HTTPS.

Algemene opmerkingen

We hebben een paar weken besteed aan het verkennen van het Dark Web en het vertrouwd raken met deze wereld. Dat is natuurlijk niet genoeg om ons experts te noemen, maar wel voldoende om een eerste indruk te krijgen. We hebben deze verkenning uitgevoerd met Tails + Tor. We hebben uiteraard nooit iets besteld op de “markets”, hebben niet deelgenomen aan forums en hebben uiteraard geen websites bezocht die in strijd zijn met de wet en de goede zeden. Voordat we dieper ingaan op de verschillende soorten inhoud, beginnen we met enkele algemene opmerkingen:

• het beheer van “.onion”-namen is bijzonder ongebruiksvriendelijk. Ze zijn onmogelijk te onthouden en het is erg moeilijk om er zeker van te zijn dat je op de juiste site bent en niet op een “gepirateerde versie”;
• veel meer dan op het “klassieke” web zijn de adressen erg veranderlijk.
  Als je een adres op een pagina vindt (bijvoorbeeld via een zoekmachine of een “hidden wiki”, zie hieronder), is de kans groot dat het niet meer geldig is.
• een groot deel van de sites (markets, forums, zoekmachines) lijkt rechtstreeks uit het begin van de jaren 2000 te komen… een zeer “vintage” ontwerp en ergonomie, weinig gebruiksvriendelijk, waar je moeilijk naar kan kijken. Misschien onder andere omdat de meeste zijn ontworpen om zonder Javascript te kunnen werken, wat wordt aanbevolen om de risico’s te beperken;
• aangezien wantrouwen de norm is op het Dark Web, worden veel sites beschermd door een Captcha-systeem, maar deze zijn bijzonder moeilijk op te lossen. Om te voorkomen dat robots ze kunnen oplossen, zijn ze zo ingesteld dat zelfs een mens (in ieder geval ondergetekende) moeite heeft om ze op te lossen. Zie het voorbeeld hiernaast. Kun je het woord lezen?
• de meeste websites zijn bijzonder traag. Dit is waarschijnlijk te wijten aan de aard van het Tor-netwerk, dat elke aanvraag van minstens 3 (of zelfs 6) tussenliggende nodes laat lopen, die niet noodzakelijk erg krachtig zijn.

Inhoud

Toegangspunten

Het is veel moeilijker om op het Dark Web te vinden wat je zoekt dan op het “Clear Web”.
Het is duidelijk onmogelijk om een “.onion”-adres te onthouden of zelfs maar over te typen. Er zijn grofweg twee manieren om een verkenning met Tor te beginnen:

• gebruik maken van een “hidden wiki”, een directory met links die op categorie zijn gerangschikt. Er zijn er een aantal, sommige op het Clear Web, die gemakkelijk te vinden zijn door met een klassieke zoekmachine op “hidden wiki” te zoeken. Je moet er echter rekening mee houden dat een groot deel van de links niet meer werkt;
• een speciale zoekmachine gebruiken, die alleen toegankelijk is met Tor, waarvan de “.onion”-adressen gemakkelijk te vinden zijn op een “hidden wiki”. “Torch” of “Ahmia” zijn hier voorbeelden van. Verwacht echter geen prestaties die vergelijkbaar zijn met die van Google of DuckDuckGo: niet alleen zijn er weinig resultaten voor een gerichte zoekopdracht, maar vaak is de lijst met resultaten ook onduidelijk. Je weet dus niet altijd waarop je klikt.

Markets

Talrijke “markets” zijn beschikbaar op het Dark Web, die een beetje werken zoals Amazon of Bol.com. De meeste eisen betalingen in Bitcoin (of vaker Monero, waardoor er geen verband kan worden gelegd tussen twee transacties) en bieden een hele reeks producten aan die niet verkrijgbaar zijn op meer traditionele opdrachten:

• wapens en munitie, van kleine pistolen tot aanvalsgeweren.
• drugs en medicijnen, waarschijnlijk de sector met het grootste aanbod.
• valse documenten: paspoorten, rijbewijzen, identiteitskaarten, en dit voor meerdere landen.
• gestolen creditcardnummers, die des te duurder zijn naarmate de limiet hoger is. Reken op tussen 50 en 100 euro per nummer.
• vals geld.
• diensten:
  • hackers : hackers bieden tal van opties, gaande van een DDoS-aanval tot het binnendringen van een systeem of het hacken van e-mailaccounts of sociale netwerken.,
  • aanslagen op personen: er zijn tal van “diensten” beschikbaar: moord, ontvoering, agressie. Sommigen zijn echter van mening dat het hier slechts om pogingen tot afpersing gaat.

Forums

Talrijke forums zijn beschikbaar, in alle talen. Wat ze allemaal gemeen hebben, is dat de deelnemers niet traceerbaar zijn en zich dus niet inhouden om volstrekt illegale of zelfs ronduit verachtelijke verzoeken of voorstellen te doen. Beledigingen en vulgariteiten zijn de norm. Openlijk racistische berichten, voorstellen of zoektochten naar verdovende middelen, verzoeken om of verkoop van kinderpornografische inhoud…

Data leaks

Het is gemakkelijk om, al dan niet gratis, een grote hoeveelheid gestolen data te vinden, zowel op forums als op markets. Deze kunnen in twee categorieën worden ingedeeld:

• lijsten met “inloggegevens”: gebruikersnaam + wachtwoord, soms met de betreffende website. Waarschijnlijk verkregen door phishing of door een “keylogger”, moeilijk te controleren (zonder ze te hebben getest, wat we natuurlijk nooit hebben gedaan) of de data nog actueel zijn. Maar met miljoenen gegevens is het aannemelijk dat er altijd wel functionele toegangen te vinden zijn.
• Resultaten van ransomware. Wanneer hackers erin slagen om in te breken in het systeem van een bedrijf, versleutelen ze vaak alle data en eisen ze losgeld om ze weer toegankelijk te maken. En als het losgeld niet wordt betaald, publiceren veel groepen de gestolen inhoud in zijn geheel. Een aantal websites biedt “bewijsmateriaal” (meestal screenshots van enkele documenten; zie hieronder voor de hack van de Ahold Delhaize-groep door de INC Ransom-groep) voor “lopende” onderhandelingen en toegang tot grote volumes voor verlopen onderhandelingen.
  Bijvoorbeeld:    
  • data van een lokale missie in het zuidwesten van Frankrijk: lijst met de namen (geboortedata, telefoonnummers) van de gevolgde jongeren,
  • een Frans farmaceutisch bedrijf, met fabrieksplannen, contracten met partners, inhoud van een testdatabase,
  • voor een Franse vrijmetselaarsloge: interne veiligheidsanalyse, uitnodigingen, ledenlijsten en contributiebedragen,
  • voor de 200 GB aan data van de Nederlandse groep “Ahold Delhaize”, die vooral betrekking lijken te hebben op haar activiteiten in de Verenigde Staten,
  • voor een Belgisch revalidatiecentrum, naast talrijke data (beheer, aankopen, financiën, HR…), persoonlijke informatie over meer dan 30 000 patiënten (naam, voornaam, geboortedatum, pathologiecode), evenals een “export” van 380 000 patiënten met veel persoonlijke details (naam, adres, telefoonnummer, e-mailadres, nummer van het ziekenfonds… ), maar weinig medische gegevens.

Activisme

Naast de hierboven beschreven illegale activiteiten zijn er ook een aantal websites die aansluiten bij de oorspronkelijke redenen voor de oprichting van het Tor-netwerk. Hier vinden we een aantal gerenommeerde organisaties die een “.onion”-versie van hun website hebben om informatie van klokkenluiders te verzamelen: Greenpeace, CNN, The Guardian, ProPublica, de CIA…

Een aantal blogs die we als activistisch of rebels kunnen omschrijven, of strijden tegen politiegeweld, zijn op het dark web te vinden om censuur te vermijden. Het gaat vaak om websites met twee toegangen: één op het “Clear Web” en één op het Dark Web.

Conclusies

De meest “gevoelige” goederen zijn alleen verkrijgbaar van persoon tot persoon, nadat een vertrouwensrelatie is opgebouwd met degenen die ze bezitten, met name als het gaat om hacking en de bijbehorende tools. Aangezien we geen contact hebben gelegd met iemand op het Dark Web, hebben we ongetwijfeld een groot deel van wat er te vinden is gemist.

Maar wat we in slechts enkele weken tijd hebben gevonden, heeft ons ervan overtuigd dat veel overheidsinstellingen en bedrijven er goed aan zouden doen om op zijn minst na te gaan of er activiteiten te vinden zijn die verband houden met hun werkterrein, of data van hun personeel of klanten. Hoewel het vrijwel onmogelijk is om deze data te laten verdwijnen, is het raadzaam om in geval van een lek de juiste maatregelen te nemen.

Als een probleem optreedt, is het essentieel om hulp in te roepen van specialisten. In België moet, afhankelijk van de omstandigheden, dringend contact worden opgenomen met het CCB (Center for Cybersecurity Belgium) of de FCCU (Federal Computer Crime Unit, politie).

Nederlandstalige versie

Dans notre dernier article, nous avons détaillé le fonctionnement du navigateur “Tor”, qui permet de naviguer de façon quasiment intraçable sur le web. C’est une des deux façons d’utiliser Tor. La seconde, c’est d’utiliser cet outil comme portail d’entrée sur le “dark web”. Nous avons ces derniers mois exploré cette zone sombre du web. Qu’est-ce que c’est ? Qu’y trouve-t-on ? Comment s’y retrouver ? Dans cet article, nous allons partager notre modeste expérience de ce monde qui, s’il a été créé au départ pour offrir un espace d’expression sécurisé pour les dissidents de régimes autoritaires, est devenu aujourd’hui essentiellement le paradis de la cybercriminalité.

Commençons par un peu de vocabulaire. Différencions d’abord deux concepts trop souvent confondus : Internet et le Web. Internet, c’est une infrastructure, interconnectant des milliers de réseaux, permettant à n’importe quelle machine en faisant partie, dont l’appareil avec lequel vous lisez cet article, de communiquer avec (presque) n’importe quelle autre (par exemple le serveur qui héberge notre site web). Internet, qui existe depuis le début des années ’70, a permis le déploiement d’un grand nombre d’applications : le courrier électronique, le transfert de fichiers (FTP), le contrôle à distance (telnet, SSH et successeurs), les messageries, la visioconférence, ou encore le (World Wide) Web, apparu au CERN début des années ’90 et qui a réellement popularisé Internet. Il permet, à l’aide d’un “navigateur” (le premier étant Mosaic, qui a évolué en Netscape, pour devenir aujourd’hui Firefox ; mais aussi Chrome, Edge, ou Opera), d’afficher de façon interactive un document généré par un serveur Web. Le Web, de son nom complet “World Wide Web”, c’est donc une des nombreuses applications utilisant l’infrastructure d’Internet ; il est composé d’un protocole de communication entre le serveur et le navigateur (HTTP/HTTPS), d’un protocole de désignation d’une ressource (URL) et d’un format de document (HTML).

On considère en général que le contenu du Web peut être divisé en trois catégories :

• le “web de surface” (surface web, clear web) est toute la partie directement accessible avec un navigateur, sans restriction d’accès et indexée par les moteurs de recherche : ce blog, le contenu de la plupart des médias, Wikipédia ou tout un tas d’autres ressources ;
• le “deep web” est la partie du web qui n’est pas indexée par les moteurs de recherche. On peut y accéder à l’aide d’un navigateur classique, pour autant qu’on en connaisse l’adresse, ou les informations privées (nom d’utilisateur, mot de passe…) pour s’y rendre. Le contenu non public des médias sociaux, votre boite mail, le contenu d’entreprises à accès restreint…
• le “dark web” est la partie du web qui nécessitera des outils spécifiques ou des configurations particulières pour y accéder. On aura typiquement besoin d’un navigateur tel que Tor, mais également d’une “adresse .onion”, une chaine de 56 caractères impossible à retenir (par exemple http://juhanurmihxlp77nkq76byazcldy2hlmovfu2epvl5ankdibsot4csyd.onion/).

C’est cette dernière partie qui va nous intéresser dans cet article. Il faudrait en fait plutôt parler des dark webs. Il en existe plusieurs, chacun utilisant une architecture propre et des technologies différentes. Les plus populaires sont Tor, et, loin derrière, I2P et Freenet (devenu Hyphanet). Nous allons nous concentrer sur Tor dans la suite de cet article.

Si on utilise le navigateur Tor pour naviguer sur un site du “clear web” (par exemple, https://www.smals.be), le client est très bien protégé, mais pas le site visité : on peut connaitre facilement son adresse IP, et donc où il est hébergé, et les autorités du pays concerné pourront imposer sa fermeture, voire obtenir de nombreuses informations sur ses utilisateurs. Ceci parce que le réseau Tor ne contrôle pas la connexion entre son nœud de sortie et le serveur de destination.

Il existe une façon, pour l’hébergeur d’un site web, de se protéger autant que le client, de façon à ne jamais dévoiler son adresse IP. L’idée est de mettre d’abord en place un serveur web classique (avec NGINX ou Apache, par exemple), puis d’installer, sur la même machine, un “serveur Tor” (moins de 5 minutes de travail). Celui-ci va générer une “clé publique” de 56 caractères alphanumériques qui servira d’adresse (de la forme <clé publique>.onion), et la renseigner auprès des annuaires décentralisés du réseau Tor. En procédant de la sorte, le gestionnaire du site web en question peut publier une adresse “.onion”, qui ne sera plus accessible aux utilisateurs d’un navigateur classique, et à partir de laquelle il sera très difficile, voire impossible, de remonter jusqu’à lui. Intéressant pour un dissident dans un pays autoritaire, mais également pour gérer en toute sécurité un business criminel.

Pour plus de détails, à la fois le client et le serveur vont utiliser un “circuit Tor” de 3 nœuds, pour se retrouver à un “point de rendez-vous”, ce qui permet tant au client qu’au serveur d’obtenir toutes les garanties d’anonymat. Mais avec dans certaines situations jusqu’à 6 nœuds intermédiaires. Notons que lorsqu’on se connecte avec le navigateur Tor a un service “.onion”, la connexion est chiffrée de bout en bout. Il n’est donc pas nécessaire d’ajouter une couche de chiffrement en utilisant HTTPS.

Remarques générales

Nous avons passé quelques semaines à explorer le dark web et à nous familiariser avec cet univers. Clairement pas suffisant pour pouvoir se targuer d’en être devenus des experts, mais assez pour se faire une première impression. Nous avons fait cette exploration avec Tails + Tor. Nous n’avons bien sûr jamais rien commandé sur les “markets”, ne sommes pas intervenus sur les forums et ne sommes de toute évidence pas entrés sur des sites contraires à la loi et à la décence. Avant d’entrer dans plus de détails dans les différentes types de contenu, commençons par quelques remarques générales. 

• La gestion des noms “.onion” est particulièrement peu conviviale. Impossible à retenir, et très difficile de s’assurer qu’on est sur le bon site et pas sur une version “pirate” ;
• Beaucoup plus que sur le web “classique”, il y a une grande volatilité des adresses. Si vous trouvez une adresse sur une page (par exemple via un moteur de recherche ou un “hidden wiki”, voir plus bas), il y a beaucoup de chances qu’elle ne soit plus valide ;
• Une partie importante des sites (markets, forums, moteurs de recherches) semblent sortir tout droit du début des années 2000… un design et une ergonomie très “vintage”, peu conviviale, qui fait souvent presque mal aux yeux. Peut-être entre autres parce que la plupart sont conçus pour pouvoir fonctionner sans Javascript, ce qui est recommandé pour limiter les risques ;
• La méfiance étant la norme sur le dark web, de nombreux sites sont protégés par un système de Captcha, mais ceux-ci sont particulièrement difficiles à résoudre. Pour empêcher les robots de les réussir, ils sont réglés à un tel niveau que même un humain (en tout cas votre serviteur) a du mal à les réussir. Voir l’exemple ci-contre. Sauriez-vous lire le mot ?
• La plupart des sites web sont particulièrement lents. Ceci est sans doute dû à la nature même du réseau Tor, qui fait passer chaque requête par au moins 3 (voire 6) nœuds intermédiaires, pas nécessairement très puissants.

Contenu

Points d’entrée

Il est de loin plus difficile de trouver ce que l’on veut sur le dark web que sur le “clear web”. Il est clairement impossible de retenir, voire même de retaper une adresse “.onion”. Il y a principalement deux façons de démarrer une exploration avec Tor :

• utiliser un “hidden wiki”, soit un annuaire de liens classés par catégorie. Il en existe un certain nombre, certains sur le clear web facilement trouvables en cherchant “hidden wiki” avec un moteur de recherche classique. Il faut cependant s’attendre à ce qu’une part importante des liens ne marchent plus.
• se servir d’un moteur de recherche dédié, uniquement accessible avec Tor, dont on trouve facilement l’adresse “.onion” sur un “hidden wiki”. “Torch” ou “Ahmia” en sont des exemples. Il ne faut cependant pas s’attendre à des performances comparables à des Google ou autres DuckDuckGo : non seulement peu de résultats pour une recherche un peu ciblée, mais souvent une liste de résultats peu explicites. On ne sait donc pas toujours sur quoi on clique.

Markets

De nombreux “markets” sont disponibles sur le dark web, fonctionnant un peu comme Amazon ou Bol.com. La plupart exigent des paiements en Bitcoin (ou plus souvent Monero, qui empêche de faire le lien entre deux transactions), et proposent toute un série de produits qui ne sont pas accessibles sur des marchés plus classiques : 

• armes et munitions, du petit pistolet aux fusils d’assaut ;
• drogues et médicaments, probablement le secteur le plus fourni ;
• faux documents : passeports, permis de conduire, cartes d’identité, et ce pour de multiples pays ;
• numéros de cartes de crédit volés, d’autant plus cher que le plafond est élevé. Compter entre 50 et 100 euros le numéro ;
• fausse monnaie ;
• services :
  • hackers : des hackers proposent de nombreuses options, allant d’une DDoS, à la pénétration d’un système ou au piratage de comptes mail ou réseaux sociaux,
  • atteinte aux personnes : on trouve de nombreuses proposition de “services” : assassinat, enlèvement, agression. Certains estiment cependant qu’il ne s’agit là que de tentatives d’extorsion.

Forums

De nombreux forums sont disponibles, dans toutes les langues. Ils ont tous en commun que les participants étant intraçables, ils ne se privent pas pour faire des demandes ou propositions totalement illégales, voire carrément abjectes. Les insultes et vulgarités sont la norme. Messages ouvertement racistes, propositions ou recherches de stupéfiants, demande ou vente de contenu pédopornographique…

Data leaks

On peut trouver facilement, gratuitement ou non, une grande quantité de données volées, que ce soit sur des forums ou sur des markets. On pourrait les classer en deux catégories : 

• des listes de “credentials” : nom d’utilisateur + mot de passe, parfois avec le site concerné. Vraisemblablement obtenus par phishing ou par “keylogger”, difficile de s’assurer (sans les avoir testés, ce que nous n’avons bien sûr jamais fait) de l’actualité des données. Mais sur des millions de lignes, on peut imaginer qu’on trouvera toujours des accès fonctionnels ;
• des résultats de ransomware. Quand des pirates parviennent à s’introduire dans le système d’une entreprise, ils vont souvent chiffrer l’intégralité des données et exiger une rançon pour les rendre accessibles. Et si la rançon n’est pas payée, de nombreux groupes publient en intégralité le contenu volé. On peut trouver un certain nombre de sites, avec pour les négociations “en cours”, des “preuves” (captures d’écran de quelques documents, typiquement ; voir ci-dessous pour le piratage du groupe Ahold Delhaize par le groupe INC Ransom), et pour celles expirées, un accès à de grands volumes. On pourrait citer :  
  • les données d’une mission locale dans le Sud-Ouest de la France : listing avec les noms (dates de naissance, n° téléphones) des jeunes suivis,
  • une société pharmaceutique française, avec des plans d’usine, contrats avec des partenaires, contenu d’une base de données de test,
  • pour une Loge maçonnique française : analyse interne de sécurité, invitations, listes de membres et montants de cotisations,
  • pour les 200 GB de données du groupe néerlandais “Ahold Delhaize”, semble-t-il surtout concernant son activité aux États-Unis,
  • pour un pôle de revalidation belge, parmi de nombreuses données (gestion, achat, finances, RH…), des informations personnelles sur plus de 30.000 patients (nom, prénom, date de naissance, code de pathologie), ainsi qu’un “export” de 380.000 patients avec beaucoup de détails personnels (nom, adresse, téléphone, email, numéro de mutuelle…), mais peu de détails médicaux .

Activisme

À côté des activités illégales citées plus haut, on trouve aussi une série de sites web qui se rapprochent des raisons initiales de la création du réseau Tor. On va y trouver un certain nombre d’organisations ayant pignon sur rue, mais ayant une version “.onion” de leur site web pour recueillir les informations de lanceurs d’alerte : Greenpeace, CNN, The Guardian, ProPublica, la CIA…

On trouvera aussi un certain nombre de blogs que l’on pourrait qualifier d’activistes, de rebelles, en lutte contre les violences policières, et qui se mettent sur le dark web pour éviter la censure. Il s’agit souvent de sites web à deux accès : un sur le “clear web”, un autre sur le dark web.

Conclusions

Il se dit que les marchandises les plus “sensibles” ne s’obtiennent de personne à personne qu’après avoir établi une relation de confiance avec ceux qui les possèdent, en particulier en ce qui concerne le hacking et ses outils. N’étant rentré en contact avec personne sur le dark web, nous sommes sans doute passé à côté de tout un pan de ce qu’on pourrait y trouver.

Mais ce que nous avons pu y trouver en seulement quelques semaines d’exploration nous a convaincus que de nombreuses administrations et entreprises auraient tout intérêt à au minimum se demander si on y trouve des activités liées à leur domaine d’action, ou des données de leur personnel ou de leurs clients. Même s’il est quasiment impossible de faire disparaitre ces données, il conviendra de prendre les mesures adéquates en cas de fuite. En cas de problème, il est essentiel de se faire aider par des spécialistes. En Belgique, en fonction des circonstances, un appel au CCB (Center for Cybersecurity Belgium) ou la FCCU (Federal Computer Crime Unit, Police) sera à faire de tout urgence.