Llaves: generación, guarda, respaldo y rotación

Martes, 9:40. La persona que aprueba retiros grandes pierde su teléfono en el metro. En ese teléfono vivía uno de los fragmentos de la llave que firma la wallet de tesorería. Nadie sabe todavía si alguien puede usarlo, y el equipo de operación pregunta si debe congelar los retiros. La respuesta depende de decisiones que se tomaron (o no) meses antes: dónde se generó la llave, en cuántas partes se dividió, quién tiene el respaldo y cuál es el procedimiento escrito para este caso.

En el módulo anterior vimos que una transacción firmada no se revoca. La consecuencia es directa: quien controla la llave controla los fondos. Este capítulo recorre el ciclo de vida de esa llave (generación, guarda, uso, respaldo, rotación y baja) y termina con una plantilla de responsables para cada etapa.

Dónde vive la llave: entera en un HSM o repartida en fragmentos

Una llave privada es un número secreto que permite firmar; su llave pública se deriva de ella y permite a cualquiera verificar esas firmas. Qué garantiza exactamente una firma digital, y qué no, está en por qué las firmas criptográficas reducen los nodos necesarios. Para custodia, la pregunta práctica es otra: en qué componente existe la llave y quién puede pedirle que firme.

Hay dos modelos institucionales. En el primero, la llave existe entera dentro de un HSM (hardware security module): un dispositivo que genera y usa llaves sin dejarlas salir de su frontera física. El estándar de referencia para validarlos es FIPS 140-3, alineado con ISO/IEC 19790, que define cuatro niveles de seguridad crecientes; el nivel debe elegirse según el entorno y el riesgo. [1]

En el segundo modelo, la llave nunca existe entera. Se usa computación multiparte (MPC, multi-party computation): varias partes generan cada una un fragmento (key share) y firman juntas sin reconstruir la llave. NIST describe estos esquemas de umbral así: al menos k de n componentes deben participar para firmar, y menos de k no pueden firmar ni aprender nada de la llave. [2]

Un matiz sobre la nota de MPC: en 2026 NIST publicó su primera convocatoria para esquemas de umbral multiparte, es decir, el proceso de estandarización está abierto, no cerrado. [3] Eso no invalida el uso de MPC, pero sí significa que la evaluación del protocolo de cada proveedor recae en el equipo y en sus auditorías.

Derivación jerárquica: una semilla, miles de direcciones

Escenario: cada cliente necesita su propia dirección de depósito. Generar y respaldar una llave independiente por cliente sería inmanejable. La solución estándar es la derivación jerárquica determinista (HD, hierarchical deterministic): de una sola semilla se deriva un árbol de llaves.

BIP-39 convierte entre 128 y 256 bits de entropía en una frase de 12 a 24 palabras, y de esa frase obtiene una semilla de 512 bits con PBKDF2, HMAC-SHA512 y 2048 iteraciones; una contraseña opcional (passphrase) cambia por completo la semilla resultante. [4] BIP-32 define cómo derivar llaves hijas de esa semilla, y BIP-44 fija la ruta m / purpose' / coin_type' / account' / change / address_index. [5] [6]

BIP-32 distingue dos tipos de hijos. Los endurecidos (marcados con apóstrofo) solo se pueden derivar con la llave privada del padre. Los normales se pueden derivar también desde la clave pública extendida (xpub) del padre. Esa propiedad es útil: un servidor de depósitos puede generar direcciones nuevas sin tener ninguna llave privada.

El precio es una advertencia que todo el equipo debe conocer. Según BIP-32, quien conoce la xpub de un padre y cualquier llave privada hija no endurecida puede calcular la llave privada del padre y, con ella, todo el subárbol. Por eso las xpub deben tratarse con más cuidado que una llave pública común, y los niveles de cuenta se derivan endurecidos. [5] Además, una xpub compartida con un auditor le permite ver todos los movimientos de esa cuenta: no roba fondos, pero sí expone la operación completa. El capítulo Cuentas, claves y direcciones sin humo lo desarrolla con ejemplos.

Un último detalle operativo: BIP-44 fija en 20 el número de direcciones vacías consecutivas tras el cual el software deja de buscar fondos. [6] Si el sistema reparte miles de direcciones y la mayoría nunca recibe nada, una recuperación con una herramienta estándar puede no encontrar los fondos de las direcciones altas. La recuperación debe conocer el índice máximo usado.

Generación y uso: la ceremonia y la política

La llave se genera una vez y se usa miles de veces; los errores de la generación duran toda su vida. Por eso se hace en una ceremonia: un procedimiento escrito, con al menos dos testigos, en un equipo controlado, con un acta de quién estuvo, qué se generó y dónde quedó cada parte. En el modelo HSM, la llave nace dentro del módulo. En MPC, cada parte genera su fragmento por separado y solo se publica la llave pública común.

NIST llama criptoperiodo al tiempo durante el cual una llave está autorizada para usarse. Para una llave privada de firma recomienda un máximo de uno a tres años y su destrucción al final del periodo. [7] La misma norma define los estados por los que pasa: preactivada, activa, suspendida, desactivada, comprometida y destruida. Usar esos nombres en los sistemas internos facilita la auditoría.

El uso es la etapa más larga. Aquí la regla es que nadie pide una firma directamente: la pide un sistema que primero evalúa una política (quién inicia, cuánto, hacia dónde). El módulo de tipos de firma explica cuántas aprobaciones exigir y dónde se verifican.

Figura 1

Ciclo de vida de una llave de firma

Fuentes:

[7][2]

Cómo leer esta figura

