Wenn Sie das Wort „Kryptografie“ hören, erinnern sich manche Menschen an ihr WLAN-Passwort, an das grüne Vorhängeschloss neben der Adresse ihrer Lieblingswebsite und daran, wie schwierig es ist, auf die E-Mails einer anderen Person zuzugreifen. Andere erinnern mit aussagekräftigen Abkürzungen (DROWN, FREAK, POODLE...), stilvollen Logos und der Warnung, Ihren Browser dringend zu aktualisieren, an eine Reihe von Sicherheitslücken in den letzten Jahren.

Kryptographie deckt alles ab, aber Essenz von in einem anderen. Der Punkt ist, dass es einen schmalen Grat zwischen einfach und komplex gibt. Manche Dinge sind einfach zu erledigen, aber schwer wieder zusammenzusetzen, wie zum Beispiel ein Ei zu zerbrechen. Andere Dinge sind einfach zu erledigen, aber schwer wieder rückgängig zu machen, wenn ein kleiner, wichtiger und entscheidender Teil fehlt: zum Beispiel das Öffnen einer verschlossenen Tür, wenn der „entscheidende Teil“ der Schlüssel ist. Die Kryptographie untersucht diese Situationen und wie sie in der Praxis genutzt werden können.

In den letzten Jahren hat sich die Sammlung kryptografischer Angriffe in einen Zoo auffälliger Logos verwandelt, gefüllt mit Formeln aus wissenschaftlichen Arbeiten, und ein allgemeines düsteres Gefühl hervorgerufen, dass alles kaputt ist. Tatsächlich basieren viele der Angriffe jedoch auf ein paar allgemeinen Prinzipien, und endlose Seiten mit Formeln werden oft auf leicht verständliche Ideen reduziert.

In dieser Artikelserie werden wir uns mit den verschiedenen Arten kryptografischer Angriffe befassen und dabei den Schwerpunkt auf die Grundprinzipien legen. Im Allgemeinen und nicht genau in dieser Reihenfolge, aber wir werden Folgendes behandeln:

• Grundlegende Strategien: Brute Force, Frequenzanalyse, Interpolation, Downgrade und protokollübergreifende.
• Gebrandmarkte Schwachstellen: FREAK, CRIME, POODLE, DROWN, Logjam.
• Fortgeschrittene Strategien: Oracle-Angriffe (Vodenet-Angriff, Kelsey-Angriff); Meet-in-the-Middle-Methode, Geburtstagsangriff, statistische Verzerrung (differentielle Kryptoanalyse, integrale Kryptoanalyse usw.).
• Seitenkanalangriffe und ihre nahen Verwandten, Fehleranalysetechniken.
• Angriffe auf die Public-Key-Kryptographie: Kubikwurzel, Broadcast, verwandte Nachricht, Coppersmith-Angriff, Pohlig-Hellman-Algorithmus, Zahlensieb, Wiener-Angriff, Bleichenbacher-Angriff.

Dieser spezielle Artikel behandelt das oben genannte Material bis zu Kelseys Angriff.

Grundlegende Strategien

Die folgenden Angriffe sind in dem Sinne einfach, dass sie ohne große technische Details fast vollständig erklärt werden können. Lassen Sie uns jede Art von Angriff in einfachsten Worten erklären, ohne auf komplexe Beispiele oder fortgeschrittene Anwendungsfälle einzugehen.

Einige dieser Angriffe sind weitgehend veraltet und wurden viele Jahre lang nicht mehr eingesetzt. Andere sind Oldtimer, die sich auch im 21. Jahrhundert regelmäßig an ahnungslose Entwickler von Kryptosystemen heranschleichen. Man kann davon ausgehen, dass die Ära der modernen Kryptographie mit der Einführung von IBM DES begann, der ersten Verschlüsselung, die allen Angriffen dieser Liste standhielt.

Einfache rohe Gewalt

Das Verschlüsselungsschema besteht aus zwei Teilen: 1) einer Verschlüsselungsfunktion, die eine Nachricht (Klartext) in Kombination mit einem Schlüssel verwendet und dann eine verschlüsselte Nachricht – Chiffretext – erstellt; 2) eine Entschlüsselungsfunktion, die aus dem Chiffretext und dem Schlüssel den Klartext erzeugt. Sowohl die Verschlüsselung als auch die Entschlüsselung müssen mit dem Schlüssel leicht zu berechnen sein – und ohne ihn schwierig zu berechnen sein.

Nehmen wir an, wir sehen den Chiffretext und versuchen, ihn ohne zusätzliche Informationen zu entschlüsseln (dies wird als reiner Chiffretext-Angriff bezeichnet). Wenn wir auf magische Weise den richtigen Schlüssel finden, können wir leicht überprüfen, ob er tatsächlich korrekt ist, wenn das Ergebnis eine vernünftige Nachricht ist.

Beachten Sie, dass es hier zwei implizite Annahmen gibt. Erstens wissen wir, wie man eine Entschlüsselung durchführt, also wie das Kryptosystem funktioniert. Dies ist eine Standardannahme bei der Erörterung der Kryptographie. Das Verbergen der Implementierungsdetails der Verschlüsselung vor Angreifern mag wie eine zusätzliche Sicherheitsmaßnahme erscheinen, aber sobald der Angreifer diese Details herausfindet, geht diese zusätzliche Sicherheit stillschweigend und unwiderruflich verloren. So geht das Kerchhoffs Prinzip: Das System, das in die Hände des Feindes fällt, sollte keine Unannehmlichkeiten verursachen.

Zweitens gehen wir davon aus, dass nur der richtige Schlüssel zu einer sinnvollen Entschlüsselung führt. Dies ist auch eine vernünftige Annahme; es ist erfüllt, wenn der Chiffretext viel länger als der Schlüssel ist und lesbar ist. Dies ist normalerweise das, was in der realen Welt passiert, außer riesige unpraktische Tasten oder andere Spielereien, die man am besten beiseite lässt (Wenn Ihnen das nicht gefällt, haben wir die Erklärung übersprungen, siehe Satz 3.8 hier).

Vor diesem Hintergrund ergibt sich eine Strategie: Überprüfen Sie jeden möglichen Schlüssel. Dies nennt man Brute-Force-Angriff, und ein solcher Angriff wirkt sich garantiert gegen alle praktischen Verschlüsselungsverfahren aus – irgendwann. Zum Hacken reicht beispielsweise rohe Gewalt aus Caesar-Chiffre, eine alte Chiffre, bei der der Schlüssel aus einem Buchstaben des Alphabets besteht, was etwas mehr als 20 mögliche Schlüssel impliziert.

Unglücklicherweise ist für Kryptoanalytiker die Erhöhung der Schlüsselgröße ein guter Schutz gegen Brute-Force-Angriffe. Mit zunehmender Schlüsselgröße nimmt die Anzahl der möglichen Schlüssel exponentiell zu. Bei modernen Schlüsselgrößen ist einfache rohe Gewalt völlig unpraktisch. Um zu verstehen, was wir meinen, nehmen wir den schnellsten bekannten Supercomputer von Mitte 2019: Gipfel von IBM mit einer Spitzenleistung von etwa 1017 Operationen pro Sekunde. Heutzutage beträgt die typische Schlüssellänge 128 Bit, was 2128 mögliche Kombinationen bedeutet. Um alle Schlüssel zu durchsuchen, benötigt der Supercomputer Summit Zeit, die etwa dem 7800-fachen Alter des Universums entspricht.

Sollte rohe Gewalt als historische Kuriosität betrachtet werden? Überhaupt nicht: Es ist eine notwendige Zutat im Kochbuch der Kryptoanalyse. Selten sind Chiffren so schwach, dass sie nur durch einen geschickten Angriff gebrochen werden können, ohne dass in gewissem Maße Gewalt angewendet wird. Viele erfolgreiche Hacks verwenden eine algorithmische Methode, um zunächst die Zielchiffre zu schwächen und dann einen Brute-Force-Angriff durchzuführen.

Frequenzanalyse

Die meisten Texte sind kein Kauderwelsch. Beispielsweise gibt es in englischen Texten viele Buchstaben „e“ und Artikel „the“; In Binärdateien gibt es viele Nullbytes als Auffüllung zwischen Informationsteilen. Unter Frequenzanalyse versteht man jeden Angriff, der sich diese Tatsache zunutze macht.

Das kanonische Beispiel einer für diesen Angriff anfälligen Verschlüsselung ist die einfache Substitutionsverschlüsselung. In dieser Chiffre ist der Schlüssel eine Tabelle, in der alle Buchstaben ersetzt sind. Beispielsweise wird „g“ durch „h“, „o“ durch j ersetzt, sodass das Wort „go“ zu „hj“ wird. Diese Verschlüsselung lässt sich nur schwer mit roher Gewalt erzwingen, da es so viele mögliche Nachschlagetabellen gibt. Wenn Sie sich für die Mathematik interessieren, beträgt die effektive Schlüssellänge etwa 88 Bit: das ist
. Aber die Frequenzanalyse erledigt die Arbeit normalerweise schnell.

Betrachten Sie den folgenden Chiffretext, der mit einer einfachen Substitutions-Chiffre verarbeitet wurde:

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

