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é !

(FR) Circom est un framework pour les preuves à divulgation nulle de connaissance programmables. Il permet de prouver efficacement des connaissances ou des propriétés, tout en gardant secrètes les données sous-jacentes à partir desquelles ces connaissances ou propriétés sont dérivées.

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!

Intro

Les citoyens possèdent généralement de nombreux certificats : carte d’identité, permis de conduire, diplômes, certificats d’aptitudes pédagogiques, cartes bancaires, carte d’assurance maladie, prescriptions médicales, extrait de casier judiciaire, carte de stationnement pour personnes handicapées, titres de propriété, billets de concert… Ces documents peuvent être physiques ou numériques et contiennent des données personnelles souvent sensibles.

Lorsque vous présentez un tel certificat, vous divulguez souvent plus d’informations à propos de vous que celles strictement nécessaires. Or, cela peut poser problème, notamment dans un monde numérique. Les données sont lues en une fraction de seconde et peuvent ensuite être conservées pendant de nombreuses années, ce qui permet de dresser votre profil de manière plus complète.

Voici deux exemples :

• Pour acheter de l’alcool ou des feux d’artifice, ou pour accéder à des sites web à contenu érotique, il suffit en principe de prouver que l’on est majeur. Pour participer à des jeux de hasard ou à des paris, l’âge minimal est de 21 ans. La date de naissance exacte, sans parler du lieu de naissance ou du numéro de registre national, n’ont pas d’importance. Ce n’est qu’en cas d’abus, tel que la tricherie, que l’identité de la personne concernée doit pouvoir être révélée.
• Pour participer à un sondage organisé par la ville de Louvain, il suffit en principe de prouver que l’on réside effectivement dans cette ville et que l’on n’a pas encore participé, éventuellement en communiquant des informations supplémentaires telles que la tranche d’âge et la commune, à des fins statistiques.

Les technologies de certification couramment utilisées aujourd’hui ne permettent pas une divulgation sélective des données personnelles ; soit vous montrez le certificat complet avec toutes les données personnelles qu’il contient, soit vous ne montrez rien. Au cours des dernières décennies toutefois, de nombreux travaux de recherche et de développement ont été menés pour mettre au point une technologie capable de remédier à cela facilement. Cette technologie, appelée “titres numériques anonymes”, a déjà été abordée dans un précédent article de blog.

Il s’agit d’une technologie favorisant la confidentialité qui recourt aux preuves à divulgation nulle de connaissance (zero-knowledge (ZK) proof) pour divulguer de manière sélective des informations personnelles. Les preuves ZK permettent à une partie de prouver une affirmation (par exemple, être âgé de plus de 18 ans) à une autre partie sans divulguer plus de détails sur cette affirmation (par exemple, la date de naissance exacte). Bien que le titre numérique lui-même soit délivré par un émetteur autorisé, la divulgation sélective ne nécessite plus le recours à un tiers de confiance.

David Chaum a réalisé en 1985 les premiers travaux novateurs et révolutionnaires en proposant une monnaie numérique anonyme. Chaum mettait déjà en garde à l’époque contre l’impact des évolutions technologiques sur la vie privée des citoyens. Sur cette base, les deux premières propositions de titres numériques anonymes ont suivi rapidement. En 2000, Stefan Brands a publié sa solution U-Prove, et en 2001, Jan Camenisch (IBM) et Anna Lysyanskaya (MIT) ont proposé Idemix, une solution plus avancée.

Au cours de ces années, j’ai manié cette technologie dans le cadre de mon doctorat, ce qui m’a valu, entre autres, un best paper award à SECRYPT 2009 à Milan, avec une solution permettant aux détenteurs de titres numériques d’utiliser un service de manière anonyme, mais pas plus d’un nombre déterminé de fois par période, par exemple pas plus de 10 fois par mois.

Caractéristiques

Tout comme pour les certificats numériques classiques, un titre numérique anonyme est délivré par un émetteur autorisé (issuer ou identity provider) au détenteur (holder).
Au moyen de preuves ZK, ce dernier peut ensuite prouver de manière sélective des informations issues du titre numérique à un vérificateur (verifier).

Les caractéristiques de base des titres numériques anonymes sont les suivantes :

• Infalsifiabilité (Unforgeability). Il est impossible de falsifier un titre numérique anonyme. Seul l’émetteur peut créer des titres numériques anonymes.
• Divulgation sélective d’attributs (selective attribute disclosure). Seule une partie sélectionnée des informations contenues dans le titre numérique anonyme est divulguée. Il peut s’agir de valeurs d’attributs, telles que la date de naissance, mais aussi d’informations dérivées, telles que la majorité. Toutes les autres informations contenues dans le titre numérique restent cachées au vérificateur. Idemix et U-Prove prennent tous deux en charge cette fonctionnalité.
• Non-corrélabilité (Unlinkability). Des présentations multiples d’un même titre numérique anonyme à un vérificateur (identique ou différent) ne peuvent pas être reliées entre elles. U-Prove ne disposait pas encore de cette fonctionnalité, contrairement à Idemix.

