Pour illustrer ces propos, nous allons nous baser sur le jeu de données “urgences data”, disponible sur Kaggle. Il s’agit d’un fichier CSV de ~430 MB, comprenant 336 253 lignes et 39 colonnes, sans aucune métadonnée associée. Chaque ligne correspond à la visite d’un patient dans le service d’urgences d’un hôpital (non identifié) du nord de la France, entre le 6 janvier 2016 et le 6 décembre 2020. On y trouve une multitude d’informations : date et heure d’arrivée et de sortie, moyen d’arrivée, motif, âge, un certain nombre de paramètres médicaux, tels que fréquence cardiaque, tension, température, saturation, ainsi que des booléens semblant indiquer si des examens complémentaires ont été prescrits (biologie, radio, échographie, scanner, IRM…)

Nous allons utiliser “Data Analyst”, un des “GPTs” proposé dans ChatGPT. La version gratuite étant limitée à un très petit nombre de questions, nous avons utilisé une version payante (“Personal Plus”). Nous avons interagi en anglais pour cet exercice, mais des résultats semblables auraient probablement été obtenus en français ou en néerlandais.

Analyse préliminaire

Une première étape peut consister à simplement soumettre le fichier à analyser à “Data Analyst”, et lui demander de dire ce qu’il peut y trouver. Plus formellement, une question telle que “What useful insight can you extract from those data?” nous fournit le résultat ci-dessous.

Nous obtenons un résultat qui va suivre une structure que l’on retrouvera dans presque toutes les réponses :

1. Une série de graphiques. Ici, une distribution de l’âge des patients, la répartition moyenne suivant l’heure de la journée, ainsi que la répartition de l’orientation (retour domicile, transfert interne…). Notons que sans qu’on n’ait rien eu à dire, ChatGPT a compris qu’il s’agissait de patients d’un service d’urgences ;
2. Une analyse textuelle structurée de ce qu’il a pu comprendre des données. La démographie des patients, quelles sont les heures de pointe, où vont les patients à la sortie et comment sont-ils arrivés ;
3. Des propositions stratégiques ;
4. Des propositions d’étapes suivantes. “If you’d like, I can next:“, suivi d’une série de prompts pertinents pour continuer l’analyse (qu’il faut malheureusement copier-coller).

Par ailleurs, le texte termine toujours par un lien “</>”, que l’on ne retrouve pas dans un chat ChatGPT “de base” et sur lequel on peut cliquer pour obtenir le code Python sur lequel est basé cette analyse. Celui-ci, réalisé en utilisant la bibliothèque “Pandas” de Python (un des outils open source le plus répandu d’analyse de données/data science), permet de générer les graphiques proposés, ainsi que tous les chiffres utilisés dans les descriptions. Il est donc tout à fait possible non seulement d’utiliser ce code directement, mais aussi de s’assurer que les chiffres ne sont pas totalement inventés sur la base de modèles statistiques généraux et bien calculés à partir des données fournies.

On a donc pu, en une seule phrase et à peine une minute d’attente, obtenir trois graphiques, du code Python et un texte descriptif qu’un data scientist aurait typiquement mis plusieurs heures à obtenir. Il s’agit, bien sûr, d’une première approche très sommaire. Mais on peut aller plus loin.

On peut par exemple demande de fournir une description statistique pour chaque colonne. On obtient ici en résultat une longue description très structurée, par type de variable (numérique ou catégorique) avec une série d’indicateurs : moyenne, minimum/maximum, nombre de valeurs manquantes… ainsi qu’un commentaire (“Not usable for analysis“, “Vital signs moderately complete“, “Excellent for resource utilization analysis“, “Likely categorical indicator”…). L’outil nous propose également quelques observations liées à la qualité des données (Exemple : “Outliers: Age max = 218 (likely error)“).

De façon similaire, on pourrait demander une “EDA” (Exploratory Data Analysis), qui fournira une analyse semblable, en partie redondante mais couvrant d’autres aspects.

Avec ce type de “prompt”, on a donc, en quelques minutes seulement, un premier aperçu détaillé, chiffré mais clair et facile à comprendre d’un jeu de données raisonnablement volumineux. ChatGPT comprend, ou à tout le moins se comporte comme s’il comprenait le contenu des données :

• Il calcule un “length of stay“, interprétant donc bien deux colonnes (DH_arrivee et DH_sortie). Petit bémol cependant : dans les données, l’heure d’arrivée contient une date et une heure, mais le “DH_sortie” uniquement la date (avec 00:00 comme heure), rendant le calcul peu pertinent, surtout pour les courts séjours. Mais si on lui demande comment il a calculé ce “length of stay“, il fait remarquer le problème ;
• Il “comprend” que la colonne “Code_CCMU” (avec les codes 1, 2, 3, 4, 5, P ou D) fait référence à la nomenclature française de la “Classification Clinique des Malades aux Urgences” et dénote la gravité. Il propose de faire une “severity analysis (CCMU code distribution)”, dans laquelle il interprète correctement les codes ;
• Il fait des propositions, certes un peu naïves, mais pertinentes dans le contexte, dont voici deux exemples :

Analyse par catégorie

En observant les données, nous avons remarqué deux colonnes concernant la raison d’arrivée du patient : une colonne “motif_entree”, très peu structurée (“Trauma cheville G”, “A avalé une LED avec une pile”…) et une autre “semi-structurée” : “Cardiologie: Douleur thoracique atypique”, “Pneumologie: Dyspnée sans détresse”, “Toxicologie: Alcoolisation/Ivresse aigue”… Il serait intéressant de pouvoir analyser certains éléments en fonction d’une “catégorie” : “Cardiologie”, “Pneumologie”, “Toxicologie”…

On peut tout simplement demander à ChatGPT “extract categories from motif_venue“, sans lui donner aucune information sur la façon de procéder. On reçoit alors en réponse une distribution de ce nouvel attribut, expliquant comment il l’a réalisé, ainsi que quelques commentaires pertinents sur la qualité des données :

Une question qui viendrait naturellement à l’esprit serait de voir comment celles-ci se comportent dans le temps. On peut par exemple imaginer que les problèmes pulmonaires surviennent surtout en hiver à l’époque des grippes et autres virus. Mais qu’en est-il des autres pathologies ?

Demandons à ChatGPT “Plot occurrence line charts grouped by cleansed categories, for the top 10“. Nous obtiendrons alors le graphique ci-contre, ainsi qu’une série de commentaires. On peut être surpris par la chute vertigineuse des chiffres, toutes catégories confondues, survenue début 2020. Mais toute personne n’ayant pas vécu dans une grotte à cette période en aura rapidement compris la raison… qui n’a pas échappé à ChatGPT, comme en témoigne un de ses commentaires :

“The sharp drop in early 2020 is visible across all categories — a clear COVID shock to ED visit“

Pour obtenir des tendances saisonnières, on peut demander de sommer les trois années pour lesquelles on a des données entières et de lisser les données, en considérant une moyenne glissante sur 7 jours : “For the top 10 cleansed categories, plot the number of visits per date in year (summing up values for 2017, 2018 and 2019, excluding 2016 and 2020), with a moving average of 7 days“.

Après quelques essais-erreurs de prompts pour sortir la légende du graphique ou adapter divers aspects, on obtient le résultat suivant :

Comme on s’y attendait, on peut observer que les pathologies pulmonaires (en brun) sont plus élevées en hiver qu’en été, mais ce qui est surprenant, c’est cet énorme pic à la toute fin de l’année de la stomatologie. Après s’être assuré que le pic se reproduisait bien tous les ans avec quelques prompts que nous passerons sous silence, nous avons demandé “how to explain the peak of total visits for stomatology for the last week?“. Nous avons été clairement bluffés par la pertinence de la réponse.

Deux explications, que ChatGPT n’a pas pu trouver dans le jeu de données, mais uniquement en faisant le lien avec son “savoir général”, nous paraissent très plausibles :

• Les cabinets de dentisteries sont majoritairement fermés pendant les fêtes (ou plus généralement pendant les congés, vu les deux plus petits pics) ;
• Beaucoup de monde veut “épuiser” ses possibilités de remboursement avant la fin de l’année.

Il va sans dire qu’un approfondissement serait nécessaire avant d’en tirer des décisions opérationnelles, mais on a déjà ici à très petits frais une série d’hypothèses à explorer.

Limitations

