La industria de custodia de criptoactivos operaba bajo una premisa extendida: la presencia de un Secure Element certificado bastaba para calificar un dispositivo como resistente.
El incidente de Coldcard, cuyo firmware reemplazó el generador de números aleatorios por hardware con una implementación de software que redujo la entropía a 40 bits, desmiente la premisa. Mi posición es que la evaluación de un hardware wallet debe iniciar por la trazabilidad del origen de la aleatoriedad, no por la certificación del chip que resguarda la clave.
Sostengo que el sector requiere un marco de análisis orientado a vectores de ataque verificables: extracción física, inyección de fallos, compromiso de cadena de suministro y generación de secretos. Los tres fabricantes responden de manera distinta a cada vector, y las diferencias importan más que las listas de funciones.
Ledger: Secure Element certificado y firmware propietario
El modelo de Ledger se basa en un Secure Element (SE) con certificación Common Criteria. Los modelos Nano S Plus, Stax, Flex y Nano Gen5 incorporan chips con certificación EAL6+, mientras que generaciones anteriores se mantenían en EAL5+. La función del SE es doble: almacenar material criptográfico y resistir ataques de canal lateral y manipulación física.
En generación de semillas, Ledger emplea un TRNG integrado en el Secure Element que produce 256 bits de entropía sin mecanismo de respaldo en software. La decisión de diseño descrita explica por qué la compañía pudo declarar que sus dispositivos no resultaron afectados por el fallo de Coldcard. Desde la ingeniería, eliminar el fallback de software reduce la superficie de ataque en el punto más sensible del ciclo de vida de una clave.
La contrapartida es el firmware propietario. Ledger somete el código a auditorías del equipo Donjon y a revisiones de firmas como EDSI y Synacktiv, pero la comunidad no puede verificar el binario completo. Para una parte del sector, la opacidad es un costo aceptable frente a la resistencia física del SE. Para otra parte, constituye un riesgo de confianza no mitigable por certificación.
El historial de filtraciones de datos de clientes en Ledger es un recordatorio de que seguridad operativa y seguridad del dispositivo son dominios separados. Un SE robusto no protege una base de datos de pedidos mal asegurada.
Trezor: transparencia open source y arquitectura multichip
El modelo de Trezor evolucionó desde una arquitectura de microcontrolador de propósito general hacia un esquema con Secure Element.
La serie Trezor Safe incorpora chips dedicados, y el Safe 7 emplea una arquitectura de doble chip: el TROPIC01, presentado como el primer SE auditable de forma independiente, junto con un OPTIGA Trust M de Infineon con certificación EAL6+.
El argumento central de Trezor es la ausencia de un punto único de fallo para el almacenamiento de secretos. La distribución de responsabilidades entre dos chips de proveedores distintos dificulta un ataque que dependa de una vulnerabilidad aislada.
La generación de entropía se apoya en el TRNG del dispositivo, y la firma mantiene firmware open source verificable en toda la pila, desde el boardloader hasta la aplicación.
El incidente de 2026 con el TROPIC01 merece un análisis separado. El equipo Donjon de Ledger documentó un ataque de inyección de fallos por láser sobre el chip. Trezor divulgó el hallazgo y sostuvo que el ataque exige posesión física, equipamiento de laboratorio y no compromete fondos, porque las claves no residen exclusivamente en el chip afectado.
Considero que la divulgación responsable y la arquitectura de doble chip limitaron el impacto, aunque el episodio demuestra que ningún SE es inmune a ataques físicos dirigidos.
Para el usuario que prioriza verificabilidad, Trezor ofrece una propuesta coherente. Para el usuario que prioriza resistencia física certificada, la comparación con Ledger depende del modelo y del adversario considerado.
Coldcard: air-gapped, Bitcoin-only y doble Secure Element
Coldcard se diseñó para un perfil de usuario avanzado en Bitcoin. La característica definitoria es el funcionamiento air-gapped: firma de transacciones mediante MicroSD o código QR, sin conexión a un equipo con acceso a red. Los modelos Mk4 y Q incorporan doble Secure Element con chips de dos fabricantes, Microchip ATECC608 y Maxim DS28C36B, bajo la lógica de que un atacante debe comprometer ambos para extraer el secreto maestro.
El firmware es open source, verificable, y el soporte se limita a Bitcoin, con funciones como multifirma y PSBT. La ausencia de altcoins reduce la superficie de código y simplifica la auditoría.
El fallo de entropía de 2026 altera la evaluación. Un error de firmware, activo entre marzo de 2021 y mediados de 2026, sustituyó el RNG por hardware con un sistema de software que degradó la entropía a 40 bits. La consecuencia fue la sustracción de más de 38 millones de dólares en Bitcoin y un daño reputacional severo para un dispositivo comercializado bajo criterios de paranoia operativa.
Mi lectura es que el caso Coldcard demuestra una jerarquía de riesgos que el sector tiende a invertir. La cadena de suministro y el almacenamiento reciben atención prioritaria, mientras la generación de semillas se trata como un componente resuelto. Un dispositivo con doble SE puede perder toda su ventaja si el proceso previo a la escritura de la clave produce material predecible.
Comparación de modelos y modelos de amenaza
La comparación útil no es de marcas sino de modelos de amenaza. Para un adversario remoto sin acceso físico, los tres dispositivos ofrecen garantías equivalentes en firma de transacciones y aislamiento de claves. Para un adversario con acceso físico y equipamiento de laboratorio, Ledger y Trezor Safe 7 presentan certificaciones EAL6+ y arquitecturas multichip, mientras Coldcard añade el modo air-gapped como capa adicional.
Para un adversario que explota debilidades de generación de aleatoriedad, la diferencia es decisiva. Ledger mantiene un TRNG en SE sin fallback. Trezor distribuye la responsabilidad entre chips. Coldcard sufrió una degradación documentada durante cinco años.
Considero que el sector subestima el riesgo de firmware frente al riesgo de hardware. Las certificaciones evalúan el silicio, no la lógica de arranque ni la implementación del RNG. Un programa de auditoría continua sobre el ciclo de vida completo, con verificación reproducible de binarios y pruebas de entropía en producción, resulta más relevante que una certificación estática.
