Wenn das Wort „Kryptographie“ fällt, denken einige an ihr WiFi-Passwort, das grüne Schloss neben der Adresse ihrer Lieblingswebseite und daran, wie schwierig es ist, in fremde E-Mails einzudringen. Andere hingegen erinnern sich an die Reihe von Sicherheitsanfälligkeiten der letzten Jahre, die mit einprägsamen Abkürzungen (DROWN, FREAK, POODLE…) und stylischen Logos aufwarten und vor der dringenden Notwendigkeit warnen, den Browser zu aktualisieren.

Kryptographie umfasst all dies, aber der Kern liegt woanders. Der Kern liegt in der feinen Grenze zwischen Einfachheit und Komplexität. Einige Dinge sind einfach zu machen, aber schwierig rückgängig zu machen: ein Ei zu zerbrechen beispielsweise. Andere Dinge lassen sich leicht tun, aber es ist schwierig, sie zurückzudrehen, wenn ein kleines, wichtiges Teil fehlt: zum Beispiel eine verschlossene Tür zu öffnen, wenn das „entscheidende Teil“ der Schlüssel ist. Die Kryptographie untersucht diese Situationen und die Praktiken, die sich daraus ableiten lassen.

In den letzten Jahren hat sich die Sammlung kryptographischer Angriffe in einen Zoo schreiender Logos verwandelt, überladen mit Formeln wissenschaftlicher Artikel und hat das allgemeine düstere Gefühl erzeugt, dass alles kaputt ist. Tatsächlich basieren jedoch viele dieser Angriffe auf einigen gemeinsamen Prinzipien, und die unendlichen Seiten voller Formeln lassen sich oft auf einfache, nachvollziehbare Ideen reduzieren.

In dieser Artikelreihe beleuchten wir verschiedene Arten von kryptografischen Angriffen, wobei wir uns auf die grundlegenden Prinzipien konzentrieren. Im Großen und Ganzen, wenn auch nicht ganz in dieser Reihenfolge, werden wir Folgendes behandeln:

Grundlegende Strategien: Brute-Force, Frequenzanalyse, Interpolation, Herabstufung und Cross-Protocol-Angriffe.
„Markenspezifische“ Schwachstellen: FREAK, CRIME, POODLE, DROWN, Logjam.
Fortgeschrittene Strategien: Oracle-Angriffe (Wiener-Angriff, Kelsey-Angriff); Meet-in-the-Middle, Geburtstagsangriff, statistische Verzerrung (Differential-Kryptoanalyse, Integrale Kryptoanalyse usw.).
Seitenkanalangriffe und deren nahe Verwandte, Methoden zur Fehleranalyse.
Angriffe auf die Public-Key-Kryptographie: Kubikwurzel, Broadcast, verbundenes Nachrichtensystem, Coppersmith-Angriff, Pollard-Hellman-Algorithmus, numerisches Sieb, Wiener-Angriff, Bleichenbacher-Angriff.

Dieser spezifische Artikel behandelt die oben genannten Themen bis hin zum Kelsey-Angriff.

Grundlegende Strategien

Die folgenden Angriffe sind einfach zu erklären, da sie nahezu vollständig ohne technische Details beschrieben werden können. Wir werden jeden Angriffstyp in den einfachsten Begriffen erklären, ohne uns in komplexen Beispielen oder erweiterten Nutzungsszenarien zu verlieren.

Einige dieser Angriffe sind weitgehend obsolet und wurden seit vielen Jahren nicht mehr angewendet. Andere sind hingegen alte Bekannte, die weiterhin regelmäßig ahnungslose Entwickler von Kryptosystemen im 21. Jahrhundert überfallen. Die Ära der modernen Kryptographie kann mit der Einführung des IBM DES – des ersten chiffrierten Verfahrens, das allen Angriffen in dieser Liste standhielt – als begonnen betrachtet werden.

Einfacher Brute-Force

Das Verschlüsselungsschema besteht aus zwei Teilen: 1) einer Verschlüsselungsfunktion, die eine Nachricht (Plaintext) in Verbindung mit einem Schlüssel entgegennimmt und dann eine verschlüsselte Nachricht – Ciphertext – erstellt; 2) einer Entschlüsselungsfunktion, die den Ciphertext und den Schlüssel entgegennimmt und den Plaintext erstellt. Sowohl die Verschlüsselung als auch die Entschlüsselung müssen mit dem Schlüssel leicht berechenbar sein – und schwer ohne ihn.

Angenommen, wir haben einen Chiffretext und versuchen, ihn ohne weitere Informationen zu entschlüsseln (dies wird als "Ciphertext-only-Attacke" bezeichnet). Wenn wir auf magische Weise den richtigen Schlüssel finden, können wir leicht überprüfen, ob er tatsächlich richtig ist, indem wir feststellen, dass das Ergebnis eine sinnvolle Nachricht ist.

Beachten Sie, dass hier zwei implizite Annahmen existieren. Erstens, dass wir wissen, wie die Entschlüsselung durchzuführen ist, d.h. wie das Kryptosystem funktioniert. Dies ist eine allgemeine Annahme in der Diskussion über Kryptografie. Das Verbergen von Implementierungsdetails des Verschlüsselungsverfahrens vor Angreifern mag wie eine zusätzliche Sicherheitsmaßnahme erscheinen, aber sobald der Angreifer diese Details herausfindet, ist diese zusätzliche Sicherheit unauffällig und unwiderruflich verloren. So funktioniert das Prinzip von Kerckhoffs: Der Verlust der Kontrolle über das System darf keine Schwierigkeiten verursachen.

Zweitens gehen wir davon aus, dass der richtige Schlüssel der einzige Schlüssel ist, der zu einer vernünftigen Entschlüsselung führt. Dies ist auch eine sinnvolle Annahme; sie gilt, wenn der Chiffretext deutlich länger ist als der Schlüssel und gut lesbar ist. Im Allgemeinen ist das in der realen Welt der Fall, mit Ausnahme von großen unpraktischen Schlüsseln oder und anderen Machenschaften, die besser unerwähnt bleiben (wenn Ihnen unsere Auslassungen nicht gefallen, siehe bitte Theorem 3.8 hier).

Vor dem Hintergrund ergibt sich eine Strategie: Jeden möglichen Schlüssel zu überprüfen. Dies wird als Brute-Force-Angriff bezeichnet, und ein solcher Angriff funktioniert garantiert gegen alle praktischen Chiffren — letztendlich. Zum Beispiel genügt Brute-Force, um den Caesar-Schlüssel, eine alte Chiffre, bei der der Schlüssel ein Buchstabe aus dem Alphabet ist, was etwas mehr als 20 mögliche Schlüssel impliziert.

Leider schützt eine Vergrößerung der Schlüsselgröße Kryptoanalytiker gut vor Brute-Force-Attacken. Mit der Zunahme der Schlüsselgröße steigt die Anzahl der möglichen Schlüssel exponentiell. Bei heutigen Schlüsselgrößen ist ein einfacher Brute-Force-Angriff völlig unpraktisch. Um zu verstehen, was wir meinen, betrachten wir den schnellsten bekannten Supercomputer aus der Mitte des Jahres 2019: Summit von IBM, mit einer Spitzenleistung von etwa 10^17 Operationen pro Sekunde. Heute beträgt die typische Schlüssellänge 128 Bit, was 2^128 möglichen Kombinationen entspricht. Um alle Schlüssel zu durchprobieren, würde der Supercomputer Summit eine Zeit benötigen, die etwa 7800 Mal das Alter des Universums übersteigt.

Sollte man Brute-Force als historischen Kuriosität betrachten? Ganz und gar nicht: Es ist eine notwendige Zutat im Kochbuch der Kryptoanalyse. Es gibt nur sehr selten so schwache Verschlüsselungen, dass sie ohne irgendeine Form von Gewaltanwendung nur durch clevere Angriffe geknackt werden können. Viele erfolgreiche Hacks verwenden zunächst methodische Ansätze, um die Zielverschlüsselung zu schwächen, bevor sie Brute-Force einsetzen.

Häufigkeitsanalyse

Die meisten Texte sind keine willkürlichen Buchstabensalate. Beispielsweise gibt es in englischen Texten viele Buchstaben 'e' und Artikel 'the'; in binären Dateien finden sich viele Null-Bytes als Platzhalter zwischen Informationsfragmenten. Die Frequenzanalyse ist jede Attacke, die dieses Faktum nutzt.

Ein klassisches Beispiel für einen Verschlüsselungsalgorithmus, der anfällig für diese Attacke ist, ist die einfache Substitutionsverschlüsselung. In dieser Verschlüsselung besteht der Schlüssel aus einer Tabelle, die alle Buchstaben ersetzt. Zum Beispiel wird 'g' durch 'h' ersetzt, 'o' durch 'j'. Daher wird das Wort 'go' zu 'hj'. Diese Verschlüsselung ist schwer durch einen simplen Brute-Force-Angriff zu knacken, da es sehr viele mögliche Substitutionstabellen gibt. Wenn Sie sich für Mathematik interessieren, beträgt die effektive Schlüssellänge etwa 88 Bit: das
. Aber die Frequenzanalyse kommt in der Regel schnell zum Ziel.

Betrachten wir den folgenden Chiffretext, der durch eine einfache Substitutionsverschlüsselung erzeugt wurde:

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

Da Y kommt häufig vor, insbesondere am Ende vieler Wörter, können wir vorab annehmen, dass es sich um den Buchstaben e:

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

