Une nouvelle attaque contre RSA forge des signatures sans récupérer la clé privée

Des chercheurs sur RSA ont réalisé une falsification de signature de 1024 bits en utilisant 1 380 années-cœur de CPU, sans factoriser le module public ni récupérer sa clé privée.

Ce résultat offre à la nouvelle attaque contre RSA un titre spectaculaire, mais l’algorithme sous-jacent remonte à 2007. La véritable avancée réside dans une implémentation ayant mené la méthode théorique jusqu’à un calcul à grande échelle.

Cette distinction est importante, car l’attaque ne compromet pas tous les déploiements de RSA. Elle cible les systèmes qui fournissent temporairement un accès à des opérations RSA brutes, sans padding. Les signatures modernes utilisant un encodage standardisé restent en dehors du modèle d’attaque démontré.

L’évaluation de l’attaque de Bruce Schneier résume le renversement central. Il s’agit d’un véritable résultat cryptanalytique, mais pas d’une technique universelle permettant d’extraire les clés privées RSA.

Ce qui a réellement changé avec la nouvelle attaque contre RSA

Les chercheurs ont transformé un algorithme de 2007 largement négligé en une falsification de signature de 1024 bits achevée contre une cible de signature réelle.

Laura Shea, Miro Haller, Adam Suhl, Nadia Heninger et Emmanuel Thomé ont implémenté l’attaque dans le cadre d’une collaboration impliquant UC San Diego et Inria. Leur calcul sur 1024 bits s’est achevé le 31 août 2026.

L’équipe a publié son article et le code associé en septembre. Les documents publics décrivent ces travaux comme une falsification de signature réalisée en un temps proche de celui du crible de corps de nombres spécial.

Ce nom renvoie aux performances asymptotiques de l’attaque. Le crible de corps de nombres est une famille d’algorithmes destinée à des calculs complexes de théorie des nombres, notamment la factorisation de grands entiers.

Le crible général de corps de nombres, ou GNFS, est la méthode classique connue la plus rapide pour factoriser des modules RSA ordinaires. Le crible spécial de corps de nombres, ou SNFS, obtient de meilleurs résultats lorsqu’un problème sous-jacent présente une structure algébrique exploitable.

La nouvelle implémentation déplace effectivement une partie de l’attaque vers cette catégorie plus rapide. Elle ne transforme toutefois pas la cryptanalyse de RSA en un problème simple ou résoluble en temps polynomial.

Les chercheurs indiquent que le calcul a consommé 1 380 années-cœur de CPU. Le traitement parallèle a ramené cette charge totale à plusieurs mois de temps écoulé sur un cluster de calcul universitaire.

Cela reste une entreprise considérable. L’équipe estime toutefois que la factorisation du même module de 1024 bits nécessiterait entre 500 000 et un million d’années-cœur de CPU.

Ces estimations ne se traduisent pas directement en un coût financier universel. Le matériel, les logiciels, la mémoire, le réseau et les choix d’implémentation influencent tous les dépenses réelles d’exploitation.

Elles établissent néanmoins le résultat technique central. Dans les conditions d’oracle requises, forger des signatures RSA peut demander beaucoup moins de calcul que factoriser le module associé.

Un oracle est un système qui effectue une opération cryptographique sur une entrée choisie par l’attaquant et renvoie le résultat. Ici, l’attaquant doit disposer temporairement d’un accès à des opérations RSA brutes de signature ou de déchiffrement.

Cet accès n’a pas besoin de rester disponible indéfiniment. Après avoir achevé un vaste précalcul lié à la clé publique, l’attaquant obtient la capacité hors ligne de produire d’autres sorties valides.

Cette persistance rend le résultat plus important qu’un usage abusif ordinaire d’un service de signature. L’attaquant peut conserver sa capacité de falsification après avoir perdu l’accès à l’oracle initial.

