Come garantire la privacy sui file che immagazzino

1

Voglio creare un'app per Android in cui gli utenti di un ufficio (uso tipico) possono caricare i documenti scansionati sul servizio di back-end dell'app per un uso futuro.

es. Un avvocato desidera caricare una frase sensitiveDocument.png .

La privacy garantita per l'utente è un punto vendita importante per il prodotto. Dall'esempio precedente, l'avvocato vuole che sia l'unica persona in grado di leggere il documento, né io come amministratore S3 (ho intenzione di utilizzare Amazon S3 per lo storage) e per non parlare degli altri utenti.

Inoltre, voglio assicurare ai miei utenti che non posso leggere i loro file.

Idea

Un tasto utente controllato dall'utente : l'utente crittografa simmetricamente il file con la sua chiave, carica il file crittografato e quando vuole leggere il file, recupera il file crittografato e lo decodifica su l'app per Android.

Contro

  • L'utente deve ricordare un altro bit di informazioni oltre alla password.
  • Alternativa alla precedente, l'app può generare e memorizzare automaticamente la chiave ma ...
  • In entrambi i casi l'utente può perdere la chiave, per il primo caso, ad es. se ha dimenticato la chiave e nel lato app, ad es. se la chiave viene cancellata per errore o il telefono viene rubato, ecc.

C'è un modo per farlo correttamente?

    
posta sanrodari 15.01.2014 - 19:33
fonte

3 risposte

1

Se l'utente può leggere il suo documento, ma non è possibile, l'utente deve "sapere" (cioè ricordare o archiviare) un valore che non è possibile. Un "valore" segreto che viene utilizzato per sbloccare l'accesso ad alcuni documenti: i crittografi chiamano tali "chiavi" di valori.

Una password è una chiave che l'utente può ricordare, cioè può memorizzarla nel suo cervello. Ciò ha delle carenze, soprattutto essendo che le password realistiche sono deboli contro la forza bruta. L'hashing della password appropriato viene utilizzato per cercare di far fronte a questa debolezza . In ogni caso, gli utenti possono dimenticare le password.

Da un punto di vista crittografico, un modo "ragionevole" di fare le cose è il seguente:

  • Ogni utente ha due "password": la sua normale ( P ) e una "password di ripristino" ( R ) che non è propriamente una password, in quanto è una grande sequenza di lettere casuali e l'utente non tenterà di ricordarlo.
  • L'utente scrive la password di ripristino su un foglio di carta che memorizza in un luogo sicuro (ad esempio in una banca). La password di ripristino è lì per recuperare i dati quando l'utente dimentica la sua password.
  • Ogni file è crittografato con una chiave simmetrica K , chiamata "chiave principale" (ogni utente ha la propria "chiave master").
  • Il sistema di archiviazione, dove sono i documenti, contiene anche la crittografia di K di P e la crittografia di K di R . Quando si crittografa "con la password P ", voglio dire che c'è un salt casuale specifico dell'utente usato in una buona funzione di hashing della password per convertire P in una chiave simmetrica K P e quella chiave simmetrica viene utilizzata per crittografare K . Allo stesso modo con R .

Quando l'utente vuole leggere i suoi documenti, inserisce P , da cui deriva K P (usando il sale memorizzato); questo permette di recuperare K e quindi decifrare i documenti.

Quando l'utente cambia la sua password in P ', è sufficiente recuperare K (come sopra), generare un nuovo salt, quindi calcolare K P ' , codifica K con quello e archivia il risultato (insieme al nuovo salt) sul server.

Quando l'utente dimentica la sua password, va nella sua banca, recupera la sua password di ripristino R e la usa per recuperare K e quindi sceglie una nuova password.

Con quanto sopra, il sysadmin del server di archiviazione può ottenere informazioni sufficienti per "provare le password" (che si chiama "attacco del dizionario offline"). Questo è inevitabile, ed è per questo che usiamo una buona funzione di hashing della password con sali e molte iterazioni.

Come indica @ scuzzy-delta, un punto critico è che il cliente non è uno sviluppatore, quindi dovrà necessariamente fidarsi di alcuni software, a un certo punto, di non giocarci brutti scherzi. Questo copre la tua app, ma anche il sistema operativo; e, più in generale, spetterà al cliente assicurarsi che il suo PC non sia infetto da malware. In queste condizioni, non è possibile garantire che i documenti del cliente non vengano saccheggiati; ma puoi assicurarti di non essere incolpato per questo, se ottieni il tuo codice controllato (ricorda che i tuoi clienti sono avvocati: potrebbero essere feroci). L'audit è molto costoso, e lo è sempre di più se il codice è più grande, quindi vuoi mantenere l'app più piccola possibile.

La crittografia è nota per essere difficile da implementare, quindi sei ampiamente incoraggiato ad attenersi ai formati standard esistenti e, se possibile, alle librerie standard. Il formato OpenPGP sarebbe un buon punto di partenza. Idealmente, dovresti trovare un buon formato già implementato sia da Android che da iOS (il codice che è già nel telefono non deve essere controllato, almeno non per l'audit che copre la tua skin).

    
risposta data 15.01.2014 - 20:43
fonte
2

Un ulteriore passaggio consiste nell'utilizzare una funzione di derivazione della chiave per derivare una chiave dalla password dell'utente. È quindi possibile crittografare la chiave dati utilizzata per crittografare ciascun file con la chiave derivata dell'utente ed è possibile memorizzare il modulo crittografato della chiave dati sul server con il file. Senza la password dell'utente, la chiave non può essere utilizzata, ma consente anche all'utente di accedervi da più dispositivi senza dover gestire la gestione delle chiavi.

    
risposta data 15.01.2014 - 19:51
fonte
1

@AJ Henderson è corretto - usa una funzione di derivazione della chiave anziché far creare all'utente / ricordare / inserire la chiave effettiva.

Oltre a ciò, hai detto che vuoi rassicurare l'utente che non puoi leggere i loro file - il che significa che devi fornire una prova che sei sincero. Le migliori prove sono costose da simulare. Quindi potresti considerare quanto segue:

  • Apri il codice per l'ispezione
  • Offri un "bug bug di sicurezza" (per punti extra, fallo tenere in deposito da una terza parte neutrale)
  • In alternativa o in aggiunta all'open-sourcing, invita una terza parte autorizzata a eseguire un controllo del codice sorgente ( il processo è attualmente in corso per TrueCrypt ed è molto interessante da seguire).
  • Promuovi rimborsi in caso di violazione della sicurezza
risposta data 15.01.2014 - 20:02
fonte

Leggi altre domande sui tag