Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Penitipan Bitcoin institusional di Google Cloud

Untuk melindungi cadangan Bitcoin institusional tanpa membuat satu titik kompromi, Anda dapat mendistribusikan kunci penandatanganan di seluruh enclave yang diisolasi hardware dengan menggunakan Google Cloud Multi-party Compute. Dokumen ini membandingkan Cloud Key Management Service (Cloud KMS) dan Cloud HSM dengan Multi-party Compute, mengevaluasi kedua model keamanan untuk penyimpanan Bitcoin, dan menyajikan topologi referensi.

Saat memindahkan kustodi Bitcoin ke cloud, Anda dapat memilih di antara dua arsitektur pengelolaan kunci:

Modul keamanan hardware (HSM) kunci tunggal: Cloud KMS dan Cloud HSM mengelola kunci kriptografis statis di dalam batas HSM fisik.
Penandatanganan nilai minimum terdistribusi: Multi-party Compute mendistribusikan bagian kunci di seluruh trusted execution environment (TEE) yang diisolasi hardware dan didukung oleh kunci root-of-trust HSM.

Cloud KMS dan Cloud HSM mendukung enkripsi amplop perusahaan dan infrastruktur kunci publik web. Namun, HSM tidak dirancang untuk primitif kustodi Bitcoin seperti derivasi kunci hierarkis deterministik (HD) berdasarkan Bitcoin Improvement Proposal 32 (BIP32), penandatanganan Schnorr BIP340, dan tata kelola multi-pihak yang terperinci.

Tantangan utama dalam kustodi Bitcoin berbasis cloud

Tabel berikut merangkum tiga tantangan utama yang Anda hadapi saat mengevaluasi layanan pengelolaan kunci cloud standar untuk penyimpanan Bitcoin, dan cara Multi-party Compute memenuhi setiap persyaratan.

Persyaratan Batasan di Cloud KMS dan Cloud HSM Cara Multi-party Compute memenuhi persyaratan ini

Derivasi kunci BIP32

Persyaratan	Batasan di Cloud KMS dan Cloud HSM	Cara Multi-party Compute memenuhi persyaratan ini
Derivasi kunci BIP32	Partisi Cloud HSM multi-tenant dirancang untuk pengelolaan kunci statis dan datar, seperti enkripsi amplop perusahaan. Untuk menjaga keamanan tingkat hypervisor di lingkungan cloud bersama, penyedia cloud tidak mengizinkan modul firmware HSM kustom, sehingga Cloud HSM tidak dapat menghitung jalur derivasi BIP32 secara native. Karena batasan ini, Cloud KMS memerlukan arsitektur kunci datar. Aplikasi harus melacak resource kunci diskret atau mendapatkan kunci turunan dalam memori host yang tidak dienkripsi.	Multi-party Compute menggunakan homomorfisme linear dari program span monoton DKLS23 untuk menghitung jalur derivasi BIP32 yang tidak diperkuat secara lokal. Setiap node secara independen menghitung penyesuaian offset skalar publik (`I_L`) dan menerapkan offset tersebut ke pembagian kunci lokalnya tanpa putaran komunikasi jaringan. Di dompet kunci tunggal, membobol kunci publik yang diperluas induk (`xpub`) dan satu kunci pribadi turunan yang tidak diperkuat memungkinkan penyerang menghitung kunci pribadi induk. Multi-party Compute menghilangkan eksposur ini karena kunci pribadi turunan (`k_child`) tidak disusun dalam teks biasa. Kunci tersebut hanya ada sebagai pembagian lokal sementara yang didistribusikan (`s₁'`, `s₂'`) di dalam memori TEE yang dienkripsi hardware.
Titik tunggal penyusupan	Kunci pribadi lengkap berada di dalam satu batas HSM fisik. Kredensial otorisasi yang disusupi atau ancaman orang dalam akan mengekspos seluruh dompet.	Kunci pribadi lengkap tidak ada dalam teks biasa di satu lokasi mana pun. Berbagi kunci didistribusikan secara matematis di seluruh node komputasi independen.
Agilitas algoritma (Schnorr dan Taproot)	Siklus hardware HSM fisik lambat. Menambahkan dukungan untuk kurva elips atau skema tanda tangan seperti BIP340 Schnorr pada kurva `secp256k1` memerlukan sertifikasi ulang hardware selama beberapa tahun.	Operasi kriptografi berjalan di dalam enclave Confidential VM yang terisolasi hardware, sehingga Multi-party Compute dapat mengadopsi update protokol tanpa mengubah batas HSM fisik.