L’explication des chercheurs indique que cette capacité ressemble, dans ses effets pratiques, au vol de la clé secrète. Cela ne signifie pas que les véritables facteurs privés ont été récupérés.

Les chercheurs ont également publié leur implémentation et leurs données intermédiaires. Cette transparence permet à d’autres cryptographes de reproduire les hypothèses, d’examiner les décisions d’ingénierie et de tester les contre-mesures proposées.

L’exécution achevée constitue donc l’événement d’actualité. Les mathématiques qui l’ont rendue possible sont publiques depuis près de 19 ans.

Pourquoi un algorithme de 2007 est important aujourd’hui

L’implémentation modifie les estimations de sécurité de RSA dans un modèle d’attaque spécifique, même si elle n’introduit pas de nouveau raccourci mathématique.

Antoine Joux, David Naccache et Emmanuel Thomé ont décrit la technique sous-jacente dans leur article de 2007. Ils ont étudié les cas où calculer certaines racines modulo un nombre RSA devient plus facile que factoriser ce nombre.

En termes simplifiés, RSA applique une exponentiation modulo un nombre composé. Une opération privée calcule une racine qui devrait rester infaisable sans connaissance de la clé secrète.

Les travaux de 2007 ont montré que des réponses d’oracle sélectionnées pouvaient révéler suffisamment de structure pour permettre une attaque plus rapide. Leurs auteurs ont décrit des résultats allant de falsifications sélectives à des capacités de falsification universelle.

Ce résultat n’a jamais impliqué que des attaquants puissent observer passivement une clé publique RSA ordinaire et falsifier immédiatement des signatures. Il exigeait un accès répété à des opérations de clé privée soigneusement structurées.

Jusqu’en 2026, personne n’avait démontré publiquement le processus complet à l’échelle de 1024 bits. Les grands calculs cryptanalytiques exigent davantage qu’une expression de complexité imprimée dans un article.

Les chercheurs doivent élaborer des sélections de polynômes appropriées, collecter des relations, traiter d’énormes ensembles de données, effectuer de l’algèbre linéaire creuse et achever la reconstruction finale. De petites inefficacités peuvent se multiplier sur des mois de travail.

La nouvelle équipe a relié ces étapes et démontré le résultat contre une cible de 1024 bits. Une grande partie de son implémentation s’appuie sur CADO-NFS, une suite logicielle établie pour les calculs par crible de corps de nombres.

Cette différence entre théorie et implémentation est au cœur de la nouvelle attaque contre RSA. L’algorithme était connu, mais ses constantes pratiques et ses exigences d’ingénierie restaient incertaines.

Un calcul achevé transforme ces inconnues en éléments de preuve. Il montre que l’écart de calcul entre falsification et factorisation n’est pas seulement une curiosité asymptotique.

Pour la cible démontrée, les chercheurs estiment le coût de l’attaque à environ 2^65 opérations. Ils comparent ce chiffre à environ 2^80 opérations pour factoriser un module RSA comparable de 1024 bits.

Pour des clés plus grandes, ils estiment environ 2^90 opérations contre RSA à 2048 bits et 2^119 contre RSA à 4096 bits dans le modèle d’oracle vulnérable.

Ces attaques à plus grande échelle n’ont pas été menées à bien. Il s’agit de projections dérivées de l’algorithme, des performances mesurées de l’implémentation et du comportement attendu lors du passage à l’échelle.

Ces projections méritent l’attention, car le niveau de sécurité mesure le travail attendu pour compromettre un système. Le NIST définit un niveau de sécurité de S bits comme environ 2^S opérations élémentaires.

Ces chiffres s’appliquent toutefois à la construction exposée, et non à chaque utilisation d’une clé RSA. L’encodage d’un protocole, les contrôles d’accès, les limites de débit et la durée de vie des clés font toujours partie de sa sécurité effective.

La comparaison doit également être replacée dans son contexte. Un calcul de 2^90 est immensément plus difficile que l’expérience achevée sur 1024 bits, même s’il reste inférieur à une marge théorique souhaitée.

