Apa itu Enkripsi End-to-End? Cara Melindungi Foto Anda
Enkripsi ujung ke ujung menjauhkan konten foto dan kunci konten teks biasa yang dapat dibaca dari penyedia penyimpanan.
Enkripsi ujung ke ujung (E2EE) adalah model keamanan di mana teks biasa dienkripsi pada satu titik akhir resmi dan didekripsi pada titik akhir lainnya. Penyedia penyimpanan atau transportasi tidak memegang kunci konten teks biasa. Batas tersebut melindungi konten dari pembacaan langsung di sisi server, namun tidak menyembunyikan setiap item metadata atau melindungi titik akhir yang disusupi, kredensial pemulihan, penerima bersama, atau pembaruan klien berbahaya.
Untuk penyimpanan foto, enkripsi ujung ke ujung berarti ponsel Anda mengenkripsi konten foto sebelum diunggah dan cloud menyimpan teks sandi, bukan gambar yang dapat dibaca. Dekripsi memerlukan kunci yang tersedia melalui perangkat resmi atau jalur pemulihan. Ukuran file, waktu, data akun, hubungan berbagi, dan metadata lainnya mungkin tetap terlihat. Panduan ini menjelaskan batasan dan membandingkan model layanan umum.
Cara Kerja Enkripsi End-to-End
Mekanisme utama melibatkan tiga tahap: pembuatan kunci, enkripsi, dan dekripsi.
Pembuatan Kunci
Perangkat pengguna menghasilkan kunci kriptografi. Dalam enkripsi simetris (seperti AES-256), kunci yang sama mengenkripsi dan mendekripsi. Dalam enkripsi asimetris (seperti RSA), kunci publik mengenkripsi dan kunci privat mendekripsi. Banyak sistem E2EE menggabungkan keduanya: enkripsi asimetris menukar kunci sesi simetris, yang kemudian menangani enkripsi massal.
Aplikasi brankas foto menggunakan beberapa desain manajemen kunci. Beberapa menurunkan kunci file langsung dari kata sandi; desain berlapis yang lebih kuat dapat menggunakan kunci buka kunci yang diturunkan dari kredensial untuk membungkus kunci file acak. Vaultaire menggunakan PBKDF2-HMAC-SHA512 untuk menurunkan kunci brankas 256-bit dari pola 5x5 dan salt yang berlaku untuk seluruh perangkat. Kunci brankas tersebut mengautentikasi indeks terenkripsi dan membuka kunci master acak terpisah yang digunakan untuk enkripsi file.
Enkripsi
Plaintext (foto Anda) diubah menjadi ciphertext menggunakan kunci enkripsi dan algoritma enkripsi. AES-256-GCM adalah cipher simetris yang paling banyak digunakan untuk tujuan ini. GCM (Galois/Counter Mode) menyediakan enkripsi terautentikasi -- ia mengenkripsi data dan menghasilkan tag autentikasi yang mendeteksi perusakan apa pun. Setiap file menerima vektor inisialisasi (IV) unik, memastikan file identik menghasilkan ciphertext yang berbeda.
Dekripsi
Perangkat penerima menggunakan kunci yang sama (simetris) atau kunci privat yang cocok (asimetris) untuk membalik transformasi. Tanpa kunci yang benar, ciphertext tidak dapat dibedakan dari data acak. Tidak ada jalan pintas matematis. AES-256 memiliki 2^256 kemungkinan kunci -- lebih dari perkiraan jumlah atom di alam semesta yang dapat diamati.
Enkripsi End-to-End vs. Model Enkripsi Lainnya
Tidak semua enkripsi adalah end-to-end. Perbedaannya menentukan siapa yang dapat mengakses data Anda.
Enkripsi dalam Transit (TLS/SSL)
Data dienkripsi antara perangkat Anda dan server. Server mendekripsinya setelah diterima. Ini melindungi terhadap penyadapan selama transmisi tetapi membiarkan data dapat dibaca di server. Setiap layanan cloud besar menggunakan enkripsi dalam transit. Ini adalah baseline, bukan standar.
Enkripsi Saat Diam (Sisi Server)
Server mengenkripsi data yang disimpan menggunakan kunci yang dikelola server. Ini melindungi terhadap pencurian fisik perangkat keras server tetapi tidak terhadap penyedia layanan itu sendiri, karyawannya, atau permintaan hukum yang diarahkan ke penyedia. iCloud, Google Drive, dan Dropbox semua menggunakan enkripsi sisi server saat diam. Penyedia memegang kunci.
Enkripsi End-to-End
Data dienkripsi pada titik akhir resmi sebelum penyedia penyimpanan menerimanya. Desain yang baik menjauhkan kunci konten teks biasa dari penyimpanan rutin di sisi server penyedia, sehingga kompromi penyimpanan saja atau tuntutan hukum untuk konten yang disimpan akan menghasilkan teks tersandi, bukan foto yang dapat dibaca. Penyedia masih dapat menyerahkan teks tersandi dan metadata, mendistribusikan perangkat lunak klien, atau mengoperasikan sistem pemulihan dan berbagi yang harus disertakan dalam model ancaman.
| Model Enkripsi | Siapa yang Memegang Kunci | Penyedia Dapat Membaca Data? | Melindungi dari Penyedia? |
|---|---|---|---|
| Hanya dalam transit (TLS) | Server | Ya | Tidak |
| Saat diam (sisi server) | Server | Ya | Tidak |
| End-to-end | Titik akhir resmi atau pemegang pemulihan | Bukan dari ciphertext yang disimpan saja | Melindungi konten dari kunci penyimpanan yang dimiliki penyedia |
| Enkripsi sisi klien yang buta penyedia | Jalur pemulihan klien dan terdokumentasi | Tidak ada akses konten teks biasa berdasarkan desain | Melindungi konten; metadata dan kepercayaan klien tetap ada |
Cara Layanan Penyimpanan Foto Menangani Enkripsi
Model enkripsi bervariasi secara signifikan di seluruh layanan penyimpanan foto. Beberapa mengiklankan "enkripsi" tanpa menentukan modelnya, yang dapat menyesatkan pengguna untuk percaya foto mereka adalah E2EE padahal tidak.
Foto iCloud
Apple menggunakan enkripsi dalam transit dan saat diam. Apple memegang kunci enkripsi secara default. Dengan permintaan hukum yang valid, Apple dapat memberikan data Foto iCloud. Pengecualian: Perlindungan Data Lanjutan (ADP) Apple, tersedia sejak Desember 2022, menambahkan enkripsi end-to-end ke Foto iCloud. ADP harus secara eksplisit diaktifkan di Pengaturan. Ketika diaktifkan, Apple tidak dapat mengakses data Foto iCloud. Sebagian besar pengguna belum mengaktifkan ADP.
Google Photos
Google menggunakan enkripsi dalam transit dan saat diam dengan kunci sisi server. Google memegang kunci enkripsi untuk semua data Google Photos, termasuk konten Folder Terkunci. Google dapat mematuhi permintaan data hukum. Google tidak menawarkan opsi enkripsi end-to-end untuk Google Photos.
Dropbox
Enkripsi dalam transit (TLS 1.2+) dan saat diam (AES-256 dengan kunci yang dikelola Dropbox). Dropbox memegang kunci dan dapat mengakses file Anda. Dropbox Vault (fitur berbayar) menambahkan perlindungan PIN tetapi bukan enkripsi end-to-end.
OneDrive
Microsoft menggunakan enkripsi dalam transit dan saat diam dengan kunci yang dikelola Microsoft. OneDrive Personal Vault menambahkan verifikasi identitas (2FA) tetapi bukan enkripsi end-to-end -- Microsoft masih dapat mengakses data.
Vaultaire
Enkripsi sisi klien dengan kunci yang disimpan penyedia dikecualikan. Vaultaire mengenkripsi foto dan metadata di perangkat dengan AES-256-GCM sebelum unggahan cloud apa pun. Kunci master acak mengenkripsi data brankas. Kunci brankas lokal yang diturunkan dari pola pengguna dan salt perangkat membungkus kunci master tersebut, sementara kunci cadangan terpisah yang diturunkan dari pola melindungi catatan cadangan CloudKit pribadi. Vaultaire tidak mengoperasikan server konten dan tidak menerima kunci tersebut, sehingga tidak dapat mengubah catatan CloudKit menjadi teks biasa. Aplikasi, iOS, dan perangkat yang tidak terkunci tetap berada dalam batas kepercayaan, dan permintaan hukum masih dapat memperoleh metadata akun atau layanan yang disimpan oleh penyedia terkait.
| Layanan | Enkripsi dalam Transit | Enkripsi Saat Diam | Enkripsi End-to-End | Penyedia Dapat Mengakses |
|---|---|---|---|---|
| Foto iCloud (default) | Ya | Ya (kunci Apple) | Tidak | Ya |
| Foto iCloud (ADP diaktifkan) | Ya | Ya | Ya | Tidak |
| Google Photos | Ya | Ya (kunci Google) | Tidak | Ya |
| Dropbox | Ya | Ya (kunci Dropbox) | Tidak | Ya |
| OneDrive | Ya | Ya (kunci Microsoft) | Tidak | Ya |
| Vaultaire | Ya | Ya | Cadangan terenkripsi sisi klien, aktif secara default | Tidak ada kunci konten teks biasa; metadata CloudKit tetap ada |
Mengapa Enkripsi End-to-End Penting untuk Foto
Foto adalah data yang sangat sensitif. Foto mengandung wajah, lokasi (metadata GPS), stempel waktu, dan catatan visual momen pribadi. Pelanggaran perpustakaan foto Anda mengekspos lebih banyak informasi pribadi daripada hampir semua jenis data lainnya.
Pelanggaran Data
Saat penyedia layanan menyimpan foto dengan kunci sisi server, kompromi pada penyimpanan dan jalur manajemen kuncinya dapat mengekspos konten yang dapat dibaca. Dengan E2EE yang baik, pembobolan yang hanya mengenai penyimpanan menghasilkan teks tersandi dan metadata apa pun yang disimpan layanan. Kompromi titik akhir, kredensial pemulihan yang dicuri, perangkat lunak klien berbahaya, dan kelemahan layanan kunci tetap menjadi jalur terpisah menuju teks biasa.
Akses Hukum dan Pemerintah
Penyedia layanan dapat diminta untuk memberikan catatan yang mereka miliki. Dengan E2EE, catatan itu dapat mencakup teks tersandi, informasi akun, log akses, ukuran catatan, waktu, dan metadata berbagi, bukan konten foto yang dapat dibaca. Apakah suatu permintaan dapat menjangkau perangkat, metode pemulihan, penerima, atau perilaku klien di masa depan adalah pertanyaan hukum dan teknis yang berbeda.
Akses Internal
Karyawan atau penyerang yang memiliki akses ke kunci penyimpanan yang dikelola penyedia mungkin dapat menjangkau konten terenkripsi sisi server. E2EE menghapus jalur kunci penyimpanan langsung tersebut ketika penyedia tidak memiliki kunci konten teks biasa. Hal ini tidak membuat penyalahgunaan orang dalam menjadi mustahil karena penyedia dapat mengontrol distribusi klien, status akun, metadata, pembagian, atau komponen pemulihan.
Perlindungan Metadata
Beberapa implementasi E2EE hanya mengenkripsi konten file, sehingga metadata seperti nama file dan tanggal tidak terlindungi. Vaultaire melindungi header file, jenis MIME, indeks, gambar mini, dan metadata brankas lainnya dengan enkripsi terautentikasi AES-256-GCM. Panjang teks tersandi yang disimpan dan jumlah file indeks terenkripsi masih dapat memaparkan informasi struktural kepada seseorang yang memiliki akses kontainer aplikasi.
Kesalahpahaman Umum tentang E2EE
"Penyimpanan cloud saya terenkripsi, jadi foto saya aman." Enkripsi sisi server melindungi terhadap pelanggaran eksternal perangkat keras server. Ini tidak melindungi terhadap penyedia itu sendiri, permintaan hukum, atau ancaman orang dalam. Penyedia memegang kunci.
"HTTPS berarti foto saya dienkripsi end-to-end." HTTPS (TLS) mengenkripsi data dalam transit antara perangkat Anda dan server. Setelah data tiba di server, ia didekripsi. HTTPS adalah enkripsi saluran, bukan enkripsi data.
"Enkripsi end-to-end berarti tidak ada yang pernah bisa melihat foto saya." E2EE berarti tidak ada yang tanpa kunci yang dapat melihat foto Anda. Jika seseorang memiliki kata sandi atau kunci Anda, mereka dapat mendekripsi data. Manajemen kunci dan kata sandi yang kuat tetap penting.
"Apple/Google tidak dapat melihat foto saya." Secara default, kedua perusahaan memegang kunci enkripsi untuk foto yang disimpan di cloud Anda. Apple menawarkan Perlindungan Data Lanjutan sebagai opt-in. Google tidak menawarkan opsi E2EE untuk Google Photos sama sekali.
Cara Vaultaire Mengimplementasikan Enkripsi End-to-End
Vaultaire menggunakan pendekatan E2EE berlapis:
- AES-256-GCM mengenkripsi semua konten file. Setiap file mendapatkan vektor inisialisasi unik. Enkripsi terautentikasi mendeteksi perusakan.
- PBKDF2 dengan HMAC-SHA512 menurunkan kunci brankas lokal dari pola yang digambar pengguna dan salt perangkat. Faktor kerja meningkatkan biaya setiap tebakan offline tanpa menambahkan entropi pada polanya. Kunci brankas tersebut mengautentikasi indeks terenkripsi dan membuka kunci master acak yang digunakan pada data file.
- AES-256-GCM untuk metadata melindungi nama file, tanggal, dimensi, indeks, dan thumbnail di bawah enkripsi yang diautentikasi.
- iOS Keychain dan Perlindungan Data melindungi salt perangkat dan basis data pemulihan terenkripsi. Operasi AES-GCM dan kunci simetris aktif tetap berada dalam proses aplikasi saat brankas terbuka.
- Pemisahan kunci penyedia berarti Wraxle tidak menerima kunci brankas, kunci master, kunci cadangan, atau kunci pemulihan dalam bentuk teks biasa. Cadangan CloudKit (aktif secara default), sinkronisasi, dan berbagi menyimpan catatan teks tersandi dan amplop kunci terenkripsi, sementara Apple masih dapat mengamati metadata layanan. Vaultaire tidak memerlukan akun identitas Vaultaire.
Vaultaire menyimpan informasi pemulihan, termasuk polanya, di dalam basis data terenkripsi AES-GCM yang disimpan di iOS Keychain. Informasi ini tidak ditulis ke file teks biasa atau dikirim ke layanan akun Vaultaire. Jika tidak ada pola yang dapat digunakan, frasa pemulihan, atau perangkat yang sudah terbuka yang tersisa, Vaultaire tidak memiliki kunci pemulihan penyedia yang dapat memulihkan akses.
Pertanyaan yang Sering Diajukan
Apakah enkripsi end-to-end legal?
Perlakuan hukum terhadap enkripsi, akses paksa, dan layanan terenkripsi bervariasi menurut yurisdiksi dan dapat berubah. Panduan ini menjelaskan model teknis, bukan nasihat hukum. Periksa undang-undang setempat saat ini jika penggunaan Anda melibatkan penggeledahan perbatasan, perintah pengadilan, pencatatan yang diatur, atau lingkungan berisiko tinggi lainnya.
Bisakah penegak hukum memecahkan enkripsi end-to-end?
Serangan jarang perlu mencari di seluruh ruang kunci AES-256. Pemeriksa dapat menargetkan kata sandi atau pola yang lemah, titik akhir yang tidak terkunci, memori, frasa pemulihan, penerima, cadangan, atau kelemahan implementasi. AES-256-GCM yang diimplementasikan dengan benar dengan kunci acak berentropi tinggi dirancang untuk menahan pencarian kunci langsung, tetapi itu hanya satu bagian dari sistem.
Apa perbedaan antara E2EE dan enkripsi zero-knowledge?
E2EE menjelaskan di mana enkripsi dan dekripsi teks biasa terjadi dan siapa yang memegang kunci konten yang dapat digunakan. "Zero-knowledge" sering digunakan dalam pemasaran produk untuk enkripsi tanpa penyedia layanan, namun tidak boleh dibaca secara harfiah: suatu layanan mungkin tidak memiliki kunci teks biasa namun tetap melihat teks sandi, data akun, ukuran, waktu, hubungan berbagi, dan metadata lainnya. Evaluasi kunci dan jalur pemulihan yang terdokumentasi, bukan hanya labelnya saja.
Apakah enkripsi end-to-end memperlambat ponsel saya?
Perangkat modern menangani AES-256 secara efisien dengan akselerasi perangkat keras yang tersedia melalui pustaka kriptografi sistem. Di iPhone, Vaultaire menjalankan AES-GCM di dalam proses aplikasi melalui CryptoKit. API Secure Enclave publik dari Apple bukan mesin AES-GCM serbaguna untuk enkripsi file. Overhead enkripsi dan dekripsi bergantung pada ukuran file dan perangkat, namun dirancang agar tidak mengganggu selama penggunaan normal.
Apa yang terjadi jika saya kehilangan kunci enkripsi?
Kehilangan setiap jalur dekripsi dan pemulihan yang dapat digunakan membuat data terenkripsi tidak dapat dipulihkan. Oleh karena itu, banyak sistem E2EE menggunakan frasa pemulihan, perangkat tepercaya, kontak pemulihan, kit darurat, atau amplop kunci terenkripsi. Mekanisme tersebut mempertahankan akses, namun masing-masing juga menjadi bagian dari model keamanan.
Kesimpulan
Enkripsi ujung ke ujung dapat menghapus jalur kunci teks biasa penyedia penyimpanan ketika enkripsi terjadi pada titik akhir resmi sebelum pengunggahan. Itu adalah perlindungan yang berarti, bukan jaminan terhadap keseluruhan sistem. Periksa penyimpanan kunci konten, pemulihan, metadata, pembaruan klien, keamanan titik akhir, dan berbagi sebelum memercayai layanan dengan foto pribadi.
Vaultaire mengimplementasikan enkripsi sisi klien untuk iOS. Foto dan metadata brankas Anda dienkripsi di perangkat dengan AES-256-GCM sebelum pencadangan (aktif secara default) atau sinkronisasi. Vaultaire tidak menerima kunci dekripsi atau mengoperasikan server yang dapat mengubah catatan terenkripsi tersebut menjadi foto Anda. Batas penyedia ini tidak membuat iPhone yang disusupi atau sedang terbuka menjadi dapat dipercaya.