0,5 % en 2012, 0,003 % en 2026 : ce que 31 millions de modules RSA nous ont appris
En 2012, Heninger et al. publiaient Mining Your Ps and Qs : 0,5 % des modules RSA visibles dans la PKI Web étaient factorisables par un simple batch GCD. Quatorze ans plus tard, on a rejoué l'exercice — plus large, plus profond, avec quatre détecteurs — sur 44,6 millions de certificats. Le résultat sur les modules RSA scannés : 836 clés faibles, soit 0,003 %. Un facteur ~150× d'amélioration sur le crypto pur.
Pourtant, 891 clés vulnérables vivent dans le scan TLS actif aujourd'hui. La PKI commerciale moderne est solide. La longue traîne, elle, ne l'est pas. Voici comment on a mesuré l'un et l'autre.
Notre équipe Research a conduit, entre février et avril 2026, une campagne d'audit cryptographique de la PKI publique. L'objectif : déterminer si les attaques cryptanalytiques classiques — RNG cassé, biais de nonce ECDSA, erreurs d'émission de CA, défauts de génération de modules — ont toujours prise sur les certificats qu'émettent les autorités commerciales modernes.
Quatre mois plus tard, le verdict est en deux temps. Sur la portion visible via Certificate Transparency — toutes ces CAs commerciales que tout le monde connaît : Let's Encrypt, Sectigo, DigiCert, Google Trust Services, Cloudflare, Microsoft Azure, Amazon Trust… — les quatre détecteurs produisent zéro résultat positif. La crypto y est propre. Heninger 2012 → corrigé.
Sur la longue traîne — équipements embarqués, plans de gestion d'appliances, CPE résidentiels, contrôleurs industriels — il en va autrement. Mais c'est l'objet d'un livre blanc complet sous embargo coordonné jusqu'au 25 juillet 2026. Ce billet, lui, parle de la méthodologie : ce qu'on a regardé, comment, et pourquoi.
Le corpus : 44,6 millions de certificats X.509
Le corpus a été construit à partir de deux sources distinctes par construction.
Certificate Transparency — moissonnage de dix logs publics : Google Xenon et Argon, Cloudflare Nimbus, DigiCert Wyvern et Sphinx, Sectigo Elephant et Tiger, TrustAsia 2026a et 2026b. 33,6 millions de certificats, exhaustifs sur le parc commercial moderne. CT est la source la plus propre pour ce qu'on cherche : tout certificat signé par une CA membre de la racine de confiance Web doit être journalisé, donc on a une vue complète et signée.
Scan TLS courtois — 24 ports IoT et SCADA-pertinents sur l'espace IPv4 public, à un rythme de 10 à 20 connexions par seconde par port. 11 millions de certificats complémentaires, ciblant la longue traîne : équipements embarqués, consoles d'administration d'appliances, contrôleurs industriels, CPE résidentiels. Ce parc n'est jamais signé par une CA publique, donc invisible à CT. Sans le scan actif, on rate la moitié de l'histoire.
Total dédoublonné côté analyse cryptanalytique : 24,9 millions de modules RSA uniques, environ 19,8 millions de points publics ECC distincts. Le scan est continu : le tableau de bord public audit.zetacert.com indexe en temps réel, et le corpus s'enrichit entre deux campagnes.
À l'instant du gel pour analyse, la distribution est dominée par RSA-2048 (86 %), avec une présence marginale de RSA-3072 (0,7 %) et 13 % de RSA-4096 — conforme CA/B Forum BR, avec une migration timide vers les tailles CNSA 2.0. Côté ECC, 89 % en P-256, 11 % en P-384, et une poignée en P-521 (44 certificats). Et puis les outliers : 836 modules RSA sous la frontière <1024 ou strictement 1024 — soit 0,003 % du corpus RSA. Le facteur Heninger 2012 (0,5 %) divisé par ~170.
Note éthique sur le scan TLS actif
Le scan se limite à la lecture du certificat publiquement présenté à toute connexion TLS — c'est la même information qu'expose tout client web qui visite un site. Aucune tentative d'authentification, aucune exploitation, aucun scraping derrière une authentification. Le rythme de 10-20 conn/s/port est volontairement bas pour ne pas peser sur les équipements scannés.
Méthodologiquement, c'est la même approche que Censys, Shodan ou Rapid7 Project Sonar — des outils académiques et industriels publiquement utilisés depuis dix ans.
Quatre détecteurs cryptanalytiques
Chaque détecteur cible une classe spécifique de défaillance cryptographique. Aucun n'est une invention interne : tous sont des constructions canoniques de la littérature académique. L'objectif est la reproductibilité — n'importe qui doit pouvoir rejouer le pipeline sur le même corpus et obtenir le même résultat.
Détecteur 1 — Batch GCD (Bernstein 2004 / Heninger 2012)
Le principe est simple : si deux modules RSA n₁ = p × q₁ et n₂ = p × q₂ partagent un facteur premier p, alors gcd(n₁, n₂) = p et les deux clés sont factorisées.
Le batch GCD est l'algorithme qui calcule cette opération en O(N log² N) pour tout le corpus — pas en O(N²) comme on pourrait le craindre naïvement. Bernstein 2004 a publié la construction ; Heninger et al. l'ont déployée à grande échelle dans Mining Your Ps and Qs en 2012 et ont trouvé que 0,5 % des modules RSA visibles dans la PKI Web étaient factorisables ainsi. Le pattern racine : des routeurs SOHO et appareils embarqués qui amorçaient leur RNG à partir de sources de faible entropie au premier démarrage, produisant des clés statistiquement non indépendantes.
Exécution 2026 : 6,6 millions de modules RSA dédoublonnés, ~7 heures sur matériel standard, 0 facteur partagé sur la portion CT-visible.
Détecteur 2 — Sweep Fermat sur premiers proches
L'algorithme de Fermat factorise efficacement les modules RSA n = p × q quand |p − q| est suffisamment petit. Il cible une classe de défauts différente du batch GCD : pas un RNG qui partage des bits entre clés indépendantes, mais un RNG biaisé qui tire p et q du même pool restreint — produisant des facteurs proches en valeur absolue mais non partagés.
La paire la plus saillante de ce mode de défaillance dans la littérature : le rapport Pearl-2019 du NCC Group, qui a factorisé plusieurs centaines de clés Yubico vendues entre 2015 et 2018 par exactement ce mécanisme — un RNG firmware qui tirait p et q trop proches.
Exécution 2026 : à profondeur k=100 sur 25,8 millions de modules, ~10 minutes (40 500 modules/seconde sur 12 workers). Puis sweep additionnel à profondeur k=2 000 000 (vingt mille fois plus profond) sur le sous-corpus IoT scanné — le plus à risque parce que les firmware embarqués ont historiquement les pires RNG. 0 paire de premiers proches dans les deux passes.
Détecteur 3 — Hidden Number Problem / réduction de réseau (ECDSA)
Ce détecteur est plus technique. En résumé : si une autorité ECDSA signe avec un nonce biaisé — typiquement, les bits de poids fort toujours à zéro à cause d'un RNG limité — alors la clé privée de signature est récupérable par réduction de réseau à partir d'un nombre suffisant de signatures.
C'est la construction Boneh-Venkatesan / Nguyen-Shparlinski, formalisée dans les années 1990 et déployée à plusieurs reprises depuis :
- Breitner & Heninger 2019 sur la chaîne Bitcoin : récupération de dizaines de clés ECDSA P-256 ayant signé des transactions ;
- Feng et al. 2026 sur des signatures Alipay : récupération sur biais de nonce ;
- Plusieurs déploiements PKI Web historiques avec implémentations ECDSA en bibliothèques non-standard.
Exécution 2026 en deux passes :
- Sur les signatures CT extraites : 23 groupes (émetteur, courbe), 61 tentatives lattice à biais ∈ {2, 4, 8} → 0 récupération.
- Sur des signatures live extraites de handshakes TLS contre des cibles sélectionnées pour leur volume : 1 436 signatures, mêmes biais → 0 récupération.
Les CA testées dans la passe CT incluaient des intermédiaires de Cloudflare TLS Issuing, Google Trust Services, Microsoft Azure ECC TLS, Amazon Trust, ZeroSSL ECC, Sectigo Public Server Auth, TrustAsia LiteSSL, Certainly et plusieurs autres. Toutes propres. C'est parfaitement cohérent avec des CAs opérant en HSM FIPS-validés, avec génération de nonces déterministe (RFC 6979) ou matérielle.
Détecteur 4 — Erreur d'émission CA
Recherche regex stricte des certificats émis publiquement dont le Common Name du sujet pointe vers un espace de nommage privé : RFC 1918 (10.x.x.x, 172.16-31.x.x, 192.168.x.x), .local, .internal, .lan, .home, .corp, .intranet, localhost. Conçu pour faire émerger les violations de la CA/B Forum Baseline Requirements §7.1.4.2.1 — une CA publique ne doit jamais émettre un certificat pour un espace de nommage non publiquement routable.
Exécution 2026 : 44,6 millions de certificats, 2 faux positifs (artefacts AWS-internes : ip-10-x-y-z.compute.internal, déposés dans CT à des fins de monitoring), 0 vraie erreur d'émission.
Le résultat négatif compte autant que le positif
| Détecteur | Périmètre scanné | Résultat |
|---|---|---|
| Batch GCD (Bernstein 2004) | 6,6 M modules RSA uniques | 0 facteur partagé |
| Fermat (k=100) | 25,8 M modules uniques | 0 paire de premiers proches |
| Fermat (k=2 M, sous-corpus IoT) | 22 000 / 30 050 | 0 paire de premiers proches |
| HNP / lattice (sigs CT) | 23 groupes, 61 tentatives | 0 récupération |
| HNP / lattice (sigs handshake TLS) | 1 436 signatures | 0 récupération |
| Erreur d'émission CA | 44,6 M certificats | 2 faux positifs, 0 vraie |
Aucun de ces résultats n'est anodin. Ils signifient quelque chose de précis et de fort : la portion CT-visible du parc commercial moderne implémente correctement la génération de clés, la génération de nonces et la discipline de templates.
Mais sur la longue traîne, on parle d'une réalité différente. Le tableau de bord live agrège aujourd'hui 1 158 clés vulnérables dans le corpus complet, réparties en quatre familles : tailles de clés faibles (837), exposants publics non standard (230), réutilisation de clé ECDSA (90), et validités codées en dur jusqu'à la limite 32 bits (1). Aucune de ces familles ne concerne les CAs commerciales modernes — elles vivent toutes dans le firmware, dans des templates d'usine, dans des architectures opérateurs non documentées.
Cela colle avec ce qu'on sait des CAs commerciales modernes : génération en HSM FIPS-validés, nonces ECDSA déterministes (RFC 6979) ou matériels, revues de templates par les CAB Forum Working Groups, audits Web Trust annuels. Le défaut de 0,5 % qu'Heninger mesurait en 2012 a été corrigé.
C'est la couche visible — celle qu'on regarde, celle qu'on audite, celle qui se ré-audite. C'est rassurant.
Mais le risque cryptographique n'a pas disparu pour autant. Il a migré vers des couches que les détecteurs cryptanalytiques classiques ne voient pas — et que les scans de suites cipher TLS ne voient pas non plus. Le tableau de bord public expose la répartition par catégorie de fabricant : 287 constats actifs sur des routeurs SOHO grand public, 30 sur des passerelles résidentielles, 16 sur des pare-feu d'entreprise, et plusieurs catégories plus petites jusqu'aux CPE industriels et CCTV réseau. Aucun nom de fabricant n'est encore publié — c'est l'objet du livre blanc complet du 25 juillet.
La leçon méthodologique — un faux positif HNP qui nous a appris l'humilité
Cette section est défensive. Elle révèle un bug interne de notre pipeline. La transparence ici est plus utile que le silence.
Notre première exécution du détecteur HNP a produit des résultats absurdes : prétention de récupération de clés de signature pour des CAs connues pour opérer en HSM FIPS-validés. Cloudflare TLS Issuing ECC CA 3, plusieurs intermédiaires Google Trust Services (WE1, WE3, WE5), deux Microsoft Azure ECC TLS CAs, ZeroSSL ECC, cPanel ECC, TrustAsia LiteSSL, Certainly Intermediate E1, nazwaSSL DV TLS G2 E29.
Évidemment faux. Aucune chance que toutes ces CAs soient simultanément cassées de la même façon.
L'investigation a remonté à une expression de contrôle de cohérence, ligne 132 du fichier research/ecdsa_nonce.py :
if k_candidate.bit_length() > n.bit_length() - bias + 2:
break
Pour la courbe P-256 (n.bit_length() == 256), à biais 2, la condition s'évalue en > 256 — inatteignable pour tout k < n valide. La vérification ne brisait donc jamais la boucle, et la routine lattice rapportait chaque candidat « court » comme une clé récupérée.
Correction : borne stricte n.bit_length() - bias et rejet de x_candidate ∈ {0, n−1}. Ré-exécution → résultat négatif propre.
20 lignes de faux positifs nettoyées de la base.
À toute personne qui exécute des détecteurs de type HNP à l'échelle : vérifiez vos bornes de contrôle de cohérence contre un échantillon de CA connu-propre avant de tirer des conclusions d'un hit positif. Au moins un constat « weak-CA HNP » publié antérieurement dans la littérature pourrait avoir utilisé un code lattice modèle avec un bug latent similaire. Ce bug est plus facile à introduire qu'à détecter.
Cette discipline — vérifier le détecteur sur un échantillon négatif connu avant de croire aux positifs — coûte une demi-journée. Elle évite de publier des constats imaginaires. Recommandation universelle.
Divulgation coordonnée — la photo en direct
Documenter une faille sans contacter le fabricant n'est pas de la recherche, c'est du théâtre. Toute la chaîne de constats est en divulgation coordonnée avec les acteurs concernés, sous délai de grâce de 90 jours par lot. Le tableau de bord public montre l'état en temps réel :
Au moment où ce billet est rédigé : 63 divulgations sous délai de grâce, 1 092 divulgations rédigées mais pas encore envoyées (orphelines de constats supplémentaires sur des fabricants déjà notifiés), 0 grâce expirée, 0 correctif confirmé. Le cycle de vie des certificats concernés est mesuré en passif — sans sondage actif pendant la fenêtre de grâce, pour éviter de signaler à un attaquant que le constat existe.
C'est une discipline éthique : un constat publié sans divulgation préalable est un cadeau aux attaquants. Et c'est cette discipline qui définit le calendrier du livre blanc — la publication interviendra quand l'ensemble des grâces auront expiré.
Ce qui sort le 25 juillet
Le livre blanc complet documente :
- Le corpus dans le détail (logs CT individuels, distribution géographique des scans IPv4, déduplication)
- La méthodologie ci-dessus, en plus formel (preuves de correction des détecteurs, complexité, performance)
- Les résultats négatifs ci-dessus, en table complète
- Les modes de défaillance migrés — où le risque cryptographique a réellement déménagé dans l'écosystème 2026
- Le spectre des réponses obtenues lors de la divulgation coordonnée auprès des fabricants et opérateurs concernés
- Une checklist d'audit concrète pour les RSSI et les équipes achats
Le document est sous embargo coordonné jusqu'au 25 juillet 2026, date à laquelle les grâces de divulgation expirent sur l'ensemble des batches de notifications envoyées.
En attendant — deux choses utiles
1. Auditer vos propres certificats, gratuitement
audit.zetacert.com rejoue exactement la même chaîne de détecteurs sur un certificat individuel ou un nom d'hôte. Aucun compte, aucune rétention de données. Si vous voulez vérifier votre propre exposition aux modes de défaillance que nous documentons, c'est l'outil :
2. Être notifié à la publication
Notre page livre blanc accepte les inscriptions pour notification à la publication. Aucune autre communication d'ici là — un seul email avec le lien de téléchargement le 25 juillet.
→ zetacert.com/fr/whitepapers/state-of-public-pki-2026
ZetaCert Research conduit des audits cryptographiques à grande échelle de la PKI publique. Méthodologie reproductible, résultats négatifs publiés, divulgation coordonnée. Plus d'informations sur zetacert.com/research ou par email à research@zetacert.com.