Les chercheurs indiquent qu’il nécessiterait environ 1 000 fois plus de travail qu’un calcul de 2^80. Aucune équipe publique n’a encore achevé la tâche correspondante de factorisation sur 1024 bits.

Le résultat met donc davantage sous pression les modèles de sécurité que les systèmes de production actuels. Les concepteurs ne peuvent plus supposer que la factorisation fournit toujours la meilleure estimation d’attaque pour les opérations RSA brutes.

Cette correction est importante pour les modules matériels de sécurité, les protocoles de signature aveugle et les interfaces spécialisées. Ces systèmes exposent parfois l’opération RSA privée tout en tentant de limiter ce qu’elle peut autoriser.

Si le protocole environnant fournit l’oracle nécessaire, une estimation de longueur de clé fondée uniquement sur GNFS peut surestimer la sécurité. L’implémentation donne aux concepteurs une raison concrète de réviser cette analyse.

La nouvelle attaque contre RSA relève de la falsification, pas de la récupération de clé

L’attaque compromet une capacité de signature dans des conditions d’entrées choisies, mais elle ne déduit pas la clé privée RSA à partir d’informations publiques.

Les clés RSA contiennent un module et un exposant publics, ainsi que des valeurs privées dérivées des facteurs premiers secrets du module. Les attaques conventionnelles par factorisation cherchent à obtenir ces facteurs.

Les récupérer donne à l’attaquant la véritable clé privée. Cette clé peut prendre en charge toute opération autorisée par la construction RSA concernée, sous réserve des détails du protocole.

Cette technique de falsification de signature suit une autre voie. Elle utilise les réponses d’un oracle RSA brut pour préparer des données qui permettent ensuite des calculs de racines.

L’attaquant commence par disposer temporairement d’un accès à un appareil ou à un protocole qui effectue des opérations de clé privée sans padding. Il soumet de nombreuses valeurs spécialement sélectionnées et enregistre les réponses.

Le précalcul recherche ensuite des relations algébriques à l’aide d’une variante du crible de corps de nombres. Une fois suffisamment de relations collectées, l’attaquant peut les combiner pour falsifier des sorties choisies.

L’essentiel du calcul coûteux dépend de la clé publique. Après cette étape, la production de falsifications individuelles devient beaucoup moins coûteuse.

Le résultat peut ressembler au vol d’une clé privée du point de vue d’un défenseur. Une partie non autorisée peut générer des signatures qui se vérifient avec la véritable clé publique.

Le mécanisme et la portée restent néanmoins différents. Le module public n’a pas été factorisé, et l’exposant privé n’a pas nécessairement été reconstruit.

Cette distinction affecte la réponse aux incidents. Le remplacement de la clé concernée empêche les futures vérifications sous cette clé publique, comme après une compromission ordinaire.

Elle affecte également l’évaluation de la vulnérabilité. Un système qui ne possède pas l’interface de signature brute requise ne devient pas vulnérable simplement parce qu’il utilise un certificat RSA.

Décrire ces travaux comme une compromission des « clés RSA » peut brouiller ces limites. Cela peut suggérer une attaque passive qui ne commence qu’avec un certificat ou une clé publique.

L’attaque démontrée exige davantage. Elle nécessite une source interactive de résultats RSA bruts choisis et suffisamment de requêtes avant que cette source disparaisse ou que la clé soit remplacée.

L’article complet des chercheurs présente la contribution comme la falsification de signatures en un temps proche de SNFS. Cette formulation identifie avec précision le résultat comme l’amélioration de complexité.

Elle évite également un autre malentendu courant. Sous-exponentiel ne signifie pas polynomial, instantané ou peu coûteux.

Les algorithmes en temps polynomial évoluent selon une puissance fixe de la taille de leur entrée. Les algorithmes sous-exponentiels croissent plus vite que les algorithmes polynomiaux, mais moins vite que les algorithmes pleinement exponentiels.

