Au mot «cryptographie», certains se souviennent de leur mot de passe WiFi, d'un cadenas vert à côté de l'adresse de leur site préféré et de la difficulté à accéder au courrier de quelqu'un d'autre. D'autres rappellent une série de vulnérabilités de ces dernières années avec des abréviations parlantes (DROWN, FREAK, POODLE ...), des logos stylés et un avertissement mettant à jour d'urgence le navigateur.

La cryptographie couvre tout cela, mais l' essence est différente. L'essentiel est entre simple et complexe. Certaines choses sont faciles à faire, mais difficiles à récupérer: par exemple, casser un œuf. D'autres choses sont faciles à faire, mais difficiles à récupérer lorsqu'une petite pièce cruciale est manquante: par exemple, ouvrir une porte verrouillée lorsque la «partie critique» est la clé. La cryptographie étudie ces situations et comment les utiliser dans la pratique.

Au cours des dernières années, la collection d'attaques cryptographiques s'est transformée en un zoo de logos flashy remplis de formules d'articles scientifiques et a créé un sentiment général sombre que tout est cassé. Mais en fait, de nombreuses attaques sont basées sur plusieurs principes généraux, et les pages interminables de formules se résument souvent à des idées faciles à comprendre.

Dans cette série d'articles, nous examinerons différents types d'attaques cryptographiques, en mettant l'accent sur les principes de base. En termes généraux et pas tout à fait dans cet ordre, mais nous dirons ce qui suit:

• Stratégies de base: force brute, analyse de fréquence, interpolation, déclassement et protocoles croisés.
  
• Vulnérabilités de la marque: FREAK, CRIME, POODLE, DROWN, Logjam.
  
• Stratégies avancées: attaques Oracle (attaque Woden, attaque Kelsey); méthode de rencontre au milieu, attaque d'anniversaires, biais statistique (cryptanalyse différentielle, cryptanalyse intégrale, etc.).
  
• Attaques de tiers et leurs proches, méthodes d'analyse des défaillances.
  
• Attaques sur la cryptographie à clé publique: racine cubique, diffusion, message associé, attaque Coppersmith, algorithme Polyg-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 détails techniques particuliers. Nous expliquons chaque type d'attaque dans les termes les plus simples, sans fouiller dans des exemples complexes ou des cas d'utilisation avancés.

Certaines de ces attaques ont pour la plupart perdu de leur pertinence et n'ont pas été utilisées depuis de nombreuses années. D'autres sont des anciens, ils se glissent toujours régulièrement sur des développeurs de cryptosystèmes sans méfiance au 21e siècle. Nous pouvons supposer que l'ère de la cryptographie moderne a commencé avec l'avènement d'IBM DES - le premier chiffrement qui a 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 reçoit un message (texte en clair) en combinaison avec une clé, puis crée un message crypté - texte chiffré; 2) une fonction de déchiffrement qui prend un texte chiffré et une clé et crée du texte en clair. Le chiffrement et le déchiffrement devraient être faciles à calculer avec la clé - et difficiles sans elle.

Supposons que nous voyons du texte chiffré et essayons de le déchiffrer sans aucune information supplémentaire (c'est ce qu'on appelle une attaque de texte chiffré uniquement). Si, par magie, nous trouvons 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 deux hypothèses implicites. Premièrement, que nous savons comment effectuer le déchiffrement, c'est-à-dire comment fonctionne le cryptosystème. Il s'agit d'une hypothèse standard lors de la discussion sur la cryptographie. Masquer les détails de l'implémentation du chiffrement aux intrus peut sembler une mesure de sécurité supplémentaire, mais dès que l'intrus découvre ces détails, cette sécurité supplémentaire est invisible et irréversiblement perdue. C'est le principe de Kerchhoffs : tomber entre les mains de l'ennemi ne devrait pas gêner.

Deuxièmement, nous supposons que la bonne clé est la seule clé qui conduira à un décryptage raisonnable. Il s'agit également d'une hypothèse raisonnable; il est exécuté si le texte chiffré est beaucoup plus long que la clé et est bien lu. En règle générale, c'est ce qui se passe dans le monde réel, à l'exception d' énormes clés impraticables ou d' autres fraudes, qu'il vaut mieux laisser de côté (si vous n'aimez pas que nous ayons rejeté les explications, veuillez consulter le théorème 3.8 ici ).

Compte tenu de ce qui précède, une stratégie se pose: vérifiez 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 chiffres pratiques - à la fin. Par exemple, la force brute suffit 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 cryptanalystes, l'augmentation de la taille de la clé protège contre la force brute. À mesure que la taille de la clé augmente, le nombre de clés possibles augmente de façon exponentielle. Avec des tailles de clés modernes, une force brute simple n'est pas du tout pratique. Pour comprendre ce que nous voulons dire, prenons le supercalculateur le plus rapide connu à la mi-2019: IBM's Summit , avec des performances de pointe de l'ordre de 10 ¹⁷ opérations par seconde. Aujourd'hui, une longueur de clé typique est de 128 bits, ce qui signifie ²¹²⁸ combinaisons possibles. L'énumération de toutes les clés nécessite que le supercalculateur Summit prenne environ 7800 fois 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 cuisine de la cryptanalyse. On trouve rarement des chiffres aussi faibles qu'ils ne peuvent être fissurés qu'avec une attaque intelligente, sans recourir à la force à un degré ou à un autre. De nombreux hacks réussis utilisent d'abord la méthode algorithmique pour affaiblir le chiffrement cible, puis exécuter la force brute.

Analyse de fréquence

La plupart des textes ne sont pas du charabia. Par exemple, dans les textes anglais, il y a beaucoup de lettres «e» et d'articles «the»; dans les fichiers binaires - beaucoup d'octets nuls comme espace réservé entre les éléments d'information. L'analyse de fréquence est toute attaque qui exploite ce fait.

Un exemple canonique d'un chiffre vulnérable à cette attaque est un simple chiffre de substitution. Dans ce chiffre, la clé est une table avec le remplacement de toutes les lettres. Par exemple, 'g' est remplacé par 'h', 'o' par j, donc le mot 'go' se transforme en 'hj'. Ce chiffrement est difficile à simple force brute, car il existe de nombreuses tables de recherche possibles. Si vous êtes intéressé par les mathématiques, la longueur de clé effective est d'environ 88 bits: ce
$$$log_2 (26!)$ . Mais l'analyse de fréquence fait généralement le travail rapidement.