Paar XD wiederholt sich am Anfang mehrerer Wörter. Insbesondere die Kombination XDeLe deutet eindeutig auf das Wort hin diese oder dort, deshalb machen wir weiter:

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

Nehmen wir an, dass L entspricht r, A — a und so weiter. Wahrscheinlich müssen einige Versuche unternommen werden, aber im Vergleich zu einem vollständigen Brute-Force-Verfahren ermöglicht dieser Angriff eine schnelle Wiederherstellung des ursprünglichen Texts:

Es gibt mehr Dinge zwischen Himmel und Erde, Horatio, als eure Philosophie sich je träumen ließ.

Für manche ist das Lösen solcher "Kryptogramme" ein spannendes Hobby.

Die Idee der Frequenzanalyse ist grundlegender, als es auf den ersten Blick scheint. Sie ist auch auf deutlich komplexere Verschlüsselungen anwendbar. Im Lauf der Geschichte haben verschiedene Verschlüsselungskonstruktionen versucht, solchen Angriffen durch „polyalphabetische Substitution“ zu widerstehen. Hier wird bei der Verschlüsselung die Buchstabentausch-Tabelle auf komplexe, aber vorhersehbare Weise geändert, die vom Schlüssel abhängt. All diese Verschlüsselungen galten zu ihrer Zeit als schwer zu knacken; und doch hat die bescheidene Frequenzanalyse letztlich alle überwunden.

Der ambitionierteste polyalphabetische Code in der Geschichte und vielleicht der bekannteste war der "Enigma"-Code im Zweiten Weltkrieg. Er war im Vergleich zu seinen Vorgängern relativ komplex, aber nach langem und hartnäckigem Arbeiten gelang es britischen Kryptoanalytikern, ihn durch Frequenzanalyse zu brechen. Natürlich konnten sie keinen eleganten Angriff wie den oben gezeigten entwickeln; sie mussten bekannte Paare von Klar- und Chiffretexten vergleichen (sogenannter "Angriff auf Basis von Klartexten") und sogar die Nutzer der "Enigma" dazu anstiften, bestimmte Nachrichten zu verschlüsseln, um die Ergebnisse zu analysieren ("Angriff auf Basis von ausgewähltem Klartext"). Aber das erleichterte das Schicksal der besiegten Armeen und der versenkten U-Boote nicht.

Nach diesem Triumph verschwand die Frequenzanalyse aus der Geschichte der Kryptoanalyse. Die Codes der modernen digitalen Ära sind für die Arbeit mit Bits und nicht mit Buchstaben konzipiert. Noch wichtiger ist, dass diese Codes mit dem düsteren Verständnis entwickelt wurden, was später als Schneier-Gesetz bekannt wurde: Jeder kann einen Verschlüsselungsalgorithmus erstellen, den er selbst nicht knacken kann. Es reicht nicht aus, dass das Verschlüsselungssystem komplex erscheint. Um seinen Wert zu beweisen, muss es eine gnadenlose Sicherheitsüberprüfung durch viele Kryptanalytiker bestehen, die alles daran setzen werden, den Code zu brechen. Vorläufige Berechnungen

Nehmen wir die hypothetische Stadt Prekom Heights mit einer Bevölkerung von 200.000 Menschen. In jedem Haushalt der Stadt befinden sich im Durchschnitt Wertgegenstände im Wert von 30.000 $, jedoch nicht mehr als 50.000 $. Der Sicherheitsmarkt in Prekom wird von ACME Industries monopolisiert, das legendäre Coyote ™ Türschlösser herstellt. Laut Expertenanalyse kann das Coyote-Schloss nur von einer sehr komplexen hypothetischen Maschine geknackt werden, deren Erstellung etwa fünf Jahre und 50.000 $ Investitionen erfordert. Ist die Stadt sicher?

Wahrscheinlich nicht. Schließlich wird es einen ausreichend ehrgeizigen Verbrecher geben. Er wird sich denken: „Ja, ich werde hohe Vorabkosten haben. Fünf Jahre geduldiges Warten und 50.000 $. Aber am Ende habe ich Zugang zum

ganzen Reichtum dieser Stadt. dem gesamten Reichtum dieser Stadt. Wenn ich meine Karten richtig ausspiele, wird sich diese Investition vielfach auszahlen.

Ähnlich verhält es sich in der Kryptografie. Angriffe auf einen bestimmten Verschlüsselungsalgorithmus werden gnadenlos auf Kosten-Nutzen-Analysen überprüft. Wenn das Verhältnis günstig ist, wird kein Angriff stattfinden. Diese Angriffe, die sofort gegen viele potenzielle Opfer gerichtet sind, zahlen sich jedoch fast immer aus. In diesem Fall ist die beste Designpraxis anzunehmen, dass sie vom ersten Tag an begonnen haben. Wir haben im Wesentlichen eine kryptografische Version des Murphy-Gesetzes: "Alles, was das System brechen kann, wird das System brechen."

Ein einfaches Beispiel für ein kryptografisches System, das anfällig für Angriffe mit Vorabberechnungen ist, ist ein Algorithmus mit fester Methode ohne Schlüssel. So war es im Fall des Caesar-Codes, der einfach jeden Buchstaben des Alphabets um drei Buchstaben nach vorne verschiebt (die Tabelle ist kreisförmig, daher wird der letzte Buchstabe im Alphabet durch den dritten verschlüsselt). Hier zeigt sich erneut das Kerckhoffs-Prinzip: Sobald das System gebrochen ist, ist es für immer gebrochen.

Das Konzept ist einfach. Selbst ein unerfahrener Entwickler von Kryptosystemen wird wahrscheinlich die Bedrohungen erkennen und sich entsprechend vorbereiten. Betrachtet man die Entwicklung der Kryptographie, waren solche Angriffe für die meisten Verschlüsselungsverfahren, beginnend mit den ersten verbesserten Versionen des Cäsar-Chiffres bis hin zum Rückgang polyalphabetischer Chiffren, nicht relevant. Solche Angriffe kehrten erst mit dem Eintritt in die moderne Ära der Kryptographie zurück.

Diese Rückkehr wird durch zwei Faktoren bedingt. Erstens sind endlich ausreichend komplexe Kryptosysteme entstanden, bei denen die Möglichkeit einer Ausnutzung nach einem Angriff nicht offensichtlich war. Zweitens hat die Kryptographie so weit verbreitet, dass Millionen von Laien täglich Entscheidungen darüber trafen, wo und welche Teile der Kryptographie sie wiederverwenden. Es dauerte eine Weile, bis Experten die aufgetretenen Risiken erkannten und Alarm schlugen.

Merken Sie sich den Angriff mit Vorberechnung: Am Ende des Artikels werden wir zwei kryptographische Beispiele aus der realen Welt betrachten, in denen er eine wichtige Rolle spielte.

Interpolation

Hier steht der berühmte Detektiv Sherlock Holmes, der mit einer soliden Überlegung den ahnungslosen Dr. Watson angeht:

Ich habe sofort erkannt, dass Sie aus Afghanistan kommen... Mein Gedankengang war folgender: „Dieser Mensch sieht aus wie ein Arzt, aber seine Haltung ist militärisch. Also ein Militärarzt. Er ist gerade aus den Tropen zurückgekehrt – sein Gesicht ist gebräunt, aber das ist nicht die natürliche Farbe seiner Haut, denn seine Handgelenke sind viel heller. Sein Gesicht ist erschöpft – offensichtlich hat er viel durchgemacht und eine Krankheit übertragen. Er wurde an der linken Hand verletzt – er hält sie unbeweglich und etwas unnatürlich. Wo könnte ein britischer Militärarzt in den Tropen Entbehrungen erlitten und eine Verletzung erlitten haben? Natürlich in Afghanistan.“ Der gesamte Gedankengang dauerte nicht einmal eine Sekunde. Und so sagte ich, dass Sie aus Afghanistan gekommen sind, und Sie waren überrascht.

Aus jeder einzelnen Hinweis konnte Holmes nur sehr wenig Informationen ableiten. Er konnte zu einem Schluss gelangen, indem er sie alle zusammen betrachtete. Ähnlich funktioniert ein Interpolationsangriff, der bekannte Paare von Klartext und chiffriertem Text untersucht, die resultieren, wenn derselbe Schlüssel angewendet wird. Aus jedem Paar werden einzelne Beobachtungen gewonnen, die es ermöglichen, eine allgemeine Schlussfolgerung über den Schlüssel zu ziehen. All diese Schlussfolgerungen bleiben vage und erscheinen nutzlos, bis sie plötzlich eine kritische Masse erreichen und zu einem einzigen möglichen Ergebnis führen: So unglaublich es auch sein mag, es muss wahr sein. Danach wird entweder der Schlüssel enthüllt oder der Entschlüsselungsprozess so verfeinert, dass er reproduziert werden kann.

Lassen Sie uns an einem einfachen Beispiel veranschaulichen, wie Interpolation funktioniert. Nehmen wir an, wir möchten das Tagebuch unseres Feindes Bob lesen. Er verschlüsselt jede Zahl in seinem Tagebuch mit einem einfachen Kryptosystem, von dem er aus einer Anzeige im Magazin „Spott auf Kryptographie“ erfahren hat. Das System funktioniert folgendermaßen: Bob wählt zwei Zahlen, die ihm gefallen: und Ab diesem Moment berechnet er, um eine beliebige Zahl zu verschlüsseln, . Zum Beispiel, wenn Bob gewählt hat, dann wird die Zahl und als verschlüsselt. Angenommen, am 28. Dezember haben wir bemerkt, dass Bob etwas in seinem Tagebuch kratzt. Sobald er fertig ist, nehmen wir es unbemerkt und schauen uns den letzten Eintrag an: .

