O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Custódia institucional de Bitcoin no Google Cloud

Para proteger as reservas institucionais de Bitcoin sem criar um único ponto de comprometimento, é possível distribuir chaves de assinatura em enclaves isolados por hardware usando a computação multipartidária do Google Cloud . Neste documento, comparamos o Cloud Key Management Service (Cloud KMS) e o Cloud HSM com a computação multipartidária, avaliamos os dois modelos de segurança para custódia de Bitcoin e apresentamos uma topologia de referência.

Ao mover a custódia do Bitcoin para a nuvem, você escolhe entre duas arquiteturas de gerenciamento de chaves:

Módulos de segurança de hardware (HSMs) de chave única: o Cloud KMS e o Cloud HSM gerenciam chaves criptográficas estáticas dentro dos limites físicos do HSM.
Assinatura de limite distribuída: a computação multipartidária distribui compartilhamentos de chaves em ambientes de execução confiáveis (TEEs) isolados por hardware com suporte de chaves de raiz de confiança do HSM.

O Cloud KMS e o Cloud HSM são compatíveis com a criptografia de envelope empresarial e a infraestrutura de chave pública da Web. No entanto, eles não foram projetados para primitivos de custódia do Bitcoin, como derivação de chave determinística hierárquica (HD, na sigla em inglês) de acordo com a Proposta de Melhoria do Bitcoin 32 (BIP32, na sigla em inglês), assinatura Schnorr BIP340 e governança granular de várias partes.

Principais desafios na custódia de Bitcoin baseada na nuvem

A tabela a seguir resume três desafios principais que você encontra ao avaliar os serviços padrão de gerenciamento de chaves na nuvem para custódia de Bitcoin e como a computação multipartidária aborda cada requisito.

Requisito Limitação no Cloud KMS e no Cloud HSM Como a computação multipartidária atende a esse requisito

Derivação de chave BIP32

Requisito	Limitação no Cloud KMS e no Cloud HSM	Como a computação multipartidária atende a esse requisito
Derivação de chave BIP32	As partições multilocatárias do Cloud HSM são projetadas para gerenciamento de chaves estáticas e simples, como criptografia de envelope empresarial. Para preservar a segurança no nível do hipervisor em ambientes de nuvem compartilhados, os provedores de nuvem não permitem módulos de firmware de HSM personalizados. Portanto, o Cloud HSM não pode calcular caminhos de derivação BIP32 de forma nativa. Devido a essa restrição, o Cloud KMS exige arquiteturas de chave simples. Os aplicativos precisam rastrear recursos de chaves discretas ou derivar chaves filhas na memória do host não criptografada.	A computação multipartidária usa o homomorfismo linear do programa de span monótono DKLS23 para calcular caminhos de derivação BIP32 não reforçados localmente. Cada nó calcula de forma independente o ajuste de deslocamento escalar público (`I_L`) e aplica esse deslocamento à chave compartilhada local sem rodadas de comunicação de rede. Em carteiras de chave única, comprometer uma chave pública estendida pai (`xpub`) e uma chave privada filha não protegida permite que um invasor calcule a chave privada pai. A computação multipartidária remove essa exposição porque as chaves privadas filhas (`k_child`) não são montadas em texto simples. Eles existem apenas como compartilhamentos locais distribuídos e temporários (`s₁'`, `s₂'`) dentro da memória TEE criptografada por hardware.
Ponto único de comprometimento	A chave privada completa reside em um único limite físico do HSM. Uma credencial de autorização comprometida ou uma ameaça interna expõe toda a carteira.	A chave privada completa não existe em texto simples em nenhum local. As partes da chave são distribuídas matematicamente entre nós de computação independentes.
Agilidade de algoritmo (Schnorr e Taproot)	Os ciclos de hardware do HSM físico são lentos. Adicionar suporte a curvas elípticas ou esquemas de assinatura, como o BIP340 Schnorr na curva `secp256k1`, exige uma recertificação de hardware de vários anos.	As operações criptográficas são executadas em enclaves de VM confidencial isolados por hardware, o que permite que a computação multipartidária adote atualizações de protocolo sem modificar o limite físico do HSM.

