Modellierung kryptographischer Protokolle und Angriffe auf das Design

Seminar Formale Methoden zur IT-Sicherheit Modellierung kryptographischer Protokolle und Angriffe auf das Design Johannes Clos clos@rbg.informatik.tu-darmstadt.de November 2003 Veranstalter: Prof. Dr. Christoph Walter, Joachim Nadler, Carsten Kunz Fachgebiet Programmiermethodik Fachbereich Informatik TU Darmstadt

Abstract Wir werden verschiedene Public-Key Authentifizierungs-Protokolle so wie Angriffe auf ihr Design kennenlernen. Zunächst wird das Protokoll von Needham-Schroeder vorgestellt. Da es insgesamt eine geringere Anzahl an erreichbaren Zuständen hat, ist es vergleichsweise einfach zu analysieren. Dennoch hat es unter Verwendung menschlicher Protokollanalyse lange Zeit gedauert, bis eine Schwäche entdeckt wurde. Die Untersuchung von SSL ist wesentlich schwieriger. Es umfasst mehrere Unterprotokolle, was zu einer großen Zahl möglicher Protokollabläufe führt. Bei der Untersuchung kryptographischer Protokolle wird formale Logik intensiv eingesetzt. Am Beispiel von SSL wird eine auf formaler Logik basierende, automatisierte Protokollanalyse exemplarisch dargestellt. Schlagwörter: Finite-State Modell, Model-Checking, Public-Key Kryptografie Einleitung Kryptographische Protokolle spielen im Internet eine wichtige Rolle. SSL ist heute der de-facto Standard für die Absicherung elektronischer Geschäftsabschlüsse. Online-Banking ist nicht zuletzt deshalb so weit verbreitet, weil seine Nutzung dem Anwender keinerlei Mühen bereitet. Die benötigten Protokolle sind in den meisten Browsern standardmäßig integriert, so dass man dessen Verwendung kaum noch merkt. Doch egal, als wie sicher ein Protokoll entworfen wurde, es kommt vor, dass ein Programmierer bei der Implementierung Benutzerfreundlichkeit stärker gewichtet als die Protokollsicherheit, und deswegen die Definitionen nicht exakt umsetzt. Da diese die exakte Arbeitsweise eines Protokolls beschreiben, dürfen hier allerdings keine wesentlichen Abstriche gemacht werden. Ein anderes Beispiel für Implementierungsfehler sind sogenannte Buffer-Overflow Angriffe. Bei einem Buffer- Overflow Angriff wird Programmcode (z.b. ein Trojaner) auf einem Stack eingeschleust und anschließend mit den Rechten des Prozesses (Root) ausgeführt. Dabei wird ausgenützt, dass bei einem Prozeduraufruf Rücksprung-adresse und Parameter auf dem Stackbereich des Prozessadressraums abgelegt wird. Buffer- Overflow Angriffe werden ebenfalls durch fehlerhafte Programmierung verursacht. Im Gegensatz dazu nutzen Angriffe auf das Design gezielt Schwachstellen der Protokoll-Spezifikationen. Die Möglichkeit eines Angriffs, der durch Definitionslücken in einem Protokoll zustande kommt, wird auch nach der Implementierung vorhanden sein, da die Programmierung die Spezifikationen bestenfalls exakt umsetzt. Wie man mögliche Fehler von Protokolldefinition finden kann und wie sich diese beheben lassen, wird diese Arbeit anhand zweier verschiedener Protokolle aufzeigen. Dazu betrachten wir zunächst in Abschnitt 1 das Protokoll von Needham-Schroeder. Anschließend wird in Abschnitt 2 am Beispiel von SSL gezeigt, wie sich die Suche nach Schwachstellen unter Verwendung formaler Methoden gestalteten lässt. 2