Da Y Wenn er häufig vorkommt, auch am Ende vieler Wörter, können wir versuchsweise davon ausgehen, dass es sich um den Buchstaben handelt e:

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

Paar XD am Anfang mehrerer Wörter wiederholt. Insbesondere die Kombination XDeLe deutet das Wort deutlich an these oder there, also machen wir weiter:

theLe Ale UGLe thWNKE WN heAJeN ANF eALth DGLAtWG than Ale FLeAUt GR WN OGQL ZDWBGEGZDO

Nehmen wir das weiter an L Streichhölzer r, A - a usw. Es wird wahrscheinlich ein paar Versuche dauern, aber im Vergleich zu einem vollständigen Brute-Force-Angriff stellt dieser Angriff den Originaltext in kürzester Zeit wieder her:

Es gibt mehr Dinge im Himmel und auf Erden, als in Ihrer Philosophie geträumt wird

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. Und es gilt für viel komplexere Chiffren. Im Laufe der Geschichte haben verschiedene Verschlüsselungsdesigns versucht, einem solchen Angriff durch „polyalphabetische Substitution“ entgegenzuwirken. Dabei wird die Buchstabenersetzungstabelle während des Verschlüsselungsprozesses auf komplexe, aber vorhersehbare Weise geändert, die vom Schlüssel abhängt. Alle diese Chiffren galten gleichzeitig als schwer zu knacken; und doch besiegte eine bescheidene Frequenzanalyse schließlich sie alle.

Die ehrgeizigste polyalphabetische Chiffre der Geschichte und wahrscheinlich die berühmteste war die Enigma-Chiffre aus dem Zweiten Weltkrieg. Es war im Vergleich zu seinen Vorgängern relativ komplex, aber nach viel harter Arbeit haben britische Kryptoanalytiker es mithilfe der Frequenzanalyse geknackt. Natürlich konnten sie keinen eleganten Angriff wie den oben gezeigten entwickeln; Sie mussten bekannte Klartext- und Chiffretext-Paare vergleichen (der sogenannte „Klartext-Angriff“) und Enigma-Benutzer sogar dazu verleiten, bestimmte Nachrichten zu verschlüsseln und das Ergebnis zu analysieren (der „ausgewählte Klartext-Angriff“). Doch das machte das Schicksal der besiegten feindlichen Armeen und versenkten U-Boote nicht einfacher.

Nach diesem Triumph verschwand die Frequenzanalyse aus der Geschichte der Kryptoanalyse. Chiffriermittel im modernen digitalen Zeitalter sind darauf ausgelegt, mit Bits und nicht mit Buchstaben zu arbeiten. Noch wichtiger ist, dass diese Chiffren mit dem dunklen Verständnis dessen entwickelt wurden, was später als bekannt wurde Schneiers Gesetz: Jeder kann einen Verschlüsselungsalgorithmus erstellen, den er selbst nicht knacken kann. Für das Verschlüsselungssystem reicht es nicht aus schien schwierig: Um seinen Wert zu beweisen, muss es einer gnadenlosen Sicherheitsüberprüfung durch viele Kryptoanalytiker unterzogen werden, die ihr Bestes geben, um die Chiffre zu knacken.

Vorläufige Berechnungen

Nehmen wir die hypothetische Stadt Precom Heights mit 200 Einwohnern. In jedem Haus der Stadt befinden sich durchschnittlich Wertsachen im Wert von 000 US-Dollar, jedoch nicht mehr als 30 US-Dollar. Der Sicherheitsmarkt in Precom wird von ACME Industries monopolisiert, das die legendären Türschlösser der Coyote™-Klasse herstellt. Einer Expertenanalyse zufolge kann ein Schloss der Coyote-Klasse nur durch eine sehr komplexe hypothetische Maschine aufgebrochen werden, deren Herstellung etwa fünf Jahre und eine Investition von 000 US-Dollar erfordert. Ist die Stadt sicher?

Höchstwahrscheinlich nein. Irgendwann wird ein ziemlich ehrgeiziger Verbrecher auftauchen. Er wird so argumentieren: „Ja, es entstehen mir hohe Vorabkosten. Fünf Jahre geduldiges Warten und 50 US-Dollar. Aber wenn ich fertig bin, habe ich Zugriff darauf der ganze Reichtum dieser Stadt. Wenn ich meine Karten richtig spiele, wird sich diese Investition um ein Vielfaches amortisieren.“

Dasselbe gilt auch für die Kryptographie. Angriffe gegen eine bestimmte Chiffre unterliegen einer schonungslosen Kosten-Nutzen-Analyse. Wenn das Verhältnis günstig ist, wird der Angriff nicht stattfinden. Aber Angriffe, die gegen viele potenzielle Opfer gleichzeitig wirken, zahlen sich fast immer aus. In diesem Fall besteht die beste Designpraxis darin, davon auszugehen, dass sie vom ersten Tag an begonnen haben. Wir haben im Wesentlichen eine kryptografische Version von Murphys Gesetz: „Alles, was das System tatsächlich zerstören kann, wird das System zerstören.“

Das einfachste Beispiel für ein Kryptosystem, das anfällig für einen Vorberechnungsangriff ist, ist eine Verschlüsselung ohne konstanten Schlüssel. Dies war der Fall bei Caesars Chiffre, wodurch einfach jeder Buchstabe des Alphabets um drei Buchstaben nach vorne verschoben wird (die Tabelle ist in einer Schleife, sodass der letzte Buchstabe im Alphabet an dritter Stelle verschlüsselt wird). Auch hier kommt das Kerchhoffs-Prinzip ins Spiel: Sobald ein System gehackt ist, bleibt es für immer gehackt.

Das Konzept ist einfach. Selbst ein unerfahrener Entwickler von Kryptosystemen wird die Bedrohung wahrscheinlich erkennen und sich entsprechend vorbereiten. Betrachtet man die Entwicklung der Kryptographie, waren solche Angriffe für die meisten Chiffren ungeeignet, von den ersten verbesserten Versionen der Caesar-Chiffre bis zum Niedergang der polyalphabetischen Chiffren. Solche Angriffe kehrten erst mit dem Aufkommen der modernen Kryptographie zurück.

Diese Rendite ist auf zwei Faktoren zurückzuführen. Erstens erschienen endlich ausreichend komplexe Kryptosysteme, bei denen die Möglichkeit einer Ausnutzung nach einem Hackerangriff nicht offensichtlich war. Zweitens verbreitete sich die Kryptographie so weit, dass Millionen von Laien jeden Tag Entscheidungen darüber trafen, wo und welche Teile der Kryptographie sie wiederverwenden sollten. Es dauerte einige Zeit, bis Experten die Risiken erkannten und Alarm schlugen.

Erinnern Sie sich an den Precomputation-Angriff: Am Ende des Artikels werden wir uns zwei reale kryptografische Beispiele ansehen, bei denen er eine wichtige Rolle spielte.

Interpolation

Hier ist der berühmte Detektiv Sherlock Holmes, der einen Interpolationsangriff auf den unglücklichen Dr. Watson durchführt:

Ich vermutete sofort, dass Sie aus Afghanistan kamen ... Mein Gedankengang war folgender: „Dieser Mann ist vom Typ her ein Arzt, aber er hat eine militärische Einstellung. Also ein Militärarzt. Er ist gerade aus den Tropen angekommen – sein Gesicht ist dunkel, aber das ist nicht der natürliche Farbton seiner Haut, da seine Handgelenke viel weißer sind. Das Gesicht ist ausgezehrt – offensichtlich hat er viel gelitten und an einer Krankheit gelitten. Er wurde an der linken Hand verletzt – er hält sie regungslos und etwas unnatürlich. Wo in den Tropen könnte ein englischer Militärarzt Strapazen ertragen und verwundet werden? Natürlich in Afghanistan.“ Der ganze Gedankengang dauerte keine Sekunde. Und so sagte ich, dass Sie aus Afghanistan kamen, und Sie waren überrascht.

Holmes konnte aus jedem einzelnen Beweisstück nur sehr wenige Informationen extrahieren. Er konnte zu seiner Schlussfolgerung nur kommen, wenn er sie alle zusammen betrachtete. Ein Interpolationsangriff funktioniert ähnlich, indem er bekannte Klartext- und Chiffretextpaare untersucht, die aus demselben Schlüssel resultieren. Aus jedem Paar werden Einzelbeobachtungen extrahiert, die einen allgemeinen Rückschluss auf den Schlüssel zulassen. Alle diese Schlussfolgerungen sind vage und scheinen nutzlos, bis sie plötzlich eine kritische Masse erreichen und zu der einzig möglichen Schlussfolgerung führen: Egal wie unglaublich es ist, es muss wahr sein. Danach wird entweder der Schlüssel preisgegeben oder der Entschlüsselungsprozess wird so verfeinert, dass er repliziert werden kann.

Lassen Sie uns anhand eines einfachen Beispiels veranschaulichen, wie die Interpolation funktioniert. Nehmen wir an, wir möchten das persönliche Tagebuch unseres Feindes Bob lesen. Er verschlüsselt jede Zahl in seinem Tagebuch mit einem einfachen Kryptosystem, von dem er durch eine Anzeige in der Zeitschrift „A Mock of Cryptography“ erfahren hat. Das System funktioniert folgendermaßen: Bob wählt zwei Zahlen aus, die ihm gefallen: и . Von nun an können Sie jede beliebige Nummer verschlüsseln , es berechnet . Zum Beispiel, wenn Bob wählen würde и , dann die Zahl wird verschlüsselt als .

