Lorsque vous entendez le mot « cryptographie », certaines personnes se souviennent de leur mot de passe WiFi, du cadenas vert à côté de l’adresse de leur site Web préféré et de la difficulté d’accéder au courrier électronique de quelqu’un d’autre. D'autres rappellent une série de vulnérabilités ces dernières années avec des abréviations révélatrices (DROWN, FREAK, POODLE...), des logos stylés et un avertissement pour mettre à jour de toute urgence votre navigateur.

La cryptographie couvre tout, mais substance en autre. Le fait est qu’il y a une frontière ténue entre le simple et le complexe. Certaines choses sont faciles à faire, mais difficiles à reconstituer, comme casser un œuf. D'autres choses sont faciles à faire mais difficiles à récupérer lorsqu'il manque une petite partie importante et cruciale : par exemple, ouvrir une porte verrouillée lorsque la « partie cruciale » est la clé. La cryptographie étudie ces situations et comment elles peuvent être utilisées en pratique.

Ces dernières années, la collection d'attaques cryptographiques s'est transformée en un zoo de logos flashy, remplis de formules tirées d'articles scientifiques, et a donné lieu à un sentiment général sombre que tout est cassé. Mais en réalité, bon nombre d’attaques reposent sur quelques principes généraux, et d’interminables pages de formules se résument souvent à des idées faciles à comprendre.

Dans cette série d’articles, nous examinerons les différents types d’attaques cryptographiques, en mettant l’accent sur les principes de base. En termes généraux et pas exactement dans cet ordre, nous aborderons les éléments suivants :

• Stratégies de base : force brute, analyse de fréquence, interpolation, déclassement et protocoles croisés.
• Vulnérabilités de marque : FREAK, CRIME, CANICHE, NOYER, Embouteillage.
• Stratégies avancées : attaques d'oracle (attaque Vodenet, attaque Kelsey) ; méthode de rencontre, attaque d'anniversaire, biais statistique (cryptanalyse différentielle, cryptanalyse intégrale, etc.).
• Attaques par canal secondaire et leurs proches, les techniques d'analyse des échecs.
• Attaques contre la cryptographie à clé publique : racine cubique, diffusion, message associé, attaque Coppersmith, algorithme Pohlig-Hellman, tamis numérique, attaque Wiener, attaque Bleichenbacher.

Cet article particulier couvre le matériel ci-dessus jusqu'à l'attaque de Kelsey.

Stratégies de base

Les attaques suivantes sont simples dans le sens où elles peuvent être presque entièrement expliquées sans trop de détails techniques. Expliquons chaque type d'attaque dans les termes les plus simples, sans entrer dans des exemples complexes ou des cas d'utilisation avancés.

Certaines de ces attaques sont devenues largement obsolètes et n’ont plus été utilisées depuis de nombreuses années. D’autres sont des anciens qui continuent régulièrement de surprendre les développeurs de cryptosystèmes sans méfiance au 21e siècle. L’ère de la cryptographie moderne peut être considérée comme ayant commencé avec l’avènement d’IBM DES, le premier chiffrement ayant résisté à toutes les attaques de cette liste.

Force brute simple

Le schéma de cryptage se compose de deux parties : 1) une fonction de cryptage qui prend un message (texte en clair) combiné à une clé, puis crée un message crypté - texte chiffré ; 2) une fonction de décryptage qui prend le texte chiffré et la clé et produit le texte en clair. Le chiffrement et le déchiffrement doivent être faciles à calculer avec la clé, et difficiles à calculer sans elle.

Supposons que nous voyons le texte chiffré et essayons de le déchiffrer sans aucune information supplémentaire (c'est ce qu'on appelle une attaque par texte chiffré uniquement). Si nous trouvons comme par magie la bonne clé, nous pouvons facilement vérifier qu'elle est bien correcte si le résultat est un message raisonnable.

Notez qu’il existe ici deux hypothèses implicites. Premièrement, nous savons comment effectuer le décryptage, c’est-à-dire comment fonctionne le cryptosystème. Il s’agit d’une hypothèse standard lorsqu’on parle de cryptographie. Cacher les détails de mise en œuvre du chiffrement aux attaquants peut sembler être une mesure de sécurité supplémentaire, mais une fois que l'attaquant a compris ces détails, cette sécurité supplémentaire est perdue de manière discrète et irréversible. C'est comme ça Principe de Kerchhoff: Le système tombant entre les mains de l'ennemi ne devrait pas causer de désagréments.

Deuxièmement, nous supposons que la clé correcte est la seule clé permettant un déchiffrement raisonnable. C'est également une hypothèse raisonnable ; il est satisfait si le texte chiffré est beaucoup plus long que la clé et est lisible. C'est généralement ce qui se passe dans le monde réel, sauf énormes touches peu pratiques ou d'autres manigances qu'il vaut mieux laisser de côté (si vous n'aimez pas que nous ayons sauté l'explication, veuillez consulter le théorème 3.8 ici).

Compte tenu de ce qui précède, une stratégie apparaît : vérifier toutes les clés possibles. C’est ce qu’on appelle la force brute, et une telle attaque est garantie de fonctionner contre tous les chiffrements pratiques, à terme. Par exemple, la force brute suffit pour pirater Chiffre de César, un chiffre ancien dont la clé est une lettre de l'alphabet, ce qui implique un peu plus de 20 clés possibles.

Malheureusement pour les cryptanalystes, augmenter la taille de la clé constitue une bonne défense contre la force brute. À mesure que la taille de la clé augmente, le nombre de clés possibles augmente de façon exponentielle. Avec les tailles de clés modernes, la simple force brute est totalement peu pratique. Pour comprendre ce que nous voulons dire, prenons le supercalculateur le plus rapide connu à la mi-2019 : Sommet d'IBM, avec des performances maximales d'environ 1017 opérations par seconde. Aujourd’hui, la longueur typique d’une clé est de 128 bits, ce qui signifie 2128 7800 combinaisons possibles. Pour parcourir toutes les clés, le supercalculateur Summit aura besoin d’un temps environ XNUMX XNUMX fois supérieur à l’âge de l’Univers.

La force brute doit-elle être considérée comme une curiosité historique ? Pas du tout : c’est un ingrédient nécessaire dans le livre de recettes de cryptanalyse. Les codes sont rarement si faibles qu'ils ne peuvent être brisés que par une attaque intelligente, sans recourir à la force à un degré ou à un autre. De nombreux hacks réussis utilisent une méthode algorithmique pour affaiblir d’abord le chiffre cible, puis effectuer une attaque par force brute.

Analyse de fréquence

La plupart des textes ne sont pas du charabia. Par exemple, dans les textes anglais, il y a de nombreuses lettres « e » et des articles « the » ; dans les fichiers binaires, il y a de nombreux octets nuls comme remplissage entre les informations. L'analyse de fréquence est toute attaque qui profite de ce fait.

L’exemple canonique d’un chiffre vulnérable à cette attaque est le chiffre de simple substitution. Dans ce chiffre, la clé est un tableau dans lequel toutes les lettres sont remplacées. Par exemple, « g » est remplacé par « h », « o » par j, donc le mot « go » devient « hj ». Ce chiffre est difficile à appliquer par force brute car il existe un grand nombre de tables de recherche possibles. Si les mathématiques vous intéressent, la longueur effective de la clé est d'environ 88 bits : c'est
. Mais l’analyse fréquentielle fait généralement le travail rapidement.

Considérons le texte chiffré suivant traité avec un simple chiffre de substitution :

XDYLY ALY UGLY XDWNKE WN DYAJYN ANF YALXD DGLAXWG XDAN ALY FLYAUX GR WN OGQL ZDWBGEGZDO

Depuis Y apparaît fréquemment, y compris à la fin de nombreux mots, nous pouvons provisoirement supposer qu'il s'agit de la lettre e:

XDeLe ALe UGLe XDWNKE WN DeAJeN ANF eALXD DGLAXWG XDAN ALe FLeAUX GR WN OGQL ZDWBGEGZDO

