Firma operativa: BitGo Express, firmantes externos y co-firmantes

Son las tres de la madrugada y un cliente pide retirar 40 000 USDC. La política de tesorería del módulo de wallets dice que ese monto sale de la wallet hot sin aprobación humana. Nadie abre una app ni pulsa un botón, y aun así la transacción tiene que salir firmada. Alguna pieza de software nuestra descifra una llave, firma y entrega la firma. ¿Cuál es, en qué máquina corre y quién más puede pedirle que firme?

Esa es la pregunta de este módulo, y aplica sobre todo al proyecto Middleware Blockchain (custodia y wallets con Fireblocks y BitGo). El módulo de custodia decidió quién responde por los activos; aquí bajamos al despliegue: qué proceso toca qué llave, en qué zona de red vive y qué controles lo rodean. El resultado es un diagrama de despliegue que el equipo de seguridad pueda revisar componente por componente.

Quién firma cuando nadie pulsa un botón

Un firmante es el componente que usa una llave privada (o un fragmento de llave) para producir una firma. Un co-firmante es otro firmante que aporta una segunda firma o un segundo fragmento para completar el umbral, como en el esquema 2 de 3 del módulo de tipos de firma. Lo que garantiza una firma y por qué reduce lo que hay que confiar está explicado en firmas criptográficas y reducción de nodos.

En BitGo, toda wallet en la cadena tiene tres llaves: la de usuario, la de respaldo y la de BitGo. [1] Una transacción normal completa el 2 de 3 con la llave de usuario y la de BitGo; la de respaldo solo entra en una recuperación. [2] Por tanto, la pregunta "quién firma" se reduce a "quién guarda la llave de usuario".

Si la wallet es de autocustodia, la llave de usuario es nuestra: BitGo solo recibe la llave de usuario cifrada y la llave pública de respaldo. [2] Entonces algún proceso nuestro debe descifrarla y firmar. Si la wallet es de custodia, el cliente no firma: lo hace BitGo con la llave de usuario, tras una verificación por video con un operador de BitGo Bank & Trust. [1] En ese caso no hay firmante nuestro que desplegar.

Dos términos más. Un HSM (hardware security module) es un dispositivo que genera y usa llaves sin dejarlas salir en claro. Un KMS (key management service) es un servicio, a menudo de la nube, que cifra, descifra y custodia llaves bajo control de acceso. Ambos aparecen cuando la llave de usuario no debe vivir en un archivo del servidor que firma.

BitGo Express: un proxy que firma dentro de nuestra red

BitGo Express es un servidor REST que corremos nosotros, en nuestro centro de datos o en nuestra nube. Hace dos trabajos: reenvía (proxy) las llamadas a la API de BitGo y realiza las operaciones del lado del cliente con nuestras llaves, como firmar parcialmente una transacción antes de enviarla. Según BitGo, las llaves privadas nunca salen de nuestra red y BitGo nunca las ve. [3] Existe para equipos que trabajan en un lenguaje sin SDK oficial de BitGo o que prefieren un servicio independiente del lenguaje. [4]

La figura sigue el retiro de las tres de la madrugada paso a paso. Nuestra app pide el envío a Express (1). Express pide a BitGo que construya la transacción y la recibe sin firmar (2). Express descifra la llave de usuario con la passphrase de la wallet y firma (3, 4). La transacción semifirmada viaja a BitGo (5), que evalúa sus políticas y co-firma con su llave (6) antes de difundirla (7).

Figura 1

Retiro firmado con BitGo Express

Fuentes:

[3][2]

Cómo leer esta figura

