Custodia institucional de Bitcoin en Google Cloud

Vista previa

Este producto está sujeto a las "Condiciones de la oferta previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Los productos de la fase previa a la DG están disponibles "sin modificaciones" y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Para proteger las reservas institucionales de Bitcoin sin crear un único punto de vulneración, puedes distribuir las claves de firma entre enclaves aislados por hardware con la computación multipartita de Google Cloud . En este documento, se comparan Cloud Key Management Service (Cloud KMS) y Cloud HSM con la computación multipartita, se evalúan ambos modelos de seguridad para la custodia de Bitcoin y se presenta una topología de referencia.

Cuando trasladas la custodia de Bitcoin a la nube, eliges entre dos arquitecturas de administración de claves:

• Módulos de seguridad de hardware (HSM) de clave única: Cloud KMS y Cloud HSM administran claves criptográficas estáticas dentro de los límites físicos del HSM.
• Firma de umbral distribuida: La computación multipartita distribuye los recursos compartidos de claves en entornos de ejecución confiables (TEE) aislados por hardware respaldados por claves de raíz de confianza de HSM.

Cloud KMS y Cloud HSM admiten la encriptación de sobre empresarial y la infraestructura de clave pública web. Sin embargo, no se diseñaron para primitivas de custodia de Bitcoin, como la derivación de claves determinísticas jerárquicas (HD) según la propuesta de mejora de Bitcoin 32 (BIP32), la firma Schnorr BIP340 y la gobernanza multipartita detallada.

Desafíos clave en la custodia de Bitcoin basada en la nube

En la siguiente tabla, se resumen tres desafíos principales que encuentras cuando evalúas los servicios estándar de administración de claves en la nube para la custodia de Bitcoin y cómo la computación multipartita aborda cada requisito.

Requisito	Limitación en Cloud KMS y Cloud HSM	Cómo la computación multipartita aborda este requisito
Derivación de claves BIP32	Las particiones de Cloud HSM multiusuario están diseñadas para la administración de claves estáticas y planas, como la encriptación de sobre empresarial. Para preservar la seguridad a nivel del hipervisor en entornos de nube compartidos, los proveedores de servicios en la nube no permiten módulos de firmware de HSM personalizados, por lo que Cloud HSM no puede calcular las rutas de derivación de BIP32 de forma nativa. Debido a esta restricción, Cloud KMS requiere arquitecturas de claves planas. Las aplicaciones deben realizar un seguimiento de los recursos de claves discretas o derivar claves secundarias en la memoria del host sin encriptar.	La computación multipartita usa el homomorfismo lineal del programa de intervalo monótono DKLS23 para calcular rutas de derivación BIP32 no endurecidas de forma local. Cada nodo calcula de forma independiente el ajuste de compensación escalar público (IL) y aplica esa compensación a su recurso compartido de claves local con cero rondas de comunicación de red. En las billeteras de clave única, si se vulneran tanto una clave pública extendida superior (xpub) como una clave privada secundaria no reforzada, un atacante puede calcular la clave privada superior. La computación multipartita quita esta exposición porque las claves privadas secundarias (kchild) no se ensamblan en texto sin formato. Solo existen como recursos compartidos locales efímeros y distribuidos (s1', s2') dentro de la memoria del TEE encriptada por hardware.
Punto único de vulneración	La clave privada completa reside dentro de un solo límite físico de HSM. Una credencial de autorización comprometida o una amenaza interna exponen toda la billetera.	La clave privada completa no existe en texto simple en ninguna ubicación. Los fragmentos de claves se distribuyen matemáticamente entre nodos de procesamiento independientes.
Agilidad de algoritmos (Schnorr y Taproot)	Los ciclos de hardware de HSM físico son lentos. Agregar compatibilidad con curvas elípticas o esquemas de firma, como BIP340 Schnorr, en la curva secp256k1 requiere una recertificación de hardware de varios años.	Las operaciones criptográficas se ejecutan dentro de Confidential VMs aisladas por hardware, lo que permite que la computación multipartita adopte actualizaciones de protocolo sin modificar el límite físico del HSM.

Compara Cloud KMS y la computación multipartita

Cuando diseñas la infraestructura de firma de recursos digitales en Google Cloud, puedes evaluar el modelo de HSM de clave única en comparación con el modelo de umbral distribuido.

Modelo de Cloud KMS y Cloud HSM de clave única

En una implementación de Cloud KMS, Cloud HSM genera una clave de firma asimétrica que usa el algoritmo EC_SIGN_SECP256K1_SHA256 directamente dentro de un HSM físico validado con el nivel 3 del estándar FIPS 140-2. En la siguiente figura, se muestra cómo una capa de aplicación interactúa con Cloud HSM cuando se derivan claves secundarias:

Esta arquitectura proporciona una validación administrada de nivel 3 de FIPS 140-2 y produce firmas de algoritmo de firma digital de curva elíptica (ECDSA) secp256k1 normalizadas de S baja que acepta la red de Bitcoin. Sin embargo, presenta dos limitaciones de arquitectura para la custodia de Bitcoin:

• Fragmentación de la administración de claves: Debido a que Cloud HSM no puede calcular las rutas de derivación de BIP32, tu aplicación debe realizar un seguimiento de millones de IDs de recursos de CryptoKey discretos en Cloud KMS, lo que quita los flujos de trabajo de recuperación de raíz única.
• Riesgo de exposición de la memoria: Para realizar una derivación reforzada, tu aplicación debe exportar la semilla raíz a la memoria del host, lo que rompe el perímetro de seguridad del hardware.

Modelo de umbral de computación multipartita distribuida

La computación multipartita implementa una extensión reforzada del protocolo ECDSA de umbral DKLS23. En lugar de generar una sola clave completa, los nodos independientes que se ejecutan dentro de Confidential Space en enclaves encriptados por hardware de AMD SEV-SNP generan y conservan recursos compartidos de claves matemáticas. Para obtener más información sobre el protocolo, consulta Antecedentes criptográficos de DKLS23.

En la siguiente figura, se muestra cómo la computación multipartita distribuye la firma entre los nodos de TEE respaldados por claves de encriptación de claves de HSM independientes:

Este modelo de umbral distribuido proporciona tres beneficios de seguridad principales:

• No hay una clave privada completa: ningún dispositivo físico, enclave ni operador individual tiene la clave privada completa.
• Raíz de confianza anclada al hardware: Los recursos compartidos de claves se encriptan en reposo con claves de encriptación de claves (KEK) protegidas por particiones de Cloud HSM de nivel 3 de FIPS 140-2 o HSM locales externos conectados a través de Cloud External Key Manager.
• Desencriptación aplicada por certificación: Cloud KMS desenvuelve los recursos compartidos de claves en la memoria del enclave solo cuando una cita de certificación de hardware confirma que el nodo ejecuta imágenes de contenedor de procesamiento multipartito verificadas y sin alteraciones.

Mecanismos criptográficos para BIP32 y Taproot

Cuando evalúes la firma de umbral para la custodia de Bitcoin, verifica que el protocolo admita la derivación de direcciones jerárquicas y el ajuste de Taproot sin agregar rondas de red entre nodos.

Derivación aditiva de BIP32 no reforzada

BIP32 define la derivación de claves privadas secundarias no endurecidas como una suma escalar modular:

\[ k_{\text{child} } = (k_{\text{par} } + \text{parse}_{256}(I_L)) \bmod n \]

Debido a que la computación multipartita usa un esquema de uso compartido de secretos lineal basado en programas de intervalo monótono, los nodos participantes derivan claves compartidas secundarias de forma local con cero rondas de comunicación de red. En la siguiente figura, se ilustra este flujo de derivación local de cero rondas:

Ajuste de claves de Taproot de BIP341

Esta propiedad lineal también admite el ajuste de claves de Taproot de BIP341 sin modificar la distribución de claves subyacente:

\[ Q = P + t \cdot G \quad \text{where} \quad t = H_{\text{TapTweak} }(P \parallel \text{MerkleRoot}) \]

Antes de participar en la ceremonia de firma de umbral, un nodo participante aplica el ajuste escalar (t) directamente a su recurso compartido de clave local. Esta capacidad te permite interactuar con árboles de secuencias de comandos de Taproot, ordinales y contratos de registro discretos sin volver a generar ni compartir claves.

Comparación de arquitectura

En la siguiente tabla, se comparan Cloud KMS y Cloud HSM con la computación multipartita en las dimensiones de custodia principales.

Dimensión de la arquitectura	Cloud KMS y Cloud HSM	Computación multipartita
Primitivas criptográficas	ECDSA de firma única en la curva secp256k1	ECDSA de umbral (DKLS23) y algoritmo de firma digital de curva de Edwards (EdDSA) de umbral en la curva Ed25519, extensible al Schnorr de umbral en la curva secp256k1
Límite de hardware	Tarjeta PCIe HSM física	Enclaves de Confidential Space de AMD SEV-SNP anclados a una raíz de confianza de Cloud HSM
Compatibilidad con la billetera HD BIP32	Administración manual de claves de Cloud KMS discretas	Ajuste de uso compartido de claves aditivas locales sin rondas
Protección con llave física	FIPS 140-2 Nivel 3	Nivel 3 del estándar FIPS 140-2 para las KEK residentes en HSM que unen claves compartidas
Latencia de firma (p95)	De 20 a 50 ms	Menos de 1,000 ms (menos de un segundo) en regiones distribuidas
Alcance afectado de una violación de la seguridad de las credenciales	Exposición completa de la clave si se vulneran las credenciales del emisor o las políticas de Identity and Access Management (IAM)	No se permite la firma no autorizada, a menos que un atacante vulnere un umbral de enclaves y KEK independientes de forma simultánea.
Auditabilidad	Registros de auditoría de Cloud	Registros de auditoría de Cloud y registros de certificación de hardware de Key Access Justifications

Evolución de BIP32 a la administración de claves de umbral