Nehmen wir an, wir haben am 28. Dezember bemerkt, dass Bob etwas in sein Tagebuch geritzt hat. Wenn er fertig ist, nehmen wir es ruhig in die Hand und schauen uns den letzten Eintrag an:

Дата: 235/520

Liebes Tagebuch,

Heute war ein guter Tag. Durch 64 Heute habe ich ein Date mit Alisa, die in einer WG wohnt 843. Ich glaube wirklich, dass sie es sein könnte 26!

Da es uns sehr wichtig ist, Bob bei seinem Date zu folgen (wir sind in diesem Szenario 15 Jahre alt), ist es wichtig, sowohl das Datum als auch Alices Adresse zu kennen. Glücklicherweise stellen wir fest, dass Bobs Kryptosystem anfällig für einen Interpolationsangriff ist. Wir wissen es vielleicht nicht и , aber wir kennen das heutige Datum, also haben wir zwei Klartext-Chiffretext-Paare. Das wissen wir nämlich verschlüsselt ein Und - in . Das werden wir aufschreiben:

Da wir 15 Jahre alt sind, kennen wir bereits ein System aus zwei Gleichungen mit zwei Unbekannten, das in dieser Situation ausreicht, um es zu finden и ohne Probleme. Jedes Klartext-Chiffretext-Paar stellt eine Einschränkung für Bobs Schlüssel dar, und die beiden Einschränkungen zusammen reichen aus, um den Schlüssel vollständig wiederherzustellen. In unserem Beispiel lautet die Antwort и (bei so dass 26 im Tagebuch entspricht dem Wort „the one“, also „derselbe“ – ca. Fahrbahn).

Interpolationsangriffe beschränken sich natürlich nicht auf solche einfachen Beispiele. Jedes Kryptosystem, das sich auf ein gut verstandenes mathematisches Objekt und eine Liste von Parametern reduziert, ist dem Risiko eines Interpolationsangriffs ausgesetzt – je verständlicher das Objekt, desto höher das Risiko.

Neulinge beschweren sich oft darüber, dass Kryptographie „die Kunst ist, Dinge so hässlich wie möglich zu gestalten“. Schuld daran dürften vor allem Interpolationsangriffe sein. Bob kann entweder ein elegantes mathematisches Konzept anwenden oder sein Date mit Alice privat halten – aber leider kann man normalerweise nicht beides haben. Dies wird deutlich deutlicher, wenn wir schließlich zum Thema der Public-Key-Kryptographie kommen.

Protokollübergreifend/Downgrade

In Now You See Me (2013) versucht eine Gruppe von Illusionisten, den korrupten Versicherungsmagnaten Arthur Tressler um sein gesamtes Vermögen zu betrügen. Um Zugriff auf Arthurs Bankkonto zu erhalten, müssen die Illusionisten entweder seinen Benutzernamen und sein Passwort angeben oder ihn zwingen, persönlich bei der Bank zu erscheinen und an dem Plan teilzunehmen.

Beide Optionen sind sehr schwierig; Die Jungs sind es gewohnt, auf der Bühne aufzutreten und nicht an Geheimdienstoperationen teilzunehmen. Also entscheiden sie sich für die dritte Möglichkeit: Ihr Komplize ruft bei der Bank an und gibt sich als Arthur aus. Zur Überprüfung der Identität stellt die Bank mehrere Fragen, etwa den Namen des Onkels und den Namen des ersten Haustiers; Unsere Helden im Voraus Diese Informationen entlocken sie Arthur ganz einfach mithilfe von cleverem Social Engineering. Ab diesem Zeitpunkt spielt eine hervorragende Passwortsicherheit keine Rolle mehr.

