È questo il flusso corretto dell'attacco KRACK?

Question

È questo il flusso corretto dell'attacco KRACK?

#1 da (2 voti)

4

Non sono un esperto di crittografia quindi ti prego di perdonare questa domanda di base. Sto cercando di capire come avviene il flusso dell'attacco KRACK per capire meglio perché il protocollo di crittografia stesso può essere rotto.

Consente di iniziare dopo il passaggio 3 dell'handshake WPA a 4 vie::

Il client ha ricevuto il messaggio 3 e ha installato la crittografia chiave e invia il messaggio 4 per confermare che la crittografia è ora correttamente impostato e può iniziare a trasmettere i pacchetti.
All'insaputa del client, l'autore dell'attacco ha già memorizzato una copia di messaggio 3.
Dopo aver trasmesso alcuni pacchetti il client riceve nuovamente il messaggio 3. Ora resetta il nonce al valore iniziale e re installa il chiave di crittografia. Non si rende conto che aveva già ricevuto messaggio 3 prima e tutto andava bene.
Quindi ora il keystream si ripeterà letteralmente visto che sta usando lo stesso nonce due volte, sono corretto?

Se il flusso sopra riportato è corretto, ho un paio di domande,

Che cosa puoi fare per attaccare il protocollo di crittografia se due codici i testi sono generati dallo stesso stesso keystream?
Correggimi se sbaglio, in Linux, dove il cliente è fondamentalmente ingannato nell'installare una chiave di crittografia zero, questo significa l'accesso punto non verifica più / si preoccupa di quale chiave sta usando il client crittografare i messaggi dopo che il messaggio 4 è stato ricevuto. Voglio dire, non dovrei l'AP ha un modo di verificare se il messaggio è effettivamente crittografato usando il PMK / PTK? L'AP non dovrebbe andare come "attendere che questo messaggio non sia crittografato usando la chiave su cui ci siamo accordati"? Come funziona?

Per favore fammi sapere se la mia intuizione sull'attentato è corretta o meno.

wifi krack nonce

posta ng.newbie 22.10.2017 - 21:05

fonte

1 risposta

Leggi altre domande sui tag wifi krack nonce

Memorizzazione dei dati della carta di credito del cliente per l'elaborazione manuale successiva Il datore di lavoro vuole che io installi il certificato di origine per lavorare in remoto - problemi di privacy?

score 2 · Answer 1

Introduzione per semplificare la comprensione generale del lettore: non è necessario connettersi effettivamente alla rispettiva rete. Aspetti solo che qualcuno si connetta con una password (questo è ciò che sta per PSK, chiave precondivisa). Quando lo fa, molto prima che accedano a qualcosa, deve avvenire una stretta di mano a quattro vie. Questo controlla che la password fornita dall'utente sia corretta e stabilisce la connessione crittografata tra il router e il dispositivo dell'utente. È qui che l'attaccante interferisce - nell'handshake iniziale tra il dispositivo e il router - in un modo che consente all'aggressore di ottenere la capacità di decifrare il traffico che si scambiano tramite WiFi. Ciò significa accesso sufficiente senza nemmeno essere sulla rete. Ascoltare lo scambio di dati tra l'utente e il punto di accesso è sufficiente, mentre si restituiscono pacchetti di attacker per cambiare le cose sul dispositivo dell'utente e sul router.

L'attacco di reinstallazione della chiave funziona esattamente perché le ritrasmissioni del messaggio 3 sono accettate, anche quando è nello stato PTK-DONE , che è un difetto del modello. Ecco perché una reinstallazione del PTK può essere forzata. Più precisamente, il MitM viene stabilito tra client e router. Quindi le ritrasmissioni del messaggio 3 vengono attivate impedendo l'arrivo del messaggio 4. Di conseguenza, si verifica la ritrasmissione del messaggio 3, che fa sì che il router reinstalli un PTK già in uso. A sua volta, questo ripristina il nonce utilizzato dal protocollo di riservatezza dei dati. A seconda del protocollo utilizzato, questo consente ad un avversario di riprodurre, decodificare e / o falsificare i pacchetti.

Gli attacchi non violano praticamente le proprietà di sicurezza, ma evidenziano i limiti dei modelli impiegati. I modelli non specificano quando deve essere installata una chiave per l'utilizzo da parte del protocollo di riservatezza dei dati. In là si trova il problema e la correzione. Ecco perché la specifica di un protocollo dovrebbe essere sufficientemente precisa ed esplicita. Ad esempio, lo standard 802.11 è ambiguo su quali valori di riproduzione dovrebbero essere accettati. In pratica, non definisce quando deve essere installata la chiave della sessione negoziata . Di conseguenza, non c'era alcuna garanzia che una chiave di sessione sia installata una sola volta. Una definizione del modello più precisa può impedirlo.