Ledger prueba firmas poscuánticas, pero admite fallas de seguridad

La posible llegada de la computación cuántica empuja a distintos actores del ecosistema de las criptomonedas a sumar protecciones frente a una amenaza que, aunque no es inminente, ya condiciona el diseño de nuevos productos.

En ese marco, Ledger sumó soporte experimental para ML-KEM y ML-DSA, dos algoritmos de criptografía poscuántica estandarizados por el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST), al chip elemento seguro (Secure Element, SE) de sus dispositivos desde el modelo Nano X en adelante. Ledger realiza estas pruebas poscuánicas en los SE a través de sus kits de desarrollo de software (SDK) en los lenguajes Rust y C, según anunció la compañía el 6 de julio.

Raf, director de Software Embebido y Control de Calidad de Ledger, confirmó el desarrollo en una publicación en la red social X y reconoció que «esto es experimental, la implementación todavía no es completamente segura. Falta mucho más, pero la base es sólida».

En el contexto de Bitcoin y la mayoría de las redes de criptoactivos, un atacante con una computadora cuántica suficientemente potente ejecutando el algoritmo de Shor podría, en teoría, obtener una clave privada de un usuario a partir de una clave pública basada en criptografía de curva elíptica (ECC) y autorizar transacciones sin conocer la clave privada de un usuario.

Los dispositivos de Ledger almacenan las claves privadas dentro del chip elemento seguro y generan las firmas criptográficas de las transacciones sin exponer esas claves al exterior. El algoritmo utilizado para firmar esas operaciones depende de la red correspondiente. En Bitcoin, por ejemplo, las transacciones pueden firmarse con el esquema de curva elíptica ECDSA o, en el caso de las direcciones Taproot, con firmas Schnorr.

La incorporación de ML-KEM y ML-DSA al elemento seguro no significa que los dispositivos Ledger hayan empezado a firmar transacciones de Bitcoin o Ethereum con algoritmos poscuánticos. Esas redes continúan aceptando únicamente los esquemas definidos por sus propios protocolos. Lo que cambió fue la integración de la capacidad en el elemento seguro de Ledger para ejecutar los algoritmos poscuánticos y exponerlos mediante nuevas funciones de los kits de desarrollo de software (SDK), que una aplicación puede invocar de la misma forma en que hoy invoca las funciones de ECDSA.

El SDK es el conjunto de herramientas y bibliotecas con el que los desarrolladores construyen aplicaciones para los dispositivos Ledger. A través de él, la nueva capacidad poscuántica del elemento seguro queda disponible para quien la necesite en el futuro: una red nueva, una actualización de protocolo, una cadena lateral o cualquier aplicación que decida adoptar criptografía poscuántica.

Lo que la propia Ledger reconoce que falta

El elemento seguro aísla las claves privadas de los algoritmos que las redes de criptoactivos utilizan, pero hacerlo también con las nuevas claves poscuánticas, protegiéndolas frente a ataques físicos, es un desafío distinto que Ledger todavía no resolvió por completo.

El elemento seguro es el chip aislado del resto del sistema operativo del dispositivo de Ledger y la seguridad de ese aislamiento no depende solo de la solidez matemática del algoritmo empleado, sino también de que su ejecución física no filtre información: un atacante con acceso físico al dispositivo puede, en teoría, medir el consumo eléctrico del chip o el tiempo que tarda en resolver cada operación para inferir la clave privada sin necesidad de romper la matemática detrás de ML-KEM o ML-DSA, según el documento técnico compartido por el equipo de Ledger.

Esa técnica se conoce como ataque de canal lateral (side-channel attack) y es independiente de la amenaza cuántica, ya que no requiere una computadora cuántica, solo acceso al dispositivo y equipamiento de medición.

Desde Ledger detallan que la implementación actual de ML-KEM y ML-DSA en el SDK no incluye contramedidas contra este tipo de ataques. La compañía adelantó que una futura versión sumará dos técnicas específicas para cerrar esa brecha: el enmascaramiento aritmético (arithmetic masking), que divide cada clave secreta en fragmentos aleatorios para que ninguna medición aislada revele el valor real, y la aleatorización de operaciones (shuffling), que cambia el orden en que se ejecutan los cálculos internos para que el patrón de consumo eléctrico no sea predecible. Ninguna de las dos está disponible todavía, y Ledger no precisó una fecha para su llegada.

El costo técnico: claves y firmas más pesadas

Las nuevas claves y firmas son considerablemente más pesadas que las actuales, de acuerdo con el equipo de Ledger. Como se ve en la siguiente imagen, una clave pública de ML-KEM-768 ocupa 1.184 bytes, frente a los 64 bytes de una clave pública equivalente basada en criptografía de curva elíptica (P-256/ ECDH). A su vez, una firma generada con ML-DSA-65 ocupa 3.309 bytes, frente a los 64 bytes de una firma con ECDSA, lo que implica un aumento de tamaño de hasta 50 veces.

Para que ese peso adicional funcione dentro de la memoria limitada de sus dispositivos, de entre 28 y 40 kilobytes según el modelo, Ledger optimizó el cálculo para generar cada componente de a uno por vez en lugar de cargarlo todo junto. Ledger asegura además que la salida de su implementación es, en sus palabras, «bit a bit idéntica» a los vectores de prueba oficiales del NIST.

El antecedente de Trezor

Como reportó CriptoNoticias, Trezor incorporó en octubre pasado protección poscuántica en el Boardloader de su wallet Safe 7, el primer programa que se ejecuta al encender el dispositivo, grabado de fábrica y que no puede modificarse después. Ese programa combina ECDSA con SLH-DSA-128, un algoritmo de firma digital de la familia SPHINCS+ que, a diferencia de ML-DSA empleado por Ledger, basa su resistencia cuántica en funciones hash en lugar de retículos, aunque cumple el mismo propósito: probar que una operación fue autorizada por quien posee la clave privada. El NIST también lo estandarizó en 2024. Además, Trezor distribuyó ML-DSA-44, una variante del mismo algoritmo que incorporó Ledger, en uno de los tres chips que integran su dispositivo.»

La diferencia entre los enfoques de ambas empresas está en el grado de madurez. En Trezor, la protección quedó grabada de fábrica; en Ledger, en cambio, ML-KEM y ML-DSA llegan por ahora como una capacidad experimental dentro del SDK, sin estar integrados todavía como firmware de fábrica en los dispositivos ya vendidos.

Charles Guillemet, director de Tecnología (CTO) de Ledger, explicó la lógica detrás de correr estos algoritmos sobre un elemento seguro con una pantalla confiable: «La criptografía poscuántica no sirve de nada si la clave privada sigue viviendo en una máquina que puede mentirte sobre lo que está firmando».

De este modo, mientras Trezor ya grabó protección poscuántica de fábrica en un componente inalterable, Ledger avanza con una capa experimental que la propia compañía todavía no considera del todo segura.