Datum:

Lieber Tagebuch, 235/520
Heute war ein guter Tag. In
Tagen habe ich ein Date mit Alice, die in der Wohnung 64 wohnt. Ich glaube wirklich, dass sie 843sein könnte. Da wir sehr ernsthaft vorhaben, Bob bei seinem Date zu beobachten (in diesem Szenario sind wir 15 Jahre alt), ist es entscheidend, das Datum sowie die Adresse von Alice zu erfahren. Glücklicherweise stellen wir fest, dass Bobs Kryptosystem anfällig für Interpolationsangriffe ist. Wir müssen möglicherweise nicht wissen 26!

Da wir sehr ernsthaft darauf bedacht sind, Bob bei seinem Date zu verfolgen (in diesem Szenario sind wir 15 Jahre alt), ist es entscheidend, das Datum sowie die Adresse von Alice zu erfahren. Glücklicherweise stellen wir fest, dass Bobs Kryptosystem anfällig für eine Interpolationsattacke ist. Wir könnten es wissen oder auch nicht. und , aber wir wissen das heutige Datum, daher haben wir zwei Paare von "Klartext — Chiffretext". Genauer gesagt, wir wissen, dass in , und – dafür braucht man 10-mal weniger Hardware. . Das werden wir aufschreiben:

Da wir seit 15 Jahren im Geschäft sind, wissen wir bereits über das System von zwei Gleichungen mit zwei Unbekannten Bescheid, was in dieser Situation ausreicht, um und ohne größere Probleme zu finden. Jedes Paar "Klartext-Chiffretext" erhebt Anforderungen an Bobs Schlüssel, und zwei Einschränkungen zusammen sind ausreichend, um den Schlüssel vollständig zu rekonstruieren. In unserem Beispiel lautet die Antwort und (bei , daher 26 im Tagebuch dem Wort ‘the one’ entspricht, was ‚der Eine‘ bedeutet — Anmerkung des Übersetzers).

Interpolationsangriffe beschränken sich natürlich nicht auf so einfache Beispiele. Jedes Kryptosystem, das auf einem gut verständlichen mathematischen Objekt und einer Liste von Parametern basiert, ist anfällig für einen Interpolationsangriff — je verständlicher das Objekt, desto höher das Risiko.

Neulinge beschweren sich oft darüber, dass Kryptographie "die Kunst ist, so viele hässliche Dinge wie möglich zu entwerfen". Wahrscheinlich sind Angriffe auf die Interpolation in hohem Maße dafür verantwortlich. Bob kann entweder ein elegantes mathematisches Design nutzen oder die Privatsphäre seines Treffens mit Alice wahren – aber leider ist es in der Regel nicht möglich, beides zu bekommen. Dies wird besonders deutlich, wenn wir schließlich das Thema der asymmetrischen Kryptographie ansprechen.

Cross-Protokoll/Downgrade

Im Film "The Illusionist" (2013) versucht eine Gruppe von Illusionisten, das gesamte Vermögen des korrumpierten Versicherungsmagnaten Arthur Tressler durch Betrug zu erlangen. Um Zugang zu Arthurs Bankkonto zu erhalten, müssen die Illusionisten entweder seinen Benutzernamen und sein Passwort angeben oder ihn dazu bringen, persönlich in die Bank zu kommen und an dem Plan teilzunehmen.

Beide Optionen sind äußerst schwierig; die Leute sind es gewohnt, auf der Bühne zu stehen, und nicht an Aktionen der Geheimdienste teilzunehmen. Daher wählen sie die dritte Möglichkeit: Ihr Komplize ruft die Bank an und gibt sich als Arthur aus. Die Bank stellt einige Fragen zur Identitätsüberprüfung, wie den Namen des Onkels und den Namen des ersten Haustiers; unsere Helden erhalten diese Informationen mühelos von Arthur durch geschickte soziale Ingenieurtechniken. Ab diesem Moment spielt eine hervorragende Passwortsicherheit keine Rolle mehr.

(Laut einer städtischen Legende, die wir persönlich überprüft und bestätigt haben, traf der Krypto-Experte Eli Behem damals auf eine Kassiererin, die auf die Einrichtung einer geheimen Frage bestand. Als die Kassiererin nach dem Namen der Großmutter mütterlicherseits fragte, begann Behem zu diktieren: „Großbuchstabe X, kleines y, drei…“).

Genauso verhält es sich in der Kryptographie. Wenn zum Schutz desselben Vermögenswerts gleichzeitig zwei kryptografische Protokolle verwendet werden, wobei eines viel schwächer ist als das andere, wird das gesamte System anfällig für einen Cross-Protocol-Angriff, bei dem das schwächere Protokoll angegriffen wird, um das Ziel zu erreichen, ohne das stärkere zu berühren.

In einigen komplexen Fällen reicht es nicht aus, die Verbindung zu einem Server über ein schwächeres Protokoll herzustellen; es bedarf vielmehr ungewollter Mitwirkung eines legitimen Kunden. Dies kann durch einen sogenannten Downgrade-Angriff organisiert werden. Um diesen Angriff zu verstehen, nehmen wir an, dass unsere Illusionisten eine kompliziertere Aufgabe haben als im Film. Angenommen, ein Bankmitarbeiter (Kassierer) und Arthur stehen vor unvorhergesehenen Umständen, wodurch folgender Dialog entsteht:

Hacker: Hallo? Hier ist Arthur Tresler. Ich möchte mein Passwort zurücksetzen.
Kassierer: Gut. Bitte schauen Sie in Ihr persönliches Buch der geheimen Codes, Seite 28, Wort 3. Alle folgenden Nachrichten werden mit diesem speziellen Wort als Schlüssel verschlüsselt. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Hacker: Hey, hey, warte, warte. Ist das wirklich notwendig? Können wir nicht einfach normal sprechen?
Kassierer: Ich rate davon ab.
Hacker: Ich… hör mal, ich hatte einen schrecklichen Tag, klar? Ich bin VIP-Kunde und habe keine Lust, in diesen dummen Kodexbüchern zu wühlen.
Kassierer: Okay. Wenn Sie darauf bestehen, Herr Tresler. Was kann ich für Sie tun?
Hacker: Bitte, ich möchte all mein Geld an den Nationalen Fonds für die Opfer von Arthur Tressler überweisen.
(Pause).
Kassierer: Verstehe. Bitte geben Sie Ihren PIN-Code für große Transaktionen an.
Hacker: Meinen was?
Kassierer: Auf Ihre persönliche Anfrage hin erfordern Transaktionen dieser Größenordnung die Eingabe des PIN-Codes für große Transaktionen. Dieser Code wurde Ihnen bei der Kontoeröffnung ausgegeben.
Hacker:… Ich habe ihn verloren. Ist das wirklich notwendig? Können Sie die Transaktion nicht einfach genehmigen?
Kassierer: Nein. Es tut mir leid, Herr Tressler. Nochmals, das ist eine Sicherheitsmaßnahme, die Sie angefordert haben. Wenn Sie möchten, können wir Ihnen einen neuen PIN-Code an Ihre Adresse senden.

Unsere Helden verschieben die Operation. Sie überwachen einige große Transaktionen von Tressler in der Hoffnung, den PIN-Code zu hören; aber jedes Mal wird das Gespräch in ein verschlüsseltes Kauderwelsch verwandelt, bevor etwas Interessantes gesagt wird. Schließlich, an einem schönen Tag, setzen sie ihren Plan in die Tat um. Sie warten geduldig auf den Moment, als Tressler eine große Transaktion am Telefon durchführen muss, er verbindet sich mit der Leitung, und dann...

Tressler: Hallo. Ich möchte bitte eine entfernte Transaktion durchführen.
Kassierer: Ausgezeichnet. Bitte werfen Sie einen Blick in Ihr persönliches Buch der Geheimcodes, Seite…
(Der Hacker drückt auf den Knopf; die Stimme des Kassierers verwandelt sich in unverständliches Geräusch).
Kassierer: — #@$#@$#*@$$@#* wird mit diesem Wort als Schlüssel verschlüsselt. AAAYRR PLRQRZ MMNJK LOJBAN…
Tressler: Entschuldigung, ich habe nicht ganz verstanden. Noch einmal? Auf welcher Seite? Welches Wort?
Kassierer: Das ist die Seite @#$@#*$)#*#@()#@$(#@*$(#@*.
Tressler: Was?
Kassierer: Wort Nummer zwanzig @$#@$#%#$.
Tressler: Im Ernst! Reicht jetzt! Ihr Sicherheitsprotokoll ist ein echter Zirkus. Ich weiß, dass du einfach normal mit mir sprechen kannst.
Kassierer: Ich rate davon ab…
Tressler: Und ich rate dir, meine Zeit nicht weiter zu verschwenden. Ich möchte nicht mehr darüber hören, bis ihr eure Telefonleitung repariert habt. Können wir diesen Deal abschließen oder nicht?
Kassierer:… ja. Gut. Was darf es sein?
Tressler: Ich möchte 20.000 $ an die Firma Lord Business Investments, Kontonummer…
Kassierer: Einen Moment bitte. Das ist ein großes Geschäft. Bitte geben Sie Ihren PIN für große Transaktionen an.
Tressler: Was? Ach, genau. 1234.