Si un premier aperçu peut sembler impressionnant, il faut cependant rester prudent. De toute évidence, un tel outil peut être un allié précieux pour un data scientist, et peut même permettre à des profils “métiers” aux compétences techniques limitées d’accéder à une première analyse. Voici quelques points d’attention issus de notre expérience sur ce jeu de données.

• On ne devient pas “data scientist” simplement parce qu’on est capable de produire des beaux graphiques ou livrer des chiffres. Encore faut-il être capable de les interpréter, de s’assurer qu’on n’est pas tombé dans un des nombreux pièges que les statistiques nous tendent ;
• Dans notre exemple, nous avons envoyé tout notre jeu de données à ChatGPT. Nous n’avons aucun contrôle sur ce qu’il en fait. Il s’agissait en l’occurrence de données publiques, mais qu’en sera-t-il avec des données confidentielles ? Il est toujours possible d’installer un LLM on-premise, mais les coûts sont autrement plus élevés et les performances moindres ;
• Nous n’avons testé qu’un exemple avec une seule table. La littérature semble montrer que ça reste valable avec une base de données plus complexe, il nous faudra encore l’expérimenter ;
• Le mode “question-réponse” permet uniquement un long dialogue linéaire. On se retrouve vite avec une longue discussion très désordonnée, plusieurs tentatives pour arriver à faire comprendre à l’outil ce que l’on veut. Si l’on veut par exemple corriger un critère en amont d’une analyse déjà faite (par exemple, la limiter à une période dans le temps, ou éliminer certains types de données), on ne peut pas revenir en arrière. Il sera nécessaire de recommencer un nouveau chat, ou de reposer toutes les questions ;
• Dans le même ordre d’idée, si les données d’entrée sont mises à jour, il sera nécessaire de recommencer toute la conversation ;
• À côté de l’aspect peu structuré, on note aussi un manque de cohérence :
  • Lors de l’extraction de la “catégorie”, nous avons demandé, outre la séparation sur la base du “:”, de corriger également certains problèmes de qualité (pour par exemple remplacer “Cardiovasculaire” par “Cardiologie” ou “Intoxications” par “Toxicologie”). Les questions qui suivaient de près ce nettoyage considéraient la version la plus élaborée. Mais quelques jours après, quand nous évoquions “cleansed categories”, ChatGPT se contentait de la séparation sur la base du “:”,
  • Nous avons posé exactement la même question à un mois d’intervalle. Les valeurs numériques fournies dans la réponse restaient cohérentes, mais le texte était radicalement différent sur la forme (bien que semblable sur le fond) ;
• Le code Python proposé à chaque question est réellement exécuté sur les serveurs de ChatGPT qui se sert du résultat pour générer sa réponse. Mais le temps d’exécution disponible est assez limité. Entraîner un modèle de Machine Learning simple (par exemple “Compute feature importance using Random Forest, with ‘scanner’ as target“) provoque souvent un timeout. Cependant, ChatGPT fait alors une série de propositions, visant à réduire le temps de calcul nécessaire (stratification, réduction du nombre d’arbres, diminution de la cardinalité de certaines variables…).

Une approche pertinente serait probablement d’utiliser ChatGPT ou un de ses concurrents pour découvrir les données, identifier rapidement des anomalies ou des problèmes de qualité, les approches possibles, les modèles de prédiction adaptés… On pourrait aussi demander de générer des graphiques, des tableaux, des chiffres… On pourra ensuite récupérer les morceaux de codes proposés qui pourront être intégrés dans un script ou un notebook consolidé. Notons que l’on peut également interagir avec les API de ChatGPT et autres Gemini. Nous aborderons cette approche dans un prochain article.

En regardant vers l’avenir, nous ne craignons pas que le GenAI remplace les data scientists. De toute évidence, l’augmentation inévitable des volumes de données de plus en plus importants et complexes ne va faire qu’accroître la nécessité de personnel capable de mener leur analyse. Mais le GenAI va indiscutablement changer leur métier. Et le GenAI va certainement remplacer les data scientists qui ne l’utilisent pas par les data scientists qui sauront s’en servir efficacement.

Containercertificering

Het gebruik van Kubernetes-pods als abstractielaag voor vertrouwelijke container-workloads introduceert diverse uitdagingen. Door hun dynamische karakter – het maken, verwijderen, updaten van de containers – en de invloed van de Kubernetesomgeving (omgevingsvariabelen, toelatingscontrollers, enz.) valt het moeilijk te garanderen dat enkel de door de gebruiker bedoelde code wordt uitgevoerd. Zo kan het injecteren van kwaadaardige variabelen of het wijzigen van de specificatie van een pod voordat deze wordt gestart, de vertrouwelijkheid in gevaar brengen.

Het CoCo-project stelt een elegante oplossing voor, namelijk het gebruik van een engine voor beveiligingsbeleid, geïntegreerd in de containerruntime-omgeving binnen de trusted execution environment (TEE), die de door de gebruiker gedefinieerde regels toepast. Deze engine kan bijvoorbeeld alleen bepaalde images of commando’s toestaan en problematische verzoeken (zoals het uitvoeren van ongeoorloofde processen) afwijzen. Figuur 1 toont een voorbeeld van zo’n beleid.

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

Figuur 1 – Voorbeeld van een beperkend beveiligingsbeleid voor images die kunnen worden uitgevoerd en de commando’s die in de image kunnen worden aangeroepen. Dit beleid wordt toegepast door een agent die in de vertrouwelijke VM zit.

Vier componenten van de vertrouwelijke virtuele guestmachine worden altijd gecontroleerd om te bepalen of ze nog goed werken: de firmware (bijvoorbeeld OVMF), de kernel van het besturingssysteem, de kernel commandoregel en het rootbestandssysteem (Figuur 2). Een vertrouwelijke externe entiteit, vaak Trustee genoemd, zorgt ervoor dat de vertrouwensketen versterkt wordt.

Vertrouwelijke containers hebben echter meestal initialisatiedata nodig die niet direct in de image van de virtuele machine of de toepassingscontainer kunnen worden opgenomen, zoals certificaten, adressen van certificeringsdiensten of toe te passen beveiligingsbeleidsregels. Deze data zijn weliswaar niet geheim, maar moeten wel worden beschermd tegen wijzigingen.

Deze initialisatiedata, ook wel init-data genoemd, kunnen worden opgegeven in de vorm van een woordenboek (bijv. JSON-bestanden, TOML, YAML), gecodeerd in base64 en doorgegeven aan de Kubernetes-pod via een Kubernetes annotation (Figuur 3). Om de integriteit ervan te garanderen, wordt hun cryptografische hashwaarde door de certificeringsagent (die in de vertrouwelijke virtuele machine draait) als data voor de berekening van de certificering verstrekt (dit kan worden gedaan met behulp van het veld “HostData” van SEV-SNP). Het is dan mogelijk om de initialisatiedata die naar de hostmachine zijn gestuurd voor het starten van de container te vergelijken met de hashwaarde die op het moment van de certificering is ontvangen, zodat elke wijziging tijdens de certificering op afstand kan worden gedetecteerd.

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

Figuur 3 – Voorbeeld van initialisatiedata die (in gecodeerde vorm) via een Kubernetes-annotatie aan de CoCo-guestagent in de vertrouwelijke virtuele machine worden geleverd.

Sleutelbeheer

Een externe sleutelbemiddelingsdienst (key broker service), die kan worden gekoppeld aan een transactionele ‘black box’, stelt de container in staat om dynamisch de resources op te halen die nodig zijn voor de werking ervan. Indien de client nog niet in het bezit is van een eerder verkregen authenticatietoken van de sleutelbemiddelingsdienst, moet hij zich eerst authenticeren, waarna de sleutelbemiddelingsdienst hem een challenge stuurt die hij moet beantwoorden (Figuur 4).

De client genereert een paar cryptografische sleutels en vraagt de processor om een certificaat te verstrekken met daarin de hashwaarde van zijn openbare sleutel en een unieke willekeurige waarde die door de dienst in zijn challenge is verzonden. Het certificaat dat de openbare sleutel van de client, de unieke willekeurige waarde die door de service is gestuurd en de meting van de vertrouwelijke VM die de client bevat aan elkaar koppelt, wordt door de processor ondertekend. De service gebruikt een certificeringsagent die het certificaat controleert door de handtekening te verifiëren en de meting te vergelijken met een referentiewaarde.

Installatie en testen

