Custodia istituzionale di Bitcoin su Google Cloud

Per proteggere le riserve di Bitcoin istituzionali senza creare un singolo punto di compromissione, puoi distribuire le chiavi di firma tra enclave isolate dall'hardware utilizzando il calcolo multipartitico di Google Cloud . Questo documento mette a confronto Cloud Key Management Service (Cloud KMS) e Cloud HSM con il calcolo multipartitico, valuta entrambi i modelli di sicurezza per la custodia di Bitcoin e presenta una topologia di riferimento.

Quando sposti la custodia di Bitcoin nel cloud, scegli tra due architetture di gestione delle chiavi:

  • Moduli di sicurezza hardware (HSM) a chiave singola: Cloud KMS e Cloud HSM gestiscono le chiavi di crittografia statiche all'interno dei confini fisici degli HSM.
  • Firma con soglia distribuita: il calcolo multipartitico distribuisce le condivisioni delle chiavi in ambienti Trusted Execution Environment (TEE) isolati dall'hardware supportati da chiavi root of trust HSM.

Cloud KMS e Cloud HSM supportano la crittografia envelope aziendale e l'infrastruttura a chiave pubblica web. Tuttavia, non sono stati progettati per le primitive di custodia di Bitcoin, come la derivazione delle chiavi gerarchiche deterministiche (HD) secondo la proposta di miglioramento di Bitcoin 32 (BIP32), la firma Schnorr BIP340 e la governance multi-party granulare.

Le principali sfide della custodia di Bitcoin basata su cloud

La tabella seguente riassume tre sfide principali che si incontrano quando si valutano i servizi di gestione delle chiavi cloud standard per la custodia di Bitcoin e il modo in cui il calcolo multipartitico risponde a ciascun requisito.

Requisito Limitazione in Cloud KMS e Cloud HSM In che modo il calcolo multipartitico soddisfa questo requisito
Derivazione delle chiavi BIP32

Le partizioni Cloud HSM multi-tenant sono progettate per la gestione statica e piatta delle chiavi, come la crittografia envelope aziendale. Per preservare la sicurezza a livello di hypervisor negli ambienti cloud condivisi, i provider cloud non consentono moduli firmware HSM personalizzati, pertanto Cloud HSM non può calcolare i percorsi di derivazione BIP32 in modo nativo.

A causa di questo vincolo, Cloud KMS richiede architetture di chiavi piatte. Le applicazioni devono monitorare risorse di chiavi discrete o derivare chiavi secondarie nella memoria host non criptata.

Il calcolo multipartitico utilizza l'omomorfismo lineare del programma di span monotono DKLS23 per calcolare localmente i percorsi di derivazione BIP32 non sottoposti ad aumento della protezione. Ogni nodo calcola in modo indipendente l'offset scalare pubblico (IL) e lo applica alla propria condivisione di chiavi locale senza round di comunicazione di rete.

Nei portafogli a chiave singola, la compromissione di una chiave pubblica estesa principale (xpub) e di una chiave privata secondaria non protetta consente a un malintenzionato di calcolare la chiave privata principale. Il calcolo multipartitico rimuove questa esposizione perché le chiavi private secondarie (kchild) non vengono assemblate in testo non crittografato. Esistono solo come condivisioni locali distribuite ed temporanee (s1', s2') all'interno della memoria TEE criptata tramite hardware.
Single point of compromise

La chiave privata completa si trova all'interno di un unico confine HSM fisico. Una credenziale di autorizzazione compromessa o una minaccia interna espone l'intero wallet.

La chiave privata completa non esiste in testo non crittografato in nessuna singola posizione. Le condivisioni delle chiavi sono distribuite matematicamente tra nodi di computing indipendenti.
Agilità degli algoritmi (Schnorr e Taproot)

I cicli dell'hardware HSM fisico sono lenti. L'aggiunta del supporto per le curve ellittiche o gli schemi di firma come BIP340 Schnorr sulla curva secp256k1 richiede una ricertificazione dell'hardware pluriennale.

