-
Kraken propone un estándar específico para validar la entropía.
-
Expertos discrepan sobre el costo de nuevos estándares.
La vulnerabilidad descubierta en las hardware wallets Coldcard continúa generando repercusiones más allá del robo de aproximadamente 600 bitcoin (BTC), en un inicio, cuya cifra alcanzó los ya los 2.000 BTC robados. Ahora, la discusión se centra en la forma en que los fabricantes verifican la generación de las semillas criptográficas que permiten recuperar una cartera. El incidente abrió un debate sobre los estándares de seguridad.
Nick Percoco, director de seguridad (CSO) del exchange Kraken, sostuvo que la industria debería adoptar un estándar específico para validar la entropía utilizada durante la creación de semillas.
Según Percoco, el incidente demostró que la certificación de componentes individuales, como los elementos seguros (secure elements), no garantiza que el firmware utilice correctamente esas fuentes de aleatoriedad. En su opinión, el proceso completo debe ser verificado por terceros y no únicamente la calidad del hardware.
CoinKite, fabricante de Coldcard, explicó que ciertas versiones del firmware generaron semillas con una entropía inferior a la prevista durante aproximadamente cinco años y medio. La compañía estima de forma preliminar unos 40 bits efectivos en los modelos Mk2 y Mk3, y cerca de 72 bits en Mk4, Mk5 y Q, frente a un objetivo de 128 bits. Una investigación sobre la vulnerabilidad detalló cómo un cambio de bibliotecas terminó alterando el proceso de generación de las semillas. El error se originó en la implementación del firmware.
Más allá de Coldcard: un estándar para evaluar fuentes de entropía
Percoco sostiene que el problema no fue la ausencia de hardware certificado, sino la falta de controles que confirmaran que el firmware realmente utilizaba esa fuente de entropía. Los modelos más recientes de Coldcard incorporaban elementos seguros capaces de generar números aleatorios, pero el código encargado de crear las semillas terminó utilizando una ruta distinta.
Para respaldar su argumento, el ejecutivo cita metodologías como NIST SP 800-90B, un estándar desarrollado por el Instituto Nacional de Estándares y Tecnología (NIST) de Estados Unidos para evaluar fuentes de entropía empleadas en módulos criptográficos. La propuesta toma como referencia estándares ya existentes.
Ese documento establece procedimientos para validar el origen físico de la aleatoriedad, recopilar grandes volúmenes de muestras, ejecutar pruebas estadísticas y realizar verificaciones independientes mediante laboratorios acreditados. Percoco reconoce que ese modelo fue diseñado para otros sectores, pero considera que parte de su metodología podría adaptarse al mercado de las hardware wallets.
El análisis también plantea que una certificación debería comprobar que la fuente de entropía validada sea la misma que utiliza el firmware distribuido a los usuarios. Además, propone que las certificaciones estén ligadas a versiones concretas de hardware y software, junto con un registro público donde los usuarios puedan verificar el estado de cada dispositivo. La validación debería abarcar todo el proceso criptográfico.
Ya hay pruebas preliminares para el estándar, pero aún requiere pasos extras
El planteamiento de Percoco encontró eco entre algunos desarrolladores de la industria, aunque no existe consenso sobre cómo implementarlo. Zach Herbert, fundador de Foundation Devices, comentó que su empresa busca certificaciones FIPS para Passport Prime, pero admitió que esos procesos requieren inversiones significativas y largos periodos de evaluación.
Mientras tanto, CoinKite incorporó un nuevo control de compilación para impedir que futuras versiones del firmware utilicen una fuente de entropía distinta de la prevista. Para Percoco, ese cambio demuestra que existían mecanismos relativamente simples para detectar este tipo de errores antes de distribuir el software.
El debate también coincidió con el seguimiento realizado por la comunidad sobre el movimiento de los bitcoin robados, un elemento que mantiene la atención sobre las consecuencias prácticas del incidente mientras continúan las investigaciones.
El hardware requiere más auditorías
El caso Coldcard también reabrió la discusión sobre el papel del software de código abierto dentro de la seguridad de las hardware wallets. Percoco sostiene que publicar el código facilita auditorías y acelera la detección de errores, pero advierte que la transparencia no sustituye las verificaciones independientes del comportamiento real del firmware. El código abierto no reemplaza una auditoría integral.
La discusión se suma a otros análisis publicados tras el incidente, entre ellos los que evaluaron el impacto del caso en Bitcoin y las medidas que los usuarios pueden adoptar para reducir riesgos. Una de ellas es el uso de passphrase adicionales, cuya eficacia frente a ataques por fuerza bruta depende de que sean suficientemente robustas.
Por ahora, la propuesta de Percoco no constituye un estándar formal ni cuenta con el respaldo de un organismo de certificación. Sin embargo, el caso Coldcard amplió la discusión desde un error específico hacia una pregunta más amplia: si la industria de las hardware wallets debería adoptar mecanismos independientes para verificar la generación de entropía, uno de los procesos más sensibles para la seguridad de los fondos en bitcoin. La confianza podría depender tanto de la verificación como del diseño del hardware.