Partisi Cloud HSM multi-tenant dirancang untuk pengelolaan kunci statis dan datar, seperti enkripsi amplop perusahaan. Untuk menjaga keamanan tingkat hypervisor di lingkungan cloud bersama, penyedia cloud tidak mengizinkan modul firmware HSM kustom, sehingga Cloud HSM tidak dapat menghitung jalur derivasi BIP32 secara native.

Karena batasan ini, Cloud KMS memerlukan arsitektur kunci datar. Aplikasi harus melacak resource kunci diskret atau mendapatkan kunci turunan dalam memori host yang tidak dienkripsi.

Multi-party Compute menggunakan homomorfisme linear dari program span monoton DKLS23 untuk menghitung jalur derivasi BIP32 yang tidak diperkuat secara lokal. Setiap node secara independen menghitung penyesuaian offset skalar publik (I_L) dan menerapkan offset tersebut ke pembagian kunci lokalnya tanpa putaran komunikasi jaringan.

Di dompet kunci tunggal, membobol kunci publik yang diperluas induk (xpub) dan satu kunci pribadi turunan yang tidak diperkuat memungkinkan penyerang menghitung kunci pribadi induk. Multi-party Compute menghilangkan eksposur ini karena kunci pribadi turunan (k_child) tidak disusun dalam teks biasa. Kunci tersebut hanya ada sebagai pembagian lokal sementara yang didistribusikan (s₁', s₂') di dalam memori TEE yang dienkripsi hardware.

Titik tunggal penyusupan

Kunci pribadi lengkap berada di dalam satu batas HSM fisik. Kredensial otorisasi yang disusupi atau ancaman orang dalam akan mengekspos seluruh dompet.

Kunci pribadi lengkap tidak ada dalam teks biasa di satu lokasi mana pun. Berbagi kunci didistribusikan secara matematis di seluruh node komputasi independen.

Agilitas algoritma (Schnorr dan Taproot)

Siklus hardware HSM fisik lambat. Menambahkan dukungan untuk kurva elips atau skema tanda tangan seperti BIP340 Schnorr pada kurva secp256k1 memerlukan sertifikasi ulang hardware selama beberapa tahun.

Operasi kriptografi berjalan di dalam enclave Confidential VM yang terisolasi hardware, sehingga Multi-party Compute dapat mengadopsi update protokol tanpa mengubah batas HSM fisik.

Membandingkan Cloud KMS dan Multi-party Compute

Saat mendesain infrastruktur penandatanganan aset digital di Google Cloud, Anda dapat mengevaluasi model HSM kunci tunggal terhadap model nilai minimum terdistribusi.

Model Cloud KMS dan Cloud HSM kunci tunggal

Dalam deployment Cloud KMS, Cloud HSM menghasilkan kunci penandatanganan asimetris yang menggunakan algoritma EC_SIGN_SECP256K1_SHA256 langsung di dalam HSM fisik yang divalidasi FIPS 140-2 Level 3. Gambar berikut menunjukkan cara lapisan aplikasi berinteraksi dengan Cloud HSM saat memperoleh kunci turunan:

Dua lapisan aplikasi VM standar yang berinteraksi dengan batas Cloud HSM FIPS 140-2 Level 3, tempat turunan turunan yang diperkuat mengekspos kunci induk di memori host.

Arsitektur ini menyediakan validasi FIPS 140-2 Level 3 terkelola dan menghasilkan tanda tangan secp256k1 Elliptic Curve Algoritma Tanda Tangan Digital (ECDSA) yang dinormalisasi S rendah yang diterima jaringan Bitcoin. Namun, hal ini menimbulkan dua batasan arsitektur untuk kustodi Bitcoin:

Fragmentasi pengelolaan kunci: karena Cloud HSM tidak dapat menghitung jalur turunan BIP32, aplikasi Anda harus melacak jutaan ID resource CryptoKey terpisah di Cloud KMS, sehingga menghapus alur kerja pemulihan root tunggal.
Risiko eksposur memori: untuk melakukan derivasi yang diperkuat, aplikasi Anda harus mengekspor root seed ke memori host, yang melanggar perimeter keamanan hardware.

