Depuis l’essor de l’engouement pour les grands modèles de langage, la plupart des développeurs ont sans doute déjà pu constater le gain de productivité que ces outils peuvent offrir, à condition de les utiliser correctement. Dans cet article de blog, nous explorons la possibilité d’aller plus loin : l’IA offre-t-elle une aide suffisante afin de maîtriser le legacy code ?

Le recours aux grands modèles de langage (Large Language Model – LLM) en programmation est en effet bien connu à présent : cela va de la formulation de questions à un chatbot (“comment écrire un algorithme dans Java qui…”), à un code completion de plus en plus intelligent et étendu (saisie automatique de ce que vous souhaitez taper dans l’éditeur), jusqu’au vibe coding complet (dans l’IDE, ou même simplement dans un terminal) : des agents IA rédigent, à l’aide de prompts, des pans entiers de code sur votre machine – oui, même des applications fonctionnelles.

Nous avons donné une définition très large du code legacy dans un précédent article de blog. Commençons donc par préciser ce que nous entendons par “legacy” et par mieux illustrer le “degré de difficulté” des projets legacy.

“Ancien” code : une multitude de possibilités

Il n’existe pas vraiment de définition officielle du code legacy ; généralement, on parle de l’utilisation d’une technologie qui n’est plus prise en charge, difficile à maintenir, ou simplement de “code dont on hérite de quelqu’un d’autre”. Il s’agit évidemment toujours de code encore en service, et donc important. Ironiquement, les applications les plus critiques sont souvent celles qui existent depuis des années et auxquelles on “fait confiance” depuis longtemps, mais sans les entretenir correctement.

L’IA peut nous aider à entretenir n’importe quel code ; nous allons donc présenter un spectre allant du code legacy le plus ancien et le plus problématique au code de projets ne nécessitant qu’une petite mise à jour. À une extrémité du spectre, on trouve des programmes écrits dans des langages de programmation obsolètes, selon une architecture dépassée, utilisant des bases de données qui ne sont plus d’actualité et fonctionnant sur des serveurs équipés de systèmes d’exploitation qui ne sont plus pris en charge : avec ces géants, on doit souvent craindre une défaillance critique à la moindre modification erronée. À l’autre extrémité, on trouve des logiciels assez bien entretenus, mais qui utilisent une bibliothèque logicielle qui n’est plus la version la plus récente : il est généralement très facile de les remettre entièrement à jour. Enfin, quelque part entre les deux, on trouve des applications pour lesquelles la plupart des développeurs n’utiliseraient pas encore le terme Legacy, mais qui nécessitent néanmoins des migrations complexes, avec par exemple un ou deux frameworks obsolètes à remplacer.

Que pouvons-nous en faire ? Les LLM offrent-ils d’autres possibilités en fonction de la position du projet sur ce spectre ? Jusqu’à présent, nos recherches se sont concentrées sur la partie gauche de ce spectre ; la suite de cet article portera donc davantage sur les possibilités d’aborder le “véritable” legacy. Plus tard dans l’année, nous approfondirons également ce que nous pouvons faire en matière de migrations et d’updates.

Utilisation des LLM sur des bases de code legacy

Il est clair qu’un simple prompt “réécris ce programme selon les normes modernes” ne fonctionnera pas (même si certains fournisseurs affirment que cela sera bientôt possible). Nous devrons poser des questions un peu plus concrètes et décomposer le travail en plusieurs étapes. Il y a en fait deux choses que nous pouvons faire avec notre code legacy : le réécrire et le documenter.

Réécriture du code legacy

Lorsque nous commençons à réécrire du code, nous devons souvent tenir compte du fait que la reconstruction complète d’un très grand projet est une tâche trop difficile. Il est possible d’obtenir des “quick wins” en réécrivant stratégiquement certaines parties d’un projet, qui seront ensuite réutilisées dans un contexte plus large, où une équipe humaine et l’IA reconstruiront l’application dans les règles de l’art. Nos expériences nous ont montré qu’il était trop ambitieux d’attendre de l’IA qu’elle utilise une architecture entièrement nouvelle tout en traduisant l’ancien code vers le nouveau. En revanche, il est possible de “vibe coder” une grande partie de la charpente typique d’un nouveau projet, puis d’y injecter de manière ciblée un certain nombre de morceaux de code qui sont des traductions de parties d’un projet legacy. En tant qu’êtres humains, notre tâche consiste à indiquer clairement quelle architecture nous attendons et quelles sont les règles de qualité du code nouveau.

L’un des principaux défis liés à la réécriture de code à l’aide de l’IA consiste à tester l’exactitude de la traduction : le code fait-il toujours ce qu’il faisait auparavant (indépendamment du fait que cela soit souhaitable, car même le business case peut parfois être trop obsolète dans le cas d’un projet legacy) ? Pour les projets relativement récents, il existe déjà de nombreux tests que nous pouvons effectuer pour vérifier l’exactitude, mais avec les anciens systèmes legacy, nous sommes souvent confrontés au problème que l’application est simplement testée en production, ou du moins avec des données de production : il n’y a pas de tests spécifiques ni même de données de test pouvant être utilisées en toute sécurité. Dans ce cas, il s’agit de créer un environnement dans lequel nous pouvons tester le nouveau code en toute sécurité, ce qui est généralement un travail ad hoc et demande une certaine créativité. Nous ne pouvons pas envoyer de données de production vers le cloud, nous devons donc nous assurer que le LLM ne puisse pas les lire. Ce serait plus simple si nous pouvions utiliser des LLM fonctionnant en local, mais pour l’instant, ceux-ci ne sont pas encore assez puissants (quand ils sont disponibles) pour effectuer des tâches aussi complexes avec du code legacy.

L’interface utilisateur constitue un autre défi : dans les projets plus anciens, celle-ci est souvent obsolète et il faut construire une nouvelle GUI à partir de zéro. Cela pose toutefois le problème de ne plus disposer d’une base de référence dans l’ancien projet : la nouvelle interface devra généralement être testée manuellement par des personnes. J’espère toutefois que nous verrons des progrès dans ce domaine dans un avenir proche, en ce qui concerne les possibilités de l’IA. En effet, nous voyons déjà apparaître des systèmes capables de contrôler l’intégralité de votre ordinateur (comme OpenClawd), et l’intégration avec des frameworks plus traditionnels pour le test d’une interface graphique fait également partie des possibilités.

Enfin, les petits projets legacy constituent également un domaine où nous pouvons obtenir des résultats rapides. Si nous utilisons un programme legacy petit à moyen, doté de fonctionnalités limitées et d’une GUI simple, ou présentant un input et un output clairs en cas de batch processing, et qu’il n’existe aucun business case justifiant son intégration dans une autre méthode de travail, nous pouvons alors tenter une approche directe pour construire une version moderne dans un nouveau langage de programmation à l’aide de l’IA. Dans ce cas, il faudra tout de même bien tester et adopter une approche structurée avec un accompagnement des développeurs humains, mais il est possible d’essayer cette méthode pour des applications non critiques. Une application à usage interne, par exemple, constitue généralement un bon premier candidat.

Documentation du code legacy

Parfois, la réécriture du code legacy avec l’IA est un peu trop ambitieuse, ou nous avons besoin de plus d’informations avant de nous y risquer. Il peut être intéressant de se tourner d’abord vers la documentation : l’IA peut également nous aider à faire en sorte que l’exploration d’une base de code legacy ressemble un peu moins à de l’archéologie de haut niveau.