1. Needham-Schroeder Public-Key Protokoll Alice und Bob wollen über ein allgemein abhörbares Netz ein gemeinsames Geheimnis vereinbaren. (Dies ist eine der Grundaufgaben in kryptographischen Anwendungen z.b. bei der Generierung eines Sitzungsschlüssels, mit dem nachfolgende Nachrichten verschlüsselt werden.) Dazu generieren sie zwei Zufallszahlen (nonces) Na und Nb, die sie austauschen - das Geheimnis besteht dann im Paar (Na, Nb). Der Austausch soll so vonstatten gehen, dass Authentizität und Vertraulichkeit gewährleistet werden. Alice und Bob sollen also anschließend davon überzeugt sein, dass die gesendete Zufallszahl wirklich vom jeweiligen Kommunikationspartner stammt. Alice und Bob besitzen öffentliche Schlüssel Ka und Kb, die nicht korrumpiert sind. Alice gelangt an Bobs Public-Key, indem sie z.b. von einem Verzeichnisdienst sein Zertifikat anfordert: A S : A,B S A : {Kb,B} Ks-1 Wir bezeichnen mit {M} K das Ergebnis der Verschlüsselung von Nachricht M mit dem Schlüssel K. Nachrichten der Form {M} Ka können nur von Alice entschlüsselt werden, da nur sie den hierfür benötigten Private-Key Ka -1 besitzt. Dies ist ein wesentliches Merkmal der Public-Key Kryptografie. Needham und Schroeder schlugen folgendes Protokoll vor, mit dem Alice und Bob ihre Zufallszahlen Na und Nb austauschen können. A B : {Na,A} Kb B A : {Na,Nb} Ka A B : {Nb} Kb (1) Das Needham-Schroeder Protokoll Ein Angreifer hat dabei die folgenden Möglichkeiten: Er kann wie jeder andere Teilnehmer als Partner in Abläufen des Protokolls auftreten; insbesondere besitzt er einen eigenen öffentlichen Schlüssel und kann eigene Nonces generieren. Er kann allerdings nur solche Nachrichten entschlüsseln, die mit seinem eigenen Schlüssel chiffriert sind. Er kann Nachrichten für andere Teilnehmer abfangen und ggf. zwischenspeichern (selbst wenn er sie nicht entschlüsseln kann), um sie später zu verschicken. Er kann sich als Alice oder Bob ausgeben und insbesondere Nachrichten unter deren Namen versenden. Daraus resultiert das folgende Angriffszenario: 3

A I : {Na,A} Ki I(A) B : {Na,A} Kb B I(A) : {Na,Nb} Ka I A : {Na,Nb} Ka A I : {Nb} Ki I(A) B : {Nb} Kb (1.1.) Angriff auf Needham-Schroeder Das Protokoll ist unsicher, denn es garantiert nicht die Authentizität der beteiligten Partner. Dieser Fehler wurde erst 1995 von Gavin Lowe gefunden. Er wurde also 17 Jahre lang nicht entdeckt, obwohl das Protokoll sehr einfach ist und in vielen Lehrbüchern der Kryptographie erwähnt wird. Mit Model Checking kann der Fehler automatisch in wenigen Sekunden Rechenzeit gefunden werden. Diese Form eines Man-in-the-middle-Angriffs kann verhindert werden, indem Bob zusätzlich seinen Namen in die die beiden Noncen enthaltende Antwort an Alice einbringt. Falls nämlich die Bedeutung einer Nachricht unbedingt von der Identität einer Person abhängt, so muss deren Namen ausdrücklich in dieser Nachricht erwähnt werden. 2. Secure Socket Layer SSL wurde 1994 von Netscape vorgestellt. Seitdem hat es einige Verbesserungen erfahren und wurde 1999 von der IETF als Standard für die Kommunikationsabsicherung im Internet festgelegt [6]. Die Hauptziele von SSL sind der Schutz vor Abhören, Verfälschen und Nachahmen von Nachrichten, d.h. es bietet Vertraulichkeit (hybride Verschlüsselung), Authentizität (Zertifikate) und Integrität (digitale Signatur, MAC). SSL ist zwischen der Anwendungs- und der Netzwerkschicht angeordnet. Zwar ist es speziell auf TCP/IP abgestimmt, doch ist es auch auf jedem weiteren verbindungsorientierten Protokoll (x.25) lauffähig. SSL ist sehr leicht in bestehende Systeme zu integrieren, da es den Standard x.509 als Grundlage verwendet. Es tritt gegenüber der Anwendungsschicht wie die Netwerkschicht (TCP) und gegenüber der Netzwerkschicht wie eine Anwendung auf. In der Netzwerkschicht enthalten sind die Message- und die Record-Layer [7]. Zur Message-Layer gehören das Handshake-, das Alert- und das ChangeCipher- Spec-Protokoll. Das mit Abstand wichtigste davon ist das Handshake-Protokoll. Es dient der Versionsabstimmung, der Abstimmung der kryptographischen Verfahren, dem Austausch von Zertifikaten, dem Schlüsselaustausch zum Festlegen von symmetrischen Schlüsseln (Verschlüsselung, MAC), der Authentisierung und der Zuweisung einer Session-ID. Über die Session-ID kann eine frühere Session über einen verkürzten Handshake fortgesetzt werden. 4

