Avec le mot « cryptographie », certains se souviennent de leur mot de passe WiFi, du petit cadenas vert à côté de l'adresse de leur site préféré et de la difficulté d'accéder à la messagerie d'autrui. D'autres se rappellent des vulnérabilités récentes avec des acronymes évocateurs (DROWN, FREAK, POODLE…), des logos stylés et un avertissement urgent de mettre à jour leur navigateur.

La cryptographie englobe tout cela, mais l'essence réside ailleurs. L'essentiel est la fine ligne entre le simple et le complexe. Certaines choses sont faciles à faire, mais il est difficile de revenir en arrière : par exemple, casser un œuf. D'autres choses sont faciles à réaliser, mais il est compliqué de revenir en arrière quand il manque une petite pièce décisive : par exemple, ouvrir une porte verrouillée lorsque la « pièce décisive » est la clé. La cryptographie étudie ces situations et les moyens de les utiliser pratiquement.

Au cours des dernières années, la collection d'attaques cryptographiques s'est transformée en un zoo de logos criards, remplis de formules d'articles scientifiques, et a engendré une sensation générale sombre que tout est brisé. Mais en réalité, de nombreuses attaques reposent sur quelques principes communs, et les pages infinies 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 fondamentaux. En termes généraux et pas tout à fait dans cet ordre, nous aborderons les sujets suivants :

Stratégies de base : brute force, analyse de fréquence, interpolation, réduction et protocoles croisés.
Vulnérabilités « de marque » : FREAK, CRIME, POODLE, DROWN, Logjam.
Stratégies avancées : attaques par oracle (attaque de Vodené, attaque de Kelsey) ; méthode de rencontre au milieu (meet-in-the-middle), attaque par « anniversaires », biais statistiques (analyse différentielle, analyse intégrale, etc.).
Attaques par canaux auxiliaires et leurs proches, méthodes d'analyse des défaillances.
Attaques sur la cryptographie à clé publique : racine cubique, diffusion, message lié, attaque de Coppersmith, algorithme de Pollard-Hellman, crible numérique, attaque de Wiener, attaque de Bleichenbacher.

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

Stratégies de base

Les attaques suivantes sont simples dans le sens où elles peuvent être pratiquement entièrement expliquées sans détails techniques particuliers. Nous allons aborder chaque type d'attaque dans les termes les plus simples, sans plonger dans des exemples complexes ou des cas d'utilisation étendus.

Certaines de ces attaques ont principalement perdu leur pertinence et n'ont pas été utilisées depuis de nombreuses années. D'autres, quant à elles, sont des vétérans qui continuent de guetter les développeurs de cryptosystèmes sans méfiance au XXIe siècle. On peut dire que l'ère de la cryptographie moderne a commencé avec l'apparition d'IBM DES, le premier chiffrement ayant résisté à toutes les attaques de cette liste.

Bruteforce simple

Le schéma de chiffrement se compose de deux parties : 1) une fonction de chiffrement qui prend un message (texte en clair) en association avec une clé, puis crée un message chiffré - le ciphertext ; 2) une fonction de déchiffrement qui prend le ciphertext et la clé et produit le texte en clair. Tant le chiffrement que le déchiffrement doivent être facilement calculables avec la clé - et difficiles sans elle.