En fonction de la technologie spécifique, des fonctionnalités supplémentaires peuvent être prises en charge, notamment :

• Durée de validité limitée. Le détenteur prouve au vérificateur que la date d’expiration du titre numérique anonyme n’est pas encore atteinte, sans divulguer d’autres informations sur cette date d’expiration.
• Révocation. Un titre numérique anonyme peut être révoqué, par exemple après que la clé privée correspondante a été compromise ou parce que les données personnelles ont été modifiées, par exemple en cas de déménagement ou de retrait du permis de conduire. Chaque fois qu’un détenteur présente un titre numérique à un vérificateur, il prouve également que l’identifiant du titre numérique figure sur une liste blanche ou qu’il ne figure pas sur une liste noire. Ces listes peuvent être compressées en une seule valeur compacte, laquelle est actualisée à chaque nouvelle révocation. C’est ce que l’on appelle un accumulateur dynamique.
• Anonymat conditionnel. En cas d’abus, l’anonymat du détenteur du titre numérique peut être levé, avec la coopération d’un tiers de confiance, et son identité est alors révélée. La justice peut ainsi faire son travail et éventuellement engager des poursuites.
• Délégation. Un détenteur de titres numériques peut déléguer des titres numériques anonymes. Une personne pourrait ainsi déléguer son droit (ou son obligation) de vote à son partenaire, ce qui équivaut alors à une procuration. Pour des raisons juridiques, la délégation ne sera généralement possible que pour des individus ayant une capacité juridique et donc pas pour des mineurs, par exemple.
• Combinabilité. Une divulgation sélective peut être dérivée de plusieurs titres numériques anonymes, potentiellement émis par différents émetteurs. Par exemple, un détenteur de titres numériques peut prouver avec une seule preuve ZK qu’il est titulaire d’un permis de conduire valide et qu’il est assuré, sans pour autant divulguer d’identifiant commun, tel que son numéro de registre national. Il prouve simplement que les deux titres numériques anonymes contiennent le même identifiant, comme illustré dans un précédent article.

Il est évident que les titres numériques anonymes constituent une technologie particulièrement puissante et recèlent un potentiel considérable. Malheureusement, cela ne signifie pas nécessairement qu’ils sont adoptés à grande échelle. Les sections suivantes traitent 1) des initiatives destinées à parfaire cette technologie et à la faire adopter, 2) de son utilisation dans la pratique et 3) des défis liés à la résistance à l’informatique quantique.

Initiatives

Lorsque j’ai commencé à travailler avec Idemix il y a environ vingt ans, la signature d’un accord de confidentialité était indispensable. Depuis, la situation s’est complètement inversée et il existe désormais divers projets open source. Les principaux sont IBM Idemix, Microsoft U-prove, Yivi et Hyperledger AnonCreds. Ces deux derniers proposent actuellement leurs propres implémentations d’Idemix.

La Commission européenne a déjà investi des dizaines de millions d’euros dans la recherche et le développement de technologies de titres numériques anonymes à travers des projets tels que PRIME (2004-2008), PrimeLife (2008-2011) et ABC4Trust (2011-2014).

Le battage médiatique autour de la blockchain (entre 2015 et 2019 environ) s’est accompagné d’un regain d’intérêt pour les titres numériques anonymes, en tant que concrétisation technologique du paradigme de l’identitié auto-souveraine (Self-sovereign identity – SSI). La blockchain et les titres numériques anonymes promettaient en effet quelque chose de très similaire : redonner le contrôle aux citoyens, en le retirant des mains des autorités et des intermédiaires. Beaucoup ont alors supposé à tort que la SSI nécessitait la blockchain. Ce n’est pas nécessairement le cas, mais la blockchain peut néanmoins jouer un rôle, notamment pour répertorier de manière distribuée les émetteurs reconnus et donc dignes de confiance.

Hyperledger est un projet open source sous l’égide de la Linux Foundation destiné à développer une technologie pour les réseaux blockchain autorisés (fermés et contrôlés). Hyperledger a adopté le paradigme SSI ; Hyperledger AnonCreds, actuellement un projet en incubation, met spécifiquement en œuvre une technologie de titres numériques anonymes.

