Principi di attacchi alla cache

Question

Principi di attacchi alla cache

#1 da (4 voti)
#2 da (0 voti)

19

Ci sono molte pubblicazioni scientifiche che si occupano di attacchi di cache. Più di recente, è stato pubblicato l'attacco CacheBleed che sfrutta i conflitti di cache cache sull'architettura Intel Sandy Bridge. La maggior parte degli attacchi temporali usa un approccio simile:

L'attaccante riempie la cache con gli stessi dati casuali che controlla.
L'attaccante attende mentre la sua vittima sta facendo alcuni calcoli (ad es. crittografia).
L'attaccante continua l'esecuzione e misura il tempo di caricare ogni set di dati che ha scritto nella cache al punto 1. Se la vittima ha effettuato l'accesso ad alcuni set di cache, avrà sfrattato alcune delle linee dell'attaccante, che l'utente malintenzionato osserva come maggiore latenza di accesso alla memoria per quelle linee.

In questo modo l'utente malintenzionato può scoprire quale cache set o anche quale linea cache è stata aperta dalla vittima.

La maggior parte dei documenti che ho letto concludono automaticamente che l'autore dell'attacco ha quindi la possibilità di dedurre i dati (ad esempio una chiave privata sicura) che è stata scritta in queste posizioni della cache. Questo è quello che non capisco:

Se so che la vittima V ha avuto accesso a una determinata posizione della cache, come posso ottenere i suoi dati? Molti indirizzi di memoria si associano alla stessa posizione di cache e anche se avessi l'indirizzo di memoria completo, dubito che l'autore dell'attacco possa eseguire un DMA.

Come riferimento puoi prendere l'attacco CacheBleed pubblicato di recente.

caching timing-attack side-channel

posta null 05.06.2016 - 10:07

fonte

2 risposte

0

Questo attacco è simile a Flush + Reload, tuttavia il tuo utilizza il riempimento della cache invece dei flush per forzare lo sfratto della cache.

Fare riferimento alle parti 3 e 4 di questo documento: link

Fondamentalmente, a causa di come funziona l'esponenziazione modulare, conoscendo il tempo tra ogni accesso in memoria alla chiave privata, puoi dedurre la chiave.

Un lungo ritardo tra due accessi significa una moltiplicazione che è un 1.

Un breve ritardo tra due accessi significa uno spostamento binario che è uno 0.

Quindi li sommi tutti e hai una rappresentazione abbastanza vicina della chiave. Prova più volte e aggiungi un po 'di magia statistica e finisci con la chiave.

Se qualcuno vuole volgarizzare ulteriormente la carta, sentiti libero di modificare questa risposta.

risposta data 23.08.2016 - 17:08

fonte

Leggi altre domande sui tag caching timing-attack side-channel

Utilizzo di URL oscuro per la sicurezza [duplicato] Quali sono le differenze tra WPA2-PSK e WPA2-EAP-PSK?

score 4 · Accepted Answer

Apparentemente, questo argomento ha suscitato grande interesse per molti di voi. Dopo aver fatto ulteriori ricerche, il mese scorso ho presentato l'attacco CacheBleed a un gruppo di scienziati. Ora vorrei condividere i miei risultati con te e rispondere effettivamente alla mia domanda.

I tre passaggi precedenti del generico attacco Prime + Probe sono corretti. Tuttavia, manca il passo decisivo, cioè come dedurre la chiave segreta. L'autore dell'attacco è non in grado di eseguire un DMA ed è non in grado di leggere i dati salvati nelle linee della cache. Questo è abbastanza importante da capire, perché altrimenti l'intero attacco sarebbe molto più facile.

L'utente malintenzionato sa solo quale linea cache è stata raggiunta misurando i ritardi. Inoltre, sa come viene implementato RSA e quali sono gli algoritmi in uso. OpenSSL utilizza un algoritmo di esponenziazione a finestra fissa per calcolare il messaggio m

m = c^d mod p

Dobbiamo capire come funziona questo algoritmo di esponenziazione. Il Manuale di crittografia applicata di Menezes, van Oorschot e Vanstone suggerisce il seguente pseudo codice:

Per favore non confondere la chiave segreta d e l'esponente e nell'algoritmo sopra. Dato che siamo interessati solo alla fase di decodifica, e non è la chiave pubblica ma il segreto. Quindi d = e nel nostro caso. Il punto interessante è la moltiplicazione in 3.2 . Usa il moltiplicatore precomposto g_j che effettivamente accelera l'esponenziazione. Tuttavia, la loro selezione dipende dalla chiave segreta.

Se l'attaccante conosce l'indice del moltiplicatore corrente, cioè quale moltiplicatore viene usato, conosce alcuni bit della chiave segreta. Il valore del moltiplicatore è non di interesse .

OpenSSL utilizza la cosiddetta tecnica scatter-gather per evitare attacchi alla cache sulla granularità della cache line. È prevedibile dove il moltiplicatore è memorizzato. In totale ci sono 32 moltiplicatori. Per questo motivo ciascuno ha bisogno di 5 bit per essere identificato in modo univoco. I due bit più significativi selezionano la linea della cache mentre i tre bit meno significativi identificano il bin. Ogni linea della cache è composta da otto contenitori.

L'utente malintenzionato è in grado di dedurre quale bin è stato utilizzato durante un'operazione di decrittografia. Questo rivela tre bit dell'indice del moltiplicatore usato e quindi parzialmente la chiave privata. I due bit mancanti possono essere calcolati a causa delle ridondanze nelle chiavi RSA.

Per riassumere, nessun DMA viene eseguito, l'utente malintenzionato non legge i dati dalla cache. Il fattore cruciale è che la posizione della cache rivela in parte la chiave segreta. Ciò è dovuto agli accessi alla memoria dipendenti dal segreto. Anche attacchi simili come AES fanno uso della posizione della cache. I dati effettivi non sono interessanti, ma la posizione rivela dati sensibili.