Seguridad de monederos de hardware de bitcoin: Lecciones del defecto en la generación de semillas de Coldcard
2026/08/09 08:05:06
Bug en la generación de semillas de Coldcard expone debilidades en la seguridad de monederos de bitcoin
Un cambio de firmware en marzo de 2021 en los monederos físicos de bitcoin Coldcard de Coinkite redirigió la generación de semillas lejos del generador de números aleatorios hardware STM32 previsto hacia un generador de números seudoaleatorios de software determinista. El error permaneció sin detectar hasta finales de julio de 2026, cuando atacantes vaciaron más de 1.000 direcciones de bitcoin en oleadas coordinadas, retirando aproximadamente entre 1.082 y 1.367 BTC, valorados entre $70 millones y $88 millones en ese momento. Galaxy Research mapeó la primera oleada de 41 minutos que afectó a 1.196 direcciones el 30 de julio y posteriormente identificó oleadas adicionales que ampliaron el total observado. El equipo de ingeniería de Block y investigadores independientes rastrearon la causa raíz hasta una verificación de macro del preprocesador que vinculaba libngu al mecanismo de respaldo Yasmarang de MicroPython, el cual se inicializaba a partir del ID único del chip y los registros del temporizador en lugar de entropía fresca.
Coinkite confirmó el problema en los modelos Mk2, Mk3, Mk4, Mk5 y Q, lanzó un firmware de emergencia al día siguiente y instruyó a los usuarios a generar semillas completamente nuevas, ya que actualizar el firmware existente no puede reparar una frase de recuperación comprometida. El episodio ha renovado el escrutinio sobre cómo los monederos de hardware obtienen y verifican la entropía, los límites prácticos de la revisión de código abierto y los riesgos residuales que persisten incluso en dispositivos aislados. La falla en la generación de semillas de Coldcard demuestra que los monederos de hardware siguen dependiendo de la integración correcta del firmware con las fuentes de entropía; un solo error de configuración que duró cinco años puede reducir la aleatoriedad efectiva mucho por debajo del objetivo de 128 bits de una semilla estándar BIP-39, permitiendo la reconstrucción offline de claves privadas y robos a gran escala que ninguna cantidad de aislamiento físico puede prevenir una vez que la semilla misma es débil.
Cómo una migración de firmware de 2021 deshabilitó el RNG del hardware de Coldcard
En marzo de 2021, Coinkite migró las operaciones de curva elíptica de Coldcard a libsecp256k1 de Bitcoin Core e introdujo la biblioteca libngu MicroPython. El código de generación de semillas cambió de la llamada específica de la placa ckcc.rng_bytes, que invocaba correctamente el generador de números aleatorios verdaderos por hardware STM32, a ngu.random.bytes. La configuración de la placa de producción definía MICROPY_HW_ENABLE_RNG como cero porque Coinkite proporcionaba su propio envoltorio de RNG por hardware. La verificación del preprocesador de libngu solo comprobaba si la macro estaba definida, no si su valor era distinto de cero. Como resultado, la compilación tuvo éxito y se vinculó con la alternativa de software Yasmarang de MicroPython. Esa alternativa se inicializó una sola vez, utilizando los 32 bits menos significativos del ID único del chip XOR con los registros de tiempo SysTick y RTC, y luego produjo un flujo determinista sin recopilar más entropía.
En los dispositivos Mk2 y Mk3 que ejecutan las versiones 4.0.1 a 4.1.9, la ruta proporcionada no ofrecía esencialmente ninguna entropía criptográfica. Posteriormente, los firmwares Mk4, Mk5 y Q combinaban valores del elemento seguro, pero conservaban solo cuatro bytes tras el hash y los utilizaban para volver a inicializar una única palabra de estado de 32 bits, dejando aproximadamente 72 bits de entropía efectiva frente a los 128 bits previstos. El código intencionado del RNG de hardware permanecía presente en el binario, pero nunca se alcanzaba mediante la ruta de generación del monedero. La revisión de código existente confirmó la presencia de la implementación TRNG, pero no verificó la resolución simbólica de extremo a extremo desde el punto de llamada de generación de la semilla. Por lo tanto, la regresión persistió sin detectar durante más de cinco años hasta que su explotación activa forzó la divulgación pública.
Efecto y resultado
La consecuencia práctica es que un atacante que pueda limitar o obtener el UID del dispositivo, el tiempo aproximado de arranque y el historial de llamadas previas al RNG puede regenerar flujos de salida candidatos en off-line. Cada candidato puede expandirse en una semilla BIP-39, derivarse en direcciones y verificarse contra la cadena de bloques pública. Para los dispositivos Mk3 más gravemente afectados, Coinkite estimó el espacio de búsqueda efectivo en aproximadamente 40 bits; el análisis de Block colocó límites condicionales muy por debajo de los niveles de seguridad criptográfica para modelos posteriores.
Hashear la salida débil o aplicar el checksum de BIP-39 no puede aumentar el número de semillas posibles. Una vez que se encuentra una dirección coincidente, la clave privada correspondiente controla cada derivación posterior, permitiendo un drenaje completo sin acceso físico al dispositivo. La superficie de ataque sigue, por lo tanto, la frase de recuperación en sí, no el hardware que actualmente la contiene. Restaurar una semilla afectada en un firmware actualizado o en cualquier otro monedero simplemente transfiere el mismo secreto débil.
Galaxy Research mapea el barrido del 30 de julio y las olas subsiguientes
El 30 de julio de 2026, un operador no identificado vació 1.196 direcciones de bitcoin en un período de 41 minutos, retirando 1.082,65 BTC valorados en aproximadamente $70,2 millones. Galaxy Research identificó el cluster mediante una tasa de tarifa distintiva de 30 sat/vB y la ausencia de salidas de cambio, patrones que se destacaban frente a la actividad on-chain normal. La empresa posteriormente documentó dos olas adicionales que elevaron el total acumulado observado a 1.367,05 BTC en 4.585 direcciones, equivalente a aproximadamente $88,6 millones a los precios vigentes. Galaxy advirtió que las heurísticas on-chain por sí solas no prueban computacionalmente que cada dirección proviniera de una entropía débil de Coldcard, pero la agrupación temporal y la conexión técnica proporcionada por el análisis de causa raíz de Block hicieron que la conexión fuera altamente probable.
La empresa informó aproximadamente 600 direcciones sospechosas controladas por atacantes a investigadores y servicios de cumplimiento. No se ha publicado ninguna reconstrucción pública de una semilla específica de víctima, sin embargo, la escala de los saqueos demostró que la entropía reducida fue suficiente para una enumeración offline práctica una vez que se conocieron o aproximaron las restricciones necesarias del estado del dispositivo. La velocidad de la primera ola subraya que la vulnerabilidad no requería interacción en tiempo real con los monederos físicos. Una vez que se pudieron generar y validar semillas candidatas contra direcciones conocidas con fondos, el operador simplemente firmó y transmitió transacciones.
Olas posteriores continuaron tras el aviso de Coinkite, lo que indica que no todos los titulares habían completado la migración. Galaxy señaló que el patrón de transacción identifica más al operador que el robo en sí, ya que un propietario legítimo que consolida monedas puede producir firmas en cadena idénticas. La ausencia de actividad previa que comparta las mismas características de tarifa y cambio en los treinta días anteriores fortaleció la atribución a una sola campaña en lugar de un comportamiento orgánico de los usuarios. Por lo tanto, el incidente ilustra tanto el poder del análisis de la cadena de bloques para la detección rápida como los límites de esas herramientas cuando la debilidad criptográfica subyacente se origina fuera de línea.
Respuesta de emergencia y parches de firmware de Coinkite
Coinkite emitió su primer aviso público el 31 de julio de 2026 y amplió el alcance al día siguiente tras un análisis adicional. Se lanzaron versiones fijas de firmware para cada modelo afectado: 4.2.0 para Mk2 y Mk3, 5.6.0 para Mk4 y Mk5 estándar, 1.5.0Q para Q estándar, y las compilaciones Edge correspondientes 6.6.0X y 6.6.0QX. La empresa detuvo los envíos de stock vulnerable y destruyó el inventario restante. Las guías oficiales enfatizaron que instalar el nuevo firmware no repara una semilla existente; se debe generar una semilla completamente nueva en el dispositivo actualizado, y los fondos deben migrarse tras verificar la nueva copia de seguridad y la dirección de recepción.
Coinkite estimó la entropía efectiva en aproximadamente 40 bits para las semillas Mk3 afectadas y alrededor de 72 bits para las semillas Mk4, Mk5 y Q previas a la corrección. El aviso excluyó explícitamente las semillas creadas con al menos 50 lanzamientos de dados justos, independientes y privados, ya que la contribución de los dados por sí sola proporcionaba los 128 bits requeridos y se combinó mediante hash con la salida del dispositivo. Se reconoció que contraseñas BIP-39 fuertes y únicas constituyen una barrera adicional que impide que un atacante que recupere solo las palabras de la semilla acceda a los fondos, sin embargo, la empresa recomendó aún así una migración completa porque la semilla subyacente sigue siendo débil.
Las instrucciones de migración enfatizaron una verificación secuencial y tranquila: confirmar la versión fija del firmware, generar la nueva semilla, registrar y verificar la copia de seguridad y la huella digital, enviar una transacción de prueba pequeña, y luego mover el resto, manteniendo la copia de seguridad antigua hasta la confirmación. Los usuarios cuyo único dispositivo era un Mk2 o Mk3 recibieron un procedimiento cuidadoso para un solo dispositivo que alterna entre las semillas antiguas y nuevas. Coinkite también señaló que los productos TAPSIGNER, OPENDIME y SATSCARD utilizan bases de código separadas y permanecen sin afectar. La respuesta demostró tanto las ventajas de un modelo de firmware de código abierto que permitió una corrección rápida como la dificultad práctica de comunicar la urgencia a una base de usuarios dispersa que pudo haber generado semillas hace años y luego dejado los dispositivos desconectados.
Estimaciones de entropía y por qué 40 o 72 bits no alcanzan los objetivos de BIP-39
Una semilla BIP-39 estándar de 12 palabras está diseñada para proporcionar 128 bits de seguridad. Cuando la fuente de entropía subyacente se reduce a aproximadamente 40 bits en los dispositivos Mk3 o 72 bits en modelos posteriores, el espacio combinatorio se vuelve buscable con recursos computacionales modernos. El análisis de Block mostró que el fallback MicroPython Yasmarang, una vez inicializado desde valores fijos o restringidos, produce un flujo completamente determinista. En los dispositivos Mk4 y posteriores, la contribución del elemento seguro se reduce a un resemilla de 32 bits de una sola palabra de estado; las salidas posteriores permanecen dentro de una familia de como máximo 2^32 flujos para cualquier estado previo fijo y historial de llamadas.
El hash determinístico de esa salida no puede ampliar la familia. En consecuencia, un atacante que obtenga o aproxime los parámetros de inicialización necesarios puede enumerar candidatos en off-line, derivar las direcciones correspondientes y hacer coincidirlas con el conjunto público de UTXO. El costo está dominado por la derivación de direcciones en lugar de adivinaciones aleatorias puras, pero sigue siendo factible a la escala observada de robos. Las cifras preliminares de Coinkite coinciden con evaluaciones independientes que indican que la entropía residual es insuficiente para la autosupervisión a largo plazo de saldos significativos.
La brecha no es teórica; las operaciones de liquidación del 30 de julio y las olas subsiguientes proporcionaron confirmación empírica de que el espacio reducido ya estaba siendo explotado. Incluso la estimación más alta de 72 bits para modelos posteriores deja un margen mucho por debajo del nivel de seguridad esperado por los usuarios que eligieron monederos de hardware precisamente para evitar fallos de entropía en monederos de software. Por lo tanto, este episodio proporciona un punto de calibración concreto para el diseño futuro de monederos de hardware: cualquier ruta que pueda volver silenciosamente a un PRNG de software sembrado desde un estado de dispositivo no criptográfico debe rechazarse en tiempo de compilación, no simplemente revisarse después del hecho.
Lanzamientos de dados y frases de acceso como mitigaciones parciales
El asesoramiento de Coinkite estableció una distinción clara para las semillas que incorporaron al menos 50 tiradas de dados justas, independientes y privadas ingresadas a través de la interfaz dedicada del dispositivo. En esos casos, la entropía de los dados sola cumplía o superaba el objetivo de 128 bits y se combinó con la salida débil del dispositivo antes de mostrar las palabras finales de la semilla. Siempre que las tiradas nunca se registraran ni observaran, la semilla resultante se considera fuera del alcance del defecto del RNG. Menos de 50 tiradas, o cualquier incertidumbre sobre el número o la privacidad de las tiradas, devuelve la semilla a la categoría de riesgo.
Una frase de paso BIP-39 fuerte y única crea un monedero independiente que no se puede acceder solo con las palabras de semilla; un atacante también debe recuperar la frase de paso. Frases de paso cortas, comunes o reutilizadas no califican. Incluso cuando existe una frase de paso fuerte, Coinkite recomienda una migración eventual porque la semilla subyacente sigue siendo criptográficamente débil y la frase de paso se convierte en un punto único de fallo si alguna vez se expone. Estas mitigaciones ilustran el valor de las defensas en capas, pero también su incompletitud. Los lanzamientos de dados requieren procedimientos físicos disciplinados que muchos usuarios nunca realizaron.
Las frases de paso requieren una copia de seguridad separada cuidadosa y un recuerdo exacto; un solo error tipográfico produce una monedero diferente y vacío. Ninguna de estas medidas restaura la entropía que el firmware no suministró, y ninguna protege las funciones avanzadas del dispositivo que siguen dependiendo de la misma ruta debilitada de números aleatorios. Los usuarios que confiaron únicamente en la generación predeterminada de semillas por parte del dispositivo enfrentaron el pleno impacto del espacio de búsqueda reducido, mientras que aquellos que ya habían adoptado entropía adicional o frases de paso ganaron tiempo, pero no seguridad permanente.
Configuraciones de multifactores y los límites del riesgo compartido
Cuando todas las claves de un quórum de firma múltiple se generan en un Coldcard afectado, toda la política se vuelve gastable por un atacante que recupera las semillas débiles. Una disposición 2-de-3 en la que dos de las tres semillas provienen de firmware vulnerable aún permite al atacante cumplir el umbral una vez que se conocen esas dos semillas. Solo las configuraciones que conservan al menos una clave externa fuerte fuera del conjunto afectado preservan la seguridad. Liana y otros monederos basados en miniscript introducen consideraciones adicionales de ruta: una ruta principal que puede satisfacerse únicamente con claves débiles de Coldcard es inmediatamente gastable, mientras que una ruta de recuperación restringida por un timelock permanece protegida solo mientras la bloqueo esté activo. Gastar desde un monedero SegWit revela el descriptor completo en la primera transacción, lo que posiblemente permite reconstruir todas las direcciones si todas las claves son débiles.
Taproot limita la revelación al camino utilizado, reduciendo el radio de impacto, pero aún expone las claves débiles que participan en ese camino. La lección práctica es que la diversidad de hardware y las fuentes de entropía independientes siguen siendo esenciales incluso dentro de los esquemas de multifactores. Depender de múltiples dispositivos del mismo modelo y generación de firmware concentra el riesgo en lugar de distribuirlo. Los usuarios que combinaron claves de Coldcard con claves de otros proveedores o con semillas generadas con dados conservaron una protección parcial; aquellos que se estandarizaron en una sola línea de productos vulnerable descubrieron que el umbral de cuórum no ofrecía ninguna defensa una vez explotada la falla de entropía. Por lo tanto, el incidente refuerza las recomendaciones de larga data sobre fuentes heterogéneas de claves, demostrando que esta recomendación no es meramente teórica.
Fallas en la revisión de código abierto y el papel de la IA en el descubrimiento
El firmware de Coldcard ha estado publicado durante mucho tiempo bajo una licencia de código abierto, lo que permite una inspección independiente. Sin embargo, el error de integración del RNG sobrevivió múltiples ciclos de lanzamiento y escrutinio externo. Las revisiones existentes verificaron que la implementación de RNG de hardware prevista existía en el binario, pero no confirmaron que el punto de llamada para la generación del monedero realmente alcanzara esa implementación en lugar del respaldo de MicroPython. La protección del preprocesador utilizó #ifndef en lugar de una verificación de valor, lo que permitió que una definición cero pasara en silencio. Coinkite señaló que incluso la revisión de código reciente asistida por IA realizada por la propia empresa no detectó el problema, mientras que los atacantes o los investigadores que primero identificaron la debilidad podrían haberse beneficiado de herramientas similares. Por lo tanto, este episodio pone de manifiesto una brecha persistente entre la presencia del código fuente y la verificación del comportamiento en tiempo de ejecución a través de límites de submódulos.
La latencia de cinco años también ilustra la dificultad de detectar fallos de entropía silenciosos. A diferencia de los desbordamientos de búfer o errores de firma que producen bloqueos inmediatos o firmas inválidas, un PRNG débil continúa generando semillas que parecen plausibles y pasan las verificaciones de coherencia interna. Solo posteriormente, mediante enumeración fuera de línea contra la cadena de bloques, se revela la deficiencia. Los procesos de revisión futuros necesitarán auditorías explícitas de extremo a extremo de la entropía que obliguen al sistema de compilación a rechazar cualquier ruta de respaldo y que midan la calidad estadística de la salida bajo condiciones controladas. El código abierto sigue siendo una condición necesaria para la confianza, pero el caso de Coldcard muestra que no es una condición suficiente sin una verificación dirigida de las rutas de código más críticas para la seguridad.
Practicidad de la migración y el riesgo de transferencias apresuradas
Coinkite enfatizó repetidamente que una migración apresurada puede crear nuevos vectores de pérdida que superan el riesgo original. Se instruyó a los usuarios a verificar la versión fija del firmware en el dispositivo, generar la nueva semilla solo después de la actualización, registrar la copia de seguridad y la huella digital sin conexión, confirmar una dirección de recepción en la pantalla del dispositivo y mover una cantidad pequeña de prueba antes de transferir la mayor parte de los fondos. Los propietarios de un solo dispositivo enfrentaron pasos adicionales de alternar entre la semilla antigua y la nueva, manteniendo ambas copias de seguridad intactas hasta la confirmación final. Cualquier error en el orden de las operaciones, cualquier dirección mal escrita o cualquier destrucción prematura de la copia de seguridad antigua podría quedar permanentemente atrapada la moneda.
La empresa también advirtió contra la restauración de una semilla afectada en un nuevo dispositivo o monedero de software, ya que la debilidad viaja con la frase en sí. El volumen de monederos afectados y los continuos saqueos generaron presión de tiempo que entró en conflicto con la necesidad de un procedimiento deliberado. Muchos titulares a largo plazo habían generado semillas hace años, almacenado los dispositivos fuera de línea y conservado únicamente copias en papel. Reconstruir la versión exacta del firmware en uso en el momento de la generación no siempre fue sencillo. Por lo tanto, el aviso equilibró urgencia y cautela, instando a una acción inmediata para semillas no protegidas, mientras insistía en pasos de verificación que eviten pérdidas autoinfligidas. La tensión entre velocidad y seguridad sigue siendo una característica inherente de cualquier migración masiva de semillas y volverá a aparecer en futuros incidentes relacionados con monederos de hardware.
Contexto de la industria: Monederos de hardware tras el incidente de Coldcard
La vulnerabilidad de Coldcard llega tras episodios anteriores de entropía débil en entornos de software y hardware, incluyendo la investigación Ill Bloom que vinculó un problema separado de PRNG en una billetera de software con pérdidas superiores a $5 millones en múltiples cadenas. Las billeteras de hardware fueron durante mucho tiempo comercializadas como la solución definitiva contra fallos de entropía de software y malware. Los eventos de 2026 demuestran que el límite protector es tan fuerte como el firmware que implementa la ruta de entropía. Los competidores que dependen de elementos seguros diferentes, arquitecturas de números aleatorios distintas o procesos de revisión diferentes no han sido implicados, pero el mercado en general ahora debe enfrentar la posibilidad de que errores de integración similares puedan existir en otros lugares. Es probable que aumente la demanda de herramientas independientes para medir la entropía, verificación formal de gráficos de llamadas RNG y interfaces estandarizadas de lanzamientos de dados o entropía externa.
Los defensores de la autosuficiencia enfrentan un desafío paralelo. El incidente ya ha generado discusiones públicas sobre si los tenedores a largo plazo deberían considerar almacenamiento diversificado, incluyendo productos regulados, para una parte de sus activos. Al mismo tiempo, la rápida liberación del firmware fijo y la transparencia de las divulgaciones técnicas reafirman las ventajas de los ecosistemas de hardware abierto que pueden responder en horas en lugar de meses. El efecto neto es una calibración más realista del riesgo, en lugar de un rechazo total de los monederos de hardware. Los usuarios que consideran el dispositivo como un componente dentro de un modelo de seguridad en capas que incluye entropía externa, frases de contraseña y diversidad multisignatura mantienen una protección más sólida que aquellos que tratan cualquier producto individual como una salvaguardia absoluta.
Lecciones para el diseño futuro de monederos de hardware
Los sistemas de compilación deben exigir la presencia de un RNG de hardware verificado en los puntos de llamada exactos utilizados para la generación de semillas; un retroceso silencioso a un PRNG de software sembrado con metadatos del dispositivo es inaceptable. Las comprobaciones del preprocesador deben evaluar el estado activado de las funciones de entropía, no simplemente su definición. Las contribuciones del elemento seguro deben conservar toda la entropía en lugar de truncarse a 32 bits antes de volver a sembrar una máquina de estados débil. Las pruebas de extremo a extremo que midan la calidad estadística de las semillas generadas bajo condiciones de arranque realistas deben convertirse en criterios estándar de lanzamiento.
La documentación debe aclarar que la versión del firmware en el momento de la generación del seed, no la versión actualmente instalada, determina la exposición. Finalmente, las interfaces de usuario deben mostrar el estado de la fuente de entropía y fomentar o requerir dados suplementarios o entropía externa para monederos de alto valor. Estos cambios de diseño son incrementales, pero habrían evitado la regresión de Coldcard y reducirían la probabilidad de fallos similares en otros productos.
Pasos prácticos para propietarios actuales de Coldcard
Los propietarios que generaron semillas en el firmware Mk2 o Mk3 4.0.1–4.1.9, o en Mk4, Mk5 o Q antes de las versiones corregidas del 31 de julio, deben considerar las semillas como comprometidas a menos que puedan confirmar al menos 50 lanzamientos de dados privados o una frase de contraseña única y segura. Instale el firmware corregido correspondiente desde las páginas de descarga oficiales de Coinkite, genere una nueva semilla en el dispositivo actualizado, verifique la copia de seguridad y la huella digital sin conexión, confirme una dirección de recepción en la pantalla del dispositivo, envíe una pequeña transacción de prueba y solo luego migre el saldo restante.
Mantenga la copia de seguridad antigua hasta que el nuevo monedero muestre la cantidad completa confirmada. Los usuarios que nunca generaron una semilla en un dispositivo afectado pero que importaron una semilla afectada a otro monedero aún deben migrar, porque la debilidad reside en la frase. Los participantes de multisignatura deben evaluar cada clave de forma independiente según su dispositivo y firmware de generación. El aviso oficial y el documento técnico de fondo siguen siendo las referencias autorizadas para las instrucciones específicas del modelo.
Implicaciones más amplias para las prácticas de auto-custodia de bitcoin
El episodio de Coldcard refuerza que la autosuficiencia es un proceso continuo, no una compra única de hardware. La calidad de la entropía, la procedencia del firmware, la verificación de copias de seguridad y la diversidad de claves deben revisarse periódicamente. El análisis en cadena puede detectar explotaciones a gran escala rápidamente, pero los titulares individuales aún tienen la responsabilidad de monitorear los canales oficiales y actuar según los avisos. Es probable que el mercado para auditorías de seguridad independientes del firmware de monederos hardware se expanda, al igual que la demanda de herramientas que permitan a los usuarios medir la entropía efectiva de sus semillas sin exponerlas.
Al mismo tiempo, el incidente no invalida el valor fundamental del almacenamiento de claves fuera de línea; simplemente demuestra que el límite fuera de línea debe complementarse con una fuerza criptográfica verificada en el momento de la generación de la clave. Los titulares que combinan hardware actualizado, entropía adicional, frases de contraseña y acuerdos de firma múltiple continúan controlando sus propias claves con un mayor grado de certeza que aquellos que confían en una sola capa.
|
KuCoin celebra su 9º aniversario con una campaña especial de plataforma llena de recompensas exclusivas, actividades de trading y ofertas de tiempo limitado. No pierdas la oportunidad de participar y disfrutar de los beneficios mientras el exchange conmemora nueve años de crecimiento e innovación. Visita la página oficial de la campaña ahora:
|
Preguntas frecuentes
¿Qué versiones de firmware de Coldcard están afectadas por la falla en la generación de la semilla?
Los dispositivos Mk2 y Mk3 que ejecutan las versiones 4.0.1 a 4.1.9 inclusive generaron semillas con aproximadamente 40 bits de entropía efectiva. Los dispositivos Mk4 y Mk5 antes de la versión estándar 5.6.0 o la versión Edge 6.6.0X, y los dispositivos Q antes de la versión estándar 1.5.0Q o la versión Edge 6.6.0QX, produjeron semillas con aproximadamente 72 bits de entropía. La exposición se determina por la versión del firmware presente en el momento en que se creó la semilla, no por la versión actualmente instalada. Las versiones corregidas solucionan la generación de nuevas semillas, pero no pueden reparar semillas débiles ya existentes. Las páginas de descarga oficiales listan las versiones corregidas para cada modelo y línea de lanzamiento. Los usuarios que generaron semillas fuera de estos rangos, o aquellos que utilizaron al menos 50 lanzamientos de dados privados, no caen dentro de la categoría de riesgo principal.
¿Protege la actualización del firmware en un Coldcard existente una semilla ya generada?
No. La vulnerabilidad reside en la entropía utilizada para crear las palabras de semilla. Instalar un firmware fijo solo cambia la ruta de generación para futuras semillas. Restaurar una frase de recuperación afectada en un firmware corregido o en cualquier otro monedero simplemente transmite el mismo secreto débil. La única solución confiable es generar una nueva semilla completamente en un firmware corregido y migrar los fondos tras verificar completamente la nueva copia de seguridad y la dirección de recepción. El aviso de Coinkite es explícito en este punto y proporciona procedimientos paso a paso para la migración en escenarios de múltiples dispositivos y de un solo dispositivo.
¿Siguen siendo seguras las semillas creadas con tiradas de dados?
Las semillas que incorporan al menos 50 tiradas de dados justas, independientes y privadas ingresadas a través de la interfaz oficial del dispositivo reciben suficiente entropía únicamente de las tiradas de dados. El dispositivo hashiza esas tiradas junto con su propia salida (débil), por lo que la semilla final cumple o supera el objetivo de 128 bits siempre que las tiradas no hayan sido observadas ni registradas. Menos de 50 tiradas, o cualquier incertidumbre sobre el número o la privacidad de las tiradas, devuelve la semilla a la categoría de riesgo. Las tiradas de dados no protegen las funciones avanzadas del dispositivo que siguen dependiendo de la misma ruta de números aleatorios, pero sí protegen las palabras de la semilla misma de esta falla específica.
¿Cómo cambia una frase de contraseña BIP-39 el perfil de riesgo?
Una frase de paso BIP-39 fuerte y única crea un monedero separado que no puede derivarse solo con las palabras de semilla. Un atacante que recupere solo la semilla débil aún no podrá acceder a los fondos protegidos con frase de paso sin descubrir también la frase de paso. Frases de paso cortas, comunes, con patrones o reutilizadas no ofrecen protección significativa. Incluso con una frase de paso fuerte, Coinkite recomienda una migración eventual, ya que la semilla subyacente sigue siendo criptográficamente deficiente y la frase de paso se convierte en un secreto crítico que debe respaldarse por separado y nunca ingresarse en dispositivos no confiables. La frase de paso es independiente del PIN del dispositivo.
¿Qué deben hacer los usuarios de multisignatura si algunas claves provienen de Coldcards afectados?
Evalúe cada clave según el dispositivo y el firmware que la generaron. Si el número de claves afectadas cumple o supera el umbral de gasto de cualquier ruta, esa ruta está en riesgo inmediato. Una configuración 2-de-3 que incluya dos claves Coldcard débiles puede ser gastada por un atacante que recupere esas dos semillas. Las rutas de recuperación protegidas por timelocks activos permanecen más seguras hasta que expire el bloqueo. Los usuarios deben generar claves de reemplazo en firmware fijo o en dispositivos no afectados, construir una nueva política de multisignatura y migrar los fondos tras verificar el nuevo descriptor y las direcciones. Las fuentes heterogéneas de claves reducen la posibilidad de que una sola falla en el firmware comprometa todo el cuórum.
¿El ataque aún está en curso y cómo pueden los titulares monitorear más barridos?
Galaxy Research observó múltiples olas tras el primer barrido del 30 de julio y reportó que la actividad continuó mientras los usuarios migraban. Los patrones en cadena caracterizados por tasas de tarifas específicas y comportamiento de variación pueden monitorearse a través de exploradores públicos y servicios de análisis, pero los titulares individuales no pueden confiar únicamente en la detección después del hecho. La protección más efectiva es la migración inmediata de cualquier semilla no protegida. Los canales oficiales de Coinkite y las cuentas de investigación confiables siguen siendo las fuentes principales para actualizaciones sobre olas adicionales o agrupaciones de direcciones recientemente identificadas.
Descargo de responsabilidad: Este contenido tiene fines informativos únicamente y no constituye asesoramiento de inversión. Las inversiones en criptomonedas conllevan riesgos. Por favor, realiza tu propia investigación (DYOR).
Aviso: Esta página fue traducida utilizando tecnología de IA para tu conveniencia. Para obtener la información más precisa, consulta la versión original en inglés.