Model nilai minimum Distributed Multi-party Compute

Multi-party Compute menerapkan ekstensi yang diperkuat dari protokol ECDSA nilai minimum DKLS23. Alih-alih membuat satu kunci lengkap, node independen yang berjalan di dalam Confidential Space pada enclave terenkripsi hardware AMD SEV-SNP membuat dan menyimpan bagian kunci matematika. Untuk mengetahui informasi selengkapnya tentang protokol ini, lihat latar belakang kriptografis DKLS23.

Gambar berikut menunjukkan cara Multi-party Compute mendistribusikan penandatanganan di seluruh node TEE yang didukung oleh kunci enkripsi kunci HSM independen:

Permintaan transaksi Bitcoin dirutekan ke dua node TEE yang menjalankan protokol DKLS23 dan membuka paket pembagian kunci melalui Cloud HSM dan Cloud EKM.

Model nilai minimum terdistribusi ini memberikan tiga manfaat keamanan utama:

Tidak ada kunci pribadi yang lengkap: tidak ada satu pun perangkat fisik, enclave, atau operator yang menyimpan kunci pribadi yang lengkap.
Root of trust berbasis hardware: pembagian kunci dienkripsi dalam penyimpanan di bawah kunci enkripsi kunci (KEK) yang dilindungi oleh partisi Cloud HSM FIPS 140-2 Level 3 atau HSM lokal eksternal yang terhubung melalui Cloud External Key Manager.
Dekripsi yang diterapkan pengesahan: Cloud KMS membuka paket pembagian kunci ke dalam memori enclave hanya jika kutipan pengesahan hardware mengonfirmasi bahwa node menjalankan image container Multi-party Compute yang diverifikasi dan tidak diubah.

Mekanisme kriptografi untuk BIP32 dan Taproot

Saat Anda mengevaluasi penandatanganan nilai minimum untuk penyimpanan Bitcoin, pastikan protokol mendukung derivasi alamat hierarkis dan penyesuaian Taproot tanpa menambahkan putaran jaringan antar-node.

Derivasi aditif BIP32 yang tidak diperkuat

BIP32 mendefinisikan turunan kunci pribadi turunan yang tidak diperkeras sebagai penambahan skalar modular:

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

Karena Multi-party Compute menggunakan skema berbagi rahasia linear yang dibangun di atas program span monoton, node peserta memperoleh pembagian kunci turunan secara lokal tanpa putaran komunikasi jaringan. Gambar berikut mengilustrasikan alur turunan lokal tanpa putaran ini:

Node 1 dan Node 2 secara independen menghitung penyesuaian skalar HMAC-SHA512
secara lokal, memperbarui Share 1 sambil mempertahankan Share 2, dan menjalankan
sesi penandatanganan DKLS23 online.

Penyesuaian kunci Taproot BIP341

Properti linear ini juga mendukung penyesuaian kunci Taproot BIP341 tanpa mengubah distribusi pembagian kunci yang mendasarinya:

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

Sebelum berpartisipasi dalam upacara penandatanganan nilai minimum, node peserta menerapkan tweak skalar (t) langsung ke pembagian kunci lokalnya. Kemampuan ini memungkinkan Anda berinteraksi dengan hierarki skrip Taproot, Ordinal, dan Discreet Log Contract tanpa membuat ulang atau membagikan ulang kunci.

Perbandingan arsitektur

Tabel berikut membandingkan Cloud KMS dan Cloud HSM dengan Multi-party Compute di seluruh dimensi pengamanan inti.

Dimensi arsitektur	Cloud KMS dan Cloud HSM	Komputasi Banyak Pihak
Primitif kriptografis	ECDSA tanda tangan tunggal pada kurva `secp256k1`	Threshold ECDSA (DKLS23) dan threshold Edwards-curve Digital Signature Algorithm (EdDSA) pada kurva `Ed25519`, dapat diperluas ke threshold Schnorr pada kurva `secp256k1`
Batas hardware	Kartu HSM PCIe fisik	Enklave Confidential Space AMD SEV-SNP yang ditambatkan ke root of trust Cloud HSM
Dukungan dompet HD BIP32	Pengelolaan manual kunci Cloud KMS diskret	Penyesuaian pembagian kunci aditif lokal tanpa putaran
Perlindungan kunci fisik	FIPS 140-2 Level 3	FIPS 140-2 Level 3 untuk KEK yang berada di HSM yang menggabungkan pembagian kunci
Latensi penandatanganan (p95)	20-50 md	Kurang dari 1.000 md (sub-detik) di seluruh region yang didistribusikan
Cakupan pelanggaran kredensial yang terpengaruh	Eksposur kunci lengkap jika kredensial pemanggil atau kebijakan Identity and Access Management (IAM) disusupi	Tidak ada penandatanganan yang tidak sah kecuali jika penyerang membahayakan batas enklave independen dan KEK secara bersamaan
Auditabilitas	Cloud Audit Logs	Log pengesahan hardware Cloud Audit Logs dan Key Access Justifications