Couple XD répété au début de plusieurs mots. En particulier, la combinaison XDeLe suggère clairement le mot these ou there, alors continuons :

theLe ALe UGLe thWNKE WN heAJeN ANF eALth DGLAtWG thAN ALe FLeAUT GR WN OGQL ZDWBGEGZDO

Supposons en outre que L match r, A - a et ainsi de suite. Cela prendra probablement quelques essais, mais comparée à une attaque par force brute, cette attaque restaure le texte original en un rien de temps :

il y a plus de choses dans l'horatio du ciel et de la terre que n'en rêve votre philosophie

Pour certains, résoudre de tels « cryptogrammes » est un passe-temps passionnant.

L’idée de l’analyse fréquentielle est plus fondamentale qu’il n’y paraît à première vue. Et cela s’applique à des chiffrements beaucoup plus complexes. Tout au long de l'histoire, diverses conceptions de chiffrement ont tenté de contrer une telle attaque en utilisant la « substitution polyalphabétique ». Ici, pendant le processus de cryptage, la table de substitution de lettres est modifiée de manière complexe mais prévisible qui dépend de la clé. Tous ces chiffres étaient considérés comme difficiles à déchiffrer à la fois ; et pourtant, une modeste analyse de fréquence les a finalement tous vaincus.

Le chiffre polyalphabétique le plus ambitieux de l’histoire, et probablement le plus célèbre, était le chiffre Enigma de la Seconde Guerre mondiale. Il était relativement complexe par rapport à ses prédécesseurs, mais après beaucoup de travail acharné, les cryptanalystes britanniques l'ont déchiffré en utilisant l'analyse de fréquence. Bien sûr, ils ne pouvaient pas développer une attaque élégante comme celle présentée ci-dessus ; ils ont dû comparer des paires connues de texte en clair et de texte chiffré (ce qu'on appelle « l'attaque en texte clair »), incitant même les utilisateurs d'Enigma à chiffrer certains messages et à analyser le résultat (l'« attaque en texte clair choisie »). Mais cela n’a pas facilité le sort des armées ennemies vaincues et des sous-marins coulés.

Après ce triomphe, l’analyse fréquentielle a disparu de l’histoire de la cryptanalyse. À l’ère numérique moderne, les chiffres sont conçus pour fonctionner avec des bits et non des lettres. Plus important encore, ces chiffres ont été conçus avec la sombre compréhension de ce qui est devenu plus tard connu sous le nom de Loi de Schneier: N’importe qui peut créer un algorithme de cryptage qu’il ne peut pas lui-même déchiffrer. Ce n'est pas suffisant pour le système de cryptage semblait difficile : pour prouver sa valeur, il doit subir une revue de sécurité impitoyable par de nombreux cryptanalystes qui feront de leur mieux pour déchiffrer le chiffre.

Calculs préliminaires

Prenez la ville hypothétique de Precom Heights, peuplée de 200 000 habitants. Chaque maison de la ville contient en moyenne 30 000 $ d'objets de valeur, mais pas plus de 50 000 $. Le marché de la sécurité à Precom est monopolisé par ACME Industries, qui produit les légendaires serrures de porte de classe Coyote™. Selon une analyse d'experts, une serrure de classe Coyote ne peut être brisée que par une machine hypothétique très complexe, dont la création nécessite environ cinq ans et 50 000 $ d'investissement. La ville est-elle sûre ?

Très probablement non. Finalement, un criminel assez ambitieux apparaîtra. Il raisonnera ainsi : « Oui, j’engagerai des frais initiaux importants. Cinq ans d'attente et 50 000 $. Mais quand j'aurai fini, j'aurai accès à toute la richesse de cette ville. Si je joue bien mes cartes, cet investissement sera rentabilisé plusieurs fois.

Il en va de même en cryptographie. Les attaques contre un chiffre particulier sont soumises à une analyse coûts-avantages impitoyable. Si le rapport est favorable, l’attaque n’aura pas lieu. Mais les attaques qui ciblent simultanément de nombreuses victimes potentielles s’avèrent presque toujours payantes, auquel cas la meilleure pratique de conception consiste à supposer qu’elles ont commencé dès le premier jour. Nous avons essentiellement une version cryptographique de la loi de Murphy : « Tout ce qui peut réellement briser le système brisera le système. »

L’exemple le plus simple d’un système cryptographique vulnérable à une attaque par précalcul est un chiffrement sans clé constante. Ce fut le cas de Le chiffre de César, qui décale simplement chaque lettre de l'alphabet de trois lettres vers l'avant (le tableau est en boucle, donc la dernière lettre de l'alphabet est cryptée en troisième). Ici encore, le principe de Kerchhoffs entre en jeu : une fois qu’un système est piraté, il l’est pour toujours.

Le concept est simple. Même un développeur de cryptosystèmes novice reconnaîtra probablement la menace et se préparera en conséquence. Si l’on considère l’évolution de la cryptographie, de telles attaques étaient inappropriées pour la plupart des chiffrements, depuis les premières versions améliorées du chiffre de César jusqu’au déclin des chiffrements polyalphabétiques. De telles attaques ne sont réapparues qu’avec l’avènement de l’ère moderne de la cryptographie.

Ce retour est dû à deux facteurs. Premièrement, des cryptosystèmes suffisamment complexes sont finalement apparus, où la possibilité d'exploitation après piratage n'était pas évidente. Deuxièmement, la cryptographie est devenue si répandue que des millions de profanes ont décidé chaque jour où et quelles parties de la cryptographie réutiliser. Il a fallu un certain temps avant que les experts réalisent les risques et tirent la sonnette d’alarme.

Souvenez-vous de l’attaque par précalcul : à la fin de l’article, nous examinerons deux exemples réels de cryptographie où elle a joué un rôle important.

L'interpolation

Voici le célèbre détective Sherlock Holmes, effectuant une attaque par interpolation sur le malheureux Dr Watson :

J'ai tout de suite deviné que vous veniez d'Afghanistan... Ma pensée était la suivante : « Cet homme est médecin de type, mais il a une allure militaire. Donc, un médecin militaire. Il vient d'arriver des tropiques - son visage est foncé, mais ce n'est pas la teinte naturelle de sa peau, puisque ses poignets sont beaucoup plus blancs. Le visage est hagard - évidemment, il a beaucoup souffert et est tombé malade. Il a été blessé à la main gauche - il la tient immobile et un peu anormalement. Où, sous les tropiques, un médecin militaire anglais pourrait-il endurer des épreuves et être blessé ? Bien sûr, en Afghanistan. » L’ensemble de cette réflexion ne prit même pas une seconde. Alors j'ai dit que vous veniez d'Afghanistan et vous étiez surpris.

Holmes pouvait extraire très peu d’informations de chaque élément de preuve individuellement. Il ne pouvait parvenir à sa conclusion qu’en les considérant tous ensemble. Une attaque par interpolation fonctionne de la même manière en examinant les paires connues de texte clair et de texte chiffré résultant de la même clé. De chaque paire, des observations individuelles sont extraites qui permettent de tirer une conclusion générale sur la clé. Toutes ces conclusions sont vagues et semblent inutiles jusqu’à ce qu’elles atteignent soudainement une masse critique et conduisent à la seule conclusion possible : aussi incroyable soit-elle, elle doit être vraie. Après cela, soit la clé est révélée, soit le processus de décryptage devient si raffiné qu'il peut être répliqué.

Illustrons par un exemple simple le fonctionnement de l'interpolation. Disons que nous voulons lire le journal personnel de notre ennemi, Bob. Il crypte chaque numéro de son journal à l'aide d'un système cryptographique simple dont il a découvert l'existence grâce à une publicité dans le magazine "A Mock of Cryptography". Le système fonctionne comme ceci : Bob choisit deux nombres qu'il aime : и . Désormais, pour chiffrer n'importe quel numéro , il calcule . Par exemple, si Bob a choisi и , puis le numéro sera crypté comme .

Disons que le 28 décembre nous avons remarqué que Bob grattait quelque chose dans son journal. Quand il aura fini, nous le reprendrons tranquillement et regarderons la dernière entrée :

Дата: 235/520

Cher journal,

Aujourd'hui était un bon jour. À travers 64 aujourd'hui j'ai rendez-vous avec Alisa, qui vit dans un appartement 843. Je pense vraiment qu'elle pourrait l'être 26!

Puisque nous souhaitons très sérieusement suivre Bob à son rendez-vous (nous avons tous les deux 15 ans dans ce scénario), il est essentiel de connaître la date ainsi que l'adresse d'Alice. Heureusement, on remarque que le cryptosystème de Bob est vulnérable à une attaque par interpolation. Nous ne savons peut-être pas и , mais nous connaissons la date du jour, nous avons donc deux paires texte brut-texte chiffré. A savoir, nous savons que crypté dans Et - dans . Voici ce que nous allons écrire :

Depuis l'âge de 15 ans, nous connaissons déjà un système de deux équations à deux inconnues, ce qui dans cette situation suffit pour trouver и sans aucun problème. Chaque paire texte brut-texte chiffré impose une contrainte sur la clé de Bob, et les deux contraintes réunies sont suffisantes pour récupérer complètement la clé. Dans notre exemple, la réponse est и (à de sorte que 26 dans le journal correspond au mot « celui-là », c'est-à-dire « le même » - env. voie).