Dos zonas delimitadas con línea discontinua. A la izquierda, Nuestra red, con el rótulo la llave de usuario nunca sale de aquí, contiene tres cajas: Nuestra app (servicio de retiros), BitGo Express (proxy de la API, TLS, puerto propio) y debajo Firma local (llave de usuario cifrada más passphrase, o firmante externo). A la derecha, BitGo, con el rótulo guarda solo su propia llave, contiene API de BitGo arriba y Políticas y llave BitGo abajo. Fuera de ambas zonas, a la derecha, la Red blockchain. Pasos: 1, la app pide el envío a Express por localhost o TLS; 2, Express y la API construyen la transacción, flecha doble; 3, Express pide la firma parcial a Firma local; 4, Firma local devuelve la transacción; 5, Express envía la transacción semifirmada a la API; 6, la API pasa a Políticas y llave BitGo, que co-firma 2 de 3; 7, BitGo difunde a la red.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Para el código que llama a Express, el cambio es mínimo: las llamadas son idénticas a las de la API directa, pero apuntan a localhost:3080 en lugar del host de BitGo. [3] Para retiros simples, Express construye, firma y envía en una sola llamada; si hace falta más control, hay rutas separadas para cada paso. [5]

Una advertencia que evita un malentendido frecuente: en BitGo, aprobar una transacción no aplica una firma. [5] Las aprobaciones humanas del módulo de custodia ocurren en BitGo; la firma con la llave de usuario ocurre en Express. Son dos controles distintos y el diagrama de despliegue debe mostrar ambos.

Configurar Express para producción: puerto, interfaz y TLS

Cuatro parámetros deciden quién puede hablar con Express. El puerto por defecto es 3080 (BITGO_PORT) y la interfaz por defecto es localhost (BITGO_BIND); para escuchar en todas las interfaces hay que poner 0.0.0.0. [6] Si quien llama vive en el mismo host, Express puede escuchar en un socket IPC, que se protege con permisos y dueño de archivo como cualquier otro archivo. [6]

El tercero es TLS. Cuando Express apunta al entorno de producción y escucha en interfaces externas, debe arrancar con TLS (keyPath y crtPath); si no, falla al iniciar. El cuarto es NODE_ENV=production, que apaga información de depuración que podría filtrar datos del sistema. [4] BitGo recomienda correrlo con su contenedor Docker oficial. [3] El comando de producción que publica tiene esta forma: [7]

# Comando de la documentación de BitGo (ilustrativo: rutas y puerto son de ejemplo)
docker run --platform linux/amd64 -it -e NODE_ENV=production \
  --volume /path/to/certs:/private -p 4000:4000 \
  bitgo/express:latest -p 4000 -k /private/cert.key -c /private/cert.crt -e prod

La salida a internet tiene dos detalles que chocan con redes corporativas. Por defecto, Express solo acepta certificados de un conjunto propio de autoridades raíz para los dominios de BitGo; detrás de un proxy que inspecciona TLS, la variable NODE_EXTRA_CA_CERTS se ignora para esos dominios. Express sí puede salir por un proxy indicado en BITGO_USE_PROXY. [4] En la práctica, el proxy corporativo debe dejar pasar el tráfico a BitGo sin inspeccionarlo.

Por último, algunas operaciones solo existen en Express. La creación de Wallet Safes y de sus wallets hijas ejecuta ceremonias de llave locales: deben llamarse a través de Express, no de la API de BitGo, y la passphrase nunca sale del host de Express. [4]

El firmante externo: separar el proxy de las llaves

En el despliegue simple, el mismo proceso Express hace de proxy, sale a internet y guarda las llaves cifradas con sus passphrases. El modo de firmante externo separa esas funciones en dos instancias. La instancia de proxy apunta, con externalSignerUrl, a una segunda instancia que corre en una máquina aislada y es la única que guarda las llaves de usuario y firma. [8]

La instancia firmante arranca con --signerMode y --signerFileSystemPath, que apunta al archivo con las llaves privadas cifradas. Las passphrases le llegan como variables de entorno con el formato WALLET_<walletId>_PASSPHRASE. [8] Eso convierte la gestión de secretos del firmante en un punto de diseño: de dónde salen esas variables, quién puede leerlas y cómo se rotan.