Expliquer un morceau de code de petite à moyenne taille et en extraire la logique business, ou analyser un morceau plus important et en expliquer la structure et l’architecture, tout cela est tout à fait possible avec les grands modèles de langage actuels. Il est toutefois possible d’aller plus loin : il est possible de créer des outils d’IA pour l’aider à explorer la base de code et, par exemple, à générer des diagrammes illustrant les dépendances entre les segments de code. Ou bien on peut lui faire écrire des scripts afin de structurer soigneusement ses conclusions après chaque analyse dans un fichier texte pour elle-même et un PDF destiné à l’utilisateur humain.

Il est également possible d’adopter une approche hiérarchique : commencer par explorer la base de code, puis approfondir progressivement l’analyse des différents modules afin d’obtenir de plus en plus de détails et de compléter l’analyse. Il s’agit là de l’approche top-down, que nous pouvons toutefois compléter par une version bottom-up : une fois que nous sommes allés en profondeur, nous pouvons à nouveau demander un résumé afin de construire une présentation mieux documentée de la situation dans son ensemble.

Il est toutefois important ici de savoir à l’avance ce que nous souhaitons exactement atteindre. Une analyse générale d’une base de code par l’IA peut s’avérer intéressante lorsque les utilisateurs humains ne connaissent pas du tout le système et souhaitent disposer de points de repère pour se familiariser avec celui-ci.

Cependant, lorsque l’objectif est de pouvoir assurer la maintenance de la base de code, il est préférable de mettre en place un système proposant un chatbot qui connaît le contexte spécifique et les particularités du projet legacy, et qui peut répondre à des questions très ciblées à ce sujet. Cela est possible, par exemple, dans CoPilot Studio. Si cela ne fonctionne pas correctement, il est possible d’envisager de construire manuellement une knowledge base en utilisant l’IA qui pourra ensuite être utilisée par l’IA pour répondre aux questions.

Une autre option consiste à extraire des informations spécifiques de la base de code, telles que la logique business par module individuel, ou du pseudocode pouvant aider les développeurs humains à réimplémenter cette logique dans un autre projet. (Et bien sûr, une IA peut également être mise à contribution lors de cette deuxième étape).

Avec une touche de créativité, nous pouvons concevoir une meilleure approche pour la plupart des analyses ad hoc que celle consistant à “se contenter d’analyser à tout va”. Et la documentation d’un système legacy peut tout simplement constituer une première étape vers sa réécriture.

Conclusion : professionnels recherchés

Comme mentionné précédemment, les LLM nous offrent progressivement des possibilités très puissantes pour traiter nos bases de code legacy, surtout lorsque nous avons accès aux modèles volumineux et puissants disponibles aujourd’hui. Nous constatons toutefois qu’il s’agit en réalité d’une boîte à outils très bien fournie, comprenant plusieurs “power tools” puissants, et que nous devons savoir ce que nous voulons en faire et comment les utiliser au mieux.

Tout n’est pas encore entièrement automatisé : nous aurons donc toujours besoin de bons professionnels pour tirer le meilleur parti de ces outils. Notre conseil aux développeurs est de ne surtout pas avoir peur de l’IA et de l’utiliser régulièrement lors de l’analyse et du développement de logiciels : l’expérience est la meilleure école pour former les bons professionnels dont nous avons besoin dans ce domaine.

Pour l’instant, la conclusion est donc la suivante : pour le code legacy, l’IA n’est pas une panacée, mais une boîte à outils pratique qu’il vaut mieux essayer dans le cadre d’une approche plus large. Comme indiqué, nous nous pencherons plus tard dans l’année sur le milieu et la partie droite du spectre du code legacy. Nous pensons qu’il existe ici davantage de possibilités d’automatisation de certains workflows, surtout si nous exploitons davantage les agents. Il est donc possible que, pour des projets un peu plus simples et répétitifs, nous puissions évoluer du “professionnel” vers “l’usine”.

Sinds de hype van grote taalmodellen is losgebarsten, zullen de meeste ontwikkelaars ondertussen al wel geproefd hebben van de productiviteitswinst die deze tools, mits correct gebruik, kunnen bieden. In deze blog onderzoeken we of we verder kunnen gaan dan dat: biedt AI ook voldoende hulp bij het beheersen van Legacy Code?

Het inzetten van Large Language Models (LLM) bij het programmeren is inderdaad ondertussen stilaan goed gekend: het gaat van vragen stellen aan een chatbot (“hoe schrijf ik in Java een algoritme dat … “), overheen steeds slimmere en langer wordende code completion (automatisch aanvullen wat je wil typen in de editor), tot volledige vibe coding (in de IDE, of zelfs gewoon in een terminal): AI agenten, via prompts, hele stukken code – ja, zelfs werkende toepassingen – laten schrijven op je machine.

In een vorige post rond legacy code, gaven we een erg brede definitie. Laten we dus vooreerst iets duidelijker stellen wat we met Legacy bedoelen, en de “moei- lijkheidsgraad” van Legacy projecten beter illustreren.

“Oude” code: een spectrum aan mogelijkheden

Er is niet echt een officiële definitie van legacy code; meestal spreekt men van het gebruik van niet langer ondersteunde technologie, moeilijk te onderhouden, of simpelweg “code die je van iemand anders erft”. Het gaat uiteraard altijd wel om code die nog in gebruik, en dus belangrijk is. Ironisch genoeg, zijn het vaak de meest kritische toepassingen, die al jaren meegaan en waar men al jaren “op vertrouwt”, maar dan zonder ze goed te onderhouden.

AI kan ons helpen bij het onderhoud van eender welke code, dus we zullen een spectrum demonstreren dat van de oudste, ergste legacy code gaat, tot code van projecten die slechts een kleine update nodig heeft. Aan de ene kant van het spectrum heb je programma’s, geschreven in ouderwetse programmeertalen, volgens een achterhaalde architectuur, gebruik makend van databases die niet meer van deze tijd zijn, en draaiende op servers met niet langer ondersteunde besturingssystemen: bij deze mastodonten moet men vaak bang zijn dat ze kritisch zullen falen bij de kleinste verkeerde wijziging. Helemaal aan de andere kant heb je vrij goed onderhouden software, waarin een softwarebibliotheek wordt gebruikt die niet meer de meest recente versie is: meestal een koud kunstje om ze weer helemaal up-to-date te krijgen. Ergens in het midden vind je, ten slotte, toepassingen terug waarbij de meeste developers nog niet meteen het woord Legacy in de mond zullen nemen, maar waar wel moeilijke migraties dienen te gebeuren, met b.v. een verouderd framework of twee dat zou moeten worden vervangen.

Wat kunnen we hier nu mee? Bieden LLMs ons andere mogelijkheden naargelang de plaats van het project op dit spectrum? Ons onderzoek heeft zich tot nu toe op de linkerkant van dit spectrum gefocust, dus het vervolg van deze blogpost zal veeleer over de mogelijkheden gaan om “échte” Legacy aan te pakken. Later dit jaar gaan we ook verder uitdiepen wat we met migraties en updates kunnen doen.

Gebruik van LLMs op Legacy Codebases

