Attacco di tempo contro HMAC nella crittografia autenticata?

15

In una risposta a un'altra mia domanda , è stato notato che una classe utilizza funzioni di confronto di stringhe standard quando il controllo dell'HMAC nella crittografia autenticata renderebbe la classe vulnerabile agli attacchi temporali contro l'HMAC.

Non riesco a capire come questo sia un problema con un attacco a tempo contro l'HMAC della crittografia autenticata?

Prima di tutto, le implementazioni dovrebbero essere considerate note all'attaccante (in questo caso particolare la fonte viene semplicemente pubblicata), quindi l'unica cosa segreta sarebbe la chiave. Seguendo questa linea di ragionamento, in che modo una funzione di confronto a tempo costante nell'implementazione protegge da qualsiasi cosa? (Mi aspetterei che l'attaccante lo rimuovesse semplicemente, se usasse lo stesso codice).

E in secondo luogo, se considerassi l'implementazione come una black-box, il confronto è contro un HMAC dei dati con una chiave derivata PBKDF2. Non tentare un attacco di temporizzazione contro l'HMAC essere a) tanto lento quanto provare a forzare una password protetta da PBKDF2 b) non rivelare realmente alcuna informazione utile in qualsiasi tentativo di decifrare i dati? (l'HMAC è anche aggiunto al testo cifrato, accessibile a chiunque abbia accesso ai dati crittografati).

Quindi, cosa mi manca qui, perché gli attacchi temporali in questo scenario sono considerati un rischio da proteggere?

Aggiornamento rapido: Capisco come funzionano gli attacchi temporali , ma non capisco cosa si otterrebbe impiegando un attacco a tempo in uno scenario in cui la funzione di decifrazione assomiglia a:

/**
 * @param binary $data Where $data = salt, IV, encrypted data, HMAC(salt, IV, encrypted data)
 * @param string $password The decrypt-password
 * @return string|null plain text if data was successfully decrypted, null otherwise
 */
function decrypt($data, $password) {
    ...
}
    
posta Monika 08.12.2014 - 16:42
fonte

2 risposte

10

Il rischio è che un utente malintenzionato possa falsificare dati. In altre parole, possono creare il proprio testo cifrato e quindi capire l'HMAC previsto per far sì che il sistema accetti l'input come valido.

L'intero punto dell'HMAC è che tu solo come il proprietario della chiave può "firmare" i dati. Tuttavia, se l'applicazione perde informazioni sull'HMAC previsto dell'input, un utente malintenzionato può effettivamente "firmare" i propri dati.

In poche parole, funziona così:

L'autore dell'attacco ha trovato alcuni dati e vuole che il tuo sistema lo accetti. Per questo, hanno bisogno di conoscere l'HMAC giusto. Poiché l'utente malintenzionato non ha la chiave, non può semplicemente calcolare l'HMAC. Tuttavia, misurando le sottili differenze temporali, possono "chiedere" al sistema il valore atteso:

  • Attaccante: "Ho questo pezzo di dati, e la mia ipotesi è che l'HMAC inizia con il byte 0x00. È corretto? "
  • Tu: "No".
  • Attaccante: "HMAC inizia con 0x01?"
  • Tu: "No".
  • ...
  • Attaccante: "HMAC inizia con 0xAB?"
  • Tu: "Sì, il primo byte è corretto."
  • Attaccante: "OK. Il byte successivo è 0x00? "
  • Tu: "No".
  • ...

Alla fine, l'utente malintenzionato conosce tutti i byte.

Il problema è che l'applicazione non rifiuta semplicemente l'HMAC sbagliato. In realtà aiuta l'attaccante dicendo loro come dovrebbe l'HMAC .

Guardando il tuo aggiornamento, sembra che tu generalmente non capisca lo scopo dell'HMAC e perché sia importante.

Diciamo che non c'era HMAC. In tal caso, proteggi solo la riservatezza dei dati, non è integrità . Le persone potrebbero manipolare il testo cifrato esistente o inventare il proprio testo cifrato, e la tua applicazione sarebbe felicemente di trasformarlo in qualunque testo normale dovesse venire fuori. In molti casi, questo è un problema serio. Pensa a un cookie di sessione crittografato che contiene l'ID utente: non vuoi che le persone lo cambino.

Quindi aggiungi un HMAC come una specie di "firma" per impedire agli utenti di manomettere il testo cifrato. Desideri l'integrità della riservatezza e . Tuttavia, se un utente può capire l'HMAC giusto per dati arbitrari, l'intero esercizio è inutile. Si perde la protezione dell'integrità e si torna alla semplice crittografia. Ora di nuovo chiunque è in grado di fare confusione con il testo cifrato.

    
risposta data 08.12.2014 - 17:31
fonte
22

Permette il potenziale di una falsificazione esistenziale. Un utente malintenzionato può creare un HMAC valido per un messaggio scelto senza conoscere la chiave HMAC.

Fondamentalmente, il modo in cui funziona l'attacco è questo:

  1. L'attaccante invia un messaggio e un HMAC (in realtà solo una sequenza di byte della stessa lunghezza dell'HMAC) e le volte la risposta dal sistema di decrittografia.

  2. L'utente malintenzionato invia quindi lo stesso messaggio ripetutamente e lo stesso pseudo-HMAC, con l'eccezione che ora esegue iterazioni anche se ogni (256) valore possibile per il primo byte dell'HMAC.

  3. Se il sistema di decrittografia restituisce immediatamente un errore nel trovare una mancata corrispondenza tra i byte, una di queste iterazioni (quella con lo stesso valore del primo byte calcolato dal sistema di decrittografia) dovrebbe prendere leggermente più tempo per tornare. Se l'utente malintenzionato può rilevare tale differenza, ora conosce il primo byte corretto per l'HMAC corretto per il messaggio, data la chiave HMAC del sistema di decrittografia.

  4. L'attaccante invia lo stesso messaggio e HMAC, questa volta con il primo byte corretto noto, iterando sul secondo byte, fino a quando non trova di nuovo il byte che fa sì che il sistema di decrittografia impieghi un po 'più tempo a rispondere con un errore. L'hacker ora conosce il secondo byte dell'HMAC corretto.

  5. Risciacquare e ripetere per ogni byte successivo nell'HMAC, fino a quando non è stato derivato un HMAC valido per il messaggio scelto dall'aggressore, chiave sans.

Ecco perché il confronto HMAC deve essere costante, confrontando tutti i byte dell'HMAC inviato all'HMAC calcolato prima di restituire una risposta. In questo modo, indipendentemente dalla posizione di eventuali byte errati, il tempo di errore sarà sempre uguale. L'utente malintenzionato non ha più modo di dire cosa o dove sono i byte errati.

Aggiorna

Nello scenario specifico che presenti, HMAC ti fornisce protezione dell'integrità o è la parte "autenticazione" della "crittografia autenticata". Se può essere falsificato da un utente malintenzionato, il testo cifrato può essere modificato a tua insaputa e non hai più crittografia autenticata, ma efficacemente crittografia non autenticata e vulnerabile agli attacchi di testo cifrato scelti.

    
risposta data 08.12.2014 - 17:08
fonte

Leggi altre domande sui tag