Perché TLS 1.3 ha abbandonato AES-CBC?

Il problema qui non è tanto con CBC, ma con alternative che sono più facili da implementare in modo sicuro, senza perdere la sicurezza matematica. Infatti, AES-CBC si è rivelato essere notoriamente difficile da implementare correttamente. Ricordo che le vecchie implementazioni della sicurezza del livello di trasporto non hanno vettori di inizializzazione crittograficamente sicuri, che sono un must per la modalità CBC

Molti attacchi recenti stanno colmando attacchi oracle, come l'attacco Bleichenbacher . Questi dipendono soprattutto dalle vecchie modalità mantenute per il supporto. POODLE è una vulnerabilità di downgrade. LOGJAM sta eseguendo il downgrade di TLS a vecchie suite crittografiche di tipo export (leggere NSA-sabotate).

Per la modalità CBC, c'è l'attacco Vaudenay. Questi attacchi dipendono dal server che dice esplicitamente "padding non valido", con conseguente perdita di 1 bit di informazioni su ciascuna transazione. I messaggi di errore sono stati rimossi, ma il problema del tempo è rimasto. Il server ha utilizzato ancora più tempo prima di rispondere se il padding era valido.

In risposta sono stati costretti a escogitare la soluzione peculiare di generare una chiave fittizia e utilizzarla per la decrittografia, in modo da non riuscire in un'altra parte dell'implementazione. In ogni implementazione. Così hanno deciso di non forzare più questo sugli sviluppatori supportandolo nelle specifiche.

La crittografia è un campo molto vasto e una specialità a parte. La storia ha imparato attraverso l'esperienza scomoda, che farlo correttamente è impossibile da fare perfettamente, anche per i migliori sul campo. Ad esempio MD5, creato da Ron Rivest, co-inventore (e parte-omonimo) di RSA è stato ampiamente utilizzato, quindi interrotto nel 2013. La sua resistenza alla collisione è stata aggirata in 2 ^ 18 volte, meno di un secondo su un computer desktop per gli hash a 128 bit.

CBC è una buona modalità per la crittografia se implementata correttamente. In una breve frase, ho indicato due difetti di CBC.

• CBC è solo una modalità di crittografia: fornisce riservatezza, ma non autenticità o integrità. È necessario autenticare i dati separatamente. Può essere fatto, ovviamente, e quello era l'unico modo per farlo prima di TLS 1.2. Ma è difficile ottenere la giusta , che Ecco perché sono consigliate le modalità di crittografia autenticate . TLS 1.3 spinge GCM anziché CBC + HMAC.
• CBC è difficile da implementare correttamente. C'è il problema di come combinarlo con un MAC che ho già menzionato. Un altro problema è non divulgare informazioni tramite errori di riempimento . La IV deve essere davvero casuale; un IV che è influenzato da un avversario non è sicuro ed è almeno un BESTIA .

Se è così difficile da implementare correttamente, è meglio non permetterlo dal protocollo. Il design della crittografia si sta lentamente spostando dall'avere pochi primitivi ben studiati e flessibili ad avere alcuni primitivi robusti e ben studiati, perché in pratica il problema è meno che le persone non possono fare quello che vogliono, ma più che fanno cose che funzionano nel caso nominale ma cadono agli attacchi.

"Perché" è sempre difficile rispondere senza speculazioni. Nel caso della crittografia, le nostre migliori guide al futuro sono attacchi del passato. In questo caso particolare, la semplice presenza dell'implementazione di CBC imperfetta ha contribuito all'attacco di POODLE.

Ora possiamo pensare che tutti sappiano che dovrebbero testare i loro schemi di byte di riempimento, ma questa è solo un'ipotesi. Purtroppo, troppe persone interrompono i test una volta ottenuti i buoni risultati che si aspettano, senza assicurarsi che non vi siano effetti collaterali nei loro avanzi.

Ora, considera il costo di implementazione di TLS 1.3. Scrivere il codice è facile. Ma gli sviluppatori dovranno testare un incubo combinatorio di versioni, algoritmi, scambi di chiavi, ecc. E sappiamo che gli aggressori hanno spesso sfruttato i protocolli combinando elementi in modi inaspettati e nuovi. Tutto ciò che possono buttare fuori dalla suite lo fa studiare e testarlo più facilmente.

La CBC era davvero da incolpare o ha semplicemente portato a un percorso in cui un errore imprevisto ha creato una vulnerabilità? La risposta è se questo è un percorso di cui non abbiamo bisogno, forse è meglio chiuderlo interamente, riducendo la superficie di attacco.

Credo che AES-CBC sia ancora valido, purché tu lo usi correttamente . Poiché TLS utilizza mac-then-encrypt, è un campo pericoloso che consente più vulnerabilità. Le attuali implementazioni TLS contengono più hack per implementarlo (si spera) in modo sicuro. Ad esempio, quando un peer vede un riempimento non valido, distrugge solo alcuni dati (probabilmente tramite xor) per interrompere il controllo MAC un po 'più tardi. L'intero processo deve richiedere la stessa quantità di tempo indipendentemente dal tipo di errore (riempimento difettoso o errore MAC) e posizione di errore per non perdere alcuna informazione nei tempi.

La rimozione di CBC è un modo come risolverlo per la nuova versione del protocollo. Usare encrypt-then-mac sarebbe un altro modo, ma questo AFAIK cambierebbe le strutture di TLS, il che potrebbe causare difficoltà di implementazione, immagino. Cambiare le strutture del protocollo potrebbe essere doloroso nel codice che supporta più versioni TLS. Dato che ci sono altre buone modalità, è probabilmente più facile passare a loro che modificare le strutture del protocollo.