Hay un límite documentado: las wallets MPC con ECDSA no son compatibles con el modo de firmante externo. [8] La página de retiros, en cambio, dice que la ruta de firma MPC admite el modo de firmante externo en un entorno aislado. [5] Leídas juntas, sugieren que el modo externo cubre multifirma y MPC con EdDSA, pero no MPC con ECDSA, que es el caso de Ethereum y de los tokens ERC-20 como USDC. Esa lectura es nuestra y queda a validar con el proveedor.

La segunda regla afecta a la alta disponibilidad. Cada signerFileSystemPath debe pertenecer a un solo proceso firmante, porque ese proceso mantiene un registro de fragmentos ya consumidos; compartirlo entre réplicas puede perder registros que protegen contra repeticiones. [4] Escalar el firmante no es replicar un contenedor detrás de un balanceador: cuántas instancias y con qué archivos es otro punto a validar con BitGo.

Advanced Wallets: llaves en nuestro HSM o KMS

Las Advanced Wallets son wallets hot de autocustodia en las que la llave de usuario y la de respaldo se gestionan con nuestro propio HSM o KMS, en nuestra región o jurisdicción. Usan dos servidores Express dedicados, y BitGo sigue gestionando la llave BitGo. [9]

El primero es el Master BitGo Express (MBE): un Express normal, fuera de la zona segura, que orquesta las operaciones entre la API de BitGo y el segundo servidor, y que necesita salida a app.bitgo.com. El segundo es el Advanced Wallet Manager (AWM): un servidor ligero, aislado en una subred interna sin acceso a internet, que genera llaves, firma transacciones multifirma y ejecuta recuperaciones. [9]

El AWM usa mTLS (TLS con autenticación mutua: cada lado presenta un certificado) y solo acepta conexiones entrantes del MBE y salientes hacia nuestro KMS. [9] La integración con el HSM o KMS es trabajo nuestro: BitGo publica la especificación de la API del proveedor de llaves, pero no la implementa. [9] El esfuerzo de ingeniería cambia de "operar un contenedor" a "construir y certificar un servicio de llaves".

La documentación menciona firma multifirma en el AWM; si las Advanced Wallets cubren también wallets MPC, y para qué activos, es un punto a validar con el proveedor. Elegir entre Advanced Wallets y Express con firmante externo es una decisión conjunta del equipo de seguridad y de BitGo, no de este capítulo.

Cuándo no hace falta un firmante nuestro

La forma más simple de no operar un firmante es no tener llave que firmar. En las wallets de custodia de BitGo, que son siempre frías, BitGo firma con la llave de usuario después de la verificación por video; tiene un SLA de 24 horas para completar retiros, y se pueden configurar políticas que eliminen la verificación por video en condiciones definidas por el cliente. [1] Para esas wallets basta la API REST, sin Express.

El Go Account, la cuenta ómnibus de BitGo con libro fuera de la cadena, tiene una ruta de envío en Express. Las páginas de BitGo no coinciden sobre si usa una sola llave o es una multifirma de custodia, así que su necesidad de firmante es un punto a validar. [1]

Para el proyecto que usa stablecoins con Circle Mint, la cuenta Mint es un servicio de Circle y el capítulo de USDC y Circle Mint no documenta ninguna llave nuestra en ese flujo. En cuanto los USDC salen a una wallet de autocustodia propia, este capítulo vuelve a aplicar.

Dónde se coloca el firmante y quién puede llamarlo

Volvamos al retiro de las tres de la madrugada, pero ahora con un atacante dentro de la red interna. Si Express escucha en 0.0.0.0 sin restricciones, cualquier proceso que lo alcance y tenga un token de acceso de BitGo puede pedir un envío. La primera línea de defensa no es criptográfica: es quién puede abrir una conexión con el firmante.

Cuatro reglas cubren la mayoría de los casos. Primera: Express vive en una subred privada, sin entrada desde internet, y solo el servicio de retiros puede llamarlo, por política de red y con TLS o un socket IPC. Segunda: la única salida permitida es hacia los dominios de BitGo, directa o por el proxy de BITGO_USE_PROXY. Tercera: las passphrases salen de un gestor de secretos, nunca del repositorio ni de la imagen. Cuarta: la llave de respaldo no vive en ningún host de Express.