Het is duidelijk dat de eenvoudige prompt “herschrijf mij dit programma volgens moderne standaarden” niet zal werken (al beweren sommige vendors dat dit eraan zit te komen). We zullen iets concretere zaken gaan vragen, en het werk ook enigszins in stukjes moeten kappen. Verder zijn er eigenlijk twee zaken die we kunnen gaan doen met onze legacy code: ze herschrijven en ze documenteren.

Herschrijven van Legacy Code

Als we beginnen met code herschrijven, zullen we er vaak rekening mee moeten houden dat een heel groot project voldoende goed herbouwen een te moeilijke opgave is. We kunnen “quick wins” behalen door strategisch een aantal zaken te gaan herschrijven van een project, en die stukken dan te gebruiken in een ruimere context, waarbij een team van mensen en AI de toepassing opnieuw bouwen volgens de regels van de kunst. Bij onze experimenten stelden we vast dat het een brug te ver was om van het AI te verwachten een volledig nieuwe architectuur te gebruiken, tegelijk met het vertalen van oude code naar nieuwe. Wat wel mogelijk is, is om heel wat van de typische scaffolding van een nieuw project te vibe coden, en daar dan gericht een aantal stukken code in te injecteren die vertalingen zijn van stukjes van een legacy project. Als mens is het onze taak om duidelijk aan te geven welke architectuur we verwachten, en wat de kwaliteitsregels zijn van de nieuw geschreven code.

Eén van de grotere uitdagingen bij het herschrijven van code met behulp van AI, is het testen van de correctheid van de vertaling: doet de code nog wat ze vroeger deed (los van het feit of dit wenselijk is, want zelfs de business case kan soms te verouderd zijn in geval van Legacy)? Bij redelijk nieuwe projecten zullen er reeds heel wat testen bestaan die we kunnen uitvoeren om de correctheid na te gaan, maar bij legacy hebben we vaak het probleem dat de toepassing eenvoudigweg wordt getest in productie, of op zijn minst met productiedata: er zijn geen specifieke tests of zelfs maar veilig bruikbare testdata. In dat geval komt het erop neer een omgeving te creëren waarin we de nieuwe code op een veilige manier kunnen testen, wat meestal ad hoc werk is en enige creativiteit vraagt. We mogen namelijk geen productiedata naar de Cloud sturen, dus we moeten ervoor zorgen dat het LLM deze niet kan lezen. Het zou eenvoudiger zijn als we lokaal draaiende LLMs zouden kunnen gebruiken, maar voorlopig zijn deze nog niet krachtig genoeg (als ze al beschikbaar zijn) om dergelijke complexe taken uit te voeren met legacy code.

Een andere uitdaging is de gebruikersinterface: bij oudere projecten is deze vaak achterhaald en moet er, vanaf de grond, een nieuwe GUI (Graphical User Interface) worden opgebouwd. Dat geeft echter het probleem dat je geen basis meer hebt in het oude project om mee te vergelijken: de nieuwe interface zal doorgaans manueel door mensen moeten worden getest. Ik verwacht echter dat we op dit vlak nog vorderingen zullen zien in de nabije toekomst, wat de mogelijkheden van het AI betreft. We zien namelijk al systemen opduiken die je volledige computer kunnen besturen (zoals OpenClawd of het “Computer Use” van Anthropic), en ook integratie met meer traditionele raamwerken voor het testen van een GUI behoort tot de mogelijkheden.

Waar we, ten slotte, ook quick wins mee kunnen halen, zijn kleinere Legacy projecten. Als we een klein tot matig groot legacy programma gebruiken, met bepertke functionaliteit en een eenvoudige GUI of een duidelijke input en output in geval van batch processing, en geen business case om deze te integreren in een andere manier van werken, dan kunnen we een rechttoe rechtaan aanpak proberen om een moderne versie in een nieuwe programmeertaal te bouwen met AI. We moeten dan nog altijd goed testen en een gestructureerde aanpak hebben met bijsturingen door menselijke developers, maar het wordt wel feasible om dit voor niet-kritische toepassingen te gaan uitproberen. Een intern gebruikte toepassing is bijvoorbeeld een typische goede eerste kandidaat.

Documenteren van Legacy Code

Soms is herschrijven van Legacy met AI net iets te ambitieus, óf we hebben meer informatie nodig voor we er ons aan wagen. In dat geval kan het interessant zijn om eerst richting documentatie te kijken: het AI kan ons ook helpen om het verkennen van een legacy codebase net iets minder op archeologie voor gevorderden te doen lijken.

Van een klein tot matig stuk code uitleggen en er de business logica uithalen, of een groter stuk analyseren en de opbouw en architectuur uitleggen: dat kan met de huidige grote taalmodellen zonder meer. We kunnen echter verder gaan: we kunnen het AI tools laten bouwen om zichzelf te helpen de codebase te verkennen, en b.v. diagrammen te voorzien van de afhankelijkheden tussen de stukken code. Of we kunnen het scripts laten maken om de bevindingen na elk stuk analyse netjes te structureren in een tekstbestand voor zichzelf en een pdf voor de menselijke gebruiker.

We kunnen ook hiërarchisch werken: eerst een verkenning van de codebase doen, en dan telkens dieper duiken in de verschillende modules, om meer en meer detail te verkrijgen en de analyse aan te vullen. Dat is de top-down aanpak, die we echter kunnen aanvullen met een bottom-up versie: eens we tot in de diepte zijn gegaan, kunnen we weer zaken laten samenvatten om van het grotere plaatje een beter geïnformeerde uiteenzetting op te bouwen.

Hier is het wel van belang dat we van tevoren weten wat we precies willen bereiken. Een algemene analyse van een codebase door het AI kan interessant zijn wanneer de menselijke gebruikers het systeem nog totaal niet kennen en aanknopingspunten willen hebben om zaken te leren, maar biedt meestal weinig extra aan mensen die de codebase reeds beheersen.

Maar wanneer het doel is om de codebase te kunnen onderhouden, kunnen we eventueel een systeem opbouwen waarbij we een chatbot aanbieden die de specifieke context en bijzonderheden van het legacy project kent, en daar heel gerichte vragen over kan beantwoorden. Dit kan b.v. in CoPilot Studio. Wanneer dat niet goed genoeg werkt, kunnen we nog overwegen om manueel een knowledge base op te bouwen, gebruik makend van het AI, die dan weer door het AI kan worden gebruikt om vragen te beantwoorden.

Nog een andere optie bestaat eruit dat we specifieke informatie uit de codebase willen extraheren, zoals de business logica per afzonderlijke module, of pseudocode die menselijke developers kan helpen om de logica in een ander project te herimplementeren. (En uiteraard kan bij die tweede stap ook weer een AI worden ingezet.)

Kortom, met een beetje creativiteit kunnen we voor de meeste ad hoc analyses een betere aanpak verzinnen dan “analyseer er maar gewoon op los”. En het documenteren van een legacy systeem kan ook gewoon een eerste opstap zijn naar het herschrijven.

Besluit: vakmannen gevraagd

Zoals we hebben aan-gekaart, bieden LLMs ons stilaan erg krachtige mogelijkheden om onze Legacy Codebases aan te pakken, zéker wanneer we toegang hebben tot de grote en krachtige modellen die vandaag beschikbaar zijn. We zien echter ook dat het eigenlijk een heel goed gevulde gereedschapskoffer is, met een aantal krachtige “power tools”, en dat we moeten weten wat we ermee willen bereiken en hoe we deze best kunnen gebruiken.