Fila superior con cinco cajas conectadas: generación (con testigos), uso (tras la política), respaldo (fuera de línea), rotación (llave nueva) y baja (destrucción). Bajo cada una, su responsable: seguridad y dos testigos; operación como iniciador; custodios del respaldo; tesorería y seguridad; seguridad y auditoría. Una flecha ocre sale de rotación y vuelve a generación con el rótulo rotar: la llave nueva vuelve a empezar y se barren los fondos. Abajo a la izquierda, panel HSM: una caja azul frontera de hardware con la llave k completa recibe una flecha pide firma desde una caja política fuera del HSM. Abajo a la derecha, panel MPC fragmentos 2 de 3: tres cajas moradas s1, s2 y s3 rotuladas cliente, proveedor y respaldo, con la nota dos fragmentos firman juntos; k nunca se reconstruye.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Respaldo y recuperación: perder un dispositivo no es perder los fondos

Volvamos al teléfono perdido. Si ese fragmento era uno de tres y el quórum es dos, los fondos siguen accesibles con los otros dos, y quien encuentre el teléfono no puede firmar solo. Lo que hay que hacer es retirar ese fragmento y emitir uno nuevo para la persona, no improvisar.

Aquí aparece una tensión con la práctica clásica de gestión de llaves. NIST recomienda, en general, no respaldar llaves privadas de firma, porque una copia debilita la garantía de que solo su dueño firmó; admite excepciones y exige que, cuando haya respaldo, quede bajo control del dueño. [7] En activos digitales la excepción es la norma: si la llave se pierde, los fondos se pierden, porque el protocolo no tiene un "olvidé mi contraseña".

La salida es respaldar sin crear un punto único de fallo: el respaldo se guarda fuera de línea, repartido entre custodios distintos y con un procedimiento de recuperación probado. Un respaldo que nunca se restauró en un simulacro es una hipótesis. Dos preguntas que el procedimiento debe contestar por escrito: qué pasa si se pierde un aprobador (se reemite su fragmento o su llave), y qué pasa si el proveedor deja de operar (cómo se recuperan los fondos sin él).

Rotación y baja sin perder fondos

Rotar una contraseña es cambiarla en el mismo lugar. Rotar una llave de una dirección no funciona así: en una cuenta controlada por llave, la dirección es función de la llave pública. Cambiar la llave significa generar direcciones nuevas y mover los fondos a ellas con una transacción firmada por la llave vieja.

Eso convierte la rotación en una operación de tesorería, con su costo de comisiones, su ventana de riesgo y un efecto externo: clientes y contrapartes que tenían registrada la dirección vieja deben actualizarla. La rotación se dispara por fin del criptoperiodo, por salida de una persona con acceso, o por sospecha de compromiso; en este último caso no se espera a la ventana planificada.

Hay una alternativa en MPC: algunos protocolos permiten renovar los fragmentos sin cambiar la llave pública ni las direcciones, de modo que los fragmentos viejos dejan de servir. Si cada proveedor lo ofrece, cómo se activa y qué evidencia deja es un punto a validar con el proveedor. La baja cierra el ciclo: se vacían las direcciones, se destruyen llave, fragmentos y respaldos, y se levanta un acta.

Cómo lo resuelven Fireblocks, BitGo y Kaleido

Los tres proveedores responden distinto a la pregunta "dónde vive la llave". La tabla resume lo que dicen sus documentos públicos; los detalles contractuales se validan con cada uno.

Fireblocks usa una llave maestra por espacio de trabajo, dividida en tres fragmentos, y deriva las wallets con la ruta m/purpose/coinType/account/change/index, donde el identificador de la cuenta de bóveda ocupa el nivel de cuenta. [8] Según su guía de recuperación, un fragmento queda en hardware del cliente (la app móvil de cada firmante o el servidor del API Co-signer) y dos en proveedores de nube, nunca juntos. [9]

Los fragmentos que gestiona Fireblocks se guardan en enclaves Intel SGX, que aíslan el material criptográfico incluso frente a quien controla el sistema operativo. [10] Para quien quiere la llave en su propio HSM, Fireblocks documenta Key Link: llaves de firma externas secp256k1 o Ed25519 certificadas por una llave de validación del cliente. [11]

BitGo usa tres llaves en todas sus wallets en cadena: de usuario, de respaldo y de BitGo, con firma 2 de 3. En autocustodia el cliente genera las llaves de usuario y de respaldo, y BitGo siempre la suya; en custodia, BitGo genera las tres y las reparte de modo que ninguna persona controle más de una. En MPC, ninguna parte ve la llave completa, y cada fragmento puede dividirse hasta 99 veces. [12]

Para wallets frías, BitGo recomienda crear las llaves en una máquina aislada de la red y enviar a BitGo solo las públicas. [13] Su asistente de recuperación mueve fondos sin BitGo usando las llaves de usuario y de respaldo, y esas transacciones saltan las políticas configuradas en BitGo. [14] Eso convierte la llave de respaldo en la más sensible de las tres.

Kaleido afirma que su producto de custodia no genera ni guarda llaves privadas: se crean dentro del almacén que elija el cliente, con soporte nativo para siete HSM y almacenes (Thales Luna, IBM OSO, Fortanix, AWS CloudHSM, GCP Cloud HSM, Azure Key Vault y HashiCorp Vault) y cualquier HSM PKCS#11 mediante su Zero Trust Verifier, que además aplica la política antes de firmar. [15] No encontramos en su documentación pública un modelo de fragmentos MPC: si se necesita, es un punto a validar con el proveedor.

Decisiones del módulo y entregable

El entregable es el ciclo de vida de llaves con responsables. La plantilla siguiente se completa por cada tipo de wallet; los roles son ejemplos que el equipo ajusta a su organigrama.

El siguiente módulo, Tipos de firma: multifirma frente a MPC, toma la llave ya custodiada y responde cuántas personas o sistemas deben aprobar cada firma y dónde se verifica esa aprobación.