Sovrin était le pionnier le plus influent dans le domaine de la SSI utilisant la blockchain et recourrait notamment à Hyperledger AnonCreds comme base. Malheureusement, le réseau Sovrin est passé à la trappe au début de cette année. Les raisons invoquées étaient une baisse de l’utilisation, une incertitude législative, des défis techniques et un engagement limité de la part de la communauté.

Le portefeuille d’identité numérique de l’UE (EU digital identity wallet ou EUDIW en anglais), défini dans la réglementation eiDAS 2.0 (en vigueur depuis mai 2024), offre en principe une nouvelle occasion d’exploiter le potentiel des titres numériques anonymes (avec ou sans blockchain). Malheureusement, il semble que l’on ne s’oriente pas dans cette direction. En juin 2024, un groupe de cryptographes éminents a formulé  des critiques à l’égard de la conception actuelle de l’EUDIW et estime qu’une nouvelle conception, avec un soutien explicite aux titres numériques anonymes, s’impose pour améliorer la confidentialité. La conception actuelle de l’EUDIW n’autorise par exemple pas la non-corrélabilité. L’intégration de titres numériques anonymes est l’un des “sujets en suspens”, mais aucun plan d’action n’a encore été établi à ce jour.

Depuis 2012, un projet appelé IRMA, qui signifie “I Reveal My Attributes” est en cours aux Pays-Bas. Il a été développé à l’université Radboud de Nimègue. En 2023, il a été rebaptisé Yivi. Yivi entend redonner aux citoyens le contrôle de leurs données, sans recourir à la technologie blockchain. 

Dans la pratique

Yivi dispose notamment de sa propre implémentation du protocole Idemix ainsi que de sa propre app, qui serait utilisée par des centaines de milliers de Néerlandais. Elle est proposée par la ville de Nimègue comme solution d’identité respectueuse de la vie privée. La ville l’utilise notamment pour mener des enquêtes anonymes auprès de ses habitants.

Parallèlement, les compagnies d’assurances soutiennent Yivi, étant donné que les autres solutions d’identité numérique aux Pays-Bas ne sont pas utilisables dans ce contexte ; DigiD n’est possible qu’auprès des institutions gouvernementales, iDIN passe par une banque et n’est utilisable que par les personnes titulaires d’un compte bancaire aux Pays-Bas. Les considérations pratiques semblent ici primer sur l’aspect de la vie privée.

L’administration de la province canadienne de Colombie-Britannique a investi massivement dans le développement et l’adoption de titres numériques anonymes. Elle a consacré plus d’un million de lignes de code au projet Hyperledger Aries. La Colombie-Britannique utilise également cette technologie dans la pratique, notamment avec Hyperledger AnonCreds :

• 

  OrgBook BC met à disposition de nombreuses informations sur les entreprises de la province : numéros d’entreprise, adresses, certificats d’enregistrement, licences de vente de cannabis… Afin d’accroître la confiance dans leur exactitude, ces données sont mises à disposition sous la forme de titres numériques anonymes révocables, délivrés par des organismes du secteur public. Les citoyens peuvent obtenir, stocker et présenter des titres numériques vérifiables les concernant ou concernant leur entreprise grâce à leur BC Wallet.
• Le Justice Project permet aux juges et aux avocats de consulter en ligne des documents judiciaires sensibles, auxquels seuls les juristes agréés ont accès, sans révéler leur identité.

Les applications ci-dessus se situent au niveau local. Cependant, il ne faut pas oublier que les titres numériques anonymes sont également utilisés à l’échelle mondiale.

Signal, l’application de messagerie sécurisée populaire qui compte quelque 70 millions d’utilisateurs, utilise des titres numériques anonymes pour gérer des groupes privés ; les serveurs de Signal ne voient pas quels sont les membres d’un groupe privé. Lorsqu’un membre du groupe ajoute ou supprime quelqu’un du groupe, les serveurs de Signal ne voient pas qui exécute cette action, mais seulement que cette personne en a le droit. Signal utilise pour cela des Keyed-Verification Anonymous Credentials (KVAC), i.e. des titres numériques anonymes, où l’émetteur et le vérificateur partagent une clé secrète, ce qui permet de gagner en efficacité.

Un TPM (Trusted Platform Module) est une puce de sécurité intégrée à un ordinateur. Il est notamment capable de prouver l’intégrité du système à une entité externe dans le respect de la vie privée. Pour ce faire, il utilise la technologie Direct Anonymous Attestation (DAA). Celle-ci utilise une sorte de titre numérique anonyme, lié à la puce TPM. La technologie SGX d’Intel utilise une variante de la DAA, appelée Enhanced Privacy ID (EPID). À ce jour, plus de 2,5 milliards de titres numériques EPID ont été émis. Il s’agit probablement aujourd’hui de l’application la plus réussie de la technologie des titres numériques anonymes.

