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

Cryptographic recommendations

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

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

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

Recommendations as code

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

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

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

Cryptography Bill of Materials (CBOM)

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

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

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

Deviations as code

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

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

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

Conclusion

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

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

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

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

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

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

La cryptographie est essentielle dans notre société, notamment pour sécuriser les communications sensibles et les transactions financières. Les recommandations cryptographiques aident les organisations et les équipes à déterminer quand un algorithme de cryptographie doit être supprimé progressivement et remplacé par un autre dans leurs systèmes. L’expression de ces recommandations cryptographiques sous forme de code présente des avantages, tels qu’une automatisation accrue et une meilleure compréhension, et constitue une étape logique vers la maturité cryptographique.

Recommandations cryptographiques

Les algorithmes et paramètres recommandés, y compris la longueur des clés, notamment pour l’authentification, les signatures numériques, les fonctions de hachage cryptographique et le chiffrement symétrique, changent régulièrement. Les algorithmes recommandés jadis ne sont plus sûrs aujourd’hui. Il en va de même pour les suites cryptographiques dans les protocoles de communication comme TLS. Les suites cryptographiques sont des combinaisons d’algorithmes et de paramètres cryptographiques convenues par les parties communicantes. Sur cette base, un canal sûr est ensuite mis en place.

Dans de nombreux pays, y compris nos pays voisins tels que l’Allemagne, la France et les Pays-Bas, les agences nationales de sécurité de l’information publient des recommandations détaillées concernant l’utilisation de la cryptographie. Une distinction est généralement opérée entre la cryptographie recommandée (recommended), la cryptographie non recommandée mais considérée comme sûre (secure), la cryptographie à éliminer progressivement (phase out) et, enfin, la cryptographie non sûre (insecure). Ces recommandations sont actualisées régulièrement. L’agence allemande BSI le fait par exemple annuellement.

En Belgique, nous n’avons pas encore de telles recommandations. Idéalement, elles devraient être formulées au niveau européen, par exemple par  l’Agence de l’Union européenne pour la cybersécurité (ENISA). Nous n’y sommes pas encore toutefois. Néanmoins, Smals et le secteur public belge en ont concrètement besoin aujourd’hui. Aussi l’équipe Smals Research a-t-elle pris l’initiative, il y a quelques années, de formuler ses propres recommandations en interne. Ces recommandations reposent sur celles de l’agence allemande BSI, étant donné qu’il s’agit de l’agence de cybersécurité principale en Europe et la mieux subventionnée.  

Recommandations sous forme de code

Comme toutes les autres recommandations cryptographiques, celles-ci sont exprimées sous forme lisible par l’homme, mais pas suffisamment structurées pour être traitées par des machines. Ce dernier aspect autoriserait une plus grande automatisation et profiterait à la sécurité.

• Cela permettrait de générer automatiquement la partie cryptographique des fichiers de configuration pour des protocoles de communication tels que TLS et OpenSSH, avec, à la clé, des mises à jour plus rapides, moins de main-d’œuvre et moins de risques d’erreur humaine. Smals dispose en effet de centaines, voire de milliers de machines qui doivent pouvoir communiquer en toute sécurité.
• Cela permettrait d’accéder de façon interactive aux recommandations cryptographiques.
  Au moyen d’une interface web, une équipe de projet peut rapidement consulter les plus récentes recommandations cryptographiques pertinentes. Une équipe de projet peut également être automatiquement tenue informée des changements qui la concernent une fois l’application opérationnelle.

Le site web CipherSuite est ce qui s’en rapproche le plus aujourd’hui. C’est une initiative louable, mais pour plusieurs raisons, nous voulons aller plus loin avec Smals. En effet, nous ne suivons pas nécessairement ces recommandations, qui se limitent en outre au protocole de communication TLS.
De plus, nous voulons quelque chose qui soit compatible avec CBOM.

Nomenclature cryptographique (CBOM)

Dans le contexte de la menace que représentent les puissants ordinateurs quantiques, une migration majeure de la cryptographie s’impose à nouveau. Pour nous préparer à cette migration ainsi qu’à d’autres migrations futures, il est judicieux, en tant qu’organisation, de savoir où est appliquée quelle cryptographie. Ceci pour pouvoir dresser un plan de migration étayé et exécuter la migration avec plus de rapidité et de fluidité. Cet inventaire devient vite très complexe et doit donc idéalement être exprimé sous forme de code pour faciliter la mise à jour et le traitement automatiques par des machines.

IBM a dès lors développé la nomenclature cryptographique CBOM (Cryptography Bill of Materials), qui permet d’exprimer en format JSON des composants cryptographiques tels que des algorithmes, des paramètres, des protocoles et des bibliothèques ainsi que leurs dépendances. Il s’agit d’un standard OWASP CycloneDX, de sorte qu’il est compatible entre autres avec la nomenclature logicielle SBOM (Software Bill Of Materials). CBOM nous permet de faire passer la gestion des actifs cryptographiques (algorithmes, protocoles, bibliothèques, clés, certificats…) à un niveau supérieur.

L’illustration ci-dessous est un fragment de CBOM qui montre où RSA-2048 est utilisé dans le code source scanné d’une application.

Supposons qu’une organisation exprime ses actifs cryptographiques en CBOM et qu’elle dispose de recommandations cryptographiques dans un code compatible. Cette organisation peut alors vérifier très rapidement où et dans quelle mesure les recommandations cryptographiques sont observées.

Cet aperçu peut être particulièrement utile pour prendre des mesures destinées à renforcer la sécurité de l’organisation et des données qu’elle protège. Une organisation peut ainsi rapidement savoir où elle est la plus vulnérable aux puissants ordinateurs quantiques. L’organisation peut aussi rapidement communiquer des informations exactes lors d’un audit, par exemple sous la forme d’un rapport généré automatiquement au format PDF ou Excel, en réponse à des questions spécifiques de l’auditeur.

Dérogations sous forme de code

Outre les recommandations et les actifs cryptographiques, un troisième élément peut être exprimé sous forme de code lisible par une machine, à savoir les dérogations à ces recommandations.

Dans un monde idéal, Smals n’appliquerait que la cryptographie recommandée et sûre dans ses systèmes. Or, ce n’est pas toujours possible, car cela entraînerait de facto l’indisponibilité de certains services pour les utilisateurs de ces systèmes. Nous ne pouvons en effet pas attendre des médecins, des pharmaciens, des kinésithérapeutes, des CPAS, etc. qu’ils ne prennent en charge que la cryptographie sûre de dernière génération. Smals doit donc faire preuve d’une certaine tolérance et continuer à prendre en charge une cryptographie non optimale pendant une période limitée. Ceci de manière structurée, avec une période de tolérance limitée et une évaluation précise du risque par les services de sécurité et sa validation par l’équipe dirigeante.

Là encore, il est préférable de procéder de manière à permettre un traitement automatique. Ainsi, en combinaison avec les recommandations et l’inventaire, nous pouvons voir en un coup d’œil où nous dérogeons aux recommandations, sous forme documentée ou non. Cela nous permet d’avoir une idée du risque cumulé, ce qui contribue à accroître la sécurité au sein de l’organisation. Ceci aussi peut bien évidemment être utile lors d’un audit.

Conclusion

Il y a quelques années, l’équipe Smals Research a émis une proposition de recommandations cryptographiques, que Smals a adoptée et actualise au moins annuellement. L’équipe considère qu’il est temps de passer à l’étape suivante et se charge actuellement de traduire ces recommandations sous une forme structurée aussi compatible que possible avec CBOM. Elle en fait de même pour les dérogations à ces recommandations.

CBOM et les ambitions de Smals d’exprimer à la fois les actifs cryptographiques, les recommandations et les dérogations dans un format lisible par une machine s’inscrivent dans la tendance plus large du Everything as code, une philosophie qui se traduit par une automatisation accrue des processus et de la gestion. Cela nous offre un meilleur aperçu et nous permet de mieux anticiper et d’intervenir en cas de besoin. Il en résulte également une cohérence et une évolutivité accrues grâce à une moindre intervention humaine.

Selon nous, l’application de l’approche Everything as Code à la cryptographie constitue donc une étape importante dans l’augmentation de la maturité cryptographique. CBOM nous apparaît dès lors comme un standard nécessaire qui, d’après nous, sera de plus en plus pris en charge par les outils de développement, de sécurité de l’information et de migration post-quantique dans les années à venir. Nous nous attendons dès lors à ce que les fournisseurs livrent de plus en plus un CBOM avec leurs logiciels, leurs matériels ou leurs services.

Nous pensons que le triumvirat des actifs cryptographiques sous forme de code, des recommandations sous forme de code et des dérogations sous forme de code, ouvrira de nouvelles possibilités et opportunités en matière d’aperçu et d’automatisation. Une idée serait de réaliser des analyses de graphes (graph analytics) sur ce plan, idéalement à l’aide d’une base de données orientée graphes complétée d’un outil de visualisation interactif.

À suivre. N’hésitez pas à nous contacter si vous êtes intéressé.

Cette contribution a été soumise par Kristof Verslype, cryptographe chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

Cryptografie is essentieel in onze samenleving, onder meer om gevoelige communicatie en financiële transacties te beveiligen. Cryptografische aanbevelingen helpen organisaties en teams om te beslissen wanneer bepaalde cryptografie in hun systemen uitgefaseerd en vervangen dient te worden. Dergelijke cryptografische aanbevelingen uitdrukken als code heeft voordelen, zoals een verhoogde graad van automatisering en toegenomen inzicht, en is een logische stap richting cryptografische maturiteit.

Cryptografische aanbevelingen

De aanbevolen algoritmes en parameters, waaronder sleutellengtes, voor onder meer authenticatie, digitale handtekeningen, cryptografische hashfuncties en symmetrische vercijfering veranderen geregeld. Algoritmes die ooit aanbevolen werden zijn vandaag onveilig. Hetzelfde geldt voor cipher suites in communicatieprotocollen zoals TLS. Cipher suites zijn combinaties van cryptografische algoritmes en parameters die de communicerende partijen afspreken. Op basis daarvan wordt vervolgens een veilig kanaal opgezet.

In heel wat landen, waaronder buurlanden Duitsland, Frankrijk en Nederland, publiceren de nationale agentschappen voor informatieveiligheid gedetailleerde aanbevelingen omtrent het gebruik van cryptografie. Doorgaans maakt men een onderscheid tussen de cryptografie die aanbevolen wordt (recommended), de cryptografie die niet aanbevolen wordt, maar wel nog als veilig beschouwd wordt (secure), de cryptografie die we moeten uitfaseren (phase out) en, ten slotte, de cryptografie die onveilig is (insecure). Die aanbevelingen worden geregeld bijgewerkt. Het Duitse BSI doet dit bijvoorbeeld jaarlijks.

In België missen we dergelijke aanbevelingen vooralsnog. Idealiter worden deze op Europees niveau geformuleerd, bijvoorbeeld door ENISA, het Europese agentschap voor cyberveiligheid. Daar zijn we vooralsnog nog niet. Niettemin hebben Smals en de Belgische publieke sector daar wel vandaag reeds een concrete nood aan. Daarom heeft Smals Research een aantal jaar terug het initiatief genomen om eigen, interne aanbevelingen te formuleren. Deze zijn gebaseerd op die van het Duitse BSI, gezien dit toch in Europa het toonaangevende en best gesubsidieerde agentschap voor cyberveiligheid is.  

Aanbevelingen als code

Net zoals alle andere cryptografische aanbevelingen, worden deze vandaag uitgedrukt op een wijze die leesbaar is voor mensen, maar onvoldoende gestructureerd is om verwerking door machines toe te laten. Dat laatste zou hogere graad van automatisering toelaten en zou de veiligheid ten goede kunnen komen.

• Het zou toelaten om automatisch het cryptografische deel te genereren van de configuratiebestanden voor communicatieprotocollen zoals TLS en OpenSSH. Dit laat toe sneller de updates door te voeren, met minder mankracht en minder risico op menselijke fouten. Smals heeft inderdaad honderden, zoniet duizenden machines die in staat moeten zijn veilig te communiceren.
• Het zou toelaten om de cryptografische aanbevelingen interactief te ontsluiten. Via een webinterface kan een projectteam snel de meest recente voor hen relevante cryptografische aanbevelingen consulteren. Een projectteam kan ook automatisch op de hoogte gehouden worden van voor hen relevante veranderingen eens de applicatie live is.

Wat vandaag het dichtste in de buurt komt is de website CipherSuite. Dit is een lovenswaardig initiatief, maar omwille van een aantal redenen willen we met Smals verder gaan. We volgen immers niet per se deze aanbevelingen, die zich bovendien beperken tot het TLS communicatieprotocol. Bovendien willen we iets dat compatibel is met CBOM.

Cryptography Bill of Materials (CBOM)

In het kader van de dreiging van krachtige kwantumcomputers dringt zich opnieuw een grote crypto migratie op. Om ons op deze en andere toekomstige migraties voor te bereiden is het verstandig om als organisatie alvast een overzicht te bouwen van welke cryptografie waar gebruikt wordt. Dit laat toe om een onderbouwd migratieplan op te stellen en het zal bovendien de migratie zelf sneller en vlotter doen verlopen. Deze inventaris wordt al snel erg complex en wordt daarom idealiter uitgedrukt als code om een automatische bijwerking en verwerking door machines te faciliteren.

IBM ontwikkelde daarom CBOM (Cryptography Bill of Materials), wat toelaat om cryptografische componenten zoals algoritmes, parameters, protocollen en libraries en hun afhankelijkheden uit te drukken in JSON. Het is een  OWASP CycloneDX standaard, wat betekent dat het compatibel is met onder meer SBOM (Software Bill Of Materials). CBOM laat ons toe het management van cryptografische assets (algoritmes, protocollen, libraries, sleutels, certificaten …) naar een hoger niveau te tillen.

Onderstaande figuur is een CBOM fragment, dat toont waar in de gescande broncode van een applicatie RSA-2048 gebruikt wordt.

Stel dat een organisatie haar cryptografische assets uitdrukt als CBOM, en dat ze beschikt over cryptografische aanbevelingen in code die daarmee compatibel is. Dan kan die organisatie zeer snel nagaan waar in de organisatie ze in welke mate in overeenstemming is met de cryptografische aanbevelingen en waar niet. Dit inzicht kan bijzonder nuttig zijn bij het nemen van stappen om de organisatie en de data die ze beschermt veiliger te maken. Zo kan een organisatie snel te weten komen waar ze het meest kwetsbaar is voor krachtige kwantumcomputers. Ook bij audits kan de organisatie snel exacte informatie geven, bijvoorbeeld in de vorm van een automatisch gegenereerd rapport in PDF of Excel formaat, als antwoord op de specifieke vragen door de auditor.

Afwijkingen als code

Naast de aanbevelingen en de cryptografische assets is er nog een derde element dat als machine-readable code uitgedrukt kan worden: de afwijkingen op die aanbevelingen.

