it-swarm-eu.dev

Online zálohování: jak může být šifrování a duplikace kompatibilní?

Online zálohovací služba „brzy vstoupit do beta“, Bitcasa, prohlašuje, že má de-duplikaci (zálohu již nemáte v cloudu) a šifrování na straně klienta.

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

Patentové vyhledávání neposkytuje nic s názvem jejich společnosti, ale patenty mohou být v přípravě a dosud nebyly uděleny.

Považuji tvrzení za velmi pochybné s úrovní informací, které mám nyní, někdo ví víc o tom, jak tvrdí, že toho dosáhli? Kdyby zakladatelé společnosti neměli seriózní obchodní zázemí (Verisign, Mastercard ...), okamžitě bych klasifikoval produkt jako hadí olej, ale možná je toho víc.

Úpravy: nalezl znepokojující Tweet: https://Twitter.com/#!/csoghoian/status/113753932400041984 , šifrovací klíč na soubor by byl odvozen z jeho hash, takže určitě vypadá, jako by místo uložte svoji torrentovou filmovou sbírku, ne že bych to někdy udělal.

Edit2: Vlastně jsme to uhádli správně, používali takzvané konvergentní šifrování, takže někdo, kdo vlastní stejný soubor jako vy, může vědět, že váš je stejný, protože má klíč. Díky tomu je Bitcasa velmi špatnou volbou, pokud soubory, které chcete mít důvěrné, nejsou originální. http://techcrunch.com/2011/09/18/bitcasa-explains-encryption/

Edit3: https://crypto.stackexchange.com/questions/729/is-convergent-encryption-really-secure mají stejnou otázku a různé odpovědi

58
Bruno Rohée

Nepřemýšlel jsem o podrobnostech, ale pokud byl jako klíč použit bezpečný hash obsahu souboru, měli by k němu mít přístup všichni (a pouze) klienti, kteří „znali hash“.

V zásadě by cloudové úložiště fungovalo jako kolektivní částečná (ve skutečnosti jen velmi řídká) tabulka Rainbow pro hašovací funkci, která by umožňovala „obrácení“.

Z článku: „I kdyby se RIAA a MPAA zaklepaly na Bitcasa dveře, předvolání v ruce, vše, co by Bitcasa měla, je kolekce šifrovaných bitů, aniž by je bylo možné dešifrovat.“ - true, protože bitcasa nemá mapování objectid/filename-to-hash/key; pouze jejich klienti (na straně klienta). Kdyby RIAA/MPAA znaly hashování dotyčných souborů (dobře známé např. Pro konkrétní MP3 skladby), mohli by dešifrovat a dokázat, že máte kopii, ale nejdřív by museli vědět, který cloudový úložný objekt/soubor, který obsahoval kterou píseň.

Klienti by museli mít hash pro každý objekt uložený v cloudu a jeho místní název, aby k němu samozřejmě měli přístup a šifrovat jej.

Pokud jde o některé další funkce nárokované v článku:

  • "komprese" - nefungovalo by na straně serveru (šifrovaný obsah nebude komprimovat dobře), ale mohl by být použit na straně klienta před šifrováním
  • „přístupné kdekoli“ - pokud mapování objid-to-filename-and-hash/key je pouze na klientovi, pak jsou soubory zbytečné z jiných zařízení, což omezuje užitečnost cloudového úložiště. Mohlo by být vyřešeno např. také ukládat kolekci objid-to-filename-and-hash/key tuples, na straně klienta šifrované pomocí přístupového fráze.
  • „patentované de-duplicitní algoritmy“ - musí existovat více než výše uvedené, aby byl patent odůvodněn - možná de-duplikace na úrovni bloku, nikoli na úrovni souborů?
  • rIAA/MPAA by byla schopna přijít s předvoláním a zašifrovanou kopií hash bez ohledu na písničku/film, o kterém mají podezření, že mají kopie. Bitcasa by pak mohl potvrdit, zda byl tento soubor uložen či nikoli. Nebyli by schopni to dešifrovat (aniž by jim RIAA/MPAA poskytla hash/klíč), a (zejména pokud nevynucují kvóty na uživatele, protože nabízejí „nekonečné úložiště“), možná si nezachovali záznamy o které uživatelé nahráli/stáhli. Mám však podezření, že by mohli být požádáni o odstranění souboru (podle pravidel bezpečného přístavu DMCA) nebo případně o uchování obsahu, ale pak si protokolovat všechny účty, které jej v budoucnu nahrají/stáhnou.
