Protocollo di crittografia broadcast per servizio di condivisione file (a-la Dropbox)

Prima lasciatemi dire che questa è essenzialmente una riformulazione della risposta collegata nella tua domanda.

Suggerisco di utilizzare la crittografia a chiave simmetrica per proteggere i file e la crittografia a chiave asimmetrica (pubblica) per proteggere le chiavi di crittografia simmetriche. È possibile utilizzare una coppia di chiavi PGP / GPG esistente oppure, per renderla trasparente, generare una coppia di chiavi esplicitamente per la propria applicazione. Se lo fai, per favore usa il codice collaudato per generare le chiavi.

Hai affermato che non è necessario memorizzare alcuna chiave sul server perché "Non voglio dare al manutentore del servizio la possibilità di accedere ai dati dell'utente". Finché le chiavi memorizzate sul server sono crittografate, il manutentore del servizio non ha accesso ai dati, quindi ho interpretato "nessuna chiave sul server" come "nessuna chiave che consentirebbe l'accesso ai dati."

Il processo funziona così: quando un file viene caricato, deve essere crittografato (da un'app sul client del mittente) utilizzando un algoritmo simmetrico come AES e una chiave generata casualmente. La chiave deve essere generata da un generatore di numeri casuali crittograficamente sicuro ( CSPRNG )

Il file crittografato viene caricato sul server. La chiave simmetrica, crittografata con la chiave pubblica del mittente, viene caricata come metadata del file, associata all'ID del mittente. Se un file viene caricato da un utente con l'[email protected], i metadati saranno:

[email protected] | crittografato (con K _A ) chiave simmetrica

A questo punto, solo Alice può leggere il file perché solo Alice ha la chiave privata che decrittografa la chiave simmetrica crittografata del file. (L'applicazione deve aver scartato la copia non crittografata della chiave simmetrica subito dopo l'aggiornamento dei metadati.)

Se Alice vuole consentire a [email protected] di recuperare il file, aggiunge ai metadati una riga come questa:

[email protected] | crittografato (con K _B ) tasto simmetrico

Alice lo fa recuperando i propri metadati, decifrando la chiave simmetrica con la sua chiave privata e ricodificando con la chiave pubblica di Bill.

Supponendo che il file di metadati non sia protetto, Bill può passare l'accesso a Charlie eseguendo lo stesso tipo di operazione. Non è solo OK, è buono. Bill può ovviamente scaricare il file e dare una copia a chi vuole. Se l'accesso viene passato attraverso i metadati del file, c'è una registrazione di ciò che è successo. (Bill può ancora passare il file ad altri, ma non è più costretto a seguire quella strada.)

A causa del tuo requisito di utilizzare una sola password, dovrai utilizzare la password che sblocca la chiave privata come password di accesso. Un modo per farlo potrebbe essere quello di memorizzare sul server un autenticatore per ogni utente, crittografato con la chiave pubblica dell'utente. Solo un utente con la chiave privata corrispondente può decrittografarlo e restituire l'autenticatore di testo normale al server.

Tutto fino al login comporta la crittografia end-to-end e quindi tutto ciò che passa "over the wire" è crittografato. Per l'autenticazione di accesso, il client deve restituire l'autenticatore di testo normale e ciò significa che è necessaria una connessione TLS.

Se si desidera disporre di una singola copia non duplicata e non si desidera che il provider di archiviazione sia in grado di decifrare la copia a riposo e il mittente può aggiungere e rimuovere i destinatari dopo il caricamento iniziale tempo, quindi limiti le opzioni. Se uno o più vincoli sono negoziabili, diventa più facile.

1. Encoder del mittente con una chiave master (simmetrica), quindi codifica una copia della chiave master con una chiave pubblica per destinatario e carica una revoca: richiede al mittente di mantenere la chiave master simmetrica o di mantenere il provider di archiviazione la chiave master simmetrica
   1 bis. Ciò significa che i destinatari possono apprendere la chiave principale, poiché è quello che sbloccherà la chiave privata del destinatario
2. Il mittente codifica una copia per-destinatario del messaggio con una chiave pubblica o condivisa per-destinatario unica. Ciò significa che persistono molte copie
3. Encoder del mittente con la chiave pubblica del provider di archiviazione, il provider di archiviazione lo decodifica, il provider di archiviazione rimane protetto dal provider di archiviazione e rende disponibile una copia a ciascun destinatario con la chiave pubblica del destinatario
4. Un sistema di segretezza come il sistema di condivisione segreta di Shamir 1 con un minimo la dimensione del quorum di 1 potrebbe essere utilizzata (non ne ho mai sentito parlare nel mondo reale, solo nelle discussioni crittografiche)