In een ideale wereld gebruikt Smals steeds enkel de aanbevolen en veilige cryptografie in haar systemen. Dit is niet steeds mogelijk gezien het zo de facto diensten onbeschikbaar zou maken voor gebruikers van die systemen. We kunnen inderdaad niet verwachten dat artsen, apothekers, kinesisten, OCMW’s, … allen steeds enkel de meest recente veilige cryptografie ondersteunen. Smals moet dus een zekere tolerantie aan de dag leggen waarbij het gedurende een beperkte periode sub-optimale cryptografie blijft ondersteunen. Dit gebeurt op een gestructureerde wijze, waarbij de tolerantieperiode beperkt is en waarbij het risico duidelijk ingeschat wordt door de veiligheidsdiensten en goedgekeurd wordt door het management.

Ook dit wordt het best uitgedrukt op een wijze die automatische verwerking toelaat. Zo kunnen we in combinatie met de aanbevelingen en inventaris in een oogopslag te weten komen waar we, zowel gedocumenteerd als ongedocumenteerd, afwijken van de aanbevelingen. Dit laat ons toe een beeld te krijgen van het cummulatieve risico. Dit inzicht helpt om de veiligheid in de organisatie te verhogen. Ook dit kan uiteraard nuttig zijn bij audits.

Conclusie

Een paar jaar terug deed Smals Research een voorstel tot cryptografische aanbevelingen, wat door Smals geadopteerd werd en op zijn minst jaarlijks bijgewerkt wordt. Smals Research vindt de tijd rijp voor een volgende stap en zet die aanbevelingen momenteel om naar een gestructureerde vorm die maximaal compatibel is met CBOM. Hetzelfde doet Smals Research voor de afwijkingen op die aanbevelingen.

CBOM en de ambities van Smals om zowel cryptografische assets, aanbevelingen als afwijkingen uit te drukken in een machine-readable formaat passen in de bredere tendens van Everything as code, wat een filosofie is die resulteert in een toegenomen graad van automatisering van processen en beheer. Het geeft ons meer inzicht en laat ons toe beter te anticiperen en in te grijpen indien nodig. Bovendien resulteert het in een verhoogde consistentie en schaalbaarheid dankzij de verminderde menselijke interventie.

Het toepassen van Everything as Code op cryptografie is volgens ons dan ook een belangrijke stap bij het verhogen van de cryptografische maturiteit. CBOM zien we daarom als een noodzakelijke standaard die naar onze verwachtingen de komende jaren in toenemende mate ondersteund zal worden in tools voor ontwikkeling, informatieveiligheid en post-kwantummigratie. We verwachten dan ook dat vendors meer en meer een CBOM zullen leveren bij hun software, hardware of diensten.

Onze verwachting is dat het triumviraat cryptografische assets as code, aanbevelingen as code en afwijkingen as code nieuwe mogelijkheden en opportuniteiten zullen ontsluiten richting inzicht en automatisering. Een idee is bijvoorbeeld om hierop graafanalyses (graph analytics) te doen, met behulp van een graph-database idealiter aangevuld met een interactieve visualisatietool.

Wordt vervolgd en aarzel niet ons te contacteren bij interesse.

Dit is een ingezonden bijdrage van Kristof Verslype, cryptograaf bij Smals Research. Het werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Oorzaken van datalekken en veiligheidsincidenten zijn onder andere het per ongeluk delen of verkeerd gebruiken van gevoelige gegevens door een bediende of onderaannemer, of opzettelijke diefstal van gegevens door een kwaadwillige insider voor persoonlijk gebruik. Spijtig genoeg zijn veel gebruikelijke methodes en aanpakken niet ontworpen tegen dergelijke schendingen door gebruikers die a priori betrouwbaar lijken. De efficiëntste technieken zijn nog steeds voorbehouden aan zeer specifieke sectoren.

Het probleem bestaat echter al langer. In bepaalde kritische domeinen zoals de staatsveiligheid is het een gekend probleem. Sinds de jaren 70 inspireerde het model Bell-LaPadula¹ de compartimentering van informaticasystemen in geïsoleerde beveiligingsdomeinen. Een organisatie kan bijvoorbeeld fysiek gescheiden systemen invoeren: een verbonden met internet voor gegevens zonder specifiek vertrouwelijkheidsniveau en een voor elke van de vertrouwelijkheidsniveaus van de organisatie zoals “beperkt”, “vertrouwelijk” of “geheim”. Daarbovenop komen vaak klassieke mechanismes zoals het gebruik van vercijferde bestandssystemen, de blokkering – of zelfs verwijdering – van USB-poorten, de beperking van copy/pasten in software, maar ook de controle van alle gegevens die circuleren op het informaticanetwerk zodat gevoelige of vertrouwelijke gegevens kunnen opgespoord worden.

Om gegevens van een niveau naar een ander over te brengen kan deze organisatie een beroep doen op gespecialiseerde IT gateways bij de bescherming van de gegevens. Deze veronderstellen dat elk gegeven, alsook de gebruiker of de dienst van het domein dat deze gegevens verstuurt, eerst wordt gekoppeld aan een vertrouwelijkheidslabel waarmee beslist wordt of de gegevens al dan niet doorgestuurd kunnen worden. Informatiebescherming gebeurt met andere woorden op het vlak van de data-objecten zelf in plaats van op het vlak van domeinen die aangemaakt werden met gescheiden informaticanetwerken (die soms ontoegankelijk zijn en leiden tot stoelendansen).

Vertrouwelijkheidslabels

De vertrouwelijkheidslabels zijn een manier om verschillende beveiligingskenmerken² te linken aan een specifiek object. Deze vertrouwelijkheidslabels kunnen eender welke nuttige informatie bevatten om beslissingen te nemen op het vlak van veiligheid en worden a priori beschouwd als correct wanneer een veiligheidsbeslissing zich daarop baseert. Er bestaan twee belangrijke manieren om een vertrouwelijkheidslabel toe te kennen aan een data-object:

• De veiligheidseigenschappen baseren op de oorsprong van de informatie aanwezig in het data-object. Dat is de eenvoudigste methode op voorwaarde dat de oorsprong van de informatie traceerbaar is.
• De eigenlijke inhoud van het data-object evalueren om de beveiligingskenmerken te bepalen. In een volgend artikel bekijken we hoe deze toewijzing min of meer automatisch kan verlopen.

Het gebruik van vertrouwelijkheidslabels heeft verschillende beperkingen. Bij de onderlinge verbinding van twee systemen op verschillende veiligheidsniveaus moet er rekening gehouden worden met het risico op verkeerde labeling van de objecten (bv. gebruikersfout, misbruikt of gecompromitteerd systeem, enz.). Bovendien:

• Weerspiegelt een vertrouwelijkheidslabel de beschermingsvereisten en de voorwaarden voor vrijgave van een object bij de creatie van dit label. De update van deze laatste vereist manuele handelingen die strikte beheersprocessen moeten volgen.
• De labeling volgt niet altijd correct de objecten, zelfs binnen eenzelfde organisatie.
• Omwille van subjectieve interpretaties van het veiligheidsbeleid kunnen de auteurs van de objecten verschillende vertrouwelijkheidslabels plakken op objecten met gelijkaardige inhoud. Dit kan leiden tot situaties waarin sterk gelijkende gegevens verschillende beveiligingsniveaus kunnen hebben.

De labeling van de informatie leidt dus tot minstens twee belangrijke uitdagingen. De eerste betreft het bestaan van een syntaxis en een gemeenschappelijke interpretatie van de labels – dit wil zeggen tussen de systemen die informatie willen uitwisselen. De andere is de definitie van een mechanisme waarmee deze labels verbonden kunnen worden aan de objecten waarbij de integriteit van deze link verzekerd wordt.

Gestandaardiseerd mechanisme

In 2010 heeft de onderzoeksgroep voor domeinoverschrijdende veiligheidsoplossingen van de Organisatie voor Wetenschap en Technologie van de NAVO een voorstel gepubliceerd voor XLM-specificatie voor labeling en verbinding van metagegevens. Dit werk werd later verwerkt in twee “standardisation agreements” of “STANAG”.

Het eerste standardisation agreement “STANAG 4774 – Confidentiality Metadata Label Syntax” [1] is een XML-schema dat gebruikt kan worden om een vertrouwelijkheidslabel weer te geven en om machtigingen van de entity’s te beschrijven. Het voorziet formaten en een gemeenschappelijke XML-gebaseerde syntaxis voor veiligheidspolicy’s en vertrouwelijkheidsmetadata. Het kan toegepast worden tussen entity’s die bestuurd worden door verschillende, identieke policy’s of zonder veiligheidspolicy. Om de interoperabiliteit tussen verschillende systemen te verzekeren bestaan er profielen voor verschillende objecttypes: SOAP, REST, Office Open XML, enz.

In het kader van deze standardisation agreement werd de syntaxis van de vertrouwelijkheidslabels ontworpen om gebruikt te worden zodat een of meerdere elementen van metadata bepaald kunnen worden aangezien deze elementen op hun beurt verbonden worden aan de data-objecten. De vertrouwelijkheidslabels kunnen drie soorten metadata specificeren:

• vertrouwelijkheidslabel door de auteur toegekend aan de informatie.
• vertrouwelijkheidslabel in een verschillende policy die vergelijkbaar is met het vertrouwelijkheidslabel van de auteur.
• vertrouwelijkheidslabel verbonden aan de beschrijvende metadata van het beveiligde object.

Het tweede standardisation agreement “STANAG 4778 – Metadata Binding Mechanism” [2] is een XML-schema dat gebruikt kan worden om willekeurige metadata (ook metadata die de syntaxis van het vertrouwelijkheidslabel gebruiken) te verbinden aan de data-objecten tijdens hun levenscyclus en doorheen verschillende organisaties. De link tussen de metadata en het object zorgt er bijvoorbeeld voor dat de oorsprong van de gegevens bewezen, hun integriteit en authenticiteit gecontroleerd, hun vertrouwelijkheid en informatiebescherming verzekerd, een controleketen opgezet en informatiedeling vergemakkelijkt kan worden. Deze manier van veiligheidsdata en -metadata met elkaar te verbinden doet denken aan de methoden voor het beheer van digitale beperkingen die gebruikt worden om onder andere digitale auteursrechtelijke werken te beschermen.

De STANAG-norm 4778 laat verschillende aanpakken toe:

• Losse verbinding: de metadata worden opgeslagen in een aparte structuur van het data-object, en de twee worden aan elkaar gekoppeld via een referentie.
• Integration: de verbinding wordt geïntegreerd in het data-object en de verbinding bevat een referentie naar het data-object.
• Encapsulation: het data-object en de metadata worden ingekapseld in de verbinding en weergegeven door een nieuw samengesteld data-object.

Aangezien een data-object samengesteld kan zijn (bv.: een document met meerdere hoofdstukken en paragrafen) en elk subelement zijn eigen metadata kan hebben, geeft de STANAG-norm 4778 na te leven regels om de metadata van een samengesteld object goed te interpreteren.

De norm definieert tot slot de syntaxis en de semantiek van het verbindingsmechanisme tussen metadata en data-objecten. Verbindingsprofielen beschrijven hoe het verbindingsmechanisme van de metadata toegepast moet worden op gegevensformaten en specifieke protocollen (bv.: Microsoft Word-documenten, JPEG-afbeeldingen), maar de norm laat niet toe datastromen zoals video’s en audiostreams te verwerken.

Merk tot slot op dat de verbinding bepaald door de norm niet sterk is en dat er een digitale handtekening toegevoegd moet worden die de data-objecten en metadata dekt, bijvoorbeeld door de W3C-aanbeveling “XML Signature Syntax and Processing te gebruiken”.

Conclusies

De toepassing van vertrouwelijkheidslabels zoals die bepaald worden in de STANAG-normen 4474 en 4778 is een belangrijk element bij de invoering van een datagecentraliseerde veiligheidsstrategie. Het gebruik van deze labels in een attribuut-gebaseerd toegangscontrolesysteem (bv.: die XACML-policy’s gebruiken) biedt een dynamische en contextuele toegangscontrole waardoor organisaties een uiterst flexibele en efficiënte naleving van de reglementering kunnen bekomen.

Er bestaan veel overwegingen wat betreft de invoering van dergelijke systemen en in het bijzonder de evaluatie van de gevoeligheid van de gegevens waar de labeling van afhangt. Daar komen we op terug in een volgend artikel.

Bibliografische referenties

[1]        Confidentiality metadata label syntax, NATO standard ADat-4774, Edition A Version 1, NATO Standardisation Office (NSO), 20 december 2017.

[2]        Metadata binding mechanism, NATO standard ADatP-4778, Edition A Version 1, NATO Standardisation Office (NSO), 26 oktober 2018.

Noten

¹   Een model ontwikkeld in de jaren 70 om het meerlagig veiligheidsbeleid te formaliseren van de defensieafdeling van de Verenigde Staten. Het model wordt gekenmerkt door het aforisme “naar boven schrijven, naar beneden lezen” (het omgekeerde is verboden).

²   De kenmerken zijn paren van het type (sleutel, waarde) die gelinkt kunnen worden aan eender welke entiteit: data-object, gebruiker, omgeving, enz.

Dit is een ingezonden bijdrage van Fabien A. P. Petitcolas, IT-beveiligingsspecialist bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Parmi les causes de violations de données et d’incidents de sécurité on trouve le partage accidentel ou la mauvaise manipulation d’informations sensibles par un employé ou un sous-traitant, ou le vol délibéré de données par un initié malveillant à des fins personnelles. Malheureusement beaucoup de méthodes et d’approches habituelles ne sont pas conçues pour se protéger de telles violations par des utilisateurs a priori de confiance et les techniques les plus efficaces sont encore réservées à des secteurs très spécifiques.

Le problème n’est pourtant pas nouveau. Il est en fait bien connu dans certains domaines critiques comme la sécurité d’un pays. Dès les années 1970, le modèle de Bell-LaPadula¹ inspirait la compartimentalisation des systèmes informatiques en domaines de sécurité isolés. Par exemple une organisation peut mettre en œuvre des systèmes séparés physiquement : l’un, connecté à Internet, pour les informations sans niveau de confidentialité particulier et un pour chacun des niveaux de confidentialité de l’organisation comme par exemple « restreint, » « confidentiel, » ou « secret. » À cela sont souvent ajoutés des mécanismes classiques comme l’utilisation de systèmes de fichiers chiffrés, le blocage – voire le retrait – de ports USB, la restriction des fonctionnalités de copier/coller dans les logiciels, mais aussi l’inspection de toutes les données circulant sur le réseau informatique afin de détecter la présence éventuelle de données sensibles ou confidentielles.

Afin de transférer des informations d’un niveau à un autre cette organisation peut avoir recours à des passerelles informatiques spécialisées dans la protection des données. Celles-ci supposent que chaque donnée, ainsi que l’utilisateur ou le service du domaine envoyant ces données, sont d’abord liés à une étiquette de confidentialité permettant de décider si les données peuvent être transmises ou pas. En d’autres termes, la protection de l’information se fait au niveau des objets de données eux-mêmes plutôt qu’au niveau des domaines créés avec des réseaux informatiques séparés (parfois imperméables et conduisant à des processus de chaises tournantes).

Étiquettes de confidentialité

