Sécuriser l’embarqué face au quantique : Mise en œuvre avec Yocto

Cet article fait suite à celui [1] du mainteneur de la cryptographie de Go, Filippo Valsorda (6 avril 2026), là où il exprime son inquiétude sur le niveau de sécurité cryptographique des systèmes actuels, très loin d’égaler les récentes avancées sur l’ordinateur quantique.

Un ordinateur quantique ? Déjà ?

Les estimations les plus pessimistes (ou optimistes) indiquaient l’arrivée d’un ordinateur quantique viable au cours des 10 à 15 prochaines années [2]. Dans son article, Filippo cite deux articles scientifiques récents [3] [4] qui pourraient rapprocher cette date fatidique.

Certains d’entre vous ont probablement connu le bug de l’an 2000 (aussi appelé Y2K) et vous avez peut-être déjà entendu parler du bug de l’an 2038 [5]. La date d’arrivée de l’ordinateur quantique porte elle aussi un nom : le Q-Day (ou Y2Q en référence à Y2K). À la différence des deux autres, il est difficile de prédire cette date.
 

Mais quelle est cette menace ?

Pour comprendre les conséquences de l’avènement d’une telle technologie, commençons par rappeler les enjeux de la cryptographie. La cryptographie est un élément central et indispensable pour la sécurité des communications modernes en garantissant la confidentialité, l’authentification et l'intégrité des données, entre autres.

La cryptographie sécurise les transactions bancaires, les transferts de crypto-monnaies,  les communications privées ou encore valide l'identité d’entités (utilisateurs, serveurs, etc…). Sans la cryptographie, aucun échange de données sur Internet ne saurait être considéré comme fiable et/ou confidentiel.

Ce qu’on appelle communément l’ordinateur quantique vient remettre en question ce socle de sécurité et la réalisation d’une telle machine signe l'obsolescence des systèmes cryptographiques actuels. En effet, des algorithmes comme RSA [6] ou ECC [7], considérés comme la colonne vertébrale de l’économie moderne, sont cassés par l’algorithme de Shor [8] (1994). Dans une moindre mesure, l’algorithme de Grover [9] (1996) réduit le niveau de sécurité des systèmes symétriques comme AES [10].

L’algorithme de Shor résout les problèmes mathématiques sous-jacents aux algorithmes cryptographiques classiques en temps polynomial, ce qui est impossible avec un ordinateur classique. Mais cet algorithme nécessite un matériel suffisamment sophistiqué n’étant pas encore disponible. Ce qui inquiète ici est le “pas encore”.

Durant la rédaction de cet article, Filippo Valsorda a sorti un autre article [11] à ce sujet intitulé : Quantum Computers Are Not a Threat to 128-bit Symmetric Keys, où il explique que contrairement à une idée reçue, les clés symétriques de 128 bits (standard actuel) restent sûres face aux ordinateurs quantiques, car l'algorithme de Grover perd son efficacité dès qu'on tente de le paralléliser pour une attaque réelle. Les experts et les organismes comme le NIST confirment qu'il est inutile de doubler la taille de ces clés, contrairement aux primitives asymétriques (RSA, ECDSA [12]) qui doivent être remplacées d'urgence.

Ceci étant dit, on peut penser que le quantique est un problème appartenant au futur, mais les avancées récentes montrent que ce futur se rapproche à grand pas. En vérité, c’est un problème qui nécessite de réagir immédiatement et pour cause : le Harvest Now, Decrypt Later [13]. Le concept de Harvest Now, Decrypt Later décrit une stratégie où des attaquants collectent (dès maintenant et depuis longtemps) des données chiffrées avec des techniques classiques (Harvest Now) dans l'attente de pouvoir les déchiffrer ultérieurement (Decrypt Later) grâce à un ordinateur quantique.

Toute donnée générée aujourd’hui et devant rester confidentielle jusqu’après l’arrivée de ce dernier est considérée compromise.
 

Comment réagir ?

La cryptographie post-quantique (ou PQC pour Post Quantum Cryptography), c’est l’ensemble des mécanismes et algorithmes réputés résistants à l’adversaire quantique. Il est important de noter qu’il s’agit uniquement d’algorithmes fonctionnant sur des ordinateurs et puces classiques.

