Google Cloud Multi-party Compute menyediakan infrastruktur kepercayaan kriptografis untuk operasi aset digital institusional. Layanan ini menggunakan arsitektur multi-single-tenant: setiap instance yang Anda buat adalah lingkungan khusus yang terisolasi dengan traffic masuk jaringan, penyimpanan, dan komputasi yang terisolasi hardware untuk operasi kriptografinya sendiri.
Komponen inti
Setiap instance Multi-party Compute memiliki tiga komponen utama. Logika tata kelola, pemilihan rute permintaan, dan komputasi kriptografis berjalan di komponen terpisah.
MPC API
Multi-party Compute API mengelola resource berikut:
- Pengguna dan Tim: identitas yang memiliki peran dalam instance, dan grup Penanda Tangan yang dirujuk oleh kebijakan kunci.
- KeyRing dan KeyPolicy: KeyRing yang mengelompokkan kunci, masing-masing dengan kebijakan kunci yang menentukan Tim dan Pengguna mana yang memiliki bagian kunci dan berapa banyak dari mereka yang harus menyetujui tanda tangan.
- TransactionPolicies: aturan Cedar yang mengizinkan atau melarang transaksi, dan persetujuan Penulis Kebijakan yang mengaktifkan atau menonaktifkannya.
- KeyLists: daftar alamat bernama yang dapat dirujuk oleh kebijakan transaksi.
Multi-party Compute API melacak status setiap transaksi dan persetujuan yang dicatat di dalamnya, serta meminta Koordinator untuk mengorkestrasi pembuatan dan penandatanganan kunci. Spanner menyimpan permintaan dan persetujuan yang ditandatangani. TEE pekerja memverifikasi tanda tangan persetujuan sendiri sebelum menindaklanjutinya.
Koordinator
Multi-party Compute API menghubungkan Pengontrol ke TEE peserta:
- Penemuan pembagian kunci dan pemilihan rute permintaan: menetapkan TEE yang responsif untuk menyimpan pembagian kunci baru selama pembuatan kunci dan kemudian mengarahkan permintaan ke TEE yang sesuai.
- Health: memantau kondisi TEE peserta dan berfungsi sebagai load balancer untuk permintaan penandatanganan.
- Daya tahan: mengelola pembagian ulang saat pembagian kunci perlu diganti.
Koordinator tidak memengaruhi keamanan protokol. Koordinator tidak menyimpan pembagian kunci, dan tidak memverifikasi persetujuan atau hasil kebijakan; verifikasi tersebut terjadi di dalam TEE peserta.
TEE Worker
Setiap Worker adalah TEE yang berjalan di Confidential Space. TEE Worker menjalankan dua bagian:
- Mesin Kriptografis: menyimpan bagian kunci serta menjalankan pembuatan kunci nilai minimum yang aman dan protokol penandatanganan dengan TEE Worker lainnya.
- Policy Evaluator: mengevaluasi transaksi berdasarkan kumpulan kebijakan transaksi yang aktif.
Alur penandatanganan transaksi
Di Multi-party Compute, Anda menandatangani payload dengan satu panggilan API, CreateTransaction. Evaluasi kebijakan transaksi, persetujuan penanda tangan, dan penandatanganan nilai minimum semuanya dimulai dengan panggilan ini. Berikut adalah alur dalam urutan tetap:
- Permintaan. Penanda tangan memanggil
CreateTransactionpada kunci. Permintaan tersebut membawa persetujuan Penanda Tangan sendiri, yang ditandatangani dengan kunci otorisasi mereka. IAM memeriksa apakah pemanggil dapat memanggil metode, dan permintaan dicatat dalam Cloud Audit Logs. - Evaluasi kebijakan. Transaksi dievaluasi berdasarkan kumpulan kebijakan transaksi yang aktif. Evaluasi kebijakan menghasilkan log audit yang tahan lama untuk setiap keputusan, baik
APPROVEDmaupunREJECTED. - Persetujuan inisiator. Jika persetujuan inisiator saja sudah memenuhi nilai minimum kebijakan kunci,
CreateTransactionakan langsung melanjutkan ke Langkah 5. - Persetujuan penanda tangan. Jika persetujuan inisiator saja tidak memenuhi nilai minimum kebijakan kunci, transaksi akan memasuki status
PENDING_AUTHORIZATION. Penanda Tangan lain yang memiliki bagian kunci dari kunci tersebut menyetujui atau menolak transaksi menggunakan panggilanRecordSignerDecision, yang masing-masing ditandatangani dengan kunci otorisasi mereka. Transaksi akan menunggu dalam statusPENDING_AUTHORIZATIONhingga jumlah Penanda Tangan yang menyetujui memenuhi nilai minimum kebijakan kunci. Jika jumlah Penanda Tangan yang menolak transaksi cukup banyak sehingga nilai minimum tidak dapat lagi dipenuhi, transaksi akan dipindahkan ke statusREJECTED. Jika tidak mendapatkan cukup persetujuan sebelum waktu habis masa berlakunya, perubahan tersebut akanEXPIRED. Penandatanganan nilai minimum. Saat nilai minimum terpenuhi, Trusted Execution Environment (TEE) yang menyimpan bagian kunci akan menjalankan protokol penandatanganan nilai minimum dan menghasilkan tanda tangan pada transaksi.
Sebelum TEE peserta menggunakan pembagian kuncinya, TEE tersebut akan memeriksa apakah payload yang diminta untuk ditandatangani telah dievaluasi berdasarkan kebijakan transaksi Anda. Tidak ada klien, operator, atau komponen layanan lain yang dapat membuat peserta menandatangani payload yang tidak dievaluasi.
Untuk resource yang terlibat, seperti Pengguna, Tim, KeyRing, dan kebijakan transaksi, lihat Ringkasan Komputasi Multi-pihak.
Model keamanan
- Berbagi kunci yang disematkan ke TEE mereka. Setiap pembagian kunci hanya dapat dibaca oleh TEE yang membuatnya. Pembagian kunci tidak pernah keluar dari TEE tersebut dalam bentuk yang dapat dibaca oleh komponen lain, termasuk Koordinator, Pengontrol, atau operator Google.
- Penyimpanan kunci pelanggan. Pelanggan mempertahankan pengawasan penuh atas kunci enkripsi mereka setiap saat dengan menggunakan Cloud Key Management Service di Organisasi Google Cloud pelanggan.
- Isolasi hardware. TEE peserta berjalan di Confidential Space, yang menggunakan enkripsi memori hardware untuk melindungi data aktif dari host dan dari infrastruktur Google. Pengesahan mengikat setiap TEE ke image container yang diverifikasi.
- Enkripsi E2E. TEE Worker berkomunikasi langsung melalui gRPC yang dienkripsi end-to-end.
- Persetujuan yang ditandatangani. Penanda Tangan, Penulis Kebijakan, dan Admin menandatangani persetujuan mereka dengan kunci otorisasi yang bagian pribadinya tidak pernah keluar dari mereka. TEE peserta memverifikasi tanda tangan ini sebelum menandatangani transaksi, menerima kebijakan transaksi, atau menerima perubahan peran Admin atau Penulis Kebijakan. Hal ini membuat transaksi kebal modifikasi dan meninggalkan log audit yang tahan lama.
- Quorum Penulis Kebijakan. Kebijakan transaksi baru, atau permintaan untuk menonaktifkannya, hanya akan berlaku setelah disetujui oleh jumlah Penulis Kebijakan yang diperlukan.
- Kuorum admin. Pemberian atau penghapusan peran Admin atau Penulis Kebijakan hanya akan berlaku setelah jumlah Admin yang diperlukan menyetujuinya. Untuk mengetahui informasi selengkapnya, lihat Persetujuan admin atas perubahan peran.
Roadmap
Kemampuan berikut direncanakan untuk rilis mendatang:
- TEE Eksternal: pembagian kunci yang disimpan di TEE yang dijalankan pelanggan di luar Google Cloud, seperti AWS Nitro Enclaves.
- Pembagian kunci seluler: pembagian kunci yang disimpan di perangkat seluler Pengguna.
- Membagikan ulang: mengubah siapa yang memegang bagian dari kunci yang ada, atau mengganti bagian yang hilang, tanpa mengubah kunci.
Properti sistem
Infrastruktur kepercayaan multi-party computation mempertahankan properti sistem berikut.
Keamanan (kebenaran dalam konteks kriptografis)
Dalam keadaan apa pun, sistem tidak boleh berperilaku dengan cara yang tidak diizinkan. Misalnya, tidak ada grup yang terdiri dari kurang dari k peserta, berdasarkan protokol DKLS23, yang dapat memalsukan tanda tangan. Definisi keamanan yang tepat diformalkan dalam framework Universal Composable dalam literatur.
Saat sistem kriptografi diwujudkan dalam implementasi praktis, harus diperhatikan agar tidak mengandalkan asumsi yang merusak properti keamanan. Misalnya, setiap pihak dalam protokol harus independen: kerentanan mereka terhadap penyusupan harus independen.
Untuk memastikan properti ini, Multi-party Compute menjalankan setiap peserta dalam TEE yang diuji, dan setiap pembagian kunci disematkan ke TEE yang membuatnya. Kompromi satu peserta dalam protokol tidak memengaruhi peserta lainnya.
Literatur akademis tentang multi-party computation hampir secara eksklusif berfokus pada keandalan, dan mengasumsikan dunia yang sederhana, yaitu kumpulan pihak tidak dapat diubah, semua pihak selalu tersedia, dan para pihak berkomunikasi menggunakan saluran terautentikasi point-to-point yang ideal dan selalu tersedia. Untuk produk di dunia nyata, beberapa masalah tambahan harus diatasi.
Keaktifan
Sistem pada akhirnya akan membuat progres. Properti keaktifan yang paling biasa adalah tidak adanya deadlock, yang berlaku dalam protokol DKLS23. Kunci nilai minimum dapat digunakan untuk penandatanganan selama TEE yang menyimpan bagiannya tersedia dalam jumlah yang cukup untuk memenuhi nilai minimum kebijakan kunci. Misalnya, dengan kunci 2 dari 3, 2 dari 3 bagian mana pun dapat menyelesaikan tanda tangan.
Ketahanan
Pihak yang gagal secara permanen harus diganti, jika tidak, sistem pada akhirnya akan kehilangan rahasia bersama secara permanen. Misalnya, saat hardware gagal, status peserta yang berjalan di hardware tersebut akan hilang. Karena bagian kunci disematkan ke TEE-nya, Koordinator melacak TEE mana yang menyimpan bagian dari setiap kunci. Di v1beta, kunci tetap dapat digunakan selama jumlah pembagiannya masih cukup untuk memenuhi nilai minimum kebijakan kunci. Mengganti pembagian yang hilang memerlukan pembagian ulang, yang direncanakan untuk rilis mendatang.
Perubahan konfigurasi
Baik kegagalan hardware (TEE kehilangan data) maupun perubahan organisasi (karyawan baru bergabung ke protokol dengan bagian kunci rahasia) memerlukan perubahan pemegang bagian kunci. Multi-party Compute berencana mendukung hal ini dengan protokol berbagi ulang yang aman dan mempertahankan properti keandalan DKLS23: pihak baru yang berbahaya yang terlibat dalam berbagi ulang paling banyak membocorkan satu bagian rahasia, sama seperti pihak berbahaya lainnya.