Les étiquettes de confidentialité sont des moyens d’associer différents attributs² de sécurité à un objet particulier. Ces étiquettes de confidentialité peuvent contenir n’importe quelles informations utiles pour prendre des décisions de sécurité et sont a priori considérées comme correctes lorsqu’une décision de sécurité se base dessus. Il existe deux manières principales d’assigner une étiquette de confidentialité à un objet de données :

• Baser les propriétés de sécurité sur l’origine de l’information présente dans l’objet de données. C’est la méthode la plus simple, pour autant que l’origine de l’information puisse être tracée.
• Évaluer le contenu même de l’objet de données afin de déterminer les attributs de sécurité. Nous verrons dans un prochain article comment cette assignation peut être faite de manière plus ou moins automatique.

L’utilisation d’étiquettes de confidentialité présente différentes limites. Lors de l’interconnexion de deux systèmes de niveaux de sécurité différents, il faut tenir compte du risque de mauvais étiquetage des objets (p. ex., erreur de l’utilisateur, détournement ou compromission du système, etc.). De plus :

• Une étiquette de confidentialité reflète les exigences de protection et les conditions de libération d’un objet au moment de la création de cette étiquette. La mise à jour de cette dernière requiert des opérations manuelles qui doivent suivre des processus de gestion stricts.
• L’étiquetage ne voyage pas toujours correctement avec les objets, même au sein de la même organisation.
• En raison d’interprétations subjectives de la politique de sécurité, les auteurs des objets peuvent apposer des étiquettes de confidentialité différentes pour des objets au contenu similaire. Cela peut conduire à des situations où des données très similaires peuvent avoir des niveaux de protection différents.

L’étiquetage de l’information introduit donc au moins deux défis importants. Le premier concerne l’existence d’une syntaxe et d’une interprétation commune des étiquettes – c’est à dire entre les systèmes souhaitant échanger des informations. L’autre est la définition d’un mécanisme permettant de lier ces étiquettes aux objets tout en assurant l’intégrité de ce lien.

Mécanisme standardisé

En 2010, le groupe de recherche sur les solutions de sécurité inter-domaines de l’Organisation pour la science et la technologie de l’OTAN a publié une proposition de spécification XML pour l’étiquetage et la liaison des métadonnées. Ce travail a ensuite été développé dans deux accords de normalisation (« standardisation agreement » ou « STANAG »).

Le premier accord de normalisation, le « STANAG 4774 – Confidentiality Metadata Label Syntax » [1] est un schéma XML qui peut être utilisé pour représenter une étiquette de confidentialité ainsi que pour décrire les habilitations des entités. Il fournit des formats et une syntaxe commune basée sur le langage XML pour les politiques de sécurité et les métadonnées de confidentialité. Il peut s’appliquer entre des entités gouvernées par des politiques différentes, identiques, ou sans politique de sécurité. Afin d’assurer l’interopérabilité entre différents systèmes, des profils existent pour différents types d’objets : SOAP, REST, Office Open XML, etc.

Dans le cadre de cet accord de normalisation, la syntaxe des étiquettes de confidentialité a été conçue pour être utilisée afin de définir un ou plusieurs éléments de métadonnées, ces éléments de métadonnées étant à leur tour liés à des objets de données. Les étiquettes de confidentialité peuvent spécifier trois types de métadonnées :

• étiquette de confidentialité attribuée à l’information par l’auteur.
• étiquette de confidentialité dans une politique différente qui est équivalente à l’étiquette de confidentialité de l’auteur.
• étiquette de confidentialité associée aux métadonnées descriptives de l’objet protégé.

Le deuxième accord de normalisation, le « STANAG 4778 – Metadata Binding Mechanism » [2] est un schéma XML qui peut être utilisé pour lier des métadonnées arbitraires (y compris des métadonnées qui utilisent la syntaxe de l’étiquette de confidentialité) à des objets de données, au cours de la vie de ceux-ci et à travers différentes organisations. Le lien entre les métadonnées et l’objet permet par exemple de prouver l’origine des informations, de vérifier leur intégrité et authenticité, d’assurer la confidentialité et la protection de l’information, de mettre en place une chaîne de contrôle, et de faciliter le partage de l’information. Cette façon de lier données et métadonnées de sécurité n’est pas sans rappeler les méthodes de gestion numérique des restrictions utilisées pour protéger notamment les œuvres numérisées bénéficiant d’un droit d’auteur.

La norme STANAG 4778 autorise différentes approches :

• Liaison détachée : les métadonnées sont stockées dans une structure distincte de l’objet de données, et les deux sont liés par référence.
• Intégration : la liaison est intégrée dans l’objet de données et la liaison contient une référence à l’objet de données.
• Encapsulation : l’objet de données et les métadonnées sont encapsulés dans la liaison et représentés par un nouvel objet de données composite.

Puisqu’un objet de données peut être composite (p. ex., un document avec plusieurs chapitres et paragraphes), et que chaque sous-élément peut avoir ses propres métadonnées, la norme STANAG 4778 donne les règles à respecter afin de bien interpréter les métadonnées d’un objet composite.

Enfin la norme définit la syntaxe et la sémantique du mécanisme de liaison entre métadonnées et objets de données. Des profils de liaison décrivent comment appliquer le mécanisme de liaison des métadonnées à des formats de données et à des protocoles spécifiques (p. ex., documents Microsoft Word, images JPEG), mais la norme ne permet pas de traiter les flux de données comme les vidéos et les transmissions sonores.

Notons enfin que la liaison définie par la norme n’est pas forte et il faut ajouter une signature numérique couvrant l’objets de données et les métadonnées, par exemple en utilisant la recommandation du W3C « XML Signature Syntax and Processing. »

Conclusions

L’application d’étiquettes de confidentialité comme, par exemple, celles définies dans les normes STANAG 4474 et 4778 est un élément important de la mise en œuvre d’une stratégie de sécurité centrée sur les données. L’utilisation de ces étiquettes dans un système de contrôle d’accès basé sur les attributs (par ex. utilisant des politiques XACML) offre un contrôle d’accès dynamique et contextuel, permettant aux organisations d’atteindre avec une grande flexibilité, une conformité réglementaire efficace.

Il existe de nombreuses considérations liées à la mise en œuvre de tels systèmes et notamment l’évaluation de la sensibilité des informations dont dépend l’étiquetage. Cela sera l’objet d’un prochain article.

Références

[1]        Confidentiality metadata label syntax, NATO standard ADat-4774, Edition A Version 1, NATO Standardisation Office (NSO), 20 décembre 2017.

[2]        Metadata binding mechanism, NATO standard ADatP-4778, Edition A Version 1, NATO Standardisation Office (NSO), 26 octobre 2018.

Notes

¹   Un modèle développé dans les années 1970 afin de formaliser la politique de sécurité multi-niveau du département de la défense des États-Unis. Le modèle est caractérisé par l’aphorisme « écrire vers le haut, lire vers le bas » (l’inverse étant interdit).

²   Les attributs sont des paires de type (nom, valeur) qui peuvent être associées à n’importe quelle entité : objet de données, utilisateur, environnement, etc.

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

La cryptographie est la science qui applique des principes mathématiques en vue de sécuriser les données. Elle est indispensable dans notre société actuelle. Il suffit de penser aux communications sécurisées et à la signature électronique de toutes sortes de documents. Les algorithmes cryptographiques qui étaient autrefois considérés comme extrêmement sûrs sont aujourd’hui totalement inadaptés. Il faudra un jour, par exemple avec l’avènement probable de puissants ordinateurs quantiques, s’affranchir progressivement ou très rapidement des méthodes cryptographiques qui sont la norme aujourd’hui. Cet article examine les préparatifs que nous pouvons faire à cette fin.

La cryptographie sécurisée devient douteuse

Les mécanismes cryptographiques peuvent se dégrader pour diverses raisons, telles que l’augmentation de la puissance des ordinateurs, les percées dans le domaine de la cryptanalyse et – c’est ce qui nous préoccupe le plus aujourd’hui – la capacité de construire de puissants ordinateurs quantiques. 

Puissance de calcul

Une première raison est l’augmentation de la puissance de calcul disponible sur les ordinateurs classiques. En 1977, le DES (Data Encryption Standard) a été normalisé. Le DES offrait une sécurité de 56 bits, ce qui signifie qu’un attaquant devait rechercher la clé dans un espace de recherche de 2⁵⁶ (72 millions de milliards) possibilités. Actuellement, en raison notamment de l’augmentation exponentielle de la puissance de calcul disponible, et conformément à la loi de Moore, une sécurité minimale de 128 bits est exigée.  

Aujourd’hui, RSA-2048 est encore couramment utilisé pour l’authentification, l’échange de clés et les signatures électroniques, entre autres. Il figure encore aujourd’hui sur certaines cartes d’identité électroniques actives en Belgique. Avec la sécurité de 112 bits qu’il offre, il n’est pas immédiatement insécurisé, mais il est préférable de procéder à sa suppression progressive. Quoi qu’il en soit, il est vivement déconseillé de l’adopter dans de nouveaux systèmes.

Cryptanalyse

Les percées dans le domaine de la cryptanalyse constituent une deuxième raison pour laquelle les mécanismes cryptographiques peuvent perdre de leur sécurité. La cryptanalyse est l’art de trouver les faiblesses des méthodes cryptographiques. Pendant la Seconde Guerre mondiale, il a été crucial de déchiffrer Enigma, qui permettait auparavant au commandement nazi de communiquer en toute sécurité avec ses sous-marins. La cryptanalyse différentielle a également permis de réduire la sécurité du DES de 56 à 47 bits. Plus récemment, la cryptanalyse continue de jouer un rôle important. En 2008, par exemple, on est parvenu à générer un faux certificat TLS, parce que la fonction de hachage cryptographique sous-jacente, MD5, était devenue peu sûre à la suite de percées dans le domaine de la cryptanalyse.

Ordinateurs quantiques cryptographiquement pertinents

La menace d’ordinateurs quantiques devenant plus puissants d’année en année constitue une troisième menace, qui pourrait éventuellement rendre toute la cryptographie moderne à clé publique dangereuse.  Les signatures numériques, l’authentification par clé publique, les connexions TLS, etc. deviendraient alors totalement incertaines. Ces machines sont généralement appelées ordinateurs quantiques cryptographiquement pertinents.

Personne ne sait vraiment quand (ni même si) il sera possible de construire de tels ordinateurs quantiques. Même les experts ont des avis fortement divergents, comme le montre l’illustration ci-dessous, où 46 experts ont été interrogés en 2021. La moitié d’entre eux estimaient qu’il y avait au moins 50 % de chances qu’un tel ordinateur quantique soit construit d’ici 15 ans, c’est-à-dire d’ici 2036.

Cela ne veut cependant pas dire que nous pouvons attendre encore une dizaine d’années. Après tout, un attaquant peut aujourd’hui intercepter et stocker des communications chiffrées. Plusieurs années plus tard, si cet attaquant a accès à un ordinateur quantique pertinent sur le plan cryptographique, il pourrait toujours déchiffrer les données, qui pourraient encore être sensibles. C’est ce qu’on appelle l’attaque harvest now decrypt later.

Le BSI, l’agence allemande de cybersécurité, recommande de partir du principe que des ordinateurs quantiques pertinents sur le plan cryptographique seront disponibles au début de la prochaine décennie et d’en tenir compte dès aujourd’hui dans l’évaluation des risques. Il ne s’agit donc pas d’une prédiction, mais d’une ligne directrice prudente pour l’évaluation des risques.

Nouvelles normes et confiance

Il existe donc un risque important que des ordinateurs quantiques pertinents sur le plan cryptographique soient construits dans un avenir pas si lointain. Heureusement, le NIST (National Institute for Standards and Technologies) mène depuis 2016 une procédure de normalisation de la cryptographie post-quantique (PQC). Elle se compose de deux parties :

• L’encapsulation de clé (KEM) permet à deux parties de se mettre d’accord sur une clé partagée qui chiffre les données à échanger.
• Les signatures numériques permettent entre autres de signer des documents de manière électronique et d’authentifier les parties.

En août 2024, le NIST a publié les premières normes :

• ML-KEM, basé sur CRYSTALS-KYBER, est la première norme à résistance quantique pour l’encapsulation de clés.
• ML-DSA, basée sur CRYSTALS-Dilithium et SLH-DSA, basée sur Sphincs+, sont les deux premières normes de signatures numériques résistantes aux attaques quantiques. Une troisième norme est encore en cours d’élaboration. La future norme FN-DSA, basée sur Falcon, sera publiée dans les prochains mois. 

Dans un article précédent, j’ai donné une idée, entre autres, des performances auxquelles on peut s’attendre, ainsi que de la taille des clés et des signatures numériques.

Aux États-Unis, il existe déjà un solide engagement en faveur de ces nouvelles normes, comme en témoigne le Quantum Computing Cybersercurity Preparedness Act, signé en décembre 2022 par le président Biden. Il stipule qu’endéans les six mois, les agences fédérales doivent développer une stratégie pour leur migration vers une cryptographie résistante au quantum.

En Europe, nous sommes un peu plus prudents. La principale agence de cybersécurité en Allemagne, la BSI, déclare :

The quantum-safe algorithms that are currently being standardized are not yet as well researched as the “classical” methods (for example RSA and ECC). This applies in particular to weaknesses that largely only become apparent in applications, such as typical implementation errors, possible side-channel attacks, etc. BSI therefore recommends that post-quantum cryptography should not be used in isolation if possible, but only in hybrid mode, i.e. in combination with classical algorithms.

C’est un raisonnement valide. Fin 2016, le NIST a lancé, comme mentionné plus haut, une procédure de normalisation pour une cryptographie à clé publique résistante au quantum de nouvelle génération. En novembre 2017, 82 algorithmes candidats ont été soumis. SIKE était un des huit algorithmes candidats figurant parmi les finalistes. En 2022 – donc cinq ans plus tard – le groupe de recherche COSIC de la KU Leuven a découvert une faiblesse fondamentale, ce qui fait que le chiffrement à l’aide de SIKE pourrait être cassé en quelques minutes sur un ordinateur classique. Cette faiblesse est passée sous le radar de la communauté globale de cryptanalyse. Nous souhaitons éviter le scénario d’un changement massif vers un nouveau mécanisme cryptographique, qui ne s’avère pas aussi sûr que ce que l’on pensait. De plus, les implémentations encore jeunes de ces algorithmes peuvent contenir des vulnérabilités.

Il faudra donc un certain temps pour développer une confiance suffisante dans les nouvelles normes et leur mise en œuvre.

Mode hybride

Le BSI propose donc de travailler dans un premier temps en mode hybride, ce qui signifie que la cryptographie classique à clé publique soit utilisée en tandem avec une cryptographie résistante aux attaques quantiques. Lorsqu’un des deux algorithmes est jugé dangereux, il n’y a pas de problème tant que l’autre algorithme est sûr. Cette manière de travailler offre donc une double couche de protection.

