Ci sono alcuni riferimenti là fuori che dicono che HMAC-SHA2 deve essere usato su HMAC-SHA1.
Se sto usando un collegamento IPsec con HMAC-SHA1, quanto è vulnerabile essere intercettato e incrinato?
Ci sono alcuni riferimenti là fuori che dicono che HMAC-SHA2 deve essere usato su HMAC-SHA1.
Se sto usando un collegamento IPsec con HMAC-SHA1, quanto è vulnerabile essere intercettato e incrinato?
Per prevenire l'intercettazione e la lettura del contenuto segreto, vengono utilizzati algoritmi di crittografia come AES. Gli HMAC non hanno alcuna importanza per questa parte.
Supponendo che AES (CBC, ecc.) sia sicuro, un utente malintenzionato potrebbe comunque intercettare ciò che stai inviando o ricevendo, ma non può leggerlo. Ciò che potrebbe fare, tuttavia, è di cambiare i dati in qualcos'altro. Di nuovo, supponendo che AES sia sicuro, non è possibile per l'utente malintenzionato fornire dati che, una volta decifrati, sono significativi, ma è comunque un problema, poiché rilevare automaticamente che non si ottiene la spazzatura non è sempre possibile.
Questo è lo scopo di HMAC (con l'algoritmo hash) in IpSec: consente di verificare se il contenuto è stato modificato durante la trasmissione.
Mentre SHA1 non è sicuro come si pensava, i problemi noti non si applicano agli HMAC con SHA1. In sostanza, il rischio si riduce alla possibilità che un hacker indovini la chiave giusta o l'hash per un messaggio, per farti credere che un messaggio sbagliato con contenuto spazzatura è quello reale (e niente di più):
Per SHA1 in IpSec, è 2 ^ 160 possibili valori che la chiave può avere (se l'utente malintenzionato ha la chiave, può generare HMAC per tutti i messaggi ricevuti, cioè darti tutta la spazzatura che vuole), o 2 ^ 96 possibili valori per l'hash stesso (se l'attaccante riesce a ottenere quello, può essere modificato solo un blocco). Mentre potrebbe essere migliore, non è così male, soprattutto perché è molto improbabile trovare il giusto valore prima che la trasmissione finisca.
Per SHA256, i valori corrispondenti sono 2 ^ 256 e 2 ^ 128.
(Vedi anche RFC 6071, 2404, 4868)