Les attaques par interpolation ne se limitent bien entendu pas à des exemples aussi simples. Tout cryptosystème qui se réduit à un objet mathématique bien compris et à une liste de paramètres risque d’être victime d’une attaque par interpolation : plus l’objet est compréhensible, plus le risque est élevé.

Les nouveaux arrivants se plaignent souvent que la cryptographie est « l’art de concevoir des choses aussi laides que possible ». Les attaques par interpolation sont probablement en grande partie responsables. Bob peut soit utiliser un design mathématique élégant, soit garder son rendez-vous avec Alice privé – mais hélas, vous ne pouvez généralement pas avoir les deux. Cela deviendra tout à fait clair lorsque nous aborderons le sujet de la cryptographie à clé publique.

Protocole croisé/déclassement

Dans Now You See Me (2013), un groupe d'illusionnistes tente d'escroquer le magnat de l'assurance corrompu Arthur Tressler de toute sa fortune. Pour accéder au compte bancaire d'Arthur, les illusionnistes doivent soit fournir son nom d'utilisateur et son mot de passe, soit le forcer à se présenter en personne à la banque et à participer au stratagème.

Les deux options sont très difficiles ; Les gars sont habitués à se produire sur scène et à ne pas participer à des opérations de renseignement. Ils choisissent alors la troisième option possible : leur complice appelle la banque et se fait passer pour Arthur. La banque pose plusieurs questions pour vérifier l'identité, comme le nom de l'oncle et le nom du premier animal de compagnie ; nos héros en avance ils extraient facilement ces informations d'Arthur en utilisant une ingénierie sociale intelligente. À partir de ce moment, une excellente sécurité des mots de passe n’a plus d’importance.