(2) Das Handshake-Protokoll Das Client hello enthält die höchste unterstützte Protokollversion, ggf. die Session- ID, sowie eine Liste von "CipherSuites" (eine CipherSuite beinhaltet unter anderem Algorithmen für den Schlüsselaustausch, die digitalen Signaturen und die Kompression). Im Server hello enthalten sind die vom Server ausgewählte CipherSuite, die unterstützte Protokollversion, das Server-Zertifikat (evtl. Anforderung eines Client- Zertifikats), ggf. die Session-ID (verkürzter Handshake), ServerKeyExchange (Public Key des Servers) und das ServerHelloDone (alle Informationen wurden geschickt). Die Fortsetzung des Client hello enthält den ClientKeyExchange (der Client verschlüsselt den symmetrischen Schlüssel mit dem öffentlichen Schlüssel des Servers und sendet ihn als Premaster-Key zurück), evtl. die Zertifikatsüberprüfung des Servers und das ChangeCipherSpec-Protokoll (um so auf die festgelegten Verfahren umzustellen). Sendet der Client sein Finished-Signal, so ist er mit seinem Teil fertig. Wenn der Server das Finished-Signal zurücksendet kann die Übertragung der verschlüsselten Daten beginnen. Trotzdem kann der Server das ChangeCipherSpec-Protokoll jederzeit erneut anstoßen und damit die Einigung auf eine neue Ciphersuite erzwingen. Das Alert-Protokoll signalisiert Fehler, und erzwingt den Abbruch der Verbindung zwischen zwei Rechnern. Es ist sicherheitstechnisch sehr wichtig. Da SSL auf einer zuverlässigen Transportschicht (TCP) aufbaut, wird jeder Fehler als eine mögliche Sicherheitsattacke angesehen. Daher wird bei jedem Fehler die Verbindung abgebrochen. Der Urzustand darf dabei nicht wieder herstellbar sein, da dies zu einer Verletzung der sicheren Übertragung führt. Das ChangeCipherSpec-Protokoll wird sowohl vom Server als auch vom Client gesendet und gilt als definitive Bestätigung, dass nun auf die vereinbarten Verfahren umgestellt wurde. Gleichzeitig können Server oder Client damit aber auch die Einigung auf einen neuen Verschlüsselungsalgorithmus anstoßen. 5