Le operazioni di crittografia vengono eseguite all'interno di enclave di Confidential VM isolate dall'hardware, il che consente al calcolo multipartitico di adottare gli aggiornamenti del protocollo senza modificare il confine fisico dell'HSM.

Confronta Cloud KMS e il calcolo multipartitico

Quando progetti l'infrastruttura di firma degli asset digitali su Google Cloud, puoi valutare il modello HSM a chiave singola rispetto al modello a soglia distribuita.

Modello Cloud KMS e Cloud HSM con chiave singola

In un deployment di Cloud KMS, Cloud HSM genera una chiave di firma asimmetrica che utilizza l'algoritmo EC_SIGN_SECP256K1_SHA256 direttamente all'interno di un HSM fisico convalidato FIPS 140-2 livello 3. La figura seguente mostra come un livello di applicazione interagisce con Cloud HSM durante la derivazione delle chiavi secondarie:

Due livelli di applicazione VM standard che interagiscono con un confine Cloud HSM FIPS 140-2 livello 3, in cui la derivazione secondaria con protezione avanzata espone la chiave principale nella memoria host.

Questa architettura fornisce la convalida FIPS 140-2 di livello 3 gestita e produce firme ECDSA (Elliptic Curve Digital Signature Algorithm) secp256k1 normalizzate con S bassa accettate dalla rete Bitcoin. Tuttavia, introduce due limitazioni architetturali per la custodia di Bitcoin:

  • Frammentazione della gestione delle chiavi: poiché Cloud HSM non può calcolare i percorsi di derivazione BIP32, la tua applicazione deve monitorare milioni di ID risorsa CryptoKey discreti in Cloud KMS, rimuovendo i workflow di recupero con root singola.
  • Rischio di esposizione della memoria: per eseguire la derivazione con protezione avanzata, l'applicazione deve esportare il seed root nella memoria host, il che interrompe il perimetro di sicurezza dell'hardware.

Modello di soglia di calcolo multipartitico distribuito

Il calcolo multipartitico implementa un'estensione con protezione avanzata del protocollo ECDSA con soglia DKLS23. Anziché generare una singola chiave completa, i nodi indipendenti in esecuzione all'interno di Confidential Space su enclave criptate con hardware AMD SEV-SNP generano e conservano condivisioni di chiavi matematiche. Per saperne di più sul protocollo, consulta Background crittografico DKLS23.

La figura seguente mostra come il calcolo multipartitico distribuisce la firma tra i nodi TEE supportati da chiavi di crittografia delle chiavi HSM indipendenti:

Richiesta di transazione Bitcoin indirizzata a due nodi TEE che eseguono il protocollo DKLS23 e scompongono le condivisioni delle chiavi tramite Cloud HSM e Cloud EKM.

Questo modello di soglia distribuita offre tre vantaggi principali in termini di sicurezza:

  • Nessuna chiave privata completa: nessun singolo dispositivo fisico, enclave o operatore detiene la chiave privata completa.
  • Radice di attendibilità basata su hardware: le condivisioni delle chiavi vengono crittografate at-rest con chiavi di crittografia delle chiavi (KEK) protette da partizioni Cloud HSM FIPS 140-2 livello 3 o HSM on-premise esterni connessi tramite Cloud External Key Manager.
  • Decrittografia basata sull'attestazione: Cloud KMS esegue l'unwrapping delle condivisioni delle chiavi nella memoria dell'enclave solo quando una quota di attestazione hardware conferma che il nodo esegue immagini container di calcolo multipartitico verificate e non manomesse.

Meccanismi crittografici per BIP32 e Taproot

Quando valuti la firma con soglia per la custodia di Bitcoin, verifica che il protocollo supporti la derivazione gerarchica degli indirizzi e l'ottimizzazione di Taproot senza aggiungere round di rete tra nodi.

Derivazione additiva BIP32 non rinforzata

BIP32 definisce la derivazione della chiave privata secondaria non rinforzata come addizione scalare modulare:

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