Malgré ces quelques cas d’usage à l’échelle mondiale, nous ne constatons à ce jour qu’une adoption très limitée des titres numériques anonymes dans le contexte où nous les attendons le plus, à savoir la gestion des identités.

Résistance à l’informatique 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.

L’illustration ci-dessous présente les principales techniques en matière de titres numériques anonymes proposées par le monde académique. La première génération était basée sur RSA ou les courbes elliptiques. À partir de 2004, une génération basée sur les applications bilinéaires (pairings) a suivi. La troisième génération de titres numériques anonymes est basée sur les treillis et est la première génération à utiliser une cryptographie supposée résistante à l’informatique quantique.

Illustration 1 Chronologie des principales publications relatives aux titres numériques anonymes (source)

À l’heure actuelle, seuls quelques systèmes résistants à l’informatique quantique ont donc été proposés pour les titres numériques anonymes. Ces systèmes sont encore récents et leurs performances sont insuffisantes pour être utilisés dans la pratique. De plus amples recherches s’imposent donc pour trouver des solutions efficaces et résistantes à l’informatique quantique pour les titres numériques anonymes.

Nous avons mentionné plus haut qu’un groupe éminent de scientifiques spécialisés en cryptographie plaidait en faveur de la prise en charge des titres numériques anonymes dans le portefeuille d’identité numérique de l’UE (EUDIW).  Ils avancent deux arguments valables pour expliquer pourquoi la menace quantique n’est pas (encore) d’actualité.

• Les titres numériques anonymes sont utilisés pour l’authentification ; une session d’authentification n’est valable que pendant un très court laps de temps, quelques minutes tout au plus. Pensez par exemple à l’authentification avec itsme, à des années-lumière du chiffrement (par exemple, la communication), où un pirate dispose de plusieurs années pour déchiffrer les données chiffrées interceptées (harvest now decrypt later). On a ainsi beaucoup plus de temps (au moins une décennie, selon votre auteur).
• Les technologies de titres numériques anonymes les plus populaires aujourd’hui, comme celles proposées par Camenisch et Lysyanskaya en 2004, offrent une sécurité inconditionnelle ; même un pirate hypothétique disposant d’une puissance de calcul infinie (classique ou quantique) ne pourrait la briser, bien que la technologie – cela peut sembler contradictoire – utilise en coulisse des éléments constitutifs qui pourraient être brisés par de puissants ordinateurs quantiques.

Sur le plan technologique, rien n’empêche donc l’adoption de la technologie des titres numériques anonymes. Il existe toutefois un autre obstacle… la perception ! Emad Heydari Beni, chercheur en cryptographie au COSIC (KU Leuven) et chez Bell Labs, a récemment publié le message suivant sur LinkedIn : “Si ce n’est pas post-quantique, les acteurs de l’industrie ne veulent pas en entendre parler.”  La double argumentation évoquée plus haut n’est donc probablement pas suffisamment convaincante pour l’industrie.

Dans tous les cas, veillez à ce que votre solution soit crypto-agile si vous utilisez des titres numériques anonymes, afin de pouvoir migrer rapidement vers une technologie plus récente si nécessaire.

Conclusion

En résumé, après des décennies de recherche et de développement, et malgré leur nombreux avantages, les titres numériques anonymes ne sont encore que peu utilisés dans la pratique pour réellement protéger les données à caractère personnel. Leur potentiel est loin d’être pleinement exploité, même si des projets tels que Hyperledger leur donnent une impulsion positive. Grâce notamment à Signal et Intel SGX, certains types de titres numériques anonymes sont toutefois largement adoptés.

L’absence de normes constitue un obstacle à leur adoption dans le contexte de la gestion des identités. Grâce au travail préparatoire réalisé notamment par le W3C, la Decentralized Identity Foundation, l’IETF/IRTF et l’ISO, cela devrait être possible assez rapidement, à condition qu’il y ait une volonté politique, selon le groupe de cryptographes mentionné précédemment. La technologie doit toutefois relever un autre défi, à savoir devenir résistante à l’informatique quantique.

Il est donc encore trop tôt pour dire si cette technologie va s’imposer comme un outil de gestion des identités respectueux de la vie privée. Peut-être est-ce au secteur public de prendre l’initiative et de faire des titres numériques anonymes un succès.

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

Intro

Burgers hebben doorgaans heel wat certificaten. Voorbeelden zijn de identiteitskaart, rijbewijs, diploma’s, bekwaamheidsbewijzen, bankkaarten, de ziekteverzekeringskaart, medische voorschriften, een uittreksel uit het strafregister, een parkeerkaart voor personen met een handicap, eigendomsaktes en concerttickets. Deze kunnen een fysieke of digitale vorm aannemen en bevatten – vaak gevoelige – persoonsgegevens.