26
Misha

Komerční reklama, na kterou odkazujete, a webová stránka společnosti, mají opravdu málo informací; a mávání „20 patentů“ jako důkaz způsobilosti je divné: patenty neprokazují, že tato technologie je dobrá, pouze že existují někteří lidé, kteří vsadili pár tisíc dolarů na myšlenku, že technologie bude dobře se prodávat.

Uvidíme, jestli existuje způsob, jak tyto sliby splnit.

Pokud jsou data šifrována na straně klienta, pak musí existovat tajný klíč Kf pro tento soubor. Jde o to, že Bitcasa neví Kf. Pro implementaci de-duplikace a ukládání do mezipaměti a, což je důležitější, sdílení, je nutné, aby každý uživatel šifrující daný soubor f skončil s použitím stejného = Kf. Existuje šikovný trik, který spočívá v použití hash souboru samotného, ​​se správnou hashovací funkcí (řekněme, SHA-256), jako Kf. S tímto trikem bude stejný soubor vždy skončit ve stejném šifrovaném formátu, který pak lze podle potřeby nahrát a duplikovat.

Pak by měl uživatel místní obchod (na svém počítači) všech Kf pro všechny jeho soubory spolu s ID souboru. Když uživatel A chce sdílet soubor s uživatelem B, uživatel A „klikne pravým tlačítkem, aby získal sdílenou URL“, a odešle jej B. Pravděpodobně URL obsahuje ID souboru a Kf. Text říká, že jak uživatelé A, tak B musí být registrovanými uživateli, aby sdílení fungovalo, takže „URL“ je pravděpodobně zachyceno na stroji B nějakým softwarem, který extrahuje ID a Kf z této "URL", stáhne soubor ze serveru a dešifruje jej lokálně s jeho nově získanými znalostmi Kf.

Pro určitou extra odolnost a použitelnost je sada známých klíčů Kf pro některé uživatele lze také uložit na servery - stačí si tedy pamatovat jeden Kf klíč, který byste mohli přenést z jednoho počítače do druhého.

Takže říkám, že to, co slibuje Bitcasa, je možné - protože bych věděl, jak to udělat, a zde není nic skutečně nového nebo technologicky pokročilého. Nemohu tvrdit, že to je to, co Bitcasa dělá, pouze to je to, jak bych to udělal. "Tvrdá" část je integrace, která ve stávajících operačních systémech (takže "uložení souboru" spustí proces šifrování/nahrávání): některé práce, ale sotva stojí za patent, natož 20 patentů.

Všimněte si, že pomocí Kf = h (f) znamená, že si můžete vyzkoušet důkladné vyhledávání na obsah souboru. To je stejně nevyhnutelné ve službě s duplikováním: „nahráním“ nového souboru a pouhým načasováním operace můžete vědět, zda byl soubor již na straně serveru známý nebo ne.

22
Thomas Pornin

Bruce Schneier se tohoto tématu dotkl v květnu http://www.schneier.com/blog/archives/2011/05/dropbox_securit.html související s problémem Dropboxu v tomto týdnu. TechRepublic nabízí skvělou 7stránkovou bílou knihu na toto téma za cenu registrace e-mailu na http://www.techrepublic.com/whitepapers/side-channels-in-cloud-services-the- úložiště případu deduplikace v cloudu/3333347 .

Příspěvek se zaměřuje na útoky postranních kanálů a skrytých kanálů dostupné v deduplikaci cloudu. Útoky využívají deduplikaci mezi uživateli. Například, pokud jste věděli, že Bob tuto službu využíval, a jeho platová smlouva na základě šablony byla nahoře, můžete si vyrobit její verzi, dokud nenarazíte na jeho plat. Úspěch je označen časem, který soubor trval k nahrání.

