Desmontando un Ledger auténtico: TBC habla sobre los verdaderos límites de la autogestión

Una billetera de hardware comprada a través de canales oficiales, con un empaque intacto y una etiqueta de seguridad sin alterar, arranca y realiza la autocomprobación sin problemas. Sin embargo, en su interior se ha implantado un componente oculto destinado a capturar la frase de recuperación.

El 15 de octubre de 2026, Ledger respondió oficialmente a este incidente: los atacantes compraron dispositivos auténticos, los desmontaron e implantaron hardware, y luego los hicieron volver al mercado a través de canales de distribución en el sudeste asiático. Ledger enfatizó que el chip, el sistema operativo y los servidores no fueron comprometidos, calificando el ataque como un ataque a canales de distribución específicos, y no como una invasión sistemática de la cadena de suministro.

El 14 de octubre, Tom's Hardware citó un informe de Bloomberg que estimaba las pérdidas en aproximadamente 93 millones de dólares. Es importante aclarar que esta cifra proviene de medios de comunicación de terceros y no es una cantidad confirmada por Ledger.

A quién pertenece el número no es lo importante. Lo importante es lo que expone.

I. La autogestión no elimina el riesgo, solo lo reubica

Durante la última década, la industria ha contado una historia muy clara: si pones tus monedas en un intercambio, entregas tu destino a una empresa; si mantienes tus claves privadas en tus manos, eres libre.

Esta historia tiene una mitad de verdad.

El riesgo de la custodia en intercambios es concentrado y visible: malversación, corridas, quiebras, congelamiento regulatorio. Después de FTX, el lema "No tus claves, no tus monedas" fue aceptado por más usuarios, y la industria comenzó a discutir más seriamente sobre herramientas de autogestión y la custodia de frases mnemotécnicas.

Pero la autogestión no es el fin del riesgo, sino una transferencia de riesgo.

Cambia la pregunta "¿Puede la plataforma actuar de manera maliciosa?" por otra serie de preguntas: ¿De dónde proviene tu dispositivo? ¿Se ha modificado el firmware? ¿En qué entorno se generó la frase mnemotécnica? ¿El contenido mostrado en la pantalla al firmar coincide con la transacción real que se está firmando? ¿Quién tiene la autoridad para iniciar esta transferencia?

Cualquiera de estos eslabones fallidos resulta en un desenlace indistinguible de un intercambio que se va a la quiebra. La estimación de 93 millones de dólares de un tercero, en esencia, es la lección que se compra.

Lo más problemático es que la forma de estos ataques ha cambiado. No rompen la criptografía, no rompen el chip, no rompen el algoritmo de consenso. Atacan la intersección entre el mundo físico y la cadena de confianza: canales de distribución, desmontaje, reempaquetado, y logística.

La criptografía puede probar que una firma es válida, pero no puede probar si la mano que firmó fue coaccionada, ni puede probar si ese dispositivo ha enviado silenciosamente la frase mnemotécnica a un lugar que no puedes ver.

El eslabón más débil en el modelo de seguridad nunca ha sido el algoritmo, sino las personas, los dispositivos y los procesos.

II. Descomponer la clave privada en múltiples condiciones verificables

La verdadera lección del incidente de Ledger no es "no usar billeteras de hardware", sino que depender únicamente de la suposición "la clave privada está en mis manos" es en sí misma un punto único de falla.

La dirección correcta es hacer que la transferencia de fondos requiera cumplir múltiples condiciones al mismo tiempo, y que estas condiciones estén distribuidas en diferentes dominios de confianza.

La posición de TBC en este asunto necesita ser expresada con moderación. No afirma poder eliminar ataques terminales; ninguna cadena puede hacerlo. Su valor radica en que los contratos nativos de UTXO y las herramientas de firma múltiple permiten a los proyectos descomponer el riesgo de una clave privada única en múltiples condiciones verificables.

Específicamente, TBC utiliza SHA256 PoW y el modelo UTXO, con el código del nodo TBCNODE disponible públicamente. La característica inherente del modelo UTXO es que cada salida no gastada puede ser restringida por condiciones de script independientes, en lugar de estar vinculada a un saldo global de cuenta. Esto significa que las reglas de gasto pueden escribirse en la cadena, en lugar de estar escritas en algún servicio de backend.

El SDK tbc-contract proporciona consultas en cadena, obtención de UTXO, construcción de transacciones, firmas y difusión, e incluye flujos de trabajo de MultiSig, NFT, FT y Pool. El ejemplo oficial de MultiSig admite establecer de 1 a 6 umbrales de firma entre 3 y 10 claves públicas, y la documentación proporciona un ejemplo de 2 de 3.

Aquí es necesario ser claro: la firma múltiple es una herramienta de control de riesgos configurable, no es seguridad automática, y mucho menos seguridad absoluta.