Wanneer we een dergelijk certificaat tonen, geven we vaak meer gegevens over onszelf prijs dan strikt noodzakelijk. Vooral in een digitale wereld kan dit problematisch worden. De data worden in een fractie van een seconde uitgelezen en vervolgens misschien vele jaren bewaard, waarbij mogelijk een ruimer profiel over jou aangelegd wordt.

Een tweetal voorbeelden:

• Om alcohol of vuurwerk te kopen, of om toegang te krijgen tot websites met erotische inhoud, moet je in principe enkel aantonen dat je meerderjarig bent. Om deel te nemen aan kansspelen of weddenschappen is de minimumleeftijd 21 jaar. De exacte geboortedatum, laat staan de geboorteplaats of rijksregisternummer, doen er niet toe. Enkel in geval van misbruik, zoals valsspelen, moet de identiteit van de persoon in kwestie onthuld kunnen worden.
• Om deel te nemen aan een bevraging georganiseerd door de stad Leuven, moet je in principe enkel aantonen dat je effectief in die stad woont, en nog niet eerder gestemd hebt, eventueel aangevuld met extra info zoals leeftijdscategorie en deelgemeente, voor statistische doeleinden.

De vandaag gangbare certificaattechnologieën laten een dergelijke selectieve prijsgave van persoonsgegevens niet toe; je toont ofwel het volledige certificaat met al de persoonsgegevens die erin vervat zitten, ofwel niets. Toch is er in de laatste decennia al heel wat onderzoek en ontwikkeling gebeurd naar een technologie die daar wel vlot mee overweg kan. Die technologie luistert naar de naam anonieme credentials en kwam reeds in een vorige blogpost aan bod.

Het is een privacy bevorderende technologie die beroep doet op zero-knowledge proofs (ZKPs) om selectief persoonsinformatie prijs te geven. ZKPs laten een partij toe een bewering (vb. ouder dan 18 jaar) aan een andere partij te bewijzen zonder verdere details over die bewering (vb. exacte geboortedatum) prijs te geven. Hoewel de credential zelf wordt uitgegeven door een geautoriseerde uitgever, hoeft bij een selectieve prijsgave verder geen beroep meer gedaan te worden op een vertrouwde partij.

David Chaum deed reed in 1985 het eerste baanbrekend en visionair werk met een voorstel voor anoniem digitaal geld. Chaum waarschuwde toen reeds voor het effect van de technologische ontwikkelingen op de privacy van burgers. Daarop verder bouwend volgden kort op elkaar de twee eerste voorstellen voor anonieme credentials. In 2000 publiceerde Stefan Brands zijn oplossing U-Prove, en in 2001 werd het geavanceerdere Idemix voorgesteld door Jan Camenisch (IBM) en Anna Lysyanskaya (MIT).

In die jaren werkte ik tijdens mijn doctoraat met die technologie, wat me onder meer een best paper award opleverde op SECRYPT 2009 in Milaan, met een oplossing die credential houders toelaat anoniem van een dienst gebruik te maken, maar niet vaker dan een vast aantal keer per tijdsvenster, bijvoorbeeld niet vaker dan 10 keer per maand.

Eigenschappen

Net zoals bij klassieke digitale certificaten, wordt een anoniem credential uitgegeven door een geautoriseerde uitgever (de issuer of identity provider) aan de eigenaar (de holder). De laatste kan vervolgens, m.b.v. ZKPs selectief informatie uit de credential bewijzen aan een verifier.

De basiseigenschappen van anonieme credentials zijn:

• Onvervalsbaarheid (Unforgeability). Het vervalsen van een anonieme credential is onmogelijk. Enkel met behulp van de issuer kunnen anonieme credentials aangemaakt worden.
• Selectieve attribuutprijsgave (selective attribute disclosure). Slechts een geselecteerd deel van de informatie die in het anonieme credential vervat zit, wordt prijsgegeven. Dit kunnen attribuutwaarden zijn, zoals geboortedatum, maar ook afgeleide informatie, zoals meerderjarigheid. Alle andere informatie in de credential blijft verborgen voor de verifier. Zowel Idemix als U-Prove ondersteunen dit.
• Onlinkbaarheid (Unlinkability). Meerdere vertoningen van eenzelfde anonieme credential aan (eenzelfde of andere) verifier kunnen niet aan elkaar gekoppeld worden. U-Prove had deze eigenschap nog niet, Idemix wel.

Afhankelijk van de specifieke technologie kunnen bijkomende eigenschappen ondersteund worden, waaronder:

• Beperkte geldigheidsduur. De holder bewijst aan de verifier dat de vervaldatum van de anonieme credential nog niet bereikt is, zonder verdere info over die vervaldatum prijs te geven.
• Revocatie. Een anoniem credential kan gerevoceerd worden, bijvoorbeeld nadat de bijhorende private sleutel gecompromitteerd werd of omdat de persoonsgegevens gewijzigd zijn, bijvoorbeeld door een verhuis of intrekken rijbewijs. Telkens wanneer een holder een credential toont aan een verifier, bewijst hij ook dat de identifier van de credential zich op een whitelist bevindt of dat deze identifier zich niet op een blacklist bevindt. Die lijsten kunnen gecomprimeerd worden tot één compacte waarde, die geactualiseerd wordt bij elke nieuwe revocatie. Dit noemt met een dynamische accumulator.
• Conditionele anonimiteit. In geval van misbruik kan de anonimiteit van de credential holder, met medewerking van een vertrouwde partij, opgeheven worden en wordt de identiteit dus onthuld. Op die manier kan het gerecht zijn werk doen en eventueel tot vervolging overgaan.
• Delegatie. Een credential holder kan anonieme credentials delegeren naar andere personen. Een persoon zou zo bijvoorbeeld haar recht (of plicht) om te stemmen kunnen delegeren naar haar partner. Dit is dan het equivalent van een volmacht. Delegatie zal omwille van juridische redenen veelal enkel door handelingsbekwame personen uitgevoerd kunnen worden, en dus niet door vb. minderjarigen.
• Combineerbaarheid. Een selectieve prijsgave kan afgeleid worden uit meerdere anonieme credentials, potentieel uitgegeven door verschillende issuers. Een credential holder kan bijvoorbeeld met één enkel ZKP bewijzen dat hij over een geldig rijbewijs beschikt en verzekerd is, zonder daarbij een gemeenschappelijke identifier, zoals rijksregisternummer, prijs te gegeven. Hij bewijst enkel dat beide anonieme credentials dezelfde identifier bevatten, zoals ook geïllustreerd in een eerder artikel.

Het is duidelijk dat anonieme credentials een bijzonder krachtige technologie zijn en heel wat potentieel hebben. Dit betekent helaas niet per se dat er ook brede adoptie is. De volgende secties bespreken 1) de initiatieven om de technologie verder te ontwikkelen en ingang te doen vinden, 2) het gebruik ervan in de praktijk en 3) de uitdagingen m.b.t. kwantumresistentie.

Initiatieven

Toen ik ongeveer twintig jaar geleden met Idemix aan de slag ging, kon dit enkel mits het ondertekenen van een geheimhoudingsverklaring. Ondertussen is de situatie helemaal omgekeerd en zijn er diverse open source projecten. De voornaamste zijn IBM Idemix, Microsoft U-prove, Yivi en Hyperledger AnonCreds. Die twee laatsten bieden momenteel eigen implementaties van Idemix aan.

Vanuit de Europese Commissie werden via projecten zoals PRIME (2004-2008), PrimeLife (2008-2011) en ABC4Trust (2011-2014) reeds tientallen miljoenen euro’s geïnvesteerd in onderzoek en ontwikkeling naar anonieme credential technologie.

De blockchain hype (ruwweg 2015-2019) ging gepaard met een hernieuwde interesse in anonieme credentials, als technologische invulling van het Self-sovereign identity (SSI) paradigma. Blockchain en anonieme credentials beloofden immers iets zeer gelijkaardig; de controle teruggeven aan de burger, uit de handen van de allerlei autoriteiten en men-in-the-middle. Velen gingen er toen onterecht vanuit dat SSI blockchain vereist. Dat is niet noodzakelijk, maar toch kan blockchain een rol spelen, onder meer om op een gedistribueerde wijze bij te houden welke issuers erkend zijn, en dus vertrouwd kunnen worden.

Hyperledger is een open-source project onder de vleugels van de Linux Foundation dat bouwt aan technologie voor permissioned (gesloten, gecontroleerde) blockchain netwerken. Hyperledger omarmde het SSI-paradigma; Hyperledger AnonCreds, momenteel een incubatieproject, implementeert specifiek anonieme credential technologie.

Sovrin was de meest toonaangevende pionier in SSI m.b.v. blockchain en gebruikte onderliggend onder meer Hyperledger AnonCreds. Helaas werd het Sovrin netwerk begin dit jaar uitgedoofd. De redenen die gegeven werden waren een dalend gebruik, wetgevende onzekerheid, technische uitdagingen en beperkte betrokkenheid vanuit de community.