Examinons concrètement comment cela fonctionne. Afin d’établir un canal de communication sécurisé, deux parties doivent convenir d’une clé partagée. Il s’agit d’une des étapes du protocole TLS. Aujourd’hui, la méthode Diffie-Hellman key exchange est souvent utilisée, où X25519 représente une instanciation concrète basée sur la courbe elliptique Curve25519 Diffie-Hellman n’est malheureusement pas capable de faire face aux ordinateurs quantiques cryptographiquement pertinents. La nouvelle norme ML-KEM, basée sur CRYSTALS-KYBER, est supposée l’être. Dans l’illustration ci-dessous, le client et le serveur se mettent d’accord sur deux clés partagées en parallèle, la clé orange est définie avec X25519, la verte avec CRYSTALS-KYBER. Ces deux clés sont ensuite combinées en une clé unique, qui est ensuite utilisée pour crypter et décrypter les données échangées.

Gouvernance cryptographique

Il existe divers mécanismes cryptographiques qui étaient autrefois populaires, mais qui ne sont pas sûrs aujourd’hui. DES, 3DES, MD5 et SHA1 en sont des exemples. Une migration de l’ancienne vers une nouvelle cryptographie est donc un fait dont nous devons tenir compte. De plus, l’histoire a démontré que les migrations cryptographiques complètes, telles que celle de 3DES vers AES, peuvent traîner pendant jusqu’à dix ans et nécessiter beaucoup de ressources. Une migration cryptographique est donc un processus difficile et délicat.

Un mode hybride entraîne en outre immédiatement deux migrations futures. La première consiste à passer de la cryptographie à clé publique actuelle au mode hybride. Une fois qu’une confiance suffisante a été développée dans les nouvelles normes et leurs implémentations, l’on migre vers une cryptographie entièrement résistante aux attaques quantiques.

Une gouvernance cryptographique saine nous aide à repérer les domaines dans lesquels les migrations sont les plus urgentes, ainsi qu’à effectuer la migration elle-même. La gouvernance cryptographique permet à une organisation de comprendre où et comment la cryptographie est utilisée et de mettre en œuvre et de surveiller les changements tels que les migrations. Elle se compose, entre autres, des pièces de puzzle ci-dessous :

• L’inventaire cryptographique offre une vue d’ensemble des mécanismes cryptographiques utilisés, avec quels paramètres (par exemple, la longueur des clés), dans quel but (par exemple, la protection des données en transit), où et afin de protéger quelles données (par exemple, les données médicales personnelles).
• Les recommandations cryptographiques concrètes ; quels algorithmes et paramètres cryptographiques (par exemple la longueur des clés) sont sûrs, lesquels devraient être progressivement abandonnés, lesquels ne sont pas sûrs, … De telles recommandations sont déjà présentes au sein de Smals et ont vu le jour grâce à Smals Research. Compte tenu de la menace que représentent les puissants ordinateurs quantiques, il est probable que la cryptographie classique à clé publique recommandée aujourd’hui devra être progressivement abandonnée dans un avenir pas si lointain.
• Documentation des exceptions. Des exceptions temporaires aux recommandations en matière de cryptographie peuvent être tolérées afin d’éviter que la communication avec des systèmes externes (par exemple des clients ou des prestataires de services) ne soit de facto impossible. Ces exceptions doivent être documentées ; le risque doit être décrit, ainsi que la portée, la fenêtre temporelle et son acceptation par la direction.
• Les recommendations de crypto-agilité doivent aider les équipes de projet à construire et à personnaliser les applications et les services selon les principes de crypto-agilité. Cela signifie que les futures migrations cryptographiques doivent être prises en compte.
• Une politique cryptographique est nécessaire pour éviter que les recommandations cryptographiques ne soient interprétées comme des suggestions sans valeur obligatoire, ce qui leur donnerait un caractère contraignant. En effet, la politique cryptographique de Smals fait référence à nos recommandations. Une politique cryptographique conduit à une simplification (uniformisation) du paysage cryptographique au sein de l’organisation. Elle peut guider la migration vers des normes résistantes aux attaques quantiques et encourager la création d’applications et de services d’une manière crypto-agile.
• Surveillance cryptographique. En observant le trafic réseau, nous percevons quels mécanismes cryptographiques sont utilisés et à quel endroit, ce qui peut aider à guider les migrations. Un tel monitoring ne nécessite heureusement pas l’accès aux données en transit.  

Smals Research a l’intention au cours de la période à venir de dresser un tableau plus précis de l’inventaire cryptographique et de la crypto-agilité en particulier. En effet, les principes de la crypto-agilité et l’idée de l’inventaire cryptographique existent aujourd’hui, mais l’élaboration concrète fait malheureusement encore défaut, non seulement chez Smals, mais dans le monde entier. D’une manière générale, nous avons donc encore du pain sur la planche.

Inventaire cryptographique

Un inventaire cryptographique peut fournir une vue d’ensemble, entre autres, des éléments suivants

• les mécanismes cryptographiques utilisés. Par exemple, ECDSA pour établir des signatures numériques ou AES pour le chiffrement en bulk.
• les paramètres utilisés dans le processus. Par exemple, l’ECDSA peut utiliser la courbe elliptique P-256 et l’AES peut être déployé en mode GCM avec des clés d’une longueur de 256 bits.
• les librairies ou services cryptographiques utilisés dans le processus. BouncyCastle 1.78 et OpenSSL 3.0 sont des exemples de librairies. Les exemples de services sont le service de pseudonymisation aveugle d’eHealth et AWS CloudHSM. 
• Quelles données sont protégées et dans quel but. Par exemple, l’intégrité et la confidentialité des données médicales au repos.
• L’endroit où la cryptographie est utilisée dans le code. Dans la classe AbcSigner, de la ligne 254 à la ligne 269.

En résumé, l’inventaire cryptographique nous permet de localiser rapidement les faiblesses ou les faiblesses potentielles et, par conséquent, les endroits où des mises à jour ou des migrations sont nécessaires.

L’inventaire n’est pas un exercice ponctuel, mais doit toujours être mis à jour. Des outils de découverte, tels que CipherInsights, IBM Quantum Safe Explorer, AgileSec Analytics et QryptoDiscover, entre autres, peuvent nous aider à le construire et à le tenir à jour. 

Un tel inventaire peut contenir de nombreux détails et devenir très complexe, en particulier pour les grandes organisations. La compilation et l’actualisation de cet inventaire risquent donc de devenir une opération très gourmande en ressources. Une organisation utilise par ailleurs, entre autres, des librairies cryptographiques, des services cryptographiques, du hardware de tiers, etc. Il est donc nécessaire de disposer d’un moyen structuré et normalisé d’exprimer un inventaire cryptographique qui facilite l’automatisation et l’intégration. C’est ce à quoi travaille IBM avec son CBOM (Cryptography Bill of Materials). Nous espérons que cette proposition sera adoptée rapidement.

Un inventaire cryptographique offrirait un certain nombre d’avantages en plus de la migration vers la cryptographie à résistance quantique :

Securité & résilience

Le risque cryptographique est la possibilité de dommages à l’organisation lorsque la cryptographie ne fait pas ce qu’elle est censée faire, notamment par l’utilisation de mécanismes cryptographiques obsolètes ou de paramètres non sécurisés, par une mauvaise gestion des clés et des certificats ou par des vulnérabilités dans les implémentations des algorithmes cryptographiques. Dans le OWASP top 10, un document de sensibilisation destiné aux développeurs et conernant la sécurité des applications web, les ‘cryptographic failures’ arrivent en deuxième position. En guise d’exemple, nous comptons les $150M+ Capital One hack comme la violation des données personnelles de millions d’utilisateurs à la suite d’un problème de gestion des clés, et le $200M+ Marriott Hotel hack, où une utilisation incomplète du cryptage a rendu publics des millions de numéros de passeports. L’inventaire cryptographique, éventuellement complété par une surveillance cryptographique, rend les risques cryptographiques transparents et contribue ainsi à prévenir de tels incidents. La crypto-agilité, à son tour, devrait nous permettre de migrer rapidement vers une cryptographie sécurisée.

Conformité

En partie à cause de ces incidents, les auditeurs se contentent de moins en moins d’informations superficielles sur l’utilisation de la cryptographie. Un inventaire cryptographique, éventuellement complété par des logs de surveillance cryptographique, leur permet d’accéder facilement à tous les détails concernant l’utilisation de la cryptographie au sein de l’organisation.

Il est donc logique que la possession et la tenue d’un inventaire cryptographique soient de plus en plus recommandées, voire imposées. Dans la publication conjointe de la NSA, du NIST et de la CISA Quantum Readiness :Migration To Post-quantum Cryptography, on peut lire, par exemple :

 “Organizations should create a cryptographic inventory that offers visibility into how the organization leverages cryptography in its IT (Information Technology) and OT (Operational Technology) systems. “

C’est surtout lorsque l’inventaire cryptographique peut être accompagné de recommandations cryptographiques détaillées que la compliance devient intéressante. Ces dernières, comme nous l’avons déjà mentionné, sont déjà présentes chez Smals grâce à Smals Research.

Crypto-agilité

Un inventaire cryptographique est une étape nécessaire vers l’agilité cryptographique, ou crypto-agilité en abrégé. Elle consiste à remplacer et à adapter les mécanismes cryptographiques, qu’il s’agisse de software, de hardware ou d’infrastructure, sans interrompre le bon fonctionnement du système lui-même. Ainsi, les anciens mécanismes cryptographiques peuvent être éliminés progressivement et de nouveaux mécanismes peuvent être adoptés.

En dépit de la difficulté à définir l’agilité cryptographique, la définition ci-dessous, qui se compose de trois aspects, semble assez précise.

• La capacité des systèmes à se mettre d’accord en temps réel sur leurs algorithmes de sécurité en se basant sur leurs fonctions de sécurité combinées (c’est-à-dire le matériel, les logiciels et les microprogrammes utilisés pour assurer la sécurité d’un système) ;
• La capacité d’ajouter de nouvelles fonctions cryptographiques ou de nouveaux algorithmes au matériel ou aux logiciels existants, ce qui permet d’obtenir de nouvelles fonctions de sécurité plus robustes ;
• la capacité de désactiver élégamment les systèmes cryptographiques devenus vulnérables ou obsolètes.

Un prochain article sera consacré à la manière de mettre en pratique l’agilité cryptographique plus concrètement et aux défis qui en découlent. En attendant, le protocole TLS peut nous inspirer. TLS est un protocole cryptographique conçu pour permettre une communication sécurisée entre deux parties sur un réseau informatique. Les deux parties conviennent entre elles des mécanismes cryptographiques qu’elles souhaitent utiliser pour l’authentification, l’échange de clés, le cryptage et le hachage. Chaque partie ne prend en charge que les mécanismes qu’elle juge sûrs. Ceci est décrit dans un fichier de configuration, qui nous permet d’ajouter de nouveaux mécanismes cryptographiques et de supprimer progressivement les anciens sans affecter le fonctionnement de l’application mère.

Conclusion

Les ordinateurs quantiques sont qualifiés de cryptographiquement pertinents lorsqu’ils sont en mesure de casser la cryptographie moderne à clé publique. Actuellement, nous en sommes encore loin et les incertitudes sont nombreuses. Nous ne savons même pas si l’humanité sera un jour capable de construire de telles machines. Néanmoins, il est sage de faire preuve de prudence et de se préparer à cette éventualité.

La menace que représentent actuellement les ordinateurs quantiques et la publication des nouvelles normes cryptographiques résistantes à la quantification sont donc une bonne raison de nous poser une question plus générale : comment pouvons-nous rendre notre gouvernance cryptographique plus naturelle, de manière à ce que

1. nous puissions mieux comprendre quelle cryptographie est utilisée au sein de l’organisation, et
2. nous soyons en mesure d’effectuer une migration relativement aisée si cela s’avère nécessaire.

Cela vaut indépendamment de la menace que représentent les puissants ordinateurs quantiques.

Smals effectue déjà ces préparatifs aujourd’hui. Nous disposons déjà de recommandations et d’une politique en matière de cryptographie. Toutefois, il reste encore beaucoup à faire, notamment en ce qui concerne l’inventaire cryptographique et l’adoption de la crypto-agilité. Ce sont des éléments sur lesquels Smals Research travaillera au cours de la période à venir.

Il y a encore beaucoup de questions et d’incertitudes aujourd’hui, qui ne doivent pas nous empêcher d’agir dès à présent. Nous pensons d’ailleurs que la publication des nouvelles normes du NIST accélérera les choses.

En résumé et en guise de conclusion, je citerai le Dr. Schabhüser, vice-président de la BSI allemande :

« Si je pouvais donner trois conseils aux entreprises et aux organisations, ce serait :

• Intégrez le risque cryptogrqphique  dans votre système de gestion de risque
• Créez un inventaire cryptographique
• Implémentez et utiliser la crypto-agilité »

N’hésitez pas à nous contacter pour davantage d’informations ou une éventuelle collaboration.

Cette contribution a été soumise par Kristof Verslype, cryptographe chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

Cryptografie is de wetenschap die wiskundige principes toepast om gegevens te beveiligen. Het is onmisbaar in onze huidige samenleving. Denk maar aan veilige communicatie en het elektronisch ondertekenen van allerlei documenten. Cryptografische algoritmes die ooit als extreem veilig beschouwd werden, zijn vandaag volstrekt onvoldoende. Ooit zullen we – bijvoorbeeld door de komst van krachtige kwantumcomputers – geleidelijk of erg snel moeten migreren, weg van cryptografische methodes die vandaag de norm zijn. Dit artikel gaat in op de voorbereidingen die we daartoe kunnen treffen.

Veilige cryptografie wordt onveilig

Cryptografische mechanismes kunnen aan veiligheid inboeten omwille van diverse redenen, gaande van toegenomen computerkracht, doorbraken in cryptoanalyse en – dit is waar we ons vandaag het meeste zorgen over maken – de mogelijkheid om krachtige kwantumcomputers te bouwen. 

Rekenkracht

Een eerste reden is de toename aan beschikbare rekenkracht op klassieke computers. In 1977 werd DES (Date Encryption Standard) gestandaardiseerd. DES bood een veiligheid van 56 bit, wat wil zeggen dat een aanvaller op zoek gaat naar de sleutel in een zoekruimte met 2⁵⁶  (72 miljoen miljard) mogelijkheden. Onder meer door de exponentiële toename van de beschikbare rekenkracht, is vandaag, overeenkomstig de wet van Moore, minimum 128 bit security vereist.  

Vandaag wordt RSA-2048 nog vaak gebruikt voor onder meer authenticatie, sleuteluitwisseling en elektronische handtekeningen. Het is vandaag nog steeds op een deel van de actieve Belgische elektronische identiteitskaarten aanwezig. Met de 112 bit security die het biedt is het niet meteen onveilig, maar wordt het wel best uitgefaseerd. Sowieso is het geen goed idee om het in nieuwe systemen te adopteren.

Cryptoanalyse

Een tweede reden dat cryptografische mechanismes aan veiligheid kunnen inboeten zijn doorbraken in cryptoanalyse. Cryptoanalyse is de kunst om zwakheden te vinden in cryptografische methodes. Het was cruciaal in de 2^e wereldoorlog om Enigma te kraken, wat het Nazi commando voorheen toeliet veilig met hun duikboten te communiceren. Met behulp van differential cryptanalysis kon ook de veiligheid van DES gereduceerd worden van 56 naar 47 bits. Ook recenter blijft cryptoanalyse een rol spelen. In 2008, bijvoorbeeld slaagde men erin een vals TLS certificaat te genereren doordat de onderliggende cryptografische hashfunctie, MD5, onveilig geworden was door cryptoanalytische doorbraken.

