162012–2014

Trezor: las claves de Bitcoin en un ordenador de bolsillo

Marek Palatinus y Pavol Rusnák buscaban una forma de firmar pagos en un ordenador sin tener que confiarle la clave privada. De un prototipo en un hackerspace de Praga surgió la primera generación de carteras de hardware.

Las primeras carteras de Bitcoin presentaban a los usuarios una elección desagradable. Podían tener las claves privadas en un ordenador conectado a Internet y esperar que no fuera atacado por malware, o esconderlas de tal manera que no podrían pagar con comodidad. Marek "Slush" Palatinus y Pavol "Stick" Rusnák buscaban una tercera vía: un pequeño ordenador de propósito único que nunca revelaría la clave, pero firmaría la transacción correctamente representada cuando se le solicitara. Los primeros prototipos se crearon en el hackerspace Brmlab de Praga en Raspberry Pi. El 29 de julio de 2014, el Trezor Model One comenzó a venderse. El dispositivo no convirtió la custodia en un proceso infalible, pero trasladó su parte más crítica del ordenador común a un objeto que el usuario podía sostener, controlar y respaldar.

01

El problema no era Bitcoin, sino el ordenador que lo rodeaba

Bitcoin da al propietario la capacidad de controlar las monedas con su firma sin el consentimiento del banco. Sin embargo, esta misma característica convierte la fuga de la clave en una pérdida definitiva. Si el malware copia la clave privada, puede crear una transacción válida y la red no tiene un departamento de reclamaciones que la devuelva. Un ordenador doméstico común ejecuta el navegador, el correo electrónico, los documentos y los programas de muchas fuentes.

Las primeras guías ofrecían carteras de papel, discos cifrados o ordenadores desconectados de la red. Estas soluciones podían reducir la superficie de ataque, pero aumentaban los requisitos para crear, respaldar y firmar correctamente. Las historias de James Howells y Stefan Thomas mostraron el borde opuesto: el secreto se puede proteger tan exitosamente que ni siquiera su propietario puede acceder a él.

Palatinus ya sabía lo que suponía gestionar un Mining Pool y conocía los riesgos de los servicios de Bitcoin en línea. Junto con Rusnák, buscó una respuesta práctica: ¿cómo separar la clave de firma de un ordenador que podía ser atacado sin convertir cada pago en una tarea técnica complicada? El usuario seguiría preparando la transacción en la cartera del ordenador, pero la aprobaría en un dispositivo independiente.

Así surgió el principio de la cartera de hardware. El ordenador anfitrión envía datos no firmados al dispositivo. El dispositivo deriva la clave necesaria, muestra al usuario los datos esenciales y, después de la confirmación, devuelve la firma. El material privado permanece dentro. El ordenador infectado puede mentir, por lo que la pantalla y la confirmación física son parte del modelo de seguridad, no un adorno de diseño.

El objetivo no era eliminar la confianza en todo el hardware y software. Era más modesto y práctico: reducir la cantidad de código y situaciones en las que la clave secreta está expuesta. Un dispositivo de propósito único puede ser controlado más a fondo que una notebook completa y su interfaz limitada da al usuario la oportunidad de reconocer lo que realmente está firmando.

Un ordenador corriente debe navegar por la web, abrir adjuntos, instalar controladores y ejecutar miles de fragmentos de código que no tienen nada que ver con Bitcoin. Cada uno de ellos amplía el espacio en el que un atacante puede esperar el momento de la firma. Un dispositivo monouso no elimina este mundo, pero aísla la operación más sensible de su caos. La transacción se prepara por fuera, se firma por dentro y la clave privada no debe abandonar el dispositivo. El propósito de la pantalla y los botones es ofrecer al usuario un canal independiente: el ordenador puede afirmar una dirección, pero la confirmación decisiva se produce en la pantalla que controla la propia billetera.

02

Brmlab, Raspberry Pi y dos botones

Los primeros intentos no se parecían al producto de consumo posterior. En Brmlab, Palatinus y Rusnák construyeron placas base para Raspberry Pi, agregaron una pequeña pantalla, botones y comunicación USB. Necesitaban verificar que todo el flujo funcionara: el dispositivo crea claves de forma segura, muestra la solicitud y firma sin revelarlas.

El hackerspace proporcionó un entorno donde el hardware y el software podían cambiar simultáneamente. Un error en la disposición de los botones no estaba separado de un error en el protocolo; ambos podían llevar al usuario a aprobar algo diferente a lo que pretendía. La usabilidad no era la última capa sobre la criptografía. Era una condición para que la criptografía protegiera al ser humano real.

Los dos botones expresaban un límite importante. El ordenador podía solicitar al dispositivo que firme, pero la confirmación final debía ser física. La pantalla, por su parte, creaba un segundo canal para verificar la dirección y la cantidad. Si el portátil infectado cambió el destinatario, un Trezor utilizado correctamente mostraría la discrepancia.

A partir del prototipo surgió la empresa SatoshiLabs. Los desarrolladores tuvieron que resolver la fabricación, el firmware, las actualizaciones, la compatibilidad de las carteras y el soporte para personas que no sabían nada sobre las claves jerárquicas. La transición de la placa en el hackerspace al producto significó que la idea de seguridad debía ser dominada no solo por sus autores, sino también por la persona que abre la caja en casa.

Trezor se autodenomina la primera cartera de hardware del mundo. Es más preciso atribuir este primer lugar al fabricante y a una definición concreta del producto: un dispositivo comercial de propósito único para almacenar claves y confirmar transacciones de Bitcoin. La historia de los tokens de seguridad es más amplia, pero el Model One creó una categoría que el mercado de Bitcoin comenzó a seguir.

03

Dispositivo que se puede restaurar con palabras