Om de CoCo-omgeving te testen, hebben we gekozen voor een EPYC 9335-microprocessor van AMD. Deze maakt gebruik van SEV-SNP-technologie voor versleuteling en bescherming van de integriteit van het RAM-geheugen. We hebben een machine geassembleerd met een moederbord dat deze microprocessor ondersteunt (Supermicro MBD-H13SSL-NT-O) en 128 GB RAM-geheugen. Vervolgens moesten we het BIOS configureren om ervoor te zorgen dat de gewenste beveiligingsfuncties van de microprocessor goed waren geactiveerd. We hebben ook gekozen voor de Ubuntu 24.04.3 LTS-distributie van het Linux-besturingssysteem. Voordat we de beveiligingsfuncties van de processor konden testen, moesten we ten slotte de kernel van het besturingssysteem opnieuw compileren. Dit is eigenlijk vrij simpel dankzij de scripts die AMD heeft meegegeven.

Eenmaal het systeem is ingesteld, kun je het Docker-platform installeren (om containerimages te maken), de containeruitvoeringsinterface containerd (inbegrepen in de Docker-distributie) en het Kubernetes-beheersysteem. Het instellen van deze tools is best lastig en afhankelijk van de versie. Er zijn verschillende scripts beschikbaar om deze installatie te vergemakkelijken.

Nadat het systeem was geïnstalleerd, konden we een bestaande toepassing in vertrouwelijke containers zetten: je hoeft alleen maar de naam van de runtimeklasse die Kubernetes gebruikt (runtimeClassName) in het YAML-configuratiebestand van Kubernetes te veranderen in een van de CoCo-klassen (bijvoorbeeld kata-qemu-snp). Natuurlijk is deze simpele wijziging niet genoeg om te profiteren van de beveiligingsfuncties van CoCo. Je moet de productiecyclus aanpassen om de volgende stappen toe te voegen:

• Versleuteling van de containerimage
• Ondertekening van de containerimage
• Beschikbaar stellen van versleutelings- en ondertekeningssleutels

Zodra de containerimage op de gebruikelijke manier is gemaakt, bijvoorbeeld met docker build, kan deze worden versleuteld met de tool skopeo, die verschillende algoritmen ondersteunt: JWE (RFC7516), PGP (RFC4880) en PKCS7 (RFC2315). Deze versleutelde image kan vervolgens worden ondertekend met de tool cosign en ten slotte worden geüpload naar een imageregister.

Bij het opstarten van de container moeten de CoCo-componenten in de vertrouwelijke virtuele machine de handtekening kunnen verifiëren en de image kunnen ontsleutelen. Hiervoor moeten de benodigde sleutels beschikbaar worden gesteld. Hier komt het sleutelbemiddelingssysteem om de hoek kijken. Zoals we eerder hebben gezien, voert dit systeem een certificeringsprotocol uit voordat het de sleutels verstrekt.

De implementatie van confidential ccontainers is transparant voor de gebruiker van Kubernetes. Zodra het gebruikelijke commando kubectl apply wordt aangeroepen, wordt een lichte Kata-virtuele machine aangemaakt. Deze moet bij de sleutelbemiddelaar de toegangssleutel tot het imageregister (als dit niet openbaar is), het toe te passen beveiligingsbeleid, de sleutel voor handtekeningverificatie en de sleutel voor het ontsleutelen van de image ophalen. Deze informatie wordt pas verstrekt nadat de virtuele machine is geverifieerd (zie hierboven). De agents in de virtuele machine kunnen dan het beveiligingsbeleid toepassen, de image downloaden, de handtekening controleren en deze decoderen voordat de toepassingscontainer in de virtuele machine wordt gestart.

Wat betreft de communicatie van de gecontaineriseerde toepassing met externe diensten, moeten wederzijds erkende versleutelingssleutels worden ingesteld. Een eerste mogelijkheid is dat de vertrouwde container bij het opstarten een cryptografisch sleutelpaar aanmaakt en de cryptografische hashwaarde van deze openbare sleutel bij de certificering verstrekt. Dit wordt gebruikt binnen het authenticatieprotocol dat in Figuur 4 wordt beschreven. Een andere optie is om de openbare sleutel van een certificeringsinstantie in de versleutelde en vervolgens ondertekende image te verstrekken. De container kan dan de certificaten checken die deze autoriteit heeft ondertekend en de encryptiesleutels aanvaarden. Een derde optie bestaat erin om te steunen op de sleutelbemiddelingsdienst: hiermee kan de container op een veilige manier geheimen ophalen. Afhankelijk van de gekozen optie moet de code van de toepassing al dan niet worden aangepast.

Bescherming tegen een beheerder

Wat kan een beheerder van de hostmachine doen?  In principe niet veel, behalve de container opstarten.

Het certificeringsmechanisme zorgt er namelijk voor dat hij niets kan vervangen of simuleren wat betreft de onderdelen van de virtuele machine die wordt gebruikt om de containers te starten. Door de versleuteling van het geheugen dat aan de virtuele machine is toegewezen, heeft hij geen toegang tot de data die in de virtuele machine en de container worden verwerkt. Door de versleuteling en ondertekening van de containerimage kan hij geen andere container vervangen of de aard van de container achterhalen. In de veronderstelling dat de toepassing geconfigureerd is om versleuteld te communiceren met externe diensten waarmee ze moet interageren, kan de beheerder ook geen toegang krijgen tot gevoelige data door het netwerkverkeer te observeren, tenzij hij ook bevoorrechte toegang heeft tot het systeem voor het aanmaken van sleutels. Ten slotte kan hij de container ook niet ondervragen via het commando kubectl exec, omdat het kan worden beperkt door een beveiligingsbeleid (zie Figuur 1).

De beheerder kan daarentegen de toepassingslogboeken lezen die door Kubernetes op de host zijn opgeslagen. Daarom is het belangrijk dat de workload provider ervoor zorgt dat zijn code geen gevoelige informatie onthult in de gelogde berichten van de toepassing.

Tot slot, zoals we in de vorige blogpost al stelden, zijn vertrouwde uitvoeringsomgevingen niet perfect en houdt hun beveiligingsmodel meestal geen rekening met fysieke aanvallen. In een omgeving zoals de G-Cloud biedt de toevoeging ervan tal van mogelijkheden. In een omgeving waar echter noch SMALS, noch haar klanten, noch zelfs de Belgische Staat enige technische of juridische controle hebben over de infrastructuur, zijn er aanzienlijke risico’s die serieus moeten worden geëvalueerd.

Conclusie

In deze blogpost en de vorige hebben we de echte voordelen belicht op het gebied van beveiliging die microprocessors kunnen bieden om “vertrouwde uitvoeringsomgevingen” binnen een IT-infrastructuur te creëren. Vooral het “on-premise” gebruik ervan  maakt het mogelijk om gecontaineriseerde toepassingen beter te beschermen tegen kwaadwillige beheerders of indringers en zo onze leden nog meer garanties te bieden.

Omdat ze eenvoudiger in gebruik zijn dan geavanceerde cryptografische methoden, kunnen dergelijke systemen ons ook helpen om meer generieke problemen op te lossen dan met cryptografie alleen, of problemen die we tot nu toe simpelweg niet konden oplossen.

Attestation de conteneurs

Les capsules Kubernetes, utilisées comme abstraction pour les charges de travail conteneurisées confidentielles, introduisent plusieurs défis. Leur nature dynamique — création, suppression, mise à jour de conteneurs — et l’influence de l’environnement Kubernetes (variables d’environnement, contrôleurs d’admission, etc.) rendent difficile la garantie que seul le code prévu par l’utilisateur sera exécuté. Par exemple, l’injection de variables malveillantes ou la modification de la spécification d’une capsule avant son lancement peuvent compromettre la confidentialité.

Le projet CoCo propose une solution élégante qui consiste à utiliser un moteur de politiques de sécurité, intégré à l’environnement d’exécution du conteneur dans l’environnement d’exécution de confiance (EEC), qui applique des règles définies par l’utilisateur. Ce moteur peut, par exemple, autoriser uniquement certaines images ou commandes, et rejeter les appels problématiques (comme l’exécution de processus non autorisés). La Figure 1 montre un exemple d’une telle politique.

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

Figure 1 – Exemple de politique de sécurité (langage REGO) restreignant les images pouvant être exécutées et les commandes pouvant être invoquées dans l’image. Cette politique est appliquée par un agent inclus dans la machine virtuelle confidentielle.

