it-swarm-id.com

Cadangan online: bagaimana enkripsi dan de-duplikasi dapat kompatibel?

Layanan cadangan online "segera memasuki beta", Bitcasa, mengklaim memiliki de-duplikasi (Anda tidak membuat cadangan sesuatu yang sudah ada di cloud) dan enkripsi sisi klien.

http://techcrunch.com/2011/09/12/with-bitcasa-the-entire-cloud-is-your-hard-drive-for-only-10-per-month/

Pencarian paten tidak menghasilkan apa-apa dengan nama perusahaan mereka, tetapi paten mungkin masih dalam jalur pipa dan belum diberikan.

Saya menemukan klaim yang cukup meragukan dengan tingkat informasi yang saya miliki sekarang, ada yang tahu lebih banyak tentang bagaimana mereka mengklaim mencapai itu? Seandainya pendiri perusahaan tidak memiliki latar belakang bisnis yang serius (Verisign, Mastercard ...) Saya akan mengklasifikasikan produk tersebut sebagai minyak ular segera tetapi mungkin ada lebih dari itu.

Sunting: menemukan Tweet yang mengkhawatirkan: https://Twitter.com/#!/csoghoian/status/113753932400041984 , kunci enkripsi per file akan berasal dari hash-nya, jadi jelas terlihat seperti bukan tempat untuk simpan koleksi film Anda yang berenergi, bukan berarti saya akan melakukannya.

Sunting2: Kami benar-benar menebaknya dengan benar, mereka menggunakan apa yang disebut enkripsi konvergen dan dengan demikian seseorang yang memiliki file yang sama seperti yang Anda tahu dapat mengetahui apakah milik Anda sama, karena mereka memiliki kuncinya. Ini membuat Bitcasa pilihan yang sangat buruk ketika file yang ingin dirahasiakan tidak asli. http://techcrunch.com/2011/09/18/bitcasa-explains-encryption/

Sunting3: https://crypto.stackexchange.com/questions/729/is-convergent-encryption-really-secure memiliki pertanyaan yang sama dan jawaban yang berbeda

58
Bruno Rohée

Saya belum memikirkan detailnya, tetapi jika hash aman dari konten file digunakan sebagai kunci maka setiap (dan hanya) klien yang "tahu hash" akan dapat mengakses konten.

Pada dasarnya penyimpanan awan akan bertindak sebagai tabel pelangi parsial kolektif (sangat jarang, sebenarnya) untuk fungsi hashing, yang memungkinkannya untuk "dibalik".

Dari artikel: "Bahkan jika RIAA dan MPAA datang mengetuk pintu Bitcasa, panggilan dari pengadilan di tangan, semua Bitcasa akan memiliki koleksi bit terenkripsi tanpa sarana untuk mendekripsi mereka." - benar karena bitcasa tidak memiliki pemetaan objectid/filename-toh/key; hanya klien mereka yang melakukannya (sisi klien). Jika RIAA/MPAA mengetahui hash dari file yang dimaksud (terkenal dengan misalnya lagu MP3 tertentu) mereka akan dapat mendekripsi dan membuktikan bahwa Anda memiliki salinan, tetapi pertama-tama mereka harus tahu objek penyimpanan cloud mana/File memegang lagu yang mana.

Klien perlu menyimpan hash untuk setiap objek yang disimpan cloud, dan nama lokal mereka untuknya, tentu saja, untuk dapat mengakses dan tidak mengenkripsi itu.

Mengenai beberapa fitur lain yang diklaim dalam artikel:

  • "kompresi" - tidak akan berfungsi di sisi server (konten yang dienkripsi tidak akan kompres dengan baik) tetapi dapat diterapkan sisi klien sebelum enkripsi
  • "dapat diakses di mana saja" - jika pemetaan keberatan-ke-nama file dan hash/kunci hanya pada klien maka file tidak berguna dari perangkat lain, yang membatasi kegunaan penyimpanan cloud. Bisa diselesaikan dengan mis. juga menyimpan koleksi tuple objek-ke-nama-dan-hash/kunci, sisi klien dienkripsi dengan frasa sandi.
  • "algoritma de-duplikasi yang dipatenkan" - harus ada lebih banyak hal daripada yang dijelaskan di atas untuk membenarkan paten - mungkin de-duplikasi di blok, daripada tingkat file?
  • rIAA/MPAA akan dapat datang dengan panggilan pengadilan dan salinan hash yang dienkripsi dengan hash sendiri dari lagu/film apa pun yang mereka curigai orang miliki. Bitcasa kemudian dapat mengkonfirmasi apakah file itu telah disimpan atau belum. Mereka tidak akan dapat mendekripsi (tanpa RIAA/MPAA memberi mereka hash/kunci), dan (terutama jika mereka tidak menegakkan kuota per pengguna karena mereka menawarkan "penyimpanan tak terbatas") mereka mungkin tidak memiliki log dari pengguna mana yang mengunggah/mengunduhnya. Namun, saya menduga mereka mungkin diharuskan untuk menghapus file (di bawah aturan DMCA safe harbour) atau mungkin mempertahankan konten tetapi kemudian mencatat akun yang mengunggah/mengunduhnya di masa mendatang.