Cryptografisch Relevante Kwantumcomputers

Ten derde is er de dreiging van kwantumcomputers die jaar na jaar krachtiger worden en op termijn alle moderne publieke sleutelcryptografie onveilig kunnen maken.  Dit zou resulteren in een situatie waarbij digitale handtekeningen, publieke-sleutel authenticatie, TLS verbindingen, etc. allen volstrekt onveilig worden. Men refereert doorgaans naar zo’n machines als cryptografisch relevante kwantumcomputers.

Niemand weet echt wanneer (en of) men in staat zal zijn dergelijke kwantumcomputers te bouwen. Zelfs de meningen onder experten zijn sterk verdeeld, zoals te zien is op onderstaande figuur, waarbij in 2021 46 experten geïnterviewd werden. Wel was de helft van de experten van oordeel dat er een kans was van minstens 50% dat er binnen 15 jaar – dus tegen 2036 – zo’n kwantumcomputer gebouwd zal worden.

Dit wil overigens niet zeggen dat we nog een kleine tien jaar kunnen wachten. Een aanvaller kan namelijk vandaag vercijferde communicatie onderscheppen en bewaren. Wanneer de aanvaller een aantal jaar later de beschikking heeft over een cryptografisch relevante kwantumcomputer kan hij of zij alsnog de data ontcijferen, die dan nog steeds gevoelig kan zijn. Dit wordt de harvest now decrypt later aanval genoemd.

Het BSI, het Duitse cybersecurityagentschap raadt aan om ervan uit te gaan dat cryptografisch relevante kwantumcomputers beschikbaar zullen zijn tegen het begin van het volgend decennium en om dit vandaag reeds mee te nemen in risicobeoordelingen. Dit is dus geen voorspelling, maar een conservatieve richtlijn voor risicobeoordeling.

Nieuwe standaarden en vertrouwen

Et is dus een aanzienlijk risico dat in de niet zo heel verre toekomst cryptografisch relevante kwantumcomuters gebouwd zullen worden. Gelukkig loopt er bij het NIST (National Institute for Standards and Technologies) sinds 2016 een procedure om post-quantum cryptografie (PQC) te standaardiseren. Het bestaat uit twee luiken:

• Key encapsulation laat twee partijen toe om een gedeelde sleutel overeen te komen waarmee de uit te wisselen data vercijferd wordt.
• Digitale handtekeningen laten onder meer toe om documenten elektronisch te ondertekenen en om partijen te authenticeren.

In augustus 2024 publiceerde het NIST de eerste standaarden:

• ML-KEM, gebaseerd op CRYSTALS-KYBER, is de eerste kwantumresistente standaard voor key encapsulation.
• ML-DSA, gebaseerd op CRYSTALS-Dilithium en SLH-DSA, gebaseerd op Sphincs+, zijn de twee eerste kwantumresistente standaarden voor digitale handtekeningen. Een derde standaard zit nog in de pijplijn. De toekomstige standaard FN-DSA, gebaseerd op Falcon, wordt in de komende maanden gepubliceerd. 

In een eerdere blogpost geef ik alvast een idee onder meer van de performantie die we kunnen verwachten, alsook van de groottes van sleutels en digitale handtekeningen.

In de Verenigde Staten zet men alvast volop in op deze nieuwe standaarden, zoals ook blijkt uit de Quantum Computing Cybersecurity Preparedness Act die in december 2022 door president Biden ondertekend werd. Daarin wordt gesteld dat federale agentschappen binnen de zes maand een strategie moeten ontwikkelen voor hun migratie naar kwantumresistente cryptografie.

In Europa is men wat voorzichter. Het BSI, het toonaangevende Duitse cybersecurityagentschap, stelt:

The quantum-safe algorithms that are currently being standardized are not yet as well researched as the “classical” methods (for example RSA and ECC). This applies in particular to weaknesses that largely only become apparent in applications, such as typical implementation errors, possible side-channel attacks, etc. BSI therefore recommends that post-quantum cryptography should not be used in isolation if possible, but only in hybrid mode, i.e. in combination with classical algorithms.

Dit is een terechte redenering. Eind 2016 startte het NIST, zoals eerder aangegeven, een standaardisatieprocedure voor een nieuwe generatie, kwantumresistente publieke sleutelcryptografie. Tegen november 2017 werden 82 kandidaat algoritmes ingestuurd. SIKE was één van de acht kandidaat algoritmes die tot de finalisten behoorden. In 2022 – dus vijf jaar later – vond de COSIC onderzoeksgroep aan de KU Leuven een fundamentele zwakte, waardoor vercijfering m.b.v. SIKE in een paar minuten op een klassieke computer gebroken kon worden. Al die jaren bleef deze zwakte onder de radar van de wereldwijde cryptoanalyse community. We willen het scenario vermijden waarbij we massaal overschakelen naar een nieuw cryptografisch mechanisme, dat dan blijkbaar toch niet zo veilig is als aangenomen. Bovendien kunnen de nog jonge implementaties van deze algoritmes kwetsbaarheden bevatten.

Het zal dus nog wat tijd kosten om voldoende vertrouwen in de nieuwe standaarden en hun implementies te ontwikkelen.

Hybride modus

Het BSI stelt dus voor om initieel in hybride modus te werken, wat wil zeggen dat klassieke publieke sleutelcryptografie in tandem gebruikt wordt met kwantumresistente cryptografie. Wanneer één van beide algoritmes onveilig blijkt te zijn, is er niets aan de hand zolang het andere algoritme nog veilig is. Het biedt dus een dubbele beschermlaag.

Laat ons even concreet bekijken hoe dit in zijn werk gaat. Om een veilig communicatiekanaal op te zetten, moeten twee partijen een gedeelde sleutel afspreken. Dit is één van de stappen in het TLS protocol. Vandaag wordt daarvoor vaak de Diffie-Hellman key exchange methode gebruikt. X25519 is daar een concrete instantiatie van, gebaseerd op de elliptische kromme Curve25519. Diffie-Hellman is helaas niet opgewassen tegen cryptografisch relevante kwantumcomputers. De nieuwe standaard ML-KEM, gebaseerd op CRYSTALS-KYBER, wordt verondersteld dit wel te zijn. In onderstaande figuur spreken de client en de server in parallel twee gedeelde sleutels af; de oranje sleutel wordt afgesproken met X25519, de groene met CRYSTALS-KYBER. Die twee sleutels worden vervolgens gecombineerd tot één sleutel, waarmee vervolgens de uitgewisselde data vercijferd en ontcijferd zal worden.

Cryptographic Governance

Er zijn verschillende cryptografische mechanismes die ooit populair waren, maar vandaag onveilig zijn. Voorbeelden zijn DES, 3DES, MD5 en SHA1. Migratie van oude naar nieuwe cryptografie is dus een gegeven waar we rekening mee moeten houden. Bovendien heeft de geschiedenis ondertussen aangetoond dat volledige cryptografische migraties, zoals die van 3DES naar AES, tien jaar kunnen aanslepen en best veel resources vergen. Een cryptografische migratie is dan ook een lastig en moeilijk traject.

Een hybride modus resulteert bovendien meteen in twee toekomstige migraties. In eerste instantie wordt gemigreerd van de huidige publieke sleutelcryptografie naar hybride modus. Eens voldoende vertrouwen ontwikkeld is in de nieuwe standaarden en hun implementaties, wordt vervolgens gemigreerd naar uitsluitend kwantumresistente cryptografie.

Een gedegen cryptographic governance helpt ons alvast bij het detecteren waar migraties het dringends zijn, alsook bij het uitvoeren van de migratie zelf. Cryptographic governance laat een organisatie toe te begrijpen waar en hoe cryptografie gebruikt wordt en om veranderingen zoals migraties uit te voeren en te monitoren. Het bestaat uit onder meer onderstaande puzzelstukjes:

• De cryptografische inventaris biedt een overzicht van welke cryptografische mechanismes met welke parameters (vb. sleutellengte) gebruikt worden, voor welk doel (vb. bescherming data in transit), waar en om welke data te beschermen (vb. medische persoonsgegevens).
• Concrete cryptografische aanbevelingen; welke cryptografische algoritmes en parameters (vb. sleutellengtes)  zijn veilig, welke dienen uitgefaseerd te worden, welke zijn onveilig, … Dergelijke aanbevelingen zijn reeds aanwezig binnen Smals en zijn tot stand gekomen dankzij Smals Research. Gegeven de dreiging die uitgaat van krachtige kwantumcomputers, is het waarschijnlijk dat de klassieke publieke sleutelcryptografie die vandaag aanbevolen wordt in de niet zo verre toekomst uitgefaseerd zal moeten worden.
• Documentatie van de uitzonderingen. Om communicatie met externe systemen (vb. van klanten of aanbieders van diensten) niet de facto onmogelijk te maken, kunnen tijdelijk uitzonderingen op de cryptografische aanbevelingen getolereerd worden. Dergelijke uitzonderingen dienen te worden gedocumenteerd; het risico wordt beschreven, de scope, het tijdsvenster en de goedkeuring (acceptatie) van het risico door het management.
• Crypto agility guidance moet project teams ondersteuning bieden bij het bouwen en aanpassen van toepassingen en diensten volgens de principes van cryptographic agility. Dat wil zeggen op zo’n manier dat rekening gehouden wordt met toekomstige cryptografische migraties.
• Een cryptografische policy is nodig om te vermijden dat de cryptografische aanbevelingen als vrijblijvende suggesties geïnterpreteerd worden en geeft hen dus een dwingend karakter. De cryptografische policy van Smals verwijst inderdaad naar onze aanbevelingen. Een cryptografische policy leidt tot een vereenvoudiging (uniformisering) van het crypto landschap binnen de organisatie. Het kan richting geven aan de migratie naar kwantumresistente standaarden, en de bouw van applicaties en diensten op een crypto-agile manier stimuleren.
• Cryptographic monitoring. Door het observeren van netwerkverkeer, kunnen we een inzicht krijgen in welke cryptografische mechanismes waar gebruikt worden en kan het helpen bij het uitvoeren van migraties. Dergelijke monitoring vereist gelukkig geen toegang tot de data in transit zelf.  

In het bijzonder over de cryptogafische inventaris en crypto-agility wil Smals Research zich in de komende periode een scherper beeld vormen. Het is vandaag inderdaad zo dat de principes van crypto-agility en het idee van de cryptografische inventaris er wel zijn, maar dat de concrete uitwerking helaas nog wat ontbreekt, niet enkel bij Smals, maar wereldwijd. In het algemeen is er dus nog werk aan de winkel.

Cryptografische inventaris

Een cryptografische inventaris kan een overzicht bieden van onder meer:

• welke cryptografische mechanismes gebruikt worden. Bijvoorbeeld ECDSA om digitale handtekeningen te plaatsen of AES voor bulk vercijfering.
• welke parameters daarbij gebruikt worden. ECDSA kan bijvoorbeeld gebruik maken van de elliptische kromme P-256 en AES kan ingezet worden in GCM modus met sleutels met een lengte van 256 bits.
• welke cryptografische libraries of services daarbij gebruikt worden. Voorbeelden van libraries zijn BouncyCastle 1.78, en OpenSSL 3.0. Voorbeelden van services zijn de blinde pseudonimiseringsdienst van eHealth en AWS CloudHSM. 
• welke data er beschermd wordt en met welk doel. Bijvoorbeeld integriteit en confidentialiteit van  medische data at rest.
• Waar in de code gebruik gemaakt wordt van cryptografie. In de klasse AbcSigner van regel 254 tot regel 269.

Samengevat laat de cryptografische inventaris ons toe snel te lokaliseren waar zwakheden of mogelijke zwakheden zich lokaliseren en waar dus updates of migraties moeten gebeuren.

De inventaris is geen eenmalige oefening maar moet steeds geactualiseerd blijven. Discovery tools, zoals onder meer CipherInsights, IBM Quantum Safe Explorer, AgileSec Analytics en QryptoDiscover, kunnen ons helpen bij zowel het opbouwen als het up-to-date houden. 

Zo’n inventaris kan veel details bevatten en, zeker voor wat grotere organisaties, erg complex worden. Het samenstellen en up-to-date houden dreigt dus een erg resource-intensieve operatie te worden. Bovendien maakt een organisatie gebruik van onder meer cryptografische libraries, cryptografische services, hardware van derden, etc. Er is dus nood aan een gestructureerde, gestandaardiseerde manier om een cryptografische inventaris uit te drukken, die automatisering en integratie faciliteert. Dit is waar IBM aan werkt met hun CBOM (cryptography Bill of Materials). We hopen alvast dat dit snel geadopteerd zal worden.

Een cryptografische inventaris zou alvast een aantal voordelen bieden, naast de migratie naar kwantumresistente cryptografie:

Security & resilience

Crypto risico is de mogelijkheid dat de organisatie schade ondervindt wanneer cryptografie niet doet wat het hoort te doen, onder meer door gebruik van verouderde cryptografische mechanismes of onveilige parameters, door gebrekkig sleutel- en certificaatbeheer of kwetsbaarheden in implementaties van cryptografische algoritmes. In de OWASP top 10, een awareness document voor ontwikkelaars en webapplicatiebeveiliging, staat ‘cryptographic failures’ op de tweede plaats. Voorbeelden zijn de $150M+ Capital One hack waarbij persoonsgegevens van miljoenen gebruikers gecompromitteerd werden ten gevolge van een sleutelbeheerprobleem, en de $200M+ Marriott Hotel hack waarbij door het onvolledig gebruik van encryptie miljoenen paspoortnummers openbaar werden. De cryptografische inventaris, eventueel aangevuld met cryptographic monitoring, maakt cryptografische risico’s inzichtelijk en helpt zo gelijkaardige incidenten te voorkomen. Crypto agility moet ons dan weer toelaten snel te migreren naar veilige cryptografie.

Compliance

Mede als gevolg van dergelijke incidenten stellen auditors zich hoe langer hoe minder tevreden met opervlakkige informatie over het gebruik van cryptografie. Een cyptografische inventaris, eventueel aangevuld met logs van cryptographic monitoring, biedt hen de mogelijkheid om vlot toegang te krijgen tot alle details omtrent het gebruik van cryptografie in de organisatie.

Het is dan ook logisch dat het hebben en onderhouden van een cryptografische inventaris meer en meer aanbevolen of zelfs opgelegd wordt. In de gemeenschappelijke publicatie door NSA, NIST en CISA  Quantum readiness: Migration To Post-quantum Cryptography lezen we bijvoorbeeld:

 “Organizations should create a cryptographic inventory that offers visibility into how the organization leverages cryptography in its IT (Information Technology) and OT (Operational Technology) systems. “

Compliance wordt vooral interessant wanneer de cryptografische inventaris naast gedetailleerde cryptografische aanbevelingen gelegd kan worden. Dat laatste is, zoals reeds vermeld, reeds aanwezig binnen Smals dankzij Smals Research.

Crypto-agility