De EU digital identity wallet (EUDIW), gedefinieerd in de eiDAS 2.0 regulering (van kracht sinds mei 2024), biedt in principe opnieuw een kans om het potentieel van anonieme credentials te ontsluiten (met of zonder blockchain). Toch lijkt men helaas niet in die richting te kijken.  Een groep van vooraanstaande cryptografen formuleerde in juni 2024 kritieken op het huidige ontwerp van de EUDIW en menen dat een nieuw design, met expliciete ondersteuning voor anonieme credentials, nodig is om de privacy te verbeteren. Het huidige EUDIW-ontwerp laat bijvoorbeeld geen onlinkbaarheid toe. Integratie van anonieme credentials is één van de “open topics”, maar een roadmap ontbreekt vooralsnog.

Sinds 2012 loopt er in Nederland een project genaamd IRMA, wat staat voor I Reveal My Attributes. Het werd ontwikkeld aan de Radboud Universiteit in Nijmegen. In 2023 werd het omgedoopt naar Yivi. Yivi wil de controle over haar gegevens teruggeven aan de burger, zonder daarbij een beroep te doen op blockchain technologie.

In de praktijk

Yivi heeft onder meer zijn eigen implementatie van het Idemix protocol alsook een eigen app, die door honderdduizenden Nederlanders gebruikt zou worden. Het wordt aangeboden door de stad Nijmegen als privacy-vriendelijke identiteitsoplossing. De stad gebruikt het onder meer voor anonieme bevragingen van Nijmegenaren.

Daarnaast ondersteunen verzekeringsinstellingen Yivi, gezien de andere digitale  identiteitsoplossingen in Nederland in dit kader niet bruikbaar zijn; DigiD is alleen mogelijk bij overheidsinstellingen, iDIN verloopt via een bank en is enkel bruikbaar door mensen met een bankrekening in Nederland. Hier lijkt de praktische overweging belangrijker dan het privacy-aspect.

Het bestuur van de Canadese provincie British Columbia heeft stevig geïnvesteerd in de ontwikkeling en adoptie van anonieme credentials. Ze heeft meer dan een miljoen regels code gecommit naar het Hyperledger Aries project. British Columbia gebruikt de technologie, samen met onder meer Hyperledger AnonCreds ook in de praktijk:

• 

  OrgBook BC stelt heel wat informatie over bedrijven in de provincie ter beschikking: ondernemingsnummers, adressen, registratiebewijzen, licenties om cannabis te verkopen, etc. Om het vertrouwen in de juistheid ervan te verhogen, worden deze data ter beschikking gesteld onder de vorm van revoceerbare anonieme credentials, uitgegeven door publieke sectororganisaties. Burgers kunnen met hun BC Wallet verifiable credentials over henzelf of over hun onderneming verkrijgen, opslaan en tonen.
• Het Justice Project laat rechters en advocaten toe gevoelige gerechtelijke documenten, waar enkel erkende juristen toegang tot mogen hebben, online op te vragen zonder hun identiteit prijs te geven.

Bovenstaande toepassingen situeren zich op een lokaal niveau. Toch mogen we niet vergeten dat anonieme credentials ook op globale schaal toegepast worden.

Signal, de populaire beveiligde berichten app die ongeveer 70 miljoen gebruikers telt, maakt gebruik van anonieme credentials voor het beheer van private groepen. De Signal servers zien niet wie tot een private groep behoort. Wanneer een groepslid iemand aan de groep toevoegt of eruit verwijdert, zien de Signal servers niet wie dit doet, enkel dat die persoon het recht daartoe heeft. Signal gebruikt daarvoor Keyed-Verification Anonymous Credentials (KVACs), wat anonieme credentials zijn, waarbij de issuer en de verifier een geheime sleutel delen, wat leidt tot efficiëntiewinsten.

Een TPM (Trusted Platform Module) is een security chip in een computer. Het is, onder andere, in staat om op een privacyvriendelijke manier de integriteit van het system aan een externe entiteit te bewijzen. Daarvoor maakt het gebruik van Direct Anonymous Attestation (DAA). DAA gebruikt een soort anonieme credential, gekoppeld aan de TPM-chip. Intels SGX gebruikt een DAA-variant, genaamd Enhanced Privacy ID (EPID). Ondertussen werden meer dan 2,5 miljard EPID-credentials uitgegeven. Het is vandaag wellicht de meest succesvolle toepassing van anonieme credential technologie.

Ondanks deze enkele globale use cases zien we tot op vandaag slechts een zeer beperkte adoptie van anonieme credentials in de settings waar we het het meest zouden verwachten: identiteitsbeheer.

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.

