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).