We zitten nog niet op het punt dat alles automatisch gaat: we zullen dus nog steeds goede vakmannen nodig hebben om optimaal van dit gereedschap gebruik te maken. Onze raad aan developers is om zeker niet bang te zijn van AI en er geregeld gebruik van te maken bij de analyse en ontwikkeling van software: ervaring is de beste leerschool om de goede vakmannen die we hiervoor nodig hebben, op te leiden.

Voorlopig is dus het besluit: voor legacy code is AI geen wondermiddel, maar een handige gereedschapskist die je best kan uitproberen als deel van een bredere aanpak. Zoals gezegd kijken we later dit jaar eerder naar het midden en de rechterkant van het spectrum van legacy. Wij vermoeden dat hier meer mogelijkheden zijn tot automatisering van een aantal workflows, zeker als we ook dieper gebruik gaan maken van agents. Mogelijks kunnen we, voor iets eenvoudigere en repetitievere projecten, dus toch van “vakman” naar “fabriek” evolueren.

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.

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

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!

La communication intense autour de l’intelligence artificielle générative (IAGén) et l’augmentation de son utilisation – au moins en phase de test – que cela soit par peur de rater quelque chose ou pour apporter une réelle valeur ajoutée, conduit à se poser la question de son utilité dans beaucoup de domaines, et, pourquoi pas, afin d’améliorer la sécurité du code. En particulier, l’IAGén permet-elle d’écrire du code informatique plus sécurisé ? Peut-elle aider à détecter des vulnérabilités dans du code existant ?

Dans cette première partie nous apporterons des éléments de réponse à la première question. Nous traiterons la seconde question dans un autre article.

Aspects humains

Commençons par considérer l’aspect humain du recours à l’utilisation de l’IAGén. Dans une analyse détaillée, dont je recommande vivement la lecture, Simkute et al. [1] expliquent les raisons pouvant conduire à une perte de productivité des programmeurs ayant recours à l’IAGén. Les chercheurs citent notamment : un glissement du rôle des programmeurs de la production à l’évaluation, une restructuration inutile des flux de travail, des interruptions, et une tendance de l’IAGén à rendre les tâches faciles plus faciles et les tâches difficiles plus difficiles. On s’étonne alors moins des résultats d’une étude de Perry et al. [2], de l’université de Stanford. Ceux-ci montrent que les participants ayant accès à un assistant basé sur un modèle d’IA écrivent un code significativement moins sécurisé que ceux sans accès. Pire, les participants avec un accès à l’assistant étaient plus enclins à croire qu’ils écrivaient du code sécurisé, que ceux sans l’assistant. Cette observation de Perry et al. est corroborée par le travail de Klemmer et al. [3] : l’équipe de chercheurs a interrogé des programmeurs professionnels, et bien que ces derniers se méfient des suggestions des assistants d’IA, il apparait qu’ils surestiment aussi leur propre capacité à examiner les suggestions de ces assistants. L’adoption d’assistants impose donc la mise en place de pratiques de revue de code et d’analyse statique systématiques [4].

Fiabilité des propositions

Considérant maintenant la qualité des suggestions de l’IAGén, bien que celle-ci produise en général du code fonctionnellement correct, elle introduit également des problèmes de sécurité [5], [6]. Khoury et al. [7] ont montré à travers plusieurs exemples que ChatGPT 3.5 génère souvent du code qui présente des problèmes de sécurité : seuls 5 des 21 cas d’utilisation que les auteurs ont étudiés étaient initialement sécurisés. ChatGPT 3.5 n’a été en mesure de produire du code sécurisé que dans 7 autres cas, et ce, seulement après que les auteurs lui ont explicitement demandé de corriger le code.

Plus récemment, Sivana et al. [8] concluaient leurs expérimentations en soulignant que ChatGPT, en tant que plateforme, générait plus de vulnérabilités de type CWE que le site StackOverflow. Indépendamment, Fu et al. [9] ont montré à travers plusieurs centaines d’échantillons de codes générés par Co-Pilot et trouvés sur GitHub, qu’environ un tiers contient des vulnérabilités communes répertoriées par l’organisme MITRE (certaines faisant partie des 25 plus importantes). Les auteurs recommandent donc aux programmeurs de suivre les meilleures pratiques d’utilisation des outils de génération de code et de toujours vérifier les suggestions de code générées. Des résultats similaires avaient déjà été trouvés par Pearce et al. [10] deux ans plus tôt.

On pourrait multiplier les références à des résultats similaires. C’est ce qu’ont fait Basic et Giaretta [11] dans une étude systématique extensive de la littérature académique sur les IAGén et la sécurité du code informatique. Les modèles concernés sont divers et incluent notamment ChatGPT 3.5, GPT 4-Turbo, Copilot, Claude, Sonnet et Gemini Pro. Les auteurs confirment que plusieurs vulnérabilités clés, telles que les injections SQL et les dépassements de mémoire tampon, peuvent être trouvées dans le code généré par les IAGén. Ils signalent aussi que les risques d’empoisonnement des données d’entraînement peuvent non seulement conduire à une génération de code non sécurisé, mais aussi compromettre la détection des vulnérabilités.

Empoisonnement de l’IA

L’empoisonnement d’un modèle génératif de complétion de code consiste à compromettre l’intégrité de ce modèle en intégrant des échantillons de code malicieux dans les données d’entrainement du modèle. Les attaques par porte dérobée, quant à elles, tentent de dissimuler des déclencheurs à l’intérieur du réseau neuronal profond du modèle pendant la phase d’apprentissage, provoquant la génération de résultats choisis par l’adversaire.

Malgré des progrès importants des modèles de complétion de code, ceux-ci restent vulnérables à ce type d’attaques comme l’ont montré Yan et al. [12] avec CodeBreaker. Pour leur attaque, il n’est pas nécessaire de compromettre un modèle massif pré-entrainé comme BERT ou GPT. En effet ces modèles sont souvent utilisés comme fondation que les victimes règlent finement pour des tâches particulières en utilisant des données spécifiques souvent disponibles publiquement. Il suffit donc alors à l’adversaire de compromettre ces données de réglage fin, ou de téléverser son propre ensemble de données polluées générées avec CodeBreaker. Le code empoisonné généré après l’utilisation de CodeBreaker n’est pas détectable avec des outils de détection de vulnérabilités basés sur des analyses statiques traditionnelles ou des IAGén.

Même si ce type d’attaques est peu probable il pose la question de la provenance de l’outil d’IAGén utilisé et s’inscrit dans la problématique inhérente à l’IAGén actuelle d’obtenir des modèles à la fois sécurisés et exactes [13].

Importance de la requête

Tout n’est pas si noir cependant et il faut souligner l’importance du choix des incitations (« prompt » en anglais) données à l’IAGén afin d’éviter la génération de code avec des faiblesses potentielles. Götz et al. [14] montrent qu’alors que 65% du code initialement généré par divers outils d’IAGén est considéré comme non sécurisé par un ingénieur qualifié, ces mêmes outils génèrent du code sécurisé lorsqu’ils sont guidés manuellement. Les auteurs concluent qu’une expertise technique, en particulier dans le domaine de la sécurité est requise pour générer du code sécurisé en utilisant des assistants de codage.

