mystenlabs/ed25519-unsafe-libsListe des bibliothèques de signatures ed25519 non sûres
Une liste de bibliothèques de signature ed25519 potentiellement non sûres qui exposent une API publique où la clé secrète et la clé publique peuvent être fournies indépendamment comme entrées de la fonction de signature. Une mauvaise utilisation de ces API publiques peut entraîner l'exposition de la clé privée.
La plupart des dépôts analysés sont répertoriés dans IANIX :: Choses qui utilisent Ed25519.
Nombre de bibliothèques impactées : 45
Nombre de bibliothèques ayant corrigé le problème après l'annonce : 8
dernière mise à jour : 4 mai 2023
Notez que normalement, et conformément à la rfc8032 associée, les signatures EdDSA sont déterministes : pour un même message d'entrée à signer, une signature unique composée de deux éléments, un point de courbe R et un scalaire S, est renvoyée.
Un détail algorithmique est que la clé publique du signataire n'intervient que dans le calcul déterministe de la partie S de la signature, mais pas dans la valeur R. Cela implique que si un adversaire pouvait d'une manière ou d'une autre utiliser la fonction de signature comme un oracle (qui accepte des clés publiques arbitraires en entrée), il serait alors possible d'obtenir, pour le même message, deux signatures partageant le même R et ne différant que sur la partie S. Malheureusement, lorsque cela se produit, on peut facilement extraire la clé privée ; ce post StackOverflow explique pourquoi cela est possible.
Cela dit, les API publiques ne devraient PAS autoriser une paire de clés privée/publique dissociée comme entrée de signature. Pour contourner ce problème, de nombreuses implémentations stockent la clé publique avec la clé privée (ou la graine) et considèrent l'ensemble de la paire de clés comme le secret, OU elles redérivent toujours la clé publique dans la fonction de signature. Malheureusement, un grand nombre de bibliothèques existantes ne traitent pas ce problème et autorisent des clés publiques arbitraires en entrée sans vérifier si la clé publique d'entrée correspond à la clé privée d'entrée.
Bien sûr, cela ne signifie pas que toutes les applications dépendant de ces bibliothèques sont sujettes à des attaques d'exposition de clés ; en réalité, la plupart sont probablement sûres car elles n'exposent généralement pas l'API concernée à leurs utilisateurs et couplent leur paire de clés publique/privée juste avant l'invocation de sign. D'un autre côté, même lorsque ces API ne sont pas exposées, certaines applications adoptent des stratégies de modèle de menace TCB différentes quant à la gestion et au stockage des clés privées et publiques. Cela dit, pour prévenir cette attaque, les développeurs devraient également mettre en œuvre un protocole de protection de l'intégrité des clés publiques.
Nous listons ici quelques bibliothèques concernées ainsi que les références de code associées.
Fig 1. Un exemple de mauvaise utilisation de l'API dans la crate Rust ed25519-dalek.
