Perché memcmp non dovrebbe essere usato per confrontare i dati critici di sicurezza?

Sfruttare le informazioni sui tempi è un possibile attacco contro cose come i sistemi di autenticazione delle password.

Concettualmente memcmp() funziona confrontando due serie di dati binari su base byte per byte (in realtà i processori possono confrontare più byte alla volta, a seconda dell'ottimizzazione, ma si applicano gli stessi principi seguenti). La funzione inizia all'inizio dei dati, confronta ogni byte in sequenza ed esce non appena trova una differenza. Se non viene rilevata alcuna differenza, la funzione restituisce un codice che indica che i dati corrispondono.

Poiché la funzione ritorna non appena trova una differenza, un utente malintenzionato con un orologio sufficientemente preciso può dedurre informazioni segrete. Possono indurre chiamate a memcmp() con diversi input e misurando quali input impiegano più tempo, possono dedurre cosa potrebbe essere un segreto memorizzato.

Esempio:

Considera un classico sistema di hashing delle password. Supponiamo che la tua password sia memorizzata come hash segreto, ad esempio Ek8fAMjPhBo . (Questo hash è stato generato utilizzando lo schema DES fornito dalla funzione crypt() di Linux con una percentuale di na e una password di secret . Si noti che questa funzione è non sicura e non si deve usare in sistemi reali.)

In un sistema con password complesse, il tuo hash Ek8fAMjPhBo viene memorizzato, ma la tua password è non archiviata. Quando ti viene chiesto di autenticare il sistema, prenderà la tua password, la cancellerà e poi confronterà i due hash l'uno con l'altro. Se gli hash risultanti corrispondono, viene garantito l'accesso al sistema, se gli hash non corrispondono, la password viene rifiutata. Ciò consente al sistema di verificare se si conosce o meno la password senza effettivamente memorizzare la password stessa.

In che modo un utente malintenzionato può utilizzare i tempi per attaccare questo sistema:

Per attaccare questo sistema, un avversario deve solo capire quale hash della password ha l'hash memorizzato. Normalmente l'hash memorizzato viene tenuto segreto, ma l'avversario può utilizzare le informazioni sul tempo per dedurre quale potrebbe essere l'hash memorizzato. Una volta che l'avversario deduce l'hash memorizzato, è vulnerabile agli attacchi della tabella arcobaleno molto più veloci e non in linea, oltre a eludere le misure di sicurezza online come i limiti dei tentativi di password.

Il sistema di password sopra riportato deve confrontare un hash candidato con l'hash memorizzato per funzionare correttamente. Supponiamo che occorra 10 nanosecondi per confrontare ogni byte dell'hash candidato con l'hash segreto memorizzato. Se nessun byte corrisponde (un confronto), memcmp() richiederà circa 10ns. Se un byte corrisponde (due confronti) allora memcmp() richiederà circa 20ns. L'utente malintenzionato genera alcune password e le esegue attraverso il sistema, registrando per quanto tempo ciascuna prende. Supponiamo che i primi confronti di hash richiedano circa 10ns ciascuno e poi ritornino, indicando che nessuno dei byte dell'hash candidato corrisponde all'hash memorizzato. Dopo alcuni tentativi, uno dei confronti di hash richiede 20ns, il che indica che il primo byte dell'hash candidato corrisponde all'hash memorizzato. Nell'esempio sopra questo indica che l'attaccante ha dedotto che il primo byte dell'hash Ek8fAMjPhBo è E .

Gli hash di design hanno la proprietà che non puoi prevedere quale hash corrisponderà a quale password, quindi per esempio questo non dice all'autore dell'attacco che la password inizia con s . Tuttavia, l'autore dell'attacco potrebbe disporre di una grande tabella di hash precalcolati (una tabella arcobaleno ) in modo che possano cercare altre parole chiave hash su una stringa che inizia con E . Dopo aver provato abbastanza hash, otterranno un input che causerà memcmp() a 30ns, il che indica che i primi due byte corrispondono e hanno dedotto che i primi due byte dell'hash sono Ek . Ripetono questo processo ancora e ancora fino a quando non deducono tutto o la maggior parte dell'hash. A quel punto o conoscono la password o possono forzarla con un tradizionale attacco da tavolo arcobaleno.

Questo è un po 'ipotetico, ma puoi trovare molte informazioni pratiche sugli attacchi temporali altrove sulla rete, ad esempio:

link

La questione non è proprio quella di sostenere che un attacco di canale laterale è pratico in qualsiasi applicazione tu abbia in mente per il tuo sistema .

Un punto migliore da fare è quello

1. Gli attacchi da canale laterale tendono ad essere possibili in più situazioni di quanto la maggior parte degli sviluppatori possa pensare a mano a mano.

2. In ogni situazione, affidabile convincere se c'è no opportunità per gli attacchi temporali è molto più lavoro in fase di sviluppo che semplicemente usando un metodo di confronto sicuro come SOP. Più lavoro significa più costo e più alto rischio di sbagliare.

In parole povere, è un frutto a bassa attaccatura. Avere una politica di "non usare mai memcmp sui dati critici per la sicurezza", è superiore a una politica di "ok per usare memcmp quando questo è sicuro" su quasi tutti i parametri che posso immaginare.

Se, in modo straordinario, sei in una situazione in cui la frazione di una frazione di un microsecondo di tempo della CPU si spegne ogni confronto non corrispondente (che di solito è il non comune caso in primo luogo!) ti farà risparmiare abbastanza denaro che vale la pena spendere per un'analisi di sicurezza adeguata, quindi avrai un sacco di documenti commerciali che lo dimostrano.

(E anche così, basta leggere i fumetti per il tempo che ci vorrebbe per fare quell'analisi mentre lasci che la Legge di Moore faccia il lavoro per te probabilmente ti salverà ugualmente bene quei microsecondi della CPU per te).

Cade in una categoria di attacchi ai canali laterali (gli stessi requisiti di RSA, il tempo di esecuzione con la chiave privata dovrebbe essere costante).   Inoltre, non è necessariamente che la RAM sia compromessa, le operazioni possono essere eseguite su TEE (ambiente di esecuzione trusted).