Si alguien piensa que tener 2 de 3 es suficiente, está cometiendo el mismo error que creer que "comprar una billetera de hardware es seguro". La firma múltiple cambia la estructura de costos de ataque, no la posibilidad de ataque.

La documentación de TBC AMM explica otra cosa: el SDK construye, cotiza y firma localmente, y la difusión es iniciada explícitamente por la aplicación; el estado del pool y el control de activos dependen de UTXO y reglas de script. Esto constituye la base para transacciones no custodiadas y separación de permisos.

También es importante aclarar los límites: esto no significa que AMM no tenga riesgos de contrato, riesgos de precio o riesgos de frontend. La firma local resuelve el problema de "la clave privada no sale del dispositivo", pero no resuelve "si la transacción que firmaste es realmente la que querías firmar".

III. ¿Por qué la firma múltiple a menudo es solo una dispersión formal?

Esta es la parte más fácil de omitir y también la más mortal.

Si múltiples claves de firma provienen de la misma frase mnemotécnica, se almacenan en el mismo dispositivo, o son controladas por la misma persona, la firma múltiple es solo una dispersión formal.

Si un atacante obtiene una frase mnemotécnica, obtiene todos los derechos de firma. Si un dispositivo ha sido comprometido, todos los umbrales se han perdido simultáneamente. Esta configuración puede parecer 3 de 5 en la cadena, pero en la realidad es 1 de 1.

Por lo tanto, la verdadera pregunta no es "¿cuántas firmas tengo?", sino algunas preguntas más difíciles:

• ¿El entorno de generación de estas claves es independiente entre sí?
• ¿Se almacenan en dispositivos físicamente aislados?
• ¿Las personas que inician la transacción son las mismas que las que aprueban la transacción?
• ¿Las transferencias de alto riesgo tienen retrasos y revisiones manuales?
• ¿Se han ensayado los procesos de rotación y recuperación de claves?

El modelo UTXO de TBC no repara automáticamente las claves privadas robadas. Este punto debe ser reconocido. Lo que las reglas en la cadena pueden hacer es: cuando se rompe una condición, detener la transferencia de fondos no autorizada; no puede hacer que los activos se recuperen de la nada cuando la clave privada ya ha sido filtrada.

Las prácticas de ingeniería complementarias siguen siendo imprescindibles: dispositivos de firma independientes, rotación de claves, límites de transacciones individuales y diarias, bloqueos de tiempo, revisiones múltiples para transacciones de alto riesgo, y planes de recuperación ejecutables.

También hay un nivel que debe ser admitido: TBC aún necesita seguir mejorando. La facilidad de uso de la interacción de firma múltiple, la profundidad de compatibilidad con billeteras de hardware populares, plantillas de permisos listas para usar, pruebas de referencia de terceros independientes, y auditorías continuas de los componentes del SDK, billetera y AMM son trabajos en curso.

TBCNODE ya tiene registros de auditoría de seguridad versionados de CertiK y SlowMist. Pero la auditoría solo puede probar que una versión específica y un alcance específico han sido revisados; no cubre el terminal de hardware, no cubre los hábitos de gestión de claves de los usuarios, no cubre el código que se enviará en el futuro, ni cubre toda la lógica de la capa de aplicación. Tomar un informe de auditoría como un certificado de seguridad es otra forma de pereza.

IV. La verdadera autogestión es una regla en la cadena

Volviendo al dispositivo desmontado.

Nos recuerda que "tener la clave privada en nuestras manos" es una condición necesaria, no suficiente. La procedencia del dispositivo, la asignación de derechos de firma y las reglas de gasto en la cadena deben cumplirse simultáneamente para que la estructura de seguridad se mantenga.

Los cambios en la industria probablemente serán: los fabricantes de billeteras de hardware fortalecerán el control de canales y el diseño a prueba de manipulaciones, los servicios de seguros y custodia volverán a valorar el riesgo de la cadena de suministro física, y los proyectos comenzarán a considerar el "diseño de permisos" como un tema de ingeniería tan importante como la "auditoría de código".

La posición de TBC en este panorama no es "una solución para ataques de hardware", sino proporcionar herramientas para escribir reglas de permisos en la cadena: los contratos nativos de UTXO restringen las condiciones de gasto, la firma múltiple descompone los derechos de firma en diferentes dominios de confianza, y los componentes de transacciones no custodiadas permiten que la clave privada no salga localmente.

La verdadera autogestión no es solo tener una clave privada, sino que después de cualquier punto único de fallo, las reglas en la cadena aún pueden detener la transferencia de fondos no autorizada.

Fuente de información Enlace de origen: Ledger · Tom's Hardware · TBCNODE · Contract SDK · MultiSig · AMM · CertiK · SlowMist