Afin d’obtenir les meilleurs résultats possibles il faut donc que la requête envoyée à l’IAGén soit à la fois précise et clairement interprétable par le modèle. Autrement-dit, le programmeur a tout intérêt à se plier aux exigences de la machine et fournir avec le plus de détails possibles, non seulement la tâche que le modèle doit exécuter, mais aussi le contexte qui décrit cette tâche, ainsi que les données d’entrée et les données de sortie attendues. Cela peut se faire en seule fois ou sous forme de chaîne de pensée suivant un raisonnement particulier.

Il n’existe cependant pas de méthode idéale, mais Bruni et al. [15] donnent plusieurs exemples simples d’amélioration des incitations. Selon leurs expérimentations la méthode la plus efficace est, après une première requête, de demander à l’IAGén de revoir le code qu’elle a déjà suggéré pour des vulnérabilités potentielles, et enfin de proposer des corrections. Par exemple :

• Requête 1 : Génère du code Java pour …
• Requête 2 : Examine le code suivant et trouve les problèmes de sécurité : <réponse fournie à la requête 1>
• Requête 3 : À partir des problèmes suivants : <problèmes signalés par la requête 2>, améliore le code suivant : <réponse fournie à la requête 1>

Cette façon de faire suppose bien évidemment que l’IAGén est capable de détecter des vulnérabilités, mais comme nous le verrons dans l’article suivant ce n’est pas encore le cas aujourd’hui.

Outils spécialisés

Nous pouvons néanmoins nous attendre à l’arrivée de nouveaux outils qui pourraient permettre aux programmeurs d’éviter les écueils de sécurité créés par l’IAGén.

Par exemple l’outil SafeCoder d’ETH Zurich [16] propose un cadre permettant d’améliorer la sécurité du code généré par une IAGén sans sacrifier la fonctionnalité de ce code. L’outil combine le réglage standard des instructions avec un réglage fin – spécifique à la sécurité, en utilisant des exemples de code sûrs et non-sûrs. Pour créer un ensemble de données de qualité, les auteurs ont mis en place un processus automatisé qui extrait les corrections de vulnérabilités vérifiées à partir des modifications de code enregistrées sur GitHub à l’aide d’un filtrage heuristique et d’une analyse statique basée sur l’outil CodeQL. Les résultats montrent que SafeCoder améliore la sécurité du code d’environ 30 % tout en conservant son utilité dans des étalons tels que HumanEval et MMLU. Les auteurs admettent cependant que l’outil n’améliore pas la sécurité de code contenant des vulnérabilités pour lesquelles il n’a pas été entrainé.

En attendant, une façon de procéder pourrait être de combiner un outil d’analyse statique « classique » avec une IAGén en demandant d’abord à l’IAGén de générer le code souhaité, puis en utilisant l’outil d’analyse statique pour analyser ce code. En cas de problème identifié par l’outil, si la correction n’est pas évidente, on peut demander à l’IAGén de modifier celui-ci en indiquant à celle-ci l’erreur précédemment identifiée. On peut recommencer la boucle jusqu’à ce qu’aucun problème ne soit identifié par l’outil d’analyse. Bien évidemment cette procédure fastidieuse pourrait être automatisée dans un cycle de développement logiciel habituel..

Conclusion

La première partie de cet article était dédiée à l’impact de l’IAGén sur la qualité du code en termes de sécurité. En l’état actuel des choses, force est de constater que malgré la capacité étonnante des outils d’IAGén à générer du code informatique, ce code peut souvent présenter des problèmes de sécurité – et ce quelque-soit le modèle choisi. Il convient donc d’être très vigilent avant d’utiliser du code généré par des outils d’IAGén. De plus, même si les IAGén peuvent faciliter certaines tâches de programmation, il n’en reste pas moins qu’elles ne portent pas la responsabilité des conséquences potentiellement négatives de leur « travail », responsabilité qui échoit au programmeur et à son employeur.

Les compétences et connaissances en matière de sécurité des programmeurs – dont la tâche évoluera progressivement de créateur de code à contrôleur de code – restent un atout essentiel. L’arrivée de l’IAGén dans le cycle de développement est peut-être une bonne occasion de renforcer la collaboration entre les équipes de sécurité et de développement en établissant (ou renforçant) des groupes de travail dans lesquels sont alignés des objectifs communs afin d’améliorer la sécurité.

Dans la seconde partie nous nous focaliserons sur l’utilisation de l’IAGén pour la détection de vulnérabilités dans le code.

Références

[1] A. Simkute, L. Tankelevitch, V. Kewenig, A. E. Scott, A. Sellen, et S. Rintel, « Ironies of generative AI: Understanding and mitigating productivity loss in human-AI interactions », 17 février 2024, arXiv: arXiv:2402.11364. doi: 10.48550/arXiv.2402.11364.

[2] N. Perry, M. Srivastava, D. Kumar, et D. Boneh, « Do users write more insecure code with AI assistants? », 16 décembre 2022, arXiv: arXiv:2211.03622. Consulté le: 3 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2211.03622

[3] J. H. Klemmer et al., « Using AI assistants in software development: A qualitative study on security practices and concerns », 14 octobre 2024. doi: 10.1145/3658644.3690283.

[4] J. Ganseman, « LLM pour code : the good, the bad and the ugly », Smals Research Blog. Consulté le: 18 octobre 2023. [En ligne]. Disponible sur: /llms-pour-code/

[5] A. Chowdhery et al., « PaLM: scaling language modeling with pathways », 5 octobre 2022, arXiv: arXiv:2204.02311. doi: 10.48550/arXiv.2204.02311.

[6] M. Chen et al., « Evaluating large language models trained on code », 14 juillet 2021, arXiv: arXiv:2107.03374. doi: 10.48550/arXiv.2107.03374.

[7] R. Khoury, A. R. Avila, J. Brunelle, et B. M. Camara, « How secure is code generated by ChatGPT? », 19 avril 2023, arXiv: arXiv:2304.09655. doi: 10.48550/arXiv.2304.09655.

[8] S. Hamer, M. d’Amorim, et L. Williams, « Just another copy and paste? Comparing the security vulnerabilities of ChatGPT generated code and StackOverflow answers », 22 mars 2024, arXiv: arXiv:2403.15600. doi: 10.48550/arXiv.2403.15600.

[9] Y. Fu et al., « Security weaknesses of copilot generated code in GitHub », 4 avril 2024, arXiv: arXiv:2310.02059. doi: 10.48550/arXiv.2310.02059.

[10] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, et R. Karri, « Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions », in 2022 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA: IEEE, mai 2022, p. 754‑768. doi: 10.1109/sp46214.2022.9833571.

[11] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

[12] S. Yan et al., « An LLM-assisted easy-to-trigger backdoor attack on code completion models: Injecting disguised vulnerabilities against strong detection », présenté à 33rd USENIX Security Symposium, Philadelphia, PA, USA, août 2024.

[13] E.-M. El-Mhamdi et al., « On the impossible safety of large AI models », 9 mai 2023, arXiv: arXiv:2209.15259. Consulté le: 17 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2209.15259

[14] S. Götz et A. Schaad, « “You still have to study” – On the security of LLM generated code », août 2024, [En ligne]. Disponible sur: https://arxiv.org/abs/2408.07106

