Backup online: in che modo la crittografia e la deduplicazione potrebbero essere compatibili?

58

Un servizio di backup online "presto per entrare in beta", Bitcasa, afferma di avere sia la deduplicazione (non si esegue il backup di qualcosa già nel cloud) che la crittografia del client.

link

Una ricerca sui brevetti non produce nulla con il nome della loro società, ma i brevetti potrebbero essere in via di definizione e non ancora concessi.

Trovo abbastanza discutibili le affermazioni con il livello di informazioni che ho ora, qualcuno sa di più su come pretendono di ottenerle? Se i fondatori della società non avessero un background aziendale serio (Verisign, Mastercard ...) avrei classificato il prodotto come olio di serpente subito ma forse c'è dell'altro.

Modifica: trovato un tweet preoccupante: link , la chiave di crittografia per file sarebbe derivata dal suo hash, quindi sicuramente non sembra il posto in cui conservare la tua collezione di film torrent, non che lo farei mai.

Modifica2: abbiamo effettivamente indovinato, hanno usato la cosiddetta crittografia convergente e quindi qualcuno che possiede lo stesso file come te può sapere se il tuo è lo stesso, dal momento che ha la chiave. Questo rende Bitcasa una scelta molto brutta quando i file che vuoi essere confidenziali non sono originali. link

Modifica3: link hanno la stessa domanda e risposte diverse

    
posta Bruno Rohée 14.09.2011 - 13:45
fonte

8 risposte

26

Non ho pensato ai dettagli, ma se un hash sicuro del contenuto del file è stato usato come chiave, allora qualsiasi (e solo) cliente che "conosceva l'hash" sarebbe stato in grado di accedere al contenuto.

Essenzialmente il cloud storage agisce come una tabella arcobaleno parziale collettiva (molto sparsa, di fatto) per la funzione di hashing, che consente di "invertirlo".

Dall'articolo: "Anche se la RIAA e la MPAA arrivassero a bussare alle porte di Bitcasa, citazioni in mano, tutto ciò che Bitcasa avrebbe sarebbe una raccolta di bit criptati senza alcun mezzo per decodificarli." - true perché bitcasa non contiene la mappatura objectid / filename-to-hash / key; solo i loro clienti (lato client). Se la RIAA / MPAA conoscesse gli hash dei file in questione (ben noti per esempio specifici brani MP3) sarebbero in grado di decifrare e dimostrare di avere una copia, ma prima avrebbero bisogno di sapere quale oggetto di archiviazione cloud / file contiene quale canzone.

I client dovrebbero conservare l'hash per ogni oggetto archiviato nel cloud e il loro nome locale, ovviamente, per poterlo accedere e decrittografarlo.

