it-swarm.dev

Backup online: come possono essere compatibili la crittografia e la deduplicazione?

Un servizio di backup online "Presto per entrare in beta", Bitcasa, afferma di avere sia la deduplicazione (non esegui il backup di qualcosa già nel cloud) sia la crittografia lato client.

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

Una ricerca di brevetti non produce nulla con il nome dell'azienda, ma i brevetti potrebbero essere in cantiere e non ancora concessi.

Trovo l'affermazione piuttosto dubbia con il livello di informazioni che ho ora, qualcuno sa di più su come sostengono di raggiungerlo? Se i fondatori della società non avessero avuto un serio background commerciale (Verisign, Mastercard ...) avrei classificato il prodotto come olio di serpente immediatamente, ma forse c'è dell'altro.

Modifica: trovato un preoccupante Tweet: https://Twitter.com/#!/csoghoian/status/113753932400041984 , la chiave di crittografia per file verrebbe derivata dal suo hash, quindi sicuramente non sembra il posto dove memorizzare la tua collezione di film torrentati, non che io lo farei mai.

Edit2: In realtà l'abbiamo indovinato, hanno usato la cosiddetta crittografia convergente e quindi qualcuno che possiede lo stesso file che puoi sapere se il tuo è lo stesso, poiché hanno la chiave. Questo rende Bitcasa una pessima scelta quando i file che vuoi essere confidenziali non sono originali. http://techcrunch.com/2011/09/18/bitcasa-explains-encryption/

Edit3: https://crypto.stackexchange.com/questions/729/is-convergent-encryption-really-secure hanno la stessa domanda e risposte diverse

58
Bruno Rohée

Non ho riflettuto sui dettagli, ma se un hash sicuro del contenuto del file fosse usato come chiave, tutti i (e unici) client che "sapevano l'hash" sarebbero in grado di accedere al contenuto.

In sostanza, il cloud storage fungerebbe da tavolo Rainbow collettivo (molto scarso, in effetti) per la funzione di hashing, consentendogli di essere "invertito".

Dall'articolo: "Anche se RIAA e MPAA bussassero alle porte di Bitcasa, citando le citazioni in causa, tutto Bitcasa avrebbe una raccolta di bit crittografati senza mezzi per decrittografarli". - true perché bitcasa non contiene il mapping objectid/nomefile-a-hash/chiave; fanno solo i loro clienti (lato client). Se RIAA/MPAA conoscessero gli hash dei file in questione (ben noti, ad esempio, per specifici MP3 di brani), sarebbero in grado di decrittografare e provare che ne avevi una copia, ma prima avrebbero bisogno di sapere quale oggetto di cloud storage/il file conteneva quale canzone.

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

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

  • "compressione" - non funzionerebbe sul lato server (il contenuto crittografato non si comprimerà bene) ma potrebbe essere applicato sul lato client prima della crittografia
  • "accessibile ovunque" - se la mappatura objid-to-nomefile-e-hash/chiave è solo sul client, i file sono inutili da altri dispositivi, il che limita l'utilità dell'archiviazione cloud. Potrebbe essere risolto ad es. archiviando anche la raccolta di tuple objid-to-filename-and-hash/key, lato client crittografato con una passphrase.
  • "algoritmi di de-duplicazione brevettati" - ci deve essere più di quanto sopra per giustificare un brevetto - possibilmente de-duplicazione a livello di blocco, piuttosto che a livello di file?
  • la RIAA/MPAA sarebbe in grado di presentare una citazione e una copia criptata con hash di qualsiasi canzone/film di cui sospettano che le persone abbiano copie. Bitcasa sarebbe quindi in grado di confermare se quel file è stato archiviato o meno. Non sarebbero in grado di decrittografarlo (senza che RIAA/MPAA fornisca loro la chiave/hash) e (in particolare se non applicano le quote per utente perché offrono un "archivio infinito") potrebbero non aver conservato i log di quali utenti l'hanno caricato/scaricato. Tuttavia, sospetto che potrebbero essere tenuti a rimuovere il file (in base alle regole DMCA Safe Harbor) o eventualmente a conservare il contenuto, ma quindi registrare tutti gli account che lo caricano/scaricano in futuro.
26
Misha

L'annuncio commerciale a cui ci si collega e il sito Web dell'azienda sono 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 scommesso qualche migliaio di dollari sull'idea che la tecnologia venderà bene .

Vediamo se c'è un modo per realizzare queste promesse.

Se i dati sono crittografati sul lato client, allora deve esserci una chiave segreta Kf per quel file. Il punto è che Bitcasa non conosce Kf. Per implementare la deduplicazione e la memorizzazione nella cache e, soprattutto, la condivisione, è necessario che ogni ogni utente che crittografa un determinato file f finirà per usare lo stesso Kf. C'è un trucco ingegnoso che consiste nell'utilizzare l'hash del file stesso, con una funzione hash appropriata (diciamo, SHA-256), come Kf. Con questo trucco, lo stesso file finirà sempre nello stesso formato crittografato, che può quindi essere caricato e de-duplicato a piacimento.

