Exigences de chiffrement du CRA pour les fabricants de produits

Le Cyber Resilience Act (CRA, règlement sur la cyberrésilience, Regulation (EU) 2024/2847) fixe son exigence de chiffrement à l'Annex I, Part I (2)(e) : protéger la confidentialité des données stockées, transmises ou traitées d'une autre manière, par exemple en chiffrant les données pertinentes au repos ou en transit au moyen de mécanismes conformes à l'état de l'art. Il ne nomme aucun algorithme post-quantique. Les obligations de notification prévues à l'Article 14 s'appliquent à partir du 11 septembre 2026 et le règlement s'applique intégralement à partir du 11 décembre 2027 : les équipes produit choisissent donc dès maintenant la cryptographie d'équipements qui seront encore supportés bien après ces dates.

Ce que dit l'exigence, et ce qu'elle ne dit pas

L'Annex I comporte deux parties. La Part I énumère les exigences essentielles de cybersécurité applicables au produit lui-même, notamment sa mise sur le marché sans vulnérabilité exploitable connue, une configuration sécurisée par défaut et l'exigence de confidentialité du point (2)(e). La Part II énumère les exigences de gestion des vulnérabilités qui s'appliquent pendant toute la période de support déclarée par le fabricant. Le texte est disponible sur EUR-Lex (Regulation (EU) 2024/2847) et notre synthèse datée figure sur la page consacrée au règlement CRA.

Il en découle trois conséquences pour une équipe produit :

• L'exigence est formulée en termes de résultat. Elle mentionne la confidentialité et des mécanismes conformes à l'état de l'art, pas RSA, pas ECDH, pas ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, normalisé dans NIST FIPS 203).
• La référence évolue. Un mécanisme défendable lors de l'évaluation de la conformité peut cesser de l'être alors que le produit est encore supporté.
• Rien dans le texte ne vous oblige à livrer de la cryptographie post-quantique aujourd'hui. De même, rien ne sauve une conception dont la cryptographie ne peut plus être modifiée une fois que l'état de l'art évolue.

Des normes harmonisées pourront ultérieurement préciser comment satisfaire à l'Annex I, et la conformité à une norme harmonisée citée au Journal officiel confère une présomption de conformité. Tant qu'une telle norme n'existe pas et n'est pas citée, son contenu est inconnu : ne bâtissez pas votre planification sur des hypothèses quant à ce qu'elle dira de la cryptographie. Le contenu juridique présenté ici est informatif et ne constitue pas un conseil juridique.

Les dates du calendrier du CRA

Pour un équipement dont la période de support s'étend sur plusieurs années, l'horizon de planification n'est pas 2027. C'est la dernière date à laquelle vous devez encore des mises à jour de sécurité pour les unités vendues juste avant la fin du support.

Ce que l'état de l'art peut raisonnablement signifier sur une période de support

Le CRA ne publie aucune liste d'algorithmes. La manière honnête de raisonner sur l'état de l'art consiste donc à examiner ce que les autorités publiques et les organismes de normalisation ont effectivement publié, en conservant le statut de chaque document.

Sources primaires : la feuille de route de l'UE, BSI TR-02102-1, la FAQ PQC de l'ANSSI, NIST IR 8547 ipd et les calendriers de migration du NCSC.

Notre interprétation, présentée explicitement comme telle : aucun de ces textes ne fait de la cryptographie post-quantique une obligation au titre du CRA, et aucune autorité n'a affirmé que la cryptographie classique ne satisfait pas à l'Annex I aujourd'hui. Mais un produit dont la période de support s'étend au-delà de 2030 est vendu pour une période pour laquelle plusieurs autorités ont déjà publié des dates de retrait de l'établissement de clés classique. La position d'ingénierie défendable est donc l'agilité : la capacité à changer d'algorithme par une mise à jour ordinaire, démontrée dans le dossier de conception.

L'agilité cryptographique dans le firmware

L'agilité est une propriété de l'implémentation, pas une phrase dans une politique. Quatre questions déterminent si un équipement déjà livré peut suivre l'état de l'art, et il est plus facile d'y répondre avant le tape-out qu'après. Nous approfondissons le sujet dans l'article sur l'agilité cryptographique.