As partições multilocatárias do Cloud HSM são projetadas para gerenciamento de chaves estáticas e simples, como criptografia de envelope empresarial. Para preservar a segurança no nível do hipervisor em ambientes de nuvem compartilhados, os provedores de nuvem não permitem módulos de firmware de HSM personalizados. Portanto, o Cloud HSM não pode calcular caminhos de derivação BIP32 de forma nativa.

Devido a essa restrição, o Cloud KMS exige arquiteturas de chave simples. Os aplicativos precisam rastrear recursos de chaves discretas ou derivar chaves filhas na memória do host não criptografada.

A computação multipartidária usa o homomorfismo linear do programa de span monótono DKLS23 para calcular caminhos de derivação BIP32 não reforçados localmente. Cada nó calcula de forma independente o ajuste de deslocamento escalar público (I_L) e aplica esse deslocamento à chave compartilhada local sem rodadas de comunicação de rede.

Em carteiras de chave única, comprometer uma chave pública estendida pai (xpub) e uma chave privada filha não protegida permite que um invasor calcule a chave privada pai. A computação multipartidária remove essa exposição porque as chaves privadas filhas (k_child) não são montadas em texto simples. Eles existem apenas como compartilhamentos locais distribuídos e temporários (s₁', s₂') dentro da memória TEE criptografada por hardware.

Ponto único de comprometimento

A chave privada completa reside em um único limite físico do HSM. Uma credencial de autorização comprometida ou uma ameaça interna expõe toda a carteira.

A chave privada completa não existe em texto simples em nenhum local. As partes da chave são distribuídas matematicamente entre nós de computação independentes.

Agilidade de algoritmo (Schnorr e Taproot)

Os ciclos de hardware do HSM físico são lentos. Adicionar suporte a curvas elípticas ou esquemas de assinatura, como o BIP340 Schnorr na curva secp256k1, exige uma recertificação de hardware de vários anos.

As operações criptográficas são executadas em enclaves de VM confidencial isolados por hardware, o que permite que a computação multipartidária adote atualizações de protocolo sem modificar o limite físico do HSM.

Comparar o Cloud KMS e a computação multipartidária

Ao projetar a infraestrutura de assinatura de ativos digitais no Google Cloud, é possível avaliar o modelo de HSM de chave única em relação ao modelo de limite distribuído.

Modelo de chave única do Cloud KMS e do Cloud HSM

Em uma implantação do Cloud KMS, o Cloud HSM gera uma chave de assinatura assimétrica que usa o algoritmo EC_SIGN_SECP256K1_SHA256 diretamente em um HSM físico validado pelo FIPS 140-2 nível 3. A figura a seguir mostra como uma camada do aplicativo interage com o Cloud HSM ao derivar chaves filhas:

Duas camadas de aplicativo de VM padrão interagindo com um limite de nível 3 do Cloud HSM FIPS
140-2, em que a derivação filha reforçada expõe a
chave pai na memória do host.

Essa arquitetura oferece validação gerenciada do FIPS 140-2 nível 3 e produz assinaturas do secp256k1 algoritmo de assinatura digital de curva elíptica (ECDSA, na sigla em inglês) normalizadas de baixo S que a rede Bitcoin aceita. No entanto, ele introduz duas limitações arquitetônicas para a custódia de Bitcoin:

Fragmentação do gerenciamento de chaves: como o Cloud HSM não pode calcular caminhos de derivação BIP32, seu aplicativo precisa rastrear milhões de IDs de recursos CryptoKey discretos no Cloud KMS, removendo fluxos de trabalho de recuperação de raiz única.
Risco de exposição da memória: para realizar a derivação reforçada, o aplicativo precisa exportar a semente raiz para a memória do host, o que quebra o perímetro de segurança do hardware.

