Beim Wort „Kryptografie“ denken einige an ihr WiFi-Passwort, das grüne Schloss neben der Adresse ihrer Lieblingsseite und daran, wie schwierig es ist, sich in die E-Mail eines anderen hineinzuhacken. Andere denken an die Reihe von Schwachstellen der letzten Jahre mit sprechenden Akronymen (DROWN, FREAK, POODLE…) und stilvollen Logos sowie der dringenden Aufforderung, den Browser sofort zu aktualisieren.

Kryptografie umfasst all dies, aber das Wesentliche liegt woanders. Es geht um die feine Grenze zwischen Einfachheit und Komplexität. Einige Dinge sind einfach zu machen, aber schwer zurückzuholen: zum Beispiel ein Ei zu zerbrechen. Andere Dinge sind leicht zu erreichen, aber schwierig zurückzuholen, wenn ein kleines, wichtiges entscheidendes Teil fehlt: zum Beispiel eine verschlossene Tür zu öffnen, wenn „das entscheidende Teil“ der Schlüssel ist. Kryptografie untersucht diese Situationen und die Möglichkeiten ihrer praktischen Anwendung.

In den letzten Jahren hat sich die Sammlung kryptografischer Angriffe in einen Zoo schreiender Logos verwandelt, gefüllt mit Formeln wissenschaftlicher Arbeiten und einer allgemeinen düsteren Wahrnehmung, dass alles kaputt ist. In Wirklichkeit basieren viele der Angriffe jedoch auf einigen gemeinsamen Prinzipien, und die endlosen Seiten von Formeln reduzieren sich oft auf leicht verständliche Ideen.

In dieser Artikelreihe werden wir verschiedene Arten kryptografischer Angriffe untersuchen, mit einem Schwerpunkt auf den grundlegenden Prinzipien. Im Großen und Ganzen und nicht ganz in dieser Reihenfolge werden wir Folgendes behandeln:

Grundstrategien: Brute Force, Frequenzanalyse, Interpolation, Downgrade und Cross-Protokolle.
„Marken“-Schwachstellen: FREAK, CRIME, POODLE, DROWN, Logjam.
Fortgeschrittene Strategien: Oracle-Angriffe (Wodyna-Angriff, Kelsey-Angriff); Meet-in-the-Middle-Methode, Geburtstag-Angriff, statistische Verzerrung (differenzielle Kryptoanalyse, integrale Kryptoanalyse usw.).
Seitenkanalangriffe und ihre nahe Verwandten, Methoden zur Fehleranalyse.
Angriffe auf die Kryptografie mit öffentlichem Schlüssel: kubische Wurzel, Broadcast, verknüpftes Nachricht, Copper-Smith-Angriff, Pollard–Hellman-Algorithmus, numerisches Sieb, Wiener-Angriff, Bleichenbacher-Angriff.

Dieser spezielle Artikel behandelt das oben erwähnte Material bis hin zum Kelsey-Angriff.

Grundstrategien

Die folgenden Angriffe sind einfach, da sie nahezu vollständig ohne technische Details erklärt werden können. Wir werden jede Art von Angriff in den einfachsten Begriffen erläutern, ohne uns in komplexen Beispielen oder erweiterten Nutzungsmöglichkeiten zu verlieren.

Einige dieser Angriffe sind größtenteils veraltet und wurden seit vielen Jahren nicht mehr eingesetzt. Andere, alte Bekannte, schleichen sich weiterhin regelmäßig an nichtsahnenden Entwicklern von Kryptosystemen im 21. Jahrhundert heran. Man kann sagen, dass das Zeitalter der modernen Kryptographie mit dem Aufkommen von IBM DES – dem ersten Verschlüsselungsverfahren, das allen Angriffen in dieser Liste standhielt – begann.

Einfacher Brute-Force-Angriff

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

