Uno de los fracasos más extraños del mundo moderno de las blockchains es que la gente trata habitualmente los sistemas d
Uno de los fracasos más extraños del mundo moderno de las blockchains es que la gente trata habitualmente los sistemas diseñados para dinero digital como si el modelo de seguridad apropiado para una transacción de cinco dólares también debiera proteger toda una vida de ahorros.
Eso no es simplemente una mala práctica operativa. Es un error de categoría.
El dinero digital tiene distintos usos, distintos valores en riesgo y, por lo tanto, diferentes requisitos de seguridad. Una persona que compra un café no necesita la misma arquitectura de seguridad que alguien que protege 5 millones de dólares. Sin embargo, gran parte de la comunidad de BTC ha convergido precisamente en esta posición absurda: un dispositivo, una clave, un único punto de fallo, independientemente del valor que se esté protegiendo.
Y entonces, cuando un dispositivo es comprometido, culpan al dispositivo.
El problema más profundo es la arquitectura que eligieron.
Bitcoin siempre permitió mecanismos de gestión de claves mucho más sofisticados que el modelo simplista de una sola clave que se ha vuelto culturalmente dominante. Múltiples claves, múltiples firmantes, diferentes condiciones de gasto y estructuras de transacción más elaboradas no son elementos ajenos al sistema. Surgen naturalmente del modelo subyacente de scripting y transacciones.
El error ha sido tratar la transacción más sencilla posible como si fuera la transacción apropiada para cualquier posible uso económico.
No lo es.
Una clave no es una arquitectura de seguridad Una clave privada es una credencial.
Por sí sola, no constituye un sistema de seguridad completo.
Si poseer una sola clave es suficiente para transferir un activo significativo, entonces cualquiera que obtenga esa clave ha obtenido, en la práctica, el activo. Eso significa que todo el valor económico que se pretende proteger ha quedado concentrado en las propiedades de seguridad de una única credencial y del dispositivo que la contiene.
Para transacciones pequeñas y ocasionales, esto puede ser perfectamente razonable.
Si alguien mantiene el equivalente digital del dinero para gastos menores en un teléfono o en un pequeño dispositivo de hardware, aceptar un nivel de riesgo limitado puede tener sentido económico. Las personas siempre han hecho esto con el dinero físico. Normalmente nadie lleva en la billetera el contenido de su cuenta de jubilación simplemente porque una billetera resulta cómoda para comprar el almuerzo.
Sin embargo, esa distinción se ha olvidado con los sistemas blockchain.
El mismo mecanismo utilizado para autorizar un pago trivial se emplea habitualmente para proteger enormes cantidades de dinero.
Esto es la ingeniería de seguridad puesta al revés.
El nivel de protección debería estar determinado por el valor que se protege, las consecuencias de una vulneración, el modelo de amenazas, los requisitos de recuperación y la carga operativa aceptable.
La seguridad es contextual.
Defensa en profundidad La seguridad seria siempre se ha basado en la defensa en profundidad.
Ningún arquitecto de seguridad competente asume que un único mecanismo jamás fallará.
Los sistemas fallan. El hardware falla. El software contiene vulnerabilidades. Las personas cometen errores. Las cadenas de suministro pueden verse comprometidas. Las credenciales pueden ser robadas. Las copias de seguridad pueden perderse. Las instalaciones pueden incendiarse. Las personas pueden quedar indisponibles.
El propósito de la defensa en profundidad no es fingir que estos acontecimientos no pueden ocurrir. Es diseñar un sistema en el que el fallo de un componente no provoque una pérdida catastrófica.
Este principio no tiene nada de novedoso.
Los bancos no protegen sus bóvedas con una sola cerradura.
Los sistemas militares no protegen activos críticos mediante un único control.
Las grandes corporaciones normalmente no permiten que un solo empleado, con una única contraseña, transfiera todo el tesoro corporativo.
Los aviones no dependen de un único instrumento.
Las infraestructuras críticas no crean deliberadamente puntos únicos de fallo cuando existe redundancia económica y técnicamente viable.
Sin embargo, la gente coloca millones de dólares en activos blockchain detrás de una única clave privada almacenada en un solo dispositivo de hardware y considera que eso es seguridad sofisticada.
No es sofisticado.
Es riesgo de concentración.
La falacia de la hardware wallet Las hardware wallets pueden ser herramientas útiles.
No son mágicas.
Una hardware wallet sigue siendo un dispositivo. Contiene hardware, firmware, interfaces de software, dependencias de fabricación, mecanismos de actualización, canales de comunicación y supuestos sobre la forma en que el usuario interactúa con ella.
Cada uno de estos elementos genera posibles modos de fallo.
Cuando aparece un exploit contra una hardware wallet, la pregunta útil no es simplemente: «¿Cómo pudo atacarse este dispositivo en particular?»
La pregunta más importante es:
¿Por qué el compromiso de un solo dispositivo fue suficiente para comprometer el activo?
Si la respuesta es que todo el patrimonio podía transferirse utilizando una única clave controlada por ese dispositivo, entonces la arquitectura de seguridad ya era frágil antes de que se descubriera el exploit.
La vulnerabilidad del dispositivo simplemente dejó al descubierto esa fragilidad.
Esta distinción importa.
Idealmente, una vulnerabilidad en un componente debería comprometer un componente.
No debería comprometer todo el sistema.
Precisamente para eso existe la defensa en profundidad.
Cinco claves, tres necesarias Consideremos un ejemplo relativamente sencillo.
Un patrimonio importante podría estar controlado mediante cinco claves generadas de forma independiente, requiriéndose tres de ellas para autorizar una transacción.
Las claves podrían estar almacenadas en cinco dispositivos diferentes.
Esos dispositivos podrían utilizar hardware distinto.
Podrían almacenarse en diferentes ubicaciones físicas.
Una podría mantenerse en una residencia.
Otra en una caja de seguridad bancaria.
Otra en una oficina corporativa o en una ubicación de custodia profesional.
Otra bajo un acuerdo legal o fiduciario de confianza.
Y otra en una ubicación segura geográficamente separada.
Lo importante no son estas ubicaciones concretas. La arquitectura debe reflejar las circunstancias reales.
El punto es la separación.
Ahora consideremos lo que un atacante tendría que conseguir.
Robar un dispositivo no sería suficiente.
Comprometer una implementación de firmware no sería suficiente.
Entrar en una ubicación no sería suficiente. Obtener una copia de seguridad no sería suficiente.
Convencer a una persona para firmar una transacción maliciosa no sería suficiente.
Incluso la pérdida simultánea de dos claves no necesariamente destruiría el acceso al activo.
El problema de seguridad ha cambiado fundamentalmente.
En lugar de preguntarse si un dispositivo puede protegerse perfectamente para siempre —un objetivo poco realista—, el sistema se pregunta si un atacante puede comprometer varios componentes protegidos de forma independiente antes de que el propietario legítimo detecte o responda al ataque.
Esa es una propuesta mucho más sólida.
La independencia importa Simplemente crear cinco copias de la misma clave no proporciona la misma protección.
Tampoco sirve generar cinco claves en la misma máquina comprometida y almacenarlas unas junto a otras.
La defensa en profundidad requiere una independencia significativa.
Dispositivos diferentes reducen los fallos comunes de hardware.
Ubicaciones diferentes reducen el riesgo de concentración física.
La generación independiente de claves reduce las consecuencias de un generador de números aleatorios comprometido.
Diferentes controles administrativos pueden reducir el riesgo interno.
Diferentes mecanismos de respaldo reducen los fallos correlacionados de recuperación.
La separación geográfica reduce la exposición a incendios, inundaciones, confiscaciones, robos u otros acontecimientos localizados.
El objetivo es impedir que un único fallo se propague a través de todas las capas.
Un sistema de seguridad que parece redundante pero contiene la misma dependencia oculta en cada componente puede proporcionar muy poca redundancia real.
Esto es ingeniería básica de sistemas.
La seguridad debe escalar con el valor No existe un número universal de claves que sea correcto para todas las circunstancias.
Ese no es el punto.
Una persona que protege 50 dólares puede utilizar razonablemente una sola clave.
Una persona que protege 5.000 dólares puede elegir controles algo más sólidos.
Una empresa que protege 5 millones de dólares debería tener una arquitectura sustancialmente diferente.
Una institución que protege cientos de millones probablemente debería contar con otro nivel de seguridad, incluyendo gobernanza formal, segregación de funciones, límites de transacción, procedimientos de aprobación, controles auditables, protocolos de recuperación y gestión institucional de claves.
La defensa en profundidad tiene un coste.
Las claves adicionales generan complejidad adicional.
Los firmantes adicionales generan carga operativa.
La separación geográfica genera inconvenientes. Los mecanismos de recuperación requieren planificación.
Pero el gasto en seguridad debe considerarse en relación con el valor que se está protegiendo.
Gastar 50.000 dólares diseñando y operando una arquitectura de seguridad para proteger 5.000 dólares sería irracional.
Negarse a gastar recursos significativos para proteger 50 millones de dólares porque una única hardware wallet resulta conveniente es igualmente irracional.
La arquitectura debe ser proporcional.
El fracaso de la mentalidad de la «transacción estándar» Debajo de todo esto existe un problema conceptual mayor.
El ecosistema de BTC trata cada vez más un conjunto reducido de patrones de transacción convencionales como si esos patrones definieran lo que Bitcoin debe ser.
La transacción utilizada con mayor frecuencia se convierte en la transacción considerada normal.
La transacción considerada normal se convierte en la transacción considerada legítima.
Finalmente, las personas empiezan a diseñar su comportamiento económico alrededor de las limitaciones de esa convención.
Eso invierte la relación.
Bitcoin fue diseñado como un sistema de dinero electrónico.
El dinero se utiliza de manera diferente dependiendo de la transacción.
El importe importa.
Las partes importan.
El contexto comercial importa.
Los controles necesarios importan.
Los riesgos importan.
No existe ninguna razón sensata para asumir que la arquitectura de transacción apropiada para comprar un café deba ser también la arquitectura apropiada para proteger la tesorería de una empresa.
El sistema subyacente permite construir condiciones.
Las claves pueden combinarse.
Las firmas pueden requerirse en distintas combinaciones.
Las reglas de gasto pueden reflejar procesos empresariales.
Los controles pueden estructurarse por capas.
Las estructuras de transacción pueden reflejar la realidad económica que respaldan.
Sin embargo, sorprendentemente poco de esto recibe atención seria porque el ecosistema lleva años reduciéndolo todo a la cuestión de cómo almacenar «la seed phrase».
Y esa ya es la abstracción equivocada.
Una seed phrase es un mecanismo de respaldo, no una gestión patrimonial La obsesión cultural con las seed phrases demuestra el problema.
Se enseña a la gente a escribir doce o veinticuatro palabras.
Esconderlas en algún lugar.
Ponerlas en metal.
Guardarlas en una caja fuerte.
Quizás dividirlas de alguna manera.
Y después se les dice que han protegido su patrimonio.
Pero si esas palabras reconstruyen una única jerarquía de claves capaz de moverlo todo, el sistema puede seguir teniendo un único límite fundamental de autorización.
Proteger el respaldo con mayor cuidado no necesariamente elimina el punto único de fallo. Simplemente protege con mayor cuidado el punto único de fallo.
Hay una diferencia.
La verdadera ingeniería de seguridad pregunta cuántos fallos independientes son necesarios antes de que el activo protegido pueda ser sustraído.
Pregunta qué ocurre si un firmante es comprometido.
Pregunta qué ocurre si falla un fabricante de dispositivos.
Pregunta qué ocurre si se descubre una copia de seguridad.
Pregunta qué ocurre si una ubicación se vuelve inaccesible.
Pregunta qué ocurre si el propietario muere. Pregunta qué ocurre si un empleado se vuelve malicioso. Pregunta qué ocurre si un dispositivo de firma muestra una transacción falsa.
Pregunta si deberían existir límites sobre el valor de las transacciones.
Pregunta si las transferencias anómalas deberían requerir una aprobación adicional.
Estas son preguntas habituales en la seguridad financiera.
Deberían ser preguntas habituales en el dinero digital.
Dinero en efectivo no significa descuido Existe otra trampa lingüística.
Llamar a Bitcoin «efectivo» no significa decir que todos los fondos deban tratarse de manera despreocupada.
El dinero físico demuestra precisamente lo contrario.
Una persona puede llevar 50 dólares en el bolsillo.
Una tienda puede mantener varios miles de dólares en la caja y en una caja fuerte.
Un banco puede mantener cantidades muchísimo mayores protegidas mediante bóvedas, controles, procedimientos, separación de funciones, vigilancia, seguros, sistemas contables y procesos legales.
Todo es dinero.
La arquitectura de seguridad cambia con la escala.
El dinero digital no debería ser diferente.
La expresión «transacciones pequeñas y ocasionales» importa porque identifica una categoría económica.
Las transacciones pequeñas pueden tolerar supuestos de seguridad diferentes a los de las transacciones grandes.
Eso no significa que el sistema esté limitado a pequeñas transacciones. Significa que la arquitectura de seguridad y operación debe cambiar a medida que cambian el valor y el propósito.
El error consiste en tomar una estructura adecuada para pequeños pagos ocasionales y elevarla hasta convertirla en un modelo universal de custodia.
La lección de las Cold Cards es más grande que las Cold Cards Por lo tanto, cualquier exploit individual contra una hardware wallet debería entenderse como parte de una lección más amplia.
Si comprometer un único dispositivo de firma puede provocar una pérdida catastrófica, el propietario del activo debe preguntarse por qué el sistema fue diseñado de manera que un dispositivo comprometido tuviera autoridad catastrófica.
La lección correcta no es que otro fabricante necesariamente resolverá el problema.
El próximo dispositivo puede tener otra vulnerabilidad.
Y el siguiente.
El hardware perfecto no existe.
El software perfecto no existe.
Los usuarios perfectos no existen.
El objetivo no es descubrir el único dispositivo infalible.
El objetivo es crear un sistema que permanezca seguro cuando sus componentes individuales no sean perfectos.
Eso es defensa en profundidad.
Bitcoin puede ofrecer una seguridad mejor que la cultura que lo rodea La parte frustrante es que gran parte de las capacidades necesarias no son conceptualmente difíciles.
No es necesario rediseñar el dinero digital desde sus fundamentos simplemente para reconocer que los activos de gran valor no deberían depender de una sola clave.
El modelo de transacciones de Bitcoin ha sido capaz de admitir múltiples firmas y autorización condicional desde etapas muy tempranas de su historia.
Pueden construirse sistemas más elaborados sobre esos elementos básicos.
Las empresas pueden implementar estructuras de aprobación.
Las familias pueden crear mecanismos de herencia.
Los fondos de inversión pueden separarse de los saldos destinados a transacciones.
Las transferencias de alto valor pueden requerir firmantes adicionales.
Diferentes clases de transacciones pueden utilizar diferentes políticas de seguridad.
Las organizaciones pueden separar la autoridad entre sus responsables.
Los mecanismos de recuperación de emergencia pueden existir sin hacer que el gasto cotidiano resulte engorroso.
El sistema puede diseñarse alrededor de la realidad humana e institucional.
Pero para ello es necesario que las personas dejen de pensar en una Bitcoin wallet como si fuera simplemente una cuenta bancaria protegida mediante una contraseña.
No lo es.
Es un mecanismo para satisfacer condiciones de gasto.
Esas condiciones pueden diseñarse. Separar el dinero para gastar del patrimonio almacenado
Una arquitectura racional comienza reconociendo que el dinero destinado a transacciones y el patrimonio almacenado son problemas diferentes.
Una persona podría mantener un pequeño saldo de una sola clave para los gastos cotidianos.
Esa wallet puede ser conveniente.
Puede permanecer en un dispositivo utilizado con frecuencia.
Perderla sería molesto, pero no financieramente catastrófico.
Una estructura de ahorro separada podría utilizar una autorización tres-de-cinco.
Una reserva institucional de mayor tamaño podría utilizar controles aún más elaborados.
Esto es análogo al mundo físico.
Las personas llevan billeteras.
Tienen cuentas bancarias.
Las empresas tienen controles de tesorería. Los bancos tienen bóvedas.
A nadie le sorprende que estos sistemas utilicen distintos niveles de seguridad.
Los sistemas digitales no deberían suspender de alguna manera la economía del riesgo simplemente porque todos los activos estén representados electrónicamente.
Dejar de optimizar únicamente para la comodidad La industria ha dedicado una cantidad extraordinaria de esfuerzo a eliminar la fricción.
Un clic.
Un dispositivo.
Una seed.
Una firma.
Una interfaz.
La comodidad tiene valor.
Pero la comodidad no es el único objetivo de ingeniería.
La seguridad introduce deliberadamente fricción cuando el coste de una acción no autorizada es elevado.
Un sistema de lanzamiento nuclear que requiriera que una sola persona pulsara un único botón sería ciertamente fácil de utilizar.
Eso no lo convertiría en un sistema bien diseñado.
Un sistema de pagos corporativo en el que un empleado junior pudiera transferir todo el tesoro de la empresa sería maravillosamente cómodo.
También sería negligente.
El mismo razonamiento se aplica aquí.
Para pagos pequeños, minimizar la fricción.
Para transferencias grandes, introducir controles.
Para ahorros sustanciales, eliminar puntos únicos de fallo innecesarios.
Para activos institucionales, construir seguridad institucional.
El sistema debe reflejar el valor en riesgo.
El verdadero fracaso es conceptual Los recurrentes fallos de seguridad relacionados con los fondos blockchain, por lo tanto, no son simplemente fallos de criptografía o hardware.
Son fallos de pensamiento económico.
Las personas han confundido poseer una clave privada con poseer una arquitectura de seguridad.
Han confundido un dispositivo wallet con un sistema de custodia.
Han confundido un patrón de transacción conveniente con los límites del modelo de transacciones subyacente.
Han confundido la seguridad apropiada para el dinero del bolsillo con la seguridad apropiada para el patrimonio acumulado.
Y después se sorprenden cuando un único fallo destruye todo.
Las matemáticas pueden ser excelentes.
La criptografía puede ser excelente.
El sistema de transacciones puede permitir controles sofisticados.
Nada de eso protege a alguien que deliberadamente construye un único punto de fallo catastrófico.
El dinero digital sigue requiriendo una ingeniería de seguridad convencional.
Y, quizás más importante aún, el patrimonio digital requiere considerablemente más que una seguridad propia de una caja registradora.
Una sola clave puede ser perfectamente sensata para cinco dólares.
Una sola clave controlando una fortuna no es simplicidad.
Es negligencia disfrazada de comodidad.