SNFS et GNFS appartiennent tous deux à la catégorie sous-exponentielle. L’attaque est plus rapide parce que ses constantes et sa structure sont plus favorables, et non parce qu’elle élimine les calculs difficiles.

L’expérience achevée a utilisé des CPU plutôt que des GPU. Les chercheurs indiquent également ne pas avoir utilisé l’intelligence artificielle pour optimiser leur code.

Ils estiment que les GPU et des travaux d’implémentation supplémentaires peuvent améliorer les performances. Il s’agit d’une direction de recherche raisonnable, mais non d’un résultat mesuré dans cette expérience.

Les affirmations concernant une accélération spectaculaire par GPU restent donc spéculatives. Les charges de travail du crible de corps de nombres comprennent plusieurs étapes, et chacune réagit différemment au matériel spécialisé.

La référence démontrée est de 1 380 années-cœur de CPU pour l’implémentation réellement utilisée par l’équipe. Tout chiffre futur inférieur devra provenir d’un code reproductible et de mesures achevées.

C’est la tension principale de cet article. Ces travaux constituent une remise en cause significative des hypothèses fondées sur la factorisation, mais ils ne constituent pas une méthode générale de récupération de clés RSA.

L’exposition réelle est limitée, mais non nulle

Les signatures RSA ordinaires avec remplissage ne sont pas la cible démontrée, tandis que les interfaces de signature brute méritent un examen immédiat.

Les signatures RSA modernes n'appliquent généralement pas l'exposant privé directement à un message non restreint. Elles encodent d'abord une empreinte de message selon un schéma de signature défini.

RSASSA-PSS ajoute un formatage aléatoire avant l'opération RSA. PKCS #1 v1.5 utilise un encodage déterministe structuré, avec des identifiants et du remplissage.

Ces encodages empêchent un attaquant de choisir des entiers bruts arbitraires à signer. Cette restriction bloque le comportement d'oracle requis par la nouvelle implémentation.

L'équipe de recherche indique que son attaque ne semble pas réalisable contre les signatures RSA courantes utilisant PSS ou PKCS #1 v1.5. Schneier aboutit à la même conclusion pratique.

Cela signifie que les certificats conventionnels, les signatures d'authentification TLS, les logiciels signés et les jetons ne sont pas automatiquement exposés. Les administrateurs doivent vérifier l'algorithme et l'interface réellement utilisés avant de tirer des conclusions.

La longueur de clé seule ne répond pas à la question de la vulnérabilité. Une clé de 2 048 bits derrière une API de signature brute présente une exposition différente de celle de la même clé limitée à des signatures PSS validées.

Les candidats les plus évidents à l'examen sont les interfaces de modules matériels de sécurité qui autorisent des opérations brutes avec la clé privée. Les applications demandent parfois un tel accès pour mettre en œuvre des protocoles personnalisés hors du module.

Cette flexibilité peut affaiblir la frontière que le module était censé fournir. La clé privée ne quitte jamais l'appareil, mais l'opération disponible peut devenir un oracle de signature.

Les signatures aveugles exigent une analyse plus poussée, car leur objectif consiste à signer un contenu caché au signataire. Un client transforme son message, obtient une signature, puis retire le facteur d'aveuglement.

Cette conception prend en charge l'authentification respectueuse de la vie privée et les applications de monnaie numérique. Elle crée aussi une interface dans laquelle le client influence la valeur traitée par la clé privée.

Les protocoles RSA aveugles modernes ajoutent des exigences d'encodage et de vérification. La norme de signature aveugle actuelle utilise l'encodage RSA-PSS autour du message préparé par le client.

Toutefois, le serveur de signature effectue toujours une opération RSA privée sur un représentant aveuglé. Le nouvel article analyse comment de telles interfaces peuvent exposer l'oracle brut nécessaire lors de l'émission.