Le NIST [14], l’agence états-unienne des normes et de la technologie, a publié courant 2024 les premiers standards officiels de PQC. Les algorithmes retenus sont ML-KEM (Kyber) [15] pour l’échange de clés ainsi que ML-DSA (CRYSTALS-Dilithium) [16] et SLH-DSA (SPHINCS+) [17] pour la signature. Ces standards fournissent une base de confiance agrémentée de preuves pour ces algorithmes, afin d'effectuer la transition vers la PQC sereinement.

Les primitives cryptographiques classiques (courbes elliptiques, logarithme discret, …) étant obsolètes, ces nouveaux algorithmes se basent sur les familles suivantes :

• Module Lattice (ML) : un réseau de points dont les coordonnées sont des polynômes plutôt que de simples nombres. Cette structure permet de représenter des réseaux de grande dimension de manière très compacte en remplaçant les opérations matricielles lourdes par des multiplications polynomiales plus efficaces.
• Stateless Hashing (SLH) : produit une signature en utilisant des schémas à usage unique organisés dans une immense structure d'arbres. Chaque message est signé par une feuille choisie de manière pseudo-aléatoire via une fonction de hachage, rendant la gestion d'un compteur inutile car la probabilité de réutiliser la même feuille est quasi nulle.

Nous le verrons plus tard, mais effectuer la transition vers de nouveaux algorithmes possède de nombreuses contraintes. De ce fait, les agences nationales telles que le NIST ou son analogue français l'ANSSI [18] recommandent depuis quelques années de débuter la transition au plus vite, en préconisant une phase d’hybridation. La définition donnée par l’ANSSI est la suivante :

L'hybridation consiste à combiner des algorithmes de cryptographie asymétrique post-quantique avec des algorithmes de cryptographie asymétrique pré-quantique bien connus et bien étudiés, à des fins de non-régression.

Dans la pratique, cela consiste à utiliser des certificats contenant une clé classique et une clé post-quantique. Ainsi, les systèmes non compatibles avec la PQC disposent d’un fallback, d’autre part les systèmes compatibles peuvent d’ores et déjà proposer un niveau de sécurité résistant au quantique. Cela permet une adaptation progressive sans jamais causer de régression.

Par exemple, l’effort de transition a été débuté en mars 2019 pour TLS1.3 et est mis à jour via ce draft [19]. OpenSSL a intégré x25519MLKEM768 comme premier groupe hybride nativement supporté, il est déjà utilisé par Google Chrome et Cloudflare.

Le bénéfice de l'hybridation doit encore être évalué : les tableaux ci-dessous montrent que la PQC impose déjà une forte augmentation de la taille des données, qui s'accentue davantage lors de cette phase de transition.

Quelles différences avec la cryptographie classique ?

Pour évaluer et comparer des systèmes cryptographiques, on utilise plusieurs métriques :

• Taille des clés (publiques/privées)
• Taille des objets (signature/chiffré)
• Temps d’exécution (signature/vérification)
• Niveau de sécurité

Le niveau de sécurité est l’unité de mesure de la robustesse d’un algorithme cryptographique. On considère qu'un système offre un niveau de sécurité de N bits lorsque l'attaque la plus performante connue nécessite une complexité de calcul de 2^N opérations.
Les catégories proposées par le NIST unifient les exigences de sécurité pré et post-quantiques en indexant la robustesse des algorithmes sur la difficulté de casser les standards actuels :

• Catégorie 1 : Doit résister à des attaques au moins aussi difficiles que de casser AES-128 par recherche de clé exhaustive. Cela équivaut à environ 128 bits de sécurité.
• Catégorie 2 : Doit résister à des attaques au moins aussi difficiles que de trouver une collision dans SHA-256, autrement dit que de trouver deux entrées différentes avec le même haché. Cela équivaut également à 128 bits de sécurité mais avec un problème différent (collisions au lieu de recherche de clé).
• Catégorie 3 : Doit résister à des attaques au moins aussi difficiles que de casser AES-192 par recherche de clé exhaustive. Cela équivaut à environ 192 bits de sécurité.
• Catégorie 4 : Doit résister à des attaques au moins aussi difficiles que de trouver une collision dans SHA-384. Cela équivaut également à 192 bits de sécurité.
• Catégorie 5 : Doit résister à des attaques au moins aussi difficiles que de casser AES-256 par recherche de clé exhaustive. Cela équivaut à environ 256 bits de sécurité.
  Dans le cadre des systèmes embarqués où les ressources sont contraintes, connaître le nouvel ordre de grandeur de ces métriques est crucial.
   

