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. Berbeda dengan enkripsi cloud standar, di mana penyedia mengontrol kunci konten, enkripsi sisi klien dapat menyimpan kemampuan tersebut di 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 salt untuk menghasilkan kunci di 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 mungkin, namun siapa yang memegang kunci 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 masih memegang jalan 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 | Tidak melalui jalur layanan normal | Tergantung pada klien, pemulihan, dan paparan metadata | iCloud dengan Perlindungan Data Lanjutan |
| 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 | Brankas 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 buta penyedia memisahkan kedua aset tersebut: pelanggaran server masih dapat mengekspos teks tersandi dan metadata, namun tidak dapat mengekspos kunci konten teks biasa yang dimiliki penyedia. Penebakan kredensial dan penyusupan klien tetap menjadi risiko terpisah.
Paksaan Hukum adalah Ancaman Nyata
Penyedia dapat diminta untuk mengungkapkan data yang mereka simpan. Desain yang buta penyedia dapat membatasi respons tersebut pada ciphertext 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 Lanjutan di iOS 16.2 sebagai perluasan opsional enkripsi ujung ke ujung untuk data iCloud.
"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 terautentikasi, desain pemulihan yang baik, perangkat yang aman, dan implementasi yang sesuai dengan spesifikasi.
Standar NIST di Balik Kriptografi
AES-GCM distandarkan oleh National Institute of Standards and Technology (NIST) dalam SP 800-38D (2007). AES sendiri dipilih oleh NIST melalui kompetisi publik pada tahun 2001. Angka “256” dalam 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. Iterasi 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
Vaultaire 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 cara kerja implementasinya dan batas kepercayaan yang tersisa di setiap lapisan.
Derivasi kunci. Pengguna menggambar pola pada kisi 5x5 yang terdiri dari 25 titik. PBKDF2-HMAC-SHA512 menggabungkan urutan itu dengan satu salt Keychain tingkat perangkat dalam 600.000 iterasi untuk menurunkan kunci brankas 256-bit. Kunci brankas mengautentikasi indeks terenkripsi dan membungkus kunci master 256-bit acak yang terpisah. Informasi pemulihan, termasuk polanya, disimpan di basis data Keychain terenkripsi AES-GCM, bukan di file teks biasa atau akun Vaultaire.
Enkripsi file. 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 menurunkan nonce berbeda untuk setiap potongan berurutan.
Enkripsi metadata. Nama file, jenis MIME, tanggal, catatan indeks, dan data thumbnail juga dilindungi dengan AES-256-GCM. Vaultaire tidak menggunakan ChaCha20 untuk metadata brankas.
Manajemen kunci. Vaultaire menyimpan salt perangkat dan basis data pemulihan terenkripsi sebagai item kata sandi generik iOS Keychain biasa yang dilindungi kelas aksesibilitas WhenUnlockedThisDeviceOnly. Kunci brankas turunan pola dan kunci master acak diproses dalam memori aplikasi melalui CryptoKit. Penguncian menghilangkan status kunci aktif, tetapi Swift dan iOS tidak menjamin bahwa setiap salinan sementara akan ditimpa.
Penemuan brankas. Antarmuka normal tidak menampilkan daftar brankas. Format penyimpanan memakai satu direktori untuk setiap brankas. Karena itu, seseorang dengan akses ke kontainer aplikasi dapat menghitung brankas, meskipun nama direktori tidak mengungkapkan pola, nama, atau konten teks biasa. Lihat 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. Frasa 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. Jika login akun saja sudah cukup, itu menandakan jalur pemulihan yang dikontrol penyedia; frasa 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, salt, parameter derivasi, format enkripsi terautentikasi, 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. Vaultaire membuat frasa khusus 9 kata terpisah yang kunci pemulihan turunannya membuka amplop kunci brankas terenkripsi. Frasa tersebut tidak membuat ulang atau mengodekan kunci, dan pemulihan di perangkat baru juga memerlukan catatan CloudKit terenkripsi yang cocok.
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?
Kinerja AES-256-GCM tidak bergantung 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 batas kunci konten penyedia, tidak pada 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. Analisis aplikasi dan diagnostik kerusakannya diaktifkan secara default dan dapat dimatikan dengan “Bagikan kesalahan secara anonim” di Pengaturan. Kebijakan peristiwa yang terdokumentasi tidak termasuk konten brankas, pola, frasa, dan kunci dekripsi; kebijakan privasi menjelaskan aturan pengumpulan dan retensi saat ini.
Bagaimana enkripsi zero-knowledge dibandingkan dengan Perlindungan Data Lanjutan Apple?
Perlindungan Data Lanjutan (ADP) Apple, diperkenalkan pada iOS 16.2, memperluas enkripsi ujung ke ujung ke kategori iCloud tambahan dan menggunakan model pemulihan Akun Apple. Vaultaire mengenkripsi konten brankas di perangkat dan tidak memerlukan akun identitas Vaultaire; pencadangan iCloud, yang aktif secara default, serta sinkronisasi dan berbagi menggunakan catatan CloudKit yang dienkripsi di sisi klien di akun Apple pengguna. Vaultaire juga menawarkan akses brankas yang dipisahkan pola dan mode paksaan, dengan batas penyimpanan dan pemulihan yang dijelaskan dalam 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. Klaim ini lebih kuat dibandingkan enkripsi sisi server dengan kunci yang dikontrol penyedia, namun tidak 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 kuncinya, desain pemulihan, implementasi, dan tinjauan independen.