Considérez le texte chiffré suivant traité avec un chiffrement de substitution simple:

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

Puisque Y est commun, y compris à la fin de nombreux mots, nous pouvons supposer que c'est la lettre e :

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

La paire XD est répétée au début de quelques mots. En particulier, la combinaison de XDeLe implique explicitement le mot these ou there , nous continuons donc:

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

Supposons en outre que L correspond à r , A - a etc. Vous devrez probablement faire plusieurs tentatives, mais par rapport à la force brute totale, cette attaque restaure le texte source dès que possible:

  il y a plus de choses dans le ciel et la terre horatio que ce dont on rêve dans votre philosophie 

Pour certains, la solution à de tels «cryptogrammes» est un passe-temps fascinant.

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 chiffres beaucoup plus complexes. Tout au long de l'histoire, divers modèles de chiffrement ont tenté de résister à une telle attaque en utilisant la «substitution polyalphabétique». Ici, dans le processus de cryptage, la table de remplacement des lettres change de manière complexe mais prévisible en fonction de la clé. Tous ces chiffres étaient autrefois considérés comme difficiles à casser; et pourtant une analyse de fréquence modeste a fini par les vaincre tous.

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 à la suite d'un travail long et dur, les cryptanalystes britanniques l'ont craqué en utilisant l'analyse de fréquence. Bien sûr, ils ne pouvaient pas développer une attaque élégante, comme indiqué ci-dessus; ils ont dû comparer des paires bien connues de textes ouverts et chiffrés (ce qu'on appelle «l'attaque en texte brut») et même inciter les utilisateurs d'Enigma à chiffrer certains messages avec une analyse du résultat («attaque basée sur un texte en clair sélectionné»). Mais cela n'a pas facilité le sort des armées d'ennemis vaincus et des sous-marins coulés.

Après ce triomphe, l'analyse fréquentielle a disparu de l'histoire de la cryptanalyse. Les chiffres de l'ère numérique moderne sont conçus pour fonctionner avec des bits, pas des lettres. Plus important encore, ces chiffres sont conçus avec une 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 chiffrement qu'il ne peut lui-même déchiffrer. Il ne suffit pas que le système de cryptage semble compliqué: pour prouver sa valeur, il doit passer par un examen de sécurité impitoyable de nombreux cryptanalystes qui feront tout leur possible pour déchiffrer le chiffrement.

Calculs préliminaires

Prenez la ville hypothétique de Precom Heights avec une population de 200 000 habitants. Dans chaque maison de la ville, il y a des objets de valeur en moyenne 30 000 $, mais pas plus de 50 000 $. Le marché de la sécurité de Precom était monopolisé par ACME Industries, qui produit les légendaires serrures de porte de classe Coyote (tm). Selon une analyse d'experts, seule une machine hypothétique très complexe peut briser un verrou de classe Coyote, dont la création nécessite environ cinq ans et un investissement de 50000 $. La ville est-elle sûre?

Probablement pas. Au final, un criminel assez ambitieux apparaîtra. Il raisonnera ainsi: «Oui, j'engagerai des frais initiaux importants. Cinq ans d'attente pour les patients et 50 000 $, mais après avoir terminé mes travaux, j'aurai accès à toutes les richesses de cette ville . Si je joue correctement mes cartes, cet investissement sera payant plusieurs fois. »

De même, en cryptographie. Les attaques contre un chiffrement spécifique sont soumises à une analyse impitoyable des coûts et des avantages. Si le rapport est favorable, l'attaque ne se produira pas. Mais les attaques qui attaquent immédiatement de nombreuses victimes potentielles sont presque toujours payantes, et dans ce cas, la meilleure pratique de conception est de 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 vraiment casser le système cassera le système."

