Pourquoi TLS 1.3 a-t-il abandonné AES-CBC?
Je regardais cette vidéo sur TLS 1.3: " Déploiement de TLS 1.3: le grand, le bon et le mauvais (33c3) " et j'ai été quelque peu surpris de voir cela dans leurs efforts pour fournir
"moins, de meilleurs choix"
ils ont abandonné AES-CBC comme mode de chiffrement par bloc pris en charge.
La vidéo répertorie un certain nombre d'attaques (Lucky13, POODLE et autres) qui, à mon avis, semblent être des problèmes de mise en œuvre. Je comprends qu'il est préférable d'avoir un mode qui n'encourage pas de tels problèmes d'implémentation, mais était-ce tout ce qu'il a fallu pour déprécier tout ce mode de chiffrement?
Bien que ce livre soit quelque peu daté (2010), Cryptography Engineering il recommande AES-CBC en utilisant une IV générée aléatoirement comme la meilleure option.
Le problème ici n'est pas tellement avec CBC, mais avec des alternatives plus faciles à implémenter en toute sécurité, sans perdre la sécurité mathématique.En fait, AES-CBC s'est avéré notoirement difficile à implémenter correctement. Je rappelle que les anciennes implémentations de la sécurité de la couche de transport n'ont pas de vecteurs d'initialisation sécurisés cryptographiquement, qui sont indispensables pour le mode CBC
De nombreuses attaques récentes complètent les attaques Oracle, comme l'attaque de Bleichenbacher . Ceux-ci dépendent notamment des anciens modes conservés pour le support. POODLE est une vulnérabilité de rétrogradation. LOGJAM rétrograde TLS en anciennes suites de chiffrement de qualité export (lire NSA sabotées).
Pour le mode CBC, il y a l'attaque de Vaudenay. Ces attaques dépendent du fait que le serveur dit explicitement "remplissage non valide", ce qui fait fuir 1 bit d'informations sur chaque transaction. Les messages d'erreur ont été supprimés, mais le problème de synchronisation est resté. Le serveur utilisait encore plus de temps avant de répondre si le remplissage était valide.
En réponse, ils ont été contraints de trouver la solution de contournement particulière de générer une clé factice et de l'utiliser pour le déchiffrement afin qu'elle échoue dans une autre partie de la mise en œuvre. Dans chaque mise en œuvre. Ils ont donc décidé de ne plus imposer cela aux développeurs en le soutenant dans les spécifications.
La cryptographie est un domaine très vaste et une spécialité à part entière. L'histoire a appris par une expérience inconfortable que le faire parfaitement n'est presque jamais garanti, même pour les meilleurs du domaine. Par exemple, MD5, créé par Ron Rivest, co-inventeur (et partiellement homonyme) de RSA a été largement utilisé, puis cassé en 2013. Sa résistance aux collisions a été contournée en 2 ^ 18 fois, moins d'une seconde sur un ordinateur de bureau pour des hachages 128 bits.
CBC est un bon mode de cryptage s'il est correctement mis en œuvre. En une courte phrase, j'ai souligné deux défauts de la SRC.
- CBC est un mode de cryptage uniquement: il assure la confidentialité, mais pas l'authenticité ni l'intégrité. Vous devez authentifier les données séparément. Cela peut être fait, bien sûr, et c'était la seule façon de le faire avant TLS 1.2. Mais il est difficile de bien faire les choses , c'est pourquoi modes de cryptage authentifiés sont recommandés. TLS 1.3 pousse GCM au lieu de CBC + HMAC.
- CBC est difficile à mettre en œuvre correctement. Il y a la question de savoir comment le combiner avec un MAC que j'ai déjà mentionné. Un autre problème est de pas de fuite d'informations par des erreurs de remplissage . Le IV doit vraiment être aléatoire; un IV qui est influencé par un adversaire n'est pas sûr et est au moins une BÊTE .
S'il est si difficile à implémenter correctement, il est préférable de ne pas le permettre par le protocole. La conception de la cryptographie évolue lentement, passant de quelques primitives flexibles bien étudiées à quelques primitives robustes bien étudiées, car en pratique le problème est moins que les gens ne peuvent pas faire ce qu'ils veulent, mais plus qu'ils font des choses qui fonctionnent dans le cas nominal mais tombent dans les attaques.
Fondamentalement, Lucky13 s'est produit , et les résultats étaient très mauvais: Amazon s2n pensait qu'ils l'avaient corrigé, mais il s'est avéré que non . OpenSSL a introduit une vulnérabilité bien pire quand ils ont essayé de le réparer . Adam Langley de Google, probablement le meilleur implémenteur TLS au monde, a choisi de ne pas implémenter le correctif dans l'implémentation TLS de la bibliothèque standard Go et les gens recommandés ne prennent pas en charge les suites de chiffrement CBC s'ils sont inquiets .
L'implémentation correcte des ciphersuites TLS CBC est beaucoup trop difficile .
Les implémentations considérées comme entièrement corrigées et sécurisées sont découvertes non sécurisées à mesure que les variations de l'attaque s'améliorent .
Les gens savaient qu'il devait y avoir plus de problèmes que ceux énumérés ci-dessus, parce que l'histoire nous a appris que chaque fois qu'une personne pense à une nouvelle chose stupide qu'un mauvais implémenteur TLS pourrait mal faire (comme répéter les nonces ou vérifier un seul octet du MAC) et écrit un scanner qui peut vérifier cette erreur à grande échelle, ils trouvent inévitablement certaines implémentations qui le font mal et parviennent pourtant à être déployées en production, souvent dans les sociétés Fortune 500.
Cet article non encore publié parle de certains des derniers tours: https://github.com/RUB-NDS/TLS-Padding-Oracles
Personne qui connaît la qualification de la mise en œuvre de TLS par les petits acteurs (par exemple cavium, citrix, F5, wolfSSL et mbedTLS) ne peut pas dire que vous pouvez compter sur eux pour le faire correctement. Il existe une alternative plus performante et plus facile à implémenter correctement, donc la bonne chose à faire est de supprimer le support.
"Pourquoi" est toujours difficile de répondre sans spéculation. Dans le cas de la cryptographie, nos meilleurs guides pour l'avenir sont les attaques du passé. Dans ce cas particulier, la simple présence de l'implémentation défectueuse de CBC a contribué à l'attaque POODLE.
Nous pouvons maintenant penser que tout le monde sait qu'ils devraient tester leurs schémas d'octets de remplissage, mais ce n'est qu'une hypothèse. Malheureusement, trop de gens arrêtent les tests une fois qu'ils obtiennent les bons résultats attendus, sans s'assurer qu'il n'y a pas d'effets secondaires dans leurs restes.
Maintenant, considérez le coût de l'implémentation de TLS 1.3. L'écriture du code est facile. Mais les développeurs vont ensuite devoir tester un cauchemar combinatoire de versions, d'algorithmes, d'échanges de clés, etc. Et nous savons que les attaquants ont fréquemment exploité les protocoles en combinant des éléments de manière inattendue et inédite. Tout ce qu'ils peuvent jeter hors de la suite rend l'étude et le test des ordres de grandeur plus simples.
CBC était-elle vraiment à blâmer, ou a-t-elle simplement ouvert la voie où une erreur inattendue a créé une vulnérabilité? La réponse est que si c'est un chemin dont nous n'avons pas besoin, il est peut-être préférable de le fermer entièrement, ce qui réduit la surface d'attaque.
Je crois que AES-CBC est toujours bon, à condition que vous l'utilisiez correctement. Parce que TLS utilise mac-then-encrypt, c'est un champ dangereux qui autorise plusieurs vulnérabilités. Les implémentations TLS actuelles contiennent plusieurs hacks pour l'implémenter (espérons-le) en toute sécurité. Par exemple, lorsqu'un pair voit un remplissage invalide, il détruit simplement certaines données (probablement via xor) afin de casser la vérification MAC un peu plus tard. L'ensemble du processus doit prendre le même temps quel que soit le type d'erreur (mauvais rembourrage ou erreur MAC) et la position de l'erreur afin de ne pas divulguer d'informations dans le timing.
La suppression de CBC est un moyen de le corriger pour la nouvelle version du protocole. Utiliser encrypt-then-mac serait une autre façon, mais cela changerait AFAIK les structures de TLS, ce qui pourrait causer des difficultés de mise en œuvre, je suppose. La modification des structures de protocole peut être pénible dans le code qui prend en charge plusieurs versions TLS. Puisqu'il existe d'autres bons modes, il est probablement plus facile de basculer vers eux que de changer les structures de protocole.