Hier ist der Angriff auf den niedrigeren. Ein schwächeres Protokoll „einfach direkt sprechen“ war als Option für den Notfall gedacht. Und dennoch sind wir hier.

Man könnte sich fragen, wer im Vollbesitz seiner geistigen Kräfte ein tatsächliches System entwerfen würde, das nach dem Motto "sicher, es sei denn, man bittet um das Gegenteil" funktioniert. Doch genau wie eine fiktive Bank Risiken eingeht, um Kunden zu behalten, die kein Interesse an Kryptografie haben, sind auch Systeme oft geneigt, Anforderungen zu erfüllen, die sicherheitsneutral oder gar offen feindlich eingestellt sind.

Eine solche Geschichte ereignete sich mit dem SSLv2-Protokoll im Jahr 1995. Die US-Regierung hatte bereits frühzeitig damit begonnen, Kryptografie als eine Waffe zu betrachten, die besser von äußeren und inneren Feinden ferngehalten werden sollte. Teile des Codes wurden einzeln für den Export aus den USA genehmigt, oft unter der Bedingung, dass die Algorithmen absichtlich geschwächt werden. So erhielt das Unternehmen Netscape, Entwickler des damals populärsten Browsers Netscape Navigator, die Genehmigung für SSLv2 nur mit einem anfänglich verwundbaren 512-Bit-RSA-Schlüssel (und 40 Bit für RC4).

Bis zum Ende des Jahrtausends wurden die Regeln gelockert und der Zugang zu moderner Verschlüsselung wurde weit verbreitet. Dennoch unterstützten Kunden und Server über viele Jahre hinweg die abgeschwächte "Export"-Kryptographie aufgrund der gleichen Trägheit, die auch die Unterstützung veralteter Systeme aufrechterhielt. Kunden gingen davon aus, dass sie auf einen Server stoßen könnten, der nichts anderes unterstützt. Server hielten sich ebenfalls daran. Natürlich diktiert das SSL-Protokoll, dass Kunden und Server niemals ein schwaches Protokoll verwenden sollten, wenn ein besseres verfügbar ist. Aber dieselbe Annahme wirkte auch bei Tresler und seiner Bank.

Diese Theorie fand Anwendung in zwei spektakulären Angriffen, die nacheinander die Sicherheit des SSL-Protokolls im Jahr 2015 erschütterten, beide entdeckt von Forschern von Microsoft und INRIA. Zuerst wurden im Februar die Details des FREAK-Angriffs veröffentlicht, gefolgt drei Monate später von einem weiteren ähnlichen Angriff namens Logjam, den wir ausführlicher besprechen werden, wenn wir zu den Angriffen auf die Public-Key-Kryptographie übergehen.

Sicherheitsanfälligkeit FREAK (auch bekannt als „Smack TLS“) wurde sichtbar, als Forscher die Implementierungen von Client/Server-TLS analysierten und einen interessanten Fehler entdeckten. In diesen Implementierungen akzeptiert der Client, selbst wenn er nicht um die Nutzung schwacher Export-Kryptografie bittet, dennoch die responierenden Schlüssel des Servers – der Client sagt „Na gut“ und wechselt zu einem schwachen Cipher-Suite.

Zu dieser Zeit galt die Export-Kryptografie als veraltet und unzulässig, was den Angriff zu einem echten Schock machte und viele bedeutende Bereiche betraf, einschließlich der Websites des Weißen Hauses, des US-Steuerdienstes und der NSA. Schlimmer noch, viele anfällige Server optimierten die Leistung, indem sie dieselben Schlüssel wiederverwendeten, anstatt neue für jede Sitzung zu erstellen. Dies ermöglichte nach dem Herabsetzen des Protokolls auch eine Vorberechnung des Angriffs: Das Knacken eines Schlüssels war relativ kostspielig ($100 und 12 Stunden zum Zeitpunkt der Veröffentlichung), aber die praktischen Kosten des Angriffs auf eine Verbindung sanken erheblich. Einmal den Server-Schlüssel erraten – und die Entschlüsselung für alle nachfolgenden Verbindungen ab diesem Zeitpunkt war möglich.

Bevor wir weitermachen, sollten wir eine fortgeschrittene Angriffstechnik erwähnen…

Oracle-Angriff

Moxie Marlinspike ist bekannt als der Vater des plattformübergreifenden Kryptomessengers Signal; persönlich gefällt uns eine seiner weniger bekannten Innovationen – das Prinzip der kryptografischen Verdammnis (Cryptographic Doom Principle). Um es etwas anders zu formulieren: "Wenn ein Protokoll eine irgendeine kryptografische Operation an einer Nachricht aus potenziell schädlicher Quelle durchführt und sich unterschiedlich verhält, je nach Ergebnis, ist es zum Scheitern verurteilt." Oder in einer schärferen Form: "Nimm keine Informationen vom Feind zur Verarbeitung an, und wenn es notwendig ist, zeige zumindest nicht das Ergebnis."

Lassen wir Bufferüberläufe, Befehlseinschübe und Ähnliches beiseite; sie fallen nicht in den Rahmen dieser Diskussion. Die Missachtung des „Verdammnisprinzips“ führt zu schwerwiegenden Krypto-Hacks, da sich das Protokoll genau so verhält, wie es vorgesehen ist.

Als Beispiel nehmen wir eine fiktive Konstruktion mit einer anfälligen Substitutionsverschlüsselung und demonstrieren dann einen möglichen Angriff. Obwohl wir bereits einen Angriff auf die Substitutionsverschlüsselung durch Frequenzanalyse gesehen haben, ist dies nicht einfach „eine andere Art, denselben Schlüssel zu knacken“. Vielmehr sind Oracle-Angriffe – eine viel modernere Erfindung – anwendbar in vielen Situationen, in denen die Frequenzanalyse scheitert. Dies werden wir im nächsten Abschnitt demonstrieren. Die einfache Verschlüsselung wurde nur ausgewählt, um das Beispiel verständlicher zu machen.

Alice und Bob kommunizieren also mithilfe einer einfachen Substitutionsverschlüsselung, wobei der Schlüssel nur ihnen bekannt ist. Sie legen großen Wert auf die Länge der Nachrichten: Sie beträgt genau 20 Zeichen. Daher einigten sie sich darauf, dass, wenn jemand eine kürzere Nachricht senden möchte, er einen Dummy-Text ans Ende der Nachricht anhängen muss, damit sie genau 20 Zeichen lang ist. Nach einiger Diskussion beschlossen sie, dass sie nur die folgenden Dummy-Texte akzeptieren werden: a, bb, ccc, dddd usw. Auf diese Weise ist der Dummy-Text jeder benötigten Länge bekannt.

Wenn Alice oder Bob eine Nachricht erhalten, überprüfen sie zuerst, ob die Nachricht die richtige Länge hat (20 Zeichen) und ob der Suffix den richtigen fiktiven Text enthält. Wenn nicht, antworten sie mit einer entsprechenden Fehlermeldung. Ist die Länge des Textes und der fiktive Text in Ordnung, liest der Empfänger die Nachricht und sendet eine verschlüsselte Antwort.

Während des Angriffs gibt sich der Angreifer als Bob aus und sendet gefälschte Nachrichten an Alice. Die Nachrichten sind völliger Unsinn – der Angreifer hat keinen Schlüssel und kann daher keine bedeutungsvolle Nachricht fälschen. Da das Protokoll jedoch das Prinzip der Verzweiflung verletzt, kann der Angreifer Alice dennoch in eine Falle locken, sodass sie Informationen über den Schlüssel preisgibt, wie unten gezeigt.

Hacker: PREWF ZHJKL MMMN. LA
Alice: Falscher fiktiver Text.
Hacker: PREWF ZHJKL MMMN. LB
Alice: Falscher fiktiver Text.
Hacker: PREWF ZHJKL MMMN. LC
Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Der Angreifer hat keine Ahnung, was Alice gerade gesagt hat, bemerkt jedoch, dass das Zeichen C übereinstimmen muss a, da Alice den fiktiven Text akzeptiert hat.

Hacker: REWF ZHJKL MMMN. LAA
Alice: Falscher fiktiver Text.
Hacker: REWF ZHJKL MMMN. LBB
Alice: Falscher fiktiver Text.
Nach mehreren Versuchen…
Hacker: REWF ZHJKL MMMN. LGG
Alice: Falscher fiktiver Text.
Hacker: REWF ZHJKL MMMN. LHH
Alice: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Wiederum hat der Angreifer keine Ahnung, was Alice gerade gesagt hat, bemerkt jedoch, dass H mit b übereinstimmen muss, da Alice einen Platzhaltertext verwendet hat.

Und so weiter, bis der Angreifer den Wert jedes Symbols herausfindet.

Auf den ersten Blick ähnelt die Methode einem Angriff auf der Grundlage von bekanntem Klartext. Letztendlich versucht der Angreifer, die Geheimtexte zu erraten, und der Server verarbeitet sie bereitwillig. Der Hauptunterschied, der diese Angriffe in der realen Welt möglich macht, besteht darin, dass der Angreifer keinen Zugang zur tatsächlichen Entschlüsselung benötigt – eine Antwort des Servers reicht aus, selbst wenn sie so harmlos ist wie „Falscher Platzhaltertext“.