(Selon une légende urbaine que nous avons personnellement vérifiée et vérifiée, le cryptographe Eli Beaham a rencontré un jour un caissier de banque qui a insisté pour poser une question de sécurité. Lorsque le caissier lui a demandé le nom de sa grand-mère maternelle, Beaham a commencé à dicter : « Capital X, petit y, trois... ").

C’est la même chose en cryptographie, si deux protocoles cryptographiques sont utilisés en parallèle pour protéger le même actif, et que l’un est beaucoup plus faible que l’autre. Le système résultant devient vulnérable à une attaque inter-protocoles, où un protocole le plus faible est attaqué afin d'obtenir le prix sans toucher au plus fort.

Dans certains cas complexes, il ne suffit pas de contacter simplement le serveur en utilisant un protocole plus faible, mais nécessite la participation involontaire d'un client légitime. Cela peut être organisé à l’aide de ce que l’on appelle l’attaque par rétrogradation. Pour comprendre cette attaque, supposons que nos illusionnistes ont une tâche plus difficile que dans le film. Supposons qu'un employé de banque (caissier) et Arthur soient confrontés à des circonstances imprévues, aboutissant au dialogue suivant :

Cambrioleur: Bonjour? C'est Arthur Tressler. Je souhaite réinitialiser mon mot de passe.

La caissière: Super. Veuillez jeter un œil à votre livre de codes secrets personnel, page 28, mot 3. Tous les messages suivants seront cryptés en utilisant ce mot spécifique comme clé. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Cambrioleur: Hé, hé, attends, attends. Est-ce vraiment nécessaire ? On ne peut pas parler comme des gens normaux ?

La caissière: Je ne recommande pas de faire cela.

Cambrioleur: C'est juste que... écoute, j'ai passé une mauvaise journée, d'accord ? Je suis un client VIP et je ne suis pas d'humeur à fouiller dans ces stupides livres de codes.

La caissière: Bien. Si vous insistez, M. Tressler. Que veux-tu?

Cambrioleur: S'il vous plaît, j'aimerais donner tout mon argent au Fonds national d'aide aux victimes Arthur Tressler.

(Pause).

La caissière: Est-ce clair maintenant. Veuillez fournir votre code PIN pour les transactions importantes.

Cambrioleur: Mon quoi?

La caissière: À votre demande personnelle, les transactions de cette taille nécessitent un code PIN pour les transactions importantes. Ce code vous a été remis lors de l'ouverture de votre compte.

Cambrioleur:... Je l'ai perdu. Est-ce vraiment nécessaire ? Tu ne peux pas simplement approuver l'accord ?

La caissière: Non. Je suis désolé, M. Tressler. Encore une fois, c'est la mesure de sécurité que vous avez demandée. Si vous le souhaitez, nous pouvons envoyer un nouveau code PIN sur votre boîte mail.

Nos héros reportent l'opération. Ils écoutent plusieurs des transactions importantes de Tressler, dans l'espoir d'entendre le code PIN ; mais à chaque fois, la conversation se transforme en charabia codé avant que quelque chose d'intéressant ne soit dit. Finalement, un beau jour, le plan est mis à exécution. Ils attendent patiemment le moment où Tressler doit effectuer une transaction importante par téléphone, il téléphone, et puis...

Tressler : Bonjour. Je souhaite effectuer une transaction à distance, s'il vous plaît.

La caissière: Super. Veuillez jeter un œil à votre livre de codes secrets personnels, à votre page...

(Le cambrioleur appuie sur le bouton ; la voix du caissier se transforme en bruit inintelligible).

La caissière: - #@$#@$#*@$$@#* sera crypté avec ce mot comme clé. AAAYRR PLRQRZ MMNJK LOJBAN…

Tressler : Désolé, je n'ai pas bien compris. Encore? Sur quelle page ? Quel mot?

La caissière: Voici la page @#$@#*$)#*#@()#@$(#@*$(#@*.

Tressler : Quoi?

La caissière: Mot numéro vingt @$#@$#%#$.

Tressler : Sérieusement! Déjà assez! Vous et votre protocole de sécurité êtes une sorte de cirque. Je sais que tu peux me parler normalement.

La caissière: Je ne recommande pas…

Tressler : Et je ne vous conseille pas de perdre mon temps. Je ne veux plus en entendre parler tant que vous n'aurez pas résolu vos problèmes de ligne téléphonique. Pouvons-nous finaliser cet accord ou non ?

La caissière:… Oui. Bien. Que veux-tu?

Tressler : J'aimerais transférer 20 000 $ à Lord Business Investments, numéro de compte...

La caissière: Une minute s'il vous plait. C'est une grosse affaire. Veuillez fournir votre code PIN pour les transactions importantes.

Tressler : Quoi? Ah, exactement. 1234.

Voici une attaque vers le bas. Le protocole le plus faible « parlez simplement directement » a été envisagé comme option en cas d'urgence. Et pourtant nous y sommes.

Vous vous demandez peut-être qui, sensé, concevrait un véritable système de « coffre-fort jusqu’à demande contraire » comme celui décrit ci-dessus. Mais tout comme une banque fictive prend des risques pour fidéliser des clients qui n'aiment pas la cryptographie, les systèmes en général gravitent souvent vers des exigences indifférentes, voire carrément hostiles à la sécurité.

C'est exactement ce qui s'est passé avec le protocole SSLv2 en 1995. Le gouvernement américain commence depuis longtemps à considérer la cryptographie comme une arme qu’il vaut mieux garder à l’écart des ennemis étrangers et nationaux. Des morceaux de code ont été approuvés individuellement pour être exportés depuis les États-Unis, souvent à la condition que l'algorithme soit délibérément affaibli. Netscape, le développeur du navigateur le plus populaire, Netscape Navigator, a obtenu l'autorisation d'utiliser SSLv2 uniquement avec la clé RSA de 512 bits, intrinsèquement vulnérable (et de 40 bits pour RC4).

À la fin du millénaire, les règles s’étaient assouplies et l’accès au cryptage moderne était devenu largement disponible. Cependant, les clients et les serveurs prennent en charge depuis des années une cryptographie « d'exportation » affaiblie en raison de la même inertie qui maintient la prise en charge de tout système existant. Les clients pensaient qu'ils pourraient rencontrer un serveur qui ne prendrait en charge rien d'autre. Les serveurs ont fait de même. Bien entendu, le protocole SSL stipule que les clients et les serveurs ne doivent jamais utiliser un protocole faible lorsqu'un meilleur est disponible. Mais le même principe s’appliquait à Tressler et à sa banque.

Cette théorie s'est retrouvée dans deux attaques très médiatisées qui ont ébranlé la sécurité du protocole SSL en 2015, toutes deux découvertes par des chercheurs de Microsoft et INRIA. Tout d’abord, les détails de l’attaque FREAK ont été révélés en février, suivis trois mois plus tard par une autre attaque similaire appelée Logjam, dont nous parlerons plus en détail lorsque nous passerons aux attaques contre la cryptographie à clé publique.

La vulnérabilité FREAK (également connu sous le nom de « Smack TLS ») est apparu lorsque les chercheurs ont analysé les implémentations client/serveur TLS et ont découvert un curieux bug. Dans ces implémentations, si le client ne demande même pas d'utiliser une cryptographie d'exportation faible, mais que le serveur répond toujours avec de telles clés, le client dit « Eh bien » et passe à une suite de chiffrement faible.

À l’époque, la cryptographie d’exportation était largement considérée comme obsolète et interdite. L’attaque a donc été un choc total et a touché de nombreux domaines importants, notamment la Maison Blanche, l’IRS et les sites de la NSA. Pire encore, il s'avère que de nombreux serveurs vulnérables optimisaient les performances en réutilisant les mêmes clés plutôt que d'en générer de nouvelles pour chaque session. Cela a permis, après déclassement du protocole, de réaliser une attaque de pré-calcul : cracker une clé restait relativement coûteux (100 $ et 12 heures au moment de la publication), mais le coût pratique de l'attaque de la connexion était considérablement réduit. Il suffit de sélectionner une fois la clé du serveur et de déchiffrer le cryptage de toutes les connexions ultérieures à partir de ce moment.

Et avant de continuer, il y a une attaque avancée qui doit être mentionnée...

Attaque d'Oracle

Moxie Marlinspike mieux connu comme le père de l'application de messagerie cryptographique multiplateforme Signal ; mais nous aimons personnellement l'une de ses innovations les moins connues - principe de la catastrophe cryptographique (Principe de la catastrophe cryptographique). Pour paraphraser légèrement, nous pouvons dire ceci : « Si le protocole fonctionne tout effectue une opération cryptographique sur un message provenant d'une source potentiellement malveillante et se comporte différemment en fonction du résultat, il est voué à l'échec." Ou sous une forme plus précise: "Ne prenez pas d'informations de l'ennemi pour les traiter, et si vous devez le faire, au moins ne montrez pas le résultat."

Laissons de côté les débordements de tampon, les injections de commandes, etc. ; ils dépassent le cadre de cette discussion. La violation du « principe catastrophique » entraîne de graves piratages cryptographiques car le protocole se comporte exactement comme prévu.

À titre d'exemple, prenons une conception fictive avec un chiffre de substitution vulnérable, puis démontrons une attaque possible. Bien que nous ayons déjà assisté à une attaque contre un chiffre de substitution utilisant l’analyse de fréquence, il ne s’agit pas simplement d’une « autre façon de déchiffrer le même chiffre ». Au contraire, les attaques oracle sont une invention beaucoup plus moderne, applicable à de nombreuses situations où l’analyse de fréquence échoue, et nous en verrons une démonstration dans la section suivante. Ici, le chiffre simple est choisi uniquement pour rendre l'exemple plus clair.

Ainsi, Alice et Bob communiquent en utilisant un simple chiffre de substitution utilisant une clé connue d'eux seuls. Ils sont très stricts sur la longueur des messages : ils comportent exactement 20 caractères. Ils ont donc convenu que si quelqu'un souhaitait envoyer un message plus court, il devait ajouter un texte factice à la fin du message pour qu'il contienne exactement 20 caractères. Après quelques discussions, ils ont décidé qu’ils n’accepteraient que les textes factices suivants : a, bb, ccc, dddd etc. Ainsi, un texte factice de n'importe quelle longueur requise est connu.

Lorsqu'Alice ou Bob reçoivent un message, ils vérifient d'abord que le message a la bonne longueur (20 caractères) et que le suffixe est le bon texte factice. Si ce n'est pas le cas, ils répondent avec un message d'erreur approprié. Si la longueur du texte et le texte factice sont corrects, le destinataire lit le message lui-même et envoie une réponse cryptée.

Lors de l'attaque, l'attaquant se fait passer pour Bob et envoie de faux messages à Alice. Les messages sont totalement absurdes : l’attaquant n’a pas la clé et ne peut donc pas falsifier un message significatif. Mais comme le protocole viole le principe catastrophique, un attaquant peut toujours piéger Alice et lui faire révéler les informations clés, comme indiqué ci-dessous.

Cambrioleur: PREWF ZHJKL MMMN. LA

Alice: Texte factice invalide.

Cambrioleur: PREWF ZHJKL MMMN. LB

Alice: Texte factice invalide.

Cambrioleur: PREWF ZHJKL MMMN. LC

Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Le cambrioleur n'a aucune idée de ce qu'Alice vient de dire, mais remarque que le symbole C doit correspondre a, puisqu'Alice a accepté le faux texte.

Cambrioleur: REWF ZHJKL MMMN. LAA

Alice: Texte factice invalide.

Cambrioleur: REWF ZHJKL MMMN. LBB

Alice: Texte factice invalide.

Après plusieurs tentatives...

Cambrioleur: REWF ZHJKL MMMN. LGG

Alice: Texte factice invalide.

Cambrioleur: REWF ZHJKL MMMN. LHH

Alice: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Encore une fois, l'attaquant n'a aucune idée de ce qu'Alice vient de dire, mais note que H doit correspondre à b puisque Alice a accepté le faux texte.

Et ainsi de suite jusqu'à ce que l'attaquant connaisse la signification de chaque caractère.

À première vue, la méthode ressemble à une attaque en clair choisie. En fin de compte, l'attaquant sélectionne les textes chiffrés et le serveur les traite docilement. La principale différence qui rend ces attaques viables dans le monde réel est que l’attaquant n’a pas besoin d’accéder à la transcription réelle : une réponse du serveur, même aussi anodine que « Texte factice invalide », est suffisante.

Bien que cette attaque particulière soit instructive, ne vous attardez pas trop sur les spécificités du schéma de « texte factice », le système de chiffrement spécifique utilisé ou la séquence exacte des messages envoyés par l'attaquant. L'idée de base est de savoir comment Alice réagit différemment en fonction des propriétés du texte en clair, et ce, sans vérifier que le texte chiffré correspondant provient bien d'une partie de confiance. Ainsi, Alice permet à l'attaquant d'extraire des informations secrètes de ses réponses.

Il y a beaucoup de choses qui peuvent être changées dans ce scénario. Les symboles auxquels Alice réagit, ou la différence même dans son comportement, ou encore le cryptosystème utilisé. Mais le principe restera le même, et l’attaque dans son ensemble restera viable sous une forme ou une autre. La mise en œuvre de base de cette attaque a permis de découvrir plusieurs bugs de sécurité, que nous examinerons sous peu ; mais il y a d’abord quelques leçons théoriques à tirer. Comment utiliser ce « script Alice » fictif dans une attaque qui peut fonctionner sur un véritable chiffre moderne ? Est-ce possible, même en théorie ?

En 1998, le cryptographe suisse Daniel Bleichenbacher répondait à cette question par l’affirmative. Il a démontré une attaque Oracle contre le système cryptographique à clé publique largement utilisé RSA, en utilisant un schéma de message spécifique. Dans certaines implémentations RSA, le serveur répond avec différents messages d'erreur selon que le texte en clair correspond ou non au schéma ; c'était suffisant pour mener l'attaque.

Quatre ans plus tard, en 2002, le cryptographe français Serge Vaudenay a démontré une attaque oracle presque identique à celle décrite dans le scénario d'Alice ci-dessus - sauf qu'au lieu d'un chiffre fictif, il a brisé toute une classe respectable de chiffrements modernes que les gens utilisent réellement. En particulier, l'attaque de Vaudenay cible les chiffrements à taille d'entrée fixe (« chiffrements par blocs ») lorsqu'ils sont utilisés dans ce que l'on appelle le « mode de chiffrement CBC » et avec un certain schéma de remplissage populaire, fondamentalement équivalent à celui du scénario d'Alice.

Toujours en 2002, le cryptographe américain John Kelsey - co-auteur Deux fois — a proposé diverses attaques Oracle sur des systèmes qui compressent les messages puis les chiffrent. La plus notable d’entre elles était une attaque qui tirait parti du fait qu’il est souvent possible de déduire la longueur originale du texte en clair à partir de la longueur du texte chiffré. En théorie, cela permet une attaque Oracle qui récupère des parties du texte brut d'origine.

Nous fournissons ci-dessous une description plus détaillée des attaques Vaudenay et Kelsey (nous donnerons une description plus détaillée de l'attaque Bleichenbacher lorsque nous passerons aux attaques contre la cryptographie à clé publique). Malgré tous nos efforts, le texte devient quelque peu technique ; donc si ce qui précède vous suffit, sautez les deux sections suivantes.

L'attaque de Vodene

Pour comprendre l’attaque Vaudenay, il faut d’abord parler un peu plus des chiffrements par blocs et des modes de chiffrement. Un « chiffrement par bloc » est, comme mentionné, un chiffrement qui prend une clé et une entrée d'une certaine longueur fixe (« longueur de bloc ») et produit un bloc crypté de la même longueur. Les chiffrements par blocs sont largement utilisés et considérés comme relativement sécurisés. Le DES, désormais retiré, considéré comme le premier chiffrement moderne, était un chiffrement par blocs. Comme mentionné ci-dessus, il en va de même pour l’AES, qui est largement utilisé aujourd’hui.

Malheureusement, les chiffrements par blocs présentent une faiblesse flagrante. La taille typique d'un bloc est de 128 bits, soit 16 caractères. De toute évidence, la cryptographie moderne nécessite de travailler avec des données d’entrée plus volumineuses, et c’est là que les modes de chiffrement entrent en jeu. Le mode de chiffrement est essentiellement un hack : c'est un moyen d'appliquer d'une manière ou d'une autre un chiffrement par bloc qui n'accepte qu'une entrée d'une certaine taille à une entrée d'une longueur arbitraire.

L'attaque de Vodene se concentre sur le mode de fonctionnement populaire CBC (Cipher Block Chaining). L’attaque traite le chiffrement par bloc sous-jacent comme une boîte noire magique et imprenable et contourne complètement sa sécurité.

Voici un schéma qui montre le fonctionnement du mode CBC :

Le plus encerclé signifie l’opération XOR (OU exclusif). Par exemple, le deuxième bloc de texte chiffré est reçu :

1. En effectuant une opération XOR sur le deuxième bloc de texte en clair avec le premier bloc de texte chiffré.
2. Chiffrer le bloc résultant avec un chiffrement par bloc à l'aide d'une clé.

Étant donné que CBC fait un usage intensif de l'opération XOR binaire, prenons un moment pour rappeler certaines de ses propriétés :

• Idempotence :
• Commutativité:
• Associativité :
• Auto-réversibilité :
• Taille d'octet : octet n de = (octet n de ) (octet n de )

Généralement, ces propriétés impliquent que si nous avons une équation impliquant des opérations XOR et une inconnue, elle peut être résolue. Par exemple, si nous savons que avec l'inconnu et célèbre и , alors nous pouvons nous appuyer sur les propriétés susmentionnées ci-dessus pour résoudre l'équation de . En appliquant XOR des deux côtés de l'équation avec , on a . Tout cela deviendra très pertinent dans un instant.

Il y a deux différences mineures et une différence majeure entre notre scénario d'Alice et l'attaque de Vaudenay. Deux mineurs :

• Dans le script, Alice s'attendait à ce que les textes en clair se terminent par les personnages. a, bb, ccc et ainsi de suite. Dans l'attaque Wodene, la victime s'attend à ce que les textes en clair se terminent N fois par le N octet (c'est-à-dire hexadécimal 01 ou 02 02, ou 03 03 03, et ainsi de suite). Il s'agit d'une différence purement esthétique.
• Dans le scénario d'Alice, il était facile de savoir si Alice avait accepté le message grâce à la réponse « Texte factice incorrect ». Dans l'attaque de Vodene, une analyse plus approfondie est nécessaire et une mise en œuvre précise du côté de la victime est importante ; mais par souci de brièveté, tenons pour acquis que cette analyse est encore possible.

Différence principale:

• Puisque nous n’utilisons pas le même système de chiffrement, la relation entre les octets du texte chiffré contrôlés par l’attaquant et les secrets (clé et texte en clair) sera évidemment différente. Par conséquent, l’attaquant devra utiliser une stratégie différente lors de la création de textes chiffrés et de l’interprétation des réponses du serveur.

Cette différence majeure constitue la dernière pièce du puzzle permettant de comprendre l'attaque de Vaudenay. Prenons donc un moment pour réfléchir au pourquoi et à la manière dont une attaque oracle contre CBC peut être organisée en premier lieu.

Supposons que nous recevions un texte chiffré CBC de 247 blocs et que nous souhaitions le déchiffrer. Nous pouvons envoyer de faux messages au serveur, tout comme nous pouvions envoyer de faux messages à Alice auparavant. Le serveur déchiffrera les messages pour nous, mais n'affichera pas le décryptage - à la place, encore une fois, comme avec Alice, le serveur ne rapportera qu'une seule information : si le texte en clair a un remplissage valide ou non.

Considérons que dans le scénario d'Alice, nous avions les relations suivantes :

$$display$$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key}) = texte{plaintext}$$display$$