Algorithmes de signature

Le but d'un algorithme de signature est de garantir et l'intégrité et l'authentification d'un message.

Comparons les différences de volume de données entre les algorithmes de signatures ECDSA, RSA, ML-DSA et SLH-DSA (se déclinant en 2 variantes : f (fast) optimisée en termes de cycles CPU et s (small) optimisée en termes d’empreinte mémoire).

Dans le tableau suivant, seuls les algorithmes de Catégorie 1 sont étudiés.

Ce graphique analyse l'impact des algorithmes de signature sur le volume de données en fonction de leur catégorie de sécurité. L'axe horizontal représente la catégorie de sécurité (de 1 à 5), tandis que l'axe vertical, en échelle logarithmique, mesure la taille cumulée de la clé publique et de la signature en octets. On observe une hiérarchie très marquée : les solutions classiques comme ECDSA et RSA sont les plus économes, avec une empreinte située entre 100 et 1 000 octets. À l'opposé, les standards post-quantiques imposent une surcharge massive : ML-DSA multiplie par dix la taille des données par rapport au RSA, tandis que SLH-DSA dépassant les 40 000 octets pour les niveaux de sécurité les plus élevés.

Échange de clés

Il existe deux types de mécanismes d’établissement de secret partagé : l’échange ou l’encapsulation de clé (KEM), qui devient la norme avec la cryptographie post-quantique. Le but est de transmettre une clé symétrique via un canal non sécurisé sans qu’un tiers ne puisse l’avoir. 
 

Comparons la quantité de données transférée entre un échange Diffie-Hellman traditionnel et sur courbes elliptiques, ML-KEM et un groupe hybride. Lors d’un échange Diffie-Hellman traditionnel, les paramètres nécessitent d’être transmis, causant un transfert supplémentaire. De nos jours, DH sur courbes elliptiques est préféré.

Ce graphique compare l'impact des différents algorithmes d’échange/encapsulation de clé sur le volume de données en fonction de la catégorie de sécurité. L'axe des abscisses (horizontal) représente la catégorie de sécurité (de 1 à 5), tandis que l'axe des ordonnées (vertical), présenté en échelle logarithmique, mesure la taille cumulée de la clé publique et du texte chiffré en octets. On observe une rupture nette entre la cryptographie classique (ECDH P-256), très compacte avec moins de 100 octets, et les solutions hybrides et post-quantiques dont l'empreinte est nettement plus lourde.

Comme nous l’avons vu, les algorithmes PQC introduisent une forte augmentation du volume de données. En plus de nécessiter d’avoir des espaces de stockage plus grands, des conséquences sont à prévoir quant aux échanges de ces données. Elles ont été étudiées dans cet article [20], dont les conclusions sont résumées ci-dessous.

L’augmentation du trafic pourrait avoir comme conséquence la fragmentation des paquets ou des temps plus longs pour effectuer des transactions. Si l’impact sur des réseaux stables et à haut débit demeure faible avec des temps de transaction 5 à 15 % plus long, qu’en est t-il dans un environnement embarqué ?
Lors de simulations d’un réseau instable et de mauvaise qualité, l'ajout d'un KEM PQC et d'une signature a pu ralentir le handshake TLS 1.3 d'environ 32% et les handshakes PQC étaient 6 à 8 fois plus lents dans un canal 5G avec pertes que dans un canal sans perte.

Certains protocoles de transmission très utilisés en embarqué ne sont pas du tout adaptés à des transmissions si lourdes, par exemple LoRaWAN, les réseaux 6TiSCH, Sigfox ou NB-IoT. Ces protocoles dont les contraintes sont sévères ne sont pas conçus pour gérer de telles charges. De manière générale, les temps de transmission sont plus longs et causent inévitablement une plus grande consommation d’énergie.
 

Temps d’exécution