Obwohl dieser spezielle Angriff lehrreich ist, sollte man sich nicht zu sehr auf die Details des Schemas "fiktiver Text", die verwendete Kryptosystem oder die genaue Reihenfolge der vom Angreifer gesendeten Nachrichten konzentrieren. Der Hauptgedanke besteht darin, wie Alice unterschiedlich reagiert, basierend auf den Eigenschaften des Klartexts, und dies ohne zu überprüfen, ob der entsprechende verschlüsselte Text tatsächlich von einer vertrauenswürdigen Quelle stammt. Dadurch ermöglicht es Alice dem Angreifer, geheime Informationen aus ihren Antworten herauszupressen.

In diesem Szenario kann vieles angepasst werden. Die Zeichen, auf die Alice reagiert, oder die Veränderung in ihrem Verhalten, oder sogar das verwendete Kryptosystem. Das Prinzip bleibt jedoch dasselbe, und der Angriff bleibt in irgendeiner Form weiterhin machbar. Die grundlegende Umsetzung dieses Angriffs hat dabei geholfen, verschiedene Sicherheitsfehler zu identifizieren, die wir bald besprechen werden; aber zuvor sollten einige theoretische Lektionen gelernt werden. Wie kann dieses fiktive "Alice-Szenario" in einem Angriff verwendet werden, der mit einer realen modernen Verschlüsselung funktioniert? Ist das überhaupt möglich, zumindest theoretisch?

Im Jahr 1998 gab der Schweizer Kryptograf Daniel Bleichenbacher auf diese Frage eine positive Antwort. Er demonstrierte eine Oracle-Attacke in einem weit verbreiteten RSA-Öffentlichkeitsschlüssel-Kryptosystem, indem er ein bestimmtes Nachrichtenschema verwendete. In einigen Implementierungen von RSA antwortet der Server mit unterschiedlichen Fehlermeldungen, abhängig davon, ob der Klartext dem Schema entspricht oder nicht; das war ausreichend, um einen Angriff durchzuführen.

Vier Jahre später, im Jahr 2002, demonstrierte der französische Kryptograf Serge Vaudenay einen Oracle-Angriff, der fast identisch mit dem oben beschriebenen Szenario von Alice war – mit dem Unterschied, dass er anstelle eines fiktiven Verschlüsselungsverfahrens eine ganze respektable Klasse moderner Verschlüsselungen knackte, die tatsächlich verwendet werden. Insbesondere zielte Vaudenays Angriff auf Verschlüsselungen mit fester Eingabemenge ("Blockverschlüsselungen"), wenn sie im sogenannten "CBC-Verschlüsselungsmodus" und mit einem bestimmten populären Füllschema verwendet werden, welches im Wesentlichen dem im Szenario von Alice entspricht.

Ebenfalls im Jahr 2002 schlug der amerikanische Kryptograf John Kelsey – Mitautor Twofish – verschiedene Oracle-Angriffe auf Systeme vor, die Nachrichten komprimieren und sie dann verschlüsseln. Besonders bemerkenswert war ein Angriff, der davon ausging, dass man oft die ursprüngliche Länge des Klartexts aus der Länge des verschlüsselten Textes ableiten kann. In der Theorie ermöglicht dies einen Oracle-Angriff, der Teile des ursprünglichen Klartexts wiederherstellt.

Im Folgenden geben wir eine detaillierte Beschreibung der Watoné- und Kelsi-Attacken (eine detaillierte Beschreibung der Blaychenbacher-Attacke folgt, wenn wir zu den Angriffen auf die asymmetrische Kryptographie übergehen). Trotz all unserer Bemühungen wird der Text etwas technischer; wenn Ihnen das Vorangegangene also ausreicht, können Sie die nächsten beiden Abschnitte überspringen.

Watoné-Attacke

Um die Watoné-Attacke zu verstehen, müssen wir zunächst etwas ausführlicher über Blockchiffren und Verschlüsselungsmodi sprechen. Eine "Blockchiffre" ist, wie bereits erwähnt, ein Chiffrierverfahren, das einen Schlüssel und eine Eingabe fester Länge ("Blocklänge") annimmt und einen verschlüsselten Block derselben Länge ausgibt. Blockchiffren sind weit verbreitet und gelten als relativ sicher. Der inzwischen eingestellte DES, der als erste moderne Chiffre gilt, war eine Blockchiffre. Das Gleiche gilt für das heute weit verbreitete AES.

Leider haben Blockchiffren eine gravierende Schwäche. Die typische Blockgröße beträgt 128 Bit oder 16 Zeichen. Offensichtlich erfordert moderne Kryptoanalyse die Verarbeitung von Eingabedaten größerer Größe, und hier kommen die Verschlüsselungsmodi ins Spiel. Ein Verschlüsselungsmodus ist im Grunde ein Trick: eine Möglichkeit, einen Blockchiffre, der nur Eingabedaten einer bestimmten Größe akzeptiert, auf Eingabedaten beliebiger Länge anzuwenden.

Der Vodene-Angriff zielt auf den beliebten CBC-Modus (Cipher Block Chaining, Blockverkettungsmodus) ab. Der Angriff betrachtet den zugrunde liegenden Blockchiffre als eine magische, unzugängliche schwarze Box und umgeht vollständig dessen Sicherheit.

Hier ist eine Darstellung, die zeigt, wie der CBC-Modus funktioniert:

Das umrandete Pluszeichen bedeutet eine XOR-Operation (exklusives „ODER“). Zum Beispiel, der zweite Block des Chiffretextes wird erhalten durch:

Die Durchführung einer XOR-Operation zwischen dem zweiten Block des Klartextes und dem ersten Block des Chiffretextes.
Die Verschlüsselung des erhaltenen Blocks mit einem Blockchiffre unter Verwendung des Schlüssels.

Da CBC so intensiv die binäre XOR-Operation nutzt, lassen Sie uns die Gelegenheit nutzen, um uns an einige ihrer Eigenschaften zu erinnern:

Idempotenz:
Kommutativität:
Assoziativität:
Selbstinvarianz:
Byteweise: Byte n aus = (Byte n aus ) (Byte n aus )

In der Regel implizieren diese Eigenschaften, dass, wenn wir eine Gleichung haben, die XOR-Operationen und eine Unbekannte umfasst, sie gelöst werden kann. Zum Beispiel, wenn wir wissen, dass mit einer Unbekannten und bekannten und , können wir uns auf die oben genannten Eigenschaften verlassen, um die Gleichung für zu lösen. Indem wir XOR auf beiden Seiten der Gleichung mit anwenden, erhalten wir . In einem Moment wird all dies sehr relevant.

Es gibt zwei geringfügige Unterschiede und eine Hauptsache zwischen unserem Alice-Szenario und dem Vodene-Angriff. Die zwei geringfügigen Unterschiede:

Im Szenario hat Alice erwartet, dass die Klartexte mit den Zeichen a, bb, ccc enden. Im Vodene-Angriff hingegen erwartet das Opfer, dass die Klartexte stattdessen N-mal mit Byte N enden (d.h. hexadezimal 01 oder 02 02, oder 03 03 03 usw.). Dies ist ein rein kosmetischer Unterschied.
Im Szenario von Alice war es einfach zu sagen, ob Alice die Nachricht entgegengenommen hatte, basierend auf der Antwort „Falscher Dummy-Text“. Bei der Vodené-Attacke ist eine umfassendere Analyse erforderlich, und eine präzise Umsetzung auf der Seite des Opfers ist entscheidend; zur Vereinfachung nehmen wir jedoch an, dass diese Analyse weiterhin möglich ist.

Der Hauptunterschied:

Da wir nicht dasselbe kryptografische System verwenden, wird die Verbindung zwischen den vom Angreifer kontrollierten Bytes des verschlüsselten Textes und den Geheimnissen (Schlüssel und Klartext) offensichtlich anders sein. Daher muss der Angreifer eine andere Strategie zur Erstellung von Chiffretexten und zur Interpretation der Serverantworten verwenden.

Das ist der Hauptunterschied – das letzte Puzzlestück, um die Vodené-Attacke zu verstehen. Lassen Sie uns daher einen Moment darüber nachdenken, warum und wie überhaupt eine Orakel-Attacke auf CBC organisiert werden kann.

Angenommen, es gibt einen CBC-Ciphertext aus 247 Blöcken, und wir möchten ihn entschlüsseln. Wir können gefälschte Nachrichten an den Server senden, wie wir zuvor gefälschte Nachrichten an Alice gesendet haben. Der Server wird die Nachrichten für uns entschlüsseln, aber die Entschlüsselung nicht anzeigen — stattdessen wird der Server, ähnlich wie im Fall von Alice, nur ein Bit Information weitergeben: ob das Plaintext mit einer gültigen Auffüllung vorliegt oder nicht.

Bitte beachten Sie, dass wir in Alices Szenario folgende Beziehungen hatten:

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

Nennen wir das 'Alices Gleichung'. Wir hatten die Kontrolle über den Ciphertext; der Server (Alice) gab vage Informationen über den erhaltenen Plaintext weiter; und das ermöglichte es uns, Informationen über den letzten Faktor - den Schlüssel - zu gewinnen. Analog dazu, wenn wir eine solche Beziehung für das CBC-Szenario finden können, könnten wir dort auch einige geheime Informationen extrahieren.

Glücklicherweise gibt es tatsächlich Beziehungen, die wir nutzen können. Betrachten wir die Ausgaben des letzten Aufrufs der Entschlüsselung des Blockchiffres und bezeichnen wir diese Daten als . Bezeichnen wir auch die Blöcke des Plaintexts und die Blöcke des Ciphertexts. . Werfen Sie erneut einen Blick auf das CBC-Diagramm und beachten Sie, was dabei entsteht:

Nennen wir es die „CBC-Gleichung“.

Im Alice-Szenario, indem wir den Chiffretext kontrollieren und Informationen über den entsprechenden Klartext abfangen, konnten wir einen Angriff organisieren, der das dritte Glied der Gleichung – den Schlüssel – wiederhergestellt hat. Im CBC-Szenario kontrollieren wir auch den Chiffretext und beobachten Informationslecks zum entsprechenden Klartext. Wenn die Analogie zutrifft, könnten wir Informationen über .

Angenommen, wir haben tatsächlich wiederhergestellt , was dann? Nun, dann können wir sofort den gesamten letzten Block des Klartexts ausgeben (), indem wir einfach eingeben (den wir haben) und
den erhaltenen in die CBC-Gleichung.

Also sind wir optimistisch hinsichtlich des allgemeinen Angriffsplans, und es ist an der Zeit, die Details auszuarbeiten. Beachten Sie, auf welche Weise Informationen über den Klartext auf dem Server durchgesickert sind. Im Alice-Szenario trat die Leckage auf, weil Alice nur dann mit der richtigen Nachricht antwortete, wenn $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ mit einer bestimmten Zeichenkette endete. a (oder bb, und so weiter, aber die Chancen, dass diese Bedingungen zufällig erfüllt werden, waren sehr gering). Ähnlich wie bei CBC akzeptiert der Server die Füllung nur, wenn es mit einer hexadezimalen 01. Also versuchen wir denselben Trick: das Senden gefälschter Chiffretexte mit unseren eigenen falschen Werten , bis der Server die Füllung akzeptiert.

Wenn der Server die Füllung für eine unserer gefälschten Nachrichten akzeptiert, bedeutet das, dass:

Jetzt verwenden wir die Byte-Eigenschaft von XOR:

Wir kennen das erste und dritte Element. Und wir haben bereits gesehen, dass dies es uns ermöglicht, das verbleibende Element — das letzte Byte von :

zu rekonstruieren. Dies gibt uns auch das letzte Byte des endgültigen Klartextblocks durch die CBC-Gleichung und die Byte-Eigenschaft.

Wir könnten hier enden und uns damit zufrieden geben, dass wir einen Angriff auf einen theoretisch starken Chiffrieralgorithmus durchgeführt haben. Aber in Wirklichkeit können wir viel mehr tun: Wir können den gesamten Text tatsächlich rekonstruieren. Dazu ist ein gewisser Trick erforderlich, der im ursprünglichen Alice-Szenario nicht vorhanden war und nicht zu den obligatorischen Bedingungen des Orakelangriffs gehört, aber die Methode ist dennoch eine Untersuchung wert.

Um dies zu verstehen, sollten Sie zunächst beachten, dass wir durch die korrekte Ableitung des letzten Bytes eine neue Fähigkeit erlangt haben. Jetzt können wir beim Fälschen von Chiffretexten das letzte Byte des entsprechenden Klartexts steuern. Dies hängt wiederum mit der CBC-Gleichung und der Byteweise Eigenschaft zusammen:

Da wir nun den zweiten Teil kennen, können wir unsere Kontrolle über den ersten nutzen, um den dritten zu steuern. Wir berechnen einfach:

Früher konnten wir das nicht, weil uns das letzte Byte noch fehlte. .

Wie wird uns das helfen? Angenommen, wir erstellen alle Chiffretexte so, dass das letzte Byte der entsprechenden Klartexte gleich 02ist. Jetzt akzeptiert der Server die Füllung nur, wenn der Klartext mit 02 02endet. Da wir das letzte Byte korrigiert haben, geschieht dies nur, wenn das vorletzte Byte des Klartexts ebenfalls gleich 02 ist. Wir senden weiterhin gefälschte Chiffretextblöcke und ändern das vorletzte Byte, bis der Server die Füllung für einen von ihnen akzeptiert. In diesem Moment erhalten wir:

Und wir stellen das vorletzte Byte wieder her genauso wie wir das letzte wiederhergestellt haben. Wir machen weiter im gleichen Geist: Wir korrigieren die letzten beiden Bytes des Klartexts auf 03 03, wiederholen diesen Angriff für das drittletzte Byte und so weiter, um letztendlich vollständig wiederherzustellen .

Was ist mit dem restlichen Text? Beachten Sie, dass der Wert tatsächlich $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$ ist. Wir können jeden anderen Block anstelle von einsetzen, und der Angriff wird trotzdem erfolgreich sein. Tatsächlich können wir den Server bitten, $inline$text{BLOCK_DECRYPT}$inline$ für beliebige Daten durchzuführen. An diesem Punkt ist das Spiel vorbei – wir können jeden Ciphertext entschlüsseln (sehen Sie sich noch einmal das Diagramm zur Entschlüsselung von CBC an, um dies zu überprüfen; und beachten Sie, dass der IV-Vektor öffentlich zugänglich ist).

Diese spezielle Methode spielt eine entscheidende Rolle in dem Oracle-Angriff, mit dem wir später konfrontiert werden.

Kelsey-Angriff

Der uns nahestehende John Kelsey skizzierte die Prinzipien, die vielen möglichen Angriffen zugrunde liegen, und nicht nur die Einzelheiten eines bestimmten Angriffs auf einen bestimmten Verschlüsselungsalgorithmus. Sein Artikel von 2002 — dies ist eine Untersuchung möglicher Angriffe auf verschlüsselte komprimierte Daten. Haben Sie gedacht, dass es für einen Angriff nicht ausreicht, nur zu wissen, dass die Daten vor der Verschlüsselung komprimiert wurden? Es stellt sich heraus, dass das genügt.

Dieses erstaunliche Ergebnis beruht auf zwei Prinzipien. Erstens gibt es eine starke Korrelation zwischen der Länge des Klartexts und der Länge des Chiffretexts; für viele Verschlüsselungen ist die Gleichheit exakt. Zweitens, wenn eine Kompression durchgeführt wird, gibt es auch eine starke Korrelation zwischen der Länge der komprimierten Nachricht und dem Grad der 'Rauschhaftigkeit' des Klartexts, also dem Anteil der sich wiederholenden Zeichen (technischer Begriff - 'hohe Entropie').

Um das Prinzip in Aktion zu sehen, betrachten wir zwei Klartexte:

Klartext 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Klartext 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Angenommen, beide Klartexte werden komprimiert und anschließend verschlüsselt. Sie erhalten zwei resultierende Chiffretexte und müssen erraten, welcher Chiffretext zu welchem Klartext gehört:

Chiffretext 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA
Chiffretext 2: DWKJZXYU

Die Antwort ist klar. Unter den offenen Texten konnte nur der offene Text 1 auf die spärliche Länge des zweiten Chiffretextes komprimiert werden. Das haben wir festgestellt, ohne irgendetwas über den Kompressionsalgorithmus, den Verschlüsselungsschlüssel oder sogar die Chiffre zu wissen. Im Vergleich zur Hierarchie möglicher kryptografischer Angriffe ist das eine Art Wahnsinn.