L'exemple le plus simple d'un cryptosystème vulnérable à une attaque avec des calculs préliminaires est un chiffre avec un algorithme constant sans utiliser de clé. Ce fut le cas avec le chiffre César , qui déplace simplement chaque lettre de l'alphabet de trois lettres vers l'avant (le tableau est bouclé, donc la dernière lettre de l'alphabet est cryptée avec la troisième). Là encore, le principe Kerchhoffs se manifeste: dès que le système est piraté, il est piraté pour toujours.

Le concept est simple. Même un développeur novice de cryptosystème est susceptible d'être conscient de la menace et de se préparer en conséquence. Si vous regardez l'évolution de la cryptographie, de telles attaques étaient inappropriées pour la plupart des chiffrements, à commencer par les premières versions améliorées du chiffrement de César, jusqu'au déclin des chiffrements polyalphabétiques. De telles attaques ne sont revenues qu'avec l'avènement de l'ère moderne de la cryptographie.

Ce retour est dû à deux facteurs. Tout d'abord, enfin, des cryptosystèmes assez complexes sont apparus, où la possibilité d'exploitation après piratage n'était pas évidente. Deuxièmement, la cryptographie est si répandue que des millions de profanes décident chaque jour de l'endroit et des parties de la cryptographie à réutiliser. Il a fallu un certain temps avant que les experts ne se rendent compte des risques et sonnent l'alarme.

Souvenez-vous de l'attaque avec des précalculs: à la fin de l'article, nous considérerons deux exemples cryptographiques de la vie réelle, où il a joué un rôle important.

Interpolation

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

J'ai tout de suite deviné que vous veniez d'Afghanistan ... Mes pensées étaient les suivantes: «Cette personne est un médecin par type, mais il a un caractère militaire. Donc, un médecin militaire. Il venait juste d'arriver des tropiques - son visage est sombre, mais ce n'est pas une teinte naturelle de sa peau, car ses poignets sont beaucoup plus blancs. Le visage émacié, évidemment, a beaucoup souffert et a souffert de la maladie. Il a été blessé à la main gauche - il la tient immobile et un peu contre nature. Où, sous les tropiques, un médecin britannique pourrait-il subir des épreuves et se blesser? Bien sûr, en Afghanistan. » L'ensemble de la pensée n'a pas pris une seconde. Et donc j'ai dit que vous veniez d'Afghanistan, et vous avez été surpris.

De chaque preuve individuellement, Holmes a pu extraire très peu d'informations. Il ne pouvait arriver à sa conclusion qu'en les examinant tous ensemble. L'attaque d'interpolation fonctionne de la même manière, en explorant les paires connues de textes ouverts et chiffrés obtenues grâce à l'application de la même clé. Des observations distinctes sont extraites de chaque paire, ce qui nous permet de tirer une conclusion générale sur la clé. Toutes ces conclusions sont vagues et inutiles jusqu'à ce qu'elles atteignent soudain une masse critique et conduisent à la seule conclusion possible: aussi incroyable soit-elle, cela doit être vrai. Après cela, soit la clé est ouverte, soit le processus de déchiffrement devient tellement mature qu'il peut être dupliqué.

Nous illustrons avec un exemple simple le fonctionnement de l'interpolation. Supposons que nous voulions lire le journal intime de notre ennemi, Bob. Il crypte chaque numéro de son journal à l'aide d'un simple cryptosystème, dont il a entendu parler grâce à une publicité dans le magazine "Mockery of cryptography". Le système fonctionne comme suit: Bob sélectionne deux nombres qu'il aime: $$$M$ et $$$N$ . Désormais, pour crypter n'importe quel nombre $$$x$ il calcule $$$Mx + N$ . Par exemple, si Bob a choisi $$$M = 3$ et $$$N = 4$ alors le chiffre $$$2$ crypté comme $$ .

Supposons que nous ayons remarqué le 28 décembre que Bob grattait quelque chose dans son journal. Quand il a fini, nous le prenons tranquillement et voyons la dernière entrée:

Date: 235/520

Cher journal,

Aujourd'hui était une bonne journée. Après 64 jours, j'ai rendez-vous avec Alice, qui habite dans l'appartement 843 . Je pense vraiment qu'elle peut avoir 26 !

Puisque nous avons très sérieusement l'intention de suivre Bob à sa date (dans ce scénario, nous avons 15 ans), il est essentiel de connaître la date, ainsi que l'adresse d'Alice. Heureusement, nous remarquons que le cryptosystème de Bob est vulnérable à une attaque d'interpolation. Nous ne savons peut-être pas $$$M$ et $$$N$ , mais nous connaissons la date d'aujourd'hui, nous avons donc deux paires de «texte en clair - texte chiffré». À savoir, nous savons que $$ crypté dans $$ et $$ - dans $$$520$ . Ce que nous écrivons:

$$

$$M ∗ 12 + N = 235$$

$$

$$M ∗ 27 + N = 520$$

Puisque nous avons 15 ans, nous connaissons déjà le système de deux équations à deux inconnues, qui dans cette situation suffit à trouver $$$M$ et $$$N$ sans aucun problème. Chaque paire de «texte en clair / texte chiffré» impose une contrainte sur la clé de Bob, et deux contraintes ensemble suffisent pour restaurer complètement la clé. Dans notre exemple, la réponse $$$M = 19$ et $$$N = 7$ (à $$ $$$x = 1$ , donc 26 dans le journal correspond au mot «l'un», c'est-à-dire «le même» - env. par.) .

Les attaques par interpolation, bien sûr, ne se limitent pas à de tels exemples simples. Chaque cryptosystème, qui se résume à un objet mathématique bien compris et à une liste de paramètres, risque une attaque d'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 des choses aussi laides que possible". Les attaques par interpolation sont probablement largement à blâmer. Bob peut soit utiliser un design mathématique élégant, soit garder la confidentialité d'une date avec Alice - mais hélas, généralement, vous ne pouvez pas obtenir les deux. Cela deviendra très clair lorsque nous passerons enfin au sujet de la cryptographie à clé publique.

Protocole croisé / rétrogradation

Dans le film «L'illusion de la tromperie» (2013), un groupe d'illusionnistes tente de tromper tout l'état du magnat de l'assurance corrompu Arthur Tressler dans la tromperie. Pour accéder au compte bancaire d'Arthur, les illusionnistes doivent soit fournir son nom d'utilisateur et son mot de passe, soit le faire apparaître personnellement dans la banque et participer au programme.

Les deux options sont très difficiles; les gars ont l'habitude de se produire sur scène et de ne pas participer aux opérations de renseignement. Par conséquent, ils choisissent la troisième option: leur complice appelle la banque et fait semblant d'être Arthur. La banque pose plusieurs questions pour la vérification de l'identité, telles que le nom de l'oncle et le nom du premier animal de compagnie; nos héros à l'avance obtiennent facilement ces informations d'Arthur à l'aide d'une ingénieuse ingénierie sociale . Désormais, une excellente sécurité par mot de passe n'a plus d'importance.

(Selon une légende de la ville, que nous avons personnellement vérifiée et confirmée, le cryptographe Eli Behem est tombé sur un caissier de banque qui a insisté pour poser une question secrète. Lorsque la caissière a demandé le nom de la grand-mère de sa mère, Beeham a commencé à dicter: «Capital X, petit y, trois ... ").

Il en va de même en cryptographie, si deux protocoles cryptographiques sont utilisés en parallèle pour protéger le même actif, alors que l'un est beaucoup plus faible que l'autre. Le système résultant devient vulnérable à une attaque inter-protocoles lorsqu'un protocole plus faible est attaqué pour atteindre le prix sans toucher à un plus fort.

Dans certains cas complexes, il ne suffit pas de contacter le serveur en utilisant un protocole plus faible, et la participation involontaire d'un client légitime est requise. Cela peut être organisé à l'aide d'une attaque dite de 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 aient eu des circonstances imprévues, à la suite desquelles un tel dialogue a eu lieu:

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

Caissier: Super. Veuillez consulter votre livre de code secret personnel, page 28, mot 3. Tous les messages suivants seront chiffrés avec ce mot particulier comme clé. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV ...

Cracker: Hé hé, attendez une minute. Est-ce vraiment nécessaire? Ne pouvons-nous pas simplement parler comme des gens normaux?

Caissier: Je ne conseille pas de faire cela.

Cracker: J'ai juste ... écoutez, j'ai eu une mauvaise journée, d'accord? Je suis un client VIP et je ne suis pas d'humeur à me plonger dans ces stupides livres de code.

Caissier: Bon. Si vous insistez, monsieur Tressler. Que veux-tu?

Cracker: S'il vous plaît, je voudrais transférer tout mon argent au Fonds national des victimes Arthur Tressler.

(Pause)

Caissier: D'accord. Veuillez fournir votre code PIN pour les transactions importantes.

Cracker: Mon quoi?

Caissier: À 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 d'un compte.

Cracker: ... je l'ai perdu. Est-ce vraiment nécessaire? Vous ne pouvez pas simplement approuver l'accord?

Caissier: Aucun. Je suis désolé, monsieur 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 à la boîte aux lettres.

Nos héros reportent l'opération. Ils écoutent plusieurs transactions importantes de Tressler, espérant entendre un code PIN; mais à chaque fois la conversation se transforme en charabia chiffré avant que quelque chose d'intéressant ne retentisse. Enfin, un jour, le plan est mis en œuvre. Ils attendent patiemment le moment où Tressler doit effectuer une transaction majeure par téléphone, il se connecte à la ligne, puis ...

Thressler: Bonjour. Je souhaite émettre une transaction à distance, s'il vous plaît.

Caissier: Super. Veuillez consulter votre livre de code secret personnel, page ...

(Le cracker appuie sur le bouton; la voix du caissier se transforme en un bruit inaudible).

Caissier: - # @ $ # @ $ # * @ $$ @ # * sera crypté avec ce mot comme clé. AAAYRR PLRQRZ MMNJK LOJBAN ...

Thressler: Désolé, je n'ai pas bien compris. Encore une fois Quelle page? Quel est le mot?

Caissier: Ceci est la page @ # $ @ # * $) # * # @ () # @ $ (# @ * $ (# @ *.

Thressler: Quoi?

Caissier: Numéro de mot vingt @ $ # @ $ #% # $.

Thressler: Sérieusement! Assez c'est assez! Vous et votre protocole de sécurité êtes une sorte de cirque. Je sais que tu peux juste parler normalement avec moi.

Caissier: je ne conseille pas ...

Thressler: Et je ne vous conseille pas de perdre mon temps. Je ne veux pas en savoir plus avant d'avoir résolu les problèmes de ma ligne téléphonique. Pouvons-nous organiser cet accord ou non?

Caissier: ... oui. Bon. Que veux-tu?

Thressler: Je voudrais transférer 20 000 $ à Lord Business Investments, numéro de compte ...

Caissier: Un instant, s'il vous plaît. C'est un gros problème. Veuillez fournir votre code PIN pour les transactions importantes.

Thressler: Quoi? Oh, bien sûr. 1234.

Voici l'attaque d'automne. Le protocole plus faible, «parlez directement», était conçu comme une option en cas d'urgence. Et pourtant nous sommes là.

Vous pouvez vous demander qui, dans son bon sens, va concevoir un véritable système tel que «sûr jusqu'à ce qu'il en soit autrement», qui est décrit ci-dessus. Mais tout comme une banque fictive prend des risques pour sauver des clients qui n'aiment pas la cryptographie, les systèmes dans leur ensemble ont souvent tendance à répondre à des exigences indifférentes, voire ouvertement hostiles à la sécurité.

C'est exactement l'histoire qui s'est produite avec SSLv2 en 1995. Le gouvernement américain a depuis longtemps commencé à considérer la cryptographie comme une arme qui est mieux tenue à l'écart des ennemis externes et internes. Les fragments de code ont été approuvés individuellement pour l'exportation des États-Unis, souvent soumis à un affaiblissement intentionnel de l'algorithme. Netscape, le développeur du navigateur le plus populaire, Netscape Navigator, n'a obtenu l'autorisation SSLv2 qu'avec une clé RSA initialement vulnérable de 512 bits (et 40 bits pour RC4).

À la fin du millénaire, les règles se sont assouplies et l'accès au cryptage moderne est devenu largement disponible. Cependant, les clients et les serveurs prennent en charge depuis de nombreuses années une cryptographie «d'exportation» affaiblie en raison de la même inertie qui maintient la prise en charge de tout système hérité. Les clients pensaient qu'ils pourraient rencontrer un serveur qui ne prend en charge rien d'autre. Les serveurs ont fait de même. Bien sûr, SSL dicte que les clients et les serveurs ne doivent jamais utiliser un protocole faible lorsque le meilleur est disponible. Mais le même principe était valable pour Tressler et sa banque.

Cette théorie a trouvé application dans deux attaques de haut niveau qui ont ébranlé la sécurité du protocole SSL l'une après l'autre en 2015, toutes deux découvertes par des chercheurs de Microsoft et de l' INRIA . Tout d'abord, en février, les détails de l'attaque FREAK ont été révélés, et trois mois plus tard, une autre attaque similaire appelée Logjam, dont nous discuterons plus en détail lorsque nous nous tournerons vers des attaques contre la cryptographie à clé publique.

La vulnérabilité FREAK (également connue sous le nom de "Smack TLS") est apparue lorsque les chercheurs ont analysé la mise en œuvre du TLS client / serveur et trouvé une curieuse erreur. Dans ces implémentations, si le client ne demande même pas une cryptographie d'exportation faible, mais que le serveur répond toujours avec de telles clés, le client dit «OK» et passe à un ensemble de chiffrement faible.

À cette époque, tout le monde considérait que la cryptographie d'exportation était obsolète et interdite d'utilisation.L'attaque a donc été un véritable choc et a touché de nombreux domaines importants, notamment les sites de la Maison Blanche, du fisc américain et de la NSA. Pire, il s'est avéré que de nombreux serveurs vulnérables ont optimisé les performances en réutilisant les mêmes clés plutôt qu'en en créant de nouvelles pour chaque session. Cela a permis, après abaissement du protocole, de réaliser une attaque avec précalcul: le piratage d'une clé est resté relativement cher (100 $ et 12 heures au moment de la publication), mais le coût pratique de l'attaque de la connexion a été significativement réduit. Il suffit de récupérer une fois la clé du serveur et de casser les chiffres pour toutes les connexions suivantes.

Et avant de continuer, nous devons mentionner une attaque avancée ...

Attaque Oracle

Moxie Marlinspike est surtout connu comme le père du messager cryptographique multiplateforme Signal; — (Cryptographic Doom Principle). , : « - , ». : « , , ».

, ; . « » - , , .

Par exemple, prenez une conception fictive avec un chiffre de substitution vulnérable, puis montrez une attaque possible. Bien que nous ayons déjà vu une attaque contre un chiffrement de substitution utilisant l'analyse de fréquence, ce n'est pas simplement «une autre façon de casser le même chiffrement». Inversement, 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, un simple chiffre n'est choisi que pour rendre l'exemple plus clair.

, , , . : 20 . , - , - , 20 . , : a , bb , ccc , dddd . . , .

Lorsque Alice ou Bob reçoit le message, ils vérifient d'abord que le message est de la bonne longueur (20 caractères) et que le suffixe est le texte factice correct. Si ce n'est pas le cas, ils répondent avec le message d'erreur correspondant. Si la longueur du texte et du texte fictif est en ordre, le destinataire lit le message lui-même et envoie une réponse cryptée.

Pendant l'attaque, l'attaquant fait semblant d'être Bob et envoie de faux messages à Alice. Messages - un non-sens complet - l'attaquant n'a pas de clé, et donc il ne peut pas simuler un message significatif. Mais comme le protocole viole le principe du destin, un attaquant peut toujours piéger Alice, afin qu'elle révèle des informations sur la clé, comme indiqué ci-dessous.

: PREWF ZHJKL MMMN. LA

: .

: PREWF ZHJKL MMMN. LB

: .

: PREWF ZHJKL MMMN. LC

: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

, , , C a , .

: REWF ZHJKL MMMN. LAA

: .

: REWF ZHJKL MMMN. LBB

: .

…

: REWF ZHJKL MMMN. LGG

: .

: REWF ZHJKL MMMN. LHH

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

, , , , H b, .

, .

, . , , . , , , — , , « ».

, « », , . , -, , , . , .

Il y a beaucoup à changer dans ce scénario. Les personnages auxquels Alice réagit, ou la différence même de son comportement, ou même 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. L'implémentation de base de cette attaque a permis de détecter plusieurs erreurs de sécurité que nous aborderons sous peu; mais il faut d'abord tirer quelques leçons théoriques. Comment utiliser ce «script Alice» fictif dans une attaque capable de travailler sur un véritable chiffrement moderne? Est-ce possible, même en théorie?

En 1998, le cryptographe suisse Daniel Bleichenbacher a répondu à cette question par l'affirmative. Il a démontré une attaque oracle dans un cryptosystème à clé publique RSA largement utilisé 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 au schéma ou non; c'était suffisant pour lancer une 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 script d'Alice ci-dessus - sauf qu'au lieu d'un chiffre fictif, il a craqué toute une classe respectable de chiffres modernes que les gens ont vraiment utiliser. En particulier, l'attaque de Wodene cible les chiffrements avec une taille d'entrée fixe («chiffrement par blocs») lorsqu'ils sont utilisés dans le soi-disant «mode de chiffrement CBC» et avec un certain schéma de remplissage populaire, essentiellement équivalent à celui du script d'Alice.

Toujours en 2002, le cryptographe américain John Kelsey, co-auteur de Twofish — , , . , , . , .

( , ). , ; , , .

Pour comprendre l'attaque de Woden, vous devez d'abord parler un peu plus des chiffres de bloc et des modes de chiffrement. Un «chiffrement par bloc» est, comme déjà mentionné, un chiffrement qui accepte une clé et entre une certaine longueur fixe («longueur de bloc») et produit un bloc chiffré de la même longueur. Les chiffrements par blocs sont largement utilisés et sont considérés comme relativement sûrs. Le DES maintenant retraité, considéré comme le premier chiffrement moderne, était en bloc. Comme mentionné ci-dessus, il en va de même pour l'AES, largement utilisé aujourd'hui.

Malheureusement, les chiffres de bloc ont une faiblesse flagrante. Une taille de bloc typique est de 128 bits ou 16 caractères. De toute évidence, la cryptographie moderne nécessite de travailler avec des données d'entrée plus importantes, et c'est là que les modes de cryptage apparaissent. Le mode de cryptage est essentiellement un hack: c'est un moyen d'appliquer en quelque sorte un chiffrement par bloc, qui n'accepte des données d'entrée que d'une certaine taille, pour entrer des données d'une longueur arbitraire.

L'attaque de Woden se concentre sur le mode de fonctionnement populaire de CBC (chaînage de blocs de chiffrement, mode de couplage de blocs de texte chiffré). L'attaque voit le chiffre du bloc de base comme une boîte noire imprenable magique et contourne complètement sa sécurité.

Voici un diagramme qui montre comment fonctionne le 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. Effectuer une opération XOR sur le deuxième bloc de texte en clair avec le premier bloc de texte chiffré.
   
2. Chiffrez le bloc reçu à l'aide d'un chiffrement de bloc à l'aide d'une clé.

Étant donné que CBC utilise l'opération XOR binaire de manière si intensive, prenons un moment pour rappeler certaines de ses propriétés:

• Idempotence: $$$A \oplus 0 = A$
  
• Commutativité: $$$A \oplus B = B \oplus A$
  
• Associativité: $$$A \oplus (B \oplus C) = (A \oplus B) \oplus C$
  
• Auto-réversibilité: $$$A \oplus A = 0$
  
• Octet-octet: octet n de $$( A ⊕ B ) = (octet n de$(A \oplus B)$$$$A$ ) $$⊕ (octet n de$\oplus$$$$B$ )

En règle générale, ces propriétés impliquent que si nous avons une équation qui inclut les opérations XOR et une inconnue, elle peut être résolue. Par exemple, si nous savons que$$A ⊕ X = B avec inconnu$A \oplus X = B$$$X et célèbre$X$$$$A$ et $$B , alors nous pouvons compter sur les propriétés ci-dessus pour résoudre l'équation de$B$$$$X$ . Appliquer XOR des deux côtés de l'équation avec $$A nous obtenons$A$$$$X = A \oplus B$ . .

. :

• , a , bb , ccc . , N N ( 01 02 02, 03 03 03 ). .
  
• , , « ». ; , .

:

• , ( ), , . .

C'est la principale différence - la dernière pièce du puzzle pour comprendre l'attaque de Woden, alors réfléchissons un instant à pourquoi et comment organiser une attaque oracle sur CBC.

Supposons qu'un texte chiffré CBC de 247 blocs soit donné et que nous voulons le décrypter. Nous pouvons envoyer de faux messages au serveur, comme auparavant, nous pouvions envoyer de faux messages à Alice. Le serveur déchiffrera les messages pour nous, mais il ne montrera pas le déchiffrement - à la place, encore une fois, comme dans le cas d'Alice, le serveur ne rapportera qu'un seul bit d'information: en clair, c'est le remplissage valide ou non.

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

$$

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

Nous appelons cela l'équation d'Alice. Nous contrôlions le texte chiffré; le serveur (Alice) a fusionné des informations vagues sur le texte en clair reçu; et cela nous a permis d'afficher des informations sur le dernier facteur - la clé. Par analogie, si nous pouvons trouver une telle connexion pour le script CBC, nous pourrions également y extraire des informations secrètes.

Heureusement, il existe vraiment des relations que nous pouvons utiliser. Considérez la sortie de l'appel final de déchiffrement par chiffrement par blocs et désignez ces données comme$$$W$ . Indique également les blocs de texte en clair $$P 1 , P 2 , . . . et blocs de texte chiffré$P_1, P_2,...$$$$C_1,C_2,...$ . Jetez un autre coup d'œil au tableau de la CBC et notez qu'il s'avère:

$$

$$C_{246} \oplus W = P_{247}$$

Nous appelons cela «l'équation CBC».

Dans le scénario d'Alice, en surveillant le texte chiffré et en observant la fuite d'informations sur le texte en clair correspondant, nous avons pu organiser une attaque qui a restauré le troisième terme de l'équation - la clé. Dans le scénario CBC, nous contrôlons également le texte chiffré et observons les fuites d'informations dans le texte en clair correspondant. Si une analogie se vérifie, nous pouvons obtenir des informations sur$$$W$ .

Supposons que nous ayons vraiment restauré $$W , alors quoi? Eh bien, alors nous pouvons immédiatement imprimer le dernier bloc entier de texte en clair ($W$$$P 247 ) en tapant simplement$P_{247}$$$C 246 (que nous avons) etreçu$C_{246}$
$$W dans l'équation CBC. Donc, nous sommes optimistes quant au plan général d'attaque, et il est temps de travailler sur les détails. Nous prêtons attention à la façon exacte dont le serveur fuit les informations en texte brut. Dans le script d'Alice, une fuite s'est produite car Alice n'a répondu au bon message que si$W$

$$SIMPLE_SUBSTITUTION(texte chiffré,clé)$\text{SIMPLE_SUBSTITUTION}(\text{ciphertext},\text{key})$se terminait par une ligne a(ou bb, et ainsi de suite, mais les chances de déclenchement accidentel de ces conditions étaient très faibles). De même avec CBC, le serveur accepte le remplissage si et seulement si$$C 246 ⊕ W se termine en hexadécimal. Essayons donc la même astuce: envoyer de faux chiffrements avec nos propres fausses valeurs$C_{246} \oplus W$01$$C 246 jusqu'à ce que le serveur accepte le remplissage. Lorsque le serveur accepte le remplissage pour l'un de nos faux messages, cela signifie que:$C_{246}$

$$

$$C_{246} \oplus W = \text{ hex 01 }$$

Utilisez maintenant la propriété d'octet XOR:

$$

$$(\text{ } C_{246}) \oplus (\text{ }W) = \text{hex 01}$$

Nous connaissons le premier et le troisième membre. Et nous avons déjà vu que cela vous permet de restaurer le membre restant - le dernier octet de$$$W$ :

$$

$$(\text{ } W) = (\text{ } C_{246}) \oplus (\text{hex 01})$$

Il nous donne également le dernier octet du dernier bloc de texte en clair à travers l'équation CBC et la propriété d'octet.

Nous pourrions nous retrouver avec cela et être satisfaits d'avoir attaqué un chiffre théoriquement robuste. Mais en fait, nous pouvons faire beaucoup plus: nous pouvons vraiment restaurer l'intégralité du texte. Cela nécessite une certaine astuce, qui n'était pas dans le script original d'Alice et qui n'est pas incluse dans les prérequis pour une attaque oracle, mais la méthode vaut quand même la peine d'être explorée.

Pour le comprendre, notez d'abord qu'à la suite de la dérivation de la valeur correcte du dernier octet$$W nous avons une nouvelle capacité. Maintenant, lors de la simulation de textes chiffrés, nous pouvons contrôler le dernier octet du texte en clair correspondant. Encore une fois, cela est dû à l'équation CBC et à la propriété byte:$W$

$$

$$(\text{ } C_{246}) \oplus (\text{ } W) = \text{ } P_{247}$$

Puisque nous connaissons maintenant le deuxième terme, nous pouvons utiliser notre contrôle du premier pour contrôler le troisième. Nous calculons simplement:

$$

$$(\text{ } C_{246}) = (\text{ } P_{247}) \oplus (\text{ } W)$$

, $$$W$ .

? , , 02 . , 02 02 . , , 02. , , . :

$$

$$(\text{ } C_{246}) \oplus (\text{ } W) = \text{hex 02}$$

Et nous restaurons l'avant-dernier octet $$W exactement le même que celui restauré en dernier. Nous continuons dans la même veine: nous corrigeons les deux derniers octets de texte en clair, répétons cette attaque pour le troisième octet à partir de la fin de l'octet, et ainsi de suite, pour finalement restaurer complètement$W$03 03$$$W$ .

Et le reste du texte? Veuillez noter que la valeur$$W est en fait$W$$$BLOCK_DECRYPT(clé,C247 )$\text{BLOCK_DECRYPT}(\text{key},C_{247})$ . Nous pouvons mettre n'importe quel autre bloc à la place $$C 247 , et l'attaque sera toujours réussie. En fait, on peut demander au serveur de faire$C_{247}$$$BLOCK_DECRYPT$\text{BLOCK_DECRYPT}$ . — ( CBC, ; , IV ).

, .

, , . 2002 — . , , ? , .

. -, ; . -, , «» , ( — « »).

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

Texte clair 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Texte 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 vous devez deviner quel texte chiffré correspond à quel texte en clair:

Ciphertext 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Ciphertext 2: DWKJZXYU

La réponse est claire. Parmi les textes en clair, seul le texte en clair 1 a pu être compressé à la faible longueur du deuxième texte chiffré. Nous l'avons découvert sans rien savoir de l'algorithme de compression, de la clé de chiffrement ou même du chiffrement lui-même. Comparé à la hiérarchie des possibles attaques cryptographiques, c'est une sorte de 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 récupérer un texte en clair secret s'il peut forcer le serveur à chiffrer les données du formulaire (texte en clair, suivi de$$X pendant qu'il contrôle$X$$$X et peut en quelque sorte vérifier la longueur du résultat chiffré). Encore une fois, comme dans d'autres attaques oracle, nous avons le rapport:$X$

$$

$$\text{}(\text{}(\text{ , } X)) = \text{}$$

Encore une fois, nous contrôlons un membre ( $$X ), nous 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 aux autres attaques oracle que nous avons vues.Pour illustrer comment une telle attaque peut fonctionner, nous utilisons le schéma de compression fictif que nous venons de proposer: TOYZIP. Il recherche les lignes de texte qui sont déjà apparues plus tôt 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, une chaînepeut être compressée avec unelongueur de 13 octets par rapport aux 15 octets d'origine.Supposons qu'un attaquant tente de récupérer le texte en clair d'un formulaire$X$

helloworldhellohelloworld[00][00][05]

password=...où le mot de passe lui-même est inconnu. Selon le modèle d'attaque de Kelsey, un attaquant peut demander au serveur de compresser puis de chiffrer les messages de formulaire (texte en clair, suivi de$$X ) où$X$$$X est du texte libre. Une fois le serveur terminé, il indique la longueur du résultat. L'attaque se déroule comme suit:$X$

Cracker: veuillez compresser et crypter le texte en clair sans aucun remplissage.

Serveur: longueur du résultat 14.

Cracker: veuillez compresser et crypter le texte en clair auquel vous avez ajouté password=a.

Serveur: longueur du résultat 18.

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

Cracker: veuillez compresser et crypter le texte en clair auquel vous avez ajouté password=b.

Serveur: longueur du résultat 18.

Cracker: veuillez compresser et crypter le texte en clair auquel vous avez ajouté password=.

Serveur: longueur du résultat 17.

Le pirate note: [14 originaux] + [trois octets qui ont remplacé password=c]. Cela suppose que le texte en clair d'origine contient une chaîne password=c. Autrement dit, le mot de passe commence par une lettrec

Cracker: veuillez compresser et crypter le texte en clair auquel vous avez ajouté password=a.

Serveur: longueur du résultat 18.

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

Cracker: veuillez compresser et crypter le texte en clair auquel vous avez ajouté password=b.

Serveur: longueur du résultat 18.

(... quelque temps plus tard ...)

Cracker: veuillez compresser et crypter le texte en clair auquel vous avez ajouté password=.

Serveur: longueur du résultat 17.

Le pirate note: [14 originaux] + [trois octets qui ont remplacé password=co]. Par la même logique, le pirate conclut que le mot de passe commence par les lettresco

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

Le lecteur est pardonné de 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 pas promettre en cryptographie.

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

Enfin, après une étude détaillée de la théorie, nous pouvons voir comment ces méthodes sont utilisées dans de vraies attaques cryptographiques.

CRIME

Si l'attaque cible le navigateur et le réseau de la victime, quelque chose sera plus simple et quelque chose de plus compliqué. Par exemple, il est facile de voir le trafic de la victime: asseyez-vous avec elle dans le même café avec WiFi. Pour cette raison, les victimes potentielles (c'est-à-dire tout le monde) sont généralement invitées à utiliser une connexion cryptée. Ce sera plus difficile, mais il est toujours possible d'exécuter des requêtes HTTP au nom de la victime sur un site tiers (par exemple, Google). L'attaquant doit attirer la victime vers une page Web malveillante avec un script qui fera la demande. Le navigateur Web fournira automatiquement le cookie de session approprié.

Cela semble génial. Si Bob s'est connecté evil.com, le script de ce site peut-il simplement demander à Google d'envoyer un e-mail à Bob pourattacker@evil.com ? , , . ( Cross-Site Request Forgery , CSRF), 90-. , evil.com , Google ( ) : «, CSRF … … . , ». « » (same-origin policy), A , - B. evil.com google.com , .

Nous devons souligner que si Bob n'utilise pas de connexion cryptée, toutes ces protections n'ont aucun sens. Un attaquant peut simplement lire le trafic de Bob et restaurer 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 ennuyeuses de même origine. Mais, malheureusement pour le cracker, cela devient 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é, qu'il le veuille ou non. De plus, dès le tout début de la mise en œuvre du protocole, le trafic a également été compressé avant le chiffrement; il était courant de réduire la latence.

C'est là que CRIME entre en jeu .(Taux de compression Infoleak Made Easy, fuite simple grâce au taux de compression). La vulnérabilité révélée en septembre 2012 par les chercheurs en sécurité Juliano Rizzo et Thai Duong. Nous avons déjà examiné l'ensemble de la base théorique, ce qui nous permet de comprendre ce qu'ils ont fait et comment. Un attaquant peut forcer le navigateur de Bob à envoyer des demandes à Google, puis à écouter les réponses sur le réseau local sous une forme compressée et chiffrée. Par conséquent, nous avons:

$$

$$\text{-} = \text{}(\text{}(\text{ }))$$

Ici, le pirate contrôle la demande et a accès au renifleur de trafic, y compris la taille des paquets. Le scénario fictif de Kelsey s'est réalisé.

Comprenant la théorie, les auteurs de CRIME ont créé un exploit qui peut voler des cookies de session pour un large éventail de sites, y compris Gmail, Twitter, Dropbox et Github. La vulnérabilité a affecté la plupart des navigateurs Web modernes, à la suite de laquelle des correctifs ont été publiés qui ont enterré silencieusement la fonction de compression dans SSL afin qu'elle ne soit pas utilisée du tout. Le seul protégé contre cette vulnérabilité était le vénérable Internet Explorer, qui n'a jamais utilisé de 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 la vulnérabilité du protocole SSL, corrigé il y a plus de dix ans.

Il s'est avéré que bien que les serveurs exécutent le merveilleux nouveau TLSv1.2, beaucoup ont laissé la prise en charge de SSLv3 obsolète pour une compatibilité descendante avec Internet Explorer 6. Nous avons déjà parlé d'attaques de déclassement, vous pouvez donc imaginer ce qui se passe. Sabotage bien organisé du protocole de prise de contact - et les serveurs sont prêts à revenir à la bonne vieille SSLv3, annulant essentiellement les 15 dernières années de recherche sur la sécurité.

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

Transport Layer Security (TLS) — . [..] , , TLS. [..] TLS TLS. Netscape Communications "Secure Sockets Layer" SSL. , SSL , -. , SSL SSL 2 . , [..] 90-, « ». , , . SSLv2 , — , SSLv2 .

Après ces événements, en 1996, l'entreprise frustrée de Netscape a entièrement repensé SSL. Le résultat fut SSL version 3, qui corrigeait plusieurs problèmes de sécurité connus pour son prédécesseur .

Heureusement pour les crackers, «peu» ne signifie pas «tout». En général, SSLv3 a fourni tous les blocs de construction nécessaires pour lancer l'attaque Woden. Le protocole a utilisé un chiffrement par blocs en mode CBC et un schéma de remplissage dangereux (cela a été corrigé dans TLS; par conséquent, une attaque de déclassement est survenue). Si vous vous souvenez du motif de remplissage dans notre description originale de l'attaque Woden, le motif SSLv3 est très similaire.

Mais, malheureusement pour les crackers, «similaire» ne signifie pas «identique». Le schéma de remplissage SSLv3 est «N octets arbitraires suivis du nombre N». Dans ces conditions, essayez de choisir un bloc imaginaire de texte chiffré et passez par toutes les étapes du schéma Wodene original: vous constaterez que l'attaque réussit à extraire le dernier octet du bloc de texte brut correspondant, mais ne va pas plus loin. Déchiffrer tous les 16 octets de texte chiffré est une excellente astuce, mais ce n'est pas une victoire.

Face à l'échec, l'équipe de Google a eu recours à l'option extrême: elle est passée à un modèle de menace plus puissant - celui utilisé dans CRIME. En supposant que l'attaquant est un script lancé sur l'onglet du navigateur de la victime et peut extraire des cookies de session, l'attaque reste malgré tout impressionnante. Bien que le modèle de menace plus large soit moins réaliste, nous avons déjà vu dans la section précédente que ce modèle particulier est réalisable.

Compte tenu de ces capacités de pirate plus puissantes, l'attaque peut maintenant se poursuivre. Veuillez noter que l'attaquant sait où le 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. Par conséquent, il est capable de manipuler la requête HTTP afin d'aligner le dernier octet du cookie en fonction de la fin du bloc. Maintenant, cet octet convient au déchiffrement. Vous pouvez simplement ajouter un caractère à la demande, et l'avant-dernier octet des cookies restera au même endroit et pourra être sélectionné par la même méthode. L'attaque se poursuit de cette manière jusqu'à ce que le cookie soit complètement restauré. Cela s'appelle POODLE: Remplissage d'Oracle sur le cryptage hérité dégradé, remplissant l'oracle avec un cryptage obsolète réduit.

Noyer

Comme nous l'avons déjà mentionné, SSLv3 avait des défauts, mais il était fondamentalement différent de son prédécesseur, car SSLv2 qui fuyait était un produit d'une époque différente. Là, il a été possible d'interrompre le message au milieu: transformé en ; le client et le serveur pouvaient se rencontrer sur Internet, établir la confiance et échanger des secrets sous les yeux de l'attaquant, qui prétendait alors facilement être les deux. Il existe également un problème avec la cryptographie d'exportation, que nous avons mentionné lors de l'examen de FREAK. Il s'agissait de Sodome et Gomorrhe cryptographiques.

En mars 2016, une équipe de chercheurs de divers 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 vers SSLv2, car ce trou a été fermé après FREAK et POODLE, mais ils peuvent toujours se connecter aux serveurs et lancer eux-mêmes des sessions SSLv2.

, , ? , — ? , . , . — SSL , , , RSA TLS SSLv2. , - OpenSSL SSL « SSLv2».

- TLS, DROWN(Décryptage de RSA avec un cryptage électronique obsolète et affaibli, décryptage de RSA à l'aide d'un cryptage obsolète et faible). Rappelez-vous que ce n'est pas la même chose qu'une attaque de chute; un attaquant n'a pas besoin d'agir comme une «personne au milieu» et n'a pas besoin d'engager un client pour participer à une session dangereuse. Les attaquants lancent simplement une session SSLv2 non sécurisée avec le serveur eux-mêmes, attaquent un protocole faible et restaurent la clé de serveur privé RSA. Cette clé est également valable pour les connexions TLS, et à partir de maintenant aucune sécurité TLS ne la sauvera du piratage.

Mais le piratage nécessite une attaque efficace contre SSLv2, qui vous permet de restaurer non seulement un trafic spécifique, mais également la clé du serveur secret RSA. Bien qu'il s'agisse d'une production compliquée, les chercheurs ont pu choisir n'importe quelle vulnérabilité complètement fermée après SSLv2. En fin de compte, ils ont trouvé une option appropriée: l'attaque de Bleichenbacher, que nous avons mentionnée plus tôt et qui sera expliquée en détail dans le prochain article. SSL et TLS sont protégés contre cette attaque, mais certaines fonctions SSL aléatoires, combinées à des clés courtes en cryptographie de qualité export, ont rendu possible une implémentation spécifique de DROWN .

Au moment de la publication de la vulnérabilité DROWN, 25% des principaux sites Internet étaient touchés, et l'attaque pourrait être menée avec des ressources modestes disponibles même pour les pirates informatiques malveillants. Il a fallu huit heures de calcul et 440 $ pour récupérer la clé du serveur RSA, et SSLv2 a changé son statut de «obsolète» à «radioactif».

Attendez, qu'en est-il de Heartbleed?

Ce n'est pas une attaque cryptographique au sens décrit ci-dessus; il s'agit d'un débordement de tampon.

Faites une pause

: , , , - . , , : . — , : CBC .

FREAK, , , . ( ) Logjam, .

Nous avons ensuite examiné trois autres exemples d'application de ces principes. Premièrement, CRIME et POODLE: deux attaques qui reposaient sur la capacité du pirate à injecter du texte en clair arbitraire à côté du texte en clair cible, puis examinez les réponses du serveur, puis , en utilisant la méthodologie d'attaque d'Oracle, utilisez ces maigres informations pour récupérer partiellement le texte en clair. CRIME a pris le chemin de l'attaque de Kelsey contre la compression SSL, tandis que POODLE a plutôt utilisé l'attaque Woden contre CBC avec le même effet.

- DROWN, SSLv2, . ; Logjam, , .

— (meet-in-the-middle), « ». , — .