Modelo de limite de computação multipartidária distribuída

A computação multipartidária implementa uma extensão reforçada do protocolo ECDSA de limite DKLS23. Em vez de gerar uma única chave completa, nós independentes em execução no Confidential Space em enclaves criptografados por hardware AMD SEV-SNP geram e mantêm compartilhamentos de chaves matemáticas. Para mais informações sobre o protocolo, consulte Contexto criptográfico do DKLS23.

A figura a seguir mostra como a computação multipartidária distribui a assinatura entre nós de TEE apoiados por chaves de criptografia de chaves de HSM independentes:

Solicitação de transação de Bitcoin roteada para dois nós de TEE que executam o
protocolo DKLS23 e desencapsulam compartilhamentos de chaves pelo Cloud HSM e pelo Cloud EKM.

Esse modelo de limite distribuído oferece três benefícios principais de segurança:

Nenhuma chave privada completa: nenhum dispositivo físico, enclave ou operador tem a chave privada completa.
Raiz de confiança ancorada em hardware: as chaves compartilhadas são criptografadas em repouso com chaves de criptografia de chaves (KEKs) protegidas por partições do Cloud HSM FIPS 140-2 nível 3 ou HSMs locais externos conectados pelo Cloud External Key Manager.
Descriptografia aplicada por atestado: o Cloud KMS desencapsula as partes da chave na memória do enclave somente quando uma cotação de atestado de hardware confirma que o nó executa imagens de contêiner de computação multipartidária verificadas e não adulteradas.

Mecanismos criptográficos para BIP32 e Taproot

Ao avaliar a assinatura de limite para custódia de Bitcoin, verifique se o protocolo é compatível com a derivação de endereço hierárquico e o ajuste do Taproot sem adicionar rodadas de rede entre nós.

Derivação aditiva BIP32 não reforçada

O BIP32 define a derivação de chave privada filha não reforçada como adição escalar modular:

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

Como a computação multipartidária usa um esquema de compartilhamento de segredo linear baseado em programas de span monotônico, os nós participantes derivam compartilhamentos de chaves filhas localmente com zero rodadas de comunicação de rede. A figura a seguir ilustra esse fluxo de derivação local de zero rodada:

O Nó 1 e o Nó 2 calculam de forma independente o ajuste escalar HMAC-SHA512
localmente, atualizando a Parte 1 e mantendo a Parte 2 inalterada, e executam uma
sessão de assinatura on-line do DKLS23.

Ajuste de chave Taproot BIP341

Essa propriedade linear também permite o ajuste de chaves Taproot BIP341 sem modificar a distribuição de compartilhamento de chaves:

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

Antes de participar da cerimônia de assinatura de limite, um nó participante aplica o ajuste escalar (t) diretamente ao compartilhamento de chave local. Esse recurso permite interagir com árvores de script Taproot, Ordinals e contratos de registro discretos sem gerar novamente ou compartilhar as chaves.

Comparação de arquitetura

A tabela a seguir compara o Cloud KMS e o Cloud HSM com a computação multipartidária em dimensões de custódia principais.