Appelons cela « l'équation d'Alice ». Nous contrôlions le texte chiffré ; le serveur (Alice) a divulgué de vagues informations sur le texte brut reçu ; et cela nous a permis de déduire des informations sur le dernier facteur - la clé. Par analogie, si nous pouvons trouver une telle connexion pour le script de CBC, nous pourrons peut-être également en extraire des informations secrètes.

Heureusement, il existe réellement des relations que nous pouvons utiliser. Considérez la sortie de l'appel final pour déchiffrer un chiffrement par bloc et notez cette sortie comme . Nous désignons également des blocs de texte en clair et blocs de texte chiffré . Jetez un autre coup d’œil au diagramme CBC et remarquez ce qui se passe :

Appelons cela « l’équation CBC ».

Dans le scénario d'Alice, en surveillant le texte chiffré et la fuite de texte en clair correspondante, nous avons pu monter une attaque qui a récupéré le troisième terme de l'équation : la clé. Dans le scénario CBC, nous surveillons également le texte chiffré et observons des fuites d'informations sur le texte brut correspondant. Si l’analogie est valable, nous pouvons obtenir des informations sur .

Supposons que nous ayons vraiment restauré , et alors ? Eh bien, nous pouvons alors imprimer tout le dernier bloc de texte en clair d'un coup (), simplement en saisissant (que nous avons) et
reçu dans l’équation CBC.