Poiché il calcolo multipartitico utilizza uno schema di condivisione segreta lineare basato su programmi di span monotoni, i nodi partecipanti derivano le condivisioni delle chiavi secondarie localmente con zero round di comunicazione di rete. La figura seguente illustra questo flusso di derivazione locale zero-round:

Il Nodo 1 e il Nodo 2 calcolano in modo indipendente l'aggiustamento scalare HMAC-SHA512 localmente, aggiornando la Condivisione 1 e mantenendo invariata la Condivisione 2, ed eseguono una sessione di firma DKLS23 online.

Modifica della chiave Taproot BIP341

Questa proprietà lineare supporta anche l'ottimizzazione della chiave Taproot BIP341 senza modificare la distribuzione della condivisione della chiave sottostante:

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

Prima di partecipare alla cerimonia di firma della soglia, un nodo partecipante applica l'aggiustamento scalare (t) direttamente alla propria condivisione della chiave locale. Questa funzionalità ti consente di interagire con alberi di script Taproot, Ordinals e Discreet Log Contracts senza rigenerare o ricondividere le chiavi.

Confronto dell'architettura

La tabella seguente mette a confronto Cloud KMS e Cloud HSM con il calcolo multipartitico in base alle dimensioni principali della custodia.

Dimensione architettonica Cloud KMS e Cloud HSM Multi-party Compute
Primitive crittografiche ECDSA a firma singola sulla curva secp256k1 ECDSA a soglia (DKLS23) e Digital Signature Algorithm (EdDSA) basato sulle curve di Edwards a soglia sulla curva Ed25519, estensibile a Schnorr a soglia sulla curva secp256k1
Confine dell'hardware Scheda HSM PCIe fisica Enclave Confidential Space AMD SEV-SNP ancorate a una radice di attendibilità di Cloud HSM
Supporto del wallet HD BIP32 Gestione manuale di chiavi Cloud KMS distinte Modifica della condivisione della chiave additiva locale senza round
Protezione con chiave fisica FIPS 140-2 Livello 3 FIPS 140-2 livello 3 per le KEK residenti in HSM che eseguono il wrapping delle condivisioni di chiavi
Latenza di firma (p95) 20-50 ms Meno di 1000 ms (meno di un secondo) tra regioni distribuite
Ambito interessato da una violazione delle credenziali Esposizione completa della chiave se le credenziali del chiamante o le policy di Identity and Access Management (IAM) sono compromesse Nessuna firma non autorizzata, a meno che un utente malintenzionato non comprometta contemporaneamente una soglia di enclave e KEK indipendenti
Funzioni di audit Cloud Audit Logs Cloud Audit Logs e log di attestazione hardware di Key Access Justifications

Evoluzione da BIP32 alla gestione delle chiavi di soglia

Quando progetti una piattaforma di custodia di asset digitali interna, distingui tra gli standard di derivazione creati per i singoli wallet hardware e la gestione delle chiavi distribuite progettata per la governance istituzionale. Sebbene BIP32 sia ampiamente utilizzato per il monitoraggio degli indirizzi, fare affidamento sugli alberi di derivazione BIP32 per la sicurezza all'interno di un'architettura di calcolo multipartitico (MPC) è ridondante e può aggiungere complessità operativa.

Contesto storico dei wallet BIP32 con seed singolo

BIP32 è stato progettato in base ai vincoli dell'autocustodia individuale prima che la crittografia a soglia e le enclave hardware diventassero ampiamente disponibili:

  • Dipendenza dal seed principale: la custodia iniziale di Bitcoin si basava sulla protezione fisica di una singola frase mnemonica leggibile di 12 o 24 parole.
  • Recupero con un singolo backup: i wallet HD BIP32 consentono a un individuo di eseguire il backup di una seed phrase e di derivare in modo deterministico gli indirizzi su più account.
  • Single point of failure: il seed mnemonico principale rappresenta un single point of failure totale. Se un malintenzionato compromette questa frase o il backup fisico, tutte le chiavi private secondarie derivate di tutti gli account vengono esposte.

La figura seguente illustra come la compromissione di un singolo seed radice espone ogni account secondario derivato:

Un seed mnemonico radice di 12 o 24 parole che si dirama in Chiave secondaria 1, Chiave secondaria 2 e Chiave secondaria N, dove la compromissione del seed espone tutte le chiavi private secondarie derivate.

Rimuovi il seed radice con la firma di soglia

In un'architettura cloud istituzionale Zero Trust, non è necessario un seed mnemonico radice leggibile. Il calcolo multipartitico elimina completamente la chiave privata root centrale. Poiché non esiste una chiave privata completa in testo non crittografato su un singolo computer o supporto di backup, non è necessario il recupero dell'indirizzo con una singola frase. Invece di derivare un albero di chiavi da un secret, il calcolo multipartitico distribuisce condivisioni di chiavi indipendenti in enclave isolate dal punto di vista crittografico.

Confronta i percorsi di derivazione BIP32 nel calcolo multipartitico

Se la tua integrazione richiede la compatibilità con BIP32 per i tracker di indirizzi esterni o i workflow di contabilità, confronta i due percorsi di implementazione tecnica nella tabella seguente.

Percorso di implementazione Meccanismo crittografico Profilo di sicurezza ed esposizione Latenza e prestazioni di firma
BIP32 non rinforzato con calcolo multipartitico

Modifiche additive locali: s1' = (s1 + IL) mod n.

Ogni nodo calcola l'offset scalare pubblico (IL) in modo indipendente e lo applica alla propria condivisione della chiave locale.
  • Rischio di chiave singola: nei wallet non MPC, la compromissione di una chiave pubblica principale (xpub) e di una chiave privata secondaria consente a un malintenzionato di ricalcolare la chiave privata principale.
  • Mitigazione MPC: le chiavi private secondarie (kchild) non vengono assemblate in testo non crittografato ed esistono solo come condivisioni di chiavi distribuite temporanee (s1', s2') all'interno della memoria TEE con crittografia hardware, impedendo il recupero delle chiavi da secondarie a principali.
  • Non richiede round di comunicazione di rete tra i nodi MPC per derivare le chiavi secondarie.
  • Viene eseguito alla velocità della CPU locale prima della firma.
  • Supporta latenze di firma inferiori al secondo (p95 inferiore a 1 secondo) su canali gRPC criptati.
BIP32 con protezione avanzata e calcolo multipartitico

Interactive multi-party HMAC-SHA512 hash computed over secret-shared parent key material.
  • Protegge dall'escalation delle chiavi da figlio a genitore eseguendo l'hashing della chiave privata del genitore, il che introduce una notevole complessità del protocollo.
  • Non offre alcun vantaggio aggiuntivo in termini di sicurezza in un ambiente enclave multi-party in cui la chiave principale è già condivisa in modo segreto e protetta dall'esfiltrazione.
  • Richiede più round di rete interattivi tra i nodi MPC per valutare un circuito HMAC-SHA512 di soglia su input condivisi in modo segreto.
  • Aumenta la latenza di firma e crea colli di bottiglia nell'elaborazione delle transazioni.

Consigli per la custodia istituzionale

Il calcolo multipartitico supporta la derivazione additiva BIP32 non con protezione avanzata per la compatibilità con i sistemi esistenti e i tracker di indirizzi esterni. Per la custodia istituzionale dedicata, valuta la possibilità di passare a chiavi di soglia indipendenti gestite direttamente nel calcolo multipartitico:

  • Elimina le dipendenze da una singola radice: genera, ruota ed esegui il backup di condivisioni di chiavi indipendenti all'interno di enclave isolate anziché derivare le chiavi come offset matematici da una singola chiave radice.
  • Aumenta l'agilità degli algoritmi: disaccoppia il livello di orchestrazione dai percorsi di derivazione BIP32 specifici di Bitcoin in modo da poter adottare schemi di firma non ECDSA, come lo schema di firma Ed25519 per le reti di smart contract, in un unico modello di governance.
  • Riduci la complessità della firma: gestisci chiavi di soglia discrete per semplificare le ricerche nel database, mantenere concise le richieste di transazione e ridurre al minimo la latenza della firma.