Supposons que nous voyons le ciphertext et essayons de le déchiffrer sans aucune information supplémentaire (cela s'appelle une attaque "ciphertext-only"). Si par un moyen magique nous trouvons la bonne clé, nous pouvons facilement vérifier qu'elle est réellement correcte si le résultat constitue un message cohérent.

Notez qu'il y a ici deux hypothèses implicites. Tout d'abord, que nous savons comment réaliser le déchiffrement, c'est-à-dire comment fonctionne le cryptosystème. C'est une hypothèse standard lors de la discussion sur la cryptographie. Cacher les détails de mise en œuvre du chiffrement aux attaquants peut sembler être une mesure de sécurité supplémentaire, mais dès que l'attaquant découvre ces détails, cette sécurité supplémentaire est discrètement et irréversiblement perdue. Tel est le principe de Kerckhoffs: le fait de mettre le système entre les mains de l'ennemi ne doit pas causer de désagréments.

Deuxièmement, nous supposons que la bonne clé est la seule clé qui mènera à un déchiffrement sensé. C'est également une hypothèse raisonnable ; elle se vérifie lorsque le ciphertext est beaucoup plus long que la clé et est bien lisible. En général, c'est le cas dans le monde réel, à l'exception de immenses clés impraticables ou d'autres manigances qui sont mieux laissées de côté. (si vous n'aimez pas que nous ayons négligé les explications, veuillez consulter le théorème 3.8 ici).

Cela étant dit, une stratégie émerge : vérifier chaque clé possible. Cela s'appelle le brute force, et cette attaque fonctionne garantis contre tous les cryptages pratiques — en fin de compte. Par exemple, le brute force est suffisant pour déchiffrer le chiffre de César, un ancien chiffre où la clé est une lettre de l'alphabet, ce qui implique un peu plus de 20 clés possibles.

Malheureusement pour les cryptoanalystes, augmenter la taille de la clé protège bien contre le brute force. À mesure que la taille de la clé augmente, le nombre de clés possibles augmente de manière exponentielle. Avec les tailles de clés modernes, un simple brute force est complètement impraticable. Pour comprendre ce que nous voulons dire, prenons le superordinateur le plus rapide connu à la mi-2019 : Summit de IBM, avec une performance de pointe d'environ 10^17 opérations par seconde. Aujourd'hui, une longueur de clé typique est de 128 bits, ce qui signifie 2^128 combinaisons possibles. Pour tester toutes les clés, le superordinateur Summit aurait besoin d'un temps qui est environ 7800 fois supérieur à l'âge de l'univers.

Faut-il considérer le brute force comme une curiosité historique ? Pas du tout : c'est un ingrédient nécessaire dans le livre de recettes du cryptoanalyse. Il est rare de rencontrer des chiffrages si faibles qu'ils ne peuvent être déchiffrés que par une attaque intelligente, sans recourir à la force d'une manière ou d'une autre. De nombreuses réussites d’intrusion utilisent d'abord une méthode algorithmique pour affaiblir le chiffre ciblé, puis lancent le brute force.

Analyse de fréquence

La plupart des textes ne sont pas du charabia. Par exemple, dans les textes en anglais, il y a beaucoup de lettres ‘e’ et d'articles ‘the’ ; dans les fichiers binaires, il y a beaucoup de zéros comme espace entre les fragments d'information. L'analyse de fréquence est toute attaque qui utilise ce fait.

Un exemple canonique de chiffre vulnérable à cette attaque est le simple chiffre de substitution. Dans ce chiffre, la clé est un tableau remplaçant toutes les lettres. Par exemple, ‘g’ est remplacé par ‘h’, ‘o’ par ‘j’. Ainsi, le mot ‘go’ devient ‘hj’. Ce chiffre est difficile à déchiffrer par un simple brute force, car il y a beaucoup de tableaux de substitution possibles. Si cela vous intéresse, la longueur efficace de la clé est d'environ 88 bits : c'est
. Mais l'analyse de fréquence s'acquitte généralement rapidement de la tâche.

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

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

Puisque Y apparaît fréquemment, y compris à la fin de nombreux mots, nous pouvons supposer à priori que c'est la lettre e:

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

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

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

Supposons maintenant que L correspond à r, A — a et ainsi de suite. Il est probable que plusieurs essais soient nécessaires, mais par rapport à un bruteforce complet, cette attaque restaure le texte original en un temps record :

there are more things in heaven and earth horatio than are dreamt of in your philosophy

Pour certains, la résolution de telles « cryptogrammes » est un hobby fascinant.

L'idée de l'analyse de fréquence est plus fondamentale qu'elle n'en a l'air. Et elle est applicable à des chiffres beaucoup plus complexes. Tout au long de l'histoire, diverses constructions de chiffre ont tenté de résister à une telle attaque grâce à la « substitution polyalphabétique ». Ici, pendant le processus de chiffrage, la table de remplacement des lettres est modifiée de manière complexe mais prévisible, dépendant de la clé. Tous ces chiffres ont été considérés à leur époque comme difficiles à casser ; et pourtant, l'humble analyse de fréquence les a finalement tous vaincus.

Le chiffre polyalphabétique le plus ambitieux de l'histoire, et sans doute le plus célèbre, était le chiffre « Enigma » pendant la Seconde Guerre mondiale. Il était relativement complexe par rapport à ses prédécesseurs, mais après un travail acharné et prolongé, les cryptanalystes britanniques l'ont percé grâce à l'analyse de fréquence. Bien sûr, ils n'ont pas pu concevoir une attaque élégante, comme celle montrée ci-dessus ; ils ont dû comparer des paires connues de textes clairs et chiffrés (ce qu'on appelle l'« attaque basée sur des textes clairs ») et même inciter les utilisateurs d'« Enigma » à chiffrer des messages spécifiques tout en analysant le résultat (l'« attaque basée sur un texte clair choisi »). 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. Les codes de l'ère numérique moderne sont conçus pour fonctionner avec des bits, et non des lettres. Ce qui est encore plus important, c'est que ces codes ont été développés avec la sombre compréhension de ce qui est devenu connu sous le nom de loi de Schneier: tout le monde peut créer un algorithme de chiffrement qu'il ne peut pas lui-même déchiffrer. Il ne suffit pas qu'un système de chiffrement semble complexe : pour prouver sa valeur, il doit passer par un examen de sécurité impitoyable réalisé par de nombreux cryptanalystes qui feront tout leur possible pour déchiffrer le code.

Les calculs préliminaires

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

Probablement pas. Après tout, un criminel suffisamment ambitieux va apparaître. Il pensera : « Oui, j'assumerai de gros frais initiaux. Cinq ans d'attente patiente et 50 000 $. Mais à l'issue des travaux, j'aurai accès à toute la richesse de cette ville. Si je joue bien mes cartes, cet investissement sera multiplié par plusieurs ».

Il en va de même en cryptographie. Les attaques contre un code spécifique sont soumises à une analyse impitoyable des coûts et des bénéfices. Si le rapport est favorable, l'attaque n'aura pas lieu. Mais les attaques qui touchent immédiatement de nombreuses victimes potentielles sont presque toujours rentables, et dans ce cas, la meilleure pratique de conception est de supposer qu'elles ont commencé dès le premier jour. Nous avons en essence une version cryptographique de la loi de Murphy : « Tout ce qui peut réellement briser un système le brisera ».

Un exemple simple de système cryptographique vulnérable à une attaque par calculs préalables est le code avec un algorithme constant sans utilisation de clé. Cela a été le cas avec le chiffre de César, qui déplace simplement chaque lettre de l'alphabet de trois lettres vers l'avant (le tableau est enroulé, donc la dernière lettre de l'alphabet est chiffrée par la troisième). Ici, le principe de Kerckhoffs se manifeste à nouveau : une fois qu'un système est compromis, il l'est pour toujours.

Le concept est simple. Même un développeur débutant en cryptosystèmes, saura probablement reconnaître la menace et se préparer en conséquence. En regardant l'évolution de la cryptographie, de telles attaques étaient inappropriées pour la plupart des codes, depuis les premières versions améliorées du chiffre de César jusqu'à la chute des chiffres polyalphabétiques. Ces attaques ne sont revenues qu'avec l'avènement de l'ère moderne de la cryptographie.

Ce retour est dû à deux facteurs. Premièrement, enfin, des cryptosystèmes suffisamment complexes sont apparus, où la possibilité d'exploitation après une compromission n'était pas évidente. Deuxièmement, la cryptographie s'est répandue au point que des millions de non-professionnels prenaient chaque jour des décisions sur où et quelles parties de la cryptographie réutiliser. Il a fallu un certain temps avant que les experts réalisent les risques émergents et tirent la sonnette d'alarme.

Rappelez-vous l'attaque par précalculations : à la fin de l'article, nous examinerons deux exemples cryptographiques du monde réel où cela a joué un rôle important.

Interpolation

Devant vous se trouve le célèbre détective Sherlock Holmes, effectuant une attaque par interpolation sur le malheureux docteur Watson :

J'ai tout de suite deviné que vous veniez d'Afghanistan... Mon raisonnement était le suivant : « Cet homme par son type est médecin, mais sa posture est militaire. Donc, c'est un médecin militaire. Il vient juste des tropiques - son visage est basané, mais ce n'est pas la teinte naturelle de sa peau, car ses poignets sont beaucoup plus clairs. Son visage est émacié, il a visiblement beaucoup souffert et a contracté une maladie. Il a été blessé à la main gauche - il la tient immobile et un peu de manière peu naturelle. Où un médecin militaire anglais pourrait-il avoir souffert et reçu une blessure sous les tropiques ? Évidemment, en Afghanistan. » Tout ce raisonnement n'a pris qu'une seconde. Et voilà que j'ai dit que vous veniez d'Afghanistan, et vous avez été surpris.

De chaque ruche, Holmes pouvait extraire très peu d'informations. Il ne pouvait parvenir à sa conclusion qu'en les examinant toutes ensemble. Une attaque par interpolation fonctionne de manière analogue, en étudiant des paires connues de textes en clair et chiffrés, obtenues par l'application de la même clé. De chaque paire, on tire des observations individuelles qui permettent de tirer une conclusion générale sur la clé. Toutes ces déductions sont floues et semblent inutiles jusqu'à ce qu'elles atteignent soudainement une masse critique et conduisent à une 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échiffrement devient si rôdé qu'il peut être reproduit.

Illustrons par un exemple simple comment fonctionne l'interpolation. Supposons que nous voulons lire le journal intime de notre ennemi, Bob. Il chiffre chaque nombre dans son journal à l'aide d'un système cryptographique simple qu'il a découvert dans une publicité dans le magazine "Se moquer de la cryptographie". Le système fonctionne ainsi : Bob choisit deux chiffres qu'il aime : et . À partir de ce moment, pour chiffrer un nombre quelconque , il calcule . Par exemple, si Bob a choisi et , alors le chiffre sera chiffré en .

. Supposons qu'au 28 décembre, nous avons remarqué que Bob griffonnait quelque chose dans son journal. Quand il a fini, nous prendrons discrètement son journal et regarderons la dernière entrée :

Date : 235/520
Cher journal,
Aujourd'hui a été une bonne journée. Dans 64 jours, j'ai un rendez-vous avec Alice, qui vit dans l'appartement 843. Je pense vraiment qu'elle pourrait être 26!

. Comme nous sommes très sérieux à l'idée de suivre Bob lors de son rendez-vous (dans ce scénario, nous avons 15 ans), il est crucial de connaître la date ainsi que l'adresse d'Alice. Heureusement, nous remarquons que le système cryptographique de Bob est vulnérable à l'attaque par interpolation. Nous ne connaissons peut-être pas et , mais nous connaissons la date d'aujourd'hui, donc nous avons deux paires "texte clair - texte chiffré". À savoir, nous savons que est chiffré en , et — dans . Ce que nous allons noter :

Étant donné que nous avons 15 ans, nous savons déjà sur le système de deux équations à deux inconnues, ce qui est suffisant dans cette situation pour trouver et sans trop de problèmes. Chaque paire «texte en clair-texte chiffré» impose une restriction à la clé de Bob, et deux restrictions ensemble suffisent pour reconstruire complètement la clé. Dans notre exemple, la réponse et (lorsqu' , donc 26 dans le journal correspond au mot 'the one', c'est-à-dire «la seule» — note de l'éditeur.

Les attaques par interpolation, bien sûr, ne se limitent pas à des exemples aussi simples. Chaque cryptosystème qui se résume à un objet mathématique bien compris et une liste de paramètres est susceptible d'être exposé à une attaque par interpolation — plus l'objet est compréhensible, plus le risque est élevé.

Les débutants se plaignent souvent que la cryptographie est «l'art de concevoir les choses les plus laides possibles». Cela est probablement dû en grande partie aux attaques par interpolation. Bob peut soit utiliser un design mathématique élégant, soit préserver la confidentialité de son rendez-vous avec Alice — mais hélas, il n'est généralement pas possible d'obtenir les deux. Cela deviendra extrêmement clair lorsque nous aborderons enfin le sujet de la cryptographie à clé publique.

Cross-protocol/downgrading

Dans le film 'Now You See Me' (2013), un groupe d'illusionnistes s'efforce de dérober toute la richesse d'un assureur corrompu, Arthur Tressler. 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 non à participer à des opérations de services secrets. Ils choisissent donc une troisième option : leur complice appelle la banque et se fait passer pour Arthur. La banque pose quelques questions pour vérifier l'identité, telles que le nom de l'oncle et le nom du premier animal de compagnie ; nos héros obtiennent facilement cette information d'Arthur grâce à une ingénierie sociale habile.. À partir de ce moment, une excellente sécurité de mot de passe n'a plus d'importance.

(Selon une légende urbaine que nous avons personnellement vérifiée et confirmée, le cryptographe Eli Biham a un jour été confronté à un caissier de banque qui insistait pour établir une question secrète. Lorsque le caissier a demandé le nom de la grand-mère maternelle, Biham a commencé à dicter : «Majuscule X, minuscule y, trois…»).

De même, en cryptographie, si deux protocoles cryptographiques sont utilisés simultanément pour protéger le même actif, dont l'un est bien plus faible que l'autre, le système devient vulnérable à une attaque inter-protocoles, où le protocole le plus faible est attaqué pour atteindre le but sans toucher au protocole plus fort.

Dans certains cas complexes, il ne suffit pas de se connecter au serveur via un protocole plus faible, mais il faut une participation involontaire d'un client légitime. Cela peut être organisé grâce à ce qu'on appelle une attaque par rétrogradation (downgrade). Pour comprendre cette attaque, supposons que nos illusionnistes aient une tâche plus compliquée que dans le film. Supposons qu'il y ait eu des circonstances imprévues entre un employé de banque (le caissier) et Arthur, résultant en un dialogue tel que :

Hacker : Allô ? C'est Arthur Tressler. Je voudrais réinitialiser mon mot de passe.
Caissier : Très bien. Veuillez consulter votre livre personnel de codes secrets, page 28, mot 3. Tous les messages suivants seront chiffrés en utilisant ce mot comme clé. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Hacker : Hé hé, attends, attends. Est-ce vraiment nécessaire ? Ne pouvons-nous pas juste parler comme des gens normaux ?
Caissier : Je ne te conseille pas de le faire.
Hacker : J'essaie juste… écoute, j'ai passé une journée difficile, d'accord ? Je suis un client VIP et je ne suis pas d’humeur à fouiller dans ces maudits livres de code.
Caissier : Très bien. Si vous insistez, Monsieur Tressler. Que désirez-vous ?
Hacker : S'il vous plaît, j'aimerais transférer tout mon argent au Fonds national pour les victimes d'Arthur Tressler.
(Pause).
Caissier : Je comprends. Veuillez indiquer votre code PIN pour les transactions importantes.
Hacker : Mon quoi ?
Caissier : À votre demande personnelle, les transactions de cette taille nécessitent l'entrée d'un code PIN pour les transactions importantes. Ce code vous a été remis lors de l'ouverture de votre compte.
Hacker :… Je l'ai perdu. Est-ce vraiment nécessaire ? Ne pouvez-vous pas simplement approuver la transaction ?
Caissier : Non. Je suis désolé, Monsieur Tressler. Encore une fois, c'est une mesure de sécurité que vous aviez demandée. Si vous le souhaitez, nous pouvons vous envoyer un nouveau code PIN par courrier.

Nos héros retardent l'opération. Ils écoutent plusieurs grosses transactions de Tresler, espérant entendre le code PIN ; mais chaque fois, la conversation se transforme en charabia chiffré, avant d'entendre quelque chose d'intéressant. Enfin, un beau jour, ils mettent leur plan à exécution. Ils attendent patiemment le moment où Tresler doit effectuer une grosse transaction par téléphone, il se connecte à la ligne, et puis...

Tresler : Bonjour. Je voudrais effectuer une transaction à distance, s'il vous plaît.
Caissier : Très bien. Veuillez jeter un coup d'œil dans votre livre personnel de codes secrets, page...
(Le hacker appuie sur un bouton ; la voix du caissier se transforme en bruit indistinct).
Caissier : — #@$#@$#*@$$@#* sera chiffré avec ce mot comme clé. AAAYRR PLRQRZ MMNJK LOJBAN...
Tresler : Désolé, je n'ai pas bien compris. Encore une fois ? À quelle page ? Quel mot ?
Caissier : C'est la page @#$@#*$)#*#@()#@$(#@*$(#@*.
Tresler : Quoi ?
Caissier : Le mot numéro vingt @$#@$#%#$.
Tresler : Sérieusement ! Ça suffit ! Votre protocole de sécurité est une sorte de cirque. Je sais que tu peux juste me parler normalement.
Caissier : Je ne vous conseille pas...
Tresler : Et je ne te conseille pas de perdre mon temps. Je ne veux plus entendre parler de ça, jusqu'à ce que vous résolviez vos problèmes de ligne téléphonique. Pouvons-nous conclure cette affaire ou pas ?
Caissier :… Oui. D'accord. Que désirez-vous ?
Tresler : Je voudrais transférer 20 000 $ à la société Lord Business Investments, numéro de compte…
Caissier : Un instant, s'il vous plaît. C'est une grosse affaire. Veuillez indiquer votre code PIN pour les grosses transactions.
Tresler : Quoi ? Ah, oui. 1234.

Voici une attaque sur le déclin. Un protocole moins solide « parlez simplement à voix haute » était prévu comme option une mesure de dernier recours. Et pourtant, nous sommes ici.

Vous pouvez vous demander qui, en bonne santé mentale, concevrait un système réel de type « sécurisé, jusqu'à ce qu'on demande le contraire », comme décrit ci-dessus. Mais tout comme une banque fictive prend des risques pour garder des clients qui n’aiment pas la cryptographie, les systèmes, en général, se plient souvent à des exigences qui sont indifférentes ou même franchement hostiles à la sécurité.

C'est exactement ce qui est arrivé au protocole SSLv2 en 1995. Le gouvernement des États-Unis a longtemps considéré la cryptographie comme une arme qu'il valait mieux garder éloignée des ennemis externes et internes. Des fragments de code étaient approuvés séparément pour l'exportation depuis les États-Unis, souvent sous la condition d'un affaiblissement délibéré de l'algorithme. À l'entreprise Netscape, créatrice du navigateur le plus populaire, Netscape Navigator, il a été accordé le droit d'utiliser SSLv2 seulement avec une clé RSA de 512 bits (et 40 bits pour RC4) qui était initialement vulnérable.

À la fin du millénaire, les règles ont été assouplies et l'accès à un chiffrement moderne est devenu largement disponible. Cependant, les clients et les serveurs ont maintenu pendant de nombreuses années un chiffrement « d'exportation » affaibli en raison de la même inertie qui maintient le support de tout système obsolète. Les clients pensaient qu'ils pourraient rencontrer un serveur qui ne supportait rien d'autre. Les serveurs faisaient de même. Bien sûr, le protocole SSL dicte que les clients et les serveurs ne doivent jamais utiliser un protocole faible quand un meilleur est disponible. Mais la même prémisse était valable pour Tresler et sa banque.

Cette théorie a trouvé application dans deux attaques médiatisées qui ont secoué la sécurité du protocole SSL en 2015, toutes deux découvertes par des chercheurs de Microsoft et INRIA. D'abord, en février, les détails de l'attaque FREAK ont été divulgués, puis trois mois plus tard, une autre attaque similaire nommée Logjam, que nous examinerons plus en détail lorsque nous aborderons les attaques contre la cryptographie à clé publique.

Vulnérabilité FREAK (également connue sous le nom de « Smack TLS ») s'est manifestée lorsque des chercheurs ont analysé les implémentations du client/serveur TLS et ont découvert une curiosité. Dans ces implémentations, même si le client ne demande pas d'utiliser une cryptographie d'exportation faible, si le serveur répond tout de même avec de telles clés, le client dit « Bon d'accord » et passe à un ensemble de chiffrement faible.

À l'époque, tout le monde considérait le cryptage à l'exportation comme obsolète et interdit, donc l'attaque a été un véritable choc et a touché de nombreux domaines importants, y compris les sites Web de la Maison Blanche, de l'IRS et de la NSA. Pire encore, il s'est avéré que de nombreux serveurs vulnérables optimisaient les performances en réutilisant les mêmes clés au lieu de créer de nouvelles pour chaque session. Cela a permis, après une rétrogradation du protocole, de réaliser également une attaque par pré-calcul : le piratage d'une clé restait relativement coûteux (100 $ et 12 heures au moment de la publication), mais le coût pratique d'une attaque sur une connexion a été considérablement réduit. Il suffisait de craquer une fois la clé du serveur pour pirater les chiffrages de toutes les connexions ultérieures à partir de ce moment.

Et avant de poursuivre, il faut mentionner une attaque avancée…

Attaque de l'oracle

Moxie Marlinspike est surtout connu comme le père du cryptomessenger multiplateforme Signal ; mais personnellement, nous aimons l'une de ses innovations moins connues — le principe de la fatalité cryptographique (Cryptographic Doom Principle). Pour résumer légèrement, on peut dire : « Si un protocole effectue une opération cryptographique sur un message d'une source potentiellement malveillante et se comporte différemment en fonction du résultat, il est condamné ». Ou de manière plus abrupte : « Ne prends pas d'informations à exploiter de l'ennemi, et si tu es obligé, ne montre pas le résultat ».

Mettons de côté les dépassements de tampon, les injections de commandes et autres ; ils dépassent le cadre de cette discussion. La violation du « principe de fatalité » entraîne de graves violations de la cryptographie parce que le protocole se comporte exactement comme il se doit.

Prenons un exemple d'une construction fictive avec un chiffrement par substitution vulnérable, puis démontrons l'attaque possible. Bien que nous ayons déjà vu une attaque sur le chiffrement par substitution à l'aide de l'analyse de fréquence, ce n'est pas simplement « une autre façon de casser le même chiffrement ». Au contraire, les attaques de l'oracle sont une invention beaucoup plus moderne, applicable à de nombreuses situations où l'analyse de fréquence échoue, et nous verrons cela dans la section suivante. Ici, un simple chiffrement est choisi uniquement pour rendre l'exemple plus compréhensible.

Ainsi, Alice et Bob communiquent par un simple chiffrement par substitution, utilisant une clé uniquement connue d'eux. Ils prennent très au sérieux la longueur des messages : leur longueur est exactement de 20 caractères. Par conséquent, ils ont convenu que si quelqu'un souhaitait envoyer un message plus court, il devait ajouter un texte fictif à la fin du message afin qu'il fasse exactement 20 caractères. Après quelques discussions, ils ont décidé qu'ils n'accepteraient que les textes fictifs suivants : a, bb, ccc, dddd etc. Ainsi, le texte fictif de n'importe quelle longueur nécessaire est connu.

Lorsque Alice ou Bob reçoit 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 fictif. Si ce n'est pas le cas, ils répondent avec un message d'erreur approprié. Si la longueur du texte et le texte fictif sont corrects, le destinataire lit le message lui-même et envoie une réponse chiffrée.

Dans le cadre de l'attaque, l'attaquant se fait passer pour Bob et envoie de faux messages à Alice. Les messages sont totalement insignifiants - l'attaquant n'a pas la clé et ne peut donc pas falsifier un message significatif. Mais comme le protocole enfreint le principe de l'illusion, l'attaquant peut tout de même piéger Alice pour qu'elle révèle des informations sur la clé, comme indiqué ci-dessous.

Hacker : PREWF ZHJKL MMMN. LA
Alice : Texte fictif incorrect.
Hacker : PREWF ZHJKL MMMN. LB
Alice : Texte fictif incorrect.
Hacker : PREWF ZHJKL MMMN. LC
Alice : ILCT ? TLCT RUWO PUT KCAW CPS OWPOW !

L'attaquant n'a aucune idée de ce qu'Alice vient de dire, mais note que le symbole C doit correspondre à a, puisque Alice a accepté le texte fictif.

Hacker : REWF ZHJKL MMMN. LAA
Alice : Texte fictif incorrect.
Hacker : REWF ZHJKL MMMN. LBB
Alice : Texte fictif incorrect.
Après une série de tentatives…
Hacker : REWF ZHJKL MMMN. LGG
Alice : Texte fictif incorrect.
Hacker : 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 texte fictif.

Et ainsi de suite, jusqu'à ce que l'attaquant découvre la signification de chaque symbole.

À première vue, la méthode ressemble à une attaque par texte clair choisi. Après tout, l'attaquant choisit des chiffrages, 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 déchiffrement réel — une réponse du serveur, même aussi inoffensive que « Texte factice incorrect », suffit.

Bien que cette attaque spécifique soit instructive, il ne faut pas se concentrer excessivement sur la spécificité du schéma de « texte factice », le système cryptographique utilisé ou la séquence exacte de messages envoyés par l'attaquant. L'idée principale est de voir comment Alice réagit différemment en fonction des propriétés du texte clair, et ce sans vérifier si le texte chiffré correspondant provient réellement d'une source de confiance. Ainsi, Alice permet à l'attaquant d'extraire des informations secrètes de ses réponses.

Dans ce scénario, il est possible de changer beaucoup de choses. Les symboles auxquels Alice réagit, ou la différence même dans son comportement, ou même le système cryptographique utilisé. Mais le principe restera le même, et l'attaque en général demeurera viable d'une manière ou d'une autre. La mise en œuvre de base de cette attaque a aidé à détecter plusieurs failles de sécurité que nous examinerons bientôt ; mais d'abord, certaines leçons théoriques doivent être apprises. Comment utiliser ce « scénario d'Alice » fictif dans une attaque qui peut fonctionner sur un chiffrement moderne réel ? Est-ce même possible, même en théorie ?

En 1998, le cryptographe suisse Daniel Bleichenbacher a répondu affirmativement à cette question. Il a démontré une attaque d'oracle dans un système cryptographique à clé publique RSA largement utilisé, en utilisant un certain schéma de messages. Dans certaines implémentations de RSA, le serveur répond avec différents messages d'erreur, selon que le texte clair correspond ou non au schéma ; cela suffisait à mener l'attaque.

Quatre ans plus tard, en 2002, le cryptographe français Serge Vaudenay a démontré une attaque d'oracle presque identique à celle décrite précédemment dans le scénario d'Alice – sauf qu'au lieu d'un chiffrement fictif, il a compromis toute une classe respectable de chiffrages modernes réellement utilisés. En particulier, l'attaque de Vaudenay cible les chiffres à longueur d'entrée fixe (« chiffrages par blocs ») lorsqu'ils sont utilisés dans ce qu'on appelle le « mode de chiffrement CBC » et avec un certain schéma de bourrage populaire, principalement équivalent à celui du scénario d'Alice.

Également en 2002, le cryptographe américain John Kelsey – co-auteur Twofish – a proposé diverses attaques d'oracle sur les systèmes qui compressent les messages puis les chiffrent. La plus notable parmi elles était une attaque qui exploitait le fait qu'on peut souvent déduire la longueur d'origine du texte clair à partir de la longueur du texte chiffré. En théorie, cela permet de réaliser une attaque d'oracle qui restaure des parties du texte clair d'origine.

Nous allons maintenant fournir une description plus détaillée des attaques de Vaudenay et Kelsey (nous donnerons une description plus détaillée de l'attaque de Bleichenbacher lorsque nous aborderons les attaques sur la cryptographie à clé publique). Malgré tous nos efforts, le texte devient quelque peu technique ; donc, si ce qui précède est suffisant pour vous, passez les deux sections suivantes.

L'attaque de Vaudenay

Pour comprendre l'attaque de Vaudenay, il faut d'abord parler un peu plus en détail des chiffrages par blocs et des modes de chiffrement. Un « chiffre par blocs » est, comme mentionné précédemment, un chiffre qui prend une clé et une entrée d'une longueur fixe (« longueur de bloc ») et produit un bloc chiffré de la même longueur. Les chiffrages par blocs sont largement utilisés et considérés comme relativement sûrs. Le DES, maintenant à la retraite, qui est considéré comme le premier chiffre moderne, était un chiffre par blocs. Comme mentionné précédemment, il en va de même pour l'AES, largement utilisé aujourd'hui.

Malheureusement, les chiffrements par blocs ont une faiblesse évidente. La taille typique d'un bloc est de 128 bits, soit 16 caractères. Il est claire que la cryptographie moderne a besoin de travailler avec des données d'entrée de plus grande taille, et c'est là que les modes de chiffrement entrent en jeu. Le mode de chiffrement est en réalité un hack : c'est une façon d'appliquer d'une manière ou d'une autre un chiffre par blocs, qui n'accepte des entrées que de taille fixe, à des données d'entrée de longueur arbitrable.

L'attaque de Waterner cible le mode de fonctionnement populaire CBC (Cipher Block Chaining, mode de chaînage de blocs de texte chiffré). L'attaque considère le chiffre par blocs de base comme une boîte noire magique inaccessibile et contourne complètement sa sécurité.

Voici un diagramme qui montre comment fonctionne le mode CBC :

Le plus entouré signifie l'opération XOR (« exclusive OR »). Par exemple, le deuxième bloc de texte chiffré est obtenu :

En effectuant l'opération XOR sur le deuxième bloc de texte clair avec le premier bloc de texte chiffré.
En chiffrant le bloc obtenu avec le chiffre par blocs, en utilisant la clé.

Étant donné que le mode CBC utilise intensivement l'opération binaire XOR, profitons-en pour rappeler certaines de ses propriétés :

Idempotence :
Commutativité :
Associativité :
Involution :
Par byte : le byte n de = (byte n de ) (byte n de )

En général, ces propriétés impliquent que si nous avons une équation comportant des opérations XOR et une inconnue, elle peut être résolue. Par exemple, si nous savons que avec l'inconnue et connue et , alors nous pouvons nous fier aux propriétés mentionnées ci-dessus pour résoudre l'équation pour . En appliquant XOR des deux côtés de l'équation avec , nous obtenons . Très bientôt, tout cela deviendra très pertinent.

Entre notre scénario avec Alice et l'attaque de Waterner, il y a deux différences mineures et une différence principale. Deux mineures :

Dans le scénario, Alice s'attendait à ce que les textes clairs se terminent par des caractères a, bb, ccc et ainsi de suite. Dans l'attaque de Waterner, la victime s'attend plutôt à ce que les textes clairs se terminent par N fois le byte N (c'est-à-dire hexadécimal 01 ou 02 02, ou 03 03 03, etc.). C'est une différence purement cosmétique.
Dans le scénario d'Alice, il était facile de dire si Alice avait reçu le message en fonction de la réponse « Texte factice incorrect ». Dans l'attaque de Waterne, une analyse plus poussée est nécessaire et une mise en œuvre précise du côté de la victime est importante ; mais pour être bref, prenons comme acquis que cette analyse est toujours possible.

La principale différence :

Puisque nous n'utilisons pas la même cryptosystème, la relation entre les octets contrôlés par l'attaquant dans le texte chiffré et les secrets (clé et texte clair) sera évidemment différente. Ainsi, l'attaquant devra utiliser une autre stratégie pour créer des ciphertexts et interpréter les réponses du serveur.

C'est cette différence principale qui constitue le dernier élément pour comprendre l'attaque de Waterne, alors prenons un moment pour réfléchir à pourquoi et comment on peut effectivement organiser une attaque oracle sur CBC.

Supposons que nous disposions d'un ciphertext CBC de 247 blocs, et que nous souhaitions le déchiffrer. Nous pouvons envoyer des messages factices au serveur, comme nous pouvions auparavant envoyer des messages factices à Alice. Le serveur déchiffrera les messages pour nous, mais ne montrera pas le déchiffrement – à la place, encore une fois, comme dans le cas d'Alice, le serveur ne donnera qu'un seul bit d'information : soit le texte clair a un remplissage valide, soit non.

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

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

Appelons cela « l'équation d'Alice ». Nous contrôlions le ciphertext ; le serveur (Alice) révélait des informations vagues sur le texte clair reçu ; et cela nous a permis d'extraire des informations sur le dernier facteur – la clé. De manière analogue, si nous pouvons trouver une telle relation pour le scénario CBC, nous pourrions en extraire des informations secrètes également.

Heureusement, il existe effectivement des relations que nous pouvons utiliser. Considérons la sortie de l'appel final de décryptage d'un chiffrement par blocs et désignons ces données par . Désignons également les blocs de texte clair par et les blocs de ciphertext par . Regardez à nouveau le diagramme CBC et notez ce que cela donne :

Appelons cela « l'équation CBC ».

Dans le scénario d'Alice, en contrôlant le texte chiffré et en observant les fuites d'informations concernant le texte en clair correspondant, nous avons pu organiser une attaque qui a récupéré le troisième membre de l'équation : la clé. Dans le scénario CBC, nous contrôlons également le texte chiffré et observons des fuites d'informations sur le texte en clair correspondant. Si l'analogie est pertinente, nous pouvons obtenir des informations sur .

Supposons que nous avons effectivement récupéré , que se passe-t-il alors ? Eh bien, nous pouvons immédiatement extraire tout le dernier bloc du texte en clair (), simplement en entrant (que nous avons) et
le résultat obtenu dans l'équation CBC.

Ainsi, nous sommes optimistes quant au plan d'attaque général, et il est temps de travailler sur les détails. Nous remarquons comment la fuite d'informations sur le texte en clair se produit sur le serveur. Dans le scénario d'Alice, la fuite s'est produite parce qu'Alice ne répondait avec le bon message que si $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ se terminait par la chaîne a ou bb, et ainsi de suite, mais les chances que ces conditions se produisent par hasard étaient très faibles). De même, avec CBC, le serveur accepte le remplissage si et seulement si se termine par l'hexadécimal 01. Alors, essayons le même truc : envoyer de faux textes chiffrés avec nos propres valeurs fictives , jusqu'à ce que le serveur accepte le remplissage.

Lorsque le serveur accepte le remplissage pour l'un de nos messages fictifs, cela signifie que :

Utilisons maintenant la propriété de byte par byte de XOR :

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

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

Nous pourrions nous arrêter là et nous contenter de dire que nous avons attaqué un chiffrement théoriquement résistant. Mais en réalité, nous pouvons faire beaucoup plus : nous pouvons réellement récupérer tout le texte. Cela nécessite une certaine astuce qui n'était pas dans le scénario original d'Alice et qui n'est pas une condition obligatoire pour l'attaque de l'oracle, mais la méthode mérite d'être étudiée.

Pour le comprendre, commencez par noter que le bon résultat du dernier octet Nous avons développé une nouvelle capacité. Désormais, lors de la falsification des textes chiffrés, nous pouvons contrôler le dernier octet du texte en clair correspondant. Cela est lié à l'équation CBC et à la propriété par octet :

Puisque nous connaissons maintenant le second élément, nous pouvons utiliser notre contrôle sur le premier pour gérer le troisième. Nous calculons simplement :

Auparavant, nous ne pouvions pas faire cela, car nous n'avions pas encore le dernier octet. .

Comment cela va-t-il nous aider ? Supposons que nous allons désormais créer tous les textes chiffrés de manière à ce que les textes en clair correspondants se terminent par 02. Maintenant, le serveur n'accepte le remplissage que si le texte en clair se termine par 02 02. Étant donné que nous avons corrigé le dernier octet, cela ne se produira que si l'avant-dernier octet du texte en clair vaut également 02. Nous continuons à envoyer des blocs de textes chiffrés falsifiés en modifiant l'avant-dernier octet, jusqu'à ce que le serveur accepte le remplissage pour l'un d'eux. À ce moment-là, nous obtenons :

Et nous récupérons l'avant-dernier octet de la même manière que nous avons retrouvé le dernier. Nous continuons dans le même esprit : nous corrigeons les deux derniers octets du texte en clair en 03 03, nous réitérons cette attaque pour le troisième octet en partant de la fin, et ainsi de suite, jusqu'à ce que nous puissions entièrement récupérer .

Qu'en est-il du reste du texte ? Notez que la valeur est en réalité $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Nous pouvons mettre n'importe quel autre bloc à la place de , et l'attaque sera tout de même couronnée de succès. En fait, nous pouvons demander au serveur d'effectuer $inline$text{BLOCK_DECRYPT}$inline$ pour n'importe quelles données. À ce moment, le jeu est terminé – nous pouvons déchiffrer n'importe quel texte chiffré (jetez à nouveau un œil au diagramme de déchiffrement CBC pour vous en assurer ; et sachez que le vecteur IV est public).

Cette méthode en particulier joue un rôle crucial dans l'attaque de l'oracle que nous examinerons plus tard.

L'attaque de Kelsey

Notre proche allié, John Kelsey, a exposé les principes sous-jacents à de nombreuses attaques possibles, et pas seulement les détails spécifiques d'une attaque sur un chiffrement particulier. Son article de 2002 est une étude des attaques potentielles contre des données chiffrées et compressées. Pensiez-vous qu'il était insuffisant pour mener une attaque d'avoir uniquement l'information que les données avaient été compressées avant le chiffrement ? Il s'avère que c'est suffisant.

Ce résultat étonnant repose sur deux principes. Tout d'abord, il existe une forte corrélation entre la longueur du texte en clair et la longueur du texte chiffré ; pour de nombreux algorithmes de chiffrement, l'égalité exacte. Ensuite, lorsqu'une compression est effectuée, il existe également une forte corrélation entre la longueur du message compressé et le degré de "bruit" du texte en clair, c'est-à-dire la proportion de caractères non répétés (terme technique - "grande entropie").

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

Texte en clair 1 : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Texte en clair 2 : ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Supposons que les deux textes en clair 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 pourrait avoir été compressé à la longueur maigre du deuxième texte chiffré. Nous avons établi cela sans savoir quoi que ce soit sur l'algorithme de compression, la clé de chiffrement ou même le chiffrement lui-même. Comparé à l'éventail des attaques cryptographiques possibles, c'est en quelque sorte de la folie.

Kelsey indique 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 restaurer le texte en clair secret, s'il peut forcer le serveur à chiffrer des données de formulaire (texte en clair, suivi de , tant qu'il contrôle et peut d'une manière ou d'une autre vérifier la longueur du résultat chiffré.

Encore une fois, comme dans d'autres attaques oracle, nous avons une relation :

Encore une fois, nous contrôlons un membre (), voyons une petite fuite d'informations sur un autre membre (texte chiffré) et essayons de restaurer ce dernier (texte en clair). Malgré l'analogie, c'est une situation quelque peu inhabituelle par rapport à d'autres attaques oracle que nous avons vues.

Pour illustrer comment une telle attaque peut fonctionner, utilisons un schéma de compression fictif que nous venons de créer : TOYZIP. Il recherche des chaînes de texte qui sont déjà apparues précédemment dans le texte et les remplace par trois octets de remplissage qui indiquent où trouver une instance antérieure de la chaîne et combien de fois elle y apparaît. Par exemple, la chaîne helloworldhello peut être compressé en helloworld[00][00][05] longueur de 13 octets par rapport à l'original de 15 octets.

Supposons qu'un attaquant essaie de restaurer le texte en clair du formulaire password=..., où le mot de passe lui-même est inconnu. Selon le modèle d'attaque de Kelsey, l'attaquant peut demander au serveur de compresser, puis de chiffrer les messages du formulaire (texte clair, suivi de ), où — texte aléatoire. Lorsque le serveur a terminé son travail, il communique la longueur du résultat. L'attaque se déroule comme suit :

Hacker : Veuillez compresser et chiffrer le texte clair sans remplissages.
Serveur : La longueur du résultat est de 14.
Hacker : Veuillez compresser et chiffrer le texte clair auquel est ajouté password=a.
Serveur : La longueur du résultat est de 18.

L'attaquant remarque : [original 14] + [trois octets qui ont remplacé password=] + a

Hacker : Veuillez compresser et chiffrer le texte clair auquel est ajouté password=b.
Serveur : La longueur du résultat est de 18.
Hacker : Veuillez compresser et chiffrer le texte clair auquel est ajouté password=c.
Serveur : La longueur du résultat est de 17.

L'attaquant remarque : [original 14] + [trois octets qui ont remplacé password=c]. Cela suppose que le texte clair original contient la chaîne password=c. Autrement dit, le mot de passe commence par la lettre c

Hacker : Veuillez compresser et chiffrer le texte clair auquel est ajouté password=ca.
Serveur : La longueur du résultat est de 18.

L'attaquant remarque : [original 14] + [trois octets qui ont remplacé password=c] + a

Hacker : Veuillez compresser et chiffrer le texte clair auquel est ajouté password=cb.
Serveur : La longueur du résultat est de 18.

(… quelque temps plus tard…)

Hacker : Veuillez compresser et chiffrer le texte clair auquel est ajouté password=co.
Serveur : La longueur du résultat est de 17.

L'attaquant remarque : [original 14] + [trois octets qui ont remplacé password=co]. Selon la même logique, l'attaquant déduit que le mot de passe commence par les lettres co

Et ainsi de suite jusqu'à ce que tout le mot de passe soit restauré.

Le lecteur peut penser qu'il s'agit d'un exercice purement académique et qu'un tel scénario d'attaque ne se produira jamais dans le monde réel. Hélas, comme nous le verrons bientôt, il vaut mieux ne jamais être trop sûr dans le domaine de la cryptographie.

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

Enfin, après avoir étudié la théorie en détail, nous pouvons voir comment ces méthodes s'appliquent dans des attaques cryptographiques réelles.

CRIME

Si l'attaque cible le navigateur et le réseau de la victime, certaines choses seront plus simples, et d'autres plus compliquées. Par exemple, voir le trafic de la victime est facile : il suffit d'être dans le même café avec elle utilisant le WiFi. Pour cette raison, il est généralement conseillé aux victimes potentielles (c'est-à-dire à tout le monde) d'utiliser une connexion chiffré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 piéger la victime sur une page web malveillante avec un script qui fera la requête. Le navigateur web fournira automatiquement le cookie de session approprié.

Cela semble incroyable. Si Bob va sur evil.com, est-il vraiment possible pour un script sur ce site de demander simplement à Google d'envoyer le mot de passe de Bob par e-mail à attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Délégation de requête intersites, CSRF), qui était populaire dans les années 90. Aujourd'hui, si evil.com il tente une telle astuce, Google (ou tout site respectable) répond généralement : « Très bien, mais votre jeton CSRF pour cette transaction sera… euh… trois trillions et sept. Veuillez répéter ce chiffre ». Les navigateurs modernes appliquent une sorte de « politique de même origine » (same-origin policy), selon laquelle les scripts sur le site A n'ont pas accès aux informations envoyées par le site B. Par conséquent, un script sur evil.com peut envoyer des requêtes à google.com, mais ne peut pas lire les réponses ou vraiment compléter la transaction.

Nous devons souligner que si Bob n'utilise pas de connexion sécurisée, toutes ces protections sont inutiles. Un pirate peut simplement lire le trafic de Bob et récupérer le cookie de session de Google. Avec ce cookie, il peut ouvrir un nouvel onglet Google, sans se déconnecter de son propre navigateur, et se faire passer pour Bob, sans rencontrer les ennuyeuses politiques de même origine. Mais, malheureusement pour le pirate, cela devient de plus en plus rare. Internet dans son ensemble a depuis longtemps déclaré la guerre aux connexions non sécurisées, et le trafic sortant de Bob est probablement chiffré, qu'il le veuille ou non. De plus, depuis le début de l'implémentation du protocole, le trafic a également été compressé avant le chiffrement ; c'était une pratique courante pour réduire la latence.

C'est là que CRIME (Compression Ratio Infoleak Made Easy, fuite simple via le ratio de compression) entre en jeu. Une vulnérabilité mise en évidence en septembre 2012 par les chercheurs en sécurité Giuliano Rizzo et Thai Duong. Nous avons déjà couvert toute la base théorique qui permet de comprendre ce qu'ils ont fait et comment. Le pirate peut amener le navigateur de Bob à envoyer des requêtes à Google, puis écouter les réponses sur le réseau local sous forme compressée et chiffrée. Donc, nous avons :

Ici, le pirate contrôle la requête et a accès à un renifleur de trafic, y compris à la taille des paquets. Le scénario fictif de Kelsey s'est concrétisé.

En comprenant la théorie, les auteurs de CRIME ont créé un exploit capable de voler des cookies de session pour un large éventail de sites, y compris Gmail, Twitter, Dropbox et Github. La vulnérabilité a touché la plupart des navigateurs web modernes, entraînant la publication de correctifs qui ont silencieusement enterré la fonction de compression dans SSL, de sorte qu'elle ne soit plus utilisée du tout. Le seul protégé contre la 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 sensation dans la communauté de la sécurité. Ils ont pu exploiter une vulnérabilité dans le protocole SSL, corrigée il y a plus de dix ans.

Il s'est avéré que même si les serveurs fonctionnaient avec le tout nouveau TLSv1.2, beaucoup avaient laissé la prise en charge de l'ancien SSLv3 pour la compatibilité avec Internet Explorer 6. Nous avons déjà parlé des attaques de rétrogradation, donc vous pouvez imaginer ce qui se passait. Un sabotage bien organisé du protocole de handshake - et les serveurs étaient prêts à revenir à l'ancien SSLv3, annulant en fait 15 ans 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 par Matthew Green:

Transport Layer Security (TLS) est le protocole de sécurité le plus important sur Internet. [..] presque chaque transaction que vous effectuez en ligne dépend de TLS. [..] Mais TLS n'a pas toujours été TLS. Le protocole a commencé sa vie dans Netscape Communications sous le nom de « Secure Sockets Layer » ou SSL. On raconte que la première version de SSL était si horrible que les développeurs ont rassemblé toutes les impressions du code et les ont enterrées dans une décharge secrète au Nouveau-Mexique. Par conséquent, la première version publique de SSL est en réalité la version SSL 2. Elle est plutôt effrayante, et [..] c'était un produit du milieu des années 90, que les cryptographes modernes considèrent comme un «âge sombre de la cryptographie». Beaucoup des attaques cryptographiques les plus révoltantes que nous connaissons aujourd'hui n'avaient pas encore été découvertes. En conséquence, les développeurs du protocole SSLv2 ont dû en quelque sorte tâtonner dans l'obscurité, et ils ont rencontré de nombreux monstres terrifiants — à leur grand désarroi et à notre avantage, car les attaques sur SSLv2 ont laissé des leçons précieuses pour la génération suivante de protocoles.

Après ces événements, en 1996, l'entreprise Netscape a complètement repensé le protocole SSL. Le résultat a été la version 3 du SSL, qui a corrigé plusieurs problèmes de sécurité connus de son prédécesseur..

Heureusement pour les attaquants, « plusieurs » ne signifie pas « tous ». Dans l'ensemble, SSLv3 fournissait tous les éléments nécessaires pour mener l'attaque de Wodené. Le protocole utilisait un chiffre par blocs en mode CBC et un schéma de remplissage peu sécurisé (ce qui 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 initiale de l'attaque de Wodené, le schéma SSLv3 lui ressemble beaucoup.

Mais, malheureusement pour les attaquants, « similaire » ne signifie pas « identique ». Le schéma de remplissage SSLv3 est de la forme « N octets aléatoires, suivis du nombre N ». Essayez dans de telles conditions de choisir un bloc imaginaire de texte chiffré et de passer par toutes les étapes de l'original schéma de Wodené : vous découvrirez que l'attaque réussit à extraire le dernier octet du bloc correspondant du texte clair, mais ne va pas au-delà. Déchiffrer chaque 16e octet du texte chiffré est un excellent tour de magie, mais ce n'est pas une victoire.

Confrontée à l'échec, l'équipe de Google a opté pour une solution extrême : elle est passée à un modèle de menace beaucoup plus puissant — celui utilisé dans CRIME. En supposant que l'attaquant est un script exécuté dans l'onglet du navigateur de la victime, et qu'il peut extraire des cookies de session, l'attaque reste néanmoins impressionnante. Bien que le modèle de menace plus large soit moins réaliste, nous avons déjà vu dans le chapitre précédent que ce modèle particulier est réalisable.

Avec de telles capacités de hacker plus puissantes, l'attaque peut désormais se poursuivre. Sachez que l'attaquant sait où le fichier cookie de session chiffré est affiché dans l'en-tête et contrôle la longueur de la requête HTTP qui le précède. Il peut donc manipuler la requête HTTP pour aligner le dernier octet du cookie avec la fin du bloc. Cet octet est maintenant prêt à être déchiffré. Il suffit d'ajouter un caractère à la requête, et l'avant-dernier octet du cookie restera à la même place, utilisable pour la tentative de brute force par la même méthode. L'attaque se poursuit de cette manière jusqu'à ce que le fichier cookie soit complètement récupéré. Cela s'appelle POODLE : Padding Oracle on Downgraded Legacy Encryption, oracle de remplissage sur un chiffrement hérité dégradé.

DROWN

Comme nous l'avons déjà mentionné, SSLv3 avait des défauts, mais il différait fondamentalement de son prédécesseur, car l'SSLv2 troué était produit d'une autre époque. Là, un message pouvait être interrompu en son milieu : je n'accepterai cela que par mon cadavre devenait j'accepterai cela; le client et le serveur pouvaient se rencontrer sur Internet, établir une confiance et échanger des secrets sous les yeux d'un attaquant qui se faisait facilement passer pour l'un ou l'autre. Il y avait aussi un problème avec la cryptographie d'exportation, que nous avions évoqué lors de l'examen de FREAK. C'était une cryptographie de Sodome et Gomorrhe.

En mars 2016, une équipe de chercheurs provenant 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 pouvaient plus rétrograder les sessions TLS modernes à SSLv2, car cette faille a été comblée après FREAK et POODLE, mais ils peuvent toujours se connecter aux serveurs et initier des sessions SSLv2 par eux-mêmes.

Vous vous demandez quel intérêt cela a pour nous, ce qu'ils font là-bas ? Ils ont une session vulnérable, mais cela ne devrait pas affecter d'autres sessions ou la sécurité du serveur — n'est-ce pas ? Eh bien, pas tout à fait. Oui, cela devrait être le cas en théorie. Mais non — car la génération des certificats SSL impose un certain fardeau, de sorte 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. Pire encore, à cause d'un bug d'OpenSSL dans cette implémentation SSL populaire, l'option « Désactiver SSLv2 » ne fonctionnait effectivement pas.

Cela a rendu possible une attaque inter-protocole sur TLS, connue sous le nom de DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, déchiffrage RSA avec un chiffrement obsolète et affaibli). Rappelons que cela n’est pas la même chose qu'une attaque par rétrogradation ; un attaquant n’a pas besoin d'agir en tant que « homme du milieu » et n’a pas besoin d'impliquer le client dans une session non sécurisée. Les malfaiteurs initient 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 du serveur RSA. Cette clé est également valide pour les connexions TLS, et à partir de ce moment-là, aucune sécurité TLS ne pourra la protéger d'être compromise.

Mais pour un piratage, il faut une attaque fonctionnelle contre SSLv2, qui permet de récupérer non seulement le trafic spécifique, mais aussi la clé secrète du serveur RSA. Bien que cela semble complexe, les chercheurs pouvaient cibler n’importe quelle vulnérabilité complètement corrigée après SSLv2. En fin de compte, ils ont trouvé une option appropriée : l'attaque de Bleichenbacher, que nous avons mentionnée précédemment et que nous expliquerons en détail dans l’article suivant. SSL et TLS sont protégés contre cette attaque, mais certaines fonctionnalités aléatoires de SSL, combinées à de courtes clés dans la cryptographie de classe d'exportation, ont rendu possible une certaine implémentation de DROWN..

Au moment de la publication, 25 % des principaux sites internet étaient vulnérables à DROWN, et l'attaque pouvait être effectuée avec des ressources modestes, accessibles même pour des hackers solitaires facétieux. Pour extraire la clé RSA du serveur, il fallait huit heures de calcul et 440 $, et SSLv2 a changé de statut, passant de « obsolète » à « radioactif ».

Attendez, qu'en est-il de Heartbleed ?

Ce n'est pas une attaque cryptographique dans le sens où nous l'avons décrite ci-dessus ; c'est un débordement de tampon.

Faisons une pause.

Nous avons commencé par quelques méthodes de base : brute force, interpolation, rétrogradation, inter-protocole et pré-calcul. Puis, nous avons examiné une technique avancée, peut-être le principal composant des attaques cryptographiques modernes : l'attaque par oracle. Nous avons passé pas mal de temps dessus — et avons compris non seulement le principe sous-jacent, mais aussi les détails techniques de deux implémentations spécifiques : l'attaque de Vaudenay sur le mode de chiffrement CBC et l'attaque de Kelsey sur les protocoles de chiffrement avec compression préalable.

Dans cette revue des attaques par dégradation et avec des pré-calculs, nous avons brièvement présenté l'attaque FREAK, qui utilise les deux méthodes, car les sites ciblés retombent sur des clés faibles, puis réutilisent les mêmes clés. Pour l'article suivant, nous avons laissé l'attaque Logjam (très similaire), qui vise les algorithmes à clé publique.

Nous avons ensuite examiné trois autres exemples d'application de ces principes. Tout d'abord, CRIME et POODLE : deux attaques qui s'appuyaient sur la capacité d'un attaquant à injecter du texte clair arbitraire à côté du texte clair ciblé, puis à étudier les réponses du serveur et ensuite, en utilisant la méthodologie d'attaque oracle, utiliser ces maigres informations pour récupérer partiellement le texte clair. CRIME a emprunté la voie de l'attaque de Kelsey contre la compression SSL, tandis que POODLE a utilisé à la place une variante de l'attaque de Vaudenay contre le CBC avec le même effet.

Nous avons ensuite porté notre attention sur l'attaque inter-protocoles DROWN, qui établit une connexion avec le serveur via le protocole obsolète SSLv2, puis restaure les clés secrètes du serveur par le biais de l'attaque de Bleichenbacher. Pour l'instant, nous avons omis les détails techniques de cette attaque ; comme Logjam, elle devra attendre que nous examinions à fond les cryptosystèmes à clé publique et leurs vulnérabilités.

Dans l'article suivant, nous parlerons des attaques avancées — telles que la méthode de rencontre au milieu (meet-in-the-middle), l'analyse différentielle et l'attaque des « anniversaires ». Nous ferons un bref survol des attaques par canaux auxiliaires, puis nous nous attaquerons à la meilleure partie — les cryptosystèmes à clé publique.

Source : habr.com

Attaques cryptographiques : explication pour les esprits confus