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 mendapatkan kunci file langsung dari kata sandi; desain berlapis yang lebih kuat dapat menggunakan kunci buka kunci yang diturunkan dari kredensial untuk menggabungkan kunci file acak. Gudang penyimpanan kegunaan PBKDF2-HMAC-SHA512 untuk mendapatkan kunci brankas 256-bit dari pola 5x5 dan garam di 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 suara menjauhkan kunci konten teks biasa dari penjagaan sisi server rutin penyedia, sehingga kompromi penyimpanan saja atau tuntutan hukum untuk konten yang disimpan akan menghasilkan teks tersandi, bukan foto yang dapat dibaca. Penyedia masih dapat menyediakan ciphertext 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.
iCloud Photos
Apple menggunakan enkripsi dalam transit dan saat diam. Apple memegang kunci enkripsi secara default. Dengan permintaan hukum yang valid, Apple dapat memberikan data iCloud Photos. Pengecualian: Advanced Data Protection (ADP) Apple, tersedia sejak Desember 2022, menambahkan enkripsi end-to-end ke iCloud Photos. ADP harus secara eksplisit diaktifkan di Pengaturan. Ketika diaktifkan, Apple tidak dapat mengakses data iCloud Photos. 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 berasal dari pola pengguna dan garam perangkat membungkus kunci utama tersebut, sementara kunci cadangan turunan pola terpisah melindungi kunci pribadi CloudKit catatan cadangan. Vaultaire tidak mengoperasikan server konten atau menerima kunci tersebut, sehingga tidak dapat mengubah a CloudKit merekam ke dalam 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 |
|---|---|---|---|---|
| iCloud Photos (default) | Ya | Ya (kunci Apple) | Tidak | Ya |
| iCloud Photos (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 opsional terenkripsi sisi klien | Tidak ada kunci konten teks biasa; CloudKit metadata 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 suara E2EE, pelanggaran hanya penyimpanan akan menghasilkan teks tersandi dan metadata apa pun yang disimpan oleh 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, itu mungkin mencakup ciphertext, informasi akun, log akses, ukuran catatan, waktu, dan metadata berbagi daripada 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, MIME jenis, indeks, gambar mini, dan metadata brankas lainnya AES-256-GCM enkripsi yang diautentikasi. Panjang ciphertext 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 Advanced Data Protection 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 memperoleh kunci brankas lokal dari pola yang digambar pengguna dan garam 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 garam perangkat dan basis data pemulihan terenkripsi. AES-GCM operasi dan kunci simetris aktif tetap dalam proses aplikasi saat brankas terbuka.
- Pemisahan kunci penyedia berarti Wraxle tidak menerima brankas teks biasa, master, cadangan, atau kunci pemulihan. Opsional CloudKit menyimpan catatan ciphertext 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 AES-GCM database terenkripsi disimpan di iOS Keychain. Itu tidak ditulis ke file teks biasa atau dikirim ke layanan akun Vaultaire. Jika tidak ada pola yang dapat digunakan, frase pemulihan, atau perangkat yang sudah terbuka kuncinya tetap ada, 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 membutuhkan pencarian penuh AES-256 ruang kunci. Pemeriksa dapat menargetkan kata sandi atau pola yang lemah, titik akhir yang tidak terkunci, memori, frase pemulihan, penerima, cadangan, atau kelemahan implementasi. Diimplementasikan dengan benar AES-256-GCM dengan kunci entropi tinggi acak dirancang untuk menolak pencarian kunci langsung, tapi 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 efisien dengan akselerasi perangkat keras yang diekspos melalui perpustakaan kriptografi sistem. Aktif iPhone, Vaultaire tampil AES-GCM dalam proses aplikasi melalui CryptoKit. publik Apple Secure Enclave API tidak sembarangan AES-GCM mesin 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.
Gudang penyimpanan mengimplementasikan enkripsi sisi klien untuk iOS. Foto dan metadata brankas Anda dienkripsi di perangkat dengan AES-256-GCM sebelum pencadangan atau sinkronisasi opsional. Vaultaire tidak menerima kunci dekripsi atau mengoperasikan server yang dapat mengubah catatan terenkripsi tersebut menjadi foto Anda. Batasan penyedia ini tidak membuat kompromi atau tidak terkunci iPhone dapat dipercaya.