Die Record-Layer tritt als zusätzliche Schicht auf, die für das einheitliche Aussehen der Nachrichten zuständig ist. Sie liegt unter allen anderen Protokollen, übernimmt von ihnen die Nachrichten und modifiziert sie, indem sie den Text in höchstens 214 Byte große Pakete fragmentiert, sogenannte SSLPlaintextRecords. Diese Records werden mit den vereinbarten Kompressions- und Verschlüsselungsalgorithmen verschlüsselt und komprimiert. Die Erhaltung der Datenintegrität wird durch Hashing- Algorithmen (MDA5, SHA-1) gewährleistet. Jedes Record enthält als Informationen den Nachrichten-Typ, die Protokoll-Versions-Nummer, die Länge der Records, die (komprimierte) Nachricht selbst, sowie den Message Authentication Code (MAC). Die Record-Layer leitet diese Records schließlich weiter an die Netzwerkschicht. a. Inkrementelle Verbesserung der Protokolldefinition Wir wollen nun am Beispiel von SSL exemplarisch eine automatisierte Analyse des Protokolls vorstellen. Für das Beispiel wurde Murphi verwendet. Dabei handelt es sich um einen Model Checker. Von einem gültigen Anfangszustand werden die ungültigen Endzustände gesucht. Zunächst wird ein nichtdeterministisches Modell des Protokolls erstellt. Dabei gibt es erlaubte und unerlaubte Zustände. Alle Zustandsübergänge sind mit bestimmten Regeln verknüpft. Mit jedem Zustand werden eine Anzahl elementarer Eigenschaften, die eine Ausführung zu diesem bestimmten Zeitpunkt hat, assoziiert. Anschließend wird getestet, ob die erreichbaren Zustände des aktuellen Modells den gegebenen Spezifikationen genügen. Indem die Menge der bereits erreichten Zustände in Hashtabellen gespeichert werden, wird eine mehrmalige Überprüfung derselben Zustände vermieden, C S : C, Ver C, Suite C S C : Ver S, Suite S, Ks C S : {SecretC} Ks (3) Protokoll A (erste Version des zu untersuchenden Protokolls) Zunächst schickt der Client seine Sicherheitsanforderungen für einen Protokolldurchlauf. Darin enthalten sind mögliche SSL Versionsnummern und seine kryptographischen Präferenzen. Darauf antwortet der Server in der Regel, indem er die höchste, von ihm unterstützte Version, sowie die stärksten kryptographischen Verfahren aussucht und zusammen mit seinem Public Key zurück an den Client sendet. Mit dem erhaltenen Public-Key kann der Client nun das von ihm erzeugte Secret verschlüsseln, so dass nur der Server mit Hilfe seines Private-Key dieses wieder entschlüsseln kann. Ein Angriff auf Protokoll A ist sehr simpel: Der Angreifer fängt lediglich die vom Server an den Client gesendete Nachricht auf. Er ersetzt den Public-Key des Servers durch seinen eigenen und sendet die Nachricht weiter an den Client. Der Client verschlüsselt das SecretC mit diesem Schlüssel. Damit ist es für den Angreifer lesbar geworden. 6

C S : C, Ver C, Suite C S C(I) : Ver S, Suite S, Ks I C : Ver S, Suite S, Ki C S(I) : {SecretC} Ki I S : {SecretC} Ks (3.1) Angriff auf Protokollversion A Um den Fehler in Protokoll zu beheben wird der Public-Key des Servers in einem von einer CA (Certificate Authority) beglaubigten Zertifikat versand, so dass er die Form sign CA {S,Ks} hat. Wir gehen in unserem Modell davon aus, dass perfekte Kryptografie benutzt wird, es dem Angreifer also nicht möglich ist, ein solches Zertifikat zu fälschen. C S : C, Ver C, Suite C S C : Ver S, Suite S, sign CA {S,Ks} C S : {Secret C } Ks (4) Protokoll B (A + Server-Authentisierung) Da im Protokoll B die Identität des Client nicht überprüft wird kann der Angreifer sich einfach als C ausgeben ein von sich generiertes Secret an S schicken: I S : C, Ver C, Suite C S C(I) : Ver S, Suite S, sign CA {S,Ks} I S : {Secret I } Ks (4.1) Angriff auf Protokollversion B Eine verbesserte Protokollversion erfordert zusätzliche Client-Authentisierung. Der Server muss überprüfen, ob das erhaltene Secret tatsächlich von dem Kommunikationspartner generiert wurde, dessen Identität in der ersten Hello- Nachricht spezifiziert wurde. Also schickt C an S seinen Verifikations-Key in einem von einer CA beglaubigten Zertifikat. Zusätzlich zu seinem verschlüsselten Secret schickt C noch sein gehashtes Secret, das außerdem von ihm signiert wird. Der Server kann nun aus dem entschlüsselten Secret ebenfalls den Hash-Wert berechnen und die beiden Werte vergleichen. C S : C, Ver C, Suite C S C : Ver S, Suite S, sign CA {S,Ks} C S : sign CA {C, V C }, {Secret C } Ks, sign C {Hash(Secret C )} (5) Protokoll C (B + Client-Authentisierung) 7

