La divulgación del fallo de entropía en dispositivos Coldcard reabrió un debate recurrente en el sector: si las hardware wallets constituyen un punto de fallo dentro de la custodia propia.
La premisa merece una corrección técnica. Un error de implementación en la generación de semillas no invalida el modelo de aislamiento de claves privadas.
Lo que expone es que la seguridad de la custodia propia se sostiene sobre una cadena de procesos, y que los puntos de fallo más probables se concentran en la generación de entropía, la firma de transacciones, la cadena de suministro y el comportamiento del operador. Atribuir el problema al hardware desvía la atención de los controles que sí reducen el riesgo de forma medible.
El caso Coldcard: fallo de proceso, no de arquitectura
El incidente Coldcard involucró firmware desde la versión 4.0.1, en el que el generador de números aleatorios basado en software sustituyó al RNG de hardware en determinados flujos de creación de semilla.
El resultado fue la producción de frases semilla predecibles, reconstruibles por un tercero con acceso a la lógica del generador. Las pérdidas acumuladas superaron los 100 millones de dólares en bitcoin.
El análisis correcto separa dos capas: la arquitectura de aislamiento del dispositivo, que no fue vulnerada, y el proceso de inicialización, que sí lo fue. La distinción importa porque define dónde debe asignarse la inversión en controles y dónde no.
La entropía como raíz de confianza
La entropía es la raíz de confianza de cualquier esquema de custodia. Una clave privada derivada de una fuente predecible reduce el espacio de búsqueda a un conjunto enumerable, independientemente de la robustez del elemento seguro que la almacene después.
La corrección aplicada por Coldcard exige aporte externo de entropía: 65 pulsaciones de tecla, 50 tiradas de dado o 128 lanzamientos de moneda.
La lección operativa es que la verificación de la fuente de aleatoriedad debe formar parte del procedimiento de configuración, no quedar delegada a la confianza en el fabricante. Un dispositivo con elemento seguro certificado y una semilla generada con entropía deficiente ofrece menos seguridad que un dispositivo sin certificación con entropía verificada por el usuario.
La firma de transacciones como superficie de ataque
El segundo punto de fallo es la firma de transacciones. Los retiros no autorizados de mayor magnitud en los últimos ciclos no provienen de criptografía rota, sino de firmas válidas obtenidas mediante engaño.
El caso Bybit, con aproximadamente 1.500 millones de dólares drenados, ilustró un patrón: el firmante autorizó operaciones cuya semántica real no era visible en la interfaz del dispositivo.
La limitación no es la clave, sino la capacidad de visualización del hardware. Un firmware que no puede renderizar el destino, el monto, el contrato y el efecto de una firma deja al operador en una posición de firma ciega.
La mitigación requiere interfaces que expongan el payload completo y flujos que rechacen operaciones no verificables. El hardware protege la clave; no protege la decisión del operador si el operador no puede evaluar lo que firma.
Cadena de suministro, firmware y límites del air-gap
La cadena de suministro y la integración de firmware añaden superficie de ataque. El incidente de Ledger Connect Kit demostró que software malicioso puede alcanzar la etapa inmediatamente anterior a la aprobación final en el dispositivo.
La técnica Dark Skippy mostró que información de semilla puede codificarse dentro de firmas de transacción con apariencia normal, lo que limita el valor del air-gap como control único. La conclusión no es descartar el aislamiento físico, sino combinarlo con verificación de firmware, reproducibilidad de compilación cuando esté disponible y separación de proveedores. La seguridad de la cadena de suministro es un problema de verificación, no de confianza en la marca.
El argumento de fondo: eliminar la contraparte
El argumento a favor de la custodia propia no depende de que el hardware sea infalible. Depende de que elimina la contraparte.
La insolvencia de FTX evidenció que los saldos en exchanges son obligaciones contractuales registradas en una base de datos, no claves bajo control del usuario.
Cuando la plataforma suspendió retiros, los titulares no pudieron ejercer disposición sobre activos que contabilizaban como propios. La custodia propia no elimina el riesgo operativo, pero traslada el control a un conjunto de procedimientos que el titular puede auditar, replicar y modificar sin autorización de terceros.
Ruta de recuperación independiente
La custodia propia conserva valor porque mantiene una ruta de recuperación independiente. Mientras exista una clave válida o un respaldo legible, el titular puede reconstruir el acceso mediante herramientas compatibles aunque el fabricante discontinúe el producto o el servicio.
La portabilidad de estándares como BIP-39 y BIP-32 permite migrar entre implementaciones sin depender de la continuidad de un proveedor. La capacidad de transferir activos sin esperar la apertura de retiros de una plataforma es una propiedad operativa, no una preferencia ideológica.
La custodia delegada reintroduce un punto de control que puede denegar acceso en el momento de mayor necesidad.
Diversificación de dependencias
La respuesta proporcional al riesgo no es abandonar el hardware, sino diversificar dependencias. Para tenencias reducidas, un dispositivo correctamente inicializado y respaldado puede ser suficiente.
Para tenencias mayores, la concentración en un fabricante, un firmware o un procedimiento de respaldo introduce riesgo de punto único.
La distribución entre dispositivos de proveedores distintos, con passphrase adicional y respaldos en ubicaciones separadas, reduce la probabilidad de pérdida total ante un fallo individual. La diversificación no elimina el riesgo; lo reparte en componentes con modos de fallo no correlacionados.
Controles operativos verificables
Las prácticas que reducen riesgo de forma medible incluyen: generar entropía con dados o monedas en lugar de aceptar la generación por defecto; verificar dirección, monto y contrato en la pantalla del dispositivo y no en la interfaz del host; mantener el firmware actualizado con verificación de firma; almacenar respaldos fuera de línea con redundancia geográfica; y documentar un plan de herencia con instrucciones verificables.
Ninguna de las medidas descritas depende del fabricante ni de la continuidad de un servicio. Todas son ejecutables por el titular con recursos accesibles.