Kelsey weist weiter darauf hin, dass dieses Prinzip unter bestimmten ungewöhnlichen Umständen auch für einen Oracle-Angriff verwendet werden kann. Insbesondere beschreibt er, wie ein Angreifer den geheimen offenen Text wiederherstellen kann, wenn er den Server dazu bringen kann, die Daten des Formulars (offener Text, gefolgt von , während er kontrolliert und irgendwie die Länge des verschlüsselten Ergebnisses überprüfen kann.

Wieder haben wir, wie bei anderen Oracle-Angriffen, ein Verhältnis:

Erneut steuern wir ein Element (), sehen eine kleine Informationsleckage über ein anderes Element (Chiffretext) und versuchen, Letzteres (offener Text) wiederherzustellen. Trotz der Analogie ist dies eine etwas ungewöhnliche Situation im Vergleich zu den anderen Oracle-Angriffen, die wir gesehen haben.

Um zu veranschaulichen, wie ein solcher Angriff funktionieren kann, verwenden wir ein fiktives Kompressionsschema, das wir gerade entwickelt haben: TOYZIP. Es sucht nach Textzeilen, die bereits zuvor im Text erschienen sind, und ersetzt sie durch drei Platzhalterbytes, die angeben, wo frühere Instanzen der Zeile zu finden sind und wie oft sie dort vorkommen. Zum Beispiel kann die Zeile helloworldhello in helloworld[00][00][05] komprimiert werden, was eine Länge von 13 Bytes im Vergleich zu den ursprünglichen 15 Bytes ergibt.

Angenommen, der Angreifer versucht, den Klartext des Formulars password=..., wobei das Passwort selbst unbekannt ist. Gemäß dem Angriffsmodell von Kelsey kann der Angreifer den Server bitten, die Nachrichten des Formulars zu komprimieren und anschließend zu verschlüsseln (Klartext, gefolgt von ), wo — beliebiger Text. Wenn der Server fertig ist, gibt er die Länge des Ergebnisses bekannt. Der Angriff verläuft wie folgt:

Hacker: Bitte komprimieren und verschlüsseln Sie den Klartext ohne Platzhalter.
Server: Ergebnislänge 14.
Hacker: Bitte komprimieren und verschlüsseln Sie den Klartext, zu dem password=a.
Server: hinzugefügt wurde. Ergebnislänge 18.

Der Angreifer stellt fest: [Original 14] + [drei Bytes, die ersetzt wurden, um password=] + a

Hacker: Bitte komprimieren und verschlüsseln Sie den Klartext, dem hinzugefügt wurde passwort=b.
Server: hinzugefügt wurde. Ergebnislänge 18.
Hacker: Bitte komprimieren und verschlüsseln Sie den Klartext, dem hinzugefügt wurde passwort=c.
Server: Die Länge des Ergebnisses beträgt 17.

Der Angreifer stellt fest: [Original 14] + [drei Bytes, die ersetzt wurden, um passwort=c]. Das setzt voraus, dass der ursprüngliche Klartext eine Zeichenfolge enthält passwort=c. Das heißt, das Passwort beginnt mit dem Buchstaben c

Hacker: Bitte komprimieren und verschlüsseln Sie den Klartext, dem hinzugefügt wurde passwort=ca.
Server: hinzugefügt wurde. Ergebnislänge 18.

Der Angreifer stellt fest: [Original 14] + [drei Bytes, die ersetzt wurden, um passwort=c] + a

Hacker: Bitte komprimieren und verschlüsseln Sie den Klartext, dem hinzugefügt wurde passwort=cb.
Server: hinzugefügt wurde. Ergebnislänge 18.

(… einige Zeit später …)

Hacker: Bitte komprimieren und verschlüsseln Sie den Klartext, dem hinzugefügt wurde passwort=co.
Server: Die Länge des Ergebnisses beträgt 17.

Der Angreifer stellt fest: [Original 14] + [drei Bytes, die ersetzt wurden, um passwort=co]. Logisch schlussfolgert der Angreifer, dass das Passwort mit den Buchstaben beginnt co

Und so weiter, bis das gesamte Passwort wiederhergestellt ist.

Es ist nachvollziehbar, dass der Leser denkt, dies sei rein akademisches Wissen und ein solches Angriffsszenario nie in der realen Welt vorkommen wird. Leider, wie wir bald sehen werden, sollte man in der Kryptoanalyse nicht vorschnell sein.

Markenanfälligkeiten: CRIME, POODLE, DROWN

Nachdem wir die Theorie ausführlich untersucht haben, können wir sehen, wie diese Methoden in echten kryptographischen Angriffen angewendet werden.

CRIME

Wenn ein Angriff auf den Browser und das Netzwerk des Opfers abzielt, gibt es einfachere und schwierigere Aspekte. Zum Beispiel ist es leicht, den Datenverkehr eines Opfers zu überwachen; man muss nur in demselben Café mit WiFi sitzen. Aus diesem Grund wird potenziellen Opfern (d. h. jedem) empfohlen, eine verschlüsselte Verbindung zu verwenden. Es wird etwas komplizierter, aber immer noch möglich, HTTP-Anfragen im Namen des Opfers an eine externe Website (z. B. Google) zu senden. Der Angreifer muss das Opfer auf eine bösartige Webseite locken, die ein Skript enthält, das die Anfrage ausführt. Der Webbrowser stellt automatisch das entsprechende Sitzungscookie zur Verfügung.

Das scheint erstaunlich zu sein. Wenn Bob auf evil.com, kann das Skript auf dieser Seite Google einfach darum bitten, Bobs Passwort per E-Mail an attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Cross-Site Request Forgery, CSRF), und es war etwa in den 90er Jahren populär. Heutzutage, wenn evil.com jemand versucht, diesen Trick zu verwenden, wird Google (oder jede respektable Website) normalerweise antworten: „Gut, aber Ihr CSRF-Token für diese Transaktion ist… hmmm… drei Billionen und sieben. Bitte wiederholen Sie diese Nummer. Moderne Browser verwenden eine sogenannte „Same-Origin-Policy“, nach der Skripte auf Website A keinen Zugriff auf Informationen haben, die von Website B gesendet werden. Daher kann ein Skript auf evil.com Anfragen an google.com, senden, kann jedoch die Antworten nicht lesen oder tatsächlich die Transaktion abschließen.

Wir müssen betonen, dass alle diese Schutzmaßnahmen sinnlos sind, wenn Bob keine verschlüsselte Verbindung verwendet. Ein Angreifer kann einfach Bobs Traffic lesen und das Google-Sitzungs-Cookie wiederherstellen. Mit diesem Cookie öffnet er einfach einen neuen Google-Tab, ohne seinen eigenen Browser zu verlassen, und gibt sich als Bob aus, ohne mit den lästigen Same-Origin-Policy-Bestimmungen konfrontiert zu werden. Leider trifft dies für Angreifer jedoch immer seltener zu. Das Internet hat längst den Krieg gegen unverschlüsselte Verbindungen erklärt, und Bobs ausgehender Traffic ist wahrscheinlich verschlüsselt, ob ihm das gefällt oder nicht. Darüber hinaus wurde der Traffic bereits seit Einführung des Protokolls vor der Verschlüsselung komprimiert; dies war eine gängige Praxis zur Verringerung der Latenz.

Hier kommt CRIME (Compression Ratio Infoleak Made Easy, einfache Leckage durch Kompressionsverhältnis). Eine Schwachstelle, die im September 2012 von den Sicherheitsforschern Juliano Rizzo und Thai Duong aufgedeckt wurde. Wir haben bereits die gesamte theoretische Grundlage erarbeitet, die es ermöglicht, zu verstehen, was sie gemacht haben und wie. Ein Angreifer kann Bob's Browser dazu bringen, Anfragen an Google zu senden, und dann die Antworten im komprimierten, verschlüsselten Format im lokalen Netzwerk abhören. Daher haben wir:

Hier kontrolliert der Angreifer die Anfrage und hat Zugriff auf einen Traffic-Sniffer, einschließlich der Paketgrößen. Das fiktive Szenario von Kelsey wurde Wirklichkeit.

Mit dem Verständnis der Theorie entwickelten die Autoren von CRIME einen Exploit, der Sitzungscookies von einer Vielzahl von Websites stehlen kann, einschließlich Gmail, Twitter, Dropbox und GitHub. Die Schwachstelle betraf die meisten modernen Webbrowser, was dazu führte, dass Patches veröffentlicht wurden, die die Verwendung der Kompressionsfunktion in SSL stillschweigend unterbanden. Der einzige, der vor dieser Schwachstelle geschützt war, war der ehrwürdige Internet Explorer, der SSL-Kompression niemals verwendete.

POODLE

Im Oktober 2014 sorgte das Sicherheitsteam von Google für Aufregung in der Sicherheitsgemeinschaft. Ihnen gelang es, eine Schwachstelle im SSL-Protokoll auszunutzen, die vor über zehn Jahren behoben wurde.

Es stellte sich heraus, dass, obwohl auf den Servern das brandneue TLSv1.2 läuft, viele die Unterstützung des veralteten SSLv3 aus Gründen der Rückwärtskompatibilität mit Internet Explorer 6 beibehalten haben. Wir haben bereits über Abwärtsangriffe gesprochen, sodass Sie sich vorstellen können, was geschieht. Gut organisierter Sabotage des Handshake-Protokolls – und die Server sind bereit, zum alten SSLv3 zurückzukehren, wodurch die letzten 15 Jahre an Sicherheitsforschung im Grunde aufgehoben werden.

Zur historischen Einordnung, hier ist eine kurze Zusammenfassung der SSL-Geschichte bis zur Version 2 von Matthew Green:

Transport Layer Security (TLS) ist das wichtigste Sicherheitsprotokoll im Internet. [..] Fast jede Transaktion, die Sie online durchführen, hängt von TLS ab. [..] Aber TLS war nicht immer TLS. Das Protokoll begann sein Leben in Netscape Communications unter dem Namen „Secure Sockets Layer“ oder SSL. Es wird gemunkelt, dass die erste Version von SSL so katastrophal war, dass die Entwickler alle Code-Drucke sammelten und auf einer geheimen Müllhalde in New Mexico vergruben. Infolgedessen ist die erste öffentliche Version von SSL tatsächlich Version SSL 2. Sie ist ziemlich gruselig, und [..] sie war ein Produkt aus den 90ern, die moderne Kryptografen als „dunkle Jahrhunderte der Kryptografie“ betrachten. Viele der schlimmsten kryptografischen Angriffe, die wir heute kennen, waren damals noch nicht entdeckt. Die Entwickler des SSLv2-Protokolls mussten praktisch im Dunkeln tappen und sahen sich vieler schrecklicher Monster gegenüber – zu ihrem Bedauern und unserem Vorteil, da die Angriffe auf SSLv2 unschätzbare Lektionen für die nächste Generation von Protokollen hinterließen.

Nach diesen Ereignissen überarbeitete das frustrierte Unternehmen Netscape 1996 das SSL-Protokoll von Grund auf neu. Das Ergebnis war SSL Version 3, die einige der bekannten Sicherheitsprobleme ihres Vorgängers behoben hat..

Leider bedeutet „einige“ nicht „alle“ für Hacker. Insgesamt bot SSLv3 alle notwendigen Bausteine für den Waterene-Angriff. Das Protokoll verwendete den Blockcipher im CBC-Modus und ein unsicheres Padding-Schema (dies wurde in TLS behoben; daher die Notwendigkeit eines Downgrade-Angriffs). Wenn Sie sich das Padding-Schema in unserer ursprünglichen Beschreibung des Waterene-Angriffs merken, werden Sie feststellen, dass das SSLv3-Schema sehr ähnlich ist.

