Pattern per consentire a più persone di decrittografare un documento, senza condividere la chiave di crittografia?

È necessaria una chiave per documento, non una chiave per utente. Bene, hai bisogno anche di chiavi per utente, ma questa è un'altra questione.

In particolare, ogni documento D è crittografato con una chiave K _D . Quella chiave viene generata casualmente la prima volta che il documento viene importato nel sistema. Ogni documento ha la sua chiave. La chiave per un documento non può essere dedotta dalla chiave su nessun altro documento.

Ogni utente U ha anche una chiave K _U . Pertanto, se hai bisogno che il documento D sia accessibile agli utenti U , V e W , allora memorizzi < em> E _{K D} (D) (crittografia di D con la chiave del documento), insieme a E < sub> K _U (K _D ) , E _{K V} (K _D ) e E _{K W} (K _D ) (crittografia della chiave K _D con i tasti dell'utente U , V e W ). Queste "chiavi crittografate" hanno una piccola dimensione (poche decine di byte, indipendentemente dalle dimensioni del documento), quindi questo si ridimensiona.

Per rendere le cose più pratiche, potrebbe essere necessario utilizzare crittografia asimmetrica per le chiavi dell'utente: crittografia di D utilizza un comodo sistema simmetrico (ad esempio, AES), ma le "chiavi utente" saranno di tipo RSA (o un altro algoritmo simile come ElGamal). In questo modo, se l'utente U vuole condividere il documento D con l'utente V , allora lui:

1. recupera E _{K U} (K _D ) dal server;
2. usa la sua chiave privata per decrittografarlo e recuperare K _D ;
3. crittografa K _D con V chiave pubblica , fornendo E _{K V} (K _D ) .

La bellezza di questo schema è che V non deve essere presente per questa procedura, poiché viene utilizzata solo la chiave pubblica di V .

A quel punto, quello che hai veramente è OpenPGP , un formato pensato principalmente per le e-mail sicure. Le e-mail hanno questa "proprietà di condivisione" (un'e-mail può essere inviata a più destinatari) e sono asincrone (quando si invia l'e-mail, il destinatario non è necessariamente disponibile immediatamente). Ti consigliamo di riutilizzare OpenPGP, un formato che è stato esaminato da molti crittografi e per cui esistono già implementazioni.

Quando hai un meccanismo di condivisione, puoi semplicemente metterti come destinatario implicito per ogni documento e puoi leggere tutto. Indipendentemente dai requisiti di legge, assicurarsi di notificare agli utenti attraverso le "condizioni di utilizzo" che è possibile leggere tecnicamente tutto; altrimenti potrebbero farti causa per mancanza di avviso.

BUT, we have two new requirements to implement:

By law, we are required to be able to decrypt any documents we have on disk, upon request by the government;

Wow. Io davvero spero che tu stia pianificando di informare i tuoi utenti che starai backdooring il tuo servizio per le forze dell'ordine in modo che abbiano abbastanza tempo per cancellare i loro dati dal tuo servizio prima che ciò accada. Questa sarebbe la cosa etica e onorevole da fare.

Se sei costretto a farlo, ad es. da National Security Letter e non ti è permesso di parlare a causa di un ordine di bavaglio, quindi le tue opzioni sono limitate:

1. Chiedi a qualcuno della compagnia di divulgare anonimamente queste informazioni alla stampa gratuita (che in futuro il tuo servizio sarà backdoor).
2. Arresta il servizio per motivi non specificati. Offri ai tuoi utenti alcune settimane per scaricare i loro dati prima che vengano cancellati per sempre.
3. Trasferisci la tua azienda, il servizio online e il personale in un paese in cui non esistono leggi di sorveglianza draconiane.

Sembra che tu abbia già un servizio sicuro e che abbia attratto alcuni utenti orientati alla privacy. Qualunque cosa sarebbe meglio che installare volontariamente una backdoor per le forze dell'ordine e rovinare i tuoi utenti. Per quanto ne sai, non appena il tuo sistema proposto è in vigore per le forze dell'ordine, ti invieranno un mandato per tutti i dati degli utenti.

Sarebbe meglio chiudere la compagnia, prendere i soldi e avviare una nuova impresa, ma stavolta facendo bene. Ecco i miei suggerimenti:

• Avvia la tua azienda in un paese senza queste leggi. Ospita anche i tuoi server e i dati dell'utente.
• Utilizzare un client open source in modo che gli utenti abbiano fiducia nel software in esecuzione sul proprio computer / dispositivo. Sarà molto difficile nascondere una backdoor in futuro se sarai costretto dalle autorità perché qualcuno lo noterà.
• Tutte le chiavi di crittografia dei dati private sono archiviate lato client , mai sul server. Solo i dati crittografati sono memorizzati sul server. Tutta la crittografia e la decrittografia vengono eseguite sul client. Il server contiene solo dati crittografati. Gli utenti hanno la responsabilità di eseguire il backup delle proprie chiavi private. Quindi la tua azienda non è letteralmente in grado di rispondere alle future richieste NSL perché non hai le chiavi.
• Per l'autenticazione con il server e consentire all'utente di archiviare e scaricare i dati crittografati dal proprio account, impostare un tipo di protocollo di autenticazione della chiave pubblica per utente. Forse il server detiene la chiave pubblica per ciascun utente. L'utente conserva la chiave privata, quindi firma ogni caricamento di dati e richiede al server. Ogni client può avere la chiave pubblica del server incorporata (inserita) per verificare le risposte e i dati crittografati scaricati dal server.
• Per condividere file con altri utenti, l'utente può crittografare nuovamente il proprio file con una nuova chiave simmetrica e condividere quella chiave utilizzando lo scambio di chiavi pubbliche con altri utenti sul sistema. Il tuo servizio potrebbe gestire la condivisione della chiave pubblica per loro. Tuttavia questo è pericoloso se gli utenti non possono fidarsi completamente del server e se il server si trova in un paese con leggi di sorveglianza ostili. Gli utenti non sanno se il server sta dando loro una chiave pubblica falsa o reale per l'altro utente, quindi sarebbero vulnerabili agli attacchi MITM. Questo sarebbe un modo in cui l'applicazione della legge potrebbe utilizzare per accedere ai dati non crittografati per i file condivisi tra altri utenti. In questo scenario sarebbe più sicuro se gli utenti conoscessero le proprie chiavi pubbliche e possano condividerle privatamente con altri utenti quando desiderano condividere i dati con loro.
• Utilizza algoritmi a chiave pubblica più recenti che non sono vulnerabili ai computer quantistici. Nessuna curva RSA, DSA o ellittica.
• Usa la nuova chiave simmetrica e gli algoritmi di hash degli autori che si preoccupano della privacy e non amano la sorveglianza di massa. Ad esempio, Bruce Schneier & Daniel J. Bernstein.

La soluzione descritta da Tom Leek in precedenza è stata implementata dal negozio di documenti cloud opensource ownCloud . Il modello di crittografia è descritto qui .

Come indicato anche in altre risposte, puoi fare lo stesso con OpenPGP / GPG che ho delineato in una risposta a una domanda relativa . Per ripetere brevemente l'approccio standard:

1. Ogni utente ha una coppia di chiavi pubblica / privata
2. A ogni documento viene assegnata una chiave simmetrica univoca con cui il documento viene crittografato e caricato nel contenitore di archiviazione di backup. Questo è chiamato il file-chiave
3. Ogni volta che a un utente viene concesso l'accesso al file, la chiave del file viene crittografata con la chiave pubblica degli utenti

In particolare, si desidera essere in grado di fornire la chiave del file quando obbligato a rispettare la legge. Questa è una funzione di opt-in di ownCloud, in cui ogni chiave è crittografata con la chiave pubblica dell'amministratore di sistema. Con ownCloud l'intenzione della funzione è che l'utente possa aver dimenticato la passphrase sulla sua chiave privata e può chiedere all'amministrazione di concedere loro l'accesso al file di nuovo.

Una cosa da notare è che ownCloud utilizza un database regolare per i dati utente / gruppo e i metadati del file. I BLOB di file effettivi possono essere archiviati localmente o su un provider esterno come Amazon S3 o Google Drive. Puoi seguire lo stesso approccio; fare in modo che il client prima criptizzi e scriva in un archivio BLOB esterno fuori giurisdizione crittografato con le proprie chiavi, quindi scriva solo il proprio URL (tipicamente un GUID a 128 bit) nel proprio sistema. Benché questo sia tutt'altro che ideale in termini di complessità del sistema, potrebbe benissimo liberarti dal dover rispettare una legge pericolosa e oppressiva; come puoi solo passare i puntatori ai dati.

Penso che almeno un paese che sta implementando tali leggi totalitarie sta costringendo tutti i fornitori di cloud offshore a spostare i propri server nel paese per gli utenti domiciliati in quel paese. In tal caso, l'ultima risorsa è quella di consentire agli utenti del sistema di crittografare e scrivere sulle proprie unità di rete locali e memorizzare un percorso file nel sistema. Spetta quindi al cliente effettuare backup off-site di tali dati.

Come risposta diretta alla tua domanda, la risposta di Tom Leek è azzeccata.

Tuttavia, ti consiglio di adottare un approccio diverso: abbandonare la crittografia per utente.

Utilizzerai ancora la crittografia di rete (HTTPS), l'hashing della password e, se lo desideri, la crittografia del disco completo sul server. Tuttavia, non utilizzare alcuna crittografia oltre a questo. L'applicazione decide ancora chi può visualizzare un determinato documento: l'utente che ha caricato per la prima volta, l'amministratore per scopi legali e tutti gli utenti che hanno condiviso il documento con loro. In questo accordo, è abbastanza facile soddisfare tutte le tue esigenze.

Quindi perché suggerisco di abbandonare la crittografia per utente? Perché è complesso e difficile da implementare e in realtà non aggiunge molta sicurezza. Non hai davvero spiegato quale vantaggio si desiderava per la crittografia per utente, ma presumo che sia per mantenere i documenti al sicuro nel caso in cui il server sia compromesso elettronicamente o fisicamente. Entrambi questi dovrebbero essere eventi estremi: dovresti prendere precauzioni standard come il firewall per evitare che ciò accada. Ma se si verifica un evento così estremo, in realtà un attaccante avanzato può ottenere comunque i documenti dei tuoi utenti. Stanno aspettando in silenzio, aspettando che gli utenti effettuino il login, quindi acquisiscono la password e decrittografano i documenti.

So che è già stata data una risposta, ma ...

Devo fare qualcosa di molto simile sul mio sito web.

I documenti sono crittografati ma possono essere condivisi con altri utenti.

Essendo nel Regno Unito, sono obbligato a condividere i dettagli di sicurezza con i servizi di sicurezza se richiesto, ma solo se li ho. Non ho accesso a loro quindi questo non è un problema. (Non sono inoltre autorizzato a comunicare agli utenti che sono stati richiesti dettagli - il prezzo della libertà!)

Ogni utente ha una coppia di chiavi asimmetriche che viene utilizzata per proteggere i loro documenti. Le chiavi pubbliche sono memorizzate in testo semplice ma le chiavi private sono crittografate usando blowfish, con una chiave a 128 bit derivata dalla password dell'utente.

Quando un utente vuole condividere un documento, viene decodificato e una copia viene creata e crittografata utilizzando la chiave pubblica dell'utente di destinazione, che è semplice da fare in testo normale. Quando l'utente di destinazione esegue l'accesso, è possibile decodificare il documento utilizzando la propria chiave privata protetta.

Ovviamente se condiviso con più utenti ci deve essere una copia per ciascuno.

Poiché i requisiti dichiarati impongono che la crittografia sia essenzialmente per "show" (security theater?) e protezione di base per il furto, non protetta protezione a livello di documento, raccomanderei la crittografia di base del disco completo usando LUKS o simili. In questo modo hai la chiave principale per l'intero archivio e puoi usare schemi non crittografati per controllare l'accesso per utente ai vari documenti. La crittografia per documento non ti compra nulla se non il problema alla luce del requisito n. 1.

Inoltre, vorrei mettere in secondo piano la risposta dell'antispy sopra. Almeno il servizio proposto è altamente non etico e in alcune giurisdizioni sarebbe addirittura considerato una frode a seconda dei termini del servizio / ciò che hai comunicato ai tuoi utenti.