Angenommen, wir sehen den Ciphertext und versuchen, ihn ohne weitere Informationen zu entschlüsseln (dies wird als "Ciphertext-only-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 plausible Nachricht ist.

Beachten Sie, dass hier zwei unausgesprochene Annahmen zugrunde liegen. Erstens, dass wir wissen, wie die Entschlüsselung durchgeführt wird, das heißt, wie das Kryptosystem funktioniert. Dies ist eine Standardannahme in der Diskussion über Kryptographie. Das Verstecken von Details zur Implementierung des Verschlüsselungsverfahrens vor Angreifern mag wie eine zusätzliche Sicherheitsmaßnahme erscheinen, aber sobald ein Angreifer diese Details herausfindet, geht diese zusätzliche Sicherheit unauffällig und unwiderruflich verloren. So ist das Kerckhoffs-Prinzip: Das Eindringen eines Systems in die Hände des Feindes sollte keine Unannehmlichkeiten verursachen.

Zweitens gehen wir davon aus, dass der richtige Schlüssel der einzige Schlüssel ist, der zu einer plausiblen Entschlüsselung führt. Dies ist auch eine vernünftige Annahme; sie gilt, wenn der Ciphertext wesentlich länger als der Schlüssel und gut lesbar ist. Im Allgemeinen ist das in der realen Welt der Fall, mit Ausnahme von enormen unpraktischen Schlüsseln oder und anderen Manipulationen, die besser außen vor bleiben. (wenn Sie es nicht mögen, dass wir auf die Erklärungen verzichtet haben, siehe Theorem 3.8 hier).

Unter Berücksichtigung des Vorstehenden ergibt sich eine Strategie: Jeden möglichen Schlüssel zu überprüfen. Dies wird Brute-Force genannt, und ein solcher Angriff funktioniert garantiert gegen alle praktischen Verschlüsselungen – letztendlich. Beispielsweise reicht Brute-Force aus, um die Cäsar-Verschlüsselung, eine alte Verschlüsselung, bei der der Schlüssel ein Buchstabe des Alphabets ist, was etwas mehr als 20 mögliche Schlüssel impliziert.

Leider für Kryptoanalytiker schützt eine Vergrößerung der Schlüssellänge gut gegen Brute-Force. Mit zunehmender Schlüssellänge steigt die Anzahl der möglichen Schlüssel exponentiell. Bei den modernen Schlüssellängen ist ein einfacher Brute-Force völlig unpraktisch. Um zu verstehen, was wir meinen, nehmen wir den schnellsten bekannten Supercomputer von Mitte 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 älter ist als das Universum.

Ist Brute-Force ein historisches Kuriosum? Keineswegs: Es ist ein notwendiger Bestandteil im Kryptoanalyserezeptbuch. Es gibt nur selten so schwache Verschlüsselungen, dass sie nur mit einer cleveren Attacke ohne Anwendung von Gewalt in irgendeiner Form entschlüsselt werden können. Viele erfolgreiche Hacks verwenden zuerst einen algorithmischen Ansatz, um die Zielverschlüsselung zu schwächen, und setzen dann Brute-Force ein.

Häufigkeitsanalyse

Die meisten Texte sind keine Kauderwelsch. Beispielsweise gibt es in englischsprachigen Texten viele Buchstaben 'e' und Artikel 'the'; in Binärdateien gibt es viele Nullbytes als Platzhalter zwischen Informationsfragmenten. Häufigkeitsanalyse ist jeder Angriff, der diese Tatsache nutzt.

Ein klassisches Beispiel für eine Verschlüsselung, die anfällig für diesen Angriff ist, ist eine einfache Substitutionsverschlüsselung. In dieser Verschlüsselung stellt der Schlüssel eine Tabelle dar, die alle Buchstaben ersetzt. Beispielsweise wird 'g' durch 'h' ersetzt, 'o' durch 'j'. Daher wird das Wort 'go' zu 'hj'. Diese Verschlüsselung ist schwer mit einfachem Brute-Force 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 mit der Aufgabe zurecht.

Betrachten wir den folgenden Chiffretext, der mit einer einfachen Substitution verschlüsselt wurde:

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

Da Y häufig vorkommt, insbesondere am Ende vieler Wörter, können wir vorläufig annehmen, dass es der Buchstabe 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 deutet die Kombination XDeLe eindeutig auf das Wort these oder there, daher machen wir weiter:

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

Nehmen wir weiter an, dass L entspricht r, A — a und so weiter. Wahrscheinlich müssen einige Versuche unternommen werden, aber im Vergleich zum vollständigen Brute-Force wirkt dieser Angriff in kürzester Zeit den ursprünglichen Text wiederherzustellen:

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

Für einige ist die Lösung solcher „Kryptogramme“ ein faszinierendes Hobby.

Die Idee der Frequenzanalyse ist fundamentaler, als es auf den ersten Blick scheint. Und sie ist auf viel komplexere Chiffren anwendbar. Im Laufe der Geschichte haben verschiedene Chiffrenkonstruktionen versucht, solchen Angriffen mit Hilfe von „polyalfabetischer Substitution“ entgegenzuwirken. Hier wird der Buchstabenaustausch im Verschlüsselungsprozess auf komplexe, aber vorhersehbare Weise verändert, die vom Schlüssel abhängen. All diese Chiffren galten zu ihrer Zeit als schwer zu knacken; und dennoch hat die bescheidene Frequenzanalyse sie letztendlich alle überwunden.

Die ambitionierteste polyalphabetische Chiffre in der Geschichte und wahrscheinlich die bekannteste war die „Enigma“ im Zweiten Weltkrieg. Sie war im Vergleich zu ihren Vorgängern relativ komplex, aber durch langwierige und hartnäckige Arbeit konnten britische Kryptanalytiker sie mit Hilfe der Frequenzanalyse knacken. Natürlich konnten sie keinen eleganten Angriff entwickeln wie oben gezeigt; sie mussten bekannte Paare von Klar- und Chiffretexten vergleichen (so genannte „Angriffe basierend auf Klartexten“) und sogar die Benutzer der „Enigma“ dazu bringen, bestimmte Nachrichten zu verschlüsseln, um das Ergebnis zu analysieren („Angriffe basierend auf ausgewähltem Klartext“). Aber das erleichterte das Schicksal der besiegten feindlichen Armeen und versenkten U-Boote nicht.

Nach diesem Triumph verschwand die Frequenzanalyse aus der Geschichte der Kryptoanalyse. Die Verschlüsselungen der modernen digitalen Ära sind für die Arbeit mit Bits und nicht mit Buchstaben konzipiert. Was noch wichtiger ist, diese Verschlüsselungen wurden mit dem düsteren Verständnis entwickelt, was später als Schneier-Gesetz: Jeder kann einen Verschlüsselungsalgorithmus erstellen, den er selbst nicht knacken kann. Es reicht nicht aus, dass das Verschlüsselungssystem komplex wirkt: Um seinen Wert zu beweisen, muss es eine gnadenlose Sicherheitsüberprüfung durch viele Kryptoanalytiker überstehen, die alles tun werden, um den Code zu knacken. Vorabberechnungen

Nehmen wir die hypothetische Stadt Prekom Heights mit einer Bevölkerung von 200.000 Menschen. In jedem Haus der Stadt befinden sich wertvolle Gegenstände im Durchschnitt im Wert von 30.000 $, jedoch nicht mehr als 50.000 $. Der Sicherheitsmarkt in Prekom wurde von der Firma ACME Industries monopolisiert, die die legendären Coyote ™ Türschlösser herstellt. Laut Expertenanalyse kann nur eine sehr komplexe hypothetische Maschine das Coyote Schloss knacken, deren Erstellung etwa fünf Jahre dauert und 50.000 $ kostet. Ist die Stadt sicher?

Wahrscheinlich nicht. Schließlich wird ein ausreichender ehrgeiziger Verbrecher auftauchen. Er wird folgendermaßen argumentieren: „Ja, ich werde hohe Vorlaufkosten haben. Fünf Jahre geduldigen Wartens und 50.000 $. Aber nach Abschluss der Arbeit habe ich Zugang zu

dem gesamten Reichtum dieser Stadt . Wenn ich meine Karten richtig spiele, wird sich diese Investition vielfach auszahlen.“Ähnlich ist es auch in der Kryptographie. Angriffe auf einen bestimmten Code werden einer gnadenlosen Kosten-Nutzen-Analyse unterzogen. Wenn das Verhältnis günstig ist, findet der Angriff nicht statt. Aber Angriffe, die sofort gegen viele potenzielle Opfer gerichtet sind, rentieren sich fast immer, und in diesem Fall besteht die beste Entwurfspraktik darin, anzunehmen, dass sie vom ersten Tag an begonnen haben. Wir haben im Grunde eine kryptografische Version von Murphys Gesetz: „Alles, was das System wirklich knacken kann, wird das System knacken.“

Ein einfaches Beispiel für ein Kryptosystem, das anfällig für Angriffe mit Vorabberechnungen ist, ist eine Verschlüsselung mit konstantem Algorithmus ohne Verwendung eines Schlüssels. So war es auch im Fall des

Caesar-Codes. Caesar-Verschlüsselung, der einfach jeden Buchstaben des Alphabets um drei Buchstaben nach vorne schiebt (die Tabelle ist zyklisch, daher wird der letzte Buchstabe im Alphabet durch den dritten verschlüsselt). Hier zeigt sich wieder das Prinzip von Kerckhoffs: Sobald das System geknackt ist, bleibt es für immer geknackt.

Das Konzept ist einfach. Selbst ein angehender Entwickler von Kryptosystemen wird wahrscheinlich die Bedrohungen erkennen und sich entsprechend vorbereiten. Betrachtet man die Evolution der Kryptographie, sind solche Angriffe für die meisten Verschlüsselungen von den ersten verbesserten Versionen der Cäsar-Verschlüsselung bis zum Niedergang der polyalphabetischen Verschlüsselungen nicht relevant gewesen. Solche Angriffe traten erst mit dem Beginn der modernen Ära der Kryptographie wieder auf.

Diese Rückkehr wird durch zwei Faktoren verursacht. Erstens sind endlich ausreichend komplexe Kryptosysteme entstanden, bei denen die Möglichkeit der Ausnutzung nach einem Bruch nicht offensichtlich war. Zweitens hat die Kryptographie eine so breite Verbreitung erfahren, dass Millionen von Nicht-Profis täglich Entscheidungen trafen, wo und welche Teile der Kryptographie sie wiederverwenden. Es dauerte einige Zeit, bis die Experten die auftauchenden Risiken erkannten und Alarm schlugen.

Merken Sie sich den Angriff mit Vorabrechnungen: Am Ende des Artikels werden wir zwei kryptographische Beispiele aus der Praxis betrachten, bei denen dieser eine wichtige Rolle spielte.

Interpolation

Vor Ihnen steht der berühmte Detektiv Sherlock Holmes, der einen Interpolationsangriff auf den ahnungslosen Dr. Watson ausführt:

Ich habe sofort erraten, dass Sie aus Afghanistan gekommen sind… Mein Gedankengang war folgender: „Diese Person ist vom Typ her ein Arzt, aber seine Haltung ist militärisch. Also ein Militärarzt. Er ist gerade aus den Tropen zurückgekehrt – sein Gesicht ist bronzefarben, aber das ist kein natürlicher Hautton, da seine Handgelenke viel heller sind. Sein Gesicht ist abgemagert – er hat offensichtlich viel durchgemacht und eine Krankheit erlitten. Er wurde am linken Arm verletzt – er hält ihn unbeweglich und ein wenig unnatürlich. Wo könnte ein britischer Militärarzt in den Tropen gelitten und eine Wunde erlitten haben? Natürlich in Afghanistan.“ Der gesamte Gedankengang dauerte nicht einmal eine Sekunde. Und so sagte ich, dass Sie aus Afghanistan gekommen seien, und Sie waren erstaunt.

Aus jedem einzelnen Beweis konnte Holmes nur sehr wenig Informationen extrahieren. Er konnte zu seinem Schluss nur gelangen, wenn er sie alle zusammen betrachtete. So funktioniert auch ein Interpolationsangriff, der bekannte Paare von Klar- und Geheimtext untersucht, die durch die Anwendung desselben Schlüssels entstanden sind. Aus jedem Paar werden einzelne Beobachtungen extrahiert, die eine allgemeine Schlussfolgerung über den Schlüssel ermöglichen. Alle diese Überlegungen sind vage und scheinen nutzlos, bis sie plötzlich eine kritische Masse erreichen und zu einer einzigen möglichen Schlussfolgerung führen: egal wie unglaublich sie ist, sie muss wahr sein. Danach wird entweder der Schlüssel offenbart oder der Entschlüsselungsprozess wird so gut eingespielt, dass er reproduziert werden kann.

Lassen Sie uns an einem einfachen Beispiel veranschaulichen, wie Interpolation funktioniert. Angenommen, wir möchten das persönliche Tagebuch unseres Feindes Bob lesen. Er verschlüsselt jede Zahl in seinem Tagebuch mit Hilfe eines einfachen kryptografischen Systems, von dem er aus einer Anzeige in der Zeitschrift „Spott über Kryptografie“ erfahren hat. Das System funktioniert folgendermaßen: Bob wählt zwei Zahlen, die ihm gefallen: und . Von diesem Moment an, um eine beliebige Zahl zu verschlüsseln, berechnet er . Zum Beispiel, wenn Bob und gewählt hat, dann wird die Ziffer verschlüsselt als .

Angenommen, am 28. Dezember haben wir gesehen, dass Bob etwas in seinem Tagebuch kritzelt. Wenn er fertig ist, nehmen wir es unbemerkt und sehen uns den letzten Eintrag an:

Datum: 235/520
Liebes Tagebuch,
Heute war ein guter Tag. In 64 Tagen habe ich ein Date mit Alice, die in der Wohnung 843lebt. Ich denke wirklich, dass sie sein könnte 26!

Da wir sehr ernsthaft vorhaben, Bob an seinem Date zu beobachten (in diesem Szenario sind wir 15 Jahre alt), ist es entscheidend, das Datum sowie die Adresse von Alice zu erfahren. Zum Glück merken wir, dass Bobs kryptografisches System anfällig für einen Interpolationsangriff ist. Wir wissen vielleicht nicht und , aber wir kennen das heutige Datum, also haben wir zwei Paare von "Klartext - Geheimtext". Nämlich wissen wir, dass in , und — bei verschlüsselt wird. Das notieren wir:

Da wir 15 Jahre alt sind, wissen wir bereits von dem System mit zwei Gleichungen und zwei Unbekannten, was in dieser Situation ausreicht, um es zu finden. und ohne besondere Probleme. Jedes Paar „klarer Text - Chiffretext“ stellt eine Einschränkung für Bobs Schlüssel dar, und zwei Einschränkungen zusammen sind ausreichend, um den Schlüssel vollständig wiederherzustellen. In unserem Beispiel lautet die Antwort und (bei , also dass 26 im Tagebuch dem Wort ‘the one’ entspricht, also „die eine“ – Anm. d. Übers.

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

Anfänger beschweren sich oft, dass Kryptographie „die Kunst ist, Dinge so hässlich wie möglich zu gestalten“. Wahrscheinlich sind die Interpolationsangriffe zum Teil dafür verantwortlich. Bob kann entweder ein elegantes mathematisches Design verwenden oder die Vertraulichkeit seines Treffens mit Alice wahren – aber leider kann man normalerweise nicht beides erreichen. Das wird besonders klar, wenn wir schließlich zum Thema der asymmetrischen Kryptographie übergehen.

Kreuzprotokoll / Downgrade

Im Film „Illusion des Betrugs“ (2013) versucht eine Gruppe von Illusionisten, das gesamte Vermögen des korrupten Versicherungsmagnaten Arthur Tressler zu erschleichen. Um Zugang zu Arthurs Bankkonto zu erhalten, müssen die Illusionisten entweder seinen Benutzernamen und sein Passwort angeben oder ihn dazu bringen, persönlich zur Bank zu erscheinen und an dem Plan teilzunehmen.

Beide Optionen sind sehr schwierig; die Jungs sind es gewohnt, auf der Bühne zu performen, nicht an Geheimdienstoperationen teilzunehmen. Daher wählen sie die dritte Möglichkeit: ihr Komplize ruft bei der Bank an und gibt sich als Arthur aus. Die Bank stellt ein paar Fragen zur Identitätsprüfung, wie den Namen des Onkels und den Namen des ersten Haustiers; unsere Helden holen sich diese Informationen von Arthur leicht durch geschickte soziale Manipulation.Von diesem Moment an spielt die hervorragende Passwortsicherheit keine Rolle mehr.

(Laut einer städtischen Legende, die wir persönlich überprüft und bestätigt haben, traf der Kryptograph Eli Biham einmal auf einen Bankangestellten, der auf der Einrichtung einer Sicherheitsfrage bestand. Als der Kassierer nach dem Geburtsnamen der Großmutter fragte, begann Biham zu diktieren: „Großes X, kleines y, drei…“.)

Ebenso ist es in der Kryptografie, wenn zwei kryptografische Protokolle parallel zum Schutz desselben Assets verwendet werden, wobei eines viel schwächer ist als das andere. Das Gesamtsystem wird anfällig für einen Cross-Protokoll-Angriff, bei dem das schwächere Protokoll angegriffen wird, um an die Belohnung zu gelangen, ohne das stärkere zu berühren.

In einigen komplexen Fällen reicht es nicht aus, sich einfach mit dem Server über ein schwächeres Protokoll zu verbinden, sondern es ist das ungewollte Mitwirken eines legitimen Kunden erforderlich. Dies kann durch einen sogenannten Downgrade-Angriff organisiert werden. Um diesen Angriff zu verstehen, nehmen wir an, dass unsere Illusionisten eine komplexere Aufgabe haben als im Film. Angenommen, der Bankangestellte (Kassierer) und Arthur sind mit unvorhergesehenen Umständen konfrontiert, was zu folgendem Dialog führt:

Hacker: Hallo? Hier ist Arthur Tressler. Ich würde gerne mein Passwort zurücksetzen.
Kassierer: Perfekt. Bitte schauen Sie in Ihr persönliches Buch mit Geheimcodes, 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 wie normale Menschen reden?
Kassierer: Ich rate Ihnen davon ab, das zu tun.
Hacker: Ich möchte nur… hör zu, ich hatte einen schlechten Tag, okay? Ich bin VIP-Kunde und nicht in der Stimmung, in diesen dummen Codebüchern herumzukramen.
Kassierer: Gut. Wenn Sie darauf bestehen, Herr Tressler. 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: Verstanden. Bitte geben Sie Ihren PIN-Code für große Transaktionen an.
Hacker: Was? Meinen?
Kassierer: Auf Ihre persönliche Anfrage hin erfordern Transaktionen in dieser Größenordnung die Eingabe eines PIN-Codes für große Transaktionen. Dieser Code wurde Ihnen bei der Kontoeröffnung ausgestellt.
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, dies ist eine Sicherheitsmaßnahme, die Sie angefordert haben. Wenn Sie möchten, können wir Ihnen einen neuen PIN-Code an Ihre Postadresse senden.

Unsere Helden verschieben die Operation. Sie hören mehrere große Transaktionen von Tressler ab, in der Hoffnung, den PIN-Code zu hören; aber jedes Mal wird das Gespräch in unverständliches Kauderwelsch verwandelt, bevor dort etwas Interessantes erklingt. Schließlich setzen sie an einem schönen Tag ihren Plan in die Tat um. Sie warten geduldig auf den Moment, wenn Tressler eine große Transaktion am Telefon durchführen soll, er schaltet sich in die Leitung ein und dann…

Tressler: Guten Tag. Ich möchte bitte eine Remote-Transaktion durchführen.
Kassierer: Ausgezeichnet. Bitte schauen Sie in Ihr persönliches geheimes Codesbuch, Seite…
(Der Hacker drückt eine Taste; die Stimme des Kassierers verwandelt sich in unverständliches Rauschen).
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: Das Wort Nummer zwanzig @$#@$#%#$.
Tressler: Im Ernst! Jetzt reicht's! Mit Ihrem Sicherheitsprotokoll – das ist ein Zirkus. Ich weiß, dass Sie einfach normal mit mir sprechen können.
Kassierer: Ich rate davon ab…
Tressler: Und ich rate Ihnen, meine Zeit nicht zu verschwenden. Ich möchte nichts mehr darüber hören, bis Sie Ihre Probleme mit der Telefonleitung behoben haben. Können wir diesen Deal abschließen oder nicht?
Kassierer:… ja. Gut. Was wünschen Sie?
Tressler: Ich möchte $20.000 an die Firma Lord Business Investments überweisen, Kontonummer…
Kassierer: Einen Moment bitte. Das ist ein großes Geschäft. Bitte geben Sie Ihren PIN-Code für große Transaktionen an.
Tressler: Was? Ah, genau. 1234.

Hier ist der Angriff auf die Senkung. Ein schwächeres Protokoll „einfach direkt sprechen“ wurde angedacht als Option Notfalllösung. Und doch sind wir hier.

Man könnte fragen, wer bei klarem Verstand ein echtes System der Art „sicher, bis jemand danach fragt“ entwerfen würde, wie oben beschrieben. Aber so wie eine fiktive Bank das Risiko eingeht, um Kunden zu halten, die Kryptographie nicht mögen, neigen auch Systeme insgesamt oft dazu, Anforderungen nachzugeben, die gegenüber Sicherheit gleichgültig oder sogar offen feindlich sind.

Genau so geschah es mit dem SSLv2-Protokoll im Jahr 1995. Die US-Regierung hatte bereits früh begonnen, Kryptographie als Waffe zu betrachten, die besser von externen und internen Feinden ferngehalten werden sollte. Codefragmente wurden einzeln zur Ausfuhr aus den USA genehmigt, oft unter der Bedingung, den Algorithmus absichtlich zu schwächen. Dem Unternehmen Netscape, dem Entwickler des damals beliebtesten Browsers Netscape Navigator, wurde die Genehmigung für SSLv2 nur mit einem anfänglich anfälligen RSA 512-Bit-Schlüssel (und 40 Bit für RC4) erteilt.

Bis zum Ende des Jahrtausends wurden die Regeln gelockert, und der Zugang zu moderner Verschlüsselung wurde weit verbreitet. Dennoch unterstützten Clients und Server über viele Jahre hinweg geschwächte "Export"-Kryptographie aufgrund der gleichen Trägheit, die jede veraltete Systemunterstützung aufrecht erhält. Die Clients glaubten, dass sie auf einen Server stoßen könnten, der nichts anderes unterstützte. Die Server machten das Gleiche. Natürlich diktiert das SSL-Protokoll, dass Clients und Server niemals ein schwaches Protokoll verwenden sollten, wenn ein besseres verfügbar ist. Aber dieselbe Annahme galt für Tressler und seine Bank.

Diese Theorie fand Anwendung in zwei aufsehenerregenden 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 Einzelheiten des FREAK-Angriffs veröffentlicht, und drei Monate später folgte ein weiterer ähnlicher Angriff mit dem Namen Logjam, den wir näher besprechen werden, wenn wir uns mit Angriffen auf die asymmetrische Kryptographie befassen.

Schwachstelle FREAK (auch bekannt als „Smack TLS“) trat auf, als Forscher die TLS-Client/Server-Implementierungen analysierten und einen interessanten Fehler entdeckten. In diesen Implementierungen, wenn der Client nicht einmal um schwache Exportkryptographie bittet, aber der Server trotzdem mit solchen Schlüsseln antwortet – sagt der Client „Na gut“ und wechselt zu einem schwachen Satz von Verschlüsselungen.

Zu jener Zeit galten exportierte Kryptographien als veraltet und verboten, weshalb der Angriff ein echter Schock war und viele wichtige Domänen betraf, einschließlich der Webseiten des Weißen Hauses, des US-Finanzministeriums und der NSA. Schlimmer noch, viele verwundbare Server optimierten ihre Leistung, indem sie dieselben Schlüssel wiederverwendeten, anstatt für jede Sitzung neue zu generieren. Dies ermöglichte es nach der Senkung des Protokolls auch, einen Vorberechnungangriff durchzuführen: Der Bruch eines Schlüssels blieb relativ teuer (100 $ und 12 Stunden zum Zeitpunkt der Veröffentlichung), aber die praktische Kosten für einen Verbindungsangriff sanken erheblich. Es genügt, einmal den Server-Schlüssel zu knacken – und die Geheimnisse aller nachfolgenden Verbindungen ab diesem Zeitpunkt zu brechen.

Und bevor wir fortfahren, sollten wir einen fortgeschrittenen Angriff erwähnen…

Oracle-Angriff

Moxie Marlinspike ist am bekanntesten als der Vater des plattformübergreifenden Kryptomessengers Signal; aber persönlich gefällt uns eine seiner weniger bekannten Neuerungen – das Prinzip der kryptografischen Verdammnis (Cryptographic Doom Principle). Leicht umformuliert könnte man sagen: „Wenn ein Protokoll irgendeine kryptografische Operation über eine Nachricht aus einer potenziell bösartigen Quelle ausführt und sich abhängig vom Ergebnis unterschiedlich verhält, ist es verdammt.“ Oder in schärferer Form: „Nimm keine Informationen zur Verarbeitung von deinem Feind an, und wenn du es musst, dann zeige wenigstens nicht das Ergebnis.“

Lassen wir Bufferüberläufe, Befehlsspritze und Ähnliches beiseite; diese fallen außerhalb dieses Diskurses. Ein Verstoß gegen das „Prinzip der Verdammnis“ führt zu ernsten Sicherheitsbrüchen in der Kryptographie, da sich das Protokoll genau so verhält, wie es soll.

Nehmen wir beispielsweise eine fiktive Konstruktion mit einem verwundbaren Substitutionscipher und zeigen dann einen möglichen Angriff. Obwohl wir bereits einen Angriff auf ein Substitutionscipher durch Frequenzanalyse gesehen haben, ist dies nicht einfach „eine andere Methode, um dasselbe Cipher zu knacken“. Im Gegenteil, Oracle-Angriffe sind eine viel modernere Erfindung, die in vielen Situationen anwendbar ist, in denen Frequenzanalyse scheitert, und wir werden eine Demonstration davon im nächsten Abschnitt sehen. Hier wurde ein einfaches Cipher nur gewählt, um das Beispiel verständlicher zu machen.

Alice und Bob kommunizieren mit einem einfachen Substitutionscipher und verwenden dabei einen Schlüssel, der nur ihnen bekannt ist. Sie legen großen Wert auf die Länge der Nachrichten: Ihre Länge beträgt genau 20 Zeichen. Daher haben sie vereinbart, dass, wenn jemand eine kürzere Nachricht senden möchte, er irgendwelchen Dummy-Text am Ende der Nachricht hinzufügen muss, damit sie genau 20 Zeichen lang ist. Nach einigem Diskurs haben sie beschlossen, nur folgende Dummy-Texte zu akzeptieren: a, bb, ccc, dddd usw. Auf diese Weise ist der Dummy-Text beliebiger notwendiger Länge bekannt.

Wenn Alice oder Bob eine Nachricht erhält, überprüfen sie zuerst, ob die Nachricht die richtige Länge hat (20 Zeichen) und ob der Suffix der richtige Dummy-Text ist. Wenn dies nicht der Fall ist, antworten sie mit einer entsprechenden Fehlermeldung. Wenn die Textlänge und der Dummy-Text in Ordnung sind, liest der Empfänger die eigentliche Nachricht und sendet eine verschlüsselte Antwort.

Im Verlauf 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 sinnvolle Nachricht fälschen. Aber da das Protokoll das Prinzip der Verdammnis bricht, 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 Dummy-Text.
Hacker: PREWF ZHJKL MMMN. LB
Alice: Falscher Dummy-Text.
Hacker: PREWF ZHJKL MMMN. LC
Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Der Hacker hat keine Ahnung, was Alice gerade gesagt hat, bemerkt aber, dass das Zeichen C übereinstimmen muss a, da Alice den Dummy-Text akzeptiert hat.

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

Wieder hat der Hacker keine Ahnung, was Alice gerade gesagt hat, bemerkt jedoch, dass H mit b übereinstimmen muss, da Alice den Dummy-Text akzeptiert hat.

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

Auf den ersten Blick erinnert die Methode an einen Angriff basierend auf ausgewähltem Klartext. Schließlich wählt der Angreifer Chiffratext und der Server verarbeitet diese brav. 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 genügt, selbst eine so harmlose wie "Falscher Platzhaltertext".

Obwohl dieser spezielle Angriff lehrreich ist, sollte man sich nicht zu sehr auf die spezifischen Details des "Platzhaltertext"-Schemas, des verwendeten kryptografischen Systems oder der genauen Sequenz von Nachrichten, die der Angreifer sendet, fixieren. Die Hauptidee besteht darin, wie Alice unterschiedlich reagiert, basierend auf den Eigenschaften des Klartexts, und dies tut, ohne zu überprüfen, ob der entsprechende Chiffratext tatsächlich von einer vertrauenswürdigen Partei stammt. So erlaubt Alice dem Angreifer, geheime Informationen aus ihren Antworten herauszuziehen.

In diesem Szenario kann viel verändert werden. Die Symbole, auf die Alice reagiert, oder die Veränderung ihres Verhaltens selbst, oder sogar das verwendete kryptografische System. Aber das Prinzip bleibt dasselbe, und der Angriff bleibt im Großen und Ganzen in der einen oder anderen Form möglich. Die grundlegende Umsetzung dieses Angriffs hat dazu beigetragen, mehrere Sicherheitsfehler aufzudecken, die wir bald besprechen werden; vorher sollten jedoch einige theoretische Lektionen gelernt werden. Wie kann dieses fiktive "Alice-Szenario" in einem Angriff verwendet werden, der in der Lage ist, mit einer realen modernen Verschlüsselung zu funktionieren? Ist das überhaupt möglich, auch nur theoretisch?

Im Jahr 1998 antwortete der Schweizer Kryptograf Daniel Bleichenbacher bejahend auf diese Frage. Er demonstrierte einen Oracle-Angriff auf ein weit verbreitetes öffentliches Schlüsselsystem RSA, wobei ein bestimmtes Nachrichtenschema verwendet wurde. In einigen RSA-Implementierungen antwortet der Server mit unterschiedlichen Fehlermeldungen, je nachdem, ob der Klartext dem Schema entspricht oder nicht; das genügte, um den Angriff durchzuführen.

Vier Jahre später, im Jahr 2002, demonstrierte der französische Kryptograf Serge Vaudenay einen Oracle-Angriff, der nahezu identisch mit dem oben beschriebenen Szenario von Alice war – nur, dass er anstelle eines fiktiven Verschlüsselungsschemas eine ganze respektable Klasse moderner Verschlüsselungsverfahren knackte, die tatsächlich von Menschen verwendet werden. Insbesondere zielte Vaudenays Angriff auf Verschlüsselungsverfahren mit fester Eingabelänge („Blockverschlüsselungen“), wenn sie im sogenannten „CBC-Verschlüsselungsmodus“ verwendet werden und mit einem bestimmten populären Padding-Schema, das 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. Am bemerkenswertesten war ein Angriff, der das häufige Auslesen der ursprünglichen Länge des Klartexts aus der Länge des verschlüsselten Texts ausnutzte. Theoretisch ermöglicht dies einen Oracle-Angriff, der Teile des ursprünglichen Klartexts wiederherstellt.

Im Folgenden geben wir eine detailliertere Beschreibung der Angriffe von Vaudenay und Kelsey (wir werden eine detailliertere Beschreibung des Angriffs von Bleichenbacher geben, wenn wir zu den Angriffen auf die asymmetrische Kryptografie übergehen). Trotz aller unserer Bemühungen wird der Text etwas technisch; daher, wenn das oben Gesagte für Sie ausreichend ist, überspringen Sie die nächsten beiden Abschnitte.

Angriff von Vaudenay

Um den Angriff von Vaudenay zu verstehen, müssen wir zunächst etwas genauer über Blockverschlüsselungen und Verschlüsselungsmodi sprechen. Eine „Blockverschlüsselung“ ist, wie bereits erwähnt, ein Verfahren, das einen Schlüssel und eine bestimmte Eingabe fester Länge („Blocklänge“) annimmt und einen verschlüsselten Block derselben Länge ausgibt. Blockverschlüsselungen werden weit verbreitet verwendet und gelten als relativ sicher. Der mittlerweile pensionierte DES, der als erste moderne Verschlüsselung gilt, war eine Blockverschlüsselung. Wie bereits erwähnt, gilt das Gleiche auch für den heute weitverbreiteten AES.

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

Die Waterné-Attacke zielt auf den beliebten Betriebsmodus CBC (Cipher Block Chaining, Kettenmodus für Blockverschlüsselung) ab. Der Angriff betrachtet den zugrunde liegenden Blockchiffre als eine magische, unüberwindbare Black Box und umgeht seine Sicherheit völlig.

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

Das umrandete Plus steht für die XOR-Operation (exklusives 'ODER'). Zum Beispiel wird der zweite Block des Chiffretextes erhalten durch:

Die Ausführung der XOR-Operation auf dem zweiten Block des Klartextes mit dem ersten Block des Chiffretextes.
Die Verschlüsselung des erhaltenen Blocks mit Hilfe des Blockchiffres, unter Verwendung des Schlüssels.

Da CBC die binäre XOR-Operation so intensiv nutzt, lasst uns den Moment nutzen, um uns an einige ihrer Eigenschaften zu erinnern:

Idempotenz:
Kommutativität:
Assoziativität:
Selbstinversität:
Byte-by-Byte: Byte n von = (Byte n von ) (Byte n von )

In der Regel implizieren diese Eigenschaften, dass, wenn wir eine Gleichung haben, die XOR-Operationen und ein unbekanntes Element enthält, sie gelöst werden kann. Zum Beispiel, wenn wir wissen, dass mit unbekanntem und bekanntem und , dann können wir uns auf die oben genannten Eigenschaften verlassen, um die Gleichung für zu lösen. Indem wir von beiden Seiten der Gleichung XOR mit anwenden, erhalten wir . In einem Augenblick wird das alles sehr relevant werden.

Zwischen unserem Alice-Szenario und dem Waterné-Angriff gibt es zwei geringfügige Unterschiede und eine Hauptabweichung. Zwei geringfügige Unterschiede:

Im Alice-Szenario erwartete Alice, dass die Klartexte mit den Zeichen a, bb, ccc usw. enden. Im Waterné-Angriff hingegen erwartet das Opfer, dass die Klartexte stattdessen N Mal mit dem 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 akzeptiert hat, anhand der Antwort „Falscher Platzhaltertext“. Bei dem Waterner-Angriff ist eine größere Analyse erforderlich, und die genaue Umsetzung auf der Seite des Opfers ist wichtig; aber zur Vereinfachung nehmen wir an, dass diese Analyse immer noch 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 den Waterner-Angriff zu verstehen, daher lassen Sie uns einen Moment darüber nachdenken, warum und wie man überhaupt einen Orakelangriff auf CBC organisieren kann.

Angenommen, wir haben den CBC-Chiffretext mit 247 Blöcken und möchten ihn entschlüsseln. Wir können an den Server gefälschte Nachrichten senden, wie wir früher gefälschte Nachrichten an Alice senden konnten. Der Server wird die Nachrichten für uns entschlüsseln, zeigt jedoch die Entschlüsselung nicht an - stattdessen wird der Server, wie im Fall von Alice, nur einen Bit Informationen mitteilen: ob der Klartext eine gültige Auffüllung hat oder nicht.

Beachten Sie, dass wir im Szenario von Alice die folgenden Beziehungen hatten:

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

Nennen wir das „Alices Gleichung“. Wir kontrollierten den Chiffretext; der Server (Alice) gab uns vage Informationen über den empfangenen Klartext; und das ermöglichte es uns, Informationen über den letzten Faktor - den Schlüssel - abzuleiten. Analog, wenn wir eine solche Verbindung für das CBC-Szenario finden können, könnten wir dort einige geheime Informationen extrahieren.

Glücklicherweise gibt es tatsächlich Beziehungen, die wir nutzen können. Betrachten wir die Ausgaben des endgültigen Aufrufs zur Entschlüsselung eines Blockchiffers und bezeichnen wir diese Daten als . Bezeichnen wir auch die Blöcke des Klartexts und die Blöcke des Chiffretexts . Schauen Sie sich noch einmal das Diagramm des CBC an und beachten Sie, was dabei herauskommt:

Nennen wir das „CBC-Gleichung“.

Im Alice-Szenario, bei dem wir den Chiffretext kontrollieren und die Informationslecks zum entsprechenden Klartext beobachten, konnten wir einen Angriff organisieren, der das dritte Glied der Gleichung – den Schlüssel – wiederherstellte. Im CBC-Szenario kontrollieren wir ebenfalls den Chiffretext und beobachten Informationslecks zum entsprechenden Klartext. Wenn die Analogie zutrifft, können wir Informationen über .

Angenommen, wir haben wirklich wiederhergestellt , was dann? Nun, dann können wir sofort den gesamten letzten Block des Klartexts (), einfach durch Eingabe von (den wir haben) und
erhaltenen in die CBC-Gleichung.

Damit sind wir optimistisch hinsichtlich des allgemeinen Angriffsplans, und es ist an der Zeit, die Details auszuarbeiten. Beachten Sie, auf welche Weise der Server Informationen über den Klartext leckt. Im Alice-Szenario trat das Leck auf, weil Alice nur dann mit der richtigen Nachricht antwortete, wenn $inline$text{SIMPLE_SUBSTITUTION}(text{chiffretext},text{key})$inline$ mit dem String a (oder bb, und so weiter, endete, wobei die Chancen auf ein zufälliges Auslösen dieser Bedingungen sehr gering waren). Ähnlich im CBC akzeptiert der Server die Auffüllung, wenn und nur wenn mit einer hexadezimalen 01endet. Also versuchen wir denselben Trick: das Versenden von gefälschten Chiffretexten mit unseren eigenen gefälschten Werten , bis der Server die Auffüllung akzeptiert.

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

Jetzt nutzen wir die Byteweiseigenschaft von XOR:

Wir kennen das erste und das dritte Glied. Und wir haben bereits gesehen, dass dies es ermöglicht, das verbleibende Glied – das letzte Byte aus :

zu rekonstruieren. Das gibt uns auch das letzte Byte des endgültigen Blocks des Klartexts über die CBC-Gleichung und die byteweise Eigenschaft.

Wir könnten hier enden und uns damit zufriedengeben, dass wir einen Angriff auf einen theoretisch sicheren Verschlüsselungsalgorithmus durchgeführt haben. Aber tatsächlich können wir noch viel mehr tun: Wir können den gesamten Text tatsächlich wiederherstellen. Das erfordert einen bestimmten Trick, der im ursprünglichen Alice-Szenario nicht enthalten war und nicht zu den zwingenden Bedingungen des Orakelangriffs gehört, aber die Methode ist trotzdem interessant zu untersuchen.

Um ihn zu verstehen, beachten Sie zunächst, dass durch die Ableitung des richtigen Wertes des letzten Bytes Wir haben eine neue Fähigkeit entwickelt. Jetzt können wir bei der Manipulation von Chiffrentexten das letzte Byte des entsprechenden Klartexts steuern. Dies hängt wieder mit der CBC-Gleichung und dem Byte-für-Byte-Eigenschaft zusammen:

Da wir jetzt das zweite Glied kennen, können wir unsere Kontrolle über das erste nutzen, um das dritte zu steuern. Wir berechnen einfach:

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

Wie hilft uns das? Angenommen, wir erstellen jetzt alle Chiffrentexte so, dass das entsprechende Klartext letzte Byte gleich 02ist. Der Server akzeptiert die Auffü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 02 ist. Wir senden weiterhin gefälschte Chiffrentextblöcke und ändern das vorletzte Byte, bis der Server für einen von ihnen die Auffüllung akzeptiert. In diesem Moment erhalten wir:

Und wir stellen das vorletzte Byte wieder her genau so, wie wir das letzte wiederhergestellt haben. Wir machen im selben Stil weiter: Wir korrigieren die letzten zwei Bytes des Klartexts auf 03 03, wiederholen diesen Angriff für das drittletzte Byte und so weiter, bis wir schließlich vollständig wiederhergestellt haben .

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. In diesem Moment ist das Spiel vorbei – wir können jeden Chiffrentext entschlüsseln (schauen Sie sich noch einmal das Diagramm zur Entschlüsselung von CBC an, um sicherzustellen, dass dies der Fall ist; und beachten Sie, dass der IV-Vector öffentlich zugänglich ist).

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

Der Kelsey-Angriff

Der mit uns verwandte John Kelsey legte die Prinzipien dar, die vielen möglichen Angriffen zugrunde liegen, und nicht nur die Einzelheiten eines bestimmten Angriffs auf eine bestimmte Chiffre. Sein Artikel von 2002 ist eine Untersuchung möglicher Angriffe auf verschlüsselte komprimierte Daten. Sie dachten, dass für einen Angriff nicht nur die Tatsache ausreicht, dass die Daten vor der Verschlüsselung komprimiert wurden? Es stellt sich heraus, dass es 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; bei vielen Chiffren ist das genaue Verhältnis gleich. Zweitens, wenn eine Komprimierung durchgeführt wird, besteht ebenfalls eine starke Korrelation zwischen der Länge der komprimierten Nachricht und dem Grad der „Geräuschhaftigkeit“ des Klartexts, d.h. dem Anteil einzigartiger Symbole (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 Klartexten konnte nur Klartext 1 auf die spärliche Länge des zweiten Chiffretexts komprimiert werden. Wir haben dies herausgefunden, ohne etwas über den Komprimierungsalgorithmus, den Verschlüsselungsschlüssel oder sogar über die Chiffre selbst zu wissen. Im Vergleich zur Hierarchie möglicher kryptografischer Angriffe ist das eine Art Wahnsinn.

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

Wieder haben wir das Verhältnis:

Wieder kontrollieren wir ein Mitglied (), sehen eine kleine Informationsleckage über ein anderes Mitglied (Chiffretext) und versuchen, das letzte (Klartext) wiederherzustellen. Trotz der Analogie handelt es sich um eine etwas ungewöhnliche Situation im Vergleich zu anderen Orakelangriffen, die wir gesehen haben.

Um zu veranschaulichen, wie ein solcher Angriff funktionieren kann, verwenden wir ein fiktives Komprimierungsschema, das wir gerade erfunden haben: TOYZIP. Es sucht nach Textzeilen, die bereits zuvor im Text aufgetaucht sind, und ersetzt sie durch drei Füllbytes, die angeben, wo eine frühere Instanz der Zeile zu finden ist und wie oft sie dort vorkommt. Zum Beispiel die Zeile helloworldhello kann in helloworld[00][00][05] einer Länge von 13 Bytes im Vergleich zu den ursprünglichen 15 Bytes komprimiert werden.

Angenommen, der Angreifer versucht, den Klartext des Formulars wiederherzustellen password=..., wobei das Passwort selbst unbekannt ist. Nach dem Kelsey-Angriffsmodell kann der Angreifer den Server bitten, die Nachrichten des Formulars zu komprimieren und dann zu verschlüsseln (Klartext, dem folgt ), wo — beliebiger Text. Wenn der Server seine Arbeit beendet hat, gibt er die Länge des Ergebnisses bekannt. Der Angriff verläuft wie folgt:

Hacker: Bitte komprimiere und verschlüssele den Klartext ohne jegliche Füllzeichen.
Server: Die Länge des Ergebnisses beträgt 14.
Hacker: Bitte komprimiere und verschlüssele den Klartext, dem hinzugefügt wurde password=a.
Server: Die Länge des Ergebnisses beträgt 18.

Der Angreifer merkt an: [Ursprung 14] + [drei Bytes, die ersetzt haben password=] + a

Hacker: Bitte komprimiere und verschlüssele den Klartext, dem hinzugefügt wurde password=b.
Server: Die Länge des Ergebnisses beträgt 18.
Hacker: Bitte komprimiere und verschlüssele den Klartext, dem hinzugefügt wurde password=с.
Server: Die Länge des Ergebnisses beträgt 17.

Der Angreifer merkt an: [Ursprung 14] + [drei Bytes, die ersetzt haben password=c]. Dies deutet darauf hin, dass der ursprüngliche Klartext die Zeichenfolge enthält password=c. Das bedeutet, das Passwort beginnt mit dem Buchstaben c

Hacker: Bitte komprimiere und verschlüssele den Klartext, dem hinzugefügt wurde password=сa.
Server: Die Länge des Ergebnisses beträgt 18.

Der Angreifer merkt an: [Ursprung 14] + [drei Bytes, die ersetzt haben password=с] + a

Hacker: Bitte komprimiere und verschlüssele den Klartext, dem hinzugefügt wurde password=сb.
Server: Die Länge des Ergebnisses beträgt 18.

(… einige Zeit später…)

Hacker: Bitte komprimiere und verschlüssele den Klartext, dem hinzugefügt wurde password=со.
Server: Die Länge des Ergebnisses beträgt 17.

Der Angreifer merkt an: [Ursprung 14] + [drei Bytes, die ersetzt haben password=co]. Nach demselben Prinzip schließt der Angreifer, dass das Passwort mit den Buchstaben co

und so weiter fortfährt, bis das gesamte Passwort wiederhergestellt ist.

Es ist dem Leser verzeihlich zu denken, dass dies eine rein akademische Übung ist und ein solches Angriffsszenario in der realen Welt niemals auftreten wird. Leider, wie wir bald sehen werden, sollte man in der Kryptografie besser nichts ausschließen.

Markenspezifische Schwachstellen: CRIME, POODLE, DROWN

Schließlich, nach einer detaillierten Untersuchung der Theorie, können wir betrachten, wie diese Methoden in echten kryptografischen Angriffen angewendet werden.

CRIME

Wenn der Angriff auf den Browser und das Netzwerk des Opfers abzielt, wird es einfacher in einigen Aspekten und schwieriger in anderen. Zum Beispiel ist es einfach, den Traffic des Opfers zu sehen: Man muss nur im selben Café mit WiFi wie das Opfer sitzen. Aus diesem Grund wird potenziellen Opfern (d.h. allen) in der Regel empfohlen, eine verschlüsselte Verbindung zu verwenden. Es wird komplizierter, aber immer noch möglich, HTTP-Anfragen im Namen des Opfers an eine Drittanbieter-Website (z.B. Google) zu senden. Der Angreifer muss das Opfer auf eine bösartige Webseite mit einem Skript locken, das die Anfrage ausführen wird. Der Webbrowser wird automatisch das entsprechende Sitzungscookie bereitstellen.

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

Wir müssen betonen, dass, wenn Bob keine verschlüsselte Verbindung verwendet, all diese Schutzmaßnahmen nutzlos sind. Der Angreifer kann einfach Bobs Verkehr lesen und das Google-Session-Cookie wiederherstellen. Mit diesem Cookie kann er einfach einen neuen Tab in Google öffnen, ohne seinen eigenen Browser zu verlassen, und sich als Bob ausgeben, ohne den lästigen Same-Origin-Policy-Einschränkungen zu begegnen. Aber leider für den Angreifer kommt dies immer seltener vor. Das Internet hat im Allgemeinen den unverschlüsselten Verbindungen den Krieg erklärt, und Bobs ausgehender Verkehr ist wahrscheinlich verschlüsselt, egal ob es ihm gefällt oder nicht. Darüber hinaus wurde seit der frühen Einführung des Protokolls der Verkehr auch komprimiert vor der Verschlüsselung; dies war eine gängige Praxis zur Verringerung der Latenz.

Hier kommt CRIME (Compression Ratio Infoleak Made Easy, einfache Leckage über das Kompressionsverhältnis) ins Spiel. Eine Schwachstelle, die im September 2012 von den Sicherheitsexperten Giuliano Rizzo und Thai Duong aufgezeigt wurde. Wir haben bereits die gesamte theoretische Grundlage durchgearbeitet, die es ermöglicht, zu verstehen, was sie getan haben und wie. Der Angreifer kann den Browser von Bob dazu bringen, Anfragen an Google zu senden und dann die Antworten im lokalen Netzwerk in komprimierter, verschlüsselter Form abzuhören. Daher haben wir:

Hier kontrolliert der Angreifer die Anfrage und hat Zugriff auf einen Verkehrssniffer, einschließlich der Paketgrößen. Das fiktive Szenario von Kelsey wurde Realität.

Durch das Verständnis der Theorie haben die Autoren von CRIME einen Exploit erstellt, der Sitzungscookies von einer Vielzahl von Websites stehlen kann, einschließlich Gmail, Twitter, Dropbox und Github. Die Schwachstelle betraf die meisten modernen Webbrowser, was zu Patches führte, die die Komprimierungsfunktion in SSL stillschweigend deaktivierten, sodass sie überhaupt nicht mehr verwendet wurde. Der einzige, der gegen die Schwachstelle geschützt war, war der ehrwürdige Internet Explorer, der SSL-Komprimierung nie verwendete.

POODLE

Im Oktober 2014 sorgte das Sicherheitsteam von Google für Aufsehen in der Sicherheitsgemeinschaft. Sie konnten eine Schwachstelle im SSL-Protokoll ausnutzen, die vor über zehn Jahren behoben wurde.

Es stellte sich heraus, dass, obwohl auf den Servern der brandneue TLSv1.2 läuft, viele die Unterstützung des veralteten SSLv3 aus Gründen der Abwärtskompatibilität mit Internet Explorer 6 beibehalten haben. Wir haben bereits über Downgrade-Angriffe gesprochen, Sie können sich also vorstellen, was passiert. Ein gut organisierter Sabotageakt am Handshake-Protokoll – und die Server sind bereit, zum guten alten SSLv3 zurückzukehren, was die letzten 15 Jahre der Sicherheitsforschung essentially zunichte macht.

Zur historischen Einordnung, hier ist eine kurze Zusammenfassung der Geschichte von SSL bis zur 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 bei Netscape Communications unter dem Namen „Secure Sockets Layer“ oder SSL. Es wird gemunkelt, dass die erste Version von SSL so schrecklich war, dass die Entwickler alle Codeausdrucke einsammelten und auf einer geheimen Müllhalde in New Mexico begruben. Folglich ist die erste öffentliche Version von SSL tatsächlich die Version SSL 2.Sie ist ziemlich erschreckend, und [..] es war ein Produkt aus den 90er Jahren, die moderne Kryptographen als "dunkle Jahrhunderte der Kryptographie" betrachten. Viele der abscheulichsten kryptographischen Angriffe, von denen wir heute wissen, waren noch nicht entdeckt. Infolgedessen mussten die Entwickler des Protokolls SSLv2 essentially im Dunkeln tappen, und sie stießen auf unzählige schreckliche Monster - zu ihrem Bedauern und zu unserem Vorteil, da die Angriffe auf SSLv2 wertvolle Lektionen für die nächste Generation von Protokollen hinterlassen haben.

Nach diesen Ereignissen stellte das enttäuschte Unternehmen Netscape im Jahr 1996 das SSL-Protokoll von Grund auf neu auf. Das Ergebnis war SSL Version 3, das einige bekannte Sicherheitsprobleme seines Vorgängers behob.

Zu Glück der Hacker bedeutet „einige“ nicht „alle“. Insgesamt stellte SSLv3 alle erforderlichen Bausteine für den Start eines Wasserfallangriffs bereit. Protokoll verwendete einen Blockcipher im CBC-Modus und ein unsicheres Padding-Schema (das wurde in TLS behoben; folglich entstand die Notwendigkeit für einen Downgrade-Angriff). Wenn Sie sich das Padding-Schema in unserer ursprünglichen Beschreibung des Wasserfallangriffs erinnern, sieht das SSLv3-Schema sehr ähnlich aus.

Aber leider für die Hacker bedeutet „ähnlich“ nicht „identisch“. Das Padding-Schema von SSLv3 hat die Form „N willkürliche Bytes, gefolgt von der Zahl N“. Versuchen Sie unter diesen Bedingungen, einen imaginären Block des chiffrierten Texts auszuwählen und alle Phasen des ursprünglichen Wasserfall-Schemas durchzugehen: Sie werden feststellen, dass der Angriff erfolgreich das letzte Byte aus dem entsprechenden Klartextblock extrahiert, aber nicht weitergeht. Die Entschlüsselung jedes 16. Bytes des chiffrierten Texts ist ein großartiger Trick, aber das ist kein Sieg.

Mit dem Misserfolg konfrontiert, griff das Google-Team auf eine extreme Option zurück: Sie wechselten zu einem leistungsfähigeren Bedrohungsmodell – dem, das in CRIME verwendet wurde. Angenommen, der Angreifer ist ein Skript, das im Browser-Tab des Opfers ausgeführt wird, und er kann Sitzungs-Cookies extrahieren, bleibt der Angriff dennoch beeindruckend. Obwohl das breitere Bedrohungsmodell weniger realistisch ist, haben wir im vorherigen Abschnitt bereits gesehen, dass dieses spezifische Modell umsetzbar ist.

Angesichts solcher leistungsstarker Möglichkeiten des Angreifers kann der Angriff jetzt fortgesetzt werden. Beachten Sie, dass der Angreifer weiß, wo die verschlüsselte Sitzungscookie-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 übereinstimmt. Jetzt kann dieses Byte zur Entschlüsselung verwendet werden. Man kann einfach ein Zeichen zur Anfrage hinzufügen, und das vorletzte Byte des Cookies bleibt an derselben Stelle und kann nach demselben Prinzip verwendet werden. Der Angriff geht so lange weiter, bis die Cookie-Datei vollständig wiederhergestellt ist. Dies wird als POODLE bezeichnet: Padding Oracle on Downgraded Legacy Encryption.

DROWN

Wie bereits erwähnt, hatte SSLv3 Schwächen, war jedoch grundlegend anders als sein Vorgänger, da das unsichere SSLv2 ein Produkt einer anderen Ära war. Dort konnte die Nachricht in der Mitte unterbrochen werden: Ich will dem nur über meine Leiche zustimmen verwandelte sich in Ich will dem zustimmen; Klient und Server konnten sich im Internet treffen, Vertrauen aufbauen und Geheimnisse vor den Augen eines Angreifers austauschen, der sich dann leicht als einer von beiden ausgab. Außerdem gab es das Problem mit der Exportkryptografie, das wir bei der Betrachtung von FREAK erwähnt haben. Dies war kryptografisches Sodom und Gomorra.

Im März 2016 versammelte sich ein Team von Forschern aus verschiedenen technischen Bereichen und machte eine erstaunliche Entdeckung: SSLv2 wird weiterhin in Sicherheitssystemen verwendet. Ja, Angreifer konnten moderne TLS-Sitzungen nicht mehr auf SSLv2 herunterstufen, da dieses Loch nach FREAK und POODLE geschlossen wurde, aber sie konnten sich immer noch mit Servern verbinden und selbst SSLv2-Sitzungen initiieren.

Sie fragen sich, was es uns angeht, was sie dort tun? Sie haben eine anfällige Sitzung, aber das sollte keine Auswirkungen auf andere Sitzungen oder die Sicherheit des Servers haben – richtig? Nun, nicht ganz. Ja, so sollte es theoretisch sein. Aber nein – denn die Generierung von SSL-Zertifikaten bringt eine gewisse Last mit sich, was dazu führt, dass viele Server dieselben Zertifikate und damit dieselben RSA-Schlüssel für TLS- und SSLv2-Verbindungen verwenden. Noch schlimmer ist, dass aufgrund eines Bugs in OpenSSL in dieser beliebten SSL-Implementierung die Option "SSLv2 deaktivieren" tatsächlich nicht funktionierte.

Dies ermöglichte einen plattformü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) bezeichnet wird. Erinnern wir uns, dass dies nicht dasselbe ist wie ein Downgrade-Angriff; der Angreifer muss nicht als „Man-in-the-Middle“ agieren und braucht den Client nicht in einen unsicheren Sitzung einzubeziehen. Die 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 von diesem Zeitpunkt an kann keine TLS-Sicherheit ihn vor dem Zugriff schützen.

Aber um den Angriff durchführen zu können, benötigt man einen funktionierenden Angriff gegen SSLv2, der es erlaubt, nicht nur den spezifischen Verkehr wiederherzustellen, sondern auch den geheimen RSA-Server-Schlüssel. Auch wenn dies eine komplizierte Anforderung ist, konnten die Forscher jede Schwachstelle wählen, die nach SSLv2 vollständig geschlossen wurde. Letztendlich fanden sie eine geeignete Option: den Bleichenbacher-Angriff, auf den wir zuvor hingewiesen haben und den wir im nächsten Artikel ausführlich erklären werden. SSL und TLS sind vor diesem Angriff geschützt, aber einige zufällige Funktionen von SSL in Kombination mit kurzen Schlüsseln in der Exportverschlüsselung haben dies ermöglicht, eine bestimmte Implementierung von DROWN..

Zum Zeitpunkt der Veröffentlichung waren 25 % der Top-Websites des Internets anfällig für die DROWN-Schwachstelle, und der Angriff konnte mit bescheidenen Ressourcen durchgeführt werden, die selbst für aufregende Einzelhacker zugänglich waren. Um den RSA-Schlüssel des Servers zu extrahieren, waren acht Stunden Berechnungen und 440 $ erforderlich, und SSLv2 wechselte den Status von „veraltet“ zu „radioaktiv“.

Warte mal, was ist mit Heartbleed?

Das ist kein kryptographischer Angriff im Sinne der oben beschriebenen; es handelt sich um einen Pufferüberlauf.

Lass uns eine Pause machen.

Wir begannen mit einigen grundlegenden Methoden: Brute-Force, Interpolation, Downgrade, plattformübergreifend und Vorberechnungen. Dann betrachteten wir eine fortgeschrittene Technik, möglicherweise das Hauptmerkmal moderner kryptographischer Angriffe: den Orakelangriff. Wir haben uns eine Weile mit ihm beschäftigt – und verstanden nicht nur das zugrunde liegende Prinzip, sondern auch die technischen Details von zwei spezifischen Implementierungen: dem Vaudenay-Angriff auf den CBC-Verschlüsselungsmodus und dem Kelsey-Angriff auf Verschlüsselungsprotokolle mit vorbeugender Komprimierung.

Bei der Analyse von Abwärtsangriffen und mit vorläufigen Berechnungen haben wir den FREAK-Angriff kurz zusammengefasst, der beide Methoden nutzt, da die Zielwebsites auf schwache Schlüssel zurückfallen und dann dieselben Schlüssel wiederverwenden. Für den nächsten Artikel haben wir den (sehr ähnlichen) Logjam-Angriff belassen, der gegen Public-Key-Algorithmen gerichtet ist.

Anschließend betrachteten wir drei weitere Anwendungsbeispiele dieser Prinzipien. Zunächst CRIME und POODLE: zwei Angriffe, die auf der Fähigkeit des Angreifers basierten, beliebigen Klartext neben dem Ziel-Klartext einzufügen, dann die Serverantworten zu analysieren und dann, indem sie die Methodik des Orakelangriffs verwendeten, diese spärlichen Informationen für die teilweise Wiederherstellung des Klartexts zu nutzen. CRIME folgte dem Angriffsweg von Kelsey auf SSL-Kompression, während POODLE stattdessen eine Variante des Bleichenbacher-Angriffs auf CBC mit dem gleichen Effekt verwendete.

Dann lenkten wir unsere Aufmerksamkeit auf den protokollübergreifenden DROWN-Angriff, der eine Verbindung zum Server über das veraltete Protokoll SSLv2 herstellt und anschließend geheime Server-Schlüssel durch den Bleichenbacher-Angriff wiederherstellt. Bisher haben wir die technischen Details dieses Angriffs ausgelassen; wie Logjam muss er warten, bis wir die Public-Key-Kryptosysteme und deren Schwachstellen gründlich studiert haben.

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

Quelle: habr.com