Een crypto inventaris is een noodzakelijke stap richting cryptographic agility, of kortweg crypto-agility. Het is het vermogen om cryptografische mechanismes, zowel in software, hardware als infrastructuur, te vervangen en aan te passen, zonder dat daarbij de correcte werking van het systeem zelf onderbroken wordt. Op die manier kunnen oudere cryptografische mechanismes uitgefaseerd worden en nieuwere geadopteerd.

Hoewel de definitie van cryptographic agility niet altijd eenduidig is, lijkt onderstaande definitie, bestaande uit drie aspecten, vrij accuraat.

• Het vermogen van systemen om hun beveiligingsalgoritmen af te spreken in real-time en op basis van hun gecombineerde beveiligingsfuncties (dit is de hardware, software en firmware die gebruikt wordt om de veiligheid van een systeem te waarborgen);
• Het vermogen om nieuwe cryptografische functies of algoritmen toe te voegen aan bestaande hardware of software, wat resulteert in nieuwe, sterkere beveiligingsfuncties;
• Het vermogen om cryptografische systemen die kwetsbaar of verouderd zijn geworden, op een elegante manier uit te doven.

Hoe we cryptographic agility meer concreet in de praktijk kunnen brengen en wat de uitdagingen daarbij zijn is voer voor een toekomstig artikel. Wel kan TLS ons alvast inspireren. TLS is een cryptografisch protocol dat is ontworpen om veilige communicatie tussen twee partijen via een computernetwerk mogelijk te maken. Beide partijen spreken met elkaar af welke cryptografische mechanismes ze willen gebruiken voor authenticatie, key exchange, encryptie en hashing. Elke partij ondersteunt enkel die mechanismes die het veilig acht. Dit staat beschreven in een configuratiebestand, wat ons toelaat nieuwe cryptografische mechanismes toe te voegen en oude uit te faseren zonder de werking van de bovenliggende applicatie te beïnvloeden.

Conclusie

Kwantumcomputers worden cryptografisch relevant genoemd wanneer ze voldoende krachtig zijn om de moderne publieke sleutelcryptografie te breken. We staan daar vandaag nog ver van af en er is heel veel onzekerheid. We weten zelfs niet of de mensheid ooit in staat zal zijn om dergelijke machines te bouwen. Toch is het verstandig om het zekere voor het onzekere te nemen en ons daarop voor te bereiden.

De dreiging die momenteel uitgaat van kwantumcomputers en de publicatie van de nieuwe kwantumresistente cryptografische standaarden is dan ook een goede aanleiding om ons een algemenere vraag te stellen: hoe kunnen we onze cryptographic governance matuurder maken, zodat we

1. een beter inzicht krijgen in welke cryptografie er binnen en door de organisatie gebruikt wordt en
2. in staat zijn om relatief vlot te migreren indien nodig.

Dit is relevant, los van de dreiging die uitgaat van krachtige kwantumcomputers.

Smals is vandaag reeds bezig met die voorbereiding. We beschikken reeds over cryptografische aanbevelingen en een cryptografische policy. Maar er is meer nodig, onder meer een cryptografische inventaris en een adoptie van crypto-agility. Dit zijn elementen waar Smals Research de komende periode rond zal werken.

Er zijn vandaag nog heel wat vragen en onduidelijkheden, wat ons niet mag weerhouden reeds in actie te schieten. We gaan er trouwens van uit dat de publicatie van de nieuwe standaarden door het NIST alles in een stroomversnelling zal brengen.

Samengevat en ter afronding citeer ik Dr. Schabhüser, vice president van de Duitse BSI:

“Indien ik bedrijven en organisaties drie adviezen kon geven, zou het zijn

• Integreer het risico in je risk management systeem
• Creër een crypto inventaris
• Implementeer en gebruik crypto-agility”

Aarzel niet ons te contacteren voor meer informatie of eventuele samenwerking.

Dit is een ingezonden bijdrage van Kristof Verslype, cryptograaf bij Smals Research. Het werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Featured image by Michael Shehan Obeysekera

Les titres physiques, tels que les permis de conduire, les diplômes universitaires, la carte européenne d’assurance maladie (CEAM), ou encore l’attestation européenne A1 permettant de travailler à l’étranger (PD A1), et plus généralement les documents « papier » importants, présentent plusieurs inconvénients. Ils sont sujets à la perte, au vol, à l’endommagement ou à la duplication non autorisée et ils ne permettent pas facilement la minimisation des données comme le demande le Règlement général sur la protection des données (RGPD) de l’Union européenne.

Les titres vérifiables aussi appelés justificatifs numériques (en anglais « verifiable credentials (VC) »), sont des versions numériques et cryptographiquement sécurisées des titres physiques qui peuvent prouver numériquement quelque chose sur un sujet, comme son identité, une qualification obtenue, un droit, ou une information factuelle spécifique, tout en minimisant les informations révélées¹.

Ces titres vérifiables sont définis comme un ensemble d’une ou de plusieurs revendications formulées par un émetteur. Tout comme les titres physiques, ces titres vérifiables peuvent notamment contenir des :

• Informations relatives à l’identification du sujet (p. ex. personne, organisation, objet) du titre vérifiable (p. ex. nom, photo, numéro d’identification)
• Informations relatives à l’émetteur du titre (p. ex. gouvernement, source authentique, municipalités)
• Informations relatives au type de titre concerné (p. ex. carte d’assurance, carte d’invalidité, passeport, carte d’identité)
• Informations relatives à des attributs ou à des propriétés spécifiques revendiqués par l’émetteur sur le sujet (p. ex. date de naissance, droit à une prise en charge par la sécurité sociale, nationalité)
• Éléments de preuve relatifs à la façon dont le titre vérifiable a été créé (p. ex. renouvellement d’un titre précédent, présence physique d’un citoyen dans un bureau d’administration)
• Informations relatives aux contraintes applicables au titre vérifiable (p. ex. période de validité du titre)

Les principaux acteurs intervenant dans une architecture de titres vérifiables sont présentés dans la Figure 1 et incluent :

• Sujet: entité au sujet de laquelle les revendications sont faites (p. ex. personne, organisation, animal, objet inanimé).
• Détenteur ou titulaire: entité qui détient actuellement le titre vérifiable et le présente au contrôleur. Il peut s’agir du sujet, mais aussi d’une autre personne physique ou morale autorisée (p. ex. un parent).
• Émetteur: entité qui fait valoir des revendications sur un ou plusieurs sujets en créant un titre vérifiable à partir de ces revendications (p. ex. une institution compétente en matière de coordination de la sécurité sociale).
• Contrôleur / vérificateur: entité qui reçoit les titres vérifiables du détenteur par le biais d’une présentation et fournit des services et des avantages en retour².
• Portefeuille électronique: entité qui stocke les titres vérifiables d’un titulaire, y compris le logiciel qui interagit avec l’écosystème pour le compte du détenteur.
• Registre de données vérifiables: conceptuellement, un registre accessible sur Internet qui contient toutes les données et métadonnées essentielles permettant aux autres acteurs d’interagir.

Le détenteur d’un titre vérifiable peut le présenter à un contrôleur, qui peut vérifier l’authenticité de l’accréditation et l’identité du titulaire. Le processus d’émission d’un titre vérifiable consiste à lier une déclaration de l’émetteur sur un sujet à l’identifiant du sujet à l’aide de preuves cryptographiques [2]. C’est ce lien qui permet de combiner des sous-ensembles de plusieurs titres (voir ci-dessous). Une fois émis, un titre vérifiable peut être détenu pendant de longues périodes et présenté à de multiples fins et de multiples façons.

Divulgation d’attributs d’identité

La divulgation d’attributs pose généralement des problèmes de confidentialité. C’est le cas dans les systèmes où un fournisseur d’identité en ligne crée des jetons d’accès à la demande³. Dans de tels systèmes, le fournisseur d’identité peut suivre les activités de ses utilisateurs ou, pire, usurper leur identité. C’est également le cas des systèmes avec création de jetons hors ligne (p. ex. X509) car ils obligent l’utilisateur à révéler plus d’attributs que strictement nécessaire et rendent les transactions en ligne reliables à différents domaines.

Grâce à la technique de divulgation sélective les titulaires de titres vérifiables peuvent présenter uniquement les informations qu’ils choisissent à des contrôleurs, tout en gardant le reste de leurs données sensibles privées. Cette technique est particulièrement utile lorsqu’un utilisateur doit prouver une demande spécifique mais ne souhaite pas partager toutes les informations contenues, par exemple dans sa carte d’identité.

Dans le cadre de la coordination de la sécurité sociale, si un citoyen se trouve dans une situation de vérification avec un contrôleur qualifié, la divulgation sélective n’est pas appropriée, car les services et les prestations peuvent ne pas être fournis si seul un sous-ensemble d’informations est communiqué. Pour les contrôleurs non-qualifiés (p. ex. des entreprises souhaitant vérifier certains éléments d’un document de sécurité sociale), la divulgation sélective peut en revanche jouer un rôle.

Techniques cryptographiques connues

Sur la base de preuves à divulgation nulle de connaissance (« zero knowledge proof (ZKP) »), les titres basés sur des attributs et préservant la vie privée ou titres anonymes (« privacy-preserving attribute-based-credentials » ou « anonymous credentials ») ont été proposés comme une technique prometteuse pour établir des de titres vérifiables. Des mises en œuvre réussies de cette technique incluent Identity Mixer d’IBM [3] et U-Prove de Microsoft [4]. Un sous-ensemble des capacités d’Idemix est d’ailleurs utilisé depuis plusieurs années dans le projet néerlandais IRMA [5], [6]. Ce dernier projet a déjà permis aux citoyen(ne)s néerlandais(es) d’obtenir des informations d’identification avec des attributs vérifiés auprès de plusieurs organisations, y compris le registre de l’état civil néerlandais⁴.

Cette technique a commencé à recevoir plus d’attention au milieu des années 2010, avec le projet Européen ABC4Trust [8], [9] et également à la suite de l’essor du concept d’« identité auto-souveraine » (« self-sovereign identity (SSI) ») [10], [11]. L’identité auto-souveraine est un modèle d’identité numérique dans lequel un utilisateur est équipé de techniques pour créer, vérifier et (surtout) posséder une identité numérique divulgable entre parties de confiance. Cela signifie généralement que lorsqu’un utilisateur présente une revendication d’identité à une partie utilisatrice l’identité donnée peut être vérifiée sans intervention directe du fournisseur d’identité, ce qui présente des avantages pour la vie privée de l’utilisateur.

Les informations d’identification basées sur des titres anonymes peuvent exprimer n’importe quelle information contenue dans un justificatif d’identité physique en offrant un avantage supplémentaire : ils peuvent être combinés (voir Figure 2), et ils permettent de ne révéler que les attributs requis (divulgation sélective) voire même des informations dérivées de ces attributs. Un exemple emblématique est la date de naissance : il est possible de ne révéler que l’âge, que la catégorie d’âge (p. ex. 50-60 ans), ou encore simplement le fait que la personne a plus ou moins d’un certain âge, etc. sans pour autant révéler la date de naissance exacte.

Conclusions

En cours de standardisation par le World Wide Web Consortium [1], [2], [12], les titres vérifiables permettent de transformer des titres physiques en un format numérique que l’on peut enregistrer dans un portefeuille électronique comme un « portefeuille européen d’identité numérique » (« EUDIW »). Leur succès est soumis à un « effet de réseau » que pourrait apporter le règlement eIDAS 2.0 (identification électronique et services de confiance) qui est une étape importante vers le développement d’identités numériques interopérables en Europe tant pour les secteurs publics que privés.

Une technique de mise en œuvre des titres vérifiables sont les titres anonymes qui ont été développés depuis le début des années 2000 afin de permettre une authentification et une identification à la fois sécurisée et respectant la vie privée. Les techniques cryptographiques sous-jacentes – nécessaires au fonctionnement d’innombrables scénarios qui reposent sur des informations d’identification vérifiées – sont bien connues, mais la facilité d’utilisation des technologies qui en résultent pour les utilisateurs finaux, bien qu’elle soit d’une importance cruciale, est encore largement inexplorée.

Références

[1]        M. Sporny, D. Longley, D. Chadwick, et O. Steele, « Verifiable Credentials Data Model v2.0 ». Consulté le: 11 juillet 2024. [En ligne]. Disponible sur: https://www.w3.org/TR/vc-data-model-2.0/

[2]        M. Sporny, D. Longley, et D. Chadwick, « Verifiable Credentials Data Model v1.1 ». Consulté le: 19 février 2024. [En ligne]. Disponible sur: https://www.w3.org/TR/2022/REC-vc-data-model-20220303/

[3]        « Specification of the Identity Mixer Cryptographic Library », IBM Research, Zurich, Research Report RZ3730, avr. 2010.

[4]        Christian Paquin, « U-Prove Technology Overview V1.1 ». Microsoft Corporation, avril 2013. [En ligne]. Disponible sur: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/U-Prove20Technology20Overview20V1.120Revision202.pdf

[5]        Radboud Universiteit Nijmegen, IRMA: back in control of your personal data, (23 juin 2016). Consulté le: 24 juillet 2017. [En ligne Vidéo]. Disponible sur: https://www.youtube.com/watch?v=q6IihEQFPys

[6]        Gergely Alpár, Fabian van den Broek, Brinda Hampiholi, Bart Jacobs, Wouter Lueks, et Sietse Ringers, « IRMA: practical, decentralized and privacy-friendly identity management using smartphones », Minneapolis, 2017. Consulté le: 24 juillet 2017. [En ligne]. Disponible sur: https://www.cs.ru.nl/~gergely/objects/2017_irma-hotpets.pdf

[7]        P. Dunphy et F. A. P. Petitcolas, « A First Look at Identity Management Schemes on the Blockchain », IEEE Secur. Priv., vol. 16, n^o 4, p. 20‑29, juill. 2018, doi: 10.1109/MSP.2018.3111247

[8]        J. Camenisch, S. Krenn, A. Lehmann, G. Neven, et M. Ø. Pedersen, « Scientific Comparison of ABC Protocols », p. 70.

[9]        Kai Rannenberg, Jan Camenisch, et Ahmad Sabouri, Éd., Attribute-based Credentials for Trust – Identity in the Information Society. Springer International Publishing, 2015.

[10]      Christopher Allen, « The Path to Self-Sovereign Identity », CoinDesk. Consulté le: 5 juillet 2017. [En ligne]. Disponible sur: http://www.coindesk.com/path-self-sovereign-identity/

[11]      Andrew Tobin et Drummond Reed, « The Inevitable Rise of Self-Sovereign Identity ». The Sovrin Foundation, 29 septembre 2016. [En ligne]. Disponible sur: https://www.sovrin.org/The%20Inevitable%20Rise%20of%20Self-Sovereign%20Identity.pdf

[12]      Manu Sporny, Dave Longley, et David Chadwick, « Verifiable Credentials Data Model 1.0 – Expressing verifiable information on the Web », W3C, nov. 2019. [En ligne]. Disponible sur: https://www.w3.org/TR/2019/REC-vc-data-model-20191119/

Notes

