- Mientras los elementos seguros se usan como base de confianza para autenticación fuerte, EUCLEAK es un ataque de canal lateral que extrae claves secretas de la implementación de ECDSA de Infineon y fue demostrado en una YubiKey 5Ci
- La vulnerabilidad clave está en la operación de inverso modular no constante en tiempo de la biblioteca criptográfica de Infineon, y logró pasar durante 14 años unas 80 evaluaciones de certificación Common Criteria del nivel más alto
- El atacante necesita acceso físico al elemento seguro, además de unas cuantas mediciones electromagnéticas locales, equipo costoso, software personalizado y capacidad técnica, aunque la medición en sí toma solo unos minutos
- El alcance incluye la serie YubiKey 5 con firmware anterior a 5.7 y microcontroladores de seguridad que ejecutan la biblioteca criptográfica de Infineon, incluidos los TPM
- En FIDO, la extracción de la clave secreta ECDSA permite la clonación del dispositivo, pero para fines de defensa contra phishing sigue siendo más seguro usar los productos afectados que no usarlos
Qué apunta el ataque EUCLEAK
- Un elemento seguro (secure element) es un pequeño microcontrolador que genera y almacena secretos y realiza operaciones criptográficas; a menudo recibe la evaluación de seguridad de nivel más alto de Common Criteria
- Los tokens de hardware FIDO son un medio de autenticación fuerte usado para iniciar sesión en servicios web, y el protocolo FIDO usa ECDSA como primitiva criptográfica central
- La serie YubiKey 5 es un token de hardware FIDO ampliamente usado y utiliza el Infineon SLE78 como elemento seguro
- NinjaLab analizó la implementación ECDSA de Infineon con Feitian A22, una plataforma abierta JavaCard similar basada en Infineon SLE78, y diseñó un ataque real que aprovecha la vulnerabilidad de canal lateral
- El ataque fue demostrado en una YubiKey 5Ci
- La vulnerabilidad también se extiende a microcontroladores de seguridad más recientes como Infineon Optiga Trust M y Infineon Optiga TPM
- La causa de la vulnerabilidad es el inverso modular no constante en tiempo de la biblioteca criptográfica de Infineon Technologies, y no fue detectada durante 14 años y alrededor de 80 evaluaciones de certificación Common Criteria del nivel más alto
- La documentación técnica detallada está disponible en Download the Writeup
Productos afectados y condiciones del ataque
- El atacante debe tener acceso físico al elemento seguro y puede extraer la clave secreta ECDSA con unas cuantas mediciones locales de canal lateral electromagnético
- En el protocolo FIDO, esto permite la clonación del dispositivo FIDO
- El ataque requiere equipo costoso, software personalizado y capacidad técnica
- Los productos afectados son los siguientes
- Todas las versiones existentes de microcontroladores de seguridad Infineon con la biblioteca criptográfica de Infineon integrada
- Versiones existentes de Infineon TPM
- Toda la serie YubiKey 5 con firmware anterior a 5.7
- Estos microcontroladores de seguridad están presentes en diversos sistemas de seguridad que dependen de ECDSA, como pasaportes electrónicos, wallets de hardware para criptomonedas, smartcards y smart home, pero todavía no se ha confirmado si EUCLEAK aplica realmente a esos productos
- Feitian A22 JavaCard es un producto antiguo usado para la investigación y ya no se vende
- Los productos basados en microcontroladores de seguridad Infineon que hoy se venden en la tienda web de Feitian usan la biblioteca criptográfica propia de Feitian y, hasta donde sabe NinjaLab, no están afectados por esta investigación
Mitigación e información oficial
- El firmware 5.7 de YubiKey cambió en la actualización del 6 de mayo de 2024 de la biblioteca criptográfica de Infineon a una nueva biblioteca criptográfica de Yubico
- Hasta donde sabe NinjaLab, esta nueva biblioteca no está afectada por EUCLEAK
- Infineon ya tiene un parche para la biblioteca criptográfica, pero hasta donde sabe NinjaLab, todavía no ha pasado la evaluación de certificación Common Criteria
- La solicitud de CVE fue rechazada y MITRE usa en su lugar CVE-2024-45678
- La solicitud de actualización de la descripción está pendiente
- La postura oficial puede consultarse en los siguientes documentos
- 3 de septiembre de 2024: Yubico Security Advisory
- 9 de septiembre de 2024: comunicado de prensa de BSI (German) / (Google Translated Version)
1 comentarios
Opiniones en Hacker News
Según el artículo de Ars Technica, el atacante necesita no solo el nombre de usuario y la contraseña, sino también acceso físico a la llave; además, si quiere devolver el dispositivo después de desarmarlo, debe volver a ensamblarlo, así que no es un ataque trivial en absoluto.
Parece que poner un poco de esmalte de uñas en la unión del plástico podría servir como canario para detectar manipulación.
Sin embargo, también deja al descubierto una debilidad de los tokens FIDO. Hay que llevar manualmente una lista de dónde se registraron, y si el token se pierde o es robado, hay que revocarlo manualmente en todos los sitios registrados.
Según NinjaLab, todos los microcontroladores seguros de Infineon que ejecutan la biblioteca criptográfica de Infineon son vulnerables a este ataque en, hasta donde se sabe, todas las versiones existentes.
Esto incluye chips de pasaportes electrónicos de Estados Unidos, China, India, Brasil y varios países de Europa y Asia; zonas seguras de teléfonos Samsung y OnePlus; wallets de hardware para criptomonedas como Ledger y Trezor; tarjetas SIM; TPM de laptops Lenovo, Dell y HP; y chips EMV de tarjetas de crédito y débito.
Así, si pierdo la llave, me la roban o falla, puedo sacar rápidamente la lista de sitios donde tengo que quitarla.
Siempre registro 2 llaves y las guardo separadas físicamente, de modo que pueda iniciar sesión aunque pierda una.
Eso incluye no solo el acceso a activos cripto, sino también situaciones más graves, como contratistas de defensa.
En estos casos, el atacante tiene muchos recursos y una motivación fuerte, y YubiKey se usa precisamente para frenar ese tipo de ataques.
Por lo tanto, la llave sigue ofreciendo autenticación resistente al phishing, pero hay que asumir que algunas expectativas de seguridad se rompieron.
Lo más molesto es que no se puede simplemente reemplazar una YubiKey.
Ya sea que uses passkeys o llaves no detectables, antes de descartar esta llave hay que ir cuenta por cuenta y cambiarla por una llave nueva que no sea vulnerable.
Que sea no detectable también es un problema, porque ya no recuerdo dónde usé la YubiKey antes.
El artículo de Ars [0] también menciona el PIN, pero eso no es una función exclusiva de YubiKey, sino una función de FIDO.
[0]: https://arstechnica.com/security/2024/09/yubikeys-are-vulner...
[1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...
Me pasó realmente cuando la aduana de Estados Unidos retuvo mis dispositivos electrónicos, incluida una YubiKey.
Más tarde pude recuperar muchas cuentas que aceptaban el correo electrónico como segundo factor o como último medio de verificación, pero algunas, incluida AWS, no.
Muchos sitios web recomiendan registrar autenticación de dos factores sin explicar claramente los métodos alternativos de autenticación ni las consecuencias de perder el acceso.
A las cuentas donde está registrada una YubiKey les pongo la etiqueta "YubiKey (FIDO)".
Aun así, la experiencia de usuario de todo este flujo todavía no está al nivel esperado.
En mi caso, también dejo un TOTP guardado en una app.
Si “todas las YubiKey 5 Series con firmware anterior a 5.7 están afectadas”, pensé que bastaría con actualizar el firmware del token físico de hardware.
Pero dice que el firmware de YubiKey no se puede actualizar.
https://support.yubico.com/hc/en-us/articles/360013708760-Yu...
Entonces Yubico va a ofrecer reemplazos gratuitos, ¿no? Tengo varias de esas YubiKey…
Es decir, si eres lo suficientemente valioso como para que te ataquen directamente en el mundo real, para empezar no deberías usar YubiKey.
Alguien podría sustituir tu llave de respaldo y quizá no te des cuenta hasta que sea demasiado tarde.
https://support.yubico.com/hc/en-us/articles/15705749884444-...
En cambio, mi YubiKey 4, que había salido hacía menos de dos meses, dejó de funcionar como smart card PIV con certificación de hardware.
Que sea “por un cálculo de inverso modular que no es de tiempo constante” no es un canal lateral sutil como emisiones electromagnéticas mínimas.
Si el tiempo varía según datos secretos es algo de lo primero que debería revisarse en una auditoría de canales laterales.
Basta con verificar que todas las operaciones usen siempre el mismo número de ciclos de reloj, independientemente de los datos, y que los errores también ocurran después de un número fijo de ciclos de reloj, sin depender de los datos.
Me pregunto cómo se les pasó esto a los auditores.
Si entendí bien el paper, lo que no es de tiempo constante no es la ejecución del algoritmo en sí, sino el ciclo de trabajo del canal lateral de RF observable desde afuera.
Si el tiempo de ejecución realmente no fuera constante, en el peor caso el ataque habría sido posible solo por USB, pero la implementación de Infineon no parece ser vulnerable a un ataque puramente temporal.
También está implementado el cegado del nonce, pero el problema es que usa una máscara de multiplicación mucho más pequeña que el tamaño de la curva elíptica, lo que permite fuerza bruta.
Aun así, la sonda en sí está genial.
Si alguien está dispuesto a acceder físicamente a una YubiKey, puede cambiarla por otra con un desgaste parecido y apariencia similar.
Entonces la víctima creerá que su YubiKey se descompuso, o el atacante ganará suficiente tiempo para usarla.
Por ejemplo, si tengo dos YubiKeys y alguien entra a escondidas a mi casa y cambia la llave de respaldo, no me daría cuenta hasta que intente usarla.
En definitiva, este ataque solo tiene sentido cuando el objetivo vale lo suficiente como para atacarlo directamente, y si es un objetivo así, supongo que usaría algo un poco más seguro que una YubiKey.
ykman listse puede revisar la información de identificación de la YubiKey, así que es fácil tener un procedimiento para comprobar si la llave se descompuso o si realmente fue cambiada.Si los requisitos de seguridad son altos, se puede verificar periódicamente o proteger por separado la ubicación física de la llave de respaldo.
También me da curiosidad qué autenticador de hardware sería más seguro que una YubiKey.
El atacante puede apuntar al dispositivo, interceptar comunicaciones, o ejecutar una orden judicial contra el servicio que aloja los datos o infiltrarse en él de forma encubierta.
PDF con la explicación de EUCLEAK: https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl...
Entrada del blog de Yubico: https://www.yubico.com/support/security-advisories/ysa-2024-...
El trabajo de NinjaLab es excelente.
Una parte especialmente interesante del aviso de Yubico es que esta clonación local también invalida la atestación (attestation) [1] del protocolo WebAuthn.
¿Se podría haber diseñado el protocolo para resistir mejor este ataque de clonación local?
“El atacante puede usar la clave de atestación recuperada para crear una YubiKey falsa. En este caso, durante make credential se genera una declaración de atestación FIDO válida, lo que permite eludir los controles de preferencia de modelos de autenticador de la organización para las versiones de YubiKey afectadas”.
Todo el modelo de seguridad de un elemento seguro consiste en impedir la extracción de la clave; si eso se vuelve posible, no es mejor que guardar la clave en un archivo de computadora.
Claro que para obtener la clave hay que abrir físicamente el dispositivo, así que sigue siendo más seguro que almacenarla en una computadora, siempre y cuando nadie se lleve realmente la llave.
Si ese secreto de atestación puede extraerse de alguna manera, no se puede impedir que el atacante cree un autenticador falso que produzca una atestación fraudulenta sin comportarse como uno auténtico.
En teoría, se podría reducir el impacto de la filtración de un único secreto de atestación usando atestación indirecta o claves de atestación únicas por autenticador.
Sería un esquema distinto a que cientos de miles de autenticadores, como las YubiKey, compartan la misma clave de atestación, pero aun así probablemente solo sería una mitigación probabilística.
En el sitio web de Yubico dice que la versión 5.7 y posteriores no están afectadas.
En otro artículo de Yubico [1], se menciona que una de las funciones de la versión 5.7 fue la migración a una biblioteca criptográfica propia de Yubico para realizar las operaciones criptográficas base de RSA y ECC.
Espero que mucha gente la haya revisado. En una época como la actual, con tantas implementaciones abiertas y cerradas, no entiendo bien por qué querrían usar una biblioteca criptográfica propia.
[1] https://www.yubico.com/blog/now-available-for-purchase-yubik...
Si toda la empresa se basa en criptografía, realmente tiene sentido contratar suficientes criptógrafos aplicados y tomar el control de tu propio destino.
También puede haber otras razones, y en software de código cerrado los factores económicos pesan mucho.
Especialmente si se está migrando desde una implementación anterior del proveedor, cerrada y quizá entregada como código fuente, hacia una implementación interna.
Infineon lo hizo otra vez. Hace 7 años también pasó algo así: https://en.wikipedia.org/wiki/ROCA_vulnerability
Se afirma que “Infineon ya cuenta con un parche para la biblioteca criptográfica, pero, hasta donde se sabe, aún no ha superado la evaluación de certificación Common Criteria”; sinceramente, esto no importa en absoluto.