Maintenant que nous sommes optimistes quant au plan global d’attaque, il est temps de peaufiner les détails. Veuillez faire attention à la manière exacte dont les informations en clair sont divulguées sur le serveur. Dans le script d'Alice, la fuite s'est produite car Alice ne répondrait avec le message correct que si $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ se terminait par la ligne a (ou bb, etc., mais les chances que ces conditions soient déclenchées par hasard étaient très faibles). Semblable à CBC, le serveur accepte le remplissage si et seulement si se termine en hexadécimal 01. Essayons donc la même astuce : envoyer de faux textes chiffrés avec nos propres fausses valeurs jusqu'à ce que le serveur accepte le remplissage.

Lorsque le serveur accepte un padding pour un de nos faux messages, cela signifie que :

Nous utilisons maintenant la propriété XOR octet-octet :

Nous connaissons les premier et troisième termes. Et nous avons déjà vu que cela permet de récupérer le terme restant - le dernier octet de :

Cela nous donne également le dernier octet du bloc final de texte en clair via l'équation CBC et la propriété octet par octet.

Nous pourrions en rester là et être convaincus d’avoir mené une attaque contre un chiffre théoriquement fort. Mais en réalité, nous pouvons faire bien plus : nous pouvons réellement récupérer tout le texte. Cela nécessite une astuce qui ne figurait pas dans le script original d'Alice et qui n'est pas requise pour l'attaque oracle, mais cela vaut quand même la peine d'être appris.

Pour le comprendre, notez d’abord que le résultat de la sortie de la valeur correcte du dernier octet est nous avons une nouvelle capacité. Désormais, lors de la falsification de textes chiffrés, nous pouvons manipuler le dernier octet du texte brut correspondant. Encore une fois, cela est lié à l'équation CBC et à la propriété octet par octet :

Puisque nous connaissons maintenant le deuxième terme, nous pouvons utiliser notre contrôle sur le premier pour contrôler le troisième. On calcule simplement :

Nous ne pouvions pas faire cela auparavant car nous n'avions pas encore le dernier octet .

Comment cela va-t-il nous aider ? Supposons que nous créions maintenant tous les textes chiffrés de telle sorte que dans les textes en clair correspondants, le dernier octet soit égal à 02. Le serveur n'accepte désormais le remplissage que si le texte en clair se termine par 02 02. Puisque nous avons corrigé le dernier octet, cela ne se produira que si l'avant-dernier octet du texte en clair est également 02. Nous continuons à envoyer de faux blocs de texte chiffré, en modifiant l'avant-dernier octet, jusqu'à ce que le serveur accepte le remplissage de l'un d'entre eux. A ce stade, nous obtenons :

Et on restaure l'avant-dernier octet tout comme le dernier a été restauré. On continue dans le même esprit : on corrige les deux derniers octets du texte clair en 03 03, nous répétons cette attaque pour le troisième octet à partir de la fin et ainsi de suite, pour finalement restaurer complètement .

Et le reste du texte ? Veuillez noter que la valeur est en fait $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Nous pouvons mettre n'importe quel autre bloc à la place , et l'attaque réussira toujours. En fait, nous pouvons demander au serveur de faire $inline$text{BLOCK_DECRYPT}$inline$ pour n'importe quelle donnée. À ce stade, la partie est terminée : nous pouvons déchiffrer n'importe quel texte chiffré (regardez à nouveau le diagramme de décryptage de CBC pour voir cela ; et notez que le IV est public).

Cette méthode particulière joue un rôle crucial dans l’attaque oracle que nous rencontrerons plus tard.

L'attaque de Kelsey

Notre sympathique John Kelsey a exposé les principes qui sous-tendent de nombreuses attaques possibles, et pas seulement les détails d'une attaque spécifique sur un chiffre spécifique. Son Article 2002 de l'année est une étude des attaques possibles sur les données compressées cryptées. Pensiez-vous que l'information selon laquelle les données avaient été compressées avant le cryptage n'était pas suffisante pour mener une attaque ? Il s'avère que c'est suffisant.

Ce résultat surprenant est dû à deux principes. Premièrement, il existe une forte corrélation entre la longueur du texte en clair et la longueur du texte chiffré ; pour de nombreux chiffres, l'égalité exacte. Deuxièmement, lorsque la compression est effectuée, il existe également une forte corrélation entre la longueur du message compressé et le degré de « bruit » du texte clair, c'est-à-dire la proportion de caractères non répétitifs (le terme technique est « haute entropie ». ).

Pour voir le principe en action, considérons deux textes en clair :

Texte brut 1 : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Texte brut 2 : ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Supposons que les deux textes bruts soient compressés puis chiffrés. Vous obtenez deux textes chiffrés résultants et devez deviner quel texte chiffré correspond à quel texte en clair :

Texte chiffré 1 : PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Texte chiffré 2 : DWKJZXYU

La réponse est claire. Parmi les textes en clair, seul le texte en clair 1 pouvait être compressé dans la maigre longueur du deuxième texte chiffré. Nous l’avons compris sans rien connaître de l’algorithme de compression, de la clé de cryptage ou même du chiffre lui-même. Comparé à la hiérarchie des attaques cryptographiques possibles, c’est un peu fou.

Kelsey souligne en outre que dans certaines circonstances inhabituelles, ce principe peut également être utilisé pour mener une attaque oracle. En particulier, il décrit comment un attaquant peut récupérer le texte clair secret s'il peut forcer le serveur à chiffrer les données du formulaire (le texte clair suivi de pendant qu'il est aux commandes et peut en quelque sorte vérifier la longueur du résultat crypté.

Encore une fois, comme pour les autres attaques Oracle, nous avons la relation :

Encore une fois, nous contrôlons un terme (), nous constatons une petite fuite d'informations sur un autre membre (texte chiffré) et essayons de récupérer le dernier (texte en clair). Malgré l’analogie, il s’agit d’une situation quelque peu inhabituelle par rapport aux autres attaques d’oracles que nous avons vues.

Pour illustrer le fonctionnement d'une telle attaque, utilisons un schéma de compression fictif que nous venons de mettre au point : TOYZIP. Il recherche les lignes de texte qui sont apparues précédemment dans le texte et les remplace par trois octets d'espace réservé qui indiquent où trouver une instance antérieure de la ligne et combien de fois elle y apparaît. Par exemple, la ligne helloworldhello peut être compressé en helloworld[00][00][05] 13 octets de long par rapport aux 15 octets d'origine.

Supposons qu'un attaquant tente de récupérer le texte brut d'un formulaire password=..., où le mot de passe lui-même est inconnu. Selon le modèle d'attaque de Kelsey, un attaquant pourrait demander au serveur de compresser puis de chiffrer les messages du formulaire (texte en clair suivi de ) où  - texte libre. Lorsque le serveur a fini de travailler, il indique la longueur du résultat. L'attaque se déroule comme ceci :

Cambrioleur: Veuillez compresser et chiffrer le texte brut sans aucun remplissage.

Serveur: Longueur du résultat 14.

Cambrioleur: Veuillez compresser et chiffrer le texte brut auquel est annexé password=a.

Serveur: Longueur du résultat 18.

Le cracker note : [original 14] + [trois octets qui ont remplacé password=] + a

Cambrioleur: Veuillez compresser et chiffrer le texte brut auquel est ajouté password=b.

Serveur: Longueur du résultat 18.

