Hot Tracking 029 | Clé AES 9 bits : La crise des nombres aléatoires

Quel s’est passé

Lors de la chiffrement d’un document PDF, le mot de passe de l’utilisateur n’est pas directement chiffré dans le contenu du fichier. Le processus se déroule en deux étapes : d’abord, le logiciel génère aléatoirement une clé de 32 octets, qui est ensuite chiffrée avec AES pour contenir le texte ; puis, cette clé est utilisée pour chiffrer et stocker à nouveau le document. Lorsque l’utilisateur ouvre le document, il doit d’abord calculer la clé dérivée à l’aide du mot de passe, déchiffrer la clé du fichier, et enfin utiliser cette clé pour déchiffrer le texte. Ce design est parfaitement solide et est une pratique courante dans de nombreux logiciels de chiffrement de documents. Le problème réside dans la qualité de la clé du fichier, qui constitue la base de tout le processus de chiffrement. Si la clé du fichier peut être facilement déchiffrée, alors même l’algorithme AES-256 n’est d’aucune utilité.

Rick de Jager, chercheur chez V12, a découvert dans ses audits que quatre implémentations courantes de PDF présentaient des problèmes graves dans la génération de la clé du fichier. Le problème ne réside pas dans le nom de l’algorithme, mais dans le fait que la source aléatoire utilisée pour générer la clé ne satisfait pas aux exigences de sécurité cryptographique.

Examinons les versions anciennes de MuPDF (<1.28.5>). Elles utilisent un générateur de nombres entiers linéaires drand48, avec une seconde de timestamp Unix comme graine, et ne prennent que 9 bits du timestamp à partir des positions 17-24. Les 16 premiers bits du statut sont fixés à 0x330e, ce qui signifie que seulement 9 bits du timestamp affectent l’output. Différents timestamps sur une différence de 512 secondes peuvent produire exactement la même chaîne de clés. Avec un script Python non optimisé, il suffit d’environ 11 millisecondes pour tester toutes les 512 possibilités. Une fois le document obtenu, l’attaquant peut rapidement déterminer la bonne clé du fichier. Plus préoccupant, le champ /ID de MuPDF est également généré par le même LCG et stocké en texte brut, ce qui peut servir de vérification supplémentaire pour réduire encore plus l’espace de recherche.

Ensuite, examinons Foxit PDF Reader 2026.1.3.36551. La clé du fichier provient d’un hash de « timestamp actuel + 32 octets non initiaux + constantes ». Les octets non initiaux sont en réalité des remplissages nuls, ce qui signifie qu’il n’y a pas de randomisation. L’implémentation Rust de V12 montre qu’elle peut tester 370 à 376 millions de timestamps par seconde sur un Ryzen 9 7950X à 32 threads. Il fallait environ 0.84 seconde pour cracker le document il y a 10 ans, et il ne faut que environ 4.85 secondes pour effectuer une recherche depuis l’époque Unix. Le bloc /Perms de Foxit contient des textes connus, et la vérification nécessite simplement un hash et une déchiffrement AES, ce qui réduit encore les coûts d’attaque.

OpenPDF 3.0.5 et iText 9.7.1 présentent un autre type de problème. Ils remplacent le contenu qui devrait être fourni par un générateur de nombres aléatoires cryptographiquement sûrs par un flux ARC4. Le graine ARC4 est composé d’un timestamp en millisecondes et de la mémoire libre de la JVM, tandis que le 32 octets de salte stockés dans /U et /O sont en texte brut, ce qui permet de récupérer les timestamps et les valeurs de mémoire. Cela signifie que l’attaquant n’a pas besoin de tester tout l’espace des clés ; il suffit de reconstituer le graine à partir des informations exposées dans le document.

V12 indique également que le modèle de code problématique dans Foxit remonte à la première publication publique de PDFium en mai 2014, et que les tête des fichiers PDFium remercient Foxit, ce qui signifie que ce modèle pourrait provenir de Foxit et exister depuis plus de dix ans. En d’autres termes, ce risque n’a pas été introduit récemment, mais constitue un fardeau historique qui existe depuis longtemps dans l’écosystème PDF. Plus préoccupant, ces implémentations sont utilisées par de nombreux projets et produits commerciaux, et une faille dans un module de base pourrait se propager à des scénarios plus larges grâce à la réutilisation du code.

Fabricants et corrections

Le problème a été signalé aux fabricants concernés. Les progrès publics sont les suivants :