El Trezor Model One se lanzó oficialmente el 29 de julio de 2014. La pequeña pantalla, dos botones y el cable USB ocultaban un cambio más significativo: la cartera ya no tenía que ser idéntica a un solo hardware. Si el dispositivo se perdía o se dañaba, el usuario podía restaurar las claves a partir de un conjunto de palabras.

Marek Palatinus y Pavol Rusnák son coautores de BIP 39. La propuesta explica cómo representar datos generados al azar mediante una lista de palabras y derivar de ella el seed de una cartera. La Seed Phrase permitió respaldar la base de muchas claves en un solo registro, sin copiar cada clave por separado. Si el usuario también utiliza una passphrase, la necesita igualmente para recuperar la cartera. La comodidad tiene una consecuencia: quien consiga los secretos necesarios también podrá restaurarla.

BIP 44 describió además la jerarquía de propósitos, monedas y cuentas sobre una cartera determinista. Los estándares permitieron que el software compatible encontrara nuevamente la misma estructura de direcciones a partir de una semilla. La restauración se volvió más usable, pero también dependiente de una comprensión correcta de la derivación y el soporte de las aplicaciones individuales.

El dispositivo protegía la clave durante el uso común, mientras que el respaldo en papel o metal protegía la posibilidad de restauración. Sin el respaldo, un Trezor destruido podría significar una pérdida. Con el respaldo expuesto, un atacante podría evitar el dispositivo por completo. La seguridad no dejó de depender del ser humano; solo obtuvo una división más clara de roles.

Este modelo ayudó a expandir la autogestión más allá del círculo estrecho de técnicos. El usuario podía mantener fondos a largo plazo y, al mismo tiempo, firmar pagos ocasionalmente sin importar la semilla a un ordenador en línea. El producto no simplificó Bitcoin ocultando la responsabilidad. Intentó organizarla en pasos que se pueden seguir de manera razonable.

04

Trezor no es una moneda ni un seguro

La cartera de hardware no almacena bitcoins como monedas en una caja fuerte. Almacena los secretos necesarios para firmar la transferencia de salidas registradas en la blockchain. Cuando el usuario destruye el dispositivo, pero tiene la semilla correcta, puede restaurar los fondos. Cuando alguien más obtiene la semilla, puede transferir los fondos sin el dispositivo original.

Ni siquiera la pantalla propia ayuda si la persona no lee los datos. Una aplicación fraudulenta puede mostrar la dirección correcta en el ordenador y enviar otra al dispositivo; la defensa funciona solo cuando el usuario compara la dirección en una pantalla de confianza. El elemento de seguridad es la oferta de control, no una garantía automática de una decisión correcta.

El fabricante y la comunidad aún deben ocuparse de los errores del firmware, la seguridad de la cadena de suministro y las actualizaciones. El código abierto permite examinar cómo funciona el dispositivo; no significa que cada propietario tenga que revisar por sí mismo cada línea. La Self-Custody también depende de los procedimientos de uso y de la confianza en las herramientas elegidas. El hardware asumió parte del trabajo, pero la responsabilidad del usuario no desapareció.

La historia de Trezor ofrece otra perspectiva frente a los relatos de discos duros perdidos y contraseñas olvidadas. Sus creadores no partían de la idea de que las personas dejarían de equivocarse. Buscaban una herramienta que ayudara a evitar algunos errores y a detectar otros a tiempo. Pero usarla también conlleva responsabilidades: anotar las palabras de recuperación, proteger esa copia de seguridad del fuego y de miradas ajenas, y practicar la recuperación de la cartera antes de una emergencia.

Desde la placa en el hackerspace de Praga, se convirtió en un producto global porque resolvió un problema que crecía con el valor de la red. Cuanto más había que proteger, menos aceptable era la elección entre una clave en línea y un archivo poco práctico. Trezor no eliminó el riesgo de la clave privada. Le dio una interfaz física en la que el ser humano puede ejercer realmente su responsabilidad.

Esta división de responsabilidades tiene también un lado incómodo. El fabricante puede publicar el diseño y las correcciones, pero no puede almacenar de forma segura las palabras de recuperación en nombre del usuario, verificar cada dirección ni reconocer una solicitud fraudulenta de introducción de la semilla. El dispositivo protege un momento determinado del proceso; la seguridad surge solo de la combinación de hardware verificado, software de confianza, una copia de seguridad física y una persona atenta. Trezor no es, por tanto, una cajita que haya eliminado la necesidad de comprender la propia custodia. Es un intento de traducir la responsabilidad criptográfica abstracta en unos pocos actos visibles en los que un error puede reconocerse con mayor facilidad antes de que se vuelva irreversible.

Atlas

Personajes y conceptos en el Atlas

CZ·02TrezorSLUSHMarek «Slush» PalatinusSTICKPavol «Stick» RusnákCZ·01SatoshiLabsHWHardware WalletKEYPrivate KeySEEDSeed PhraseKEYSAutocustodia
  1. 01
    Trezor — Una década de innovación

    Nombres de los fundadores, Brmlab, prototipos en Raspberry Pi y fecha de lanzamiento del Model One.

  2. 02
    Trezor — Acerca de Trezor

    Línea de tiempo de la empresa, BIP 39, BIP 44 y el producto Model One.

  3. 03
    BIP 39 — Código mnemónico para generar claves deterministas

    Especificación técnica de las palabras de restauración, su alcance y límites de seguridad.

  4. 04
    BIP 44 — Jerarquía de cuentas múltiples para carteras deterministas

    Especificación técnica de la jerarquía de cuentas, cuyos autores son Marek Palatinus y Pavol Rusnák.

Siguiente historia · 17Bitcoin Beach: una aldea que comenzó antes de la ley