¹   Notons que le terme « vérifiable » indique seulement qu’un titre vérifiable est une déclaration authentique d’un émetteur à un moment donné, pas que les revendications encodées dans le titre sont vraies. L’émetteur peut cependant inclure des informations permettant au vérificateur de déterminer si les revendications ont une véracité suffisante pour ses besoins.

²   La réglementation européenne distingue les vérificateurs « qualifiés » soumis à des exigences strictes et ayant un effet juridique spécifique plus fort, des vérificateurs « non-qualifiés » pouvant inclure n’importe quelle partie invoquante.

³   Cela inclut des systèmes tels que Facebook ou Google login et d’autres similaires qui reposent sur des normes telles que SAML, OpenID ou WS-Federation.

⁴   Il existe d’autres tentatives pour aider les utilisateurs finaux à prouver leur identité numérique. Nous avons passé en revue certains d’entre eux [7]. Plusieurs autres n’ont pas fourni de détails techniques, mais leurs revendications commerciales ont une direction commune : plus de contrôle pour les utilisateurs, une meilleure confidentialité, et une sécurité accrue.

_________________________

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

Fysieke certificaten, zoals een rijbewijs, universitaire diploma’s, de Europese ziekteverzekeringskaart (EZVK), of het A1-attest voor werken in het buitenland (PD A1), en meer in het algemeen belangrijke “papieren” documenten, hebben verschillende nadelen. Ze zijn onderhevig aan verlies, diefstal, beschadiging of onbevoegde duplicatie, en ze bieden niet gemakkelijk de mogelijkheid om gegevens te minimaliseren zoals vereist door de General Data Protection Regulation (GDPR) van de Europese Unie.

Verifiable credentials (VC – “verifieerbare attesteringen”) zijn digitale en cryptografisch beveiligde versies van fysieke certificaten die digitaal iets over een persoon kunnen bewijzen, zoals zijn of haar identiteit, een behaalde kwalificatie, een recht of specifieke feitelijke informatie, terwijl de vrijgegeven informatie tot een minimum wordt beperkt¹.

Deze verifiable credentials worden gedefinieerd als een reeks van een of meer claims door een uitgevende instelling. Net als fysieke certificaten kunnen deze verifiable credentials het volgende bevatten:

• Informatie met betrekking tot de identificatie van het onderwerp (bijv. persoon, organisatie, object) van de verifiable credentials (bijv. naam, foto, identificatienummer)
• Informatie met betrekking tot de uitgever van de attestering (bv. overheid, authentieke bron, gemeenten)
• Informatie met betrekking tot de soort attestering in kwestie (bijv. verzekeringskaart, invaliditeitskaart, paspoort, identiteitskaart)
• Informatie met betrekking tot specifieke kenmerken of eigenschappen die de uitgever stelt over de betrokkene (bijv. geboortedatum, recht op sociale zekerheid, nationaliteit)
• Bewijs van de manier waarop de verifiable credential is gecreëerd (bijv. vernieuwing van een eerdere attestering, fysieke aanwezigheid van een burger in een administratiekantoor)
• Informatie over de beperkingen die van toepassing zijn op de verifiable credential (bv. geldigheidsduur van de attestering)

De belangrijkste spelers die betrokken zijn bij een architectuur voor verifiable credentials worden in Figuur 1 beschreven en omvatten:

• Onderwerp: entiteit waarover claims worden gemaakt (bijv. persoon, organisatie, dier, levenloos voorwerp).
• Houder: de entiteit die op dat moment de virtuele waarde bezit en deze aan de controleur presenteert. Dit kan de betrokkene zijn, maar ook een andere bevoegde natuurlijke of rechtspersoon.
• Uitgever: entiteit die aanspraken maakt op een of meer onderwerpen door een verifiable credential te creëren op basis van deze aanspraken (bijv. een instelling die verantwoordelijk is voor de coördinatie van de sociale zekerheid).
• Controleur/verificateur: een entiteit die verifiable credentials ontvangt van de houder door middel van een indiening en in ruil daarvoor diensten en voordelen verleent².
• E-portemonnee: entiteit die de verifiable credentials van een houder opslaat, met inbegrip van de software die namens de houder interageert met het ecosysteem.
• Verifieerbaar gegevensregister: conceptueel een via het internet toegankelijk register dat alle essentiële gegevens en metadata bevat die andere spelers in staat stellen om te interageren.

De houder van een verifiable credential kan het tonen aan een controleur, die de authenticiteit van de accreditatie en de identiteit van de houder kan verifiëren. Het proces van de uitgifte van een verifiable credential omvat het koppelen van een claim van de uitgever over een onderwerp aan de identifier van het onderwerp met behulp van cryptografisch bewijs [2]. Het is deze koppeling die het mogelijk maakt subsets van verschillende attesteringen te combineren (zie hieronder). Eenmaal uitgegeven, kan een verifiable credential voor langere tijd worden bewaard en voor meerdere doeleinden en op meerdere manieren worden aangeboden.

Vrijgeven van identiteitsattributen

Het vrijgeven van attributen levert over het algemeen vertrouwelijkheidsproblemen op. Dit is het geval in systemen waar een online identiteitsprovider op aanvraag toegangstokens creëert^[3]. In dergelijke systemen kan de identiteitsprovider de activiteiten van zijn gebruikers volgen of, erger nog, zich hun identiteit toe-eigenen. Dit is ook het geval bij systemen die offline tokens aanmaken (bijv. X509) omdat ze de gebruiker vragen om meer attributen prijs te geven dan strikt noodzakelijk en online transacties koppelbaar maken aan verschillende domeinen.

Met behulp van de selectieve openbaarmakingstechniek (“selective disclosure”) kunnen houders van verifiable credentials alleen de informatie presenteren die ze willen tonen, terwijl ze de rest van hun gevoelige gegevens privé houden. Deze techniek is vooral nuttig wanneer een gebruiker een specifieke claim moet bewijzen, maar niet alle informatie op bijvoorbeeld zijn identiteitskaart wil delen.

In de context van de coördinatie van de sociale zekerheid, als een burger zich in een verificatiesituatie bevindt met een gekwalificeerde controleur, is selectieve bekendmaking niet gepast, aangezien diensten en voordelen mogelijk niet worden verstrekt als slechts een subset van informatie wordt bekendgemaakt. Voor niet-gekwalificeerde controleurs (bv. bedrijven die bepaalde elementen van een socialezekerheidsdocument willen controleren) kan selectieve openbaarmaking daarentegen wel een rol spelen.

Bekende cryptografische technieken

Op basis van zero knowledge proofs (“nulkennisbewijs” – ZKP) zijn privacybehoudende attribuutgebaseerde attesteringen (privacy-preserving attribute-based-credentials) of geanonimiseerde attesteringen (anonymous credentials) voorgesteld als een veelbelovende techniek voor het vaststellen van verifiable credentials. Succesvolle implementaties van deze techniek zijn onder andere IBM’s Identity Mixer [3] en Microsoft’s U-Prove [4]. Een subset van de mogelijkheden van Idemix wordt ook al enkele jaren gebruikt in het Nederlandse IRMA-project [5], [6].  Dit project heeft Nederlandse burgers al in staat gesteld om identificatie-informatie met geverifieerde attributen te verkrijgen van een aantal organisaties, waaronder de Nederlandse Burgerlijke Stand^[4].

Deze techniek begon meer aandacht te krijgen in het midden van de jaren 2010, met het Europese ABC4Trust-project [8], [9] en ook na de opkomst van het self-sovereign identity (SSI) concept [10], [11]. Self-sovereign identity is een model van digitale identiteit waarbij een gebruiker beschikt over  technieken om een digitale identiteit te creëren, te verifiëren en (vooral) te bezitten die kan worden vrijgegeven tussen vertrouwde partijen. Dit betekent over het algemeen dat wanneer een gebruiker een identiteitsclaim indient bij een betrouwbare partij, de gegeven identiteit geverifieerd kan worden zonder directe tussenkomst van de Identity Provider, wat voordelen heeft voor de privacy van de gebruiker.

Geanonimiseerde attesteringen kunnen alle informatie in een fysiek identiteitsbewijs uitdrukken, met als extra voordeel dat ze gecombineerd kunnen worden (zie Figuur 2) en dat alleen de vereiste attributen onthuld kunnen worden (selectieve openbaarmaking) of zelfs informatie die van die attributen is afgeleid. Een emblematisch voorbeeld is de geboortedatum: het is mogelijk om alleen de leeftijd te onthullen, alleen de leeftijdscategorie (bijv. 50-60 jaar), of zelfs alleen het feit dat de persoon boven of onder een bepaalde leeftijd is, enz. zonder de exacte geboortedatum te onthullen.

Conclusies

Verifiable credentials, die momenteel worden gestandaardiseerd door het World Wide Web Consortium [1], [2], [12], maken het mogelijk fysieke attesteringen om te zetten in een digitaal formaat dat kan worden opgeslagen in een elektronische portemonnee zoals een European Digital Identity Wallet (EUDIW). Hun succes is afhankelijk van een “netwerkeffect” dat teweeggebracht zou kunnen worden door de eIDAS 2.0 verordening (elektronische identificatie en vertrouwensdiensten), die een belangrijke stap is in de ontwikkeling van interoperabele digitale identiteiten in Europa voor zowel de publieke als de private sector.

Een techniek voor het implementeren van verifiable credentials is via anonieme attesteringen, die sinds het begin van de jaren 2000 ontwikkeld zijn om authenticatie en identificatie veilig en met respect voor de privacy mogelijk te maken. De onderliggende cryptografische technieken – onmisbaar voor de werking van talloze scenario’s die vertrouwen op verifieerbare identificatiegegevens – zijn welbekend, maar de bruikbaarheid van de resulterende technologieën voor eindgebruikers, hoewel van cruciaal belang, is nog grotendeels onontgonnen terrein.

Referenties

[1]        M. Sporny, D. Longley, D. Chadwick, en O. Steele, ‘Verifiable Credentials Data Model v2.0’. Geraadpleegd: 11 juli 2024. [Online]. Beschikbaar op: https://www.w3.org/TR/vc-data-model-2.0/

[2]        M. Sporny, D. Longley, en D. Chadwick, ‘Verifiable Credentials Data Model v1.1’. Geraadpleegd: 19 februari 2024. [Online]. Beschikbaar op: https://www.w3.org/TR/2022/REC-vc-data-model-20220303/

[3]        ‘Specification of the Identity Mixer Cryptographic Library’, IBM Research, Zurich, Research Report RZ3730, apr. 2010.

[4]        Christian Paquin, ‘U-Prove Technology Overview V1.1’, april 2013, Microsoft Corporation. [Online]. Beschikbaar op: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/U-Prove20Technology20Overview20V1.120Revision202.pdf

[5]        Radboud Universiteit Nijmegen, IRMA: back in control of your personal data, (23 juni 2016). Geraadpleegd: 24 juli 2017. [Online Video]. Beschikbaar op: https://www.youtube.com/watch?v=q6IihEQFPys

[6]        Gergely Alpár, Fabian van den Broek, Brinda Hampiholi, Bart Jacobs, Wouter Lueks, en Sietse Ringers, ‘IRMA: practical, decentralized and privacy-friendly identity management using smartphones’, Minneapolis, 2017. Geraadpleegd: 24 juli 2017. [Online]. Beschikbaar op: https://www.cs.ru.nl/~gergely/objects/2017_irma-hotpets.pdf

[7]        P. Dunphy en F. A. P. Petitcolas, ‘A First Look at Identity Management Schemes on the Blockchain’, IEEE Secur. Priv., vol. 16, nr. 4, pp. 20-29, jul. 2018, doi: 10.1109/MSP.2018.3111247

[8]        J. Camenisch, S. Krenn, A. Lehmann, G. Neven, en M. Ø. Pedersen, ‘Scientific Comparison of ABC Protocols’, p. 70.

[9]        Kai Rannenberg, Jan Camenisch, en Ahmad Sabouri, Red., Attribute-based Credentials for Trust – Identity in the Information Society. Springer International Publishing, 2015.

[10]      Christopher Allen, ‘The Path to Self-Sovereign Identity’, CoinDesk. Geraadpleegd: 5 juli 2017. [Online]. Beschikbaar op: http://www.coindesk.com/path-self-sovereign-identity/

[11]      Andrew Tobin en Drummond Reed, ‘The Inevitable Rise of Self-Sovereign Identity’, 29 september 2016, The Sovrin Foundation. [Online]. Beschikbaar op: https://www.sovrin.org/The%20Inevitable%20Rise%20of%20Self-Sovereign%20Identity.pdf

[12]      Manu Sporny, Dave Longley, en David Chadwick, ‘Verifiable Credentials Data Model 1.0 – Expressing verifiable information on the Web’, W3C, nov. 2019. [Online]. Beschikbaar op: https://www.w3.org/TR/2019/REC-vc-data-model-20191119/

¹   Merk op dat de term verifiable (“verifieerbaar”) enkel aangeeft dat een verifieerbare waarde een authentieke claim is van een uitgever op een bepaald moment, niet dat de claims gecodeerd in de attestering waar zijn. De uitgever kan er informatie aan toevoegen om de controleur in staat te stellen te bepalen of de claims voldoende waar zijn voor de doeleinden van de controleur.

²   De Europese regelgeving maakt onderscheid tussen “gekwalificeerde” verificateurs, die onderworpen zijn aan strenge eisen en een sterker specifiek rechtsgevolg hebben, en “niet-gekwalificeerde” verificateurs, die elke partij kunnen zijn die een beroep doet op de regeling.

³   Dit omvat systemen zoals Facebook of Google login en vergelijkbare systemen gebaseerd op standaarden zoals SAML, OpenID of WS-Federation.

⁴   Er zijn andere pogingen om eindgebruikers te helpen hun digitale identiteit te bewijzen. We hebben er een aantal beoordeeld [7]. Verschillende andere gaven geen technische details, maar hun commerciële claims hebben een gemeenschappelijke richting: meer controle voor gebruikers, betere privacy en meer veiligheid.

Dit is een ingezonden bijdrage van Fabien A. P. Petitcolas, IT-beveiligingsspecialist bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Note : il s’agit d’un article de vulgarisation consacré à une réglementation future, basé sur la publication officielle du 12/07/2024. Adressez-vous toujours à un·e juriste pour obtenir un avis juridique professionnel.

L’AI Act européen (en français le règlement sur l’intelligence artificielle) est une des pierres angulaires d’une série d’initiatives législatives à grande échelle destinées à réglementer l’économie numérique en Europe. Il vient ainsi compléter la législation antérieure relative à certains aspects de l’intelligence artificielle, comme le RGPD, le Digital Services Act (DSA) et le Digital Markets Act (DMA), le Data Act, le Data Governance Act, le CHIPS Act et le Cyber Resilience Act en cours d’élaboration. Après de longues négociations, l’AI Act a été approuvé par le Parlement européen en mars 2024 et par le Conseil européen en mai 2024. La publication au Journal officiel de l’Union européenne, que l’on peut appeler Moniteur européen, a eu lieu le 12 juillet 2024. Les premières règles entreront en vigueur début 2025. Vous pouvez également consulter cette chronologie.

Un RGPD bis ?