La cuarta regla tiene una razón concreta. Las políticas de BitGo solo se aplican a transacciones en las que participa la llave BitGo; una recuperación con llave de usuario y llave de respaldo las omite. [10] Un host que guarde las dos llaves puede mover fondos sin pasar por ningún límite. El ciclo de vida de llaves ya pedía guardar el respaldo aparte; aquí se vuelve una regla de despliegue.

Las políticas de BitGo también ofrecen un control complementario: una regla de tipo webhook que decide según la respuesta de un servicio nuestro. [10] Eso permite que la lógica de negocio (límites por cliente, screening) diga la última palabra antes de que BitGo co-firme, sin que esa lógica tenga acceso a ninguna llave.

Cómo lo resuelven Fireblocks, BitGo y Kaleido

El equivalente de Fireblocks es el API Co-Signer. Lo alojamos en nuestro entorno, en una máquina con enclave: un entorno de ejecución aislado que protege código y datos incluso de usuarios privilegiados del propio host. Corre sobre Intel SGX, AWS Nitro o Google Cloud Confidential Space. Se empareja con usuarios de API: para un Signer o Admin guarda un fragmento MPC y firma junto a dos co-firmantes en la nube de Fireblocks; para un Approver guarda una llave de aprobación y solo aprueba. [11]

La diferencia de red es importante. El Co-Signer consulta al SaaS de Fireblocks si hay solicitudes pendientes; no espera llamadas entrantes. [11] Nuestra lógica entra por un Callback Handler, un servidor HTTPS propio que aprueba, rechaza o pide reintento; si no responde en 30 segundos, la solicitud falla, y el handler puede aprobar pero no puede crear una firma. [12] Sin handler configurado, el Co-Signer firma o aprueba todo lo que le llega para ese usuario. [11]

Kaleido declara que no genera ni guarda llaves: se crean en el keystore del cliente. En su modelo híbrido, Kaleido opera la plataforma y nosotros alojamos el Zero Trust Verifier junto a nuestro HSM, donde se evalúan las políticas antes de cada firma. [13] Circle y Tether no entran en esta comparación: son emisores de stablecoins, y la firma de nuestras wallets la resuelven los proveedores anteriores.

Fuentes de la tabla: Express, [4] Advanced Wallets, [9] políticas de BitGo, [10] Co-Signer [11] y Kaleido. [13] Las firmas por umbral en que se apoya el MPC se explican en firmas umbral y agregadas.

Decisiones que el equipo debe cerrar

Entregable: diagrama de despliegue del firmante

El entregable es un diagrama de despliegue acompañado de una tabla que lo hace auditable. El diagrama dibuja zonas de red y flechas con su sentido; la tabla dice, para cada componente, qué llave toca y qué controles lo rodean. Las filas de ejemplo son ilustrativas y corresponden al patrón Express con firmante externo.

# Esqueleto del diagrama (ilustrativo)
[Zona aplicación]   servicio-retiros --(mTLS)--> [Subred privada] express-proxy --(TLS, salida)--> api.bitgo
[Subred privada]    express-proxy --(TLS)--> [Zona aislada] firmante-externo (llave de usuario)
[Fuera de línea]    llave de respaldo (sin ruta de red)
Reglas: entrada a express solo desde servicio-retiros; salida de firmante: ninguna

Una revisión rápida del diagrama hace tres preguntas: ¿hay alguna flecha que llegue al firmante desde algo distinto del servicio autorizado?, ¿hay alguna caja que guarde dos llaves de la misma wallet?, ¿hay alguna llave en claro fuera de su zona? Si alguna respuesta es sí, el diseño vuelve a la mesa.

Con el firmante desplegado, el siguiente paso es decidir qué fondos dejamos entrar y salir: AML y KYT, el módulo 7.