• MuPDF a été corrigé, les versions affectées étant avant 1.28.5.
• L’état de correction pour Foxit, OpenPDF et iText doit être vérifié selon les annonces officielles respectives.
• V12 a publié des déchiffreurs pour MuPDF et Foxit, prouvant que la vulnérabilité peut être exploitée réellement.

Il est important de souligner qu’il n’est pas possible de protéger retroactivement les fichiers PDF cryptés déjà créés. Même si le logiciel est corrigé aujourd’hui, les fichiers créés avec ces versions précédentes peuvent toujours être vulnérables. Cela diffère des correctifs de vulnérabilités courants : les correctifs ne peuvent empêcher que de nouveaux fichiers soient endommagés, tandis que la seule solution pour les fichiers existants est de les crypter ou de les convertir à nouveau avec des outils fiables.

Cela soulève également une question de responsabilité. Les normes de cryptage PDF ne exigent pas que les générateurs de nombres aléatoires utilisent des nombres aléatoires sécurisés par la cryptologie, ni quels niveaux d’entropie doivent être atteints par les générateurs de nombres aléatoires. Les normes ne définissent que le cadre algorithmique, et les fabricants décident des implémentations spécifiques. En conséquence, la qualité des implémentations varie entre les différents fabricants, et il est difficile pour les utilisateurs de distinguer les différences de sécurité à partir des interfaces ou des noms des fonctionnalités. Tant que l’attribut du document indique « AES-256 », les utilisateurs ordinaires pensent généralement que cela est suffisamment sûr. Cette asymétrie d’informations crée une grande différence entre la communication marketing et les résultats réels de la « cryptage ».

Un autre point à noter est que ce type de problème n’est souvent pas détecté par les outils de scanning de vulnérabilités traditionnels. Parce que le code fait effectivement appel à AES-256 et stocke la clé selon le format standard, c’est simplement la source aléatoire elle-même qui est insuffisante en termes de sécurité. L’analyse statique et les tests en boîte noire ont du mal à identifier des défauts sémantiques tels que « manque d’entropie dans la clé », ce qui nécessite une vérification de sécurité spécifique pour être révélée.

D’un autre point de vue, cette divulgation révèle également les risques liés à la réutilisation du code. Il existe de nombreuses implémentations partagées et codes de référence dans l’écosystème PDF, et si un module de base ne gère pas correctement les nombres aléatoires, les outils construits à partir de celui-ci peuvent présenter le même problème. Pour les entreprises qui utilisent la cryptographie PDF pour protéger des informations sensibles, cela signifie qu’il est impossible de simplement faire confiance aux fabricants reconnus ou aux projets matures, et qu’il faut vérifier activement si l’implémentation respecte les exigences de la cryptologie moderne.

Qu’en pensez-vous dans les commentaires ?

Un commentaire populaire sur Hacker News vient de tptacek, qui souligne que le véritable problème n’est pas « la clé ne contenant que 9 bits », mais bien que la clé n’est pas du tout un nombre aléatoire sécurisé par la cryptologie. Cette distinction est importante : AES-256 n’a pas été brisé, ce qui a été brisé, c’est la source aléatoire utilisée pour générer la clé. Décrire le problème comme « une clé AES de 9 bits » est une expression imagée, mais cela peut faire croire aux lecteurs que l’algorithme AES a fait une erreur. Le nom de l’algorithme fournit une limite théorique, tandis que les détails d’implémentation déterminent la limite réelle.

Les autres discussions se concentrent sur les obstacles historiques liés à l’écosystème de chiffrement PDF. Beaucoup pensent que les normes PDF ont conçu le chiffrement pour sembler complexe, mais n’ont pas longtemps imposé l’utilisation de nombres aléatoires sécurisés par cryptographie, ce qui a conduit à des failles dans diverses implementations. Les normes de chiffrement PDF ont été créées en réponse aux besoins de protection des documents, et non à des modèles de menaces modernes, ce qui a laissé beaucoup de zones d’ombre.

D’autres rappellent que les utilisateurs ordinaires pensent que « AES-256 » est synonyme de sécurité, mais si un problème survient au niveau de la génération des nombres aléatoires, de la dérivation des clés ou du traitement des valeurs salées, cela rendrait le nom de l’algorithme haute sécurité sans véritable effet. Certains commentaires soulignent que la signification de la divulgation de ces failles est de faire réviser les hypothèses des organisations qui utilisent le chiffrement PDF, plutôt que de simplement imputer la responsabilité à un fabricant. D’autres développeurs affirment que de nombreux projets se concentrent uniquement sur la présence ou non d’une fonctionnalité de chiffrement, sans se soucier de l’audit de la mise en œuvre, et cette mentalité est en soi une source de risque.

