Investigadores de la Universidad Masaryk revelaron información importante sobre vulnerabilidades en diversas implementaciones del algoritmo de generación de firma digital ECDSA/EdDSA, que permite recuperar el valor de la clave privada en función del análisis de fugas de información sobre bits individuales que aparecen al aplicar métodos de análisis a través de canales de terceros. Las vulnerabilidades tienen el nombre en código de Minerva.

Los proyectos más famosos que afectan el método de ataque propuesto son OpenJDK, OracleJDK (CVE-2019-2894) y la biblioteca Libgcrypt (CVE-2019-13627) utilizada en GnuPG. Los problemas son también susceptibles para las bibliotecas MatrixSSL, Crypto++, wolfCrypt, elíptica, jsrsasign, Python-ECDSA, ruby_ecdsa, fastecdsa y también a algunas tarjetas inteligentes Athena IDProtect, TecSec Armored Card, SafeNet eToken 4300, Valid S/A IDflex V.

Ademas de las vulnerabilidades mencionadas de momento no se ven afectados OpenSSL, Botan, mbedTLS y BoringSSL. Mozilla NSS, LibreSSL, Nettle, BearSSL, cryptlib, OpenSSL en modo FIPS. Microsoft .NET crypto, libkcapi del kernel de Linux, Sodium y GnuTLS aún no se han probado.

Hemos encontrado implementaciones que pierden la longitud de bits del escalar durante multiplicación escalar en ECC. Esta fuga puede parecer minúscula ya que la longitud de bits presenta una cantidad muy pequeña de información presente en el escalar. Sin embargo, en el caso de la generación de firmas ECDSA / EdDSA, la filtración la longitud de bits del nonce aleatorio es suficiente para la recuperación completa de la clave privada utilizado después de observar unos cientos a unos miles de firmas en conocidos mensajes, debido a la aplicación de algunas técnicas.

Creemos que todas las tarjetas anteriores se ven afectadas porque comparten un componente ECDSA común (módulo FIPS 214 ), que se describe como Componente ECDSA2 Athena OS755 en Inside Secure AT90SC A1.0 (Firmware) . Hemos probado la vulnerabilidad solo en la tarjeta Athena IDProtect con datos CPLC y ATR

El problema es causado por la capacidad de determinar los valores de bits individuales durante la multiplicación por un escalar durante las operaciones con ECC. Los métodos indirectos, como la estimación del retraso en la realización de los cálculos, se utilizan para extraer información de bits.

Un ataque requiere acceso sin privilegios al host en el que se genera la firma digital (no se excluye un ataque remoto, pero es muy complicado y requiere una gran cantidad de datos para el análisis, por lo tanto, puede considerarse improbable).

A pesar del pequeño tamaño de la fuga, para ECDSA la definición de incluso unos pocos bits con información sobre el vector de inicialización (nonce) es suficiente para llevar a cabo un ataque para restaurar secuencialmente la clave privada completa.

Según los autores del método, para una recuperación de clave exitosa, es suficiente el análisis de varios cientos a varios miles de firmas digitales generadas para mensajes conocidos por el atacante. Por ejemplo, para determinar la clave privada utilizada en la tarjeta inteligente Athena IDProtect basada en el chip Inside Secure AT90SC, utilizando la curva elíptica secp256r1, se analizaron 11 mil firmas digitales. El tiempo total de ataque fue de 30 minutos.

Nuestro código de ataque y prueba de concepto está inspirado en el método de Brumley & Tuveri.

El problema ya se ha solucionado en libgcrypt 1.8.5 y wolfCrypt 4.1.0, otros proyectos aún no han generado actualizaciones. También es posible rastrear la corrección de la vulnerabilidad en el paquete libgcrypt en distribuciones en estas páginas: Debian, Ubuntu, RHEL, Fedora, openSUSE/SUSE, FreeBSD, Arch.

También los investigadores realizaron pruebas a otras tarjetas y bibliotecas, de las cuales no son vulnerables son las siguientes:

• OpenSSL 1.1.1d
• BouncyCastle 1.58
• AburridoSSL 974f4dddf
• libtomcrypt 1.18.2
• Botan 2.11.0
• Microsoft CNG
• mbedTLS 2.16.0
• Intel IPP-Crypto

Tarjetas

• ACS ACOSJ 40K
• Feitian A22CR
• G&D SmartCafe 6.0
• G&D SmartCafe 7.0
• Infineon CJTOP 80K INF SLJ 52GLA080AL M8.4
• Infineon SLE78 Universal JCard
• NXP JCOP31 v2.4.1
• NXP JCOP CJ2A081
• NXP JCOP v2.4.2 R2
• NXP JCOP v2.4.2 R3
• Bóveda SIMOME TaiSYS

Si quieres conocer más al respecto sobre el ataque utilizado y sobre las vulnerabilidades detectadas, puedes hacerlo en el siguiente enlace. Las herramientas utilizadas para replicar el ataque están disponibles para descargar .