Protokoll C ist anfällig für eine Version-Rollback-Attack. Dem Angreifer ist es möglich, einen SSL3.0 Server davon zu überzeugen, mit einem SSL2.0 Client zu kommunizieren und umgekehrt. C und S kommunizieren folglich indem sie als Protokoll SSL2.0 verwenden und der Angreifer so die Möglichkeit hat, eine der bekannten Schwachstellen auszunutzen. C S(I) : C,Ver C,Suite C I S : C,Ver I,Suite I S C(I) : Ver I,Suite S, sign CA {S,Ks} I C : Ver I,Suite I, sign CA {S,Ks} C S : sign CA {C, V C }, {Secret C } Ks, sign C {Hash(Secret C )} (5.1) Angriff auf Protokollversion C Diese Art Angriff ist nicht praktikabel, wenn C und S verifizieren, dass ihre Protokollläufe zueinander passen. Das geschieht, indem sie alle Nachrichten mit dem Master-Secret beglaubigen. Bei Erfolg generieren beide vom Master-Key die Session-Keys und versenden von da an ihre verschlüsselten Anwendungsdaten. C S : C, Ver C,Suite C S C : Ver S,Suite S, sign CA {S,Ks} C S : sign CA {C, V C }, {Secret C } Ks, sign C {Hash(Secret C )} S C : {Hash(Ver C, Suite C, Ver S, Suite S )} Master(SecretC) C S : {Hash(Ver C, Suite C, Ver S, Suite S )} Master(SecretC) (6) Protokoll D (C + post-handshake Verifikation des Plaintext) Dennoch hat auch dieses Protokoll seine Schwachstelle: Der Angreifer beginnt wieder, indem er C s Hello-Nachricht auffängt. Anschließend schickt er sie mit seiner eigenen Identität (statt C s) weiter an S. Alle Nachrichten von S an C, und die meisten von C an S, werden weitergeleitet. Dem Angreifer ist es nicht möglich, an das von C generierte Secret C zu gelangen. Letztendlich schließen C und S das Handshake-Protokoll erfolgreich ab, jedoch glaubt C, er kommuniziere mit S, S aber glaubt an I. C S(I) : C, Ver C, Suite C I S : I, Ver C, Suite C S I : Ver S, Suite S, sign CA {S,Ks} I C : Ver S, Suite S, sign CA {S,Ks} C S(I) : sign CA {C, V C }, {Secret C } Ks, sign C {Hash(Secret C )} I S : sign CA {I, V I }, {Secret C } Ks, sign I {Hash(Secret C )} S I : {Hash(Ver C, Suite C, Ver S, Suite S )} Master(SecretC) I C : {Hash(Ver C, Suite C, Ver S, Suite S )} Master(SecretC) C S(I) : {Hash( )} Master(SecretC) I S : {Hash( )} Master(SecretC) (6.1) Angriff auf Protokollversion D 8