Le CPU n’est pas en reste durant l’usage d’algorithmes PQC. Si les schémas peuvent être optimisés sur du matériel haute performance, ce n’est pas le cas pour les microcontrôleurs ou du matériel ancien. Les limitations de ces derniers pourraient amener des difficultés à stocker de plus grosses clés, comme vu au-dessus ou effectuer les opérations nécessaires comme ci-dessous. Les données de cette section proviennent de cette source [21], les tests ont été réalisés sur un Dell XPS 15 sous Windows 11.

Les algorithmes de signature post-quantiques nécessitent un temps d'exécution systématiquement supérieur aux algorithmes classiques.

Contrairement aux algorithmes de signature, les algorithmes d'encapsulation de clé post-quantiques proposent des temps d'exécution plus faibles que les algorithmes classiques.

Yocto et PQC

L’usage de la cryptographie en intégration embarquée est multiple :

• Chiffrement de données stockées (Confidentialité)
• Authentification/chiffrement d’échanges avec backend (Authentification/Confidentialité)
• Implémentation de Secure Boot (Intégrité/Confidentialité)
• Signature de mises à jour de paquets (Intégrité)

L'enjeu de la PQC est d'autant plus critique pour les systèmes embarqués que leur durée de vie est souvent très longue, imposant d'anticiper dès aujourd'hui la menace quantique. Le matériel actuel doit être dimensionné pour supporter la charge de données (réseau et stockage), sous peine de rendre les équipements déployés impossibles à sécuriser à l'avenir. Sans un matériel capable de générer et traiter ces clés volumineuses, les données stockées aujourd'hui seront vulnérables dès l'avènement de l'ordinateur quantique.

Dans ce cas, qu’est il possible de faire dès maintenant et comment ?

Il est d’ores et déjà possible de manipuler la cryptographie post-quantique avec Yocto master et Scarthgap, sous réserve d’utiliser OpenSSL pour cela.

OpenSSL supporte nativement les trois algorithmes post-quantiques standards depuis la version 3.5.0. Yocto exploite des versions supérieures, permettant ainsi un support natif de la PQC. Il existe aussi deux layers proposant le provider nécessaire : meta-pqc et meta-quantum-safe.
Malheureusement, python-cryptography ne supporte pas encore la PQC,  bien qu’il soit basé sur OpenSSL.

Secure boot

Il est possible d’utiliser la cryptographie post-quantique pour les composantes logicielles d’un Secure Boot. Cependant, il n’existe encore aucune racine de confiance hardware car aucun composant matériel post-quantique n’est encore disponible.
J’ai tout de même trouvé un article [22] proposant des choix d'algorithmes et d'implémentations permettant une bootchain Secure Boot full PQC. Cela reste une preuve de concept sans pour l’instant d’implémentation réelle.

Signature des MàJ

La signature de package de mise à jour quant à elle est déjà possible comme nous allons le voir dans la démonstration suivante.

Détaillons la procédure de signature/vérification d’un fichier, avec un algorithme classique (RSA) et un algorithme post-quantique (ML-DSA) de même catégorie de sécurité. Les commandes seront effectuées en parallèle pour démontrer la similarité. La démo a été réalisée sur Qemu avec l’image core-image-full-cmdline en version Scarthgap.

On commence par créer le fichier que l’on veut signer. On prend un simple message texte pour  cet exemple mais la procédure serait la même pour une image, un binaire, un document important, etc ...

echo "Ceci est un message critique pour mon système embarqué." > message.txt

On génère une clé privée RSA-4096 nommée legacy_private.key et une clé ML-DSA-44 nommée pqc_private.key :

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 \
-out legacy_private.key

openssl genpkey -algorithm ML-DSA-44 \
-out pqc_private.key

On extrait les clés publiques legacy_public.key et pqc_public.key associée à chaque clé privée :

openssl pkey -in legacy_private.key \
-pubout -out legacy_public.key

openssl pkey -in pqc_private.key \
-pubout -out pqc_public.key

On produit les signatures message_legacy.sig et message_pqc.sig du message avec chaque clé privée : [23]

openssl pkeyutl -sign -in message.txt \
-inkey legacy_private.key \
-out message_legacy.sig
-rawin -digest sha256

openssl pkeyutl -sign -in message.txt \
-inkey pqc_private.key \
-out message_pqc.sig

On vérifie les signatures du message à l’aide des clés publiques : [23]

openssl pkeyutl -verify -in message.txt \
-pubin -inkey legacy_public.key \
-sigfile message_legacy.sig \
-rawin -digest sha256 
Signature Verified Successfully