Le texte intégral de l’AI Act, y compris l’ensemble des préliminaires et annexes, comprend 144 pages. Fort heureusement, de bons résumés sont déjà disponibles ici et là. Il est ainsi presque deux fois plus long que le RGPD qui ne fait, lui, “que” 88 pages. L’impact de ce dernier est énorme : toutes les organisations traitant des données à caractère personnel – il suffit d’avoir une administration du personnel ou un fichier de clients – se sont en effet vues confrontées aux exigences relatives aux délégués à la protection des données, aux registres de traitement et aux bases juridiques du traitement des données. Chaque pays a également dû mettre en place une  Autorité de protection des données habilitée à infliger des amendes en cas d’infraction.

Le RGPD s’est également accompagné d’une certaine confusion, notamment par son utilisation fréquente de termes ouverts à l’interprétation (“approprié”, “adéquat”, “adapté”, “suffisant”…).
La nécessité de les concrétiser à nouveau pour chaque cas d’espèce alimente ce que l’on peut aujourd’hui appeler une petite industrie juridique. L’AI Act vise à fournir un peu plus d’indications, en revêtant une forme plus technique. Il comporte ainsi une liste d’annexes avec des énumérations pratiques des attentes en matière de documentation, de conformité, de transparence, etc.

L’AI Act est parti d’une proposition plus compacte de 125 pages (annexes incluses). Au cours des négociations cependant, on a assisté à l’essor fulgurant de l’IA générative et des grands modèles de langage. Cette nouvelle donne a nécessité la révision et l’ajout de certains éléments, tels qu’un nouveau chapitre (5) entièrement consacré aux modèles d’IA à usage général, parmi lesquels on compte les grands modèles de langage. Quant à certaines sections, on peut se demander ce qu’elles viennent faire dans l’AI Act, notamment un système de “bacs à sable réglementaires de l’IA” (article 57) qui doit permettre aux régulateurs de faciliter l’innovation. Certains articles sont formulés de manière plutôt énigmatique, comme la section dédiée aux “organismes d’évaluation de la conformité notifiés” (article 29), qui ne sont ni plus ni moins que des auditeurs. Des voix critiques se font donc entendre, craignant que la somme de mesures qui en résulte ne débouche avant tout sur un véritable imbroglio.

AI Act – Fondamentaux

L’AI Act s’adresse aux développeurs et aux fournisseurs d’IA, et ce uniquement lorsqu’ils publient des systèmes d’IA et les mettent à la disposition de tiers. Tous les développements et tests internes préalables sont explicitement exemptés (article 2 §8). L’AI Act ne s’applique pas non plus aux activités personnelles auxquelles vous vous adonnez dans un contexte non professionnel (article 2 §10). De même, la recherche scientifique (article 2 §6) et les applications militaires (article 2 §3) ne sont pas concernées. Bien évidemment, cela ne signifie pas que tout est permis dans tous ces cas.
Il va de soi que d’autres législations existantes restent en vigueur. Les droits des citoyens étaient déjà protégés par l’article 22 du RGPD entre autres, tandis que la législation sur les droits d’auteur continue de protéger les auteurs.

Par ailleurs, la définition de l’IA utilisée est particulièrement large et empruntée à l’OCDE : en résumé, “un système IA […] déduit, à partir des entrées, la manière de générer des sorties […]” (article 3 + considérant 12). La quasi-totalité de l’apprentissage automatique entre dans ce cadre. Dans d’autres définitions, on lit parfois que l’IA comporte un aspect cognitif (quelque chose doit être “reconnu”), mais il n’en est pas fait mention ici. Il n’est pas non plus fait mention de techniques spécifiques : tout ce qui apprend de manière adaptative ou peut réagir de manière quelque peu autonome à l’environnement est presque toujours inclus. Il s’agit donc également des systèmes que vous connaissez depuis des années, sans vous rendre compte qu’ils reposent sur l’intelligence artificielle, tels que les filtres antispam, les recommandations sur les sites web, voire les prévisions météorologiques.

L’AI Act définit d’abord et surtout une liste de pratiques interdites (article 5), qui prendra effet dès le début de l’année 2025. Cette liste est exhaustive, ce qui signifie en principe que tout ce qui n’est pas explicitement interdit est autorisé (sauf dispositions contraires prévues par d’autres lois). Aussi est-il intéressant d’examiner ce qui figure et ce qui ne figure pas dans cette liste d’interdictions, ainsi que les dispositions supplémentaires qui s’y rapportent. On découvre ainsi que :

• §1(f) : L’interdiction de la reconnaissance des émotions ne mentionne que le lieu de travail et l’enseignement.
• §1(g) : L’interdiction des systèmes d’IA biométriques ne mentionne que la déduction automatique concernant la race, la sexualité, l’affiliation à une organisation syndicale, la religion, les convictions politiques et philosophiques.
• §1(e) : L’interdiction de la reconnaissance faciale ne concerne que les systèmes basés sur ce qu’on appelle “moissonnage non ciblé”.

Elle est donc plus nuancée qu’une liste d’interdictions générales, car le contexte et l’objectif interviennent également. La reconnaissance des émotions dans les jeux vidéo, par exemple, reste ainsi autorisée. Les considérants 15 à 17 précisent que l’IA biométrique reste autorisée pour la vérification d’identité et l’authentification. Parallèlement, des exceptions sont prévues entre autres pour l’assistance médicale et la lutte contre la criminalité, bien que ces exceptions soient soumises à un contrôle strict (article 5, §2-§7), y compris une liste des infractions pénales qui entrent en ligne de compte (annexe 2).

Les systèmes qui assurent la sécurité des utilisateurs ou qui sont énumérés à l’annexe 3 sont des systèmes à haut risque (article 6). Il s’agit principalement de systèmes susceptibles d’avoir un impact majeur sur les libertés, la vie, la carrière ou la santé d’un individu. Bien que cette section de l’AI Act n’entrera en vigueur qu’à l’été 2026, il convient de noter qu’il subsiste des lacunes à combler. Par exemple, la Commission doit encore fournir des lignes directrices précisant l’interprétation de cet article (article 6 §5) et se réserve le droit d’apporter des modifications même après coup (article 6 §6-§8, article 7).

AI Act – Obligations

Quiconque souhaite construire ou a construit un système à haut risque devra se conformer à une série d’obligations, qui doivent notamment permettre aux autorités compétentes d’intervenir en cas de non-respect. Les développeurs de systèmes à haut risque devront adopter certaines pratiques, notamment :

• Un système itératif de gestion des risques (article 9), qui doit permettre d’identifier et d’évaluer les risques et d’atténuer les abus potentiels à l’avance. Le texte est relativement peu concret : il parle de “risques raisonnablement prévisibles” et de “mesures appropriées” sans autre précision. Ceci fera donc encore l’objet de discussions, mais dans la pratique, on peut déjà aujourd’hui se contenter en partie des normes récemment élaborées à cette fin, telles que la norme ISO/IEC 42001. Étant entendu qu’elle n’est pas explicitement conçue pour la loi sur l’IA Act, des mesures supplémentaires peuvent s’imposer.
• La gestion de données de qualité (article 10), qui se résume en grande partie à la transparence sur l’origine, les limites, les marges d’erreur et la représentativité. L’utilisation de Data Sheets (fiches de données), dont c’est l’objectif, est devenue populaire dans le secteur au cours des dernières années.
• Fournir une documentation technique conforme aux exigences de l’annexe 4 (annexe 11 pour l’IA à usage général). Ceci est quelque peu analogue aux Model Cards (cartes modèles) que l’on peut trouver sur le HuggingFace Hub, bien que la Commission européenne ne se contente pas de listes cochées et exige plus de détails, y compris sur la surveillance et le contrôle pendant la durée de vie du système.
• L’enregistrement (article 12) ainsi que la transparence et la fourniture d’informations aux utilisateurs (article 13).
• Le contrôle humain pendant la durée de vie du système (article 14). Si l’article 22 du RGPD en faisait déjà un droit civil, l’AI Act impose aux développeurs de prendre les mesures nécessaires à cette fin. Par exemple, il devra toujours être possible d’ignorer, de remplacer ou d’arrêter le système d’IA (article 14 §4 (d-e)).
• Prendre des mesures “appropriées” en matière de cybersécurité, de robustesse et d’exactitude (article 15). Cet article reste lui aussi relativement vague à l’heure actuelle et fait référence à l’intention de la Commission de soutenir le développement des étalonnages nécessaires.

Quiconque publie, met à disposition, incorpore dans son propre produit, importe ou distribue un système à haut risque devra prendre des mesures similaires, notamment :

• Vérifier et prouver la conformité du système (article 16 §e-l, articles 40-47), établir une déclaration de conformité (annexe 5) et obtenir le marquage CE (article 48). 
• Utiliser un système de gestion de la qualité (article 17).
• Conserver la documentation nécessaire pendant 10 ans après la mise en service (article 18).
• Coopérer avec les autorités compétentes (article 21).
• Enregistrer le système (article 49) dans une base de données européenne dédiée (article 71).
• Désigner une personne de contact ou un représentant pour tout ce qui précède (article 22).
• Mettre en place la surveillance nécessaire et agir en cas de problème (article 26 §5 et articles 72-73), notamment en informant l’autorité compétente.

Par analogie avec l’analyse d’impact relative à la protection des données du RGPD, certaines organisations, dont toutes les autorités publiques et les organisations de service public, devront réaliser une analyse d’impact sur les droits fondamentaux (Fundamental Rights Impact Assessment ou FRIA) dont les résultats devront être communiqués aux régulateurs du marché compétents (article 27). L’AI Office européen est déjà chargé de développer les questionnaires automatisés nécessaires à l’acquittement de cette obligation (article 27 §5).

On en oublierait presque que la grande majorité des systèmes d’IA sont simplement des systèmes à faible risque. À cet égard, l’AI Act est assez succinct : ils doivent satisfaire à des exigences minimales de transparence uniquement pour des applications spécifiques (article 50). Ainsi, l’utilisateur final doit toujours savoir qu’il interagit avec un système d’IA, et les résultats générés artificiellement doivent être clairement identifiés comme tels. La mainmise redoutée sur l’ensemble de l’industrie de l’IA est donc toute relative.

IA à usage général

Le développement récent de l’IA générative à usage général pour le texte et les images a nécessité l’ajout d’une catégorie distincte de systèmes, à savoir l’IA à usage général. La Commission européenne considère que ce type d’IA, indépendamment d’un éventuel risque élevé en matière de droits civils, peut également présenter un risque systémique (article 51). Le bien-fondé ou non de cette position fait l’objet d’un débat acharné dans les cercles techniques et philosophiques, mais l’UE adopte une approche prudente et prévoit un bâton juridique.

La Commission européenne se donne la liberté de déterminer les systèmes qui présentent un tel risque (article 51 §1). Bien qu’elle affirme appliquer des critères objectifs pour ce faire (annexe 13), il n’y a pas de véritable formule. Néanmoins, l’article 51 §2 fixe étonnamment une limite très concrète, à savoir qu’à partir du moment où son entraînement requiert une puissance de calcul de 10²⁵ FLOPS, un modèle d’IA à usage général est par définition considéré comme présentant un risque systémique. Cela correspond approximativement à un temps d’entraînement d’un an sur un cluster de 4000 GPU de type Nvidia RTX4090 (avec une puissance de calcul de 82×10¹² FLOPS). Pour éviter que tout cela ne devienne obsolète demain, la Commission se réserve le droit d’adapter ces valeurs à l’avenir en fonction des évolutions du domaine (article 51 §3).

Outre les exigences minimales de l’article 50 et indépendamment de la classification des risques, l’IA à usage général est soumise à son propre ensemble d’exigences en matière de documentation technique (article 53, annexe 11), qui seront un peu élargies en présence d’un risque systémique (article 55). Les constructeurs de modèles d’IA à usage général sans risque systémique publiés sous licence libre sont exemptés de certaines obligations (article 53 §2, voir également les considérants 102 à 104) et ne sont pas non plus tenus de désigner une personne de contact ou un représentant (article 54 § 6).

AI Office (Bureau de l’IA)

L’AI Act devra également être appliqué. Un rôle majeur dans ce cadre sera joué par l’AI Office (Bureau de l’IA, article 64), qui devrait être à l’AI Act ce que le Contrôleur européen de la protection des données est au RGPD. L’AI Office est actuellement mis en place à grande vitesse, les premières dispositions entrant en vigueur début 2025. Outre la responsabilité de compléter une série d’articles en suspens de l’IA Act, l’AI Office se verra confier la compétence exclusive de la surveillance de l’IA à usage général (article 75).

En pratique, l’AI Office fera partie de la DG CONNECT, commencera avec 140 collaborateurs et sera dirigé par Lucilla Sioli. Il sera soutenu dans son fonctionnement par le Centre européen pour la transparence algorithmique (ECAT), un Comité AI (article 65), un forum consultatif des parties prenantes (article 67) et un groupe scientifique d’experts indépendants (article 68).

Des régulateurs doivent également être désignés au niveau national (article 70). Ils devront travailler en étroite collaboration avec l’AI Office de l’UE et avec les régulateurs industriels et sectoriels existants, qui aujourd’hui sont déjà responsables du marquage CE, par exemple. Aux Pays-Bas, l’Autoriteit Persoonsgegevens joue clairement un rôle de pionnier dans la mise sur pied d’une autorité néerlandaise de l’IA, qui sera probablement établie dans le giron de l’Autoriteit Persoonsgegevens. En Belgique, la situation reste calme, même si le temps presse. En effet, on ne peut pas non plus engager n’importe qui pour occuper ces fonctions assez spécialisées.

Conclusion

Il est important de retenir que l’AI Act n’impose aucune restriction aux systèmes d’IA à faible risque, à l’exception de l’IA à usage général qui requiert la transparence nécessaire. Ce n’est que pour les systèmes à risques élevés ou systémiques et mis en production qu’interviennent des exigences strictes et la nécessité de se conformer aux réglementations pertinentes. Même dans ce cas, de nombreuses mesures d’atténuation offrent une marge de manœuvre supplémentaire au développement interne, aux initiatives open source, à la science, à la défense, etc.

Dans une certaine mesure, l’AI Act se veut concret, par une énumération détaillée des attentes et la mention de diverses précisions dans les considérants et les annexes. Il y parvient en partie et devient ainsi assez technique, de sorte qu’un juge concerné devra apprendre ce que sont les FLOPS. Parallèlement, il subsiste de nombreuses lacunes à combler et il reste à voir où le nouvel AI Office placera la barre dans les futures Commissions. La possibilité de modifier ultérieurement l’IA Act a été envisagée ici et là. La version actuelle de l’IA Act ne sera donc certainement pas la dernière.

Enfin, en Belgique, il ne s’agit pas d’attendre trop longtemps pour désigner et organiser le(s) régulateur(s) national(aux) pour l’AI Act si l’on veut être un tant soit peu en phase avec le reste de l’Europe. Pour obtenir des outils pratiques qui peuvent, entre autres, vous aider à vous mettre en conformité, vous pouvez d’ores et déjà consulter la base de données du Kenniscentrum Data & Maatschappij. De nombreux autres documents y seront certainement publiés lorsque l’AI Act entrera effectivement en vigueur.

______________________

Cette contribution a été soumise par Joachim Ganseman, consultant IT chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.