Privacy Pass est un cas d'usage fréquemment cité. Il permet à un client d'obtenir des jetons anonymes que les services peuvent vérifier sans relier leur émission à leur utilisation ultérieure.

Apple et Cloudflare ont utilisé des technologies liées à Privacy Pass dans des services de confidentialité et des systèmes de contournement de défis. Cela ne prouve pas que chaque déploiement est exploitable.

Une attaque réussie contre un service en production nécessiterait la bonne construction, une clé publique stable et un nombre suffisant de requêtes d'oracle acceptées. Les contrôles opérationnels peuvent modifier le calcul.

Les chercheurs estiment que l'attaque d'une clé RSA aveugle de 2 048 bits nécessite environ 2^43 requêtes d'oracle, en plus d'un calcul hors ligne bien plus important.

Ce nombre de requêtes dépasse huit mille milliards. Il est énorme pour un utilisateur individuel, bien que de grands services distribués traitent du trafic à des échelles agrégées comparables.

La limitation du débit peut restreindre les requêtes liées à un compte, un appareil, un réseau ou un identifiant. La détection des abus peut également repérer des schémas d'émission inhabituellement répétitifs.

La rotation des clés réduit la fenêtre de collecte disponible. Si un service remplace sa clé RSA avant qu'un attaquant ait obtenu suffisamment de réponses, les requêtes antérieures ne peuvent pas simplement être transférées vers la nouvelle clé.

Des périodes de validité de clé plus courtes augmentent donc les coûts opérationnels pour l'attaquant. Elles ne modifient pas les mathématiques et ne remplacent pas entièrement une défense au niveau du protocole.

Les chercheurs suggèrent que les preuves à divulgation nulle de connaissance pourraient fournir une réponse plus robuste à moyen terme. Ces preuves peuvent contraindre les entrées du client sans révéler le message caché.

Des clés RSA plus longues augmentent également le coût des attaques, mais l'article met en doute leurs marges de sécurité dans ce modèle d'oracle. Les auteurs estiment une sécurité inférieure à 128 bits, même avec 4 096 bits.

Cela ne signifie pas que les attaquants peuvent désormais forger des signatures de 4 096 bits. L'estimation de 2^119 reste très au-delà du calcul achevé sur 1 024 bits.

Cela signifie toutefois que les concepteurs de protocoles ne devraient pas considérer des clés plus longues comme la seule réponse à long terme. Une interface vulnérable peut conserver le même problème structurel à un coût plus élevé.

Pour la plupart des organisations, la bonne réponse est un inventaire plutôt qu'un arrêt d'urgence. Les équipes de sécurité doivent localiser les clés RSA et identifier chaque opération autorisée avec une clé privée.

Elles doivent distinguer le chiffrement, les signatures conventionnelles, les signatures aveugles, l'émission de certificats, la signature de jetons et les appels HSM personnalisés. Chaque voie présente une surface d'attaque différente.

Les équipes doivent confirmer que les applications demandent des mécanismes de signature nommés plutôt qu'une exponentiation modulaire générique. Elles doivent également rejeter les encodages malformés avant d'accepter des objets signés.

Les recommandations actuelles de NIST sur la gestion des clés considèrent déjà RSA à 1 024 bits comme obsolète pour les exigences de protection modernes. Cette expérience ajoute une raison supplémentaire d'éliminer les déploiements persistants.

Un service de signature brute RSA à 1 024 bits exige une correction urgente. Un déploiement PSS standard à 2 048 bits ne présente pas le même constat immédiat, même si une planification de migration plus large reste importante.

Ce que les défenseurs doivent surveiller ensuite

Les trois prochains signaux sont la reproduction indépendante, l'analyse propre aux protocoles et des changements mesurables dans les implémentations réelles.

Premièrement, les cryptographes doivent reproduire indépendamment le calcul de 1 024 bits et examiner les estimations de mise à l'échelle de l'article. La reproduction peut vérifier si le coût annoncé inclut chaque étape importante.