Evolusi dari BIP32 ke pengelolaan kunci nilai minimum

Saat Anda mendesain platform kustodian aset digital internal, bedakan antara standar derivasi yang dibuat untuk dompet hardware individual dan pengelolaan kunci terdistribusi yang dirancang untuk tata kelola institusional. Meskipun BIP32 banyak digunakan untuk pelacakan alamat, mengandalkan pohon derivasi BIP32 untuk keamanan di dalam arsitektur multi-party computation (MPC) adalah hal yang berlebihan dan dapat menambah kompleksitas operasional.

Konteks historis dompet BIP32 seed tunggal

BIP32 dirancang berdasarkan batasan penyimpanan mandiri individu sebelum kriptografi ambang batas dan enclave hardware tersedia secara luas:

Dependensi seed root: kustodi Bitcoin awal mengandalkan pengamanan fisik frasa mnemonik tunggal yang dapat dibaca manusia yang terdiri dari 12 atau 24 kata.
Pemulihan cadangan tunggal: Dompet HD BIP32 memungkinkan seseorang mencadangkan satu frasa seed dan memperoleh alamat secara deterministik di beberapa akun.
Titik tunggal kegagalan: root mnemonic seed mewakili total titik tunggal kegagalan. Jika penyerang membobol frasa atau cadangan fisik tersebut, setiap kunci pribadi turunan yang berasal dari semua akun akan terekspos.

Gambar berikut mengilustrasikan bagaimana penyusupan satu root seed akan mengekspos setiap akun turunan yang berasal darinya:

Seed mnemonik root 12 atau 24 kata yang bercabang ke Kunci turunan 1, Kunci
turunan 2, dan Kunci turunan N, yang jika seed-nya disusupi, semua kunci pribadi turunan
turunan akan terekspos.

Menghapus root seed dengan penandatanganan nilai minimum

Dalam arsitektur cloud institusional zero-trust, seed mnemonik root yang dapat dibaca manusia tidak diperlukan. Multi-party Compute menghilangkan kunci pribadi root pusat sepenuhnya. Karena tidak ada kunci pribadi lengkap yang ada dalam teks biasa di satu mesin atau media cadangan, Anda tidak memerlukan pemulihan alamat satu frasa. Alih-alih memperoleh hierarki kunci dari satu rahasia, Multi-party Compute mendistribusikan bagian kunci independen di seluruh enclave yang terisolasi secara kriptografis.

Membandingkan jalur derivasi BIP32 di Multi-party Compute

Jika integrasi Anda memerlukan kompatibilitas BIP32 untuk pelacak alamat eksternal atau alur kerja akuntansi, bandingkan dua jalur implementasi teknis dalam tabel berikut.

Alur implementasi Mekanisme kriptografi Profil keamanan dan eksposur Latensi dan performa penandatanganan

BIP32 non-hardened dengan Multi-party Compute

