El límite de seguridad de la autocustodia quizá no esté en el paso en que guardas las claves privadas, sino en el firmware que no puedes auditar. Según informó PANews, una demanda colectiva presentada ante el Tribunal Superior de Ontario, Canadá, sostiene que Coinkite, fabricante de la billetera de hardware Coldcard, y dos de sus cofundadores son objeto de una demanda colectiva. Los demandantes alegan que, desde marzo de 2021, un error de compilación hizo que el firmware utilizara el generador de números pseudoaleatorios Yasmarang de MicroPython, lo que permitiría reproducir las frases semilla. Según la demanda, atacantes explotaron la vulnerabilidad a partir del 30 de julio de 2026 y, en los primeros 25 minutos, sustrajeron alrededor de 594 BTC; las pérdidas acumuladas superan los 140 millones de dólares. La demanda también afirma que ambos fundadores conocían el defecto, a más tardar, en mayo de 2025.
A mi juicio, lo que realmente merece la atención de los lectores no es otro caso de robo, sino que este expone la cadena de confianza de las billeteras de hardware como un problema de diseño. El principal atractivo de estas billeteras suele ser que las claves privadas permanecen fuera de línea y que las frases semilla no se conectan a Internet. Sin embargo, la generación de la frase semilla depende de la fuente de números aleatorios del dispositivo. Si el propio generador de números aleatorios puede reproducirse, la protección de la firma sin conexión ya se ha eludido en la etapa de generación. Los usuarios pueden auditar cómo guardan sus claves privadas, pero no el proceso de compilación del firmware ni sus bibliotecas dependientes. De ello se desprende que las garantías de seguridad de una billetera de hardware dependen también del entorno de compilación del fabricante, de las versiones de las bibliotecas de terceros y de las auditorías previas al lanzamiento; para los usuarios comunes, estos aspectos son prácticamente una caja negra.
Cabe subrayar que las causas de la vulnerabilidad, la cronología y el momento en que los fundadores supuestamente tuvieron conocimiento de ella son alegaciones de los demandantes recogidas en la demanda. Aún no han sido confirmadas por un tribunal y, por ahora, la información procede de un solo medio, por lo que debe atribuirse a esa fuente.
Para determinar si esta evaluación se sostiene, conviene seguir tres aspectos: si el tribunal certifica la demanda colectiva; si Coinkite hace públicos sus procesos de auditoría de la compilación del firmware y de las bibliotecas dependientes; y si se determina que el problema afecta a otros lotes de dispositivos. Si se deniega la certificación de la demanda colectiva o se limita el alcance de la vulnerabilidad a determinados lotes, también deberá acotarse el alcance de esta evaluación. El material disponible no incluye una respuesta oficial de Coinkite, por lo que aún faltan pruebas en ese sentido.
#BTC #钱包安全 #SeguridadCriptográfica
Fuentes:
PANews (publicado originalmente el 22 de octubre a las 13:11, hora de Pekín)
https://www.panewslab.com/zh/articles/01a16205-dd9d-77fc-bf44-1c451cad315a
A mi juicio, lo que realmente merece la atención de los lectores no es otro caso de robo, sino que este expone la cadena de confianza de las billeteras de hardware como un problema de diseño. El principal atractivo de estas billeteras suele ser que las claves privadas permanecen fuera de línea y que las frases semilla no se conectan a Internet. Sin embargo, la generación de la frase semilla depende de la fuente de números aleatorios del dispositivo. Si el propio generador de números aleatorios puede reproducirse, la protección de la firma sin conexión ya se ha eludido en la etapa de generación. Los usuarios pueden auditar cómo guardan sus claves privadas, pero no el proceso de compilación del firmware ni sus bibliotecas dependientes. De ello se desprende que las garantías de seguridad de una billetera de hardware dependen también del entorno de compilación del fabricante, de las versiones de las bibliotecas de terceros y de las auditorías previas al lanzamiento; para los usuarios comunes, estos aspectos son prácticamente una caja negra.
Cabe subrayar que las causas de la vulnerabilidad, la cronología y el momento en que los fundadores supuestamente tuvieron conocimiento de ella son alegaciones de los demandantes recogidas en la demanda. Aún no han sido confirmadas por un tribunal y, por ahora, la información procede de un solo medio, por lo que debe atribuirse a esa fuente.
Para determinar si esta evaluación se sostiene, conviene seguir tres aspectos: si el tribunal certifica la demanda colectiva; si Coinkite hace públicos sus procesos de auditoría de la compilación del firmware y de las bibliotecas dependientes; y si se determina que el problema afecta a otros lotes de dispositivos. Si se deniega la certificación de la demanda colectiva o se limita el alcance de la vulnerabilidad a determinados lotes, también deberá acotarse el alcance de esta evaluación. El material disponible no incluye una respuesta oficial de Coinkite, por lo que aún faltan pruebas en ese sentido.
#BTC #钱包安全 #SeguridadCriptográfica
Fuentes:
PANews (publicado originalmente el 22 de octubre a las 13:11, hora de Pekín)
https://www.panewslab.com/zh/articles/01a16205-dd9d-77fc-bf44-1c451cad315a