Quindi un utente avrebbe un local store (sul suo computer) di tutti i Kf per tutti i suoi file, insieme a un ID file. Quando l'utente A vuole condividere il file con l'utente B, l'utente A "fa clic con il pulsante destro del mouse per ottenere l'URL di condivisione" e lo invia a B. Presumibilmente, l'URL contiene l'ID del file e Kf. Il testo afferma che entrambi gli utenti A e B devono essere utenti registrati affinché la condivisione funzioni, quindi "URL" viene probabilmente intercettato, sulla macchina di B, da un software che estrae l'ID e Kf da tale "URL", scarica il file dal server e lo decodifica localmente con la sua nuova conoscenza acquisita di Kf.

Per una maggiore resilienza e usabilità, il set di chiavi note Kf per alcuni utenti potrebbe anche essere memorizzato sui server - quindi devi solo "ricordare" un singolo KfTasto , che è possibile trasferire da un computer a un altro.

Quindi dico che ciò che Bitcasa promette è possibile, dal momento che vorrei sapere come farlo, e qui non c'è nulla di veramente nuovo o tecnologicamente avanzato. Non posso affermare che questo è ciò che fa Bitcasa , solo che è così che lo farei. La parte "difficile" sta integrando quella nei sistemi operativi esistenti (in modo che il "salvataggio di un file" inneschi il processo di crittografia/caricamento): alcuni lavori, ma difficilmente meritano un brevetto, e tanto meno 20 brevetti.

Nota che usando Kf = h (f) significa che puoi provare una ricerca esaustiva sul contenuto del file . Ciò è inevitabile comunque in un servizio con deduplicazione: "caricando" un nuovo file e semplicemente sincronizzando l'operazione, è possibile sapere se il file era già noto sul lato server o meno.

22
Thomas Pornin

Bruce Schneier ha toccato l'argomento a maggio http://www.schneier.com/blog/archives/2011/05/dropbox_securit.html relativo al problema Dropbox di quella settimana. TechRepublic offre un ottimo white paper di 7 pagine sull'argomento per il prezzo di un'iscrizione via e-mail a http://www.techrepublic.com/whitepapers/side-channels-in-cloud-services-the- caso-of-deduplicazione-in-cloud-storage/3333347 .

Il documento si concentra sul canale laterale e sugli attacchi del canale nascosto disponibili nella deduplicazione cloud. Gli attacchi sfruttano la deduplicazione tra utenti. Ad esempio, se sapessi che Bob stava usando il servizio e il suo contratto di stipendio costruito su modello era lì, puoi creare versioni dello stesso fino a quando non raggiungi il suo stipendio. Successo indicato dal tempo impiegato per il caricamento del file.

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



16
zedman9991

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 - di questi attacchi, basandosi sul richiedere al client di dimostrare di conoscere il contenuto del file (non solo il suo hash) prima che gli venga permesso di accedere al file.

  • Danny Harnik, Benny Pinkas, Alexandra Shulman-Peleg. Canali laterali nei servizi cloud, il caso della deduplicazione nello spazio di archiviazione cloud , IEEE Security & Privacy Magazine.

    Questo documento analizza tre servizi di archiviazione cloud che eseguono la deduplicazione (Dropbox, Mozy e Memopal) e sottolinea i conseguenti rischi per la sicurezza e la privacy. Propongono una nuova difesa contro questi rischi, basata sulla garanzia che un file sia de-duplicato solo se ne esistono molte copie, riducendo così la perdita di informazioni.

Questi documenti sembrano direttamente pertinenti alla tua domanda. Dimostrano anche che c'è spazio per l'innovazione su mitigazioni non banali per i rischi di ingenuo duplicazione.

9
D.W.

Crittografia e 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, può essere sicuro.

Se i dati vengono de-duplicati solo per un determinato utente, il server non sa nulla dell'equivalenza dei testi semplici e gli attacchi che rimangono sono davvero minori.

Se i dati vengono de-duplicati tra una cerchia di amici che condividono qualcosa che non è noto al fornitore di servizi (eseguibile automaticamente), solo le persone di quella cerchia di amici possono distinguere i caratteri di contesto (tramite tempistica ecc.).

Ma se i dati vengono de-duplicati tra tutti gli utenti, tutti gli ipotetici aggressori, che desiderano sapere a quali testi di accesso si accede, devono semplicemente archiviare il file nel cloud stesso e quindi monitorare quali account utente accedono agli stessi dati. Certo, il servizio può semplicemente "non registrare" gli account utente/gli indirizzi IP che accedono ai dati - ma ciò 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 questo attacco e credo che neanche Bitcasa lo faccia. Sarei felice di essere smentito però.

(Nota: ci sono sono alcuni modi per ottenere qualcosa di simile a questo - ci sono stati alcuni articoli pubblicati su archiviazione sicura su cloud usando ogni sorta di tecniche innovative - ma queste sono nuove ricerche e la maggior parte di esse sarà probabilmente rotto o mostrato in modo piuttosto rapido. Non mi fiderei ancora dei miei dati su nessuno di essi.)

6
Nakedible

La stessa domanda è stata posta allo scambio di stack di crittografia. Si prega di vedere la mia risposta lì, in quanto esiste una sottigliezza che è facile da trascurare e che è stata attentamente analizzata dal progetto open source Tahoe-LAFS: https://crypto.stackexchange.com/questions/729/is -convergent-crittografia-davvero-secure/758 # 758

5
Zooko

A parte la grande risposta che @Misha ha appena pubblicato sull'hash noto, la crittografia lato client rimuove efficacemente qualsiasi altro modo di eseguire la deduplicazione a meno che non sia presente una chiave di deposito a garanzia, che potrebbe comunque causare altri problemi logistici.

2
Rory Alsop