Protokoll E behebt diese Schwachstelle dadurch, daß als Verifikations-Nachricht nun alle Nachrichten gehasht und mit dem Master-Secret verschlüsselt werden. C S : C, Ver C,Suite C S C : Ver S,Suite S, sign CA {S,Ks} C S : sign CA {C, V C }, {Secret C } Ks, sign C {Hash(Secret C )} <Beginn der vereinbarten Verschlüsselung> S C : Hash{Messages} Master(SecretC) C S : Hash{Messages} Master(SecretC) (7) Protokoll E (D + post-handshake Verifikation aller Nachrichten) Ein Replay-Angriff auf Version E des Protokolls ist möglich, indem der Angreifer die zuvor abgefangenen Nachrichten, einschließlich SessionID, erneut einspielt. Unter Wiederverwendung der SessionID wird das Handshake-Protokoll im zweiten Durchlauf verkürzt und so die vorher aufgezeichnete Session zwischen C und S nun zwischen dem sich als C ausgebendem Angreifer fortgesetzt. Obwohl der Angreifer nicht in der Lage ist die abgefangenen Nachrichten zu lesen, gelingt ihm die Täuschung des Servers. Denn trotz völliger Abwesenheit von C glaubt S an die Kommunikation mit ihm. C S : C, Ver C,Suite C S C : Ver S,Suite S, sign CA {S,Ks} C S : sign CA {C, V C }, {Secret C } Ks, sign C {Hash(Secret C )} <Beginn der vereinbarten Verschlüsselung> S C : Hash{Messages} Master(SecretC) C S : Hash{Messages} Master(SecretC) I S : C, Ver C,Suite C S C(I) : Ver S,Suite S, sign CA {S,Ks} I S : sign CA {C, V C }, {Secret C } Ks, sign C {Hash(Secret C )} <Beginn der vereinbarten Verschlüsselung> S C(I) : Hash{Messages} Master(SecretC) I S : Hash{Messages} Master(SecretC) (7.1) Angriff auf Protokollversion E C S : C, Ver C,Suite C, N C S C : Ver S,Suite S, N S, sign CA {S,Ks} C S : sign CA {C, V C }, {Secret C } Ks, sign C {Hash(Secret C )} <Beginn der vereinbarten Verschlüsselung> S C : Hash{Messages} Master(SecretC) C S : Hash{Messages} Master(SecretC) (8) Protokoll F (E + Nonces) Ein Angriff auf diese Version des Protokolls ist ein sogenannter Brute-Force-Angriff. Dieser ist möglich, indem der Angreifer die Hello-Messages so modifiziert, dass sich C und S auf eine schwache Cryptosuite einigen. Anschließend zeichnet er das 9

schwach verschlüsselte SecretC auf und verzögert das Senden der Verification- Messages, um so Zeit zu gewinnen, den Public-Key Algorithmus zu brechen und das SecretC zu erhalten. C S : C, Ver C, Suite C, N C S C : Ver S, Suite S, N S, sign CA {S, Ks} C S : sign CA {C, V C }, {Ver C, Secret C } Ks, sign C {Hash(Messages)} <Beginn der vereinbarten Verschlüsselung> S C : {Hash(Messages)} Master(SecretC) C S : {Hash(Messages)} Master(SecretC) (9) Protokoll Z Protokoll Z stellt eine gegenüber dem Startprotokoll in wesentlichen Funktionen verbesserte Version dar. Die zuvor gesehen Angriffsszenarien werden verhindert, indem nach und nach Zertifizierung, Nonces und Hashwerte der Nachrichten in die Protokolldefinition aufgenommen wurden. 10