Cambrioleur: Veuillez compresser et chiffrer le texte brut auquel est ajouté password=с.

Serveur: Longueur du résultat 17.

Le cracker note : [original 14] + [trois octets qui ont remplacé password=c]. Cela suppose que le texte brut d'origine contient la chaîne password=c. Autrement dit, le mot de passe commence par une lettre c

Cambrioleur: Veuillez compresser et chiffrer le texte brut auquel est ajouté password=сa.

Serveur: Longueur du résultat 18.

Le cracker note : [original 14] + [trois octets qui ont remplacé password=с] + a

Cambrioleur: Veuillez compresser et chiffrer le texte brut auquel est ajouté password=сb.

Serveur: Longueur du résultat 18.

(… Un peu plus tard…)

Cambrioleur: Veuillez compresser et chiffrer le texte brut auquel est ajouté password=со.

Serveur: Longueur du résultat 17.

Le cracker note : [original 14] + [trois octets qui ont remplacé password=co]. En utilisant la même logique, l'attaquant conclut que le mot de passe commence par les lettres co

Et ainsi de suite jusqu'à ce que l'intégralité du mot de passe soit restaurée.

Il serait permis au lecteur de penser qu’il s’agit d’un exercice purement académique et qu’un tel scénario d’attaque ne se produirait jamais dans le monde réel. Hélas, comme nous le verrons bientôt, mieux vaut ne pas renoncer à la cryptographie.

Vulnérabilités de la marque : CRIME, POODLE, DROWN

Enfin, après avoir étudié la théorie en détail, nous pouvons voir comment ces techniques sont appliquées dans des attaques cryptographiques réelles.

CRIME

Si l'attaque vise le navigateur et le réseau de la victime, certaines seront plus faciles et d'autres plus difficiles. Par exemple, il est facile de voir le trafic de la victime : il suffit de s’asseoir avec elle dans le même café équipé du WiFi. C’est pour cette raison qu’il est généralement conseillé aux victimes potentielles (c’est-à-dire à tout le monde) d’utiliser une connexion cryptée. Il sera plus difficile, mais toujours possible, d'effectuer des requêtes HTTP au nom de la victime vers un site tiers (par exemple Google). L'attaquant doit attirer la victime vers une page Web malveillante avec un script qui effectue la demande. Le navigateur Web fournira automatiquement le cookie de session correspondant.

Cela semble incroyable. Si Bob allait evil.com, le script de ce site pourrait-il simplement demander à Google d'envoyer par courrier électronique le mot de passe de Bob à [email protected]? Eh bien, en théorie oui, mais en réalité non. Ce scénario est appelé attaque de falsification de requêtes intersites (Falsification de demande intersite, CSRF), et il était populaire vers le milieu des années 90. Aujourd'hui, si evil.com Si vous essayez cette astuce, Google (ou tout autre site Web qui se respecte) répondra généralement : « Super, mais votre jeton CSRF pour cette transaction sera… euh… три триллиона и семь. Veuillez répéter ce numéro." Les navigateurs modernes ont ce qu'on appelle une « politique de même origine » selon laquelle les scripts du site A n'ont pas accès aux informations envoyées par le site Web B. Ainsi, le script sur le site A n'a pas accès aux informations envoyées par le site Web B. evil.com peut envoyer des demandes à google.com, mais je ne peux pas lire les réponses ni finaliser la transaction.

Nous devons souligner qu’à moins que Bob n’utilise une connexion cryptée, toutes ces protections n’ont aucun sens. Un attaquant peut simplement lire le trafic de Bob et récupérer le cookie de session de Google. Avec ce cookie, il ouvrira simplement un nouvel onglet Google sans quitter son propre navigateur et se fera passer pour Bob sans rencontrer de politiques embêtantes de même origine. Mais malheureusement pour un cambrioleur, cela devient de moins en moins courant. Internet dans son ensemble a depuis longtemps déclaré la guerre aux connexions non cryptées, et le trafic sortant de Bob est probablement crypté, que cela lui plaise ou non. De plus, dès le début de la mise en œuvre du protocole, le trafic a également été rétréci avant le cryptage ; c'était une pratique courante pour réduire la latence.

C'est là que ça entre en jeu CRIME (Compression Ratio Infoleak Made Easy, simple fuite via le taux de compression). La vulnérabilité a été révélée en septembre 2012 par les chercheurs en sécurité Juliano Rizzo et Thai Duong. Nous avons déjà examiné toute la base théorique, ce qui nous permet de comprendre ce qu'ils ont fait et comment. Un attaquant pourrait forcer le navigateur de Bob à envoyer des requêtes à Google, puis à écouter les réponses sur le réseau local sous une forme compressée et cryptée. Nous avons donc :

Ici, l'attaquant contrôle la requête et a accès au renifleur de trafic, y compris la taille du paquet. Le scénario fictif de Kelsey a pris vie.

Comprenant cette théorie, les auteurs de CRIME ont créé un exploit capable de voler des cookies de session pour un large éventail de sites, notamment Gmail, Twitter, Dropbox et Github. La vulnérabilité a affecté la plupart des navigateurs Web modernes, ce qui a entraîné la publication de correctifs qui ont enterré silencieusement la fonctionnalité de compression dans SSL afin qu'elle ne soit pas utilisée du tout. Le seul à être protégé contre cette vulnérabilité était le vénérable Internet Explorer, qui n’a jamais utilisé la compression SSL.

POODLE

En octobre 2014, l'équipe de sécurité de Google a fait des vagues au sein de la communauté de la sécurité. Ils ont pu exploiter une vulnérabilité du protocole SSL qui avait été corrigée il y a plus de dix ans.

Il s'avère que même si les serveurs exécutent le tout nouveau TLSv1.2, beaucoup ont abandonné la prise en charge de l'ancien SSLv3 pour une compatibilité ascendante avec Internet Explorer 6. Nous avons déjà parlé des attaques par rétrogradation, vous pouvez donc imaginer ce qui se passe. Un sabotage bien orchestré du protocole de prise de contact et les serveurs sont prêts à revenir au bon vieux SSLv3, annulant essentiellement les 15 dernières années de recherche en matière de sécurité.

Pour le contexte historique, voici un bref résumé de l'histoire de SSL jusqu'à la version 2 de Matthew Green:

Transport Layer Security (TLS) est le protocole de sécurité le plus important sur Internet. [..] presque toutes les transactions que vous effectuez sur Internet dépendent de TLS. [..] Mais TLS n'a pas toujours été TLS. Le protocole a commencé sa vie en Communications Netscape appelé « Secure Sockets Layer » ou SSL. La rumeur veut que la première version de SSL était si terrible que les développeurs ont collecté toutes les impressions du code et les ont enterrées dans une décharge secrète au Nouveau-Mexique. En conséquence, la première version publique de SSL est en fait version SSL2. C'est assez effrayant, et [..] c'était un produit du milieu des années 90, que les cryptographes modernes considèrent comme "âges sombres de la cryptographie" La plupart des attaques cryptographiques les plus odieuses que nous connaissons aujourd’hui n’ont pas encore été découvertes. En conséquence, les développeurs du protocole SSLv2 ont été laissés pour l’essentiel se frayer un chemin dans le noir, et ils ont été confrontés à beaucoup de monstres terribles - à leur grand regret et pour notre bénéfice, puisque les attaques sur SSLv2 ont laissé des enseignements inestimables pour la prochaine génération de protocoles.

À la suite de ces événements, en 1996, Netscape, frustré, a entièrement repensé le protocole SSL. Le résultat fut SSL version 3, qui correction de plusieurs problèmes de sécurité connus de son prédécesseur.

Heureusement pour les cambrioleurs, « quelques-uns » ne signifie pas « tous ». Dans l’ensemble, SSLv3 a fourni tous les éléments de base nécessaires pour lancer une attaque Vodene. Le protocole utilisait un chiffrement par bloc en mode CBC et un schéma de remplissage non sécurisé (cela a été corrigé dans TLS ; d'où la nécessité d'une attaque par rétrogradation). Si vous vous souvenez du schéma de remplissage dans notre description originale de l'attaque Vaudenay, le schéma SSLv3 est très similaire.