Dimensão arquitetônica	Cloud KMS e Cloud HSM	Computação multipartidária
Primitivos criptográficos	ECDSA de assinatura única na curva `secp256k1`	ECDSA de limite (DKLS23) e algoritmo de assinatura digital de curva de Edwards (EdDSA) de limite na curva `Ed25519`, extensível para Schnorr de limite na curva `secp256k1`
Limite de hardware	Placa HSM PCIe física	Enclaves do Confidential Space AMD SEV-SNP ancorados em uma raiz de confiança do Cloud HSM
Suporte à carteira BIP32 HD	Gerenciamento manual de chaves discretas do Cloud KMS	Ajuste de compartilhamento de chave aditiva local de zero rodada
Proteção de chave física	FIPS 140-2 Nível 3	FIPS 140-2 nível 3 para KEKs residentes em HSM que encapsulam compartilhamentos de chaves
Latência de assinatura (p95)	20 a 50 ms	Menos de 1.000 ms (menos de um segundo) em regiões distribuídas
Escopo afetado de uma violação de credenciais	Exposição completa da chave se as credenciais do autor da chamada ou as políticas do Identity and Access Management (IAM) forem comprometidas	Nenhuma assinatura não autorizada, a menos que um invasor comprometa um limite de enclaves e KEKs independentes simultaneamente
Auditoria	Registros de auditoria do Cloud	Registros de auditoria do Cloud e registros de atestado de hardware das Justificativas de acesso às chaves

Evolução do BIP32 para o gerenciamento de chaves de limite

Ao projetar uma plataforma interna de custódia de ativos digitais, faça a distinção entre os padrões de derivação criados para carteiras de hardware individuais e o gerenciamento de chaves distribuídas projetado para governança institucional. Embora o BIP32 seja amplamente usado para rastreamento de endereços, confiar em árvores de derivação do BIP32 para segurança em uma arquitetura de computação multipartidária (MPC) é redundante e pode adicionar complexidade operacional.

Contexto histórico de carteiras BIP32 de semente única

O BIP32 foi projetado com base nas restrições de autocustódia individual antes que a criptografia de limite e os enclaves de hardware se tornassem amplamente disponíveis:

Dependência de semente raiz: a custódia inicial do Bitcoin dependia da segurança física de uma única frase mnemônica legível por humanos de 12 ou 24 palavras.
Recuperação de backup único: as carteiras HD BIP32 permitem que um indivíduo faça backup de uma frase semente e derive endereços de forma determinística em várias contas.
Ponto único de falha: a semente mnemônica raiz representa um ponto único de falha total. Se um invasor comprometer essa frase ou o backup físico, todas as chaves privadas derivadas de todas as contas serão expostas.

A figura a seguir ilustra como o comprometimento de uma única semente raiz expõe todas as contas filhas derivadas:

Uma semente mnemônica raiz de 12 ou 24 palavras que se ramifica para a chave filha 1, a chave
filha 2 e a chave filha N, em que o comprometimento da semente expõe todas as chaves privadas
filhas derivadas.

Remover a semente raiz com assinatura de limite

Em uma arquitetura de nuvem institucional de confiança zero, uma semente mnemônica raiz legível por humanos não é necessária. A computação multipartidária elimina completamente a chave privada raiz central. Como não há uma chave privada completa em texto simples em nenhuma máquina ou mídia de backup, não é necessário recuperar o endereço de frase única. Em vez de derivar uma árvore de chaves de um segredo, a computação multipartidária distribui compartilhamentos de chaves independentes em enclaves criptograficamente isolados.

Comparar caminhos de derivação BIP32 na computação multipartidária

Se a integração exigir compatibilidade com o BIP32 para rastreadores de endereços externos ou fluxos de trabalho de contabilidade, compare os dois caminhos de implementação técnica na tabela a seguir.

Caminho de implementação Mecanismo criptográfico Perfil de segurança e exposição Latência e desempenho de assinatura

BIP32 não reforçado com computação multipartidária