Elle peut aussi révéler des goulots d'étranglement d'implémentation qui renforcent ou affaiblissent les projections. Un coût reproductible plus faible accroîtrait les inquiétudes concernant les interfaces de signature brute exposées.

Un coût sensiblement plus élevé n'effacerait pas le résultat conceptuel. Il réduirait la menace opérationnelle et rendrait les estimations pour les clés plus longues moins urgentes.

Deuxièmement, les organismes de normalisation et les concepteurs de protocoles devraient publier des analyses des constructions RSA aveugles. Les affirmations génériques sur le « remplissage » sont insuffisantes lorsque l'aveuglement modifie ce que traite le signataire.

La question importante est de savoir si un protocole concret donne aux attaquants les réponses d'oracle présumées par l'article. L'authentification des requêtes et la rotation des clés doivent faire partie de cette évaluation.

Les déploiements Privacy Pass méritent une attention particulière car ils combinent des objectifs de confidentialité, l'émission répétée de jetons et des clients largement distribués. Les examens publics de conception peuvent distinguer l'exposition théorique des attaques réellement accessibles.

Une révision du protocole imposant des preuves d'entrée plus solides renforcerait l'avertissement des chercheurs. Une preuve convaincante que les déploiements courants refusent l'oracle requis réduirait la portée pratique du résultat.

Troisièmement, les défenseurs doivent surveiller les fournisseurs de HSM et les bibliothèques cryptographiques. La documentation, les valeurs par défaut des API, les règles d'audit et les avis de dépréciation révèlent comment le secteur interprète cette conclusion.

Un HSM peut protéger le matériel de clé tout en exposant une opération dangereuse. Les fournisseurs peuvent restreindre les appels RSA bruts, ajouter des contrôles sur les requêtes ou recommander des interfaces propres à un mécanisme.

Les mainteneurs de bibliothèques peuvent également renforcer les API de bas niveau. Déprécier l'exponentiation brute avec l'exposant privé réduirait le risque que les développeurs construisent accidentellement un oracle de signature exposé.

Aucun de ces signaux n'exige d'abandonner immédiatement tous les certificats RSA. L'attaque démontrée n'atteint pas les signatures normalisées avec remplissage par observation passive.

RSA fait toujours face à un problème distinct à long terme lié aux ordinateurs quantiques cryptographiquement pertinents. Les programmes de migration post-quantique offrent déjà aux organisations l'occasion de réduire leur dépendance aux algorithmes hérités.

NIST a normalisé ses premiers algorithmes de signature post-quantiques en 2024. La migration prendra néanmoins des années, car les certificats, le matériel, les protocoles et les outils opérationnels doivent évoluer ensemble.

La nouvelle attaque soutient la planification de l'agilité cryptographique, c'est-à-dire la capacité des systèmes à remplacer des algorithmes sans refondre un produit entier. Elle ne justifie pas de négliger les tests de compatibilité ni de modifier en urgence des systèmes non affectés.

Les responsables de la sécurité devraient dès maintenant poser quatre questions concrètes. Des services utilisent-ils encore RSA à 1 024 bits, exposent-ils des opérations brutes avec clé privée, mettent-ils en œuvre RSA aveugle ou conservent-ils une même clé pendant des périodes inhabituellement longues ?

Un « oui » devrait déclencher un examen du protocole, une analyse des journaux et un calendrier de migration. Il ne devrait pas entraîner l'affirmation non étayée que la clé privée a déjà été extraite.

La nouvelle attaque contre RSA est importante car elle remplace un ancien avertissement théorique par un calcul achevé. Sa limite pratique est tout aussi importante.

Considérez ce résultat comme un test des hypothèses cryptographiques et de la conception des interfaces. Vérifiez quelles opérations vos systèmes exposent, puis suivez les reproductions et les conclusions propres aux protocoles avant de décider de la réponse.