Vaše ochrana je samozřejmě před použitím služby šifrována. To však zamezí úsporám nákladů na službu, díky které je ekonomicky životaschopná, protože by to eliminovalo téměř všechny možnosti deduplikace. Služba tedy nebude podporovat výběr.



16
zedman9991

Kromě dalších dobrých odpovědí zde bych vás ráda poukazovala na následující dvě akademické práce, které byly nedávno zveřejněny:

  • Martin Mulazzani, Sebastian Schrittwieser, Manuel Leithner, Markus Huber a Edgar Weippl, Temné mraky na obzoru: Používání cloudového úložiště jako útočného vektoru a online nevyužitý prostor , Usenix Security 2011.

    Tento článek popisuje, jak Dropbox provádí duplikování a identifikuje útoky na mechanismus. Navrhují nový způsob, jak se bránit proti některým - ale ne všem - těmto útokům, a to na základě požadavku, aby klient prokázal, že zná obsah souboru (nejen jeho hash), než bude mít přístup k souboru.

  • Danny Harnik, Benny Pinkas, Alexandra Shulman-Peleg. Boční kanály v cloudových službách, případ deduplikace v cloudovém úložišti , IEEE Security & Privacy Magazine.

    Tento článek analyzuje tři služby cloudového úložiště, které provádějí duplikování (Dropbox, Mozy a Memopal), a poukazuje na následná rizika zabezpečení a soukromí. Navrhují novou obranu proti těmto rizikům, která se zakládají na zajištění toho, aby byl soubor zduplikován pouze v případě, že je jeho mnoho kopií, čímž se sníží únik informací.

Tyto dokumenty se zdají být přímo relevantní pro vaši otázku. Rovněž prokazují, že existuje prostor pro inovace v netriviální zmírnění rizika naivní de-duplikace.

9
D.W.

Šifrování a de-duplikace mezi libovolnými uživateli nejsou kompatibilní, pokud máte obavy o rozlišení určitých holých textů. Pokud vás tyto typy útoků nezajímají, může to být bezpečné.

Pokud jsou data duplikována pouze pro určitého uživatele, server neví nic o rovnocennosti prostých textů a zbývající útoky jsou opravdu malé.

Pokud jsou data duplikována mezi kruhem přátel, kteří sdílejí něco, co není poskytovateli služby známo (je možné je provádět automaticky), pouze lidé z tohoto kruhu přátel mohou rozlišovat prosté texty (načasováním atd.).

Pokud jsou však data duplikována mezi všemi uživateli, musí hypotetický útočník, který chce vědět, ke kterým prostým textům se přistupuje, potřebovat, aby soubor uložil do cloudu sám a poté sledoval, které uživatelské účty přistupují ke stejným datům. Služba samozřejmě může „nelogovat“ uživatelské účty/IP adresy, které přistupují k datům - ale to nemá nic společného s šifrováním a stejná „ochrana“ by zůstala, i kdyby soubory byly prostý text.

Zdá se, že žádná z dalších odpovědí zde nenavrhuje nic, co by zastavilo tento útok a věřím, že Bitcasa také ne. Byl bych ale rád, kdybych se ukázal špatně.

(Poznámka: Existuje jso několik způsobů, jak dosáhnout něčeho podobného - bylo publikováno poměrně málo článků o bezpečném cloudovém úložišti pomocí nejrůznějších inovativních technik - ale jedná se o nový výzkum a většina z nich bude pravděpodobně rozbitá nebo ukázaná jako neuskutečnitelná poměrně rychle. Svým datům bych dosud nevěřila.)

6
Nakedible

Stejná otázka byla položena při výměně kryptografických zásobníků. Podívejte se prosím na mou odpověď, protože existuje jemnost, kterou lze snadno přehlédnout a která byla pečlivě analyzována projektem open source Tahoe-LAFS: https://crypto.stackexchange.com/questions/729/is -convergent -ryption-opravdu-secure/758 # 758

5
Zooko

Kromě skvělé odpovědi @ Misha právě zveřejněné na „známém hašiši“ šifrování na straně klienta účinně odstraní jakýkoli jiný způsob, jak de-duplikovat, ledaže existuje klíč úschovy, který by stejně mohl způsobit další logistické problémy.

2
Rory Alsop