Verifica login e crittografia con PBKDF2

10

Sto scrivendo un'applicazione desktop in cui sto usando PBKDF2 per generare una chiave di crittografia per crittografare AES-128 il file di configurazione. Il file di configurazione contiene una chiave criptata che è stata utilizzata per crittografare i dati per il programma. L'utente ha già inserito quella chiave come fornita da noi durante l'installazione. L'idea è che entrano una volta nella chiave criptata e poi possono usare una password più facile da ricordare. Fin qui tutto bene.

Quindi, quando l'utente carica il programma, inserisce la password. Abbiamo usato la password per rigenerare la chiave PBKDF2 e decrittografare il file di configurazione.

Ora, come posso verificare facilmente che l'utente abbia inserito la password corretta? Naturalmente, se hanno inserito una password errata, la decrittografia dei dati non funzionerà. Ma mi piacerebbe rifiutare la password immediatamente piuttosto che lasciare che il programma si carichi e quindi l'utente riceve una finestra di messaggio di errore di decrittografia.

Ho letto che TrueCrypt codifica una costante conosciuta, la stringa "TRUE" e quindi verifica che la chiave basata su password crittografi "TRUE" sullo stesso testo cifrato. Ho anche letto sulla generazione di un hash HMAC-SHA per verificare i dati crittografati. Ma che non si vuole usare la stessa chiave per il MAC e per crittografare i dati. Per questo motivo, mi piace il metodo TrueCrypt (non devo tracciare due serie di Sali e IV). Non mi interessa davvero se un utente malintenzionato può caricare il programma. Non saranno in grado di leggere alcun dato. Non voglio che l'utente entri con la password sbagliata e penso che il programma non sia sicuro.

Qual è il modo giusto per farlo?

    
posta John 05.07.2012 - 16:58
fonte

2 risposte

11

Dipende se vuoi difenderci dagli errori di battitura o dagli attacchi.

Se vuoi solo difendere dagli errori di battitura , includi solo alcune strutture nel tuo file di configurazione. Ad esempio, definisci che il tuo file di configurazione DEVE iniziare, quando decrittografato, con la stringa "Questo è il file di configurazione per l'applicazione FooBar". Se non trovi quella stringa su decrittografia, la chiave è sbagliata.

Se vuoi difendersi dagli attacchi (un ragazzo cattivo modifica volontariamente parti del file di configurazione crittografato per farti caricare una chiave errata), allora hai bisogno di qualcosa di più strong . La soluzione "giusta" consiste nell'utilizzare una modalità di crittografia autenticata (il mio preferito è EAX ). Se il tuo framework di programmazione non include un'implementazione della modalità EAX, puoi fare qualcosa di simile:

  • Dalla passphrase dell'utente, genera 384 bit di chiave (PBKDF2 è una "funzione di derivazione della chiave", può essere usata per produrre chiavi di lunghezza arbitraria). Dividi questi in tre chiavi a 128 bit K 1 , K 2 e < em> K 3 .
  • Cripta il file di configurazione con AES-128-CBC, usando K 1 come chiave e K 2 come IV. Chiama il risultato C (il file crittografato).
  • Calcola un valore MAC su C , utilizzando il tasto K 3 . Per la funzione MAC, usa HMAC con SHA-256 (o SHA-1, ma SHA-256 è preferito su una base generale). Il MAC è memorizzato lungo C (aggiunto, come intestazione, come un file separato ... a tua scelta).
  • Quando decrittografato, sul retro: ottieni le tre chiavi da PBKDF2, verifica il MAC e (solo se il MAC era corretto) decrittografare il file.

Questo schema resiste sia agli attacchi che agli errori di battitura (tuttavia, non distingue tra una passphrase errata e un attacco vero e proprio).

Modifica: l'avevo lasciato implicito, ma sarebbe meglio dichiararlo chiaramente: poiché stiamo usando PBKDF2, c'è un salt che viene usato per girare la password nell'output di PBKDF2. Ogni file crittografato DEVE avere il proprio sale. Il sale DEVE essere codificato nell'intestazione del file. Se un file viene "ri-criptato", verrà generato un nuovo sale casuale.

    
risposta data 03.09.2012 - 20:10
fonte
1

Il meccanismo di TrueCrypt è probabilmente l'opzione migliore qui. Puoi verificare se la password è corretta dopo la decrittografia di un solo blocco e non richiede ulteriori considerazioni sulla sicurezza.

L'introduzione di hashing e verifiche aggiuntive ti rende vulnerabile a eventuali punti deboli di tali algoritmi. In questo caso, ti stai affidando esclusivamente alla sicurezza del tuo codice, su cui stai facendo affidamento anche per proteggere i tuoi dati. Se AES-128 è rotto, avere "TEST" erroneamente identificato come valido è l'ultima delle tue preoccupazioni!

    
risposta data 05.07.2012 - 17:55
fonte

Leggi altre domande sui tag