convalida la crittografia dei file senza chiave di decodifica

3

Potrei chiedere qualcosa di impossibile qui.

Voglio sapere se è possibile configurare un sistema di storage di terze parti in cui il provider di servizi non può decrittografare i file dei client, ma può deprezzare i file se due client caricano lo stesso file.

Penso di avere ragione nell'assumere che ciò richiederebbe che i due client che caricavano il file avrebbero dovuto cifrare con la stessa chiave, ma questo non è un problema di per sé in quanto il servizio potrebbe (per esempio) mandare i file essere crittografato con una chiave che è una funzione di un hash del file: entrambi i client condividono tale conoscenza (senza essere consapevoli l'uno dell'altro) ma il fornitore di servizi non è ancora così non sarebbe in grado di crittografare.

Va bene se i client seguono le regole e utilizzano il metodo e la chiave di crittografia obbligatori corrispondenti al file che viene caricato. Quello che mi chiedo è se sia teoricamente possibile scegliere una tecnica di crittografia in base alla quale il fornitore di servizi può verificare che il client abbia rispettato le regole , senza compromettere il requisito che il fornitore di servizi non deve essere in grado di decrittografare i file.

    
posta Jack Douglas 01.01.2014 - 09:51
fonte

3 risposte

4

In larga misura, la domanda non ha senso, perché i dati sono opachi per il server. Poiché il server non sarà in grado, in ogni caso, di leggere i file decrittografati, se due file sono identici o meno non dovrebbe avere alcun impatto. In effetti lo scenario completo deve essere reso più chiaro.

Hai un server. Il server memorizza "dati crittografati" per conto di alcuni utenti che invieranno a vicenda le chiavi di decodifica; tutta la decrittazione e la crittografia avvengono altrove, e il tuo server non può farlo. Dobbiamo assumere che esista un meccanismo fuori banda tramite il quale gli utenti scambiano le chiavi di decifrazione.

Quello che vuoi, in quanto proprietario del server, è riconoscere quando diverse istanze dello stesso file vengono caricate sul tuo server, in modo che tu possa pagare per lo spazio di archiviazione solo una volta (ho appena letto da qualche parte che "The Hobbit" è stato il film più copiato del 2013, quindi potresti presumere che la tua piattaforma prevista contenga diverse centinaia di copie di quel file di film multi-gigabyte). La crittografia normale e sicura dovrebbe impedire agli estranei di essere in grado di formulare qualsiasi asserzione sui contenuti dei dati, inclusa la possibilità di riconoscere se due file crittografati hanno lo stesso contenuto. In questo senso, la deduplicazione che stai cercando è un indebolimento del modello di sicurezza. Possiamo prevedere che alcuni utenti non gradirebbero; ad esempio, se la deduplicazione funziona, allora tu (come il server) puoi rilevare quando un utente sta caricando "Lo Hobbit".

(Quando la deduplicazione funziona, allora è possibile fare una ricerca esauriente sui contenuti del file, questo è facile da fare per i file che sono duplicati molto, perché un file noto a molti utenti non può essere quel segreto, e nel contesto dell '"enforcement della proprietà intellettuale", i file pesantemente ingannati sono di primario interesse.)

Se parliamo in termini generici, non è possibile applicare la deduplicazione , perché qualsiasi utente che voglia evaderlo può semplicemente crittografare i propri dati. L'utente 1 prima crittografa il file con una chiave segreta extra, che condividerà con l'utente 2; quella chiave viene scelta in modo casuale, quindi il file crittografato non corrisponderà a nessun'altra istanza degli stessi dati; il file crittografato viene quindi criptato di nuovo con il tuo servizio. Gli utenti possono fare una tale doppia crittografia perché i dati sono solo, in fine , un file sul loro disco, e abbiamo ipotizzato che gli utenti possano parlare tra loro indipendentemente dal proprio server. Finché gli utenti possono parlare tra loro, possono scambiarsi le chiavi segrete che non conosci.

In alcuni contesti molto specifici , è possibile dimostrare che alcuni dati crittografati soddisfano alcune proprietà algebriche senza rivelarlo. Vedi prove Zero-Knowledge non interattive . Questo viene utilizzato in alcuni protocolli di votazione elettronica, in modo che il dimostrante possa dimostrare che ciò che ha crittografato è in realtà uno 0 o un 1, non un qualsiasi altro intero, ma senza divulgare il valore effettivo del voto. Questo non si applica a un sistema di archiviazione di file generico, perché i "file normali" non seguono una struttura matematica distinguibile.

Pertanto , se vuoi applicare la deduplicazione agli utenti non collaborativi, allora devi renderlo in modo che gli utenti non possano parlare tra loro . È più facile dirlo ... e sembra difficilmente fattibile, poiché il sito è davvero utile, il mittente e il destinatario devono essere in grado di concordare almeno una chiave di riferimento, utilizzata per localizzare il file sul server.

    
risposta data 02.01.2014 - 17:29
fonte
1

Se si utilizza la crittografia a chiave pubblica con firma digitale per il proprio meccanismo di crittografia, è sufficiente decrittografare la firma utilizzando la chiave pubblica dell'utente per fornire l'hash ai dati di testo normale. Tale hash potrebbe quindi essere referenziato rispetto agli altri hash che hai memorizzato per determinare se questo particolare file è già stato caricato. Ovviamente, dovresti avere una copia della chiave pubblica dell'utente.

Suppongo che sarebbe possibile per l'utente contraffare la firma digitale (crittografare un hash non valido del file e collegarlo al file crittografato come firma) e caricarlo. Non sapresti perché non puoi decrittografare il file e controllare l'hash del testo in chiaro rispetto alla firma. L'unica ragione per cui posso pensare di farlo sarebbe ingannare il rilevamento dei duplicati, quindi non ci sarebbe molto motivo per l'utente di farlo.

Se hai il controllo sul meccanismo di crittografia potresti semplicemente richiedere che il file crittografato sia caricato insieme a un hash del testo in chiaro. Questo potrebbe anche essere sovvertito tramite il proxy di qualsiasi sistema di upload utilizzato per inviare un hash simulato.

    
risposta data 01.01.2014 - 10:28
fonte
0

Se ottengo questo correttamente, vuoi che gli utenti caricino file che il server o un intermediario non possono decifrare. Inoltre, i file crittografati con dati in testo normale ridondanti devono essere rimossi.

Tenendo da parte la sicurezza degli attuali metodi crittografici usati, credo che potresti fare quanto segue:

  1. L'utente seleziona un file da caricare. L'analisi lato client viene utilizzata per calcolare l'hash del file.
  2. Questo hash viene inviato al server per identificare se il file è duplicato.
  3. In caso contrario, viene utilizzato un approccio simmetrico o asimmetrico per crittografare il file sul lato client e quindi caricarlo sul server. Dovrebbe essere implementato un meccanismo per l'autenticazione sicura dell'host e la definizione della sessione per prevenire un vettore di attacco del canale laterale MiTM.
  4. Per il recupero, il file crittografato viene ricevuto dal server e decrittografato sul lato client.

Una preoccupazione è che se hai a che fare con file che richiedono la gestione della versione. In questo caso, l'hash del file cambierà con il suo contenuto. Avere un identificatore di file come testo normale nell'intestazione del file crittografato consentirebbe la gestione della versione senza esporre nessuno dei contenuti del file sul server.

    
risposta data 01.01.2014 - 16:43
fonte

Leggi altre domande sui tag