Cryptographie post-quantique : les banques centrales expérimentent sur l'axe France-Allemagne

Les banques centrales française et allemande tirent un premier bilan de leur projet Leap axé sur la cryptographie post-quantique.

Qu’implique la mise en œuvre de la cryptographie post-quantique dans le système financier ? Le bilan de la première phase du projet Leap apporte des éclairages.

Principaux protagonistes : la Banque de France et son homologue allemande. Elles ont expérimenté la transmission de messages de paiement (format XML ; norme ISO 20022) par l’intermédiaire d’un tunnel IPsec. Celui-ci était hybride : il implémentait un algorithme traditionnel à clé publique en parallèle d’un algorithme post-quantique.

La Banque de France jouait le rôle du serveur, avec une infrastructure sur site de type legacy. Côté Allemagne, on était sur du cloud public avec, entre autres, des technologies d’accélération matérielle (AVX2).

Le VPN mis à contribution était une version de strongSWAN modifiée pour y intégrer une bibliothèque post-quantique conçue par le fournisseur. Cinq algorithmes ont été testés : quatre distingués par le NIST ; un considéré comme une bonne option par l’ANSSI et son homologue allemand.

Projet Leap : vers les couches transport et application

Les deux banques centrales ont exploité plusieurs combinaisons de ces algorithmes, pour l’essentiel au niveau de sécurité maximal (5) tel que défini par le NIST. L’objectif était autant d’assurer la confidentialité des messages échangés que l’intégrité des données, l’authentification et l’anti-rejeu.

Implémenter en mode hybride donne davantage de flexibilité pour basculer entre les algorithmes post-quantiques. Dans la pratique, cela se fait aisément pour l’échange de clés. On ne peut pas en dire autant pour la partie signature : les systèmes ont un degré variable d’« agilité post-quantique ». Des équipements de type HSM, firewall et smart card, en particulier, peuvent représenter des goulets d’étranglement.

Peu importe la taille des messages, il n’y a pas d’impact sur le délai d’envoi, les données étant chiffrées avec un protocole symétrique (AES-256).

Ce qui varie, c’est le délai de mise en place du tunnel – opération qui, en conditions réelles, n’aurait théoriquement lieu qu’une ou deux fois par jour.

Avec certains algorithmes, il y a un écart de performance entre l’infrastructure legacy (illustration ci-dessous) et celle qui bénéficie d’AVX2. Par exemple avec la version AES de FrodoKEM.

Sur la partie signature, Sphincs+ affiche de moins bonnes performances. Mais sa fiabilité le prête, plus que les autres, à une implémentation individuelle, sans algorithme classique en support.

temps de mise en place du VPN client-serveur — IKE : échange de clés asymétriques et authentification CHILD : échange de clés (deuxième étape)

Il y a systématiquement un compromis à faire entre sécurité et performance. Il sera dicté par les besoins de l’application en termes de rapidité de traitement comme de fréquence d’usage des clés publiques et des ciphertexts.

Dans ces conditions, Falcon apparaît mieux adapté que Crystals-Dilithium pour les applications qui stockent un grand nombre de signatures. Crystals-Kyber semble quant à lui plus approprié que Frodo pour répondre à des exigences de haute performance.

Les porteurs du projet Leap projettent une implémentation plus large, sur les couches transport et application. Ils n’en oublient pas la question des ressources humaines : l’expertise dans ces domaines est encore rare…