[15] M. Bruni, F. Gabrielli, M. Ghafari, et M. Kropp, « Benchmarking prompt engineering rechniques for secure code generation with GPT models », 9 février 2025, arXiv: arXiv:2502.06039. doi: 10.48550/arXiv.2502.06039.

[16] J. He, M. Vero, G. Krasnopolska, et M. Vechev, « Instruction tuning for secure code generation », 12 juillet 2024, arXiv: arXiv:2402.09497. doi: 10.48550/arXiv.2402.09497.

_________________________

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

De uitgebreide communicatie rond generatieve artificiële intelligentie (GenAI) en het toenemende gebruik ervan – althans in de testfase – uit angst om iets te missen of om een echte meerwaarde te bieden, roept de vraag op of het in veel domeinen nuttig is, en waarom niet, om de veiligheid van code te verbeteren. Meer bepaald: kan GenAI worden gebruikt om veiligere computercode te schrijven? Kan het helpen bij het opsporen van kwetsbaarheden in bestaande code?

In dit eerste deel geven we een antwoord op de eerste vraag. De tweede vraag komt in een ander artikel aan bod.

Menselijke aspecten

Laten we beginnen met het menselijke aspect van het gebruik van GenAI. In een gedetailleerde analyse, die ik ten zeerste aanbeveel, leggen Simkute et al. [1] de redenen uit die kunnen leiden tot een productiviteitsverlies van programmeurs die een beroep doen op GenAI. Onderzoekers hebben het onder andere over: een verglijding van de programmeurrol van productie naar evaluatie, een onnuttige herstructurering van werkstromen, onderbrekingen en de neiging van GenAI om makkelijke taken nog gemakkelijker en moeilijke taken nog moeilijker te maken. De resultaten van een studie van Perry et al. [2], van Stanford University verbazen ons dan minder. Deze tonen aan dat deelnemers die toegang hebben tot een codeerassistent op basis van een AI-model aanzienlijk minder veilige code schrijven dan deelnemers zonder toegang. Erger nog, deelnemers met toegang tot de assistent geloofden vaker dat ze veilige code schreven dan deelnemers zonder toegang. Deze observatie van Perry et al. wordt bevestigd door het werk van Klemmer et al. [3]: het onderzoeksteam ondervroeg professionele programmeurs, en hoewel zij wantrouwig staan tegenover suggesties van AI-codeerassistenten, blijkt dat zij ook hun eigen vermogen om de suggesties van deze codeerassistenten te beoordelen overschatten. Het gebruik van codeerassistenten vereist daarom de implementatie van systematische codecontrole en statische analyse [4].

Betrouwbaarheid van de voorstellen

Wat betreft de kwaliteit van de suggesties van GenAI: hoewel het over het algemeen functioneel correcte code oplevert, introduceert het ook veiligheidsproblemen [5], [6]. Khoury et al. [7] hebben met behulp van meerdere voorbeelden aangetoond dat ChatGPT 3.5 vaak code genereert die voor veiligheidsproblemen kan zorgen : slechts 5 van de 21 use cases die de auteurs bestudeerd hebben waren aanvankelijk beveiligd. ChatGPT 3.5 was in staat om beveiligde code aan te maken voor slechts 7 gevallen en dit was pas mogelijk nadat de auteurs expliciet vroegen om de code te verbeteren.

Meer recentelijk concludeerden Sivana et al. [8] dat ChatGPT als platform meer CWE-kwetsbaarheden genereerde dan de website StackOverflow. Onafhankelijk daarvan hebben Fu et al. [9] aan de hand van honderden door Copilot gegenereerde codevoorbeelden die op GitHub zijn gevonden, aangetoond dat ongeveer een derde daarvan veelvoorkomende kwetsbaarheden bevat die door de organisatie MITRE zijn geïnventariseerd (waarvan sommige tot de 25 belangrijkste behoren). De auteurs raden programmeurs daarom aan om de beste praktijken voor het gebruik van codegeneratietools te volgen en de gegenereerde codesuggesties altijd te controleren. Soortgelijke resultaten waren al gevonden door Pearce et al. [10] twee jaar eerder.

Er zijn nog veel meer voorbeelden van soortgelijke resultaten. Dat hebben Basic en Giaretta [11] gedaan in een uitgebreide systematische studie van de academische literatuur over GenAI en de veiligheid van computercode. De betrokken modellen zijn divers en omvatten onder meer ChatGPT 3.5, GPT 4-Turbo, Copilot, Claude, Sonnet en Gemini Pro. De auteurs bevestigen dat verschillende belangrijke kwetsbaarheden, zoals SQL-injecties en bufferoverflows, kunnen worden aangetroffen in de code die door GenAI wordt gegenereerd. Ze wijzen er ook op dat het risico van vergiftiging van trainingsgegevens niet alleen kan leiden tot het genereren van onveilige code, maar ook de detectie van kwetsbaarheden in gevaar kan brengen.

Vergiftiging van AI

Het vergiftigen van een generatief model voor codeaanvulling bestaat uit het compromitteren van de integriteit van dit model door kwaadaardige codevoorbeelden in de trainingsgegevens van het model te integreren. Backdoor-aanvallen proberen tijdens de trainingsfase triggers te verbergen in het diepe neurale netwerk van het model, waardoor resultaten worden gegenereerd die door de tegenstander zijn gekozen.

Ondanks aanzienlijke vooruitgang op het gebied van codeaanvullingsmodellen blijven deze kwetsbaar voor dit soort aanvallen, zoals Yan et al. [12] met CodeBreaker hebben aangetoond. Voor hun aanval is het niet nodig om een vooraf getraind groot model zoals BERT of GPT te compromitteren. Deze modellen worden namelijk vaak gebruikt als basis die slachtoffers nauwkeurig afstemmen op specifieke taken met behulp van specifieke gegevens die vaak openbaar beschikbaar zijn. De tegenstander hoeft dus alleen maar deze finetuning data te compromitteren of zijn eigen set vervuilde data, gegenereerd met CodeBreaker, te uploaden. De vergiftigde code die na gebruik van CodeBreaker wordt gegenereerd, is niet detecteerbaar met kwetsbaarheidsdetectietools op basis van traditionele statische analyses of GenAI.

Hoewel dit soort aanvallen onwaarschijnlijk is, rijst de vraag waar de gebruikte GenAI-tool vandaan komt en past dit in de problematiek die inherent is aan de huidige GenAI om zowel veilige als nauwkeurige modellen te verkrijgen [13].

Belang van de prompt

Het is echter niet allemaal kommer en kwel en het belang van de keuze van de prompts die aan GenAI worden gegeven om het genereren van code met potentiële zwakke punten te voorkomen, moet worden benadrukt. Götz et al. [14] tonen aan dat, terwijl 65% van de code die oorspronkelijk door verschillende GenAI-tools werd gegenereerd, door een gekwalificeerde ingenieur als onveilig wordt beschouwd, dezelfde tools veilige code genereren wanneer ze handmatig worden aangestuurd. De auteurs concluderen dat technische expertise, met name op het gebied van beveiliging, vereist is om veilige code te genereren met behulp van code AI-codeerassistenten.