Per quanto riguarda alcune delle altre funzionalità rivendicate nell'articolo:

  • "compressione" - non funzionerebbe lato server (il contenuto crittografato non comprime bene) ma potrebbe essere applicato lato client prima della crittografia
  • "accessibile ovunque" - se l'associazione objid-to-filename-and-hash / key è solo sul client, i file sono inutili da altri dispositivi, il che limita l'utilità dell'archiviazione cloud. Potrebbe essere risolto ad es. memorizza anche la raccolta di tuple objid-to-filename-and-hash / key, lato client crittografato con una passphrase.
  • "algoritmi di de-duplicazione brevettati" - per giustificare un brevetto, ci deve essere più di quanto non accada per giustificare un brevetto - possibilmente de-duplicazione a un blocco, piuttosto che a livello di file?
  • la RIAA / MPAA sarebbe in grado di venire con un mandato di comparizione e una copia crittografata con la propria hash di qualunque canzone / film sospettano che le persone abbiano copie di. Bitcasa sarebbe quindi in grado di confermare se quel file è stato memorizzato o meno. Non sarebbero in grado di decodificarlo (senza RIAA / MPAA assegnando loro l'hash / chiave) e (in particolare se non impongono le quote per utente perché offrono una "memoria infinita") potrebbero non aver conservato i log di quali utenti l'hanno caricato / scaricato. Tuttavia, ho il sospetto che potrebbe essere richiesto di rimuovere il file (in base alle regole Safe Harbor del DMCA) o possibilmente di conservare il contenuto, ma poi di registrare qualsiasi account che lo carichi / scarichi in futuro.
risposta data 14.09.2011 - 14:31
fonte
22

Lo spot commerciale a cui ti colleghi, e il sito web aziendale, sono davvero a corto di informazioni; e sventolare "20 brevetti" come prova di competenza è strano: i brevetti non dimostrano che la tecnologia è buona , solo che ci sono alcune persone che hanno puntato qualche migliaio di dollari sull'idea che la tecnologia vendi bene .

Vediamo se c'è un modo per rendere realtà queste promesse.

Se i dati sono crittografati sul lato client, allora ci deve essere una chiave segreta K f per quel file. Il punto della questione è che Bitcasa non conosce K f . Per implementare la deduplicazione e la memorizzazione nella cache e, cosa più importante, la condivisione, è necessario che l'utente ogni che crittografa un determinato file f finisca per utilizzare lo stesso K < sub> f . C'è un trucco elegante che consiste nell'usare l'hash del file stesso, con una funzione di hash corretta (per esempio, SHA-256), come K f . Con questo trucco, lo stesso file finirà sempre nello stesso formato crittografato, che può quindi essere caricato e deduplicato a piacimento.

Quindi un utente avrebbe un negozio locale (sul suo computer) di tutti i K f per tutti i suoi file, insieme a un ID del file. Quando l'utente A desidera condividere il file con l'utente B, l'utente A "fa clic con il pulsante destro per ottenere l'URL di condivisione" e lo invia a B. Presumibilmente, l'URL contiene l'ID del file e K f . Il testo dice che entrambi gli utenti A e B devono essere utenti registrati affinché la condivisione funzioni, quindi l'URL è probabilmente intercettato, sulla macchina di B, da un software che estrae l'ID e K f da "URL", scarica il file dal server e lo decrripta localmente con la sua conoscenza appena acquisita di K f .

Per una maggiore resilienza e usabilità, l'insieme di chiavi conosciute K f per alcuni utenti potrebbe essere memorizzato anche sui server - quindi è sufficiente " ricorda "un singolo tasto K f , che potresti trasferire da un computer a un altro.

Quindi dico che ciò che Bitcasa promette è possibile, poiché vorrei sapere come farlo, e qui non c'è nulla di veramente nuovo o tecnologicamente avanzato. Non posso affermare che questo è ciò che Bitcasa , solo che è così che lo farei. La parte "difficile" sta integrando quella nei sistemi operativi esistenti (in modo che "salvare un file" attiva il processo di crittografia / upload): alcuni funzionano, ma difficilmente valgono un brevetto, figuriamoci 20 brevetti.

Si noti che l'utilizzo di K f = h (f) significa che si può provare una ricerca esauriente sul contenuto del file . Ciò è comunque inevitabile in un servizio con deduplicazione: "caricando" un nuovo file e sincronizzando l'operazione, è possibile sapere se il file era già noto lato server o meno.

    
risposta data 14.09.2011 - 14:43
fonte
16

Bruce Schneier ha toccato l'argomento nel maggio link relativo al problema Dropbox di quella settimana. TechRepublic offre un ottimo white paper di 7 pagine sull'argomento al prezzo di una e-mail iscriviti a link .

Il documento si concentra sul canale laterale e sugli attacchi di canali segreti disponibili nella deduplica del cloud. Gli attacchi sfruttano la deduplicazione tra utenti. Ad esempio, se tu sapessi che Bob stava usando il servizio e il suo contratto di stipendio basato sul modello era lassù, potresti creare versioni dello stesso fino al raggiungimento del suo stipendio. Successo indicato dal momento in cui il file è stato caricato per caricare.

Ovviamente la protezione è crittografare prima di utilizzare il servizio. Ciò tuttavia impedirà il risparmio sui costi del servizio che lo rende economicamente valido in quanto eliminerebbe quasi tutte le opportunità di deduplicazione. Quindi il servizio non incoraggerà la scelta.

risposta data 14.09.2011 - 15:19
fonte
9

Oltre alle altre buone risposte qui, vorrei indicarti i seguenti due documenti accademici, che sono stati pubblicati di recente:

  • Martin Mulazzani, Sebastian Schrittwieser, Manuel Leithner, Markus Huber e Edgar Weippl, Dark Clouds on the Horizon: utilizzo del cloud storage come vettore di attacco e spazio di gioco online , Usenix Security 2011.

    Questo documento descrive come Dropbox esegue la deduplicazione e identifica gli attacchi al meccanismo. Propongono un nuovo modo di difendersi da alcuni - ma non tutti - da questi attacchi, basandosi sul richiedere al cliente di dimostrare di conoscere il contenuto del file (non solo il suo hash) prima di poter accedere al file.

  • Danny Harnik, Benny Pinkas, Alexandra Shulman-Peleg. Canali laterali nei servizi cloud, il caso della deduplicazione nel cloud storage , IEEE Security & Rivista sulla privacy.

    Questo documento analizza tre servizi di cloud storage che eseguono la deduplicazione (Dropbox, Mozy e Memopal) e sottolinea i conseguenti rischi di sicurezza e privacy. Propongono una nuova difesa contro questi rischi, basata sulla garanzia che un file deduplicato solo se ci sono molte copie di esso, riducendo così la perdita di informazioni.

Questi articoli sembrano direttamente pertinenti alla tua domanda. Dimostrano inoltre che c'è spazio per l'innovazione su mitigazioni non banali per i rischi di deduplicazione ingenua.

    
risposta data 15.09.2011 - 05:01
fonte
6

La crittografia e la deduplicazione tra utenti arbitrari non sono compatibili se si è preoccupati di distinguere determinati testi in chiaro. Se non sei preoccupato per questi tipi di attacchi, allora può essere sicuro.

Se i dati sono solo de-duplicati per un determinato utente, il server non sa nulla sull'equivalenza dei testi in chiaro e gli attacchi che rimangono sono davvero minimi.

Se i dati sono de-duplicati tra una cerchia di amici che condivide qualcosa che non è noto al fornitore di servizi (eseguibile automaticamente), solo le persone appartenenti a quella cerchia di amici possono distinguere i testi in chiaro (tramite tempistica ecc.).

Ma se i dati sono de-duplicati tra tutti gli utenti, tutto l'ipotetico attaccante, che desidera sapere quali testi in chiaro sono accessibili, deve salvare il file nel cloud e quindi monitorare quali account utente stanno accedendo al stessi dati. Certo, il servizio può solo "non registrare" gli account utente / gli indirizzi IP che accedono ai dati - ma questo non ha nulla a che fare con la crittografia e la stessa "protezione" rimarrebbe anche se i file fossero in chiaro.

Nessuna delle altre risposte fornite qui sembra proporre qualcosa che possa fermare l'attacco questo e credo che neanche Bitcasa lo faccia. Sarei felice di essere smentito però.

(Nota: c'è sono alcuni modi per ottenere qualcosa di simile - sono stati pubblicati parecchi articoli sullo storage sicuro del cloud usando tutte le tecniche innovative - ma queste sono nuove ricerche e la maggior parte di essi sarà probabilmente rotta o mostrata non fattibile abbastanza velocemente.Non mi fiderei dei miei dati su nessuno di essi.)

    
risposta data 14.09.2011 - 23:12
fonte
5

La stessa domanda è stata posta allo scambio di stack di crittografia. Si prega di vedere la mia risposta lì, in quanto vi è una sottigliezza che è facile da trascurare e che è stata analizzata attentamente dal progetto open source Tahoe-LAFS: link

    
risposta data 23.09.2011 - 18:14
fonte
2

Oltre all'ottima risposta @Misha appena pubblicata sul "noto hash", la crittografia lato client rimuove in modo efficace qualsiasi altro modo di fare la deduplicazione, a meno che non ci sia una chiave escrow, che comunque potrebbe causare altri problemi logistici.

    
risposta data 14.09.2011 - 14:34
fonte
-1

hai totalmente ragione! L'uso della sola crittografia convergente non è una buona scelta, anche per i file non originali link Fortunatamente, sembra che esista una soluzione per combinare crittografia e deduplicazione. Si chiama ClouDedup: link

    
risposta data 16.12.2013 - 16:50
fonte

Leggi altre domande sui tag