(Laut einer urbanen Legende, die wir persönlich überprüft und verifiziert haben, traf der Kryptograph Eli Beaham einmal einen Bankangestellten, der darauf bestand, eine Sicherheitsfrage zu stellen. Als der Kassierer nach dem Namen seiner Großmutter mütterlicherseits fragte, begann Beaham zu diktieren: „Großbuchstaben X, kleines y, drei...").

Das Gleiche gilt für die Kryptografie, wenn zwei kryptografische Protokolle parallel zum Schutz desselben Vermögenswerts verwendet werden und eines viel schwächer ist als das andere. Das resultierende System wird anfällig für einen protokollübergreifenden Angriff, bei dem ein schwächeres Protokoll angegriffen wird, um an den Preis zu gelangen, ohne das stärkere anzugreifen.

In einigen komplexen Fällen reicht es nicht aus, den Server einfach über ein schwächeres Protokoll zu kontaktieren, sondern erfordert die unfreiwillige Teilnahme eines legitimen Clients. Dies kann durch den sogenannten Downgrade-Angriff organisiert werden. Um diesen Angriff zu verstehen, gehen wir davon aus, dass unsere Illusionisten eine schwierigere Aufgabe haben als im Film. Nehmen wir an, dass ein Bankangestellter (Kassierer) und Arthur auf unvorhergesehene Umstände stoßen, die zu folgendem Dialog führen:

Einbrecher: Hallo? Das ist Arthur Tressler. Ich möchte mein Passwort zurücksetzen.

Kassierer: Großartig. Bitte werfen Sie einen Blick in Ihr persönliches Geheimcodebuch, Seite 28, Wort 3. Alle folgenden Nachrichten werden mit diesem speziellen Wort als Schlüssel verschlüsselt. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Einbrecher: Hey, hey, warte, warte. Ist das wirklich notwendig? Können wir nicht einfach wie normale Menschen reden?

Kassierer: Ich empfehle dies nicht.

Einbrecher: Ich... schau mal, ich hatte einen miesen Tag, okay? Ich bin VIP-Kunde und habe keine Lust, mich in diesen dummen Codebüchern zu wühlen.

Kassierer: Bußgeld. Wenn Sie darauf bestehen, Herr Tressler. Was willst du?

Einbrecher: Bitte, ich möchte mein gesamtes Geld an den Arthur Tressler National Victims Fund spenden.

(Pause).

Kassierer: Ist es jetzt klar? Bitte geben Sie bei größeren Transaktionen Ihre PIN an.

Einbrecher: Mein was?

Kassierer: Auf Ihren persönlichen Wunsch hin ist bei Transaktionen dieser Größenordnung eine PIN für große Transaktionen erforderlich. Dieser Code wurde Ihnen bei der Kontoeröffnung mitgeteilt.

Einbrecher:... Ich habe es verloren. Ist das wirklich notwendig? Können Sie dem Deal nicht einfach zustimmen?

Kassierer: Nein. Es tut mir leid, Herr Tressler. Auch dies ist die Sicherheitsmaßnahme, um die Sie gebeten haben. Wenn Sie möchten, können wir Ihnen einen neuen PIN-Code an Ihr Postfach senden.

Unsere Helden verschieben die Operation. Sie belauschen mehrere große Transaktionen von Tressler und hoffen, die PIN zu erfahren. Aber jedes Mal wird das Gespräch zu verschlüsseltem Kauderwelsch, bevor etwas Interessantes gesagt wird. Eines schönen Tages wird der Plan schließlich in die Tat umgesetzt. Sie warten geduldig auf den Moment, in dem Tressler eine große Transaktion am Telefon tätigen muss, er sich ans Telefon setzt und dann ...

Tressler: Guten Tag. Ich möchte bitte eine Remote-Transaktion abschließen.

Kassierer: Großartig. Bitte werfen Sie einen Blick in Ihr persönliches Geheimcodebuch, Seite...

(Der Einbrecher drückt den Knopf; die Stimme der Kassiererin wird zu einem unverständlichen Geräusch).

Kassierer: - #@$#@$#*@$$@#* wird mit diesem Wort als Schlüssel verschlüsselt. AAAYRR PLRQRZ MMNJK LOJBAN…

Tressler: Entschuldigung, ich habe es nicht ganz verstanden. Noch einmal? Auf welcher Seite? Welches Wort?

Kassierer: Dies ist die Seite @#$@#*$)#*#@()#@$(#@*$(#@*.

Tressler: Was?

Kassierer: Wort Nummer zwanzig @$#@$#%#$.

Tressler: Ernsthaft! Das ist genug! Sie und Ihr Sicherheitsprotokoll sind eine Art Zirkus. Ich weiß, dass du ganz normal mit mir reden kannst.

Kassierer: Ich empfehle nicht…

Tressler: Und ich rate Ihnen nicht, meine Zeit zu verschwenden. Ich möchte nichts mehr davon hören, bis Sie Ihre Telefonleitungsprobleme behoben haben. Können wir diesen Deal abschließen oder nicht?

Kassierer:… Ja. Bußgeld. Was willst du?

Tressler: Ich möchte 20 US-Dollar an Lord Business Investments überweisen, Kontonummer...

Kassierer: Eine Minute Bitte. Es ist ein großes Geschäft. Bitte geben Sie bei größeren Transaktionen Ihre PIN an.

Tressler: Was? Oh, genau. 1234.

Hier ist ein Abwärtsangriff. Das schwächere Protokoll „einfach direkt sprechen“ war vorgesehen Option im Notfall. Und doch sind wir hier.

Sie fragen sich vielleicht, wer bei klarem Verstand ein echtes „sicher bis anders gefragt“-System wie das oben beschriebene entwerfen würde. Doch genauso wie eine fiktive Bank Risiken eingeht, um Kunden zu halten, die keine Vorliebe für Kryptografie haben, tendieren Systeme im Allgemeinen häufig zu Anforderungen, die der Sicherheit gleichgültig oder sogar geradezu feindlich gegenüberstehen.

Genau das geschah 2 mit dem SSLv1995-Protokoll. Die US-Regierung betrachtet die Kryptographie schon seit langem als eine Waffe, die man am besten von in- und ausländischen Feinden fernhalten sollte. Codeteile wurden einzeln für den Export aus den USA freigegeben, oft unter der Bedingung, dass der Algorithmus bewusst geschwächt wurde. Netscape, der Entwickler des beliebtesten Browsers Netscape Navigator, erhielt die Erlaubnis für SSLv2 nur mit dem von Natur aus anfälligen 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 allgemein zugänglich. Allerdings unterstützen Clients und Server seit Jahren eine abgeschwächte „Export“-Kryptografie aufgrund der gleichen Trägheit, die die Unterstützung für jedes Legacy-System aufrechterhält. Die Kunden glaubten, sie könnten auf einen Server stoßen, der nichts anderes unterstützte. Die Server taten dasselbe. Natürlich schreibt das SSL-Protokoll vor, dass Clients und Server niemals ein schwaches Protokoll verwenden sollten, wenn ein besseres verfügbar ist. Aber die gleiche Prämisse galt auch für Tressler und seine Bank.

Diese Theorie fand Eingang in zwei aufsehenerregende Angriffe, die 2015 die Sicherheit des SSL-Protokolls erschütterten und beide von Microsoft-Forschern entdeckt wurden INRIA. Zunächst wurden Einzelheiten des FREAK-Angriffs im Februar bekannt gegeben, drei Monate später folgte ein weiterer ähnlicher Angriff namens Logjam, auf den wir detaillierter eingehen werden, wenn wir zu Angriffen auf die Public-Key-Kryptografie übergehen.

Sicherheitslücke FREAK (auch bekannt als „Smack TLS“) kam ans Licht, als Forscher TLS-Client/Server-Implementierungen analysierten und einen merkwürdigen Fehler entdeckten. Wenn der Client in diesen Implementierungen nicht einmal nach der Verwendung einer schwachen Exportkryptografie fragt, der Server aber dennoch mit solchen Schlüsseln antwortet, sagt der Client „Na ja“ und wechselt zur schwachen Verschlüsselungssuite.

Damals galt die Exportkryptografie weithin als veraltet und tabu, daher war der Angriff ein völliger Schock und betraf viele wichtige Bereiche, darunter die Websites des Weißen Hauses, des IRS und der NSA. Schlimmer noch: Es stellte sich heraus, dass viele anfällige Server die Leistung optimierten, indem sie dieselben Schlüssel wiederverwendeten, anstatt für jede Sitzung neue zu generieren. Dies ermöglichte es, nach der Herabstufung des Protokolls einen Angriff vor der Berechnung durchzuführen: Das Knacken eines Schlüssels blieb relativ teuer (100 US-Dollar und 12 Stunden zum Zeitpunkt der Veröffentlichung), aber die praktischen Kosten für den Angriff auf die Verbindung wurden deutlich reduziert. Es genügt, den Serverschlüssel einmal auszuwählen und ab diesem Zeitpunkt die Verschlüsselung für alle weiteren Verbindungen zu knacken.

Und bevor wir weitermachen, gibt es einen fortgeschrittenen Angriff, der erwähnt werden muss …

Oracle-Angriff

Moxie Marlinspike am besten bekannt als Vater der plattformübergreifenden Krypto-Messaging-App Signal; aber uns persönlich gefällt eine seiner weniger bekannten Innovationen – Prinzip des kryptografischen Untergangs (Kryptografisches Doom-Prinzip). Um es leicht zu paraphrasieren: „Wenn das Protokoll funktioniert keine Führt eine kryptografische Operation an einer Nachricht aus einer potenziell bösartigen Quelle durch und verhält sich je nach Ergebnis anders, ist es zum Scheitern verurteilt.“ Oder in einer schärferen Form: „Nehmen Sie keine Informationen vom Feind zur Verarbeitung, und wenn es sein muss, dann zeigen Sie das Ergebnis zumindest nicht an.“

Lassen wir Pufferüberläufe, Befehlsinjektionen und dergleichen beiseite; sie liegen außerhalb des Rahmens dieser Diskussion. Ein Verstoß gegen das „Doom-Prinzip“ führt zu schwerwiegenden Kryptographie-Hacks, da sich das Protokoll genau wie erwartet verhält.

Nehmen wir als Beispiel einen fiktiven Entwurf mit einer anfälligen Substitutions-Chiffre und demonstrieren dann einen möglichen Angriff. Wir haben zwar bereits einen Angriff auf eine Substitutions-Chiffre mithilfe der Frequenzanalyse gesehen, es handelt sich jedoch nicht nur um „eine weitere Möglichkeit, dieselbe Chiffre zu knacken“. Im Gegenteil, Oracle-Angriffe sind eine viel modernere Erfindung, die auf viele Situationen anwendbar ist, in denen die Frequenzanalyse fehlschlägt, und wir werden dies im nächsten Abschnitt demonstrieren. Hier wird die einfache Chiffre nur gewählt, um das Beispiel klarer zu machen.

Also kommunizieren Alice und Bob über eine einfache Substitutionsverschlüsselung mit einem nur ihnen bekannten Schlüssel. Bei der Länge der Nachrichten sind sie sehr streng: Sie sind genau 20 Zeichen lang. Sie einigten sich also darauf, dass jemand, der eine kürzere Nachricht senden möchte, am Ende der Nachricht einen Blindtext hinzufügen sollte, damit die Nachricht genau 20 Zeichen lang ist. Nach einiger Diskussion entschieden sie, dass sie nur die folgenden Blindtexte akzeptieren würden: a, bb, ccc, dddd usw. Somit ist ein Blindtext beliebiger Länge bekannt.

Wenn Alice oder Bob eine Nachricht erhalten, überprüfen sie zunächst, ob die Nachricht die richtige Länge (20 Zeichen) hat und ob das Suffix der richtige Dummy-Text ist. Ist dies nicht der Fall, reagieren sie mit einer entsprechenden Fehlermeldung. Wenn Textlänge und Blindtext in Ordnung sind, liest der Empfänger die Nachricht selbst 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 verfügt nicht über den Schlüssel und kann daher keine aussagekräftige Nachricht fälschen. Da das Protokoll jedoch gegen das Doom-Prinzip verstößt, kann ein Angreifer Alice immer noch dazu verleiten, die Schlüsselinformationen preiszugeben, wie unten gezeigt.

Einbrecher: PREWF ZHJKL MMMN. LA

Alice: Ungültiger Dummy-Text.

Einbrecher: PREWF ZHJKL MMMN. LB

Alice: Ungültiger Dummy-Text.

Einbrecher: PREWF ZHJKL MMMN. LC

Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Der Einbrecher hat keine Ahnung, was Alice gerade gesagt hat, bemerkt aber das Symbol C muss passen a, da Alice den Dummy-Text akzeptiert hat.

Einbrecher: REWF ZHJKL MMMN. LAA

Alice: Ungültiger Dummy-Text.

Einbrecher: REWF ZHJKL MMMN. LBB

Alice: Ungültiger Dummy-Text.

Nach mehreren Versuchen...

Einbrecher: REWF ZHJKL MMMN. LGG

Alice: Ungültiger Dummy-Text.

Einbrecher: REWF ZHJKL MMMN. LHH

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

Auch hier hat der Angreifer keine Ahnung, was Alice gerade gesagt hat, stellt jedoch fest, dass H mit b übereinstimmen muss, da Alice den Dummy-Text akzeptiert hat.

Und so weiter, bis der Angreifer die Bedeutung jedes Zeichens kennt.

Auf den ersten Blick ähnelt die Methode einem gezielten Klartextangriff. Am Ende wählt der Angreifer die Chiffretexte aus und der Server verarbeitet sie gehorsam. Der Hauptunterschied, der diese Angriffe in der realen Welt realisierbar macht, besteht darin, dass der Angreifer keinen Zugriff auf das eigentliche Transkript benötigt – eine Serverantwort, selbst eine so harmlose wie „Ungültiger Dummy-Text“, reicht aus.

Obwohl dieser spezielle Angriff aufschlussreich ist, sollten Sie sich nicht zu sehr auf die Einzelheiten des „Dummy-Text“-Schemas, das verwendete spezifische Kryptosystem oder die genaue Reihenfolge der vom Angreifer gesendeten Nachrichten konzentrieren. Die Grundidee besteht darin, dass Alice je nach den Eigenschaften des Klartexts unterschiedlich reagiert und dabei nicht überprüft, ob der entsprechende Chiffretext tatsächlich von einer vertrauenswürdigen Partei stammt. Somit erlaubt Alice dem Angreifer, geheime Informationen aus ihren Antworten herauszupressen.

In diesem Szenario kann viel geändert werden. Die Symbole, auf die Alice reagiert, oder der Unterschied in ihrem Verhalten oder sogar das verwendete Kryptosystem. Aber das Prinzip wird dasselbe bleiben und der Angriff als Ganzes wird in der einen oder anderen Form realisierbar bleiben. Die grundlegende Implementierung dieses Angriffs hat dazu beigetragen, mehrere Sicherheitslücken aufzudecken, die wir uns gleich ansehen werden. Aber zunächst müssen einige theoretische Lektionen gelernt werden. Wie kann dieses fiktive „Alice-Skript“ für einen Angriff verwendet werden, der auf einer echten modernen Chiffre funktionieren kann? Ist das überhaupt möglich, sogar theoretisch?

1998 beantwortete der Schweizer Kryptograf Daniel Bleichenbacher diese Frage mit Ja. Er demonstrierte einen Oracle-Angriff auf das weit verbreitete Public-Key-Kryptosystem RSA unter Verwendung eines bestimmten Nachrichtenschemas. In einigen RSA-Implementierungen antwortet der Server mit unterschiedlichen Fehlermeldungen, je nachdem, ob der Klartext mit dem Schema übereinstimmt oder nicht; Dies reichte aus, um den Angriff durchzuführen.

Vier Jahre später, im Jahr 2002, demonstrierte der französische Kryptograf Serge Vaudenay einen Orakelangriff, der fast identisch mit dem im obigen Alice-Szenario beschriebenen war – außer dass er anstelle einer fiktiven Chiffre eine ganze respektable Klasse moderner Chiffren brach, die tatsächlich von Menschen verwendet werden. Vaudenays Angriff zielt insbesondere auf Chiffren mit fester Eingabegröße („Blockchiffren“) ab, wenn sie im sogenannten „CBC-Verschlüsselungsmodus“ und mit einem bestimmten beliebten Auffüllschema verwendet werden, das im Grunde dem im Alice-Szenario entspricht.

Ebenfalls im Jahr 2002 war der amerikanische Kryptograph John Kelsey Mitautor Twofish – schlug verschiedene Oracle-Angriffe auf Systeme vor, die Nachrichten komprimieren und dann verschlüsseln. Am bemerkenswertesten war dabei ein Angriff, der sich die Tatsache zunutze machte, dass es oft möglich ist, aus der Länge des Chiffretextes auf die ursprüngliche Länge des Klartextes zu schließen. Theoretisch ermöglicht dies einen Oracle-Angriff, der Teile des ursprünglichen Klartexts wiederherstellt.

Im Folgenden geben wir eine detailliertere Beschreibung der Vaudenay- und Kelsey-Angriffe (wir werden eine detailliertere Beschreibung des Bleichenbacher-Angriffs geben, wenn wir zu Angriffen auf die Public-Key-Kryptographie übergehen). Trotz unserer besten Bemühungen wird der Text etwas technisch; Wenn Ihnen das oben Genannte ausreicht, überspringen Sie die nächsten beiden Abschnitte.

Vodenes Angriff

Um den Vaudenay-Angriff zu verstehen, müssen wir zunächst etwas mehr über Blockchiffren und Verschlüsselungsmodi sprechen. Eine „Blockchiffre“ ist, wie erwähnt, eine Chiffre, die einen Schlüssel und eine Eingabe einer bestimmten festen Länge („Blocklänge“) nimmt und einen verschlüsselten Block derselben Länge erzeugt. Blockchiffren sind weit verbreitet und gelten als relativ sicher. Die inzwischen ausgemusterte DES, die als erste moderne Chiffre gilt, war eine Blockchiffre. Wie oben erwähnt, gilt das Gleiche auch für AES, das heute weit verbreitet ist.

Leider haben Blockchiffren eine eklatante Schwäche. Die typische Blockgröße beträgt 128 Bit oder 16 Zeichen. Offensichtlich erfordert die moderne Kryptografie die Arbeit mit größeren Eingabedaten, und hier kommen die Verschlüsselungsmodi ins Spiel. Der Verschlüsselungsmodus ist im Wesentlichen ein Hack: Es handelt sich um eine Möglichkeit, eine Blockverschlüsselung, die nur Eingaben einer bestimmten Größe akzeptiert, auf Eingaben beliebiger Länge anzuwenden.

Vodenes Angriff konzentriert sich auf die beliebte CBC-Betriebsart (Cipher Block Chaining). Der Angriff behandelt die zugrunde liegende Blockchiffre als magische, uneinnehmbare Black Box und umgeht deren Sicherheit vollständig.

Hier ist ein Diagramm, das zeigt, wie der CBC-Modus funktioniert:

Das eingekreiste Pluszeichen bedeutet die XOR-Operation (exklusives ODER). Beispielsweise wird der zweite Block Chiffretext empfangen:

1. Durch Ausführen einer XOR-Operation am zweiten Klartextblock mit dem ersten Chiffretextblock.
2. Verschlüsseln des resultierenden Blocks mit einer Blockverschlüsselung unter Verwendung eines Schlüssels.

Da CBC die binäre XOR-Operation so intensiv nutzt, nehmen wir uns einen Moment Zeit, um uns einige ihrer Eigenschaften ins Gedächtnis zu rufen:

• Idempotenz:
• Kommutativität:
• Assoziativität:
• Selbstreversibilität:
• Bytegröße: Byte n von = (Byte n von ) (Byte n von )

Normalerweise implizieren diese Eigenschaften, dass eine Gleichung mit XOR-Operationen und einer Unbekannten gelöst werden kann. Zum Beispiel, wenn wir das wissen mit dem Unbekannten und berühmt и , dann können wir uns auf die oben genannten Eigenschaften verlassen, um die Gleichung für zu lösen . Durch Anwenden von XOR auf beiden Seiten der Gleichung mit , wir bekommen . Das alles wird gleich sehr relevant werden.

Es gibt zwei kleine Unterschiede und einen großen Unterschied zwischen unserem Alice-Szenario und Vaudenays Angriff. Zwei kleinere:

• Im Drehbuch erwartete Alice, dass Klartexte mit den Zeichen enden a, bb, ccc usw. Beim Wodene-Angriff erwartet das Opfer stattdessen, dass die Klartexte N-mal mit dem N-Byte enden (also hexadezimal 01 oder 02 02 oder 03 03 03 usw.). Dies ist ein rein kosmetischer Unterschied.
• Im Alice-Szenario konnte man anhand der Antwort „Falscher Blindtext“ leicht erkennen, ob Alice die Nachricht angenommen hatte. Bei Vodenes Angriff sind weitere Analysen erforderlich und eine präzise Umsetzung auf Seiten des Opfers ist wichtig; Aber der Kürze halber gehen wir davon aus, dass diese Analyse immer noch möglich ist.

Hauptunterschied:

• Da wir nicht dasselbe Kryptosystem verwenden, wird die Beziehung zwischen den vom Angreifer kontrollierten Chiffretext-Bytes und den Geheimnissen (Schlüssel und Klartext) offensichtlich unterschiedlich sein. Daher muss der Angreifer bei der Erstellung von Chiffretexten und der Interpretation von Serverantworten eine andere Strategie anwenden.

Dieser große Unterschied ist das letzte Puzzleteil zum Verständnis des Vaudenay-Angriffs. Nehmen wir uns also einen Moment Zeit, um darüber nachzudenken, warum und wie ein Oracle-Angriff auf CBC überhaupt durchgeführt werden kann.

Angenommen, wir erhalten einen CBC-Chiffretext mit 247 Blöcken und möchten ihn entschlüsseln. Wir können gefälschte Nachrichten an den Server senden, genau wie wir zuvor gefälschte Nachrichten an Alice senden konnten. Der Server entschlüsselt die Nachrichten für uns, zeigt die Entschlüsselung aber nicht an – stattdessen meldet der Server wiederum, wie bei Alice, nur eine Information: ob der Klartext gültige Auffüllungen hat oder nicht.

Bedenken Sie, dass wir in Alices Szenario die folgenden Beziehungen hatten:

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

Nennen wir das „Alice-Gleichung“. Wir haben den Geheimtext kontrolliert; der Server (Alice) hat vage Informationen über den empfangenen Klartext preisgegeben; und dies ermöglichte es uns, Informationen über den letzten Faktor abzuleiten – den Schlüssel. Wenn wir analog dazu eine solche Verbindung für das CBC-Skript finden, könnten wir möglicherweise auch dort einige geheime Informationen extrahieren.

Glücklicherweise gibt es tatsächlich Beziehungen, die wir nutzen können. Betrachten Sie die Ausgabe des letzten Aufrufs zum Entschlüsseln einer Blockchiffre und bezeichnen Sie diese Daten als . Wir bezeichnen auch Klartextblöcke und Chiffretextblöcke . Schauen Sie sich das CBC-Diagramm noch einmal an und beobachten Sie, was passiert:

Nennen wir dies die „CBC-Gleichung“.

In Alices Szenario konnten wir durch die Überwachung des Chiffretexts und die Beobachtung des entsprechenden Klartextlecks einen Angriff starten, der den dritten Term in der Gleichung – den Schlüssel – wiederherstellte. Im CBC-Szenario überwachen wir auch den Chiffretext und beobachten Informationslecks im entsprechenden Klartext. Wenn die Analogie zutrifft, können wir Informationen darüber erhalten .

Nehmen wir an, wir haben wirklich restauriert , was dann? Dann können wir den gesamten letzten Klartextblock auf einmal ausdrucken (), einfach durch Eingabe (was wir haben) und
erhalten in die CBC-Gleichung.

Da wir nun hinsichtlich des Gesamtangriffsplans optimistisch sind, ist es an der Zeit, die Details auszuarbeiten. Bitte achten Sie genau darauf, wie Klartextinformationen auf den Server gelangen. In Alices Skript trat das Leck auf, weil Alice nur dann mit der richtigen Nachricht antwortete, wenn $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ mit der Zeile endete a (oder bbusw., aber die Wahrscheinlichkeit, dass diese Zustände durch Zufall ausgelöst werden, war sehr gering. Ähnlich wie bei CBC akzeptiert der Server die Auffüllung genau dann, wenn endet hexadezimal 01. Versuchen wir also den gleichen Trick: Senden Sie gefälschte Chiffretexte mit unseren eigenen gefälschten Werten bis der Server die Füllung akzeptiert.

Wenn der Server ein Padding für eine unserer gefälschten Nachrichten akzeptiert, bedeutet das Folgendes:

Jetzt verwenden wir die Byte-Byte-XOR-Eigenschaft:

Wir kennen den ersten und dritten Term. Und wir haben bereits gesehen, dass wir dadurch den verbleibenden Begriff – das letzte Byte von – wiederherstellen können :

Dies gibt uns auch das letzte Byte des letzten Klartextblocks über die CBC-Gleichung und die Byte-für-Byte-Eigenschaft.

Wir könnten es dabei belassen und zufrieden sein, dass wir einen Angriff auf eine theoretisch starke Chiffre durchgeführt haben. Tatsächlich können wir aber noch viel mehr tun: Wir können tatsächlich den gesamten Text wiederherstellen. Dies erfordert einen Trick, der nicht in Alices ursprünglichem Skript enthalten war und für den Oracle-Angriff nicht erforderlich ist, aber es lohnt sich trotzdem, ihn zu erlernen.

Um es zu verstehen, beachten Sie zunächst, dass das Ergebnis der Ausgabe des korrekten Werts des letzten Bytes ist Wir haben eine neue Fähigkeit. Beim Fälschen von Chiffretexten können wir nun das letzte Byte des entsprechenden Klartextes manipulieren. Auch dies hat mit der CBC-Gleichung und der Byte-für-Byte-Eigenschaft zu tun:

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

Das konnten wir vorher nicht machen, da wir das letzte Byte noch nicht hatten .

Wie wird uns das helfen? Angenommen, wir erstellen nun alle Chiffretexte so, dass in den entsprechenden Klartexten das letzte Byte gleich ist 02. Der Server akzeptiert jetzt nur noch Auffüllungen, wenn der Klartext mit endet 02 02. Da wir das letzte Byte korrigiert haben, geschieht dies nur, wenn das vorletzte Byte des Klartexts ebenfalls 02 ist. Wir senden weiterhin gefälschte Chiffretextblöcke und ändern das vorletzte Byte, bis der Server das Auffüllen für eines davon akzeptiert. An diesem Punkt erhalten wir:

Und wir stellen das vorletzte Byte wieder her genau wie das letzte restauriert wurde. Wir machen im gleichen Sinne weiter: Wir korrigieren die letzten beiden Bytes des Klartextes zu 03 03, wiederholen wir diesen Angriff für das dritte Byte vom Ende und so weiter, um letztendlich eine vollständige Wiederherstellung herbeizuführen .

Was ist mit dem Rest des Textes? Bitte beachten Sie, dass der Wert ist eigentlich $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Wir können stattdessen jeden anderen Block einfügen , und der Angriff wird trotzdem erfolgreich sein. Tatsächlich können wir den Server bitten, $inline$text{BLOCK_DECRYPT}$inline$ für alle Daten auszuführen. An diesem Punkt ist das Spiel vorbei – wir können jeden Chiffretext entschlüsseln (sehen Sie sich das CBC-Entschlüsselungsdiagramm noch einmal an, um dies zu sehen; und beachten Sie, dass der IV öffentlich ist).

Diese spezielle Methode spielt eine entscheidende Rolle bei dem Oracle-Angriff, dem wir später begegnen werden.

Kelseys Angriff

Unser sympathischer John Kelsey legte die Prinzipien dar, die vielen möglichen Angriffen zugrunde liegen, und nicht nur die Details eines bestimmten Angriffs auf eine bestimmte Chiffre. Sein 2002-Artikel des Jahres ist eine Studie über mögliche Angriffe auf verschlüsselte komprimierte Daten. Dachten Sie, dass die Information, dass die Daten vor der Verschlüsselung komprimiert wurden, nicht ausreichte, um einen Angriff durchzuführen? Es stellt sich heraus, dass das genug ist.

Dieses überraschende Ergebnis ist auf zwei Prinzipien zurückzuführen. Erstens besteht eine starke Korrelation zwischen der Länge des Klartextes und der Länge des Chiffretextes; für viele Chiffren exakte Gleichheit. Zweitens besteht bei der Durchführung einer Komprimierung auch ein starker Zusammenhang zwischen der Länge der komprimierten Nachricht und dem Grad des „Rauschens“ des Klartextes, d. h. dem Anteil sich nicht wiederholender Zeichen (der Fachbegriff lautet „hohe Entropie“). ).

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

Klartext 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Klartext 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Nehmen wir an, beide Klartexte werden komprimiert und dann verschlüsselt. Sie erhalten zwei resultierende Chiffretexte und müssen erraten, welcher Chiffretext zu welchem ​​Klartext passt:

Geheimtext 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Geheimtext 2: DWKJZXYU

Die Antwort ist klar. Von den Klartexten konnte nur Klartext 1 auf die geringe Länge des zweiten Chiffretexts komprimiert werden. Wir haben das herausgefunden, ohne etwas über den Komprimierungsalgorithmus, den Verschlüsselungsschlüssel oder sogar die Chiffre selbst zu wissen. Verglichen mit der Hierarchie möglicher kryptografischer Angriffe ist das schon ziemlich verrückt.

Kelsey weist weiter darauf hin, dass dieses Prinzip unter bestimmten ungewöhnlichen Umständen auch zur Durchführung eines Orakelangriffs genutzt werden kann. Insbesondere wird beschrieben, wie ein Angreifer den geheimen Klartext wiederherstellen kann, wenn er den Server dazu zwingen kann, die Formulardaten (den Klartext gefolgt von) zu verschlüsseln solange er die Kontrolle hat und kann irgendwie die Länge des verschlüsselten Ergebnisses überprüfen.

Auch hier haben wir, wie bei anderen Oracle-Angriffen, die Beziehung:

Auch hier kontrollieren wir einen Term (), sehen wir ein kleines Informationsleck über ein anderes Mitglied (Chiffretext) und versuchen, das letzte wiederherzustellen (Klartext). Trotz der Analogie ist dies im Vergleich zu anderen Oracle-Angriffen, die wir gesehen haben, eine etwas ungewöhnliche Situation.

Um zu veranschaulichen, wie ein solcher Angriff funktionieren könnte, verwenden wir ein fiktives Komprimierungsschema, das wir gerade erfunden haben: TOYZIP. Es sucht nach Textzeilen, die zuvor im Text erschienen sind, und ersetzt sie durch drei Platzhalterbytes, die angeben, wo eine frühere Instanz der Zeile zu finden ist und wie oft sie dort vorkommt. Zum Beispiel die Linie helloworldhello komprimiert werden kann helloworld[00][00][05] 13 Bytes lang im Vergleich zu den ursprünglichen 15 Bytes.

Angenommen, ein Angreifer versucht, den Klartext eines Formulars wiederherzustellen password=..., wobei das Passwort selbst unbekannt ist. Gemäß Kelseys Angriffsmodell könnte ein Angreifer den Server auffordern, Formularnachrichten zu komprimieren und dann zu verschlüsseln (Klartext, gefolgt von ) wo  - freier Text. Wenn der Server seine Arbeit beendet hat, meldet er die Länge des Ergebnisses. Der Angriff läuft so ab:

Einbrecher: Bitte komprimieren und verschlüsseln Sie den Klartext ohne Auffüllen.

Server: Ergebnislänge 14.

Einbrecher: Bitte komprimieren und verschlüsseln Sie den angehängten Klartext password=a.

Server: Ergebnislänge 18.

Der Cracker notiert: [Original 14] + [drei Bytes, die ersetzt wurden password=] + a

Einbrecher: Bitte komprimieren und verschlüsseln Sie den hinzugefügten Klartext password=b.

Server: Ergebnislänge 18.

Einbrecher: Bitte komprimieren und verschlüsseln Sie den hinzugefügten Klartext password=с.

Server: Ergebnislänge 17.

Der Cracker notiert: [Original 14] + [drei Bytes, die ersetzt wurden password=c]. Dies setzt voraus, dass der ursprüngliche Klartext die Zeichenfolge enthält password=c. Das heißt, das Passwort beginnt mit einem Buchstaben c

Einbrecher: Bitte komprimieren und verschlüsseln Sie den hinzugefügten Klartext password=сa.

Server: Ergebnislänge 18.

Der Cracker notiert: [Original 14] + [drei Bytes, die ersetzt wurden password=с] + a

Einbrecher: Bitte komprimieren und verschlüsseln Sie den hinzugefügten Klartext password=сb.

Server: Ergebnislänge 18.

(… Etwas später…)

Einbrecher: Bitte komprimieren und verschlüsseln Sie den hinzugefügten Klartext password=со.

Server: Ergebnislänge 17.

Der Cracker notiert: [Original 14] + [drei Bytes, die ersetzt wurden password=co]. Mit der gleichen Logik kommt der Angreifer zu dem Schluss, dass das Passwort mit den Buchstaben beginnt co

Und so weiter, bis das gesamte Passwort wiederhergestellt ist.

Man könnte dem Leser verzeihen, dass es sich hierbei um eine rein akademische Übung handelt und dass ein solches Angriffsszenario in der realen Welt niemals auftreten würde. Wie wir gleich sehen werden, ist es leider besser, die Kryptographie nicht aufzugeben.

Schwachstellen der Marke: KRIMINALITÄT, PUDEL, ERTRINKEN

Nachdem wir die Theorie im Detail studiert haben, können wir schließlich sehen, wie diese Techniken bei realen kryptografischen Angriffen angewendet werden.

KRIMINALITÄT

Wenn der Angriff auf den Browser und das Netzwerk des Opfers abzielt, werden einige einfacher und andere schwieriger sein. Es ist zum Beispiel einfach, den Verkehr des Opfers zu erkennen: Setzen Sie sich einfach mit ihm in dasselbe Café mit WLAN. Aus diesem Grund wird potentiellen Opfern (also jedem) generell empfohlen, eine verschlüsselte Verbindung zu nutzen. Es wird schwieriger, aber immer noch möglich, HTTP-Anfragen im Namen des Opfers an eine Website eines Drittanbieters (z. B. Google) zu richten. Der Angreifer muss das Opfer mit einem Skript, das die Anfrage stellt, auf eine bösartige Webseite locken. Der Webbrowser stellt automatisch das entsprechende Sitzungscookie bereit.

Das scheint erstaunlich. Wenn Bob gehen würde evil.com, könnte das Skript auf dieser Website Google einfach auffordern, Bobs Passwort per E-Mail an zu senden? [email protected]? Nun, theoretisch ja, aber in Wirklichkeit nein. Dieses Szenario wird als Cross-Site-Request-Forgery-Angriff bezeichnet (Standortübergreifende Anforderungsfälschung, CSRF) und war Mitte der 90er Jahre beliebt. Heute wenn evil.com Versuchen Sie diesen Trick, antwortet Google (oder jede Website mit Selbstachtung) normalerweise: „Großartig, aber Ihr CSRF-Token für diese Transaktion wird … ähm …“ три триллиона и семь. Bitte wiederholen Sie diese Nummer.“ Moderne Browser verfügen über eine sogenannte „Same-Origin-Richtlinie“, bei der Skripte auf Website A keinen Zugriff auf Informationen haben, die von Website B gesendet werden. Das Skript läuft also weiter evil.com kann Anfragen an senden google.com, kann aber die Antworten nicht lesen oder die Transaktion nicht tatsächlich abschließen.

Wir müssen betonen, dass alle diese Schutzmaßnahmen bedeutungslos sind, es sei denn, Bob verwendet eine verschlüsselte Verbindung. Ein Angreifer kann einfach Bobs Datenverkehr lesen und das Sitzungscookie von Google wiederherstellen. Mit diesem Cookie öffnet er einfach einen neuen Google-Tab, ohne seinen eigenen Browser zu verlassen, und verkörpert Bob, ohne auf lästige Same-Origin-Richtlinien zu stoßen. Doch leider kommt dies für Einbrecher immer seltener vor. Das Internet als Ganzes hat unverschlüsselten Verbindungen schon lange den Kampf angesagt, und Bobs ausgehender Datenverkehr ist wahrscheinlich verschlüsselt, ob er will oder nicht. Darüber hinaus war der Verkehr von Beginn der Implementierung des Protokolls an ebenfalls vorhanden schrumpfte vor der Verschlüsselung; Dies war gängige Praxis, um die Latenz zu reduzieren.

Hier kommt es ins Spiel KRIMINALITÄT (Compression Ratio Infoleak Made Easy, einfache Leckage durch das Kompressionsverhältnis). Die Sicherheitslücke wurde im September 2012 von den Sicherheitsforschern Juliano Rizzo und Thai Duong entdeckt. Wir haben bereits die gesamte theoretische Grundlage untersucht, die es uns ermöglicht zu verstehen, was sie getan haben und wie. Ein Angreifer könnte Bobs Browser zwingen, Anfragen an Google zu senden und dann die Antworten im lokalen Netzwerk in komprimierter, verschlüsselter Form abzuhören. Deshalb haben wir:

Hier kontrolliert der Angreifer die Anfrage und hat Zugriff auf den Traffic-Sniffer, einschließlich der Paketgröße. Kelseys fiktives Szenario wurde lebendig.

Die Autoren von CRIME verstanden die Theorie und erstellten einen Exploit, der Sitzungscookies für eine Vielzahl von Websites stehlen kann, darunter Gmail, Twitter, Dropbox und Github. Die Sicherheitslücke betraf die meisten modernen Webbrowser und führte dazu, dass Patches veröffentlicht wurden, die die Komprimierungsfunktion in SSL stillschweigend vergruben, sodass sie überhaupt nicht verwendet werden konnte. Der einzige, der vor der Sicherheitslücke geschützt war, war der ehrwürdige Internet Explorer, der überhaupt keine SSL-Komprimierung verwendete.

PUDEL

Im Oktober 2014 sorgte das Google-Sicherheitsteam in der Sicherheits-Community für Aufsehen. Sie konnten eine vor mehr als zehn Jahren geschlossene Schwachstelle im SSL-Protokoll ausnutzen.

Es stellt sich heraus, dass auf den Servern zwar das glänzende neue TLSv1.2 läuft, viele aber aus Gründen der Abwärtskompatibilität mit Internet Explorer 3 die Unterstützung für das alte SSLv6 eingestellt haben. Wir haben bereits über Downgrade-Angriffe gesprochen, Sie können sich also vorstellen, was vor sich geht. Eine gut orchestrierte Sabotage des Handshake-Protokolls und die Server sind bereit, zum guten alten SSLv3 zurückzukehren, was im Wesentlichen die letzten 15 Jahre der Sicherheitsforschung zunichte macht.

Für den historischen Kontext: Hier ist eine kurze Zusammenfassung der Geschichte von SSL bis Version 2 von Matthew Green:

Transport Layer Security (TLS) ist das wichtigste Sicherheitsprotokoll im Internet. [..] Fast jede Transaktion, die Sie im Internet durchführen, hängt von TLS ab. [..] Aber TLS war nicht immer TLS. Das Protokoll begann sein Leben im Netscape-Kommunikation namens „Secure Sockets Layer“ oder SSL. Gerüchten zufolge war die erste Version von SSL so schrecklich, dass die Entwickler alle Ausdrucke des Codes sammelten und auf einer geheimen Mülldeponie in New Mexico vergruben. Damit ist es tatsächlich die erste öffentlich verfügbare Version von SSL Version SSL 2. Es ist ziemlich beängstigend, und [..] es war ein Produkt der Mitte der 90er Jahre, das moderne Kryptographen als „Dunkles Zeitalter der Kryptographie" Viele der abscheulichsten kryptografischen Angriffe, die wir heute kennen, wurden noch nicht entdeckt. Infolgedessen wurden die Entwickler des SSLv2-Protokolls im Wesentlichen im Dunkeln tappen gelassen, und sie standen vor der Herausforderung viele schreckliche Monster – zu ihrem Leidwesen und zu unserem Vorteil, da die Angriffe auf SSLv2 unschätzbare Lehren für die nächste Protokollgeneration hinterlassen haben.

Nach diesen Ereignissen gestaltete der frustrierte Netscape 1996 das SSL-Protokoll von Grund auf neu. Das Ergebnis war SSL Version 3, die behebt mehrere bekannte Sicherheitsprobleme seines Vorgängers.

Zum Glück für Einbrecher bedeutet „einige“ nicht „alle“. Insgesamt stellte SSLv3 alle notwendigen Bausteine ​​bereit, um einen Vodene-Angriff zu starten. Das Protokoll verwendete eine Blockverschlüsselung im CBC-Modus und ein unsicheres Auffüllschema (dies wurde in TLS korrigiert; daher ist ein Downgrade-Angriff erforderlich). Wenn Sie sich an das Auffüllschema in unserer ursprünglichen Beschreibung des Vaudenay-Angriffs erinnern, ist das SSLv3-Schema sehr ähnlich.

Doch leider bedeutet „ähnlich“ für Einbrecher nicht gleich „identisch“. Das SSLv3-Auffüllschema besteht aus „N Zufallsbytes gefolgt von der Zahl N“. Versuchen Sie unter diesen Bedingungen, einen imaginären Chiffretextblock auszuwählen und alle Schritte des ursprünglichen Schemas von Vaudene durchzuführen: Sie werden feststellen, dass der Angriff erfolgreich das letzte Byte aus dem entsprechenden Klartextblock extrahiert, aber nicht weiter geht. Jedes 16. Byte des Chiffretextes zu entschlüsseln ist ein toller Trick, aber kein Sieg.

Angesichts des Scheiterns griff das Google-Team zum letzten Ausweg: Sie wechselten zu einem leistungsstärkeren Bedrohungsmodell – dem in CRIME verwendeten. Geht man davon aus, dass der Angreifer ein Skript ist, das im Browser-Tab des Opfers läuft und Sitzungscookies extrahieren kann, ist der Angriff immer noch beeindruckend. Während das umfassendere Bedrohungsmodell weniger realistisch ist, haben wir im vorherigen Abschnitt gesehen, dass dieses spezielle Modell machbar ist.

Angesichts dieser leistungsfähigeren Angreiferfähigkeiten kann der Angriff nun fortgesetzt werden. Beachten Sie, dass der Angreifer weiß, wo das verschlüsselte Sitzungscookie im Header erscheint, und die Länge der vorangehenden HTTP-Anfrage kontrolliert. Daher ist es in der Lage, die HTTP-Anfrage so zu manipulieren, dass das letzte Byte des Cookies am Ende des Blocks ausgerichtet ist. Nun ist dieses Byte zur Entschlüsselung geeignet. Sie können der Anfrage einfach ein Zeichen hinzufügen und das vorletzte Byte des Cookies bleibt an derselben Stelle und kann mit derselben Methode ausgewählt werden. Der Angriff wird auf diese Weise fortgesetzt, bis die Cookie-Datei vollständig wiederhergestellt ist. Es heißt POODLE: Padding Oracle on Downgraded Legacy Encryption.

ERTRINKEN

Wie bereits erwähnt, hatte SSLv3 seine Mängel, unterschied sich jedoch grundlegend von seinem Vorgänger, da das undichte SSLv2 ein Produkt einer anderen Ära war. Dort könnten Sie die Nachricht in der Mitte unterbrechen: соглашусь на это только через мой труп wurde zu соглашусь на это; Client und Server könnten sich online treffen, Vertrauen aufbauen und Geheimnisse vor dem Angreifer austauschen, der sich dann leicht als beide ausgeben könnte. Es gibt auch das Problem mit der Exportkryptographie, das wir bei der Betrachtung von FREAK erwähnt haben. Dies waren kryptografische Sodom und Gomorra.

Im März 2016 kam ein Team von Forschern aus verschiedenen technischen Bereichen zusammen und machte eine verblüffende Entdeckung: SSLv2 wird immer noch in Sicherheitssystemen verwendet. Ja, Angreifer konnten moderne TLS-Sitzungen nicht mehr auf SSLv2 herunterstufen, da diese Lücke nach FREAK und POODLE geschlossen wurde, sie können sich jedoch weiterhin mit Servern verbinden und selbst SSLv2-Sitzungen initiieren.

Sie fragen sich vielleicht: Warum kümmert es uns, was sie dort tun? Sie haben eine anfällige Sitzung, die jedoch keine Auswirkungen auf andere Sitzungen oder die Sicherheit des Servers haben sollte – oder? Nicht ganz. Ja, so sollte es theoretisch sein. Aber nein, denn die Generierung von SSL-Zertifikaten stellt einen gewissen Aufwand dar, der dazu führt, dass viele Server dieselben Zertifikate und damit auch dieselben RSA-Schlüssel für TLS- und SSLv2-Verbindungen verwenden. Erschwerend kommt hinzu, dass aufgrund eines OpenSSL-Fehlers die Option „SSLv2 deaktivieren“ in dieser beliebten SSL-Implementierung nicht wirklich funktionierte.

Dies ermöglichte einen protokollübergreifenden Angriff auf TLS, genannt ERTRINKEN (Entschlüsseln von RSA mit veralteter und abgeschwächter Verschlüsselung, Entschlüsseln von RSA mit veralteter und abgeschwächter Verschlüsselung). Denken Sie daran, dass dies nicht dasselbe ist wie ein kurzer Angriff; Der Angreifer muss nicht als „Mann in der Mitte“ agieren und den Client nicht in die Teilnahme an einer unsicheren Sitzung einbeziehen. Angreifer initiieren einfach selbst eine unsichere SSLv2-Sitzung mit dem Server, greifen das schwache Protokoll an und stellen den privaten RSA-Schlüssel des Servers wieder her. Dieser Schlüssel ist auch für TLS-Verbindungen gültig und ab diesem Zeitpunkt kann keine noch so hohe TLS-Sicherheit mehr verhindern, dass er kompromittiert wird.

Um es zu knacken, benötigen Sie jedoch einen funktionierenden Angriff gegen SSLv2, der es Ihnen ermöglicht, nicht nur bestimmten Datenverkehr, sondern auch den geheimen RSA-Serverschlüssel wiederherzustellen. Obwohl es sich um ein komplexes Setup handelt, konnten die Forscher jede Schwachstelle auswählen, die nach SSLv2 vollständig geschlossen wurde. Sie fanden schließlich eine geeignete Option: den Bleichenbacher-Angriff, den wir bereits erwähnt hatten und den wir im nächsten Artikel ausführlich erläutern werden. SSL und TLS sind vor diesem Angriff geschützt, aber einige zufällige Funktionen von SSL in Kombination mit Kurzschlüsseln in der Export-Kryptografie machten dies möglich eine spezifische Implementierung von DROWN.

Zum Zeitpunkt der Veröffentlichung waren 25 % der Top-Websites im Internet von der DROWN-Schwachstelle betroffen, und der Angriff konnte mit bescheidenen Ressourcen durchgeführt werden, die selbst böswilligen Einzelhackern zur Verfügung standen. Das Abrufen des RSA-Schlüssels des Servers erforderte acht Stunden Rechenzeit und 440 US-Dollar, und SSLv2 wurde von veraltet zu radioaktiv.

Moment, was ist mit Heartbleed?

Dabei handelt es sich nicht um einen kryptografischen Angriff im oben beschriebenen Sinne; Dies ist ein Pufferüberlauf.

Lasst uns eine Pause machen

Wir begannen mit einigen grundlegenden Techniken: Brute Force, Interpolation, Downgrade, Cross-Protocol und Vorberechnung. Dann haben wir uns eine fortschrittliche Technik angesehen, vielleicht die Hauptkomponente moderner kryptografischer Angriffe: den Oracle-Angriff. Wir haben einige Zeit damit verbracht, es herauszufinden – und haben nicht nur das zugrunde liegende Prinzip verstanden, sondern auch die technischen Details zweier spezifischer Implementierungen: des Vaudenay-Angriffs auf den CBC-Verschlüsselungsmodus und des Kelsey-Angriffs auf Verschlüsselungsprotokolle vor der Komprimierung.

Bei der Überprüfung von Downgrade- und Precomputation-Angriffen haben wir kurz den FREAK-Angriff beschrieben, der beide Methoden nutzt, indem Ziel-Sites auf schwache Schlüssel heruntergestuft und dann dieselben Schlüssel wiederverwendet werden. Für den nächsten Artikel speichern wir den (sehr ähnlichen) Logjam-Angriff, der auf Public-Key-Algorithmen abzielt.

Anschließend haben wir uns drei weitere Beispiele für die Anwendung dieser Prinzipien angesehen. Zuerst CRIME und POODLE: zwei Angriffe, die auf der Fähigkeit des Angreifers beruhten, neben dem Ziel-Klartext beliebigen Klartext einzufügen, und dann die Antworten des Servers zu untersuchen und dannNutzen Sie mithilfe der Oracle-Angriffsmethode diese spärlichen Informationen aus, um den Klartext teilweise wiederherzustellen. CRIME ging den Weg von Kelseys Angriff auf die SSL-Komprimierung, während POODLE stattdessen eine Variante von Vaudenays Angriff auf CBC mit dem gleichen Effekt nutzte.

Anschließend richteten wir unsere Aufmerksamkeit auf den protokollübergreifenden DROWN-Angriff, der mithilfe des alten SSLv2-Protokolls eine Verbindung zum Server aufbaut und dann mithilfe des Bleichenbacher-Angriffs die geheimen Schlüssel des Servers wiederherstellt. Wir haben die technischen Details dieses Angriffs vorerst übersprungen; Wie Logjam muss es warten, bis wir ein gutes Verständnis der Public-Key-Kryptosysteme und ihrer Schwachstellen haben.

Im nächsten Artikel werden wir über fortgeschrittene Angriffe wie Meet-in-the-Middle, differenzielle Kryptoanalyse und Geburtstagsangriffe sprechen. Machen wir einen kurzen Streifzug durch Seitenkanalangriffe und kommen dann zum unterhaltsamen Teil: Public-Key-Kryptosysteme.

Source: habr.com