Apa Itu Enkripsi Zero-Knowledge? Panduan Sederhana
Enkripsi zero-knowledge berarti penyedia tidak dapat mengakses data Anda.
Enkripsi tanpa pengetahuan adalah arsitektur yang dibatasi oleh penyedia di mana layanan tidak memiliki kunci yang diperlukan untuk mendekripsi konten pengguna yang disimpan. Tidak seperti enkripsi cloud standar yang mana penyedia mengontrol kunci konten, enkripsi sisi klien dapat mempertahankan kemampuan tersebut pada perangkat pengguna. Permintaan hukum, pelanggaran, atau orang dalam masih dapat mengungkap teks sandi, catatan akun, data lalu lintas, atau metadata lain yang disimpan oleh penyedia. Panduan manajemen kunci NIST menjadikan penyimpanan kunci sebagai pusat akses, namun aplikasi klien, sistem operasi, dan perangkat yang tidak terkunci tetap menjadi bagian dari batas kepercayaan.
Cara Kerja Enkripsi Zero-Knowledge
Analogi paling sederhana: brankas hotel di mana hanya Anda yang mengatur kombinasinya, dan hotel tidak pernah mengetahuinya. Jika Anda lupa kombinasinya, hotel tidak dapat membuka brankas untuk Anda. Itu bukan cacat dalam desain. Itulah desainnya.
Secara teknis, enkripsi zero-knowledge bekerja melalui tiga langkah:
Derivasi kunci di perangkat. Pengguna memberikan kredensial seperti kata sandi, frasa sandi, atau pola. Fungsi derivasi kunci berbasis kata sandi menggabungkannya dengan garam untuk menghasilkan kunci pada perangkat pengguna. Desain yang terpisah dengan baik dapat menggunakan kunci tersebut untuk membuka kunci enkripsi konten acak alih-alih mengenkripsi setiap file secara langsung dengan kredensial manusia.
Enkripsi sebelum transmisi. Semua data dienkripsi di perangkat menggunakan kunci yang diturunkan sebelum meninggalkan perangkat ke penyimpanan cloud atau cadangan. Output terenkripsi (ciphertext) adalah yang diunggah.
Penyedia tidak menerima kunci konten teks biasa. Kunci konten harus ada di memori klien selama penggunaan dan juga dapat disimpan secara lokal atau jarak jauh di dalam amplop terenkripsi yang diautentikasi. Penyedia dapat menyimpan ciphertext dan kunci yang dibungkus tanpa menyimpan rahasia pengguna yang diperlukan untuk membukanya. Metadata akun, lalu lintas, ukuran data, dan waktu mungkin masih tetap terlihat.
Batasan penting: jika pengguna kehilangan semua kredensial dan jalur pemulihan yang valid, konten terenkripsi menjadi tidak dapat diakses. Pemulihan masih bisa terjadi, namun hak asuh utamanya harus dijelaskan. Jika pengaturan ulang email saja memulihkan konten yang dapat dibaca tanpa persetujuan perangkat lama, frasa pemulihan, kunci pemulihan, atau rahasia milik pengguna yang setara, penyedia telah mempertahankan rute efektif kembali ke teks biasa.
Enkripsi Zero-Knowledge vs Jenis Enkripsi Lain
Istilah "enkripsi" muncul dalam materi pemasaran hampir setiap layanan cloud. Perbedaan antara jenisnya sangat besar.
| Jenis | Siapa yang Memegang Kunci | Penyedia Dapat Membaca Data | Bertahan dari Pelanggaran Penyedia | Contoh |
|---|---|---|---|---|
| Tidak ada enkripsi | N/A | Ya | Tidak | Dropbox (tingkat standar) |
| Enkripsi dalam transit (TLS) | Penyedia | Ya (saat tersimpan di server mereka) | Tidak | Google Photos |
| Enkripsi sisi server saat tersimpan | Penyedia | Ya (mereka memegang kunci dekripsi) | Sebagian (tergantung cakupan pelanggaran) | iCloud (standar) |
| Enkripsi platform ujung ke ujung | Perangkat klien dan sistem pemulihan akun | Bukan melalui jalur pelayanan normal | Tergantung pada klien, pemulihan, dan paparan metadata | iCloud dengan Perlindungan Data Tingkat Lanjut |
| Enkripsi sisi klien yang buta penyedia | Jalur pemulihan yang dikontrol klien dan pengguna | Tidak ada kunci konten teks biasa yang dimiliki penyedia | Konten dapat tetap terenkripsi; metadata dan ciphertext mungkin masih bocor | Gudang terenkripsi dan sistem cadangan |
Perbedaan antara "enkripsi saat tersimpan" dan "enkripsi zero-knowledge" adalah yang paling sering dikacaukan. Dengan enkripsi saat tersimpan, penyedia mengenkripsi data Anda di server mereka menggunakan kunci yang mereka kendalikan. Ini melindungi dari pencurian fisik perangkat keras server. Ini tidak melindungi dari penyedia yang membaca data Anda, subpoena pemerintah untuk data dan kunci, atau ancaman orang dalam. Penyedia memiliki kemampuan dekripsi.
Dengan enkripsi sisi klien yang buta penyedia, layanan tidak diberikan kunci konten teks biasa melalui protokol yang terdokumentasi. Teks sandi yang disimpan mungkin tetap buram bagi penyedia tersebut, sementara perangkat lunak klien, jalur pemulihan, metadata akun, dan saluran pengiriman perangkat lunak masih memerlukan kepercayaan dan peninjauan.
Mengapa Enkripsi Zero-Knowledge Penting
Pelanggaran Data Mengekspos Miliaran Catatan Setiap Tahun
Pusat Sumber Daya Pencurian Identitas melaporkan 3.205 kebocoran data di Amerika Serikat pada tahun 2023, yang berdampak pada sekitar 353 juta orang. Ketika penyedia memegang kunci konten, satu pelanggaran dapat mengekspos data yang disimpan dan jalur untuk mendekripsinya. Enkripsi yang tidak diketahui penyedia memisahkan aset-aset tersebut: pelanggaran server masih dapat mengekspos teks tersandi dan metadata, namun tidak dapat mengekspos kunci konten teks biasa yang dimiliki penyedia. Tebakan kredensial dan kompromi klien tetap merupakan risiko yang terpisah.
Paksaan Hukum adalah Ancaman Nyata
Penyedia dapat diminta untuk mengungkapkan data yang mereka simpan. Desain tanpa penyedia dapat membatasi respons tersebut terhadap teks sandi dan metadata akun, lalu lintas, penagihan, atau layanan yang tersedia karena penyedia tidak memiliki kunci konten teks biasa. Apakah pihak lain dapat memperoleh kredensial pengguna, mengeksploitasi klien, atau memaksa pengungkapan adalah pertanyaan terpisah. Apple memperkenalkan Perlindungan Data Tingkat Lanjut di iOS 16.2 sebagai perluasan opsional enkripsi ujung ke ujung untuk iCloud data.
"Percayai Kami" Bukan Arsitektur Keamanan
Enkripsi sisi server bergantung pada kunci dan kebijakan yang dikontrol penyedia. Enkripsi buta penyedia mengubah penyimpanan kunci sehingga jalur layanan yang terdokumentasi tidak memiliki kunci konten teks biasa. Itu adalah batasan arsitektur yang lebih kuat, namun kekuatannya masih bergantung pada kode klien yang benar, pengiriman perangkat lunak yang diautentikasi, pemulihan suara, perangkat yang aman, dan implementasi yang sesuai dengan spesifikasi.
Standar NIST di Balik Kriptografi
AES-GCM distandarisasi oleh Institut Standar dan Teknologi Nasional di SP 800-38D (2007). AES sendiri dipilih oleh NIST melalui kompetisi publik pada tahun 2001. The "256" in AES-256 mengacu pada kunci 256-bit. Pencarian menyeluruh atas kunci acak yang seragam secara komputasi tidak mungkin dilakukan, tetapi kata sandi atau pola manusia dapat memberikan entropi yang jauh lebih sedikit bahkan ketika fungsi derivasi kunci menghasilkan output 256 bit.
GCM (Galois/Counter Mode) menambahkan enkripsi yang diautentikasi, yang berarti proses dekripsi mendeteksi perusakan apa pun pada ciphertext. Jika satu bit data terenkripsi diubah, dekripsi gagal daripada menghasilkan output yang rusak. Ini mencegah penyerang memanipulasi data terenkripsi tanpa deteksi.
PBKDF2 (Fungsi Derivasi Kunci Berbasis Kata Sandi 2), ditentukan dalam RFC 8018, mengubah kredensial yang diberikan manusia menjadi materi kunci dengan panjang tetap melalui panggilan fungsi pseudorandom berulang. Lebih banyak iterasi meningkatkan biaya setiap tebakan. Mereka tidak menambahkan entropi ke pola atau kata sandi yang dapat diprediksi, sehingga pilihan kredensial dan verifikasi offline tetap penting.
Bagaimana Vaultaire Menerapkan Pemisahan Penyedia-Kunci
Gudang penyimpanan adalah brankas terenkripsi sisi klien untuk iPhone. Dalam pengertian produk yang sering dipasarkan sebagai "tanpa pengetahuan", klaim terdokumentasi yang lebih sempit adalah bahwa Wraxle tidak menerima konten brankas teks biasa atau kunci yang diperlukan untuk mendekripsinya. Berikut adalah cara kerja implementasi dan batasan kepercayaan yang tersisa di setiap lapisan.
Derivasi kunci. Pengguna menggambar pola pada kotak 5x5 yang terdiri dari 25 titik. PBKDF2-HMAC-SHA512 menggabungkan urutan itu dengan satu perangkat di seluruh perangkat Keychain salt untuk 600.000 iterasi untuk mendapatkan kunci brankas 256-bit. Kunci brankas mengautentikasi indeks terenkripsi dan membungkus kunci master 256-bit acak yang terpisah. Informasi pemulihan, termasuk polanya, disimpan dalam AES-GCM terenkripsi Keychain database daripada file teks biasa atau akun Vaultaire.
Enkripsi berkas. Setiap file yang diimpor dienkripsi dengan AES-256-GCM di bawah kunci master acak. CryptoKit membuat kotak tersegel yang diautentikasi dengan nonce baru, dan format streaming memperoleh nonce berbeda untuk setiap potongan yang dipesan.
Enkripsi metadata. Nama file, MIME jenis, tanggal, catatan indeks, dan data thumbnail juga dilindungi dengan AES-256-GCM. Vaultaire tidak menggunakan ChaCha20 untuk metadata brankas.
Manajemen kunci. Vaultaire menyimpan garam perangkat dan basis data pemulihan terenkripsi seperti biasa iOS Keychain item kata sandi generik yang dilindungi dengan WhenUnlockedThisDeviceOnly kelas aksesibilitas. Kunci vault yang diturunkan dari pola dan kunci master acak diproses dalam memori aplikasi melalui CryptoKit. Penguncian menghilangkan status kunci aktif, tetapi Swift dan iOS tidak mendukung jaminan bahwa setiap salinan sementara akan ditimpa.
Penemuan brankas. Antarmuka normal tidak menampilkan daftar brankas. Format lokal menyimpan tepat 1 file indeks terenkripsi untuk setiap brankas, dan kode pemeliharaan dapat menghitung file tersebut. Oleh karena itu, seseorang dengan akses wadah aplikasi dapat menghitung indeks terenkripsi, meskipun nama file tidak mengungkapkan pola, nama, atau konten teks biasa. Lihat selengkapnya arsitektur keamanan dan penjelasan enkripsi pola.
Cara Mengetahui Apakah Aplikasi Menggunakan Enkripsi Zero-Knowledge yang Nyata
Mulailah dengan tiga tes cepat, lalu verifikasi arsitektur yang dipublikasikan:
Tes lupa kata sandi. Jika pengaturan ulang email saja dapat memulihkan data yang dapat dibaca, tanyakan mekanisme apa yang dimiliki penyedia untuk memulihkan kunci konten yang efektif. Frase pemulihan yang dipegang pengguna, persetujuan perangkat lama, dan pengaturan ulang yang dikontrol penyedia adalah desain yang berbeda.
Tes perangkat baru. Jika perangkat baru memulihkan konten yang dapat dibaca, identifikasi perangkat rahasia atau tepercaya yang mengizinkannya. Login akun saja menyarankan jalur pemulihan yang dikontrol penyedia; frase pemulihan ditambah catatan cadangan terenkripsi dapat menjaga pemisahan kunci penyedia.
Tes akun. Alamat email atau nomor telepon menghubungkan identitas ke metadata layanan, namun tidak dengan sendirinya membuktikan bahwa penyedia dapat mendekripsi konten. Periksa hierarki kunci, desain pemulihan, kode atau audit klien, kebijakan metadata, dan apakah teks sandi yang diautentikasi mengizinkan pemeriksaan kredensial offline.
Tes ini adalah filter, bukan bukti keamanan. Spesifikasi yang koheren harus memberi nama kunci konten, kunci pembuka kunci, garam, parameter derivasi, format enkripsi terotentikasi, aturan nonce, amplop pemulihan, penyimpanan rahasia lokal, metadata cloud, dan titik di mana kunci teks biasa berada. Tinjauan independen merupakan bukti yang lebih kuat dibandingkan label produk.
Pertanyaan yang Sering Diajukan
Apakah enkripsi zero-knowledge sama dengan enkripsi ujung ke ujung?
Keduanya tumpang tindih tetapi tidak identik. Enkripsi ujung ke ujung (E2EE) berarti data dienkripsi di perangkat pengirim dan hanya didekripsi di perangkat penerima. Enkripsi zero-knowledge berarti penyedia tidak dapat mengakses data. Sebuah layanan bisa menggunakan E2EE tanpa zero-knowledge jika penyedia membuat atau memiliki akses ke kunci pada suatu titik. Enkripsi zero-knowledge adalah standar yang lebih ketat.
Apa yang terjadi jika saya kehilangan kata sandi dengan enkripsi zero-knowledge?
Data Anda menjadi tidak dapat diakses secara permanen jika setiap kredensial dan amplop pemulihan yang valid hilang. Reset atau kunci master yang dikontrol penyedia akan melemahkan batas penyedia, sehingga pemulihan harus dirancang secara terpisah. Gudang penyimpanan menghasilkan frasa khusus yang berisi 9 kata terpisah yang kunci pemulihan turunannya membuka amplop kunci brankas terenkripsi. Frasa tersebut tidak membuat ulang atau menyandikan kunci, dan pemulihan perangkat baru juga memerlukan pencocokan terenkripsi CloudKit catatan.
Bisakah penegak hukum mengakses data terenkripsi zero-knowledge?
Penyedia mungkin harus mengungkapkan ciphertext yang disimpan dan metadata akun, lalu lintas, penagihan, atau layanan yang disimpannya. Tanpa kunci konten teks biasa yang dimiliki penyedia, penyedia tersebut tidak dapat menggunakan jalur layanan normalnya untuk mendekripsi konten. Eksploitasi perangkat, penemuan kredensial, salinan pemulihan, dan pengungkapan paksa adalah jalur terpisah yang legalitas dan efektivitasnya berbeda-beda berdasarkan yurisdiksi dan fakta.
Apakah enkripsi zero-knowledge lebih lambat dari enkripsi biasa?
AES-256-GCM kinerja tidak tergantung pada siapa yang memegang kuncinya. Derivasi berbasis kata sandi menambah pekerjaan selama pembukaan kunci, dan durasinya bergantung pada algoritme, jumlah iterasi, perangkat, dan implementasi. Aplikasi harus mengukur biaya tersebut pada perangkat keras yang didukung dan menyeimbangkan respons terhadap biaya yang dikenakan pada setiap tebakan offline.
Apakah zero-knowledge berarti aplikasi tidak mengumpulkan data sama sekali?
Belum tentu. Istilah ini membahas batasan kunci konten penyedia, tidak setiap aliran data. Aplikasi mungkin masih memproses data akun, analitik, laporan kerusakan, alamat IP, ukuran catatan, waktu, atau metadata layanan lainnya. Vaultaire tidak memerlukan akun identitas dan mengatakan bahwa analitik berbasis persetujuannya mengecualikan konten, pola, frasa, dan kunci dekripsi brankas; itu kebijakan privasi menjelaskan aturan pengumpulan dan penyimpanan saat ini.
Bagaimana enkripsi zero-knowledge dibandingkan dengan Advanced Data Protection Apple?
Perlindungan Data Tingkat Lanjut (ADP) Apple, diperkenalkan pada iOS 16.2, memperluas enkripsi ujung ke ujung ke tingkat tambahan iCloud kategori dan menggunakan model pemulihan Akun Apple. Vaultaire menyimpan konten vault secara lokal secara default dan tidak memerlukan akun identitas Vaultaire; pencadangan, sinkronisasi, dan berbagi opsional menggunakan enkripsi sisi klien CloudKit catatan di akun Apple pengguna. Vaultaire juga menawarkan akses brankas yang dipisahkan pola dan modus paksaan, dengan batas penyimpanan dan pemulihan yang dijelaskan di dalamnya dokumentasi penyangkalan yang masuk akal.
Ringkasan
Enkripsi tanpa pengetahuan paling baik diperlakukan sebagai klaim pemisahan kunci penyedia: layanan tidak memiliki kunci teks biasa yang diperlukan untuk mendekripsi konten yang disimpan. Hal ini lebih kuat dibandingkan enkripsi sisi server dengan kunci yang dikontrol oleh penyedia, namun ini bukan berarti bahwa kunci hanya ada di memori, bahwa metadata akan hilang, atau bahwa setiap klien dan perangkat yang disusupi dapat dikalahkan. Nilai produk berdasarkan hierarki utamanya, desain pemulihan, implementasi, dan tinjauan independen.