Mais malheureusement pour les cambrioleurs, « similaire » ne signifie pas « identique ». Le schéma de remplissage SSLv3 est "N octets aléatoires suivis du nombre N". Essayez, dans ces conditions, de sélectionner un bloc imaginaire de texte chiffré et suivez toutes les étapes du schéma original de Vaudene : vous constaterez que l'attaque réussit à extraire le dernier octet du bloc de texte clair correspondant, mais ne va pas plus loin. Décrypter chaque 16ème octet du texte chiffré est une excellente astuce, mais ce n'est pas une victoire.

Face à l'échec, l'équipe de Google a eu recours à un dernier recours : elle a opté pour un modèle de menace plus puissant : celui utilisé dans CRIME. En supposant que l'attaquant soit un script exécuté dans l'onglet du navigateur de la victime et qu'il puisse extraire les cookies de session, l'attaque reste impressionnante. Bien que le modèle de menace plus large soit moins réaliste, nous avons vu dans la section précédente que ce modèle particulier est réalisable.

Grâce à ces capacités d’attaque plus puissantes, l’attaque peut désormais se poursuivre. Notez que l'attaquant sait où le cookie de session chiffré apparaît dans l'en-tête et contrôle la longueur de la requête HTTP qui le précède. Il est donc capable de manipuler la requête HTTP pour que le dernier octet du cookie soit aligné avec la fin du bloc. Cet octet peut désormais être déchiffré. Vous pouvez simplement ajouter un caractère à la requête, et l'avant-dernier octet du cookie restera au même endroit et pourra être sélectionné selon la même méthode. L'attaque se poursuit de cette manière jusqu'à ce que le fichier cookie soit complètement restauré. Cela s'appelle POODLE : Padding Oracle on Downgraded Legacy Encryption.

NOYER

Comme nous l'avons mentionné, SSLv3 avait ses défauts, mais il était fondamentalement différent de son prédécesseur, puisque le SSLv2 qui fuit était un produit d'une autre époque. Là, vous pourriez interrompre le message au milieu : соглашусь на это только через мой труп transformé en соглашусь на это; le client et le serveur pourraient se rencontrer en ligne, établir un climat de confiance et échanger des secrets devant l'attaquant, qui pourrait alors facilement usurper l'identité des deux. Il y a aussi le problème de la cryptographie d’exportation, que nous avons évoqué en parlant de FREAK. Il s’agissait de Sodome et Gomorrhe cryptographiques.

En mars 2016, une équipe de chercheurs de différents domaines techniques s'est réunie et a fait une découverte surprenante : SSLv2 est toujours utilisé dans les systèmes de sécurité. Oui, les attaquants ne peuvent plus rétrograder les sessions TLS modernes vers SSLv2 depuis que cette faille a été comblée après FREAK et POODLE, mais ils peuvent toujours se connecter aux serveurs et lancer eux-mêmes des sessions SSLv2.

Vous vous demandez peut-être pourquoi nous soucions-nous de ce qu’ils font là-bas ? Ils ont une session vulnérable, mais cela ne devrait pas affecter les autres sessions ou la sécurité du serveur, n'est-ce pas ? Eh bien, pas tout à fait. Oui, c’est comme ça que ça devrait être en théorie. Mais non, car la génération de certificats SSL impose une certaine charge, ce qui fait que de nombreux serveurs utilisent les mêmes certificats et, par conséquent, les mêmes clés RSA pour les connexions TLS et SSLv2. Pour aggraver les choses, en raison d'un bogue OpenSSL, l'option « Désactiver SSLv2 » dans cette implémentation SSL populaire n'a pas réellement fonctionné.

Cela a rendu possible une attaque multi-protocoles sur TLS, appelée NOYER (Déchiffrement RSA avec eNcryption obsolète et affaibli, déchiffrement RSA avec cryptage obsolète et affaibli). Rappelez-vous que ce n’est pas la même chose qu’une attaque courte ; l'attaquant n'a pas besoin d'agir comme un « homme au milieu » et n'a pas besoin d'impliquer le client pour participer à une session non sécurisée. Les attaquants lancent simplement eux-mêmes une session SSLv2 non sécurisée avec le serveur, attaquent le protocole faible et récupèrent la clé privée RSA du serveur. Cette clé est également valable pour les connexions TLS, et à partir de ce moment, aucune sécurité TLS ne l’empêchera d’être compromise.

Mais pour le pirater, vous avez besoin d'une attaque efficace contre SSLv2, qui vous permet de récupérer non seulement un trafic spécifique, mais également la clé secrète du serveur RSA. Bien qu’il s’agisse d’une configuration complexe, les chercheurs ont pu choisir n’importe quelle vulnérabilité complètement fermée après SSLv2. Ils ont finalement trouvé une option adaptée : l’attaque de Bleichenbacher, dont nous avons parlé plus tôt et que nous expliquerons en détail dans le prochain article. SSL et TLS sont protégés contre cette attaque, mais certaines fonctionnalités aléatoires de SSL, combinées à des clés courtes dans la cryptographie de niveau export, ont rendu possible une implémentation spécifique de DROWN.

Au moment de la publication, 25 % des principaux sites Internet étaient affectés par la vulnérabilité DROWN, et l'attaque pouvait être menée avec des ressources modestes, même disponibles pour des pirates informatiques isolés et malveillants. La récupération de la clé RSA du serveur a nécessité huit heures de calcul et 440 $, et SSLv2 est passé d'obsolète à radioactif.

Attends, et Heartbleed ?

Il ne s’agit pas d’une attaque cryptographique au sens décrit ci-dessus ; Il s'agit d'un débordement de tampon.

Faisons une pause

Nous avons commencé avec quelques techniques de base : force brute, interpolation, rétrogradation, protocole croisé et précalcul. Nous avons ensuite examiné une technique avancée, peut-être la principale composante des attaques cryptographiques modernes : l’attaque oracle. Nous avons passé pas mal de temps à le comprendre - et avons compris non seulement le principe sous-jacent, mais également les détails techniques de deux implémentations spécifiques : l'attaque Vaudenay sur le mode de cryptage CBC et l'attaque Kelsey sur les protocoles de cryptage pré-compression.

En examinant les attaques par rétrogradation et par précalcul, nous avons brièvement décrit l'attaque FREAK, qui utilise les deux méthodes en faisant rétrograder les sites cibles vers des clés faibles, puis en réutilisant les mêmes clés. Pour le prochain article, nous garderons l’attaque (très similaire) Logjam, qui cible les algorithmes à clé publique.

Nous avons ensuite examiné trois autres exemples d’application de ces principes. Premièrement, CRIME et POODLE : deux attaques qui reposaient sur la capacité de l'attaquant à injecter du texte brut arbitraire à côté du texte brut cible, puis à examiner les réponses du serveur et à puis, à l'aide de la méthodologie d'attaque Oracle, exploitez ces informations éparses pour récupérer partiellement le texte en clair. CRIME a suivi la voie de l'attaque de Kelsey contre la compression SSL, tandis que POODLE a plutôt utilisé une variante de l'attaque de Vaudenay contre CBC avec le même effet.

Nous avons ensuite porté notre attention sur l'attaque cross-protocole DROWN, qui établit une connexion au serveur à l'aide de l'ancien protocole SSLv2, puis récupère les clés secrètes du serveur à l'aide de l'attaque Bleichenbacher. Nous avons ignoré les détails techniques de cette attaque pour l'instant ; comme Logjam, il faudra attendre que nous ayons une bonne compréhension des cryptosystèmes à clé publique et de leurs vulnérabilités.

Dans le prochain article, nous parlerons des attaques avancées telles que les attaques par rencontre, par cryptanalyse différentielle et par anniversaire. Faisons une incursion rapide dans les attaques par canal secondaire, puis passons à la partie amusante : les cryptosystèmes à clé publique.

Source: habr.com