Quatre composants de la machine virtuelle confidentielle invitée sont systématiquement mesurés pour assurer leur intégrité : le micrologiciel (e.g., OVMF), le noyau du système d’exploitation, la ligne de commande du noyau et le système de fichiers racine (Figure 2). Une entité externe de confiance, généralement appelée Trustee, atteste de l’intégrité de l’invité, renforçant ainsi la chaîne de confiance.

Cependant, les conteneurs confidentiels nécessitent généralement des données d’initialisation qui ne peuvent pas être intégrées directement dans l’image de la machine virtuelle ou du conteneur applicatif, comme les certificats, les adresses des services d’attestation ou les politiques de sécurité à appliquer. Ces données, bien que non secrètes, doivent être protégées contre toute altération.

Ces données d’initialisation appelées init-data peuvent être spécifiées sous forme de dictionnaire (e.g., fichiers JSON, TOML, YAML), encodé en base64 et passé à la capsule Kubernetes via une annotation Kubernetes (Figure 3). Afin de garantir leur intégrité, leur valeur de hachage cryptographique est fournie par l’agent d’attestation (fonctionnant dans la machine virtuelle confidentielle) en donnée d’entrée pour le calcul de l’attestation (cela peut se faire en utilisant le champ « HostData » de SEV-SNP). Il est alors possible de comparer les données d’initialisation envoyées à la machine hôte pour le lancement du conteneur avec la valeur de hachage reçue au moment de l’attestation, assurant ainsi que toute modification sera détectée lors de l’attestation à distance.

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

Figure 3 – Exemple de données d’initialisation fournies (sous forme encodée) via une annotation Kubernetes à l’agent invité CoCo dans la machine virtuelle confidentielle.

Gestion de clés

Un service extérieur de médiation de clés, qui peut être connecté à une boîte noire transactionnelle, permet au conteneur d’obtenir dynamiquement des ressources nécessaires à son fonctionnement. Si le client n’est pas déjà en possession d’un témoin de connexion précédemment obtenu du service de médiation de clés, il doit d’abord s’authentifier et le service de médiation de clés lui répond avec un défi auquel il doit répondre (Figure 4).

Le client génère une paire de clés cryptographiques et demande au processeur de lui fournir une attestation en incluant la valeur de hachage de sa clé publique et une valeur aléatoire unique envoyée par le service dans son défi. L’attestation qui lie clé publique du client, valeur aléatoire unique envoyée par le service et mesure de la VM confidentielle contenant le client est signée par le processeur. Le service fait appel à un agent d’attestation qui vérifie l’attestation en vérifiant la signature et en comparant la mesure à une valeur de référence.

Installation et tests

Afin de tester l’environnement CoCo, nous avons choisi d’utiliser un microprocesseur EPYC 9335 de la société AMD. Il met en œuvre la technologie SEV-SNP de chiffrement et de protection de l’intégrité de la mémoire vive. Nous avons assemblé une machine avec une carte mère prenant en charge ce microprocesseur (Supermicro MBD-H13SSL-NT-O) et 128 Go de mémoire vive. Il a ensuite fallu configurer le BIOS afin que les fonctionnalités souhaitées de sécurité du microprocesseur soient bien activées. Nous avons aussi opté pour la distribution Ubuntu 24.04.3 LTS du système d’exploitation Linux. Avant de pouvoir tester les fonctionnalités de sécurité du processeur, nous avons enfin dû recompiler le noyau du système d’exploitation. L’opération est en fait relativement simple grâce aux scripts fournis par AMD.

Une fois le système configuré, il est alors possible d’y installer la plateforme Docker (afin de pouvoir créer des images de conteneurs), l’interface d’exécution de conteneur containerd (incluse dans la distribution de Docker) et le système de gestion Kubernetes. La configuration de ces outils est assez délicate et sensible aux version. Plusieurs scripts permettant de faciliter cette installation sont fournis ici.

Une fois le système installé, il nous a été possible de déployer une application existante dans des conteneurs confidentiels : il suffit en fait de changer le nom de classe d’exécution utilisé par Kubernetes (runtimeClassName) dans le fichier YAML de configuration de Kubernetes pour l’une des classes de CoCo (e.g., kata-qemu-snp). Bien sûr ce changement simple ne suffit pas à bénéficier des fonctionnalités de sécurité de CoCo. Il est nécessaire de modifier le cycle de production afin d’ajouter les étapes suivantes :

• Chiffrement de l’image du conteneur
• Signature de l’image du conteneur
• Mise à disposition des clés de chiffrement et de signature

Une fois l’image du conteneur créée de la manière habituelle, par exemple avec docker build, celle-ci peut être chiffrée avec l’outil skopeo qui prend en charge différents algorithmes : JWE (RFC7516), PGP (RFC4880), et PKCS7 (RFC2315). Cette image chiffrée peut ensuite être signée avec l’outil cosign et enfin chargée sur un registre d’images.

Au moment du lancement du conteneur, les composants CoCo inclus dans la machine virtuelle confidentielle devront pouvoir vérifier la signature et déchiffrer son image. Pour cela, il est nécessaire de mettre à disposition les clé requises. C’est là que le système de médiation de clés intervient. Comme nous l’avons vu précédemment, celui effectue un protocole d’attestation avant de fournir les clés.

Le déploiement des conteneurs confidentiels est transparent vis-à-vis de l’utilisateur de Kubernetes. Une fois l’invocation de la commande habituelle kubectl apply, une machine virtuelle légère Kata est créée. Celle-ci doit récupérer auprès du médiateur de clés, la clé d’accès au registre d’image (si celui-ci n’est pas public), la politique de sécurité à appliquer, la clé de vérification de signature et la clé de déchiffrement de l’image. Ces informations ne sont fournies qu’après l’attestation de la machine virtuelle (voir plus haut). Les agents inclus dans la machine virtuelle peuvent alors appliquer la politique de sécurité, télécharger l’image, vérifier sa signature et la déchiffrer avant de lancer le conteneur applicatif dans la machine virtuelle.

En ce qui concerne la communication de l’application conteneurisée avec des services extérieurs, il convient d’établir des clés de chiffrement mutuellement reconnues. Une première possibilité est que le conteneur confidentiel crée une paire de clé cryptographiques à son lancement et fournisse la valeur de hachage cryptographique de cette clé publique lors de l’attestation. C’est ce qui est utilisé dans le protocole d’authentification présenté dans la Figure 4. Une autre option est de fournir la clé publique d’une autorité de certification dans l’image chiffrée-puis-signée. Le conteneur pourra alors vérifier les certificats signés par cette autorité et accepter des clés de chiffrement. Une troisième option consiste à s’appuyer sur le service de médiation de clés : celui-ci permet au conteneur de récupérer des secrets de manière sécurisée. En fonction de l’option choisie, il conviendra de modifier plus ou moins le code de l’application.

Protection vis-à-vis d’un administrateur

Que peut faire un administrateur de la machine hôte ? A priori, pas grand-chose, à part lancer le conteneur.

En effet, le mécanisme d’attestation l’empêche de substituer ou de simuler les composants de la machine virtuelle utilisée pour le lancement des conteneurs. Le chiffrement de la mémoire allouée à la machine virtuelle le bloque dans l’observation des données traitées dans la machine virtuelle et le conteneur. Le chiffrement et la signature de l’image du conteneur ne lui permettent ni de substituer un autre conteneur, ni de connaître la nature du conteneur. En supposant que l’application soit configurée pour communiquer de manière chiffrée avec les services extérieurs avec lesquelles elle doit interagir, l’administrateur ne peut pas non plus accéder aux données sensibles en observant le trafic réseau, sauf s’il a également un accès privilégié au système de création des clés. Enfin, il ne peut pas non plus interroger le conteneur via la commande kubectl exec car celle-ci peut être restreinte via une politique de sécurité (voir Figure 1).

En revanche, l’administrateur peut lire les journaux applicatifs enregistrés par Kubernetes sur l’hôte. Par conséquent, il est important que le fournisseur de la charge de travail prenne soin que son code ne divulgue pas des informations sensibles dans les messages journalisés de l’application.

Enfin, comme nous l’avons rappelé dans l’article précédent, les environnements d’exécution de confiance ne sont pas parfaits et leur modèle de sécurité ne tient généralement pas compte des attaques physiques. Dans un environnement comme le G-Cloud, leur ajout offre de nombreuses possibilités. En revanche, dans un environnement où ni SMALS, ni ses clients, ni même l’État belge n’ont le moindre contrôle technique ou juridique sur l’infrastructure, il existe des risques importants qu’il convient d’évaluer sérieusement.

