Determinazione della forza dell'HMAC troncato

I dettagli contano.

Come sottolinea @Ricky, la visualizzazione dei valori HMAC troncati non aiuta l'utente malintenzionato a trovare la chiave segreta, rispetto a una situazione simile in cui i valori HMAC non vengono troncati. Questo ha senso: il troncamento rimuove solo le informazioni.

Tuttavia , l'utente malintenzionato non è alla fine dopo la chiave segreta. Ciò che l'utente malintenzionato vuole davvero è quello di rendere forgeries , cioè calcolare alcuni valori HMAC che il computer accetterà come propri. Scoprire la chiave segreta consente di fare falsi, ma la capacità di fare falsi non implica necessariamente la conoscenza della chiave privata.

Fortunatamente , HMAC tende a comportarsi come un PRF , quindi esistono due metodi noti fare una falsificazione:

1. Esegui un'enumerazione di forza bruta delle chiavi possibili finché non viene trovata quella giusta (una che corrisponde a un paio di valori noti + coppie HMAC). Questo attacco viene sconfitto scegliendo la chiave nello spazio abbastanza grande da rendere l'enumerazione non realistica (cioè si genera una chiave a 128 bit con un PRNG crittograficamente strong).

2. La fortuna. L'attaccante invia una sequenza casuale di bit come valore HMAC e spera che funzionerà. Questo attacco viene sconfitto non troncando i valori HMAC a una lunghezza troppo piccola e / o applicando altre attenuazioni come consentire solo un tentativo e rifiutare irrevocabilmente i dispositivi che una volta mostravano anche un singolo valore HMAC falso (come fai tu).

L'attacco "fortuna" funziona con probabilità 2 ^{- n} , dove n è la dimensione (in bit) dell'output HMAC troncato . Cioè con un output a 32 bit, quindi una falsificazione basata sulla fortuna ha probabilità 1 su 4 miliardi o giù di lì per passare inosservato. Questo è il meglio che si può fare con un output a 32 bit, in generale; che HMAC si comporta come un PRF significa che è "ottimale" sotto questo aspetto. Se si tronca a 8 bit, la probabilità di successo dell'attacco è 1 su 256, che è probabilmente troppo per comodità. Ma questa è la tua decisione, in base al tuo contesto di utilizzo.

Inoltre (sempre come @Ricky sottolinea), fai attenzione agli attacchi di replay . Un MAC valido, supponendo che non ci siano falsificazioni, dimostra solo al computer che ha visto e "approvato" il contenuto del messaggio a un certo punto - ma non che sia stato il messaggio ultimo che ha visto. Le vecchie coppie messaggio-HMAC possono essere inviate di nuovo da un dispositivo falso. Per sconfiggere gli attacchi di replay, è necessario mantenere alcuni stati sul computer (il computer deve ricordare qualcosa sul dispositivo, ad esempio un "numero di sequenza di messaggi", che fa parte dei dati su cui viene calcolato il MAC e incrementato per ciascun messaggio) .

Sì. Sì.

B interagisce con A e lo sfidante come segue: B inoltra tutte le domande da A allo sfidante,
e fornisce lo stesso risultato di A. Per ciascuna risposta dello sfidante, B tronca la risposta
e invia la risposta troncata ad A. La vista di A in quell'interazione è identica alla vista di A in
l'interazione per il tuo scenario con la stessa chiave, quindi se A trova la chiave segreta, allora anche B.

B è una riduzione costruttiva dal trovare la chiave segreta per HMAC per trovare la chiave segreta
per HMAC troncato. Pertanto, se "un utente malintenzionato non riesce a trovare la chiave segreta" per HMAC
quindi "un utente malintenzionato non riesce a trovare la chiave segreta anche se l'hash è" troncato.

Tieni presente che avrai bisogno di qualcosa per difendersi dal riutilizzo delle vecchie coppie di tag di bilancio.

"Troncare un crittografico ben progettato" PRF "non dovrebbe comportare alcun problema di sicurezza diverso da
una riduzione della dimensione " codominio ". Come "PRF, dalla definizione , sono pseudo-casuali sul loro dominio.

"Tutte le altre cose uguali, usando un algoritmo di hash più moderno"
(SHA-256) "è più sicuro rispetto all'utilizzo di uno più vecchio" (SHA-1).
"Supponiamo che tu voglia 2 ^ 16 invece di 2 ^ 256. Questo è un fenomenale calo nello spazio" tag "dello spazio. A 2 ^ 16 o 2 ^ 32"
un tag casuale avrà rispettivamente 1 / (2 ^ 16) o 1 / (2 ^ 32) possibilità di essere accettato. "Mentre i codici QR
sono meno reattivi a dimensioni più lunghe, "c'è un compromesso tra lunghezza del tag e probabilità di contraffazione.