Om de best mogelijke resultaten te verkrijgen, moet de prompt die aan GenAI wordt gegeven zowel nauwkeurig als duidelijk interpreteerbaar zijn voor het model. Met andere woorden: de programmeur heeft er alle belang bij om zich aan de eisen van de machine te houden en zo gedetailleerd mogelijk niet alleen de taak die het model moet uitvoeren, maar ook de context waarin deze taak plaatsvindt en de verwachte invoer- en uitvoergegevens te specificeren. Dit kan in één keer gebeuren of in de vorm van een chain-of-thoughts volgens een bepaalde redenering.

Er bestaat echter geen ideale methode, maar Bruni et al. [15] geven verschillende eenvoudige voorbeelden van verbetering van prompts. Volgens hun experimenten is de meest effectieve methode om, na een eerste prompt, GenAI te vragen de code die het al heeft voorgesteld op mogelijke kwetsbaarheden te herzien en vervolgens correcties voor te stellen. Bijvoorbeeld:

• Prompt 1: genereer Java-code voor …
• Prompt 2: analyseer de volgende code en vind de beveiligingsproblemen: <antwoord op prompt 1>
• Prompt 3: op basis van de volgende problemen: <problemen gemeld door prompt 2>, verbeter de volgende code: <antwoord gegeven op prompt 1>

Deze werkwijze veronderstelt uiteraard dat GenAI in staat is om kwetsbaarheden op te sporen, maar zoals we in het volgende artikel zullen zien, is dat vandaag nog niet het geval.

Gespecialiseerde tools

We kunnen echter nieuwe tools verwachten die programmeurs in staat zullen stellen om de veiligheidsrisico’s van GenAI te vermijden.

Zo biedt de tool SafeCoder van ETH Zürich [16] een kader om de veiligheid van door GenAI gegenereerde code te verbeteren zonder de functionaliteit van die code in het gedrang te brengen. De tool combineert de standaardinstellingen van instructies met een veiligheidsgerichte finetuning aan de hand van veilige en onveilige codevoorbeelden. Om een dataset van hoge kwaliteit te creëren, hebben de auteurs een geautomatiseerd proces opgezet dat geverifieerde kwetsbaarheidscorrecties uit de op GitHub geregistreerde codewijzigingen haalt met behulp van heuristische filtering en statische analyse op basis van de CodeQL-tool. De resultaten tonen aan dat SafeCoder de codeveiligheid met ongeveer 30% verbetert, terwijl de bruikbaarheid in benchmarks zoals HumanEval en MMLU behouden blijft. De auteurs geven echter toe dat de tool de veiligheid van code met kwetsbaarheden waarvoor hij niet is getraind, niet verbetert.

In de tussentijd kan een manier zijn om een traditionele statische analyse te combineren met GenAI door eerst de GenAI te vragen de gewenste code te genereren en vervolgens de statische analyse te gebruiken om deze code te analyseren. Als de tool een probleem identificeert en de correctie niet voor de hand ligt, kan men de GenAI vragen om de code aan te passen, waarbij de eerder geïdentificeerde fout wordt aangegeven. De lus kan worden herhaald totdat er geen probleem meer wordt geïdentificeerd door het analyse tool. Natuurlijk kan deze omslachtige procedure worden geautomatiseerd in een normale softwareontwikkelingscyclus.

Conclusie

Het eerste deel van dit artikel ging over de impact van GenAI op de kwaliteit van code in termen van beveiliging. In de huidige situatie moet worden vastgesteld dat, ondanks het verbazingwekkende vermogen van GenAI-tools om computercode te genereren, deze code vaak veiligheidsproblemen kan opleveren, ongeacht het gekozen model. Het is daarom raadzaam om zeer waakzaam te zijn vooraleer we code gebruiken die door GenAI-tools is gegenereerd. Bovendien kunnen GenAI-tools bepaalde programmeertaken vergemakkelijken, maar dat neemt niet weg dat zij niet verantwoordelijk zijn voor de mogelijke negatieve gevolgen van hun “werk”. Die verantwoordelijkheid ligt bij de programmeur en zijn werkgever.

De vaardigheden en kennis op het gebied van veiligheid van programmeurs – wier taak geleidelijk zal evolueren van codeschrijver naar codecontroleur – blijven een essentiële troef. De komst van GenAI in de ontwikkelcyclus is misschien een goede gelegenheid om de samenwerking tussen beveiligings- en ontwikkelingsteams te versterken door werkgroepen op te richten (of te versterken) waarin gemeenschappelijke doelstellingen worden afgestemd om de beveiliging te verbeteren.

In het tweede deel zullen we ons concentreren op het gebruik van GenAI voor het opsporen van kwetsbaarheden in code.

Referenties

[1] A. Simkute, L. Tankelevitch, V. Kewenig, A. E. Scott, A. Sellen, et S. Rintel, « Ironies of generative AI: Understanding and mitigating productivity loss in human-AI interactions », 17 février 2024, arXiv: arXiv:2402.11364. doi: 10.48550/arXiv.2402.11364.

[2] N. Perry, M. Srivastava, D. Kumar, et D. Boneh, « Do users write more insecure code with AI assistants? », 16 décembre 2022, arXiv: arXiv:2211.03622. Consulté le: 3 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2211.03622

[3] J. H. Klemmer et al., « Using AI assistants in software development: A qualitative study on security practices and concerns », 14 octobre 2024. doi: 10.1145/3658644.3690283.

[4] J. Ganseman, « LLM pour code : the good, the bad and the ugly », Smals Research Blog. Consulté le: 18 octobre 2023. [En ligne]. Disponible sur: /llms-pour-code/

[5] A. Chowdhery et al., « PaLM: scaling language modeling with pathways », 5 octobre 2022, arXiv: arXiv:2204.02311. doi: 10.48550/arXiv.2204.02311.

[6] M. Chen et al., « Evaluating large language models trained on code », 14 juillet 2021, arXiv: arXiv:2107.03374. doi: 10.48550/arXiv.2107.03374.

[7] R. Khoury, A. R. Avila, J. Brunelle, et B. M. Camara, « How secure is code generated by ChatGPT? », 19 avril 2023, arXiv: arXiv:2304.09655. doi: 10.48550/arXiv.2304.09655.

[8] S. Hamer, M. d’Amorim, et L. Williams, « Just another copy and paste? Comparing the security vulnerabilities of ChatGPT generated code and StackOverflow answers », 22 mars 2024, arXiv: arXiv:2403.15600. doi: 10.48550/arXiv.2403.15600.

[9] Y. Fu et al., « Security weaknesses of copilot generated code in GitHub », 4 avril 2024, arXiv: arXiv:2310.02059. doi: 10.48550/arXiv.2310.02059.

[10] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, et R. Karri, « Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions », in 2022 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA: IEEE, mai 2022, p. 754‑768. doi: 10.1109/sp46214.2022.9833571.

[11] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

[12] S. Yan et al., « An LLM-assisted easy-to-trigger backdoor attack on code completion models: Injecting disguised vulnerabilities against strong detection », présenté à 33rd USENIX Security Symposium, Philadelphia, PA, USA, août 2024.

[13] E.-M. El-Mhamdi et al., « On the impossible safety of large AI models », 9 mai 2023, arXiv: arXiv:2209.15259. Consulté le: 17 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2209.15259

[14] S. Götz et A. Schaad, « “You still have to study” – On the security of LLM generated code », août 2024, [En ligne]. Disponible sur: https://arxiv.org/abs/2408.07106

[15] M. Bruni, F. Gabrielli, M. Ghafari, et M. Kropp, « Benchmarking Prompt Engineering Techniques for Secure Code Generation with GPT Models », 9 février 2025, arXiv: arXiv:2502.06039. doi: 10.48550/arXiv.2502.06039.

[16] J. He, M. Vero, G. Krasnopolska, et M. Vechev, « Instruction tuning for secure code generation », 12 juillet 2024, arXiv: arXiv:2402.09497. doi: 10.48550/arXiv.2402.09497.

(FR) Entretien en Néerlandais (sous-titres disponibles) avec Bert Vanhalst de Smals Research sur les agents IA. Conversation intéressante sur la dernière évolution de l’intelligence artificielle, mais avec les deux pieds sur terre, loin du battage médiatique. Deuxième entretien d’une série de Research talks, avec la coopération de Smals Academy.

(EN) Interview in Dutch (subtitles available) with Bert Vanhalst from Smals Research about AI Agents. Interesting conversation about the latest evolution in artificial intelligence, but with both feet on the ground, away from the hype. Second conversation in a series of Research talks, with the cooperation of Smals Academy.

Cryptography is essential in our society to secure sensitive communications and financial transactions, among other things. Cryptographic recommendations help organisations and teams decide when certain cryptography in their systems should be phased out and replaced. Expressing such cryptographic recommendations as a code has advantages, such as an increased degree of automation and increased insight, and is a logical step towards cryptographic maturity.

Cryptographic recommendations

The recommended algorithms and parameters, including key lengths, for authentication, digital signatures, cryptographic hash functions and symmetric encryption, among other things, change regularly. Algorithms that were once recommended are now insecure. The same applies to cipher suites in communication protocols such as TLS. Cipher suites are combinations of cryptographic algorithms and parameters agreed upon by the communicating parties. On this basis, a secure channel is then set up.

In many countries, including our neighbours Germany, France and the Netherlands, the national information security agencies publish detailed recommendations on the use of cryptography. Usually a distinction is made between cryptography that is recommended, cryptography that is not recommended but is still considered secure, cryptography that we should phase out and, finally, cryptography that is insecure. Those recommendations are regularly updated. The German BSI does this on an annual basis, for example.

We still lack such recommendations in Belgium. These should ideally be formulated at European level, by ENISA, the European Union Agency for Cybersecurity, for example. Unfortunately, we are not there yet. At the same time, Smals and the Belgian public sector certainly have a concrete need for them today, which is why Smals Research took the initiative a few years ago to formulate its own internal recommendations. These are based on the recommendations of the German BSI, as it is the leading and best subsidised cyber security agency in Europe.  

Recommendations as code

As with all other cryptographic recommendations, these are currently expressed in a way that is legible to humans, but not sufficiently structured to allow processing by machines. The latter would allow a higher degree of automation and could improve security.

• It could allow to automatically generate the cryptographic part of the configuration files for communication protocols such as TLS and OpenSSH. As a result, updates could be implemented faster, with less manpower and less risk of human error. Smals uses hundreds, if not thousands, of machines that must be able to communicate securely.
• This would allow us to unlock the cryptographic recommendations interactively. A project team would be able to quickly consult the most recent cryptographic recommendations relevant to them via a web interface. Once the application is live, a project team would automatically be kept up to date on changes relevant to them.

The closest thing available today is the website CipherSuite. While this is a commendable initiative, we would prefer to proceed with Smals for several reasons. After all, we do not necessarily follow these recommendations, which are also limited to the TLS communication protocol. We also want something that is CBOM compatible.

Cryptography Bill of Materials (CBOM)

In the context of the threat posed by powerful quantum computers, another major crypto migration is becoming increasingly urgent. In order to prepare for this and other future migrations, organisations would be wise to start building an overview of which cryptography is being used where. This would allow them to draw up a well-founded migration plan and will also make the migration itself run more quickly and smoothly. This inventory quickly becomes very complex and is therefore ideally expressed as code to facilitate automatic updating and processing by machines.

To this end, IBM developed CBOM (Cryptography Bill of Materials), which allows cryptographic components such as algorithms, parameters, protocols and libraries and their dependencies to be expressed in JSON. It is an OWASP CycloneDX standard, which means that it is compatible with SBOM (Software Bill Of Materials), among other things. CBOM allows us to take the management of cryptographic assets (algorithms, protocols, libraries, keys, certificates, …) to the next level.
The illustration below is a CBOM fragment that shows where RSA-2048 is used in the scanned source code of an application.

Suppose an organisation expresses its cryptographic assets as CBOM, and has cryptographic recommendations in code compatible with it. That organisation could then very quickly determine where and to what extent it complies with the cryptographic recommendations, or not. This insight could be particularly useful when taking steps to make the organisation and the data it protects more secure. An organisation could then quickly find out where it is most vulnerable to powerful quantum computers. The organisation can also quickly provide exact information during audits, for example in the form of an automatically generated report in PDF or Excel format, in response to specific questions from the auditor.

Deviations as code

Aside from the recommendations and the cryptographic assets, there is a third element that can be expressed as machine-readable code: the deviations from those recommendations.

In an ideal world, Smals would systematically and solely use the recommended and secure cryptography in its systems. This is not always possible, given that it would de facto make services unavailable to the users of those systems. We cannot expect doctors, pharmacists, physiotherapists, Public Welfare Centres, etc. to support only the latest secure cryptography at any given time. Smals must therefore show a certain degree of tolerance whereby it continues to support sub-optimal cryptography for a limited period of time. This should be done in a structured manner, with a limited tolerance period and with the risks clearly assessed by security services and approved by management.

This too is best expressed in a way that allows automatic processing. Combined with the recommendations and inventory, this allows us to see immediately where we deviate from the recommendations, both documented and undocumented. This approach also provides insight into the cumulative risk, which helps increase safety in the organisation. This, too, can be useful in audits.

Conclusion

A few years back, Smals Research made a proposition for cryptographic recommendations, which was adopted by Smals and is updated at least annually. Smals Research believes the time is ripe for the next step and is currently converting these recommendations into a structured form with a maximal compatibility with CBOM. The same is done for deviations from those recommendations.

CBOM and Smals’ ambitions to express cryptographic assets, recommendations, as well as deviations in a machine readable format fit into the broader trend of Everything as code, a philosophy that results in an increased degree of automation of processes and management. This gives us more insight and allows us to better anticipate and intervene if necessary. Moreover, it results in increased consistency and scalability thanks to reduced human intervention.

Applying Everything as Code to cryptography is, in our opinion, an important step in increasing cryptographic maturity. We therefore see CBOM as a necessary standard that we expect to see increasingly supported in tools for development, information security and post-quantum migration in the coming years. Consequently, we expect vendors to increasingly provide a CBOM with their software, hardware or services.

We expect the triumvirate of cryptographic assets as code, recommendations as code and deviations as code to unlock new possibilities and opportunities for insight and automation. One idea is to perform graph analytics (graph analytics) on this data, ideally using a graph database supplemented with an interactive visualisation tool.

To be continued. Please do not hesitate to contact us if you are interested.

This contribution was submitted by Kristof Verslype, cryptographer at Smals Research. It was written in his own name and does not represent Smals’ position.