mystenlabs/ed25519-unsafe-libsLista de librerías de firma ed25519 inseguras
Una lista de librerías de firmas ed25519 potencialmente inseguras que permiten una api pública donde la clave secreta y la clave pública pueden proporcionarse de forma independiente como entradas de la función de firma. El uso indebido de estas apis públicas puede resultar en la exposición de la clave privada.
La mayoría de los repositorios de nuestro análisis están incluidos en IANIX :: Things that use Ed25519.
Número de librerías afectadas: 45
Número de librerías que corrigieron el problema tras el anuncio: 8
última actualización: 4 de mayo de 2023
Ten en cuenta que, normalmente y de acuerdo con el rfc8032 relacionado, las firmas EdDSA son deterministas y, por lo tanto, para el mismo mensaje de entrada a firmar se devuelve una salida de firma única que incluye dos elementos: un punto de la curva R y un escalar S.
Un detalle algorítmico es que la clave pública del firmante solo interviene en el cálculo determinista de la parte S de la firma, pero no en el valor R. Esto último implica que, si un adversario pudiera usar de alguna manera la función de firma como un oráculo (que espera claves públicas arbitrarias como entradas), entonces es posible que para el mismo mensaje se obtengan dos firmas que compartan el mismo R y solo difieran en la parte S. Desafortunadamente, cuando esto sucede, se puede extraer fácilmente la clave privada; esta publicación de StackOverflow explica por qué esto es factible.
Dicho esto, las apis públicas NO deberían permitir un par de claves privada/pública desacoplado como entrada de firma. Para evitar esto, muchas implementaciones almacenan la clave pública junto con la clave privada (o semilla) y consideran todo el par de claves como el secreto, O siempre vuelven a derivar la clave pública dentro de la función de firma. Desafortunadamente, un gran número de librerías existentes no abordan este problema al permitir claves públicas arbitrarias como entradas sin comprobar si la clave pública de entrada corresponde con la clave privada de entrada.
Por supuesto, esto no significa que todas las aplicaciones con dependencias de estas librerías sean propensas a ataques de exposición de claves; de hecho, la mayoría probablemente sean seguras, ya que normalmente no exponen públicamente la api afectada a sus usuarios y acoplan su par de claves pub/priv justo antes de la invocación de sign. Por otro lado, incluso cuando estas apis no están expuestas, hay aplicaciones con diferentes estrategias de modelo de amenaza TCB sobre cómo se gestionan y almacenan las claves privadas y públicas. Dicho esto, para prevenir este ataque, los desarrolladores también deberían imponer un protocolo de protección de integridad para las claves públicas.
Aquí enumeramos algunas librerías afectadas junto con las referencias de código relacionadas.
Fig. 1. Un ejemplo de uso indebido de la api en el crate Rust ed25519-dalek.