Doch leider bedeutet „ähnlich“ nicht „identisch“ für Hacker. Das Padding-Schema von SSLv3 besteht aus „N zufälligen Bytes, gefolgt von der Zahl N“. Versuchen Sie unter diesen Bedingungen, einen beliebigen Block des verschlüsselten Textes auszuwählen und alle Phasen des ursprünglichen Waterene-Schemas durchzugehen: Sie werden feststellen, dass der Angriff erfolgreich das letzte Byte des entsprechenden Klartextblocks extrahiert, aber nicht weitergeht. Die Entschlüsselung jedes 16. Bytes des verschlüsselten Textes ist ein toller Kunststück, aber das reicht nicht für den Sieg.

In Anbetracht der Herausforderungen griff das Google-Team zu einer extremen Lösung: Sie wechselten zu einem leistungsfähigeren Bedrohungsmodell – dem, das auch in CRIME verwendet wurde. Angenommen, der Angreifer ist ein Skript, das im Tab des Browsers des Opfers läuft und in der Lage ist, Sitzungscookies abzurufen, bleibt die Attacke dennoch beeindruckend. Auch wenn das umfassendere Bedrohungsmodell weniger realistisch ist, haben wir im vorherigen Abschnitt bereits gesehen, dass dieses spezifische Modell umsetzbar ist.

Angesichts solch leistungsstarker Hackerfähigkeiten kann der Angriff nun fortgesetzt werden. Beachten Sie, dass der Angreifer weiß, wo die verschlüsselte Sitzungs-Cookie-Datei im Header angezeigt wird und die Länge der vorhergehenden HTTP-Anfrage steuert. Daher ist er in der Lage, die HTTP-Anfrage so zu manipulieren, dass das letzte Byte des Cookies mit dem Ende des Blocks ausgerichtet ist. Dieses Byte ist nun für die Dekodierung geeignet. Man kann einfach ein Zeichen zur Anfrage hinzufügen, während das vorletzte Byte des Cookies an derselben Stelle bleibt und mit der gleichen Methode ermittelt werden kann. Der Angriff wird so lange fortgesetzt, bis die Cookie-Datei vollständig wiederhergestellt ist. Dies nennt sich POODLE: Padding Oracle on Downgraded Legacy Encryption, das Füllen eines Orakels bei herabgestufter veralteter Verschlüsselung.

DROWN

Wie bereits erwähnt, hatte SSLv3 Schwächen, war jedoch grundlegend anders als sein Vorgänger, da das veraltete SSLv2 ein Produkt einer anderen Ära darstellte. Dort konnte man eine Nachricht in der Mitte unterbrechen: darauf gehe ich nur über meinen Leichnam ein verwandelt sich in darauf gehe ich ein; Kunden und Server konnten sich im Internet begegnen, Vertrauen aufbauen und Geheimnisse austauschen, während sie von einem Angreifer beobachtet wurden, der sich problemlos als einer von beiden ausgeben konnte. Zudem gab es das Problem mit der Export-Kryptographie, das wir bei der Diskussion über FREAK erwähnt haben. Das war ein kryptographisches Sodom und Gomorra.

Im März 2016 versammelte sich ein Team von Forschern aus verschiedenen technischen Bereichen und machte eine erstaunliche Entdeckung: SSLv2 wird nach wie vor in Sicherheitssystemen verwendet. Ja, Angreifer konnten moderne TLS-Sitzungen nicht mehr auf SSLv2 herabstufen, da diese Lücke nach FREAK und POODLE geschlossen wurde, aber sie können immer noch eine Verbindung zu Servern herstellen und SSLv2-Sitzungen eigenständig initiieren.

Sie fragen sich vielleicht, warum uns die Aktivitäten anderer interessieren sollten? Sie haben eine anfällige Sitzung, aber das sollte die anderen Sitzungen oder die Serversicherheit nicht beeinträchtigen – richtig? Nun, nicht ganz. Ja, das sollte theoretisch der Fall sein. Aber in der Praxis ist es anders – denn die Erstellung von SSL-Zertifikaten bringt gewisse Belastungen mit sich, wodurch viele Server dieselben Zertifikate und folglich dieselben RSA-Schlüssel für TLS- und SSLv2-Verbindungen verwenden. Noch schlimmer ist, dass aufgrund eines Bugs in OpenSSL in dieser weit verbreiteten SSL-Implementierung die Option „SSLv2 deaktivieren“ tatsächlich nicht funktionierte.

Das eröffnete Möglichkeiten für einen Protokollübergreifenden Angriff auf TLS, der als DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, Entschlüsselung von RSA mit veralteter und geschwächter Verschlüsselung). Es ist wichtig zu beachten, dass dies nicht dasselbe ist wie eine Downgrade-Attacke; der Angreifer muss nicht wie ein „Man-in-the-Middle“ handeln und den Client nicht in eine unsichere Sitzung einbeziehen. Angreifer initiieren einfach selbst eine unsichere SSLv2-Sitzung mit dem Server, greifen das schwache Protokoll an und stellen den privaten RSA-Server-Schlüssel wieder her. Dieser Schlüssel ist auch für TLS-Verbindungen gültig, und ab diesem Zeitpunkt kann ihn keine TLS-Sicherheit mehr vor einem Angriff schützen.

Aber um einen erfolgreichen Angriff auf SSLv2 zu starten, benötigt man einen funktionierenden Angriff, der es ermöglicht, nicht nur spezifischen Datenverkehr wiederherzustellen, sondern auch den geheimen RSA-Server-Schlüssel. Obwohl dies eine komplexe Angelegenheit ist, konnten die Forscher jede Schwachstelle auswählen, die nach SSLv2 vollständig behoben wurde. Letztendlich fanden sie die geeignete Option: den Bleichenbacher-Angriff, den wir zuvor erwähnt haben und den wir im nächsten Artikel ausführlich erklären werden. SSL und TLS sind gegen diesen Angriff geschützt, aber einige zufällige Funktionen von SSL in Kombination mit kurzen Schlüsseln in der Export-klassifizierten Kryptografie ermöglichten dies. eine bestimmte Umsetzung von DROWN.

Zum Zeitpunkt der Veröffentlichung waren 25 % der Top-Websites im Internet anfällig für die DROWN-Schwachstelle, und die Attacke konnte mit bescheidenen Ressourcen durchgeführt werden, die sogar für versierte Einzelhacker zugänglich waren. Um den RSA-Schlüssel des Servers zu extrahieren, waren acht Stunden Rechenzeit und 440 $ erforderlich, während SSLv2 von "veraltet" zu "radioaktiv" aufstieg.

Moment mal, was ist mit Heartbleed?

Dies ist kein kryptographischer Angriff im Sinne der oben beschriebenen, sondern ein Pufferüberlauf.

Lass uns eine Pause machen

Wir haben mit einigen grundlegenden Methoden begonnen: Brute-Force, Interpolation, Downgrade, Cross-Protocol und Precomputation. Dann haben wir eine fortgeschrittene Technik betrachtet, die möglicherweise ein Hauptbestandteil moderner kryptografischer Angriffe ist: der Oracle-Angriff. Wir haben uns eine Weile damit beschäftigt – und verstanden nicht nur das zugrunde liegende Prinzip, sondern auch die technischen Details von zwei spezifischen Umsetzungen: dem Angriff von Vaudenay auf den CBC-Verschlüsselungsmodus und den Angriff von Kelsey auf Verschlüsselungsprotokolle mit vorangegangener Kompression.

In der Analyse von Abwärtsangriffen und mit vorläufigen Berechnungen haben wir den FREAK-Angriff kurz zusammengefasst, der beide Methoden nutzt, da die angestrebten Websites auf schwache Schlüssel herabsetzen und danach dieselben Schlüssel wiederverwenden. Für den nächsten Artikel haben wir den (sehr ähnlichen) Logjam-Angriff belassen, der auf Algorithmen mit öffentlichen Schlüsseln abzielt.

Anschließend haben wir drei weitere Beispiele für die Anwendung dieser Prinzipien betrachtet. Zunächst CRIME und POODLE: zwei Angriffe, die auf die Fähigkeit des Angreifers basierten, beliebigen Klartext neben dem Zielklartext einzufügen, um dann die Serverantworten zu untersuchen und dann, unter Anwendung der Orakel-Angriffs-Methodik, diese spärlichen Informationen zur teilweisen Wiederherstellung des Klartexts zu nutzen. CRIME folgte dem Weg des Kelsey-Angriffs auf die SSL-Kompression, während POODLE stattdessen eine Variante des Vorab-Griff-Angriffs auf CBC mit demselben Effekt verwendete.

Wir haben dann auf den DROWN-Cross-Protocol-Angriff hingewiesen, der eine Verbindung mit dem Server über das veraltete SSLv2-Protokoll herstellt und anschließend geheime Server-Schlüssel durch einen Bleichenbacher-Angriff wiederherstellt. Derzeit haben wir die technischen Einzelheiten dieses Angriffs übersprungen; wie bei Logjam wird es warten müssen, bis wir die Public-Key-Kryptosysteme und ihre Schwachstellen gründlich untersucht haben.

Im nächsten Artikel werden wir über fortgeschrittene Angriffe sprechen – wie die Meet-in-the-Middle-Methode, die differentielle Kryptoanalyse und den Geburtstagsangriff. Wir werden einen kurzen Blick auf Angriffe über Seitenschläuche werfen und uns dann dem Hauptthema zuwenden – den Public-Key-Kryptosystemen.

Quelle: habr.com