Certains commentaires soulignent également les difficultés réelles de correction. Comme les fichiers PDF ne peuvent être protégés de manière rétrospective une fois créés, les entreprises doivent chiffrer à nouveau de grandes quantités de documents historiques, ce qui représente une charge supplémentaire pour la stockage et les processus. Par conséquent, certains pensent que l’impact de cet incident ne disparaîtra pas immédiatement, mais persistera pendant plusieurs mois ou même plus longtemps. D’autres suggèrent qu’à l’avenir, lors de la révision des normes PDF, il faudrait imposer l’utilisation de nombres aléatoires sécurisés par cryptographie ; sinon, des problèmes similaires se reproduiront sans cesse.

Trois choses que les utilisateurs ordinaires peuvent faire

1. Ne vous contentez pas de voir la mention « AES-256 ». La sécurité du chiffrement dépend de plusieurs aspects tels que la génération des clés, la dérivation des clés et la source des nombres aléatoires. Si un outil se concentre uniquement sur le nom de l’algorithme sans préciser les détails de la mise en œuvre, soyez vigilant. Pour les contenus vraiment sensibles, envisagez d’ajouter une couche de chiffrement indépendante au-delà du chiffrement PDF, par exemple en utilisant des outils de chiffrement de fichiers audités. De cette manière, même si le chiffrement PDF présente des défauts de mise en œuvre, le contenu du document ne sera pas directement exposé.
2. Vérifiez si vous avez des PDF sensibles générés avec la version divulguée. Si oui, recommandez de chiffrer à nouveau avec l’outil de la version corrigée, ou de passer à une autre méthode de chiffrement auditée, plutôt que de compter sur le chiffrement par mot de passe des anciens fichiers. Il est particulièrement important de noter que modifier les propriétés du document ou le réencoder ne suffit pas ; il faut générer à nouveau la clé du fichier et chiffrer à nouveau le contenu. Pour les entreprises, il est préférable de combiner cette étape avec une stratégie de gestion des versions de documents et de sauvegarde, afin d’éviter la perte de contenu ou l’échec du contrôle des droits lors du chiffrement réussi.
3. Pour les entreprises, intégrer le chiffrement PDF dans les examens de baseline de sécurité. Concentrez-vous sur la source des nombres aléatoires, les fonctions de dérivation des clés et les méthodes de traitement des valeurs salées, plutôt que sur la présence ou l’absence de « AES-256 ». Établissez également une gestion du cycle de vie des documents, en marquant quels fichiers ont été créés sous une version problématique, et priorisez le chiffrement ou la migration de ces fichiers. De plus, les équipes de sécurité peuvent suivre régulièrement les annonces de sécurité des outils de traitement PDF, afin d’évaluer le champ d’impact dès que cela se produit.

Conclusion

L’incident de la « clé AES de 9 bits » montre une fois de plus que la sécurité des produits cryptographiques ne dépend pas du nom de l’algorithme, mais des détails de son implémentation. AES-256 peut offrir un niveau théorique de sécurité élevé, mais si une clé de 32 octets provient en réalité d’une source aléatoire ne possédant qu’un entropie de 9 bits, sa véritable force réduit à 9 bits. Plus compliqué encore, le standard de chiffrement PDF ne prescrit pas l’utilisation de nombres aléatoires cryptographiquement sûrs, ce qui entraîne des problèmes récurrents dans différentes implémentations. Pour les utilisateurs ordinaires, la meilleure action est de vérifier s’ils continuent d’utiliser des versions anciennes problématiques pour générer des documents sensibles et de se transférer rapidement à des méthodes de chiffrement plus fiables. Les tendances technologiques passent, mais la sécurité des documents ne se répare pas automatiquement. La vraie responsabilité est de considérer cette révélation comme une opportunité de mettre en place des mesures pour assurer la sécurité de ses actifs numériques. Pour les organisations qui dépendent du chiffrement PDF pour protéger leurs documents essentiels, cet incident constitue un avertissement : même les algorithmes les plus puissants ne peuvent pas sauver le manque de rigueur dans la gestion des nombres aléatoires. Seul en tenant compte de l’« implémentation » plutôt que du « nom » comme critère principal pour évaluer les produits de chiffrement permettra d’éviter que de tels risques ne se reproduisent.

Sources de référence

• Blogue de V12 Security : The case of the 9 bit AES key (2026-10-27)
• Forum Hacker News, objectID 50280722 (2026-10-28)