Domanda:
Backup online: come potrebbero essere compatibili la crittografia e la deduplicazione?
Bruno Rohée
2011-09-14 16:45:37 UTC
view on stackexchange narkive permalink

Un servizio di backup online "presto in fase di beta", Bitcasa, afferma di avere sia la deduplicazione (non si esegue 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 della loro 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, chiunque lo sa di più su come affermano di ottenerlo? Se i fondatori dell'azienda non avessero avuto un background professionale serio (Verisign, Mastercard ...) avrei classificato subito il prodotto come olio di serpente, ma forse c'è dell'altro.

Modifica: trovato un tweet preoccupante: https://twitter.com/#!/csoghoian/status/113753932400041984, la chiave di crittografia per file sarebbe derivata dal suo hash, quindi sicuramente non sembra il posto dove archiviare il tuo film torrentizzato raccolta, non che lo farei mai.

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

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

Mi chiedo se questa funzione di deduplicazione possa essere utilizzata per identificare le persone che hanno caricato gli stessi dati? Penso che sarebbe un problema di privacy.
@MToecker: In questo caso, lo scopo della crittografia è strettamente quello di nascondere i dati. Non ha lo scopo di fornire privacy. (Questo deve essere chiarito agli utenti, ovviamente!)
Potresti chiedere agli sviluppatori di [Conformal Systems] (https://opensource.conformal.com/) del loro progetto [Cyphertite] (https://www.cyphertite.com/)?
Otto risposte:
#1
+26
Misha
2011-09-14 17:31:58 UTC
view on stackexchange narkive permalink

Non ho esaminato i dettagli, ma se come chiave fosse stato utilizzato un hash sicuro del contenuto del file, qualsiasi (e solo) client che "conosceva l'hash" sarebbe in grado di accedere al contenuto.

Essenzialmente il cloud storage agirebbe come una tabella arcobaleno parziale collettiva (molto scarna, in effetti) per la funzione di hashing, consentendo di "invertire".

Dall'articolo: "Anche se la RIAA e l'MPAA sono venute a bussare alle porte di Bitcasa, citando in giudizio in mano, tutto ciò che Bitcasa avrebbe avuto è una raccolta di bit crittografati senza alcun mezzo per decrittografarli. " - vero perché bitcasa non detiene la mappatura objectid / filename-to-hash / key; solo i loro clienti lo fanno (lato client). Se la RIAA / MPAA conoscesse gli hash dei file in questione (ben noti ad esempio per specifici MP3 di brani) sarebbero in grado di decrittografare e dimostrare che hai una copia, ma prima dovrebbero sapere quale oggetto di archiviazione cloud / file conteneva quale canzone.

I clienti avrebbero bisogno di mantenere l'hash per ogni oggetto archiviato nel cloud e il loro nome locale, ovviamente, per essere in grado di accedervi e decrittografarlo.

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

  • "compressione" - non funzionerebbe lato server (il contenuto crittografato non si comprimerà bene) ma potrebbe essere applicata client- lato prima della crittografia
  • "accessibile ovunque" - se la mappatura objid-nome-file-e-hash / chiave è solo sul client, i file sono inutili da altri dispositivi, il che limita l'utilità del cloud Conservazione. Potrebbe essere risolto ad es. memorizza anche la raccolta di tuple objid-nome-file-e-hash / chiave, crittografate sul lato client con una passphrase.
  • "algoritmi di deduplicazione brevettati": deve esserci qualcosa di più del sopra per giustificare un brevetto - possibilmente deduplicazione a livello di blocco, piuttosto che a livello di file?
  • la RIAA / MPAA sarebbe in grado di fornire una citazione e una copia crittografata con il suo hash di qualunque canzone / film di cui sospettano le persone abbiano copie. Bitcasa sarebbe quindi in grado di confermare se quel file è stato memorizzato o meno. Non sarebbero in grado di decrittografarlo (senza RIAA / MPAA che fornisse loro l'hash / chiave) e (in particolare se non applicano quote per utente perché offrono "spazio di archiviazione infinito") potrebbero non aver conservato i log di quali utenti lo hanno caricato / scaricato. Tuttavia, sospetto che potrebbe essere richiesto loro di rimuovere il file (in base alle regole dell'approdo sicuro DMCA) o eventualmente di conservare il contenuto, ma quindi di registrare gli account che lo caricano / scaricano in futuro.
Sembra che sarebbe facile schivare l'hash noto della RIAA di un MP3 semplicemente impostando un tag ID3 su una lunga stringa casuale. Alcune modifiche non operative simili ai file del filmato ostacolerebbero gli sforzi dell'MPAA.
È improbabile che la deduplicazione avvenga a livello di file, piuttosto su blocchi di una dimensione selezionata. Quindi l'hashing e la deduplicazione non sarebbero probabilmente possibili per ottenere informazioni molto utili su file specifici.
#2
+22
Thomas Pornin
2011-09-14 17:43:50 UTC
view on stackexchange narkive permalink

L'annuncio commerciale a cui ti colleghi e il sito web dell'azienda 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 scommesso qualche migliaio di dollari sull'idea che la tecnologia vendi bene .

Vediamo se esiste un modo per realizzare queste promesse.

Se i dati sono crittografati 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 utente che crittografa un dato file f finisca per utilizzare lo stesso K f . C'è un trucco ingegnoso che consiste nell'usare l'hash del file stesso, con un'apposita funzione hash (diciamo, SHA-256), come Kf . 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 locale memorizzare (sul suo computer) 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 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 qualche software che estrae l'ID e K f sub> da quell'URL, scarica il file dal server e lo decrittografa localmente con la sua nuova conoscenza di Kf .

Per una maggiore resilienza e usabilità, anche il set di chiavi note Kf per alcuni utenti potrebbe essere memorizzato sui server, quindi è sufficiente " ricorda "una singola chiave Kf , che potresti trasferire da un computer a un altro.

Quindi dico che ciò che Bitcasa promette è possibile - poiché io saprei come farlo, e non c'è niente di veramente nuovo o tecnologicamente avanzato qui. Non posso affermare che questo sia ciò che fa Bitcasa, solo che è così che lo farei. La parte "difficile" è integrarla nei sistemi operativi esistenti (in modo che il "salvataggio di un file" inneschi il processo di crittografia / caricamento): alcuni funzionano, ma difficilmente valgono un brevetto, figuriamoci 20 brevetti.

Nota che usare K f = h (f) significa che puoi provare una ricerca esaustiva nel contenuto del file . Ciò è comunque inevitabile in un servizio con deduplicazione: "caricando" un nuovo file e solo temporizzando l'operazione, puoi sapere se il file era già noto lato server oppure no.

TechCrunch non è l'apice del reporting equo ed etico ;-)
Se la tecnologia funzionasse come hai descritto, significherebbe che se il tuo disco rigido si bloccasse non saresti in grado di recuperare i tuoi file dal cloud, poiché gli originali (e probabilmente anche le chiavi) sarebbero andati persi? Se questo è il caso renderebbe il servizio inutile come backup, corretto?
@Joshua: bene, con la crittografia devi sempre iniziare da _qualcosa_. Se i server memorizzassero tutto in modo tale che i tuoi dati potessero essere recuperati anche se non ricordassi nulla, il sistema non sarebbe protetto contro i server stessi. Quello che si potrebbe fare è memorizzare tutto il _Kf_ in un file, e poi semplicemente "ricordare" il _Kf_ per quel file - possibilmente, crittografarlo con una password, o scriverlo su un foglio che conservi in ​​una cassaforte. Con la crittografia puoi iniziare con una singola piccola chiave, che può essere archiviata con strumenti a bassa tecnologia.
#3
+16
zedman9991
2011-09-14 18:19:03 UTC
view on stackexchange narkive permalink

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 fantastico white paper di 7 pagine sull'argomento al prezzo di un'iscrizione tramite posta elettronica all'indirizzo http://www.techrepublic.com/whitepapers/side-channels-in-cloud-services-the-case -di-deduplicazione-in-cloud-storage / 3333347.

Il documento si concentra sugli attacchi del canale laterale e del canale nascosto disponibili nella deduplicazione cloud. Gli attacchi sfruttano la deduplicazione tra utenti. Ad esempio, se sapevi che Bob stava utilizzando il servizio e il suo contratto di stipendio creato da un modello era lì, potresti creare versioni dello stesso finché non raggiungi il suo stipendio. Il successo indicato dal tempo impiegato dal file per il caricamento.

Ovviamente la tua protezione consiste nel crittografare prima di utilizzare il servizio. Ciò tuttavia eviterà i risparmi sui costi per il servizio che lo rendono economicamente redditizio poiché eliminerebbe quasi tutte le opportunità di deduplicazione. Quindi il servizio non incoraggerà la scelta.



#4
+9
D.W.
2011-09-15 08:01:51 UTC
view on stackexchange narkive permalink

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

  • Martin Mulazzani, Sebastian Schrittwieser, Manuel Leithner, Markus Huber e Edgar Weippl, Dark Clouds on the Horizon: Using Cloud Storage as Attack Vector and Online Slack Space, Usenix Security 2011.

    Questo documento descrive come Dropbox esegue la deduplicazione e identifica gli attacchi al meccanismo. Propongono un nuovo modo per difendersi da alcuni - ma non tutti - di questi attacchi, basato sulla richiesta al client di dimostrare di conoscere il contenuto del file (non solo il suo hash) prima che gli sia consentito di accedere al file.

  • Danny Harnik, Benny Pinkas, Alexandra Shulman-Peleg. Canali laterali nei servizi cloud, il caso della deduplicazione nell'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 venga deduplicato solo se ce ne sono molte copie, riducendo così la fuga di informazioni.

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

#5
+6
Nakedible
2011-09-15 02:12:09 UTC
view on stackexchange narkive permalink

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 vengono deduplicati solo per un determinato utente, il server non sa nulla dell'equivalenza dei testi in chiaro e gli attacchi che rimangono sono davvero minori.

Se i dati vengono deduplicati tra una cerchia di amici che condividono qualcosa che non è noto al fornitore di servizi (fattibile automaticamente), solo le persone di quella cerchia di gli amici possono distinguere i testi in chiaro (tramite temporizzazione ecc.).

Ma se i dati vengono deduplicati tra tutti gli utenti, tutto l'ipotetico aggressore, che desidera sapere a quali testi in chiaro si accede, deve il file nel cloud stesso e quindi monitorare quali account utente stanno accedendo agli stessi dati. Certo, il servizio può semplicemente "non registrare" gli account utente / 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 questo attacco e credo che neanche Bitcasa lo faccia. Tuttavia, sarei lieto di essere smentito.

(Nota: ci sono alcuni modi per ottenere qualcosa di simile a questo - sono stati pubblicati diversi articoli sul cloud sicuro archiviazione utilizzando tutti i tipi di tecniche innovative, ma si tratta di nuove ricerche e la maggior parte di esse sarà probabilmente interrotta o mostrata non fattibile piuttosto velocemente. Non mi fiderei ancora dei miei dati su nessuna di esse.)

A questo posso solo aggiungere che MPAA e RIAA molto probabilmente otterranno solo un ordine del tribunale / legge che costringerà Bitcasa a implementare un meccanismo per consentire alle due organizzazioni di ottenere un elenco di utenti con determinati contenuti. Quindi il problema non è nemmeno tecnico.
#6
+5
Zooko
2011-09-23 21:14:47 UTC
view on stackexchange narkive permalink

La stessa domanda è stata posta allo scambio di stack di crittografia. Si prega di vedere la mia risposta lì, poiché c'è una sottigliezza che è facile da trascurare e che è stata attentamente analizzata dal progetto open source Tahoe-LAFS: https://crypto.stackexchange.com/questions/729/is- crittografia-convergente-veramente-sicura / 758 # 758

Puoi espandere solo un po 'qui - un paio di punti elenco sulla sottigliezza che menzioni aiuterebbero gli utenti.
Ci sono due possibili attacchi. Il primo, che chiamiamo "conferma di un attacco di file", è l'ovvio problema che la deduplicazione espone il fatto che le due cose erano uguali tra loro. Questo problema è stato immediatamente apprezzato e discusso quando la crittografia convergente è stata proposta per la prima volta (non con quel nome) sulla mailing list di cypherpunks nel 1996 (prima che Microsoft richiedesse un brevetto sulla crittografia convergente, quindi la discussione di cypherpunks è un'arte precedente che invalida il brevetto Microsoft .)
Il secondo attacco, che chiamiamo "impara le informazioni rimanenti", non è così ovvio, e per quanto ne so nessuno era a conoscenza di questo attacco fino al 2008, quando Drew Perttula e Brian Warner lo svilupparono come attacco contro il Tahoe-LAFS sicuro filesystem. Nell'attacco "apprendi le informazioni rimanenti", l'attaccante può fare ipotesi su alcune parti segrete, casuali e sconosciute di un file più grande e poi scoprire se una delle sue ipotesi è corretta. Si prega di consultare l'articolo su: http://tahoe-lafs.org/hacktahoelafs/drew_perttula.html
#7
+2
Rory Alsop
2011-09-14 17:34:06 UTC
view on stackexchange narkive permalink

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

Non credo che sia corretto. I metadati sono un canale laterale che può fornire una via di deduplicazione. Basta guardare la dimensione del file di tutti i tuoi documenti. Prima dell'hashing facilmente disponibile, la dimensione del file era una metrica utilizzata di frequente per il rilevamento dei duplicati.
Non mi ero reso conto che fosse effettivamente usato. Qualcuno lo fa ancora? Troppo facile falsificare qualsiasi file tu voglia, sicuramente?
È stato utilizzato nei programmi shareware di Windows (3.1 e 95) per cercare file duplicati (quando il nome del file non era sufficiente). Non credo che nessuno utilizzi quella tecnica in modo esplicito, ma la dimensione è una protezione importante contro l'aggiunta per riportare i dati modificati a un valore hash di destinazione. Per l'utente domestico medio, in passato aveva solo pochi documenti e di solito avevano dimensioni diverse. L'enorme quantità di dati che il consumatore medio ha ora insieme a un'orda di file (immagini) di dimensioni quasi identiche rendono la dimensione del file un indicatore scarso.
#8
-1
pAkY88
2013-12-16 21:50:37 UTC
view on stackexchange narkive permalink

hai perfettamente ragione! Usare solo la crittografia convergente non è una buona scelta, anche per file non originali https://tahoe-lafs.org/hacktahoelafs/drew_perttula.html Fortunatamente, sembra che esista una soluzione per combinare crittografia e deduplicazione. Si chiama ClouDedup: http://elastic-security.com/2013/12/10/cloudedup-secure-deduplication/



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...