TLS Bicycle Attack - Quale cifra è esente da difetti da usare?

21

Recentemente un nuovo attacco ai cifrari del flusso TLS è stato sviluppato da Guido Vranken , soprannominato Bicicletta e referenziato in questo post sul blog di Websense .

Si basava su una caratteristica dei flussi di codice che dice che esiste una relazione 1: 1 tra lunghezza del testo in chiaro e lunghezza del testo cifrato (sebbene possano non essere uguali), consentendo a un utente malintenzionato di correlare alcuni dati noti dalla richiesta e scoprire la lunghezza dei campi (lunghezza della password, ad esempio). Se sai che l'utente ha una passphrase da 8 caratteri, taglierai molto lavoro alla bruteforcing, creando un dizionario che ti farà entrare dopo qualche ora.

La spiegazione completa è contenuta nel PDF ospitato nel primo post del blog collegato sopra, per coloro che vogliono capire come funziona davvero.

Fondamentalmente influisce su tutti i codici di flusso, notoriamente Galois Counter Mode (GCM), utilizzato principalmente con TLS 1.2 per far parte delle suite di crittografia AEAD. Una rapida ricerca degli altri cifrari AEAD mostra che sono anche cifrari in streaming, quindi anche vulnerabili a questo problema. O non sono tutti interessati?

Quindi la domanda è: quale cifra può essere utilizzata? I cifrari a blocchi non sono influenzati da questo particolare problema, ma la maggior parte di essi ha problemi propri, rendendo questa una questione di "scegli il tuo veleno" invece di portare l'antidoto. Qualcuno qui sa di un codice noto (consigliato dal NIST) che potrebbe essere utilizzato con TLS 1.2 che non porta i suoi difetti nell'equazione?

    
posta DarkLighting 07.01.2016 - 15:52
fonte

1 risposta

46

Il PDF dell'articolo inizia con:

It is usually assumed that HTTP traffic encapsulated in TLS doesn't reveal the exact sizes of its parts

Questo non è quello che avrei detto. Piuttosto, diciamo che di solito è assunto da persone che non conoscono meglio . TLS è crittografia e la crittografia è buona per nascondere il contenuto dei dati, non la lunghezza dei dati. Questo non è esattamente nuovo. Tuttavia, è vero che l'idea che TLS "nasconda tutto" è ancora diffusa (è sbagliato, è sempre stato, ma l'educazione è lenta, soprattutto quando le persone non vogliono essere educate).

Alcune persone hanno sostenuto che le suite di crittografia basate su CBC implicano un riempimento che potrebbe in qualche modo nascondere i dettagli della lunghezza dei dati crittografati, poiché la lunghezza viene riempita con un multiplo della dimensione del blocco. Questo "effetto nascondino" non vale in pratica, quindi è più ragionevole supporre che nessuna suite di crittografia ti aiuterà a nascondere la lunghezza dei dati che stai inviando.

Se vuoi davvero nascondere, per esempio, la lunghezza della password di un utente, allora devi farlo correttamente, facendo in modo che il mittente lo blocchi su una lunghezza fissa prima di inviarlo (questo può essere fatto in poche righe di Javascript ). Tuttavia, considera che la lunghezza continuerà a fuoriuscire in molti punti; notoriamente, la lunghezza influirà sul tempo di elaborazione sia sul client che sul server, e questo può essere rilevato (almeno, quel tipo di perdita del canale laterale è stata dimostrata in condizioni di laboratorio). Inoltre, quando l'utente digita la sua password, qualsiasi attaccante a portata d'orecchio può semplicemente contare i colpi e ottenere le stesse informazioni (praticamente, registrando il rumore con il suo smartphone e riproducendolo in seguito a bassa velocità - l'attaccante può anche ottenere informazioni su le lettere effettive perché emettono rumori distinti in una tastiera tipica).

Una risposta realistica potrebbe essere quella di far notare che se la perdita della lunghezza della password consente di romperla, allora questa è una password scadente, e probabilmente dovresti correggerla. La lunghezza è solo una piccola parte del problema, ovvero che le cattive password sono cattive.

    
risposta data 07.01.2016 - 16:19
fonte

Leggi altre domande sui tag