Un file di chiavi casuali è più sicuro di una chiave derivata?

3

Sto studiando un livello di crittografia per alcune API proprietarie di cloud storage. Fondamentalmente questo dovrebbe funzionare come un adattatore trasparente che crittografa blob (file) binari interi sul caricamento e li decrittografa al download. Il motivo è archiviare i dati crittografati sul lato non attendibile del server.

Voglio utilizzare un algoritmo di crittografia simmetrica. La chiave per questo verrà generata e mantenuta dal lato client. Poiché non sono in alcun modo esperto di sicurezza, la mia domanda è se sarebbe più sicuro generare una chiave binaria della dimensione desiderata utilizzando uno pseudo-RNG piuttosto che affidarsi a un funzione di derivazione dei tasti ? La chiave casuale sarebbe in qualche modo protetta da una passphrase, naturalmente.

Una domanda correlata è come verificare se la passphrase inserita è corretta.

    
posta aeisele 21.01.2013 - 10:44
fonte

2 risposte

2

Se si genera una chiave casuale senza password, la sua entropia (una misura del tempo impiegato per trovare la chiave attraverso i tentativi di forza bruta) è la dimensione della chiave. Ad esempio, se l'algoritmo di crittografia è una modalità di AES-128 (una scelta comune), una chiave casuale ha 128 bit di entropia, il che significa che ci vogliono fino a 2 128 tentativi di trovarlo forza bruta. (Ciò richiederebbe più di un miliardo di anni con un miliardo di PC.) Il rischio con una chiave casuale senza password è che se un utente malintenzionato ottiene il file chiave, può utilizzarlo come se fosse tu.

Se si utilizza una chiave derivata da una password, la sua entropia sarà molto inferiore. Quanto dipende da come viene scelta la password , ma devi fare affidamento sull'aver scelto una password complessa, che può essere un problema se avere molti utenti che non possono essere considerati attendibili per non selezionare Passw0rd . Inoltre, l'utente malintenzionato potrebbe ottenere informazioni sulla password osservando il tipo o altri metodi "fuori banda".

Se si genera un file chiave e lo si protegge con una password, si ottiene il meglio da entrambi i mondi, in termini di riservatezza. L'utente malintenzionato dovrebbe ottenere sia il file chiave che la password per ottenere la chiave. Nota che se l'utente malintenzionato ottiene il file chiave, può provare a scoprire la password, ma anche in questo caso potresti avere un po 'più di tempo per cambiare la chiave mentre tenta di decifrare la password.

In base all'applicazione, l'inserimento di una password non valida può indicare che la password è errata senza contattare il server o può calcolare in modo non corretto una chiave errata rifiutata dal server. Quest'ultimo è migliore perché significa che tutti i tentativi di cracking devono raggiungere il server e il server può limitare il tasso di tentativi di cracking. In questo modo, anche se l'utente malintenzionato prende il file chiave, sarà limitato alla percentuale di tentativi consentiti dal server e saprai che qualcosa sta succedendo. Se la password può essere convalidata solo con il file chiave, l'utente malintenzionato può rendere offline i suoi tentativi di cracking e può parallelizzarli su molti computer.

Tieni presente che se rendi più difficile trovare la chiave, questo ti ostacola così come gli aggressori. Se si utilizza un file chiave, è necessario eseguire il backup del file chiave. Se si utilizza una password, è necessario eseguire il backup di tale password. Se si utilizza un file chiave protetto da password, è necessario eseguire il backup entrambi.

    
risposta data 21.01.2013 - 12:02
fonte
0

Supponendo che non pubblichi il file di chiavi crittografato, questo proverebbe ad implementare "qualcosa che hai" (il computer con il file di chiavi), insieme a "qualcosa che conosci" (la frase segreta).

Ma poi hai un altro problema da risolvere: la distribuzione delle chiavi. In pratica questo è un grosso problema. In particolare per sistemi più generali, e specialmente per paranioa completamente generalizzato.

Se vuoi scendere a compromessi su generalità / facilità d'uso per guadagnare sicurezza, va bene. Altrimenti, potrebbe essere meglio focalizzare l'attenzione altrove, ad es. sicurezza della password, ripristino e monitoraggio dell'accesso lato server.

La sicurezza della password IMO è un punto dolente per la maggior parte dei sistemi, il che la rende un'area importante su cui concentrarsi. Il recupero è un'area strettamente correlata (e senza cura, può finire come un anello debole che compromette l'intero sistema). Quindi il monitoraggio dell'accesso lato server potrebbe essere in grado di raggiungere un obiettivo simile al file di chiavi, in un modo più pratico.

Penso al monitoraggio degli accessi come GMail. "ATTENZIONE: hai effettuato l'ultimo accesso dalla Cina, se ti sembra sospetto, clicca qui per un consiglio". Rilevamento, attenuazione e segnalazione di attacchi a forza bruta. A livello di browser (o addirittura di app), credo che alcuni siti mantengano un elenco di dispositivi usati e invii un'email all'utente quando ne aggiungono uno nuovo. Poter aggiungere nuovi dispositivi potrebbe anche essere un utile punto per mettere l'avvertimento "hai davvero fiducia nel dispositivo che stai utilizzando con tutti i dati memorizzati nel tuo account?".

    
risposta data 21.01.2013 - 11:36
fonte

Leggi altre domande sui tag