3. Fazit Die Verwendung automatischer Protokollanalyse ist, wie wir gesehen haben, auch auf dem vielschichtigen Protokoll SSL mit seiner großen Anzahl erreichbarer Zustände erfolgreich [1]. Designschwächen in Protokollen lassen sich unter Zuhilfenahme Formaler Methoden erheblich schneller finden. Die gefundenen Fehler sind meist einfach zu beheben. Eine vollständig automatische Protokoll-analyse ist im Allgemeinen nicht möglich. Viele Schritte (Modellbeschreibung, Versionsverbesserung ) müssen zunächst vom Menschen ausgeführt werden. Eine Analyse von SSL hat gezeigt, dass das der Version 3.0 entsprechende Protokoll keine weiteren gravierenden Lücken aufweist. Auf diese Weise wurde nachgewiesen, dass die Grundstruktur von SSL 3.0 seinen Ansprüchen genügt und keiner Korrektur bedarf [5]. SSL 3.0 stellt also eine in wesentlichen Punkten verbesserte Version dar. Es bietet eine sehr gute Absicherung gegen Angriffe passiver Art (Abhören von Nachrichten) und es schützt besser vor aktiven Angriffen (Widerholung, Verzögerung, Manipulation von Nachrichten) als dies SSL 2.0 noch tat. Die Sicherheitsmängel, die Angriffe auf die Record-Layer und das Key- Exchange-Protokoll zuließen wurden behoben. Außerdem unterstützt das Protokoll nun eine Vielfalt kryptographischer Algorithmen und benutzt generell einen 128-bit MAC. Dadurch ist für die Integrität (Echtheit) der Nachrichten wesentlich besser gesorgt. Ein paar einfach zu patchende Formfehler treten noch bei aktiven Attacken auf [5]. Diese Fehler wurden bei der menschlichen Analyse zum Teil übersehen. Vor allem werden diese durch die Möglichkeit der Fortsetzung eines bereits durchlaufenen Protokolls hervorgerufen. Eine Protokollanalyse mit rein menschlichen Mitteln wäre also schwierig um einiges schwieriger gewesen und hätte eines größeren Aufwands bedurft. Man sieht, Computer unterstütztes Protokolldesign ist sehr effektiv und beschleunigt die Protokollanalyse. Die kommerzielle Nutzung der Verfahren lässt aber nicht zuletzt deshalb auf sich warten, weil viele der Analyse-Programme schwierig in der Handhabbarkeit sind. TLS (Transpor Layer Security) Version 1.0 ist eine von der IETF standardisierte Protokollversion [RFC2246] von SSL. Seine zukünftige Bedeutung wird kaum in Frage gestellt. Die gefundenen Schwachstellen basieren auf leicht zu behebenden Formfehlern, weshalb man ihre Bedeutung nicht allzu hoch einstufen sollte. Solange die dem Protokoll zugrunde liegenden kryptographischen Verfahren als sicher gelten, ist es auch das Protokoll. Sollten die heute üblichen Public-Key Verfahren in naher Zukunft wider Erwarten einfach zu brechen sein, so lassen sich einfach neue Algorithmen implementieren, ohne dass die Struktur des Protokolls geändert werden muss. 11

Quellenangaben: [1] An Attack on the Needham-Schroeder Public-Key Authentication Protocol, G. Lowe http://web.comlab.ox.ac.uk/oucl/work/gavin.lowe/security/papers/nspkp.ps [2] Analyzing the Needham-Schroeder Public-Key Protocol: A Comparison between two approaches, C. Meadows http://chacs.nrl.navy.mil/publications/chacs/1996/1996meadows- ESORICS.pdf [4] Finite-State Analysis of SSL 3.0, J. Mitchell, V. Shmatikov, U. Stern http://www.usenix.org/publications/library/proceedings/sec98/full_papers/mitch ell/mitchell.pdf [5] Analysis of the SSL 3.0 Protocol, D. Wagner and B. Schneier http://www.schneier.com/paper-ssl.html [6] SSL Version 3.0 IETF Internet Draft http://home.netscape.com/eng/ssl3 [7] SSL Eine Einführung von Netscape http://developer.netscape.com/docs/manuals/security/sslin/contents.htm [8] Murphi description language and verifier http://verify.stanford.edu/dill/murphi.html 12