openssl pkeyutl -verify -in message.txt \
-pubin -inkey pqc_public.key \
-sigfile message_pqc.sig
Signature Verified Successfully

On peut aussi regarder la taille des signatures ainsi que des clés :

ls -lh
-rw------- 1 root root 3.2K Apr 30 12:04 legacy_private.key
-rw-r--r-- 1 root root  800 Apr 30 12:04 legacy_public.key 
-rw-r--r-- 1 root root   58 Apr 30 12:04 message.txt
-rw-r--r-- 1 root root  512 Apr 30 12:04 message_legacy.sig
-rw-r--r-- 1 root root 2.4K Apr 30 12:04 message_pqc.sig
-rw------- 1 root root 3.6K Apr 30 12:04 pqc_private.key
-rw-r--r-- 1 root root 1.9K Apr 30 12:04 pqc_public_key

On remarque que les objets associés à ML-DSA sont systématiquement plus gros que ceux de RSA.

On va maintenant altérer le message, la vérification devrait échouer : [23]

echo "Message falsifié." > message.txt

$ openssl pkeyutl -verify -in message.txt \
-pubin -inkey legacy_public.key \
-sigfile message_legacy.sig \
-rawin -digest sha256
Signature Verification Failure

$ openssl pkeyutl -verify -in message.txt \
-pubin -inkey pqc_public.key \
-sigfile message_pqc.sig
Signature Verification Failure

La signature est effectivement incorrecte et la vérification échoue. On a démontré que l’on pouvait vérifier cryptographiquement l’intégrité d’un fichier à la fois par un algorithme classique et un algorithme post-quantique et ce avec une procédure identique.

Conclusion

La cryptographie est bien ancrée dans les systèmes actuels et pour cause, l’adoption massive des algorithmes encore utilisés aujourd’hui a débuté il y a plus de 20 ans. Aujourd’hui, ces standards sont menacés et une phase de transition est nécessaire et comme nous l’avons vu, a déjà débuté. Les premiers algorithmes sont déjà disponibles, OpenSSL est le premier à proposer leur implémentation qui ne change rien à son utilisation classique.

La charge de travail quant à cette transition (déjà bien amorcée) concerne plus les cryptographes et les concepteurs matériel que les développeurs logiciel ou les intégrateurs. Notre rôle est de prendre conscience de ce bouleversement, de s’informer à ce sujet afin d’y être sensibilisé et/ou de pouvoir accompagner ces changements.

Références

[1] : https://words.filippo.io/crqc-timeline/

[2] : https://globalriskinstitute.org/publication/quantum-threat-timeline-report-2025b/

[3] : https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/

[4] : https://arxiv.org/abs/2603.28627

[5] : https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038 

[6] : https://fr.wikipedia.org/wiki/Chiffrement_RSA

[7] : https://fr.wikipedia.org/wiki/Elliptic-curve_cryptography

[8] : https://fr.wikipedia.org/wiki/Algorithme_de_Shor 

[9] : https://fr.wikipedia.org/wiki/Algorithme_de_Grover

[10] : https://fr.wikipedia.org/wiki/Advanced_Encryption_Standard

[11] : https://words.filippo.io/128-bits/

[12] : https://fr.wikipedia.org/wiki/Elliptic_curve_digital_signature_algorithm

[13] : https://www.paloaltonetworks.com/cyberpedia/harvest-now-decrypt-later-hndl

[14] : https://fr.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology

[15] : https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf 

[16] : https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf 

[17] : https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf 

[18] : https://fr.wikipedia.org/wiki/Agence_nationale_de_la_s%C3%A9curit%C3%A9_des_syst%C3%A8mes_d%27information

[19] : https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/16/ 

[20] : https://postquantum.com/post-quantum/pqc-network-impacts/ 

[21] : https://www.cryptomathic.com/blog/quantum-ready-cryptography-with-openssl-3.5-on-rhel-9.6 

[22] : https://eprint.iacr.org/2022/1198.pdf

[23] : L’instruction -rawin -digest sha256 produit le haché du message avant de le signer avec l’algorithme de signature. Cela est nécessaire avec RSA, qui ne permet de signer que des messages de tailles égales ou inférieures à la taille de la clé, en l'occurrence 4096 bits.