Conclusion

À travers cet article et le précédent, nous avons mis en avant les avantages réels en termes de sécurité que pourraient apporter des microprocesseurs permettant de créer des environnements d’exécution de confiance au sein d’une infrastructure informatique. En particulier, leur utilisation « on-premise » permet de mieux protéger des applications conteneurisées d’administrateurs malveillants ou d’intrus et donc d’offrir des garanties encore plus fortes à nos Membres.

Plus simples d’utilisation que les méthodes cryptographiques avancées, de tels systèmes pourraient aussi nous permettre de résoudre des problèmes plus génériques que la cryptographie ou des problèmes que nous ne pouvions pas résoudre jusqu’à présent.

Dit artikel is ook beschikbaar in het Nederlands.

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 blogue, 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 en 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 d’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 traitement par lots, 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 descendante, que nous pouvons toutefois compléter par une version ascendante : 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 base de connaissances 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 outils 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”.

Cet article est aussi disponible en français.

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 “moeilijkheidsgraad” 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 (de standaardcode om tot iets werkend te komen) 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 OpenClaw 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 beperkte 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 aangekaart, 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.

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

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

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

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

Séparation des rôles

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

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

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

Environnement d’exécution de confiance

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

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

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

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

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

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

Cas d’usage

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

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

CoCo

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

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

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

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

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

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

Conclusion

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

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

Références

[1]        C. Bômont, « Strategic Brief no.70 – 2024 – Extension of the FISA Law European “digital sovereignty” far from American concerns – IRSEM », Institut de Recherche Stratégique de l’Ecole Militaire. Consulté le: 9 février 2026. [En ligne]. Disponible sur: https://www.irsem.fr/en/strategic-brief-no-70-2024

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

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

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

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

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

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

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

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

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

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

Confidential Computing omvat een geheel van technologieën waarmee gevoelige data zodanig worden beschermd dat ze niet hoeven te worden ontsleuteld om te worden verwerkt. Hoewel sommige technologieën, zoals homomorfe versleuteling, nog steeds erg complex zijn om te implementeren, zijn Trusted Execution Environments (TEE’s) inmiddels zo ver ontwikkeld dat ze kunnen worden beschouwd als belangrijke technologie bij databescherming.

Het belangrijkste doel van TEE’s is om een buffer te vormen tegen de nieuwsgierigheid van de entiteiten die de infrastructuur beheren. Technische bescherming lost echter niet alles op. Extraterritoriale wetten [1-5] en het gebruik van eigen softwarelibrary’s die door sommige IT-infrastructuurproviders worden opgelegd, kunnen deze isolatie ondermijnen.

In deze en de volgende blogpost kijken we naar de mogelijkheid om TEE’s op onze eigen infrastructuur (on-premise) te gebruiken. Het doel is drieledig: gebruikmaken van de kracht van confidential computing om data te beschermen en nieuwe toepassingen mogelijk te maken, terwijl we een zekere controle behouden over de software- en hardwarestack, en zo het vertrouwen van onze klanten versterken.

Scheiding van rollen

Laten we beginnen met een overzicht van de verschillende spelers die betrokken zijn bij de implementatie van een toepassing op een IT-infrastructuur. Hun rollen moeten strikt gescheiden zijn om de integriteit van het systeem te garanderen.

• De infrastructure operator beheert de hardware en infrastructuur (computing, storage, network) en onderhoudt de beveiligde runtime-omgevingen. Hij beheert de firmware-updates en de toewijzing van middelen, maar zou geen toegang mogen hebben tot de data of de uitgevoerde workloads.
• De orchestration operator, die dezelfde kan zijn als de infrastructure operator, is verantwoordelijk voor het beheer van de serverclusters en de implementatie van de workloads. Hij configureert de benodigde middelen voor de toepassing en houdt toezicht op de bijbehorende diensten (logging, monitoring). Ook zijn rechten zouden strikt beperkt moeten blijven om elke vorm van inbreuk op de toepassing te voorkomen, terwijl de noodzakelijke orchestratie wel mogelijk blijft.
• De workload provider ontwerpt de specificaties van de toepassingen en kiest de juiste container images, waarbij hij de conformiteit en integriteit ervan garandeert. Hij moet aan de data owners (zie hieronder) laten zien dat de gebruikte code veilig is en de privacy respecteert, zonder direct toegang te geven tot gevoelige data.
• De container image provider bouwt, ondertekent en versleutelt de container images, zodat hun herkomst en veiligheid gegarandeerd zijn. Hij verstrekt de verificatie en decryptiesleutel. Zijn samenwerking met de toepassingsprovider is cruciaal om de softwareketen te garanderen en ervoor te zorgen dat de geïmplementeerde code precies dezelfde is als de geauditeerde code.
• Ten slotte bezit de data owner de data die door de toepassingen worden verwerkt en eist hij de vertrouwelijkheid en integriteit ervan. Hij vertrouwt op de code van de toepassing (de container) en de cryptografische bewijzen die door de microprocessor worden geleverd, waardoor infrastructure en orchestration operators buiten zijn vertrouwensbereik vallen. Hij kan extra controles opleggen om ervoor te zorgen dat zijn data niet zichtbaar zijn voor of gemanipuleerd worden door onbevoegde personen.

De relaties tussen deze spelers brengen specifieke uitdagingen met zich mee: de data owner moet bijvoorbeeld kunnen vertrouwen op de code van de containers (geleverd door de workload provider) om zijn data te verwerken, terwijl hij deze tegelijkertijd moet beschermen tegen andere spelers, zoals de infrastructure of orchestration operator. Met name de beheerders van deze operators mogen in geen geval toegang hebben tot de data die door de containers worden verwerkt.

Betrouwbare runtime-omgeving

Met TEE’s kan een technische barrière worden gecreëerd die het vertrouwen van de data owner in de toepassingscontainer versterkt. We hebben al uitvoerig uitgelegd hoe ze werken en wat hun voor- en nadelen zijn in een technisch rapport [6] en blogposts [7], [8]. Hier gaan we even de belangrijkste punten herhalen alvorens we de technologische keuzes voor een implementatie op onze onderzoeksinfrastructuur voorstellen.

Het goed functioneren van TEE’s hangt af van de hardware. Sommige moderne microprocessors maken het mogelijk om een deel van het RAM-geheugen dat is toegewezen aan een specifieke virtuele machine (VM) te reserveren en te versleutelen. Zo zal een beheerder van de hostmachine, zelfs met de hoogste privileges, alleen versleutelde data zien als hij dit geheugengebied probeert te inspecteren. Hoewel er aanvallen via side-channels bestaan (bijv. [9]), vereisen deze vanwege hun complexiteit doorgaans langdurige fysieke toegang en de toevoeging van kwaadaardige hardwarecomponenten, waardoor ze in de praktijk uiterst moeilijk uit te voeren zijn.

Opdat de data owner er zeker van kan zijn dat zijn toepassing in een veilige omgeving draait, gebruikt hij het certificeringsmechanisme. Dit proces genereert een cryptografische handtekening van de inhoud van het geheugen van de VM op het moment dat deze wordt opgestart. Deze handtekening wordt gecertificeerd door de fabrikant van de microprocessor.

Dit proces heeft zijn beperkingen, vooral als de infrastructure operator een buitenlandse onderneming is (bijvoorbeeld Amazon AWS, Google Cloud of Microsoft Azure) die zijn eigen libraries in de VM oplegt om bijvoorbeeld de juiste hardware-abstractielaag te bieden.

Dit heeft ons ertoe aangezet om dit soort hardware op onze eigen infrastructuur binnen het onderzoekslabo te testen, in afwachting van de mogelijkheid om dit op een dag op G-Cloud toe te passen. Het voordeel hiervan is dat een klant van SMALS een toepassingscontainer op een veilige manier kan gebruiken, zonder dat een beheerder van SMALS toegang heeft tot de inhoud van de container.

Maar het nut van TEE’s gaat verder dan alleen bescherming tegen beheerders. Het opent de deur naar andere toepassingen.

Use case