Caminho de implementação	Mecanismo criptográfico	Perfil de segurança e exposição	Latência e desempenho de assinatura
BIP32 não reforçado com computação multipartidária	Ajuste aditivo local: `s₁' = (s₁ + I_L) mod n`. Cada nó calcula o deslocamento escalar público (`I_L`) de forma independente e aplica esse deslocamento à parcela de chave local.	Risco de chave única: em carteiras que não são MPC, comprometer uma chave pública pai (`xpub`) e uma chave privada filha permite que um invasor calcule a chave privada pai. Mitigação de MPC: as chaves privadas filhas (`k_child`) não são montadas em texto simples e existem apenas como compartilhamentos de chaves temporárias e distribuídas (`s₁'`, `s₂'`) dentro da memória TEE criptografada por hardware, impedindo a recuperação de chaves filhas para pais.	Não requer rodadas de comunicação de rede entre nós de MPC para derivar chaves filhas. É executado na velocidade da CPU local antes da assinatura. Oferece suporte a latências de assinatura de menos de um segundo (p95 menor que 1 segundo) em canais gRPC criptografados.
BIP32 reforçado com computação multipartidária	Hash interativo de várias partes `HMAC-SHA512` calculado sobre o material da chave pai compartilhado em segredo.	Protege contra o escalonamento de chaves de filho para pai ao fazer hash da chave privada pai, o que introduz uma complexidade de protocolo substancial. Não oferece nenhum benefício de segurança adicional em um ambiente de enclave com várias partes em que a chave pai já é compartilhada de forma secreta e protegida contra exfiltração.	Requer várias rodadas de rede interativas entre nós de MPC para avaliar um circuito de limite `HMAC-SHA512` em entradas compartilhadas em segredo. Aumenta a latência de assinatura e cria gargalos no processamento de transações.

Ajuste aditivo local: s₁' = (s₁ + I_L) mod n.

Cada nó calcula o deslocamento escalar público (I_L) de forma independente e aplica esse deslocamento à parcela de chave local.

Risco de chave única: em carteiras que não são MPC, comprometer uma chave pública pai (xpub) e uma chave privada filha permite que um invasor calcule a chave privada pai.
Mitigação de MPC: as chaves privadas filhas (k_child) não são montadas em texto simples e existem apenas como compartilhamentos de chaves temporárias e distribuídas (s₁', s₂') dentro da memória TEE criptografada por hardware, impedindo a recuperação de chaves filhas para pais.

Não requer rodadas de comunicação de rede entre nós de MPC para derivar chaves filhas.
É executado na velocidade da CPU local antes da assinatura.
Oferece suporte a latências de assinatura de menos de um segundo (p95 menor que 1 segundo) em canais gRPC criptografados.

BIP32 reforçado com computação multipartidária

Hash interativo de várias partes HMAC-SHA512 calculado sobre o material da chave pai compartilhado em segredo.

Protege contra o escalonamento de chaves de filho para pai ao fazer hash da chave privada pai, o que introduz uma complexidade de protocolo substancial.
Não oferece nenhum benefício de segurança adicional em um ambiente de enclave com várias partes em que a chave pai já é compartilhada de forma secreta e protegida contra exfiltração.

Requer várias rodadas de rede interativas entre nós de MPC para avaliar um circuito de limite HMAC-SHA512 em entradas compartilhadas em segredo.
Aumenta a latência de assinatura e cria gargalos no processamento de transações.

Recomendações para custódia institucional

A computação multipartidária é compatível com a derivação aditiva BIP32 não reforçada para compatibilidade com sistemas atuais e rastreadores de endereços externos. Para custódia institucional dedicada, considere a transição para chaves de limite independentes gerenciadas diretamente na computação multipartidária:

Eliminar dependências de raiz única: gerar, alternar e fazer backup de compartilhamentos de chaves independentes dentro de enclaves isolados, em vez de derivar chaves como deslocamentos matemáticos de uma única chave raiz.
Aumentar a agilidade do algoritmo: separe a camada de orquestração dos caminhos de derivação BIP32 específicos do Bitcoin para que você possa adotar esquemas de assinatura não ECDSA, como o esquema de assinatura Ed25519 para redes de contratos inteligentes, em um modelo de governança.
Reduzir a complexidade da assinatura: gerencie chaves de limite discretas para simplificar as pesquisas no banco de dados, manter as solicitações de transação concisas e minimizar a latência de assinatura.