Cuando diseñes una plataforma interna de custodia de recursos digitales, distingue entre los estándares de derivación creados para billeteras de hardware individuales y la administración de claves distribuida diseñada para la gobernanza institucional. Aunque BIP32 se usa ampliamente para el seguimiento de direcciones, depender de los árboles de derivación de BIP32 para la seguridad dentro de una arquitectura de computación multipartita (MPC) es redundante y puede agregar complejidad operativa.

Contexto histórico de las billeteras BIP32 de frase de origen única

BIP32 se diseñó en torno a las restricciones de la autocustodia individual antes de que la criptografía de umbral y los enclaves de hardware estuvieran ampliamente disponibles:

• Dependencia de la semilla raíz: La custodia temprana de Bitcoin dependía de la protección física de una sola frase mnemotécnica legible por humanos de 12 o 24 palabras.
• Recuperación con una sola copia de seguridad: Las billeteras HD BIP32 permiten que una persona cree una copia de seguridad de una frase de origen y derive direcciones de forma determinística en varias cuentas.
• Punto único de fallo: La frase mnemotécnica raíz representa un punto único de fallo total. Si un atacante vulnera esa frase o copia de seguridad física, todas las claves privadas secundarias derivadas de todas las cuentas quedan expuestas.

En la siguiente figura, se ilustra cómo vulnerar una sola semilla raíz expone todas las cuentas secundarias derivadas:

Quita la semilla raíz con la firma de umbral

En una arquitectura de nube institucional de confianza cero, no se requiere una frase mnemotécnica raíz legible por humanos. La computación multipartita elimina por completo la clave privada raíz central. Como no existe una clave privada completa en texto simple en ninguna máquina o medio de copia de seguridad, no necesitas la recuperación de direcciones con una sola frase. En lugar de derivar un árbol de claves de un secreto, la computación multipartita distribuye claves compartidas independientes en enclaves aislados criptográficamente.

Compara las rutas de derivación de BIP32 en la computación multipartita

Si tu integración requiere compatibilidad con BIP32 para los seguimientos de direcciones externas o los flujos de trabajo de contabilidad, compara las dos rutas de implementación técnica en la siguiente tabla.

Ruta de implementación	Mecanismo criptográfico	Perfil de seguridad y exposición	Rendimiento de latencia y firma
BIP32 no reforzado con computación multipartita	Ajuste aditivo local: s1' = (s1 + IL) mod n. Cada nodo calcula el desplazamiento escalar público (IL) de forma independiente y aplica ese desplazamiento a su recurso compartido de claves local.	Riesgo de clave única: En las billeteras que no son de MPC, si se vulneran una clave pública superior (xpub) y una clave privada secundaria, un atacante puede calcular de forma inversa la clave privada superior. Mitigación de MPC: Las claves privadas secundarias (kchild) no se ensamblan en texto simple y solo existen como recursos compartidos de claves efímeros y distribuidos (s1', s2') dentro de la memoria de TEE encriptada por hardware, lo que evita la recuperación de claves de secundarias a principales.	No requiere rondas de comunicación de red entre los nodos de MPC para derivar claves secundarias. Se ejecuta a la velocidad de la CPU local antes de la firma. Admite latencias de firma de menos de un segundo (p95 inferior a 1 segundo) en canales de gRPC encriptados.
BIP32 reforzado con computación multipartita	Hash HMAC-SHA512 interactivo de varias partes calculado sobre el material de la clave superior de secreto compartido.	Protege contra la elevación de claves de secundarias a principales mediante el hash de la clave privada principal, lo que introduce una complejidad de protocolo sustancial. No proporciona ningún beneficio de seguridad adicional en un entorno de enclave de varias partes en el que la clave superior ya se comparte de forma secreta y está protegida contra el robo de datos.	Requiere varias rondas de red interactivas entre los nodos de MPC para evaluar un circuito de umbral HMAC-SHA512 sobre entradas de secreto compartido. Aumenta la latencia de firma y crea cuellos de botella en el procesamiento de transacciones.

Recomendaciones para la custodia institucional

La computación multipartita admite la derivación aditiva de BIP32 no reforzada para la compatibilidad con sistemas existentes y rastreadores de direcciones externos. Para la custodia institucional dedicada, considera la posibilidad de realizar la transición a claves de umbral independientes administradas directamente en la computación multipartita:

• Elimina las dependencias de raíz única: genera, rota y crea copias de seguridad de los recursos de claves independientes dentro de enclaves aislados en lugar de derivar claves como desplazamientos matemáticos de una sola clave raíz.
• Aumenta la agilidad del algoritmo: Desvincula tu capa de organización de las rutas de derivación BIP32 específicas de Bitcoin para que puedas adoptar esquemas de firma que no sean ECDSA, como el esquema de firma Ed25519 para redes de contratos inteligentes, en un modelo de administración.
• Reduce la complejidad de la firma: Administra claves de umbral discretas para simplificar las búsquedas en la base de datos, mantener las solicitudes de transacciones concisas y minimizar la latencia de la firma.