De onderstaande figuur geeft een overzicht van de belangrijkste technieken voor anonieme credentials die door de academische community voorgesteld werden. De eerste generatie was gebaseerd op RSA of elliptische krommen. Vanaf 2004 volgde een generatie gebaseerd op bilineaire afbeeldingen (pairings). De derde generatie anonieme credentials is gebaseerd op lattices en is de eerste generatie die gebruik maakt van cryptografie die verondersteld is kwantumresistent te zijn.

Figuur 1 Tijdlijn van belangrijkste publicaties m.b.t. anonieme credentials (bron)

Momenteel zijn er dus slechts enkele kwantumresistente systemen voor anonieme credentials voorgesteld. Deze systemen zijn nog jong en onvoldoende performant om in de praktijk inzetbaar te zijn. Er is dus meer onderzoek vereist naar efficiënte kwantumresistente oplossingen voor anonieme credentials.

Dit artikel vermeldde reeds dat een vooraanstaande groep wetenschappers in cryptografie ervoor pleiten om ondersteuning voor anonieme credentials  in de EU digital identity wallet (EUDIW) te voorzien. Ze geven twee geldige argumenten waarom de kwantumdreiging niet of nog niet van toepassing is.

• Anonieme credentials worden gebruikt voor authenticatie; een authenticatiesessie blijft maar een zeer korte tijd geldig; niet meer dan enkele minuten. Denk bijvoorbeeld aan authenticatie met ItsMe. Dit staat in schril contrast tot encryptie (bijvoorbeeld communicatie), waarbij een aanvaller vele jaren heeft om de onderschepte vercijferde data te decrypteren (harvest now decrypt later). We kunnen voor authenticatie dus veel korter op de bal spelen en hebben dus veel meer tijd (minstens een decennium, volgens jouw schrijver).
• De vandaag meest populaire anonieme credential-technologieën, zoals diegene voorgesteld door Camenisch en Lysyanskaya in 2004 bieden onvoorwaardelijke veiligheid; zelfs een hypothetische aanvaller met oneindige (klassieke of kwantum-) rekenkracht zou ze niet kunnen breken, hoewel de technologie – dit kan contradictorisch klinken – onderliggend gebruik maakt van bouwblokken die wel met krachtige kwantumcomputers gebroken zouden kunnen worden.

Er zijn dus geen technologische redenen die de adoptie van anonieme credential-technologie in de weg staan. Wel is er nog een ander obstakel… perceptie! Emad Heydari Beni, een onderzoeker cryptografie aan COSIC (KU Leuven) en Bell Labs, postte onlangs op LinkedIn het volgende bericht: “Indien het niet postkwantum is, willen de mensen uit de industrie niet eens naar je luisteren”. Bovenstaande tweeledige argumentatie is bijgevolg wellicht onvoldoende overtuigend voor de industrie.

Zorg er in elk geval voor dat je oplossing crypto-agile is als je met anonieme credentials aan de slag gaat, zodat je snel kan migreren naar een nieuwere technologie wanneer nodig.

Conclusie

Samengevat worden anonieme credentials na decennia onderzoek en ontwikkeling en ondanks hun potentieel in de praktijk nog maar in beperkte mate gebruikt om persoonsgegevens echt te beschermen. Haar potentieel wordt nog bijlange niet ten volle benut, al geven projecten zoals Hyperledger er wel een positieve stimulans aan. Ook worden dankzij onder meer Signal en Intel SGX specifieke types anonieme credentials wel degelijk breed geadopteerd.

Een obstakel voor de adoptie in de context van identiteitsbeheer is het gebrek aan standaarden. Dankzij het voorbereidend werk door onder meer W3C, de Decentralized Identity Foundation, IETF/IRTF en ISO zou dat, mits een politieke wil, vrij vlot mogelijk moeten zijn, aldus de eerder vermeldde groep cryptografen. De technologie heeft trouwens nog een andere uitdaging op haar pad, met name overtuigend kwantumresistent worden.

Het blijft momenteel dus koffiedik kijken of de technologie zal doorbreken als tool voor privacyvriendelijk identiteitsbeheer. Misschien is het aan de publieke sector om hier het voortouw in te nemen en anonieme credentials tot een succesverhaal te maken.

Aarzel niet ons te contacteren bij interesse!

Experience has taught us that such migrations are difficult, slow and expensive processes. Organisations must therefore build crypto agility into their systems: the flexibility to deal with this reality quickly and easily.

During our free webinar on Thursday 12th of June 2025, Kristof Verslype took a closer look at crypto agility: why is it necessary, what does it mean in practice and where do we stand today? Kristof is a researcher and cryptographer at Smals Research.

The session was held in English. The webinar is free but reserved for public sector employees and Smals staff.

Recording

Presentation