Attacchi a tasti generati con bassa entropia

9

Se dovessi dare a qualcuno due chiavi da 4096 bit, e dire che uno è stato generato in un sistema operativo Linux con un'entropia molto bassa disponibile, e uno è stato generato in un sistema operativo Linux con più di sufficiente entropia.

Sarebbe possibile differenziare tra i due? Sarebbe loro in grado di fare qualsiasi tipo di attacco sulla chiave generata dall'entropia bassa?

Lo chiedo principalmente perché spesso genera molti parametri di chiavi / certificati / DH di 4096 bit e altro ancora su VM e la mia poca conoscenza di questo è che voglio utilizzare molta entropia disponibile perché rende più difficile prevedere le cose.

Ho fatto qualche ricerca sul perché la casualità è importante e ho trovato un articolo del blog ( Perché i sistemi sicuri richiedono numeri casuali ) che cerca di spiegare perché la casualità conta e descrive un hack del popolare sito Web di programmazione e tecnologia Hacker News:

And all pseudo-random number generators need to start somewhere; they need to be seeded and that's where Hacker News failed. The random number generator was seeded with the time in milliseconds when the Hacker News software was last started. By some careful work, the attacker managed to make Hacker News crash and could then predict when it restarted within a window of about one minute. From it he was able to predict the unique IDs assigned to users as they logged in and could, therefore, impersonate them.

Ok, lo capisco, ma non è ancora necessario che l'attaccante effettui un attacco attivo invece di attacchi passivi? Voglio dire che non è possibile ottenere un flusso di traffico di qualcuno e dice " Ehi, questi parametri Diffie-Hellman / chiavi SSH sembrano essere generati con bassa entropia quindi permettigli di attaccarli ", giusto?

Quindi diciamo che ho appena generato una chiave o qualcos'altro con bassa entropia, ma l'attaccante non è in grado di lanciare un attacco attivo e al momento non sa quale pre-master segreto scelto a caso è stato usato, quindi?

Ancora non mi sento in grado di esprimere veramente quello che sto dicendo, quindi aggiungerò un altro esempio:

Here's part of how a computer using WiFi establishes a secure connection to an access point using the popular WPA2 protocol:

  • The access point generates a random nonce and sends it to the computer.
  • The computer generates a random nonce and sends it to the access point.
  • The access point and the computer continue on from there using those random nonce values to secure the connection.

Ok, va bene. Dice che sono MITM e che stai guardando passivamente il traffico, ed è successo che il router aveva esaurito l'entropia, quindi? Come potrei in qualche modo sapere questo per pensare anche a lanciare un attacco per causare una nuova stretta di mano e da loro cercare di prevedere il nonce casuale usato e quindi sconfiggere la crittografia?

Se la risposta è "non puoi" come penso, perché allora è importante? Questo non sarebbe il primo attacco che chiunque proverebbe a meno che non sappiano che è stata usata una fonte di bassa entropia come loro conoscevano nell'evento Hacker News.

Inoltre sentiti libero di modificare il mio titolo se riesci a trovare un titolo migliore lol.

    
posta Freedo 23.07.2015 - 07:16
fonte

1 risposta

6

L'entropia definirà fondamentalmente il numero massimo di stati diversi che il generatore di numeri casuali può avere in un dato momento (maggiori informazioni sull'argomento può essere trovato qui ). Maggiore è l'entropia, maggiori possibilità ci sono.

Il problema principale con bassa entropia è che il generatore di numeri casuali avrà meno stati diversi possibili da passare, quindi inizierà a ripetersi.

Il modo principale per rilevare tale problema è provare a rilevare tale ripetizione. Un problema comune, ad esempio, può influire sull'ID di sessione: un utente malintenzionato può richiedere un sacco di ID di sessione dal server (o nonce dall'AP nel caso dell'accesso WiFi - qualcuno ha parlato di WEP?) E analizzare se il server può essere indotto a generare lo stesso ID due volte. Se un altro difetto lo consente, può anche causare diversi riavvii rapidi dell'applicazione per analizzare il primo ID generato.

Un esempio storico molto buono di entropia riguarda Debian (e il suo derivato numeroso). Durante due anni, hanno rotto il generatore di numeri casuali Open-SSL limitando il comando ssh-keygen (utilizzato tra l'altro per generare chiavi utilizzate per autenticare le persone sui server e autenticare il server stesso per evitare gli attacchi Man-in-the-Middle) a 32 767 chiavi diverse. Di conseguenza:

  • Un server interessato da questo problema potrebbe essere immediatamente identificato poiché presenterà la parte pubblica di una di queste chiavi vulnerabili per autenticarsi: il par privato noto all'attaccante diventa disponibile una vasta gamma di attacchi,
  • Se un utente utilizza tale chiave vulnerabile per autenticarsi (il server stesso non deve essere vulnerabile), un utente malintenzionato potrebbe accedere al proprio account provando ogni chiave del set che dovrebbe essere relativamente veloce.

Come ultima parola, devi non fare affidamento sul fatto che l'entropia bassa "assomiglia" ad una buona entropia e che non sai ancora un modo per rilevarla. Questa è chiamata sicurezza attraverso l'oscurità e non porta alcuna buona sicurezza. In effetti, il fatto che tu non sappia in questo modo non significa che nessun altro faccia, e se un singolo attaccante fa le conseguenze potrebbe essere catastrofico (suppongo che le persone WEP inizialmente considerato il loro sistema sicuro ...).

Per i tuoi dubbi sull'entropia della VM, potresti essere interessato in questa discussione . Fondamentalmente, una correzione semplice ma efficiente consiste nel " seminare ogni VM con un seme ottenuto da qualche altra fonte casuale altrove, questo è facile come scrivere un file in /dev/random " (citato dalla risposta di Thomas Pornin ).

    
risposta data 23.07.2015 - 11:23
fonte

Leggi altre domande sui tag