Su Bitcoin no fue hackeado. Su cartera sí pudo haber sido vulnerada.

Cuando el bitcoin desaparece de una cartera, los titulares suelen decir que el Bitcoin fue hackeado.

Esa descripción suele ser incorrecta.

La red de Bitcoin puede seguir operando exactamente como está diseñada incluso cuando alguien pierde el control de su bitcoin. La causa suele ser otra cosa: un dispositivo comprometido, una implementación defectuosa, una frase de recuperación expuesta, un procedimiento de custodia fallido, un interno deshonesto u otra vulnerabilidad fuera del propio protocolo.

Esa distinción es más que técnica. Puede determinar lo ocurrido, quién podría asumir la responsabilidad, qué evidencia es relevante y si el propietario tiene una vía viable para la recuperación o los daños.

El reciente problema de seguridad de Coldcard ilustra este punto.

Coinkite emitió un aviso de seguridad sobre cómo se generaban las semillas de cartera en ciertos dispositivos Coldcard y versiones de firmware. Según la empresa, algunas semillas afectadas contenían menos entropía, o aleatoriedad, de lo previsto. Coinkite advirtió que los fondos vinculados a una semilla afectada podrían permanecer en riesgo y que simplemente actualizar el firmware no repararía una semilla ya creada. Su recomendación fue generar una nueva semilla con el firmware corregido y migrar los fondos, sujeto a la guía de tiradas de dados y frases de paso indicada en el aviso.^[1][2]

Los informes públicos han vinculado el problema a transferencias de Bitcoin no autorizadas. El número de propietarios afectados, la atribución de transferencias específicas y el monto total de cualquier pérdida resultante siguen sujetos a investigación.^[7]

Sin embargo, el punto esencial ya está claro: la vulnerabilidad reportada no requirió que un atacante violara las reglas de consenso de Bitcoin, invirtiera su criptografía o corrompiera su cadena de bloques.

La posible debilidad surgió en el sistema utilizado para generar y proteger las credenciales que controlan el bitcoin.

Una cartera de Bitcoin no contiene bitcoin

Una cartera de hardware no almacena literalmente bitcoin dentro del dispositivo.

El Bitcoin sigue representado en la cadena de bloques. La cartera ayuda a generar, proteger y usar las claves privadas que autorizan transacciones en direcciones específicas.

Una frase de recuperación, a menudo llamada frase semilla, puede usarse para derivar esas claves. BIP 39 describe un proceso mnemónico que codifica la entropía generada por computadora y convierte el mnemónico en una semilla binaria para carteras determinísticas.^[3] Su seguridad depende en gran medida de la imprevisibilidad. Una semilla generada correctamente debería ser inviable de adivinar para un atacante.

Si el proceso que genera la semilla produce materialmente menos aleatoriedad de lo esperado, el conjunto de semillas posibles puede reducirse a algo mucho más pequeño de lo que los usuarios razonablemente creían —tan pequeño que un atacante capaz podría buscarlo y derivar las claves correspondientes sin tocar nunca el dispositivo físico de la víctima.

Una transacción realizada con esas claves aún puede ser válida desde la perspectiva de Bitcoin. La cadena de bloques no sabe si la persona que firma tenía autoridad legal, robó la semilla, explotó una vulnerabilidad o violó un acuerdo.

Bitcoin valida firmas. No arbitra disputas de propiedad. El sistema legal debe abordar el resto.

El sistema relevante es más grande que el dispositivo

Los propietarios serios de Bitcoin deben evitar tratar una cartera de hardware como una estrategia de seguridad completa.

El sistema real de custodia puede incluir:

• el dispositivo y sus componentes;
• firmware y software;
• generación de números aleatorios;
• el proceso utilizado para crear la semilla;
• copias de seguridad y frases de paso;
• aplicaciones complementarias;
• procedimientos de firma de transacciones;
• proveedores y prestadores de servicios;
• empleados, familiares, fiduciarios o asesores;
• ubicaciones físicas de almacenamiento;
• planes de sucesión y acceso de emergencia; y
• contratos que asignan el riesgo entre los participantes.

Una falla en cualquiera de estas capas puede derrotar al sistema más amplio.

Esto es aún más importante para empresas y oficinas familiares. Un propietario individual puede aceptar un grado particular de riesgo tecnológico para sus tenencias personales. Un fiduciario, director financiero, fiduciario, gestor de inversiones o ejecutivo de una oficina familiar puede tener obligaciones adicionales de investigar, documentar, monitorear y responder a ese riesgo.

Cuando un producto de seguridad falla, surgen preguntas legales

Una vulnerabilidad reportada no establece automáticamente negligencia o responsabilidad legal.

Una reclamación viable generalmente requiere un examen cuidadoso de:

• el producto y versión de firmware específicos;
• qué representaciones se hicieron;
• los contratos que rigen la relación;
• qué causó la pérdida;
• la conducta propia del propietario;
• qué advertencias se proporcionaron; y
• qué defensas pueden estar disponibles.

Dependiendo de los hechos y la legislación aplicable, los temas pueden incluir:

• diseño o pruebas negligentes;
• omisión de advertencia;
• incumplimiento de garantía expresa o implícita;
• representación negligente;
• incumplimiento de contrato;
• principios de responsabilidad por productos;
• estatutos de protección al consumidor;
• ejecutabilidad de renuncias y limitaciones de daños;
• culpa comparativa;
• causalidad;
• mitigación; y
• cálculo de los daños legalmente recuperables.

También pueden ser relevantes partes adicionales. Una pérdida podría involucrar a un fabricante, distribuidor, proveedor de custodia, desarrollador de software, consultor, empleado, asegurador o cualquier otro participante en el acuerdo de custodia.

Por lo tanto, la existencia de un defecto técnico es el inicio del análisis jurídico, no el final.

La primera respuesta puede moldear el caso

Los propietarios que sospechan una pérdida de activos digitales deben resistir la inclinación a restablecer, desechar o reconfigurar inmediatamente cada dispositivo afectado.

Mover lo que queda puede ser urgente, pero preservar la evidencia puede ser igualmente importante, y ambos objetivos deben coordinarse cuidadosamente.

La evidencia relevante puede incluir:

• el hardware original;
• la versión del firmware en uso cuando se generó la semilla;
• números de serie y empaques;
• registros de compra;
• configuración de la billetera;
• historial de direcciones y transacciones;
• capturas de pantalla y fotografías;
• registros;
• comunicaciones con el fabricante o proveedores de servicios;
• políticas internas;
• avisos de seguros; y
• una cronología precisa del descubrimiento y la respuesta.

Una actualización de firmware no coordinada, restablecimiento de fábrica, eliminación o intento de recuperación pueden alterar la evidencia necesaria para demostrar lo ocurrido.

Por lo tanto, el asesoramiento legal y profesionales forenses calificados deben involucrarse temprano cuando el valor o la importancia institucional de la pérdida lo justifiquen.

La autocustodia no implica aislamiento jurídico

Bitcoin fue diseñado para permitir la propiedad sin depender de un intermediario financiero central. Eso no significa que cada producto y servicio relacionado con Bitcoin opere fuera de los principios legales ordinarios.

Las empresas continúan haciendo representaciones. Los fabricantes siguen vendiendo productos. Los desarrolladores siguen escribiendo código. Los proveedores siguen celebrando contratos. Los fiduciarios siguen teniendo deberes. Las aseguradoras siguen emitiendo pólizas. Los tribunales siguen resolviendo disputas sobre propiedad, responsabilidad y daños.

Coldcard mismo ilustra el punto. Coinkite comercializa el dispositivo como exclusivamente para Bitcoin, con opciones de firma aislada del aire, doble elemento seguro y firmware que describe como verificable y de código abierto.^[4] Esas son afirmaciones específicas y comercializables, y las afirmaciones específicas pueden tener peso legal.

El historial de licencias agrega matices. Antes de noviembre de 2020, la licencia del repositorio identificó el firmware como software GPLv3-or-later. Un commit del 18 de noviembre de 2020 añadió una licencia MIT-plus-Commons-Clause que retiene el derecho a “Sell” el software según la definición de ese término en la licencia.^[5][8][9] Esa historia convierte “verificable” y “código abierto” en representaciones distintas. Si una descripción pública transmite adecuadamente la distinción, si un comprador confía razonablemente en ella, y si alguna representación causó o contribuyó a una pérdida son cuestiones legales específicas de hecho.

Por lo tanto, el incidente de Coldcard no es evidencia de que Bitcoin en sí haya fallado. Es evidencia de que incluso un propietario de Bitcoin preocupado por la seguridad sigue dependiendo de una combinación de código, hardware, personas, procedimientos y relaciones legales.

La mejor pregunta no es simplemente si una billetera fue "hackeada".

Las mejores preguntas son:

• ¿Qué componente falló?
• ¿Por qué falló?
• ¿Quién controlaba ese componente?
• ¿Qué representaciones se hicieron?
• ¿Qué precauciones fueron razonables?
• ¿Qué evidencia queda?
• ¿Quién debe asumir la pérdida resultante?

Esas son preguntas técnicas.

También son preguntas legales.

Publicidad de servicios legales. Este artículo se proporciona únicamente con fines informativos generales y no constituye asesoría legal ni de ciberseguridad. Leer o responder a este artículo no crea una relación abogado‑cliente. Los derechos y obligaciones legales dependen de los hechos particulares, contratos, jurisdicciones y la legislación aplicable.