Infrastruktur Wallet dan Model Keamanan
Latar Belakang Industri
Sistem wallet biasanya bergantung pada satu atau lebih metode kriptografi dasar untuk melindungi private key. Memahami pendekatan ini memberikan konteks bagi model keamanan yang dijelaskan dalam dokumen ini.
Shamir's Secret Sharing (SSS)
SSS membagi private key menjadi beberapa share, yang memerlukan ambang minimum untuk merekonstruksi yang asli. SSS memberikan kerahasiaan sempurna — sejumlah share di bawah ambang tidak mengungkapkan apa pun tentang kunci. SSS matang, memiliki tooling yang baik, dan cepat (penandatanganan 20–40ms). Trade-off-nya adalah private key harus dirakit sepenuhnya untuk menandatangani, sehingga menciptakan satu titik kegagalan pada saat rekonstruksi.
Threshold Signature Schemes (TSS)
TSS (umumnya dikenal sebagai MPC) memungkinkan beberapa pihak bersama-sama menghasilkan tanda tangan tanpa pernah merakit kembali private key. Ini menghilangkan risiko rekonstruksi SSS. Trade-off-nya adalah ketidakmatangan — protokol ECDSA dua pihak yang efisien pertama baru muncul pada 2017 — dan kinerja: setiap tanda tangan melibatkan putaran jaringan, yang memperkenalkan latensi hingga beberapa detik.
Trusted Execution Environments (TEE)
TEE menjalankan operasi kriptografi di dalam hardware enclave, memastikan material kunci tidak pernah terpapar dan hanya kode yang sah yang berjalan. Klien dapat memverifikasi operasi melalui attestations. TEE mudah diskalakan dan menghindari latensi putaran jaringan TSS, tetapi keamanannya bergantung pada integritas enclave, yang secara historis rentan terhadap eksploitasi side-channel.
WebAuthn PRF Extension
WebAuthn PRF (Pseudo-Random Function) extension menurunkan rahasia deterministik dari hardware passkey pengguna — Secure Enclave pada perangkat Apple, TPM di Windows, Titan chip di Android. Rahasia ini terikat pada perangkat dan biometrik atau PIN pengguna, dihitung on-device saat autentikasi, dan tidak pernah dikirim. Ini memungkinkan kelas desain wallet di mana material kunci dapat dienkripsi dengan rahasia yang tidak pernah dilihat server mana pun.
Perlindungan Kunci Tiga Pihak
Ringkasan
Private key dalam sistem ini tidak pernah disimpan utuh — tidak di perangkat pengguna, tidak di server kami, tidak di mana pun. Sebaliknya, material kunci dibagi secara kriptografis di antara tiga pihak independen menggunakan skema 3-of-3 secret sharing. Ketiga pihak harus bekerja sama untuk merekonstruksi kunci. Kurang dari tiga mengungkapkan informasi nol secara matematis tentang private key.
Ini adalah model hibrida: menggabungkan enkripsi sisi klien berbasis passkey (PRF-as-KEK), secret sharing, dan enclave sisi server yang terisolasi menjadi satu arsitektur. Konstruksi yang dihasilkan mencapai jaminan keamanan teoretis-informasi yang sama seperti Shamir's Secret Sharing — tidak ada subset pihak di bawah ambang yang memperoleh informasi apa pun tentang kunci — sambil mengikat satu share ke hardware authenticator fisik pengguna sehingga kompromi sisi server saja tidak dapat merekonstruksi kunci.
Ini adalah model keamanan default untuk semua perangkat modern (semua browser utama di iOS, macOS, Android, dan Windows).
Ketiga Pihak
Pihak 1 — Authenticator Pengguna
Hardware passkey pengguna menghitung rahasia deterministik yang terikat pada perangkat tersebut dan biometrik atau PIN pengguna. Output ini — disebut PRF output — dihasilkan on-device saat autentikasi dan tidak pernah dikirim ke mana pun. Tidak disimpan. Tidak dicatat. Hanya ada di RAM selama operasi penandatanganan.
Rahasia ini adalah kontribusi pengguna untuk rekonstruksi kunci. Tanpanya, dua pihak lainnya tidak memiliki apa pun yang dapat menghasilkan private key yang dapat digunakan.
Pihak 2 — API
API menyimpan salinan terenkripsi dari material kunci pengguna. Data dienkripsi dengan rahasia turunan PRF pengguna, yang tidak pernah dilihat API. API mengontrol akses — hanya akan melepaskan payload terenkripsi ini ke permintaan yang menyertakan WebAuthn assertion yang valid ditandatangani oleh passkey terdaftar pengguna. Namun, API tidak dapat mendekripsi payload itu sendiri.
API bertindak sebagai mekanisme pengiriman terautentikasi, bukan penjaga kunci.
Pihak 3 — Crypto Enclave
Sistem terpisah dan terisolasi — beroperasi independen dari API dengan kunci enkripsi dan infrastrukturnya sendiri — menyimpan server-side key share. Share ini dienkripsi saat tidak digunakan dengan rahasia yang hanya diketahui enclave. Enclave hanya melepaskan share yang telah didekripsi setelah permintaan lulus validasi assertion, dan hanya untuk digabungkan dengan share pengguna pada langkah penandatanganan akhir.
Enclave tidak pernah melihat PRF output pengguna, key share pengguna, atau private key yang telah dirakit.
Properti Keamanan
Tidak Ada Titik Kegagalan Tunggal
| Skenario | Akibat |
|---|---|
| Perangkat pengguna dicuri | Penyerang tidak dapat mereproduksi biometrik/PIN; PRF output tidak dapat diperoleh |
| API sepenuhnya disusupi | Penyerang hanya mendapat ciphertext yang dienkripsi dengan rahasia yang tidak pernah mereka lihat |
| Enclave sepenuhnya disusupi | Penyerang mendapat satu share kunci; share lainnya tidak ada di sistem yang disusupi |
| API dan Enclave keduanya disusupi | Penyerang mendapat payload pengguna terenkripsi dan server share — tetapi masih tidak dapat mendekripsi payload pengguna tanpa PRF output dari authenticator fisik |
Skenario terakhir adalah yang kritis. Bahkan kompromi lengkap semua infrastruktur sisi server tidak cukup untuk merekonstruksi private key. Authenticator pengguna adalah gerbang kriptografis yang tidak dapat dilewati oleh pelanggaran sisi server.
Keamanan Teoretis-Informasi
Model hibrida mewarisi kelas jaminan keamanan yang sama seperti Shamir's Secret Sharing: pembagian kunci tidak hanya aman secara komputasi — aman secara teoretis-informasi. Penyerang dengan daya komputasi tak terbatas yang memegang material dua dari tiga pihak tidak memperoleh informasi apa pun tentang private key. Tidak ada algoritme, berapa pun waktu atau perangkat kerasnya, yang dapat menurunkan kunci hanya dari data dua pihak. Ini jaminan yang sama yang diberikan oleh one-time pad.
Non-Kustodial Secara Desain
Kami mengoperasikan API dan enclave. Meskipun demikian, kami tidak dapat mengakses dana pengguna secara sepihak. PRF output pengguna adalah bagian yang hilang — dihasilkan di dalam hardware pengguna dan tidak pernah dikirim. Ketidakmampuan kami mengakses dana bukan kebijakan atau komitmen syarat layanan. Ini adalah kendala matematis yang berlaku terlepas dari kontrol akses internal, tekanan regulasi, atau kompromi infrastruktur.
Cara Transaksi Ditandatangani
Semua penandatanganan terjadi di perangkat pengguna. Private key tidak pernah dirakit di server mana pun.
- Pengguna menyetujui transaksi di aplikasi. Perangkat mengautentikasi pengguna melalui biometrik atau PIN.
- Perangkat menghitung rahasia PRF terikat hardware secara lokal. Rahasia ini tidak meninggalkan perangkat.
- Aplikasi mengambil payload pengguna terenkripsi dari API dan server share dari enclave. Keduanya tidak dapat digunakan sendiri.
- Di perangkat pengguna, di RAM: rahasia hardware mendekripsi payload pengguna, menghasilkan key share pengguna. Kedua share digabung menjadi private key lengkap.
- Private key menandatangani transaksi — sepenuhnya on-device.
- Private key segera dihapus dari RAM. Tidak di-cache, tidak disimpan, tidak dicatat.
Private key lengkap ada selama beberapa milidetik, hanya di perangkat pengguna, dan hanya selama operasi penandatanganan. Server tidak pernah melihatnya.
Ekspor Private Key
Jika pengguna memilih mengekspor private key mereka — misalnya untuk bermigrasi ke wallet lain — prinsip yang sama berlaku. Kunci direkonstruksi dan dikirim sepenuhnya di perangkat pengguna. Server menyediakan share terenkripsi, tetapi dekripsi dan perakitan terjadi secara lokal. Pada titik mana pun selama ekspor, private key tidak melewati atau terlihat oleh server mana pun.
Sinkronisasi Passkey dan Akses Lintas Perangkat
Platform modern — iCloud Keychain di Apple, Google Password Manager di Android — menyinkronkan passkeys di seluruh perangkat pengguna. Rahasia terikat hardware yang digunakan untuk rekonstruksi kunci merupakan bagian dari material passkey yang disinkronkan, artinya PRF output yang sama dapat direproduksi di perangkat mana pun dalam grup sinkronisasi pengguna. Ini mempertahankan model keamanan tiga pihak di seluruh perangkat: perangkat yang disinkronkan mana pun dapat berpartisipasi dalam penandatanganan tanpa perubahan pada arsitektur sisi server.
Pengguna diberi tahu apakah passkey mereka telah disinkronkan ke akun cloud mereka, sehingga mereka selalu memiliki visibilitas terhadap kemampuan pemulihan wallet mereka.
Dukungan PRF tersedia di iOS 18+, macOS Sequoia 15.4+, Android 14+, dan seri YubiKey 5. Untuk platform tanpa dukungan PRF, digunakan fallback penandatanganan sisi server.
Perbandingan dengan Keamanan Wallet Konvensional
| Model | Lokasi private key | Siapa yang dapat mengakses dana |
|---|---|---|
| Self-custody standar (seed phrase) | Disimpan oleh pengguna | Siapa pun yang memiliki seed phrase |
| Kustodi exchange / hot wallet | Disimpan oleh operator | Operator (dan siapa pun yang mengkompromikan operator) |
| Hardware wallet | Disimpan di perangkat | Siapa pun dengan perangkat fisik + PIN |
| Sistem ini | Tidak pernah disimpan utuh | Memerlukan authenticator live pengguna + infrastruktur server secara bersamaan |
Ringkasan
Model hibrida ini — menggabungkan enkripsi sisi klien berbasis PRF, secret sharing, dan enclave terisolasi — mendistribusikan kepercayaan di antara tiga pihak yang benar-benar independen sehingga tidak ada subset dua pihak yang dapat merekonstruksi private key, dengan jaminan keamanan teoretis-informasi yang sama seperti Shamir's Secret Sharing. Rahasia hardware terikat biometrik pengguna adalah jangkar kriptografis seluruh sistem. Infrastruktur sisi server, seberapa pun parahnya disusupi, tidak dapat menghasilkan tanda tangan yang valid tanpa partisipasi fisik pengguna.