• La négociation, pas des constantes. Les identifiants d'algorithmes, les groupes nommés et les tailles de clés proviennent de la configuration ou de la négociation du protocole, jamais d'une constante compilée ni d'un tampon de taille fixe. Les clés et chiffrés ML-KEM sont bien plus volumineux que les valeurs sur courbes elliptiques : une structure dimensionnée pour des clés de 32 octets constitue un blocage au niveau matériel.
• De la marge. Prévoyez de la flash, de la RAM et du temps de négociation pour des éléments de clés plus volumineux. Mesurez-les sur la cible, pas sur un poste de travail.
• Une frontière autour de la bibliothèque. Appelez la cryptographie via une interface interne légère, afin de pouvoir remplacer le fournisseur. Fixez la version minimale dans le build : les groupes TLS ML-KEM nécessitent OpenSSL 3.5 ou ultérieur.
• Un repli classique. Privilégiez l'établissement de clés hybride et conservez un groupe classique derrière lui, afin qu'un équipement puisse toujours se connecter lorsque l'extrémité distante est plus ancienne.

Sur un build de test, vérifiez ce que la pile peut effectivement proposer et ce que négocie un point de terminaison de l'équipement :

openssl version
# ML-KEM TLS groups require OpenSSL 3.5 or later
openssl list -tls-groups

# read-only test against a device endpoint, hybrid first, classical fallback
openssl s_client -connect device.example.com:443 -tls1_3 \
  -groups X25519MLKEM768:X25519 </dev/null

Le groupe hybride à privilégier aujourd'hui est X25519MLKEM768 (codepoint IANA 0x11EC), avec SecP256r1MLKEM768 ou SecP384r1MLKEM1024 lorsqu'une courbe NIST est exigée ; le profil IETF pour l'échange de clés hybride post-quantique et traditionnel dans TLS 1.3 est la RFC 10024 (août 2026). Les groupes issus des brouillons Kyber antérieurs à la normalisation, comme X25519Kyber768Draft00, sont obsolètes et devraient être retirés du firmware des équipements. Testez en préproduction avant la production, et conservez le groupe classique dans la liste.

Les plans d'administration des équipements méritent le même examen. OpenSSH 9.9 a ajouté mlkem768x25519-sha256, OpenSSH 10.0 en a fait l'échange de clés par défaut, et OpenSSH 10.1 émet un avertissement lorsqu'une connexion négocie un échange de clés non post-quantique, selon les notes de version d'OpenSSH.

La signature des mises à jour : la partie que vous ne pourrez pas corriger plus tard

Les clés de transport changent à chaque session. Une racine de confiance gravée dans le silicium, non. Le trafic enregistré n'est protégé que par l'échange de clés, c'est pourquoi l'établissement de clés hybride passe en premier, tandis que les signatures peuvent migrer plus tard ; mais la signature des mises à jour est le seul chemin de signature pour lequel une migration tardive peut s'avérer impossible, car le vérificateur réside dans un code de démarrage immuable.

Mesures concrètes, par ordre de valeur :

1. Prévoir plus d'un emplacement de vérification ou d'une hiérarchie de clés, afin qu'un nouvel algorithme de signature puisse être introduit par une mise à jour plutôt que par un rappel.
2. Décider dès maintenant quelle famille de signatures post-quantiques le produit pourrait accepter : ML-DSA (FIPS 204), SLH-DSA (FIPS 205), ou les schémas à base de hachage avec état LMS et XMSS de NIST SP 800-208, qui exigent une gestion d'état rigoureuse pour éviter de réutiliser une clé à usage unique.
3. Conserver le code et les paramètres de vérification des signatures dans un étage modifiable lorsque le modèle de sécurité le permet, l'étage immuable se limitant à vérifier cet étage modifiable.
4. Documenter le renouvellement des clés : qui détient les clés, comment une clé compromise ou dépréciée est retirée, et comment un équipement déployé prend connaissance de la nouvelle.

CNSA 2.0 fixe déjà à fin 2030 l'usage exclusif de ses algorithmes pour la signature des logiciels et des firmwares dans les National Security Systems américains. Ce n'est pas une obligation européenne, mais c'est une date publiée pour le même problème d'ingénierie, et un élément raisonnable à prendre en compte lorsque vous argumentez sur ce que l'état de l'art signifie pour un produit supporté au-delà de 2030.

Relier l'exigence à des éléments de preuve

Prochaine étape : mesurer ce que votre produit expose sur le réseau

Avant d'écrire la moindre ligne de documentation CRA, déterminez ce que vos propres points de terminaison et serveurs de mise à jour négocient réellement aujourd'hui. Vous pouvez analyser votre domaine avec PQC Status gratuitement pour voir les versions de TLS, les groupes hybrides ML-KEM, les suites de chiffrement et la chaîne de certificats qu'observe un client externe. Une analyse décrit uniquement la configuration TLS visible de l'extérieur : ce n'est ni une certification ni une attestation de conformité. Utilisez le résultat comme première ligne de votre inventaire, puis remontez vers le firmware : tailles de clés dans les structures, versions des bibliothèques dans le build et nombre d'emplacements de vérification dans votre chaîne de démarrage.