Alur implementasi	Mekanisme kriptografi	Profil keamanan dan eksposur	Latensi dan performa penandatanganan
BIP32 non-hardened dengan Multi-party Compute	Penyesuaian aditif lokal: `s₁' = (s₁ + I_L) mod n`. Setiap node menghitung offset skalar publik (`I_L`) secara independen dan menerapkan offset tersebut ke pembagian kunci lokalnya.	Risiko kunci tunggal: di dompet non-MPC, membahayakan kunci publik induk (`xpub`) dan satu kunci pribadi turunan memungkinkan penyerang menghitung mundur kunci pribadi induk. Mitigasi MPC: kunci pribadi turunan (`k_child`) tidak disusun dalam teks biasa dan hanya ada sebagai pembagian kunci sementara yang didistribusikan (`s₁'`, `s₂'`) di dalam memori TEE yang dienkripsi hardware, sehingga mencegah pemulihan kunci turunan ke induk.	Tidak memerlukan putaran komunikasi jaringan antara node MPC untuk mendapatkan kunci turunan. Berjalan dengan kecepatan CPU lokal sebelum penandatanganan. Mendukung latensi penandatanganan di bawah satu detik (p95 kurang dari 1 detik) melalui saluran gRPC terenkripsi.
BIP32 yang Diperkuat dengan Multi-party Computation	Hash `HMAC-SHA512` multi-pihak interaktif yang dihitung berdasarkan materi kunci induk yang dibagikan secara rahasia.	Melindungi dari eskalasi kunci turunan ke induk dengan melakukan hashing pada kunci pribadi induk, yang menimbulkan kompleksitas protokol yang signifikan. Tidak memberikan manfaat keamanan tambahan di lingkungan enclave multi-pihak tempat kunci induk sudah dibagikan secara rahasia dan dilindungi dari pemindahan yang tidak sah.	Memerlukan beberapa putaran jaringan interaktif antara node MPC untuk mengevaluasi sirkuit `HMAC-SHA512` nilai minimum atas input yang dibagikan secara rahasia. Meningkatkan latensi penandatanganan dan menciptakan bottleneck pemrosesan transaksi.

Penyesuaian aditif lokal: s₁' = (s₁ + I_L) mod n.

Setiap node menghitung offset skalar publik (I_L) secara independen dan menerapkan offset tersebut ke pembagian kunci lokalnya.

Risiko kunci tunggal: di dompet non-MPC, membahayakan kunci publik induk (xpub) dan satu kunci pribadi turunan memungkinkan penyerang menghitung mundur kunci pribadi induk.
Mitigasi MPC: kunci pribadi turunan (k_child) tidak disusun dalam teks biasa dan hanya ada sebagai pembagian kunci sementara yang didistribusikan (s₁', s₂') di dalam memori TEE yang dienkripsi hardware, sehingga mencegah pemulihan kunci turunan ke induk.

Tidak memerlukan putaran komunikasi jaringan antara node MPC untuk mendapatkan kunci turunan.
Berjalan dengan kecepatan CPU lokal sebelum penandatanganan.
Mendukung latensi penandatanganan di bawah satu detik (p95 kurang dari 1 detik) melalui saluran gRPC terenkripsi.

BIP32 yang Diperkuat dengan Multi-party Computation

Hash HMAC-SHA512 multi-pihak interaktif yang dihitung berdasarkan materi kunci induk yang dibagikan secara rahasia.

Melindungi dari eskalasi kunci turunan ke induk dengan melakukan hashing pada kunci pribadi induk, yang menimbulkan kompleksitas protokol yang signifikan.
Tidak memberikan manfaat keamanan tambahan di lingkungan enclave multi-pihak tempat kunci induk sudah dibagikan secara rahasia dan dilindungi dari pemindahan yang tidak sah.

Memerlukan beberapa putaran jaringan interaktif antara node MPC untuk mengevaluasi sirkuit HMAC-SHA512 nilai minimum atas input yang dibagikan secara rahasia.
Meningkatkan latensi penandatanganan dan menciptakan bottleneck pemrosesan transaksi.

Rekomendasi untuk kustodian institusional

Multi-party Compute mendukung derivasi aditif BIP32 non-hardened untuk kompatibilitas dengan sistem yang ada dan pelacak alamat eksternal. Untuk kustodian institusional khusus, pertimbangkan untuk beralih ke kunci batas independen yang dikelola langsung di Multi-party Compute:

Menghilangkan dependensi root tunggal: membuat, merotasi, dan mencadangkan pembagian kunci independen di dalam enclave yang terisolasi, bukan memperoleh kunci sebagai offset matematika dari satu kunci root.
Meningkatkan fleksibilitas algoritma: pisahkan lapisan orkestrasi Anda dari jalur derivasi BIP32 khusus Bitcoin sehingga Anda dapat mengadopsi skema tanda tangan non-ECDSA, seperti skema tanda tangan Ed25519 untuk jaringan smart contract, di bawah satu model tata kelola.
Mengurangi kompleksitas penandatanganan: mengelola kunci nilai minimum diskret untuk menyederhanakan pencarian database, menjaga permintaan transaksi tetap ringkas, dan meminimalkan latensi penandatanganan.