Een eerste voorbeeld is te vinden in de Europese infrastructuur voor digitale gezondheidsdiensten (eHDSI). Daar kunnen zorgverleners in het land waar de behandeling plaatsvindt de relevante gezondheidsdata van de patiënt opvragen in het land waar de patiënt is aangesloten. Technisch gezien wordt de aanvraag via de gateway van het nationale contactpunt voor gezondheidszorg (NCPeH) van het land waar de onverwachte gezondheidsgebeurtenis plaatsvindt, doorgestuurd naar het land waar de patiënt is aangesloten. De gevraagde info moet dan worden opgehaald uit de nationale infrastructuur van het land van aansluiting, vertaald naar het Engels en getranscodeerd (de gezondheidsdata worden omgezet van het nationale coderingssysteem naar het algemeen aanvaarde coderingssysteem, bijvoorbeeld van het FHIR– of KMEHR-formaat naar CDA), en vervolgens teruggestuurd en gepresenteerd worden aan de zorgverlener in het land van behandeling. Vanwege het gevoelige karakter van de data moeten deze van begin tot eind worden versleuteld, vanaf de gegevensbron op de infrastructuur van het land van aansluiting tot aan de zorgverlener in het land van behandeling. In de praktijk is dit nog niet mogelijk vanwege de grote verschillen tussen de Europese landen. Het zou echter op zijn minst mogelijk moeten zijn om te garanderen dat de data versleuteld en ontoegankelijk blijven voor alle gebruikers of beheerders tussen de bron van de data en de uitgang van de NCPeH-gateway. Een mogelijkheid is dan om TEE’s te gebruiken voor het vertalen en transcoderen van de data.

Een ander voorbeeld van het gebruik van TEE’s is de beveiligde samenwerking tussen entiteiten die hun ruwe data niet willen delen. In de onderwijs- en werkgelegenheidssector heeft een experiment van Bogdanov et al. in Estland [10] de kracht van confidential computertechnieken aangetoond. De auteurs van deze studie wilden achterhalen of werken naast een hogere opleiding ertoe leidt dat je je diploma niet op tijd behaalt – een vraag die vooral belangrijk is voor de sector van de informatie- en communicatietechnologie (ICT) in Estland. Om deze probleemstelling te beantwoorden zonder de privacy van persoonlijke data in gevaar te brengen, hebben de onderzoekers de onderwijsregisters van het ministerie van Onderwijs en Onderzoek gecombineerd met de data van de belastingdienst, dankzij een speciale techniek van confidential computing. Maar een simpelere variant met een TEE zou net zo goed hebben gewerkt voor de analyse, terwijl de fiscale vertrouwelijkheid en databescherming gewaarborgd bleven.

CoCo

Om TEE’s te gebruiken in onze eigen onderzoeksinfrastructuur bestaan er verschillende softwareoplossingen. We hebben gekozen voor het project “Confidential Containers (CoCo)“, waarvan de broncode vrij toegankelijk is. Dit project zorgt voor een goede isolatie van de toepassingscontainers en ondersteunt het certificeringsmechanisme op een transparante manier, terwijl de flexibiliteit van de implementatie en de compatibiliteit met het Kubernetes-platform waarop het is gebaseerd, behouden blijven. Elke Kubernetes-pod is geïsoleerd in een zeer lichte Confidential Virtual Machine, om te garanderen dat alleen geautoriseerde applicaties toegang hebben tot gevoelige gegevens.

CoCo’s bevatten naast de toepassing zelf enkele noodzakelijke softwarecomponenten. Deze maken het mogelijk om de uit te voeren containerimage te downloaden, de verificatie van de certificering te vergemakkelijken en bepaalde beveiligingsbeleidsregels toe te passen. Hun programmeerinterface is relatief klein, vooral vergeleken met een oplossing waarbij een hele Kubernetes-node in een Confidential Virtual Machine wordt geplaatst. Bovendien is de image van de guest-VM statisch en generiek voor alle workloads en zelfs platforms, waardoor het eenvoudiger is om veiligheidsgaranties te bieden. Tegelijkertijd is het makkelijk om dingen te delen tussen containers in dezelfde Kubernetes-pod. De naamruimte van het netwerk van de pod blijft bijvoorbeeld binnen de confidential VM, waardoor de containers daarin zonder extra kosten vertrouwelijk met elkaar kunnen communiceren.

CoCo is gebaseerd op Kata-containers, een ander open source-project, waarmee Kubernetes-pods kunnen worden uitgevoerd binnen zeer lichte Confidential Virtual Machines (zie Figuur 1). CoCo voegt echter twee cruciale componenten toe om vertrouwelijkheid en veiligheid te garanderen (zie Figuur 2).

• De eerste heeft te maken met het ophalen van containerimages: deze worden meestal gedownload door de Kubernetes-hoofdnode met behulp van een Container Runtime Interface (CRI) zoals “containerd”, waardoor de images via het bestandssysteem zichtbaar worden voor de hostmachine. Met CoCo worden de images binnen de Confidential Virtual Machine ontsleuteld en uitgepakt, vandaar de noodzaak van de bovengenoemde componenten.
• Het tweede onderdeel is het certificaat, dat, zoals we al hebben gezien, essentieel is voor het opzetten van een betrouwbare uitvoeringsomgeving. Om bijvoorbeeld een image te ontsleutelen, dient de guest de geheime ontsleutelingssleutel te kunnen verkrijgen, maar deze wordt alleen verstrekt als de guest zijn authenticiteit kan aantonen. Dit is de rol van twee componenten die steunen op een zogenaamd “Trustee”-systeem, dat buiten de virtuele machine staat en uit twee diensten bestaat: een certificeringsdienst om de vertrouwde runtime te valideren en een key mediation-dienst om de geheime middelen te leveren die de virtuele machine en de toepassing nodig hebben.

CoCo levert dus de basis voor het bouwen van confidential toepassingscontainers door het mogelijk te maken deze containers binnen confidential virtuel machines uit te voeren, waarbij de geëncrypteerde en ondertekende images van de containers, de verzegelde geheimen en andere kenmerken worden beheerd. Elke container of groep containers van dezelfde toepassing kan worden toegewezen aan een confidential virtuele machine, waarbij niet alleen de werklast wordt meegenomen, maar ook processen waarmee de toepassing bepaalde beveiligingsdiensten kan aanroepen.

Alles buiten de confidential VM op de host wordt als onbetrouwbaar beschouwd, inclusief de kubelet-tool, de runtime-interface van de containers en de kernel van het besturingssysteem van de host. De uitwisseling van informatie tussen vertrouwde en niet-vertrouwde contexten wordt streng gecontroleerd, met name via dynamische en configureerbare beveiligingsbeleidsregels. Ten slotte wordt de Kubernetes-orkestratie zelf als niet-vertrouwd beschouwd, waardoor de garanties met betrekking tot de planning of de volgorde van uitvoering van de workloads beperkt zijn, met uitzondering van de implementatie ervan in een geauthenticeerde enclave.

Conclusie

Confidential containers maken deel uit van een algemene beveiligingsaanpak, waarbij certificering, verificatie van images en best practices in de softwaretoeleveringsketen worden gecombineerd. Ze maken het mogelijk om use cases eenvoudiger te verwerken dan geavanceerde cryptografie (confidential collaboration, private set intersection, geavanceerde pseudonimisering, enz.). Puristen kunnen natuurlijk aanvoeren dat een oplossing op basis van confidential containers minder veilig is, maar in de praktijk zal deze waarschijnlijk volstaan in een on-premise omgeving, des te meer omdat het veel aspecten vereenvoudigt zodra het eenmaal is geïmplementeerd.

In de volgende blogpost gaan we dieper in op de installatie en het gebruik van confidential CoCo’s.

Referenties

[1]        C. Bômont, “Strategic Brief no.70 – 2024 – Extension of the FISA Law European ‘digital sovereignty’ far from American concerns – IRSEM”, Institut de Recherche Stratégique de l’Ecole Militaire. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.irsem.fr/en/strategic-brief-no-70-2024

[2]        D. Michels, “Europeans, forget the US Cloud Act… worry about FISA instead (!)”. Geraadpleegd: 1 juli 2025. [Online]. Beschikbaar op: https://www.linkedin.com/pulse/europeans-forget-us-cloud-act-worry-fisa-instead-dave-michels-anjze

[3]        Paul Kunert, “Microsoft exec admits it ‘cannot guarantee’ data sovereignty”. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/

[4]        M. Rochefort, “Microsoft face au Sénat : l’aveu qui fait vaciller la souveraineté numérique française”, clubic.com. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.clubic.com/actualite-573438-microsoft-face-au-senat-l-aveu-qui-fait-vaciller-la-souverainete-numerique-francaise.html

[5]        D. Deridder, “Understanding Sovereignty: Who Rules your Cloud?”, Dirk Deridder. Geraadpleegd: 1 juli 2025. [Online]. Beschikbaar op: https://dirkderidder.wordpress.com/2025/03/13/understanding-sovereignty-who-rules-your-cloud/

[6]        F. A. P. Petitcolas, “Informatique confidentielle – État de l’art”, Smals Research, jul. 2023. [Online]. Beschikbaar op: https://www.smalsresearch.be/publications/document?docid=269

[7]        F. A. P. Petitcolas, “Introduction à l’informatique confidentielle”, Smals Research. Geraadpleegd: 9 januari 2026. [Online]. Beschikbaar op: https://www.smalsresearch.be/introduction-a-l-informatique-confidentielle/

[8]        F. A. P. Petitcolas, “Outils pour l’informatique confidentielle”, Smals Research. Geraadpleegd: 9 januari 2026. [Online]. Beschikbaar op: https://www.smalsresearch.be/outils-pour-linformatique-confidentielle/

[9]        J. De Meulemeester, D. Oswald, I. Verbauwhede, en J. V. Bulck, “Battering RAM: Low-cost interposer attacks on confidential computing via dynamic memory aliasing”, gepresenteerd bij 47th IEEE Symposium on Security and Privacy (S&P), mei 2026.

[10]      D. Bogdanov, L. Kamm, B. Kubo, R. Rebane, V. Sokk, en R. Talviste, “Students and taxes: a Privacy-preserving study using secure computation”, Proc. Priv. Enhancing Technol., vol. 2016, nr. 3, pp. 117-135, jul. 2016, doi: 10.1515/popets-2016-0019.

Het opmerkelijke meertalige potentieel van grote taalmodellen (LLM’s) heeft bijgedragen aan de brede verspreiding en integratie ervan binnen AI-gebaseerde toepassingen. Er bestaan echter prestatieverschillen tussen het Engels en andere talen, met name talen met beperkte middelen.

Bij de evaluatie van een door ons ontwikkelde RAG-chatbot stelden we een duidelijk verschil vast in de kwaliteit van de antwoorden, afhankelijk van de gebruikte taal. De chatbot leverde namelijk betere antwoorden in het Frans dan in het Nederlands. De in het Frans gegenereerde antwoorden waren vlotter en betrouwbaarder ten opzichte van de door de gebruiker gevraagde informatie. De antwoorden in het Nederlands waren over het algemeen minder relevant. Deze resultaten wijzen op een cruciale uitdaging bij de ontwikkeling van LLM’s die door chatbots worden gebruikt: hoewel deze indrukwekkende meertalige capaciteiten hebben, vertonen de huidige modellen vaak een uitgesproken voorkeur voor talen met veel middelen, zoals het Engels.

In deze blogpost beschrijven we de resultaten van ons onderzoek naar de door ons vastgestelde taalkloof en tonen we de bevindingen van ons onderzoek.

Prestatieverschil tussen het Engels en de andere talen: oorzaken en factoren

Verschillende factoren dragen bij aan de taalvoorkeur voor het Engels. Deze omvatten:

• Onevenwichtige datasets: het trainingsproces van grote taalmodellen is gebaseerd op omvangrijke tekstcorpora, maar deze worden sterk gedomineerd door het Engels, gevolgd door talen met veel taalkundige middelen zoals het Chinees, het Frans en het Spaans. Daarentegen zijn de data in talen met beperkte middelen vaak van mindere kwaliteit vanwege het beperkte aantal bronnen. Dit onevenwicht in de data leidt tot slechte prestaties in andere talen dan het Engels, met hogere foutpercentages en hallucinaties tot gevolg. Om dit probleem op te lossen, maken modelontwikkelaars gebruik van een techniek die “interlinguïstische overdracht” genoemd wordt. Hierbij verbetert een model zijn prestaties in minder goed uitgeruste talen door universele of gedeelde taalkundige patronen af te leiden uit talen met veel middelen. Hoewel het exacte percentage Engelstalige data in propriëtaire modellen niet openbaar bekend is, is 93% van de data die worden gebruikt om GPT-3 te trainen in het Engels. Leveranciers van grote taalmodellen, zoals OpenAI en Google, maken vaak gebruik van het Common Crawl-webgegevensarchief, dat zelf wordt gekenmerkt door een dataset waarin het Engels overheerst (44% in het Engels, 4% in het Frans, 2% in het Nederlands). Deze vertekening wordt nog versterkt in gespecialiseerde domeinen zoals financiën en gezondheidszorg, waar hoogwaardige data bijzonder schaars is. Het is belangrijk op te merken dat het Nederlands wordt beschouwd als een taal met hoge middelen in het domein van automatische natuurlijke taalverwerking (NLP), hoewel het over minder middelen beschikt dan het Frans of het Engels.
• Morfologie en tokenisatie: modelarchitecturen zijn vaak geoptimaliseerd voor het Engels. Tokenisatieprocessen kunnen ingewikkeld zijn voor talen die niet met het Latijns alfabet worden geschreven, zoals het Chinees of het Japans, alsook voor talen met een gemiddelde tot hoge morfologische complexiteit, zoals het Nederlands. Engelse tokenizers kunnen het moeilijk hebben met het verwerken van samengestelde woorden (de combinatie van meerdere zelfstandige naamwoorden in een woord), wat kan leiden tot grammaticaal foute resultaten wanneer modellen tekst genereren.

Zeer weinig studies hebben de prestaties geanalyseerd van grote taalmodellen in het Frans en het Nederlands. Een onderzoek naar de taalkundige kwaliteit van LLM’s in deze twee talen bracht aan het licht dat de prestaties algemeen beter waren in het Frans dan in het Nederlands, in het bijzonder bij taken waarbij tekst moest worden gegenereerd [1]. Een ander onderzoek rapporteerde betere prestaties van LLM’s in het Engels in vergelijking met het Nederlands bij een vraag-antwoordtaak [2].

In de industrie blijven er grote uitdagingen bestaan met betrekking tot de toepassing van grote taalmodellen op niet-Engelse technische domeinen, met name in de medische en financiële sector. De huidige implementaties vereisen vaak een verfijning van de vooraf getrainde modellen zoals Mistral en Llama om bevredigende prestaties te bereiken.

Een andere bekende uitdaging bij de toepassing van AI-modellen in de Nederlandse taalomgeving is spraakherkenning. Dit is grotendeels een gevolg van de grote variatie in regionale accenten. Onze experimenten met het transcriberen van opnames van Teams-vergaderingen hebben aangetoond dat de Franse transcripties systematisch van betere kwaliteit waren dan de Nederlandse. Gespecialiseerde tools zoals Sembly leveren echter acceptabele transcriptieresultaten in het Nederlands.

Vergelijkende analyse van de prestaties van het Nederlands en het Frans in een chatbot

Er is een vergelijkende analyse van de prestaties uitgevoerd op een chatbot die is ontwikkeld om vragen van burgers te beantwoorden. Voor de eerste evaluatie van de chatbot hebben we een reeks vragen gebruikt die door experts zijn opgesteld. Deze vragen werden in het Frans en het Nederlands aan de chatbot voorgelegd, waarna de antwoorden door dezelfde expert werden beoordeeld en door twee andere personen werden gecontroleerd. Uit de eerste evaluatie blijkt een aanzienlijk verschil in prestaties tussen de twee talen: de chatbot behaalde een nauwkeurigheid van 95% in het Frans, tegenover 82% in het Nederlands.

Na de implementatie van de chatbot in een productieomgeving werd een tweede evaluatiefase uitgevoerd op basis van vragen die door gebruikers waren ingediend en in een database waren opgeslagen. We merkten opnieuw een verschil in prestaties: 82% nauwkeurigheid in het Frans en 69% in het Nederlands.

Verschillende factoren kunnen bijdragen aan deze waargenomen verschillen, waaronder:

• de vooringenomenheid van de beoordelaars – beoordelaars zijn minder of meer streng in hun beoordelingen;
• de variatie in het soort vragen (dubbelzinnig, slecht geformuleerd, niet ter zake) – dezelfde vragen werden niet systematisch in beide talen beoordeeld;
• het kwaliteitsverschil bij het ophalen van de bronnen (retrieval) – er zijn verschillen tussen de talen in de data-bronnen die worden opgehaald om de generatie te voeden;
• de intrinsieke capaciteiten van het generatieve model (GPT-4o) in beide talen.

Er was dus aanvullend onderzoek nodig om de waargenomen verschillen in het Frans en het Nederlands volledig te begrijpen en deze factoren te verminderen.

Test

Om de prestaties van LLM’s in zowel het Frans als het Nederlands grondig te evalueren, werd een experiment uitgevoerd met de chatbot. We selecteerden een aantal vragen waarvan de eerdere antwoorden van LLM’s als onjuist waren beoordeeld, waarbij we ervoor zorgden dat de vragen niet te complex of te simplistisch waren. Het was van cruciaal belang dat elke vraag van een gebruiker tussen het Frans en het Nederlands werd vertaald om een directe vergelijking te vergemakkelijken. Bij het evaluatieproces waren twee onafhankelijke evaluatoren betrokken, een vakexpert en een technisch expert, om vooringenomenheid te beperken en een robuuste evaluatie te garanderen. De evaluatoren beoordeelden de nauwkeurigheid, relevantie en vlotheid van de gegenereerde antwoorden. Daarnaast werden ook andere modellen dan GPT-4o getest.

Naast de tests in het Nederlands en het Frans hebben we ook een test uitgevoerd waarbij vragen in het Nederlands naar het Engels werden vertaald. De antwoorden werden in het Engels gegenereerd en vervolgens opnieuw naar het Nederlands vertaald.

Resultaten

Vraag in het Nederlands, antwoord in het Engels

Het experiment waarbij vragen in het Nederlands naar het Engels werden vertaald en hierna de antwoorden naar het Nederlands werden vertaald leverde een genuanceerd resultaat. Hoewel de vertaling van Nederlandstalige vragen naar het Engels leidde tot ietwat betere antwoorden, van 67% naar 73%, verslechterde de kwaliteit van de antwoorden bij het omgekeerde proces, namelijk het vertalen van de gegenereerde Engelse antwoorden naar het Nederlands.

Nauwkeurigheid van Franse antwoorden versus nauwkeurigheid van Nederlands antwoorden

Tijdens ons experiment hebben we de antwoorden gegenereerd op basis van Nederlandstalige vragen vergeleken met hun Franse equivalenten in verschillende tekstreeksen. We hebben vastgesteld dat de samenstelling van deze reeksen een invloed had op de evaluatie van het model. De scores varieerden namelijk van set tot set voor elk model en elke taal, en de prestatieverschillen tussen de talen kwamen niet altijd tot uiting. Dit onderstreept het belang van het selectieproces van de testvragen: voor onze laatste test hebben we een evenwichtige testset samengesteld met voorbeelden van vragen die door gebruikers in beide talen zijn ingediend en vragen die door domeinexperts zijn opgesteld. In tegenstelling tot wat aanvankelijk werd waargenomen, laten de onderstaande resultaten slechts een klein verschil in nauwkeurigheid zien tussen het Frans en het Nederlands voor onze use case.

Tabel 1. Resultaten van de eindevaluatie van de chatbot.

Opmerking: slecht geformuleerde vragen in het Frans of Nederlands werden uit de testset verwijderd omdat ze moeilijk nauwkeurig in de andere taal te vertalen bleken.

Vergelijking van de LLM’s

GPT-5 presteerde goed op het vlak van nauwkeurigheid en beknoptheid. Het vertoonde echter een groter verschil in nauwkeurigheid tussen het Frans en het Nederlands dan de andere modellen. Gemini presteerde weliswaar beter in zowel het Frans als het Nederlands, maar genereerde aanzienlijk langere antwoorden, wat leidde tot een hoger tokengebruik. We hebben ook vastgesteld dat Claude Sonnet, met een vergelijkbare nauwkeurigheid als Gemini, soms Engelse termen invoegde in het gegenereerde antwoord, en dit vaker in het Nederlands dan in het Frans. Na evaluatie concludeerden de experts op dit gebied dat Gemini het meest geschikte model was voor hun use case.

Effect van de retrieval

Het proces van retrieval bestaat erin om relevante tekstfragmenten te extraheren om een vraag te beantwoorden vanuit de vector database, afhankelijk van de gelijkenis tussen de vraag en deze fragmenten. Deze gelijkenis wordt berekend met behulp van vectorrepresentaties van de teksten, gegenereerd door een embeddingmodel. We hebben vragen geanalyseerd die aanvankelijk betere resultaten opleverden in het Frans dan in het Nederlands en hebben vastgesteld dat ongeveer 50% van de opgehaalde informatie (context) in beide talen voorkwam. Om de impact van de resterende 50% afwijkende informatie te evalueren, hebben we het model (Gemini) aan identieke contexten onderworpen om zowel Franstalige als Nederlandstalige antwoorden te genereren. Ondanks het gebruik van deze identieke contexten bleef het model prestatieverschillen vertonen tussen het Frans en het Nederlands. Het retrievalproces lijkt dus een beperkte invloed te hebben op het waargenomen prestatieverschil tussen de twee talen.

Conclusie en aanbevelingen

Het prestatieverschil tussen het Nederlands en het Engels in grote taalmodellen is een vaststaand feit, dat geworteld is in de overweldigende dominantie van het Engels in de trainingscorpora. Dit verschil wordt nog versterkt door de specifieke morfologie van het Nederlands. Ter vergelijking: als LLM’s over het algemeen betere resultaten opleveren in het Frans, is dat te danken aan een betere vertegenwoordiging van de taal in de trainingscorpora.

Ons experiment heeft waardevolle informatie opgeleverd over de prestaties van LLM’s in een RAG-toepassing (Retrieval Augmented Generation) in het Nederlands en het Frans. Hoewel we aanvankelijk een significant verschil in nauwkeurigheid tussen de antwoorden in het Nederlands en de antwoorden in het Frans constateerden, bleek uit grondig onderzoek dat andere factoren dan de capaciteit van het model de resultaten konden beïnvloeden. Het prestatieverschil is dus minder groot dan we dachten. Bovendien hebben we vastgesteld dat variaties in de samenstelling van de testset kleine schommelingen in de resultaten veroorzaakten. Deze conclusies tonen aan dat de prestaties van LLM’s zeer gevoelig zijn voor de context en de specifieke formulering van de vragen. We hebben ook een lichte kwaliteitsverbetering  van de antwoorden waargenomen bij de Engelse vertaling van Nederlandstalige vragen; dit voordeel werd echter grotendeels tenietgedaan door de daaropvolgende Nederlandse vertaling van deze Engelse antwoorden.

De bovenstaande conclusies gelden voor een chatbot die zorgvuldig opgestelde inhoud in algemene taal gebruikt om vragen te beantwoorden. Ze zijn niet noodzakelijkerwijs van toepassing op andere use cases. Het is daarom essentieel om voor elk geval grondige evaluaties uit te voeren, zeker wanneer men in specifieke domeinen zoals gezondheidszorg, financiën, recht, enzovoort werkt.

Moeten we een eentalig model gebruiken?

We hebben deze vraag niet grondig kunnen onderzoeken. Ons literatuuronderzoek heeft geen overtuigend bewijs opgeleverd dat LLM’s voor het Nederlands de prestaties verbeteren; integendeel, de aanwezigheid van talen met veel bronnen in meertalige modellen lijkt de prestaties van minder goed bedeelde talen tot op zekere hoogte te verbeteren. Er zijn echter verschillende initiatieven genomen om LLM’s voor het Nederlands te ontwikkelen. De meest opvallende zijn:

–           GEITje: model gebaseerd op Mistral 7B en verfijnd voor het Nederlands. Dit model is niet langer beschikbaar vanwege auteursrechtelijke problemen.

–           GPT-NL: lopend initiatief, ondersteund door Nederland, om een LLM te ontwikkelen die is aangepast aan de Nederlandse taal en cultuur.

Referenties

1. Exploratory Study on the Impact of English Bias of Generative Large Language Models in Dutch and French (Rigouts Terryn & de Lhoneux, HumEval 2024)
2. Performance of Large Language Models in Domain-Specific and Underrepresented Languages: A Case Study on the Transportation Domain and Dutch Language (UHasselt)
3. MEGA: Multilingual Evaluation of Generative AI (Ahuja et al., 2023)
4. A Dutch Financial Large Language Model (Sander Noels, Jorne De Blaere & Tijl De Bie, 2024)
5. Multilingual LLMs: Progress, Challenges, and Future Directions (PremAI blogpost)
6. https://hogent-cads.github.io/blog/posts/vlaamse-spraakherkenning/ (HoGent blogpost)
7. Webinar Smals Research – Generatieve AI: verder dan de hype | Smals Research

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.

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.