26
Misha

Iklan komersial yang Anda tautkan, dan situs web perusahaan, sangat kekurangan informasi; dan melambaikan "20 paten" sebagai bukti kompetensi itu aneh: paten tidak membuktikan bahwa teknologinya bagus , hanya saja ada beberapa orang yang mempertaruhkan beberapa ribu dolar pada gagasan bahwa teknologi akan laku .

Mari kita lihat apakah ada cara untuk mewujudkan janji-janji ini.

Jika data dienkripsi sisi klien, maka harus ada kunci rahasia Kf untuk file itu. Intinya adalah bahwa Bitcasa tidak tahu Kf. Untuk menerapkan de-duplikasi dan caching dan, yang lebih penting, berbagi, perlu bahwa setiap pengguna mengenkripsi file yang diberikan f akan berakhir dengan menggunakan yang sama Kf. Ada trik bagus yang terdiri dari menggunakan hash file itu sendiri, dengan fungsi hash yang tepat (katakanlah, SHA-256), seperti Kf. Dengan trik ini, file yang sama akan selalu berakhir dalam format terenkripsi yang sama, yang kemudian dapat diunggah dan diduplikasi sesuka hati.

Maka seorang pengguna akan memiliki lokal toko (di komputernya) dari semua Kf untuk semua file-nya, bersama dengan ID file. Ketika pengguna A ingin berbagi file dengan pengguna B, pengguna A "klik kanan untuk mendapatkan URL berbagi" dan mengirimkannya ke B. Agaknya, URL berisi ID file dan Kf. Teks mengatakan bahwa kedua pengguna A dan B harus menjadi pengguna terdaftar untuk berbagi agar berfungsi, sehingga "URL" mungkin disadap, pada mesin B, oleh beberapa perangkat lunak yang mengekstrak ID dan Kf dari "URL" itu, mengunduh file dari server, dan mendekripsi secara lokal dengan pengetahuan yang baru diperoleh tentang Kf.

Untuk beberapa ketahanan ekstra dan kegunaan, set kunci yang dikenal Kf untuk beberapa pengguna dapat disimpan di server juga - jadi Anda hanya perlu "mengingat" satu Kf, yang dapat Anda transfer dari satu komputer ke komputer lain.

Jadi saya katakan apa yang dijanjikan Bitcasa adalah mungkin - karena saya akan tahu bagaimana melakukannya, dan tidak ada yang benar-benar baru atau berteknologi maju di sini. Saya tidak dapat mengklaim bahwa inilah yang dilakukan Bitcasa , hanya itu yang saya lakukan. Bagian "sulit" mengintegrasikan hal itu dalam sistem operasi yang ada (sehingga "menyimpan file" memicu proses enkripsi/unggah): beberapa pekerjaan, tetapi hampir tidak bernilai paten, apalagi 20 paten.

Perhatikan bahwa menggunakan Kf = h (f) berarti Anda dapat mencoba pencarian lengkap pada konten file . Ini tidak dapat dihindari lagi dalam layanan dengan de-duplikasi: dengan "mengunggah" file baru dan hanya menentukan waktu operasi, Anda dapat mengetahui apakah file itu sudah diketahui sisi server atau tidak.

22
Thomas Pornin

Bruce Schneier menyentuh masalah ini pada bulan Mei http://www.schneier.com/blog/archives/2011/05/dropbox_securit.html terkait dengan masalah Dropbox minggu itu. TechRepublic menawarkan kertas putih 7 halaman yang bagus tentang masalah ini dengan harga pendaftaran email di http://www.techrepublic.com/whitepapers/side-channels-in-cloud-services-the- case-of-deduplication-in-cloud-storage/3333347 .

Makalah ini berfokus pada serangan sisi saluran dan saluran rahasia yang tersedia dalam deduplikasi cloud. Serangan meningkatkan deduplikasi pengguna silang. Misalnya, jika Anda tahu Bob menggunakan layanan ini dan kontrak gajinya yang dibuat templat ada di sana, Anda dapat membuat versi yang sama hingga Anda mendapatkan gajinya. Keberhasilan ditunjukkan oleh waktu file tersebut diunggah.

Tentu saja perlindungan Anda adalah mengenkripsi sebelum menggunakan layanan. Namun itu akan mencegah penghematan biaya untuk layanan yang membuatnya layak secara ekonomi karena akan menghilangkan hampir semua peluang deduplikasi. Dengan demikian layanan tidak akan mendorong pilihan.



16
zedman9991

Selain jawaban baik lainnya di sini, saya ingin mengarahkan Anda ke dua makalah akademis berikut, yang diterbitkan baru-baru ini:

  • Martin Mulazzani, Sebastian Schrittwieser, Manuel Leithner, Markus Huber, dan Edgar Weippl, Awan Gelap di Cakrawala: Menggunakan Penyimpanan Cloud sebagai Vektor Serangan dan Ruang Lambat Online , Keamanan Usenix 2011.

    Makalah ini menjelaskan bagaimana Dropbox melakukan de-duplikasi dan mengidentifikasi serangan pada mekanisme. Mereka mengusulkan cara baru untuk mempertahankan diri terhadap beberapa - tetapi tidak semua - serangan ini, berdasarkan pada permintaan klien untuk membuktikan bahwa mereka tahu isi file (bukan hanya hash) sebelum mereka diizinkan untuk mengakses file.

  • Danny Harnik, Benny Pinkas, Alexandra Shulman-Peleg. Saluran samping dalam layanan cloud, kasus deduplikasi dalam penyimpanan cloud , IEEE Security & Privacy Magazine.

    Makalah ini menganalisis tiga layanan penyimpanan cloud yang melakukan de-duplikasi (Dropbox, Mozy, dan Memopal), dan menunjukkan konsekuensi keamanan dan risiko privasi. Mereka mengusulkan pertahanan baru terhadap risiko-risiko ini, berdasarkan pada memastikan bahwa file diduplikasi hanya jika ada banyak salinannya, sehingga mengurangi kebocoran informasi.

Makalah ini tampaknya secara langsung relevan dengan pertanyaan Anda. Mereka juga menunjukkan bahwa ada ruang untuk inovasi pada mitigasi non-sepele untuk risiko de-duplikasi naif.

9
D.W.

Enkripsi dan de-duplikasi antara pengguna yang sewenang-wenang tidak kompatibel jika Anda khawatir tentang membedakan plaintext tertentu. Jika Anda tidak khawatir dengan jenis serangan ini, maka itu bisa aman.

Jika data hanya diduplikasi untuk pengguna tertentu, server tidak tahu apa-apa tentang kesetaraan plaintext dan serangan yang tersisa sangat kecil.

Jika data tidak terduplikasi antara lingkaran teman yang berbagi sesuatu yang tidak diketahui oleh penyedia layanan (dapat dilakukan secara otomatis), hanya orang-orang dari lingkaran teman yang dapat membedakan teks-teks plaint (melalui waktu dll.).

Tetapi jika data diduplikasi antara semua pengguna, semua penyerang hipotetis, yang ingin tahu plaintext mana yang diakses, yang perlu dilakukan adalah menyimpan file ke cloud sendiri dan kemudian memantau akun pengguna mana yang mengakses data yang sama. Tentu, layanan ini hanya dapat "tidak mencatat" akun pengguna/alamat IP yang mengakses data - tetapi itu tidak ada hubungannya dengan enkripsi pada waktu itu dan "perlindungan" yang sama akan tetap ada bahkan jika file-file itu plaintext.

Tak satu pun dari jawaban lain yang diberikan di sini tampaknya mengusulkan sesuatu yang akan menghentikan serangan ini dan saya percaya Bitcasa juga tidak. Saya akan senang terbukti salah.

(Catatan: Ada adalah beberapa cara untuk mencapai sesuatu yang dekat dengan ini - telah ada beberapa makalah yang diterbitkan tentang penyimpanan cloud yang aman menggunakan segala macam inovasi teknik - tetapi ini adalah penelitian baru dan kebanyakan dari mereka mungkin akan rusak atau ditampilkan tidak layak agak cepat. Saya belum percaya data saya pada salah satu dari mereka.)

6
Nakedible

Pertanyaan yang sama ditanyakan di pertukaran tumpukan kriptografi. Silakan lihat jawaban saya di sana, karena ada kehalusan yang mudah diabaikan dan yang telah dianalisis dengan cermat oleh proyek open source Tahoe-LAFS: https://crypto.stackexchange.com/questions/729/is -convergent-enkripsi-really-secure/758 # 758

5
Zooko

Selain jawaban hebat @Misha yang baru saja diposting di 'hash yang dikenal', enkripsi sisi klien secara efektif menghilangkan cara lain untuk melakukan de-duplikasi kecuali ada kunci escrow, yang berpotensi akan menyebabkan masalah logistik lainnya.

2
Rory Alsop