diff --git a/Network Security - Cheatsheet.pdf b/Network Security - Cheatsheet.pdf index 3fe1e30..401dae8 100644 Binary files a/Network Security - Cheatsheet.pdf and b/Network Security - Cheatsheet.pdf differ diff --git a/Network Security - Cheatsheet.tex b/Network Security - Cheatsheet.tex index e5b7e73..01534de 100644 --- a/Network Security - Cheatsheet.tex +++ b/Network Security - Cheatsheet.tex @@ -125,6 +125,17164 @@ \setlength{\postmulticols}{1pt} \setlength{\multicolsep}{1pt} \setlength{\columnsep}{2pt} -start + + \section{Einleitung} + \subsection{Was ist eine Bedrohung in einem Kommunikationsnetz?} + + \begin{itemize} + \item Abstrakte Definition + \begin{itemize} + \item + Eine Bedrohung in einem Kommunikationsnetz ist ein mögliches + Ereignis oder eine Folge von Aktionen, die zu einer Verletzung eines + oder mehrerer Sicherheitsziele führen können. + \item + Die tatsächliche Realisierung einer Bedrohung wird als Angriff + bezeichnet. + \end{itemize} + \item + Beispiele + + \begin{itemize} + \item + Ein Hacker bricht in einen Firmencomputer ein + \item + Offenlegung von E-Mails während der Übertragung + \item + Jemand ändert Finanzbuchhaltungsdaten + \item + Ein Hacker, der eine Website vorübergehend außer Betrieb setzt + \item + Jemand, der Dienstleistungen in Anspruch nimmt oder Waren im Namen + anderer bestellt + \end{itemize} + \item + Was sind Sicherheitsziele? + + \begin{itemize} + \item + Sicherheitsziele können definiert werden + \item + in Abhängigkeit von der Anwendungsumgebung oder + \item + auf eine allgemeinere, technische Weise + \end{itemize} + \end{itemize} + + + \subsection{Sicherheitsziele in Abhängigkeit von der + Anwendungsumgebung} + + \begin{itemize} + \item + Bankwesen + + \begin{itemize} + \item + Schutz vor betrügerischen oder versehentlichen Änderungen von + Transaktionen + \item + Identifizierung von Kunden bei Privatkundentransaktionen + \item + Schutz von PINs vor Offenlegung + \item + Sicherstellung der Privatsphäre der Kunden + \end{itemize} + \item + Elektronischer Handel + + \begin{itemize} + \item + Sicherstellung der Herkunft und Integrität von Transaktionen + \item + Schutz der Privatsphäre von Unternehmen + \item + Rechtsverbindliche elektronische Signaturen für Transaktionen + bereitstellen + \end{itemize} + \item + Regierung + + \begin{itemize} + \item + Schutz vor Offenlegung sensibler Informationen + \item + Bereitstellung elektronischer Signaturen für Regierungsdokumente + \end{itemize} + \item + Öffentliche Telekommunikationsanbieter + + \begin{itemize} + \item + Beschränken Sie den Zugang zu Verwaltungsfunktionen auf + autorisiertes Personal + \item + Schutz vor Dienstunterbrechungen + \item + Schutz der Privatsphäre der Teilnehmer + \end{itemize} + \item + Firmen-/Privatnetzwerke + + \begin{itemize} + \item + Schutz der Privatsphäre von Unternehmen/Personen + \item + Sicherstellung der Authentizität von Nachrichten + \end{itemize} + \item + Alle Netzwerke + + \begin{itemize} + \item + Verhinderung des Eindringens von außen (wer will schon Hacker?) + \end{itemize} + \item + Manchmal werden Sicherheitsziele auch als Sicherheitsvorgaben + bezeichnet + \end{itemize} + + + \subsection{Sicherheitsziele technisch + definiert} + + \begin{itemize} + \item + \textbf{Vertraulichkeit (Confidentiality)} + + \begin{itemize} + \item + Übertragene oder gespeicherte Daten sollten nur einem bestimmten + Personenkreis zugänglich gemacht werden. + \item + Die Vertraulichkeit von Entitäten wird auch als Anonymität + bezeichnet. + \end{itemize} + \item + \textbf{Integrität der Daten (Data Integrity)} + + \begin{itemize} + \item + Es sollte möglich sein, jede Veränderung von Daten zu erkennen. + \item + Dies setzt voraus, dass der Ersteller bestimmter Daten identifiziert + werden kann. + \end{itemize} + \item + \textbf{Rechenschaftspflicht (Accountability)} + + \begin{itemize} + \item + Es sollte möglich sein, die für ein Kommunikationsereignis + verantwortliche Stelle zu identifizieren. + \end{itemize} + \item + \textbf{Verfügbarkeit (Availability)} + + \begin{itemize} + \item + Die Dienste sollten verfügbar sein und korrekt funktionieren. + \end{itemize} + \item + \textbf{Kontrollierter Zugang (Controlled Access)} + + \begin{itemize} + \item + Nur autorisierte Stellen sollten auf bestimmte Dienste oder + Informationen zugreifen können. + \end{itemize} + \end{itemize} + + + \subsection{Technisch definierte + Bedrohungen} + + \begin{itemize} + \item + \textbf{Maskerade (oder Man-in-the-Middle-Angriff, Masquerade)} + + \begin{itemize} + \item + Eine Entität gibt sich als eine andere Entität aus + \end{itemize} + \item + \textbf{Lauschangriff (Eavesdropping)} + + \begin{itemize} + \item + Eine Entität liest Informationen, die sie nicht lesen soll + \end{itemize} + \item + \textbf{Verletzung der Berechtigung (Authorization Violation)} + + \begin{itemize} + \item + Eine Entität nutzt einen Dienst oder Ressourcen, für die sie nicht + vorgesehen ist + \end{itemize} + \item + \textbf{Verlust oder Veränderung} von (übertragenen) Informationen + (Loss or Modification of (transmitted) Information) + + \begin{itemize} + \item + Daten werden verändert oder zerstört + \end{itemize} + \item + \textbf{Verweigerung von Kommunikationsakten (Denial of Communication + Acts, Repudiation)} + + \begin{itemize} + \item + Ein Unternehmen leugnet fälschlicherweise seine Teilnahme an einer + Kommunikationshandlung + \end{itemize} + \item + \textbf{Fälschung von Informationen (Forgery of Information)} + + \begin{itemize} + \item + Ein Unternehmen erstellt neue Informationen im Namen eines anderen + Unternehmens + \end{itemize} + \item + \textbf{Sabotage (oder Denial-of-Service-Angriffe)} + + \begin{itemize} + \item + Jede Aktion, die darauf abzielt, die Verfügbarkeit und/oder das + ordnungsgemäße Funktionieren von Diensten oder Systemen zu + beeinträchtigen. + \end{itemize} + \end{itemize} + + + \subsection{Bedrohungen und technische + Sicherheitsziele} + + Diese Bedrohungen werden oft kombiniert, um einen Angriff durchzuführen! + + %\begin{longtable}[]{@{}llllllll@{}} + % \toprule + % Technische Sicherheitsziele & Maskerade & Abhören & + % Autorisierungsverletzung & Verlust oder Modifikation von (übertragenen) + % Informationen & Denial of Communication-Aktionen & Fälschung von + % Informationen & Sabotage (z.B. durch Überlastung)\tabularnewline + % \midrule + % \endhead + % Vertraulichkeit & x & x & x & & & & \tabularnewline + % Datenintegrität & x & & x & x & x & x & \tabularnewline + % Rechenschaftspflicht & x & & x & & x & x & \tabularnewline + % Verfügbarkeit & x & & x & x & & & x\tabularnewline + % Kontrollierter Zugriff & x & & x & & & x & \tabularnewline + % \bottomrule + %\end{longtable} + + + \subsection{Analyse der + Netzwerksicherheit} + + \begin{itemize} + \item + Um geeignete Gegenmaßnahmen gegen Bedrohungen ergreifen zu können, + müssen diese für eine gegebene Netzkonfiguration angemessen bewertet + werden. + \item + Daher ist eine detaillierte Netzsicherheitsanalyse erforderlich, die + + \begin{itemize} + \item + das Risikopotenzial der allgemeinen Bedrohungen für die ein Netz + nutzenden Einheiten bewertet und + \item + den Aufwand (Ressourcen, Zeit usw.) abschätzt, der zur Durchführung + bekannter Angriffe erforderlich ist. + \item + Achtung! Es ist im Allgemeinen unmöglich, unbekannte Angriffe zu + bewerten! + \end{itemize} + \item + Eine detaillierte Sicherheitsanalyse einer bestimmten + Netzkonfiguration / spezifischen Protokollarchitektur + + \begin{itemize} + \item + kann auch erforderlich sein, um die Finanzkontrolleure eines + Unternehmens davon zu überzeugen, Mittel für + Sicherheitsverbesserungen bereitzustellen, und + \item + kann besser nach den feinkörnigeren Angriffen auf der + Nachrichtenebene strukturiert werden. + \end{itemize} + \end{itemize} + + + \subsection{Angriffe auf die Kommunikation auf der + Nachrichtenebene} + + \begin{itemize} + \item + Passive Angriffe + + \begin{itemize} + \item + Lauschangriff + \end{itemize} + \item + Aktive Angriffe + + \begin{itemize} + \item + Verzögerung von PDUs (Protocol Data Units) + \item + Wiederholung von PDUs + \item + Löschung von PDUs + \item + Modifikation von PDUs + \item + Einfügung von PDUs + \end{itemize} + \item + Die erfolgreiche Durchführung eines der oben genannten Angriffe + erfordert + + \begin{itemize} + \item + Es gibt keine erkennbaren Nebeneffekte auf andere Kommunikationen + (Verbindungen/verbindungslose Übertragungen) + \item + Es gibt keine Nebenwirkungen auf andere PDUs der gleichen + Verbindung/verbindungslosen Datenübertragung zwischen den gleichen + Entitäten + \end{itemize} + \item + Eine Sicherheitsanalyse einer Protokollarchitektur muss diese Angriffe + entsprechend den Schichten der Architektur analysieren + \end{itemize} + + + \subsection{Schutzmaßnahmen gegen Bedrohungen der + Informationssicherheit} + + \begin{itemize} + \item + Physische Sicherheit + + \begin{itemize} + \item + Schlösser oder andere physische Zugangskontrollen + \item + Manipulationssicherung empfindlicher Geräte + \item + Umweltkontrollen + \end{itemize} + \item + Personelle Sicherheit + + \begin{itemize} + \item + Identifizierung von sensiblen Positionen + \item + Verfahren zur Überprüfung der Mitarbeiter + \item + Sicherheitsschulung und -bewusstsein + \end{itemize} + \item + Administrative Sicherheit + + \begin{itemize} + \item + Kontrolle des Imports von Fremdsoftware + \item + Verfahren zur Untersuchung von Sicherheitsverstößen + \item + Überprüfung von Prüfpfaden + \item + Überprüfung von Kontrollen der Rechenschaftspflicht + \end{itemize} + \item + Strahlungssicherheit + + \begin{itemize} + \item + Kontrolle von Funkfrequenzen und anderen elektromagnetischen + Abstrahlungen + \item + Bezeichnet als TEMPEST-Schutz + \end{itemize} + \item + Mediensicherheit + + \begin{itemize} + \item + Absicherung der Speicherung von Informationen + \item + Kontrolle der Kennzeichnung, Vervielfältigung und Vernichtung von + sensiblen Informationen + \item + Sicherstellen, dass Medien mit sensiblen Informationen sicher + vernichtet werden + \item + Scannen von Medien auf Viren + \end{itemize} + \item + Lebenszyklus-Kontrollen + + \begin{itemize} + \item + Vertrauenswürdiger Systementwurf, -implementierung, -bewertung und + -übernahme + \item + Programmierstandards und -kontrollen + \item + Kontrollen der Dokumentation + \end{itemize} + \item + Computer-Sicherheit + + \begin{itemize} + \item + Schutz von Informationen während der Speicherung/Verarbeitung in + einem Computersystem + \item + Schutz der Datenverarbeitungsgeräte selbst + \end{itemize} + \item + Sicherheit der Kommunikation + + \begin{itemize} + \item + Schutz von Informationen während des Transports von einem System zu + einem anderen + \item + Schutz der Kommunikationsinfrastruktur selbst + \end{itemize} + \end{itemize} + + + \subsection{Kommunikationssicherheit: Einige + Terminologie} + + \begin{itemize} + \item + Sicherheitsdienst + + \begin{itemize} + \item + Ein abstrakter Dienst, der eine bestimmte Sicherheitseigenschaft + gewährleisten soll. + \item + Ein Sicherheitsdienst kann sowohl mit Hilfe von kryptografischen + Algorithmen und Protokollen als auch mit herkömmlichen Mitteln + realisiert werden + + \begin{itemize} + \item + Man kann ein elektronisches Dokument auf einem USB-Stick + vertraulich halten, indem man es in einem verschlüsselten Format + auf dem Datenträger speichert und den Datenträger in einem Tresor + wegschließt. + \item + In der Regel ist eine Kombination aus kryptografischen und anderen + Mitteln am effektivsten + \end{itemize} + \end{itemize} + \item + Kryptographischer Algorithmus + + \begin{itemize} + \item + Eine mathematische Umwandlung von Eingabedaten (z. B. Daten, + Schlüssel) in Ausgabedaten + \item + Kryptografische Algorithmen werden in kryptografischen Protokollen + verwendet. + \end{itemize} + \item + Kryptografisches Protokoll + + \begin{itemize} + \item + Eine Reihe von Schritten und der Austausch von Nachrichten zwischen + mehreren Einheiten, um ein bestimmtes Sicherheitsziel zu erreichen + \end{itemize} + \end{itemize} + + + \subsection{Sicherheitsdienste - + Überblick} + + \begin{itemize} + \item + \textbf{Authentifizierung (Authentication)} + + \begin{itemize} + \item + Der grundlegendste Sicherheitsdienst, der sicherstellt, dass eine + Entität tatsächlich die Identität besitzt, die sie vorgibt zu haben + \end{itemize} + \item + \textbf{Integrität (Integrity)} + + \begin{itemize} + \item + In gewisser Weise der "kleine Bruder" des + Authentifizierungsdienstes, da er sicherstellt, dass Daten, die von + bestimmten Entitäten erstellt wurden, nicht unentdeckt verändert + werden können + \end{itemize} + \item + \textbf{Vertraulichkeit (Confidentiality)} + + \begin{itemize} + \item + Der beliebteste Sicherheitsdienst, der die Geheimhaltung der + geschützten Daten gewährleistet + \end{itemize} + \item + \textbf{Zugriffskontrolle (Access Control)} + + \begin{itemize} + \item + Kontrolliert, dass jede Identität nur auf die Dienste und + Informationen zugreift, zu denen sie berechtigt ist + \end{itemize} + \item + \textbf{Nicht-Abstreitbarkeit (Non Repudiation)} + + \begin{itemize} + \item + Schützt davor, dass an einem Kommunikationsaustausch beteiligte + Entitäten später fälschlicherweise abstreiten können, dass der + Austausch stattgefunden hat + \end{itemize} + \end{itemize} + + + \subsection{Sicherheitsunterstützende + Mechanismen} + + \begin{itemize} + \item + Allgemeine Mechanismen + + \begin{itemize} + \item + Schlüsselverwaltung: Alle Aspekte des Lebenszyklus von + kryptografischen Schlüsseln + \item + Zufallszahlengenerierung: Generierung von kryptographisch sicheren + Zufallszahlen + \item + Ereigniserkennung / Sicherheitsprüfpfad: Erkennung und Aufzeichnung + von Ereignissen, die zur Erkennung von Angriffen oder Bedingungen, + die von Angriffen ausgenutzt werden könnten, verwendet werden können + \item + Erkennung von Eindringlingen: Analyse der aufgezeichneten + Sicherheitsdaten, um erfolgreiche Einbrüche oder Angriffe zu + erkennen + \item + Beglaubigung: Registrierung von Daten durch eine vertrauenswürdige + dritte Partei, die später bestimmte Eigenschaften (Inhalt, + Ersteller, Erstellungszeitpunkt) der Daten bestätigen kann + \end{itemize} + \item + Kommunikationsspezifische Mechanismen + + \begin{itemize} + \item + Traffic Padding \& Cover Traffic: Erzeugung von gefälschtem Verkehr, + um die Analyse des Verkehrsflusses zu verhindern + \item + Routing-Kontrolle: Beeinflussung des Routings von PDUs in einem + Netzwerk + \end{itemize} + \end{itemize} + + + \subsection{Kryptologie - Definition und + Terminologie} + + \begin{itemize} + \item + Kryptologie + + \begin{itemize} + \item + Wissenschaft, die sich mit sicherer und meist geheimer Kommunikation + beschäftigt + \item + Der Begriff leitet sich von den griechischen Wörtern kryptós + (verborgen) und lógos (Wort) ab. + \item + Kryptologie umfasst + + \begin{itemize} + \item + Kryptographie ( gráphein = schreiben): die Lehre von den + Prinzipien und Techniken, mit denen Informationen in + verschlüsseltem Text verborgen und später von legitimen Nutzern + mit Hilfe eines geheimen Schlüssels offengelegt werden können + \item + Kryptoanalyse ( analýein = lýsen, losbinden): die Wissenschaft + (und Kunst) der Wiedergewinnung von Informationen aus Chiffren + ohne Kenntnis des Schlýssels + \end{itemize} + \end{itemize} + \item + Chiffre (Quelle Encyclopaedia Britannica) + + \begin{itemize} + \item + Methode zur Umwandlung einer Nachricht (Klartext), um ihre Bedeutung + zu verschleiern + \item + Wird auch als Synonym für den verborgenen Chiffretext verwendet. + \item + Chiffren sind eine Klasse von kryptografischen Algorithmen + \item + Die Umwandlung erfolgt in der Regel mit der Nachricht und einem + (geheimen) Schlüssel als Eingabe + \end{itemize} + \end{itemize} + + + \subsection{Kryptologie - einige historische + Anmerkungen} + + \begin{itemize} + \item + 400 v. Chr.: Die Spartaner verwenden ein Chiffriergerät namens Scytale + für die Kommunikation zwischen militärischen Befehlshabern. + + \begin{itemize} + \item + Die Scytale bestand aus einem spitz zulaufenden Stab, um den + spiralförmig ein Streifen Pergament oder Leder gewickelt war, auf + den die Nachricht geschrieben wurde + \item + Beim Aufwickeln wurden die Buchstaben der Reihe nach durcheinander + gewürfelt und bildeten die Chiffre. + \item + Wurde der Streifen um einen anderen Stab mit den gleichen + Proportionen wie das Original gewickelt, kam der Klartext wieder zum + Vorschein + \end{itemize} + \item + Im 4. Jahrhundert v. Chr: + + \begin{itemize} + \item + Aeneas Tacticus (Grieche) schreibt "Über die Verteidigung von + Festungen", wobei ein Kapitel der Kryptographie gewidmet ist + \item + Polybius (Grieche) erfindet eine Methode zur Kodierung von + Buchstaben in Symbolpaaren mit Hilfe eines Geräts namens + Polybius-Schachbrett, das eine bi-literale Substitution ermöglicht + und viele Elemente späterer Kryptosysteme vorwegnimmt + \end{itemize} + \item + Die Römer verwendeten eine monoalphabetische Substitution mit + einfacher zyklischer Verschiebung des Alphabets: + + \begin{itemize} + \item + Julius Caesar verwendete eine Verschiebung von drei Buchstaben (A + ergibt D, ..., Z ergibt C) + \item + Augustus Caesar verwendete eine einzige Verschiebung (A ergibt B, + ...) + \end{itemize} + \item + Die Araber waren die ersten, die die Prinzipien der Kryptographie + verstanden und die Anfänge der Kryptoanalyse entdeckten: + + \begin{itemize} + \item + Entwurf und Verwendung von Substitutions- und + Transpositions-Chiffren + \item + Entdeckung der Verwendung von Buchstabenhäufigkeitsverteilungen und + wahrscheinlichen Klartexten in der Kryptoanalyse + \item + Bis 1412 n. Chr. enthält Al-Kalka-Shandi in seiner Enzyklopädie Subh + al-a'sha eine elementare und respektable Behandlung mehrerer + kryptographischer Systeme und ihrer Kryptoanalyse + \end{itemize} + \item + Europäische Kryptographie: + + \begin{itemize} + \item + Die Entwicklung begann im Kirchenstaat und in den italienischen + Stadtstaaten im Mittelalter + \item + Die ersten Chiffren verwendeten nur Vokalsubstitutionen + \item + 1397: Gabriele de Lavinde von Parma verfasst das erste europäische + Handbuch zur Kryptographie, das eine Zusammenstellung von Chiffren + sowie eine Reihe von Schlüsseln für 24 Korrespondenten enthält und + Symbole für Buchstaben, Zahlen und mehrere zweistellige + Codeäquivalente für Wörter und Namen umfasst + \item + Code-Vokabulare, Nomenklatoren genannt, wurden für mehrere + Jahrhunderte zur Hauptstütze der diplomatischen Kommunikation der + meisten europäischen Regierungen + \item + 1470: Leon Battista Alberti veröffentlicht Trattati In Cifra, in + denen er die erste Chiffrierscheibe beschreibt und bereits + vorschreibt, die Scheibe regelmäßig neu einzustellen, wobei er den + Begriff der Polyalphabetizität entwickelt + \item + 1563: Giambattista della Porta liefert eine abgewandelte Form einer + quadratischen Tabelle und das früheste Beispiel einer digraphischen + Chiffre (2-Buchstaben-Substitution) + \item + 1586: Blaise de Vigenère veröffentlicht Traicté des chiffres, das + die ihm zugeschriebene quadratische Tabelle enthält + \item + Bis 1860 wurden große Codes für die diplomatische Kommunikation + verwendet, und Chiffren wurden nur in der militärischen + Kommunikation eingesetzt (außer auf hoher Kommandoebene), da es + schwierig war, Codebücher im Feld zu schützen. + \end{itemize} + \item + Entwicklungen während der Weltkriege 1 und 2: + + \begin{itemize} + \item + Während des 1. Weltkriegs: Chiffriersysteme wurden hauptsächlich für + die taktische Kommunikation verwendet und die Kommunikation auf + hoher Ebene wurde durch Codes geschützt. + \item + 1920: Die Kommunikationsbedürfnisse der Telekommunikation und die + Weiterentwicklung der elektromechanischen Technik führen zu einer + wahren Revolution bei den Verschlüsselungsgeräten - der Entwicklung + von Rotor-Chiffriermaschinen: + + \begin{itemize} + \item + Das Rotorprinzip wird unabhängig voneinander von E. E. Hebern + (USA), H. A. Koch (Niederlande) und A. Scherbius (Deutschland) + entdeckt + \item + Rotor-Chiffriermaschinen kaskadieren eine Sammlung von + Chiffrierscheiben, um eine polyalphabetische Substitution von + hoher Komplexität zu realisieren + \item + Die Kryptoanalyse der taktischen Kommunikation spielt während des + Zweiten Weltkriegs eine sehr wichtige Rolle. Die größten Erfolge + sind die britische und polnische Lösung der deutschen Enigma- und + der beiden Fernschreiber-Chiffren sowie die amerikanische + Kryptoanalyse der japanischen Chiffren. + \end{itemize} + \end{itemize} + \item + Entwicklungen nach dem 2. Weltkrieg: + + \begin{itemize} + \item + Die moderne Elektronik ermöglicht noch komplexere Chiffren, die + zunächst den Rotorprinzipien folgen (und deren Schwächen + einbeziehen) + \item + Die meisten Informationen über elektronische Chiffriermaschinen, die + von verschiedenen nationalen Kryptodiensten verwendet wurden, sind + nicht öffentlich zugänglich. + \item + Ende der 1960er Jahre war die kommerziell verfügbare Kryptographie + kaum bekannt, und starke Kryptographie war den nationalen Behörden + vorbehalten + \item + 1973-1977: Entwicklung des Data Encryption Standard (DES) + \item + 1976-1978: Entdeckung der Public-Key-Kryptografie + \item + 1976: W. Diffie und M. Hellman veröffentlichen "New Directions in + Cryptography" (Neue Wege in der Kryptographie), in dem sie die + Konzepte der Public-Key-Kryptographie einführen und ein Verfahren + zum Austausch von Schlüsseln über unsichere Kanäle beschreiben. + \item + R. Merkle entdeckt unabhängig das Prinzip des öffentlichen + Schlüssels, seine ersten Veröffentlichungen erscheinen jedoch erst + 1978, da der Veröffentlichungsprozess langsam ist + \item + 1978: R. L. Rivest, A. Shamir und A. M. Adleman veröffentlichen "A + Method for Obtaining Digital Signatures and Public Key + Cryptosystems", das den ersten funktionierenden und sicheren + Public-Key-Algorithmus RSA enthält + \end{itemize} + \end{itemize} + + + \section{Grundlagen der + Kryptographie} + + \begin{itemize} + \item + Überblick über kryptografische Algorithmen + \item + Angriffe auf die Kryptographie + \item + Eigenschaften von Verschlüsselungsalgorithmen + \item + Klassifizierung von Verschlüsselungsalgorithmen + \end{itemize} + + + \subsection{Kryptographische Algorithmen: + Überblick} + + \begin{itemize} + \item + In diesem Kurs stehen zwei Hauptanwendungen kryptographischer + Algorithmen im Mittelpunkt des Interesses + + \begin{itemize} + \item + Verschlüsselung von Daten: Umwandlung von Klartextdaten in + Chiffretext, um deren Bedeutung zu verbergen + \item + Signierung von Daten: Berechnung eines Prüfwerts oder einer + digitalen Signatur für einen gegebenen Klartext oder Geheimtext, der + von einigen oder allen Stellen, die auf die signierten Daten + zugreifen können, überprüft werden kann + \end{itemize} + \item + Einige kryptografische Algorithmen können für beide Zwecke verwendet + werden, andere sind nur für einen der beiden Zwecke sicher und/oder + effizient. + \item + Hauptkategorien von kryptografischen Algorithmen + + \begin{itemize} + \item + Symmetrische Kryptografie, die 1 Schlüssel für die + Ver-/Entschlüsselung oder die Signierung/Prüfung verwendet + \item + Asymmetrische Kryptografie mit 2 verschiedenen Schlüsseln für die + Ver-/Entschlüsselung oder die Unterzeichnung/Prüfung + \item + Kryptografische Hash-Funktionen mit 0 Schlüsseln (der "Schlüssel" + ist keine separate Eingabe, sondern wird an die Daten "angehängt" + oder mit ihnen "vermischt"). + \end{itemize} + \end{itemize} + + + \subsection{Angriff auf die + Kryptographie} + + + \subsection{Kryptoanalyse} + + \begin{itemize} + \item + Kryptoanalyse ist der Versuch, den Klartext und/oder den Schlüssel + herauszufinden. + \item + Arten der Kryptoanalyse + + \begin{itemize} + \item + Nur Chiffretext: bestimmte Muster des Klartextes können im + Chiffretext erhalten bleiben (Häufigkeit von Buchstaben, Digraphen + usw.) + \item + Bekannte Chiffretext-Klartext-Paare + \item + Gewählter Klartext oder gewählter Chiffretext + \item + Differentielle Kryptoanalyse und lineare Kryptoanalyse + \item + Neuere Entwicklung: verwandte Schlüsselanalyse + \end{itemize} + \item + Kryptoanalyse der Public-Key-Kryptographie + + \begin{itemize} + \item + Die Tatsache, dass ein Schlüssel öffentlich zugänglich ist, kann + ausgenutzt werden + \item + Die Kryptoanalyse öffentlicher Schlüssel zielt eher darauf ab, das + Kryptosystem selbst zu knacken und ist näher an der reinen + mathematischen Forschung als an der klassischen Kryptoanalyse. + \item + Wichtige Richtungen + + \begin{itemize} + \item + Berechnung von diskreten Logarithmen + \item + Faktorisierung von großen ganzen Zahlen + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsubsection{Brute-Force-Angriff} + + \begin{itemize} + \item + Der Brute-Force-Angriff probiert alle möglichen Schlüssel aus, bis er + einen verständlichen Klartext findet + + \begin{itemize} + \item + Jeder kryptographische Algorithmus kann theoretisch mit Brute Force + angegriffen werden + \item + Im Durchschnitt muss die Hälfte aller möglichen Schlüssel + ausprobiert werden + \end{itemize} + \end{itemize} + + Durchschnittlich benötigte Zeit für erschöpfende Schlüsselsuche + + %\begin{longtable}[]{@{}llll@{}} + % \toprule + % Schlüsselgröße {[}bit{]} & Anzahl der Schlüssel & Benötigte Zeit bei 1 + % \$Verschlüsselung/\textbackslash mu\$s & Zeitbedarf bei 10\^{}6 + % Verschlüsselung /\$\textbackslash mu\$s\tabularnewline + % \midrule + % \endhead + % 56 & \$2\^{}\{56\} = 7,2\textbackslash times 10\^{}\{16\}\$ & + % \$2\^{}\{55\}\textbackslash mu s = 1142\$ Jahre & \$10,01\$ + % Stunden\tabularnewline + % 128 & \$2\^{}\{128\} = 3,4 x 10\^{}\{38\}\$ & + % \$2\^{}\{127\}\textbackslash mu s = 5,4 x 10\^{}\{24\}\$ Jahre & \$5,4 x + % 10\^{}\{18\}\$ Jahre\tabularnewline + % 256 & \$2\^{}\{256\} = 1.2 x 10\^{}\{77\} & + % \$2\^{}\{255\}\textbackslash mu s = 3,7 x 10\^{}\{63\}\$ Jahre & \$3,7 x + % 10\^{}\{57\}\$ Jahre\tabularnewline + % \bottomrule + %\end{longtable} + + + \subsubsection{Wie groß ist groß?} + + Referenzzahlen zum Vergleich relativer Größenordnungen \textbar{} + Referenz \textbar{} Größe \textbar{} \textbar{} + -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- + \textbar{} + -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- + \textbar{} \textbar{} Sekunden in einem Jahr \textbar{} ca. \$3 x + 10\^{}7\$ \textbar{} \textbar{} Sekunden seit der Entstehung des + Sonnensystems \textbar{} ca. \$2 x 10\^{}\{17\}\$ \textbar{} \textbar{} + Taktzyklen pro Jahr (50 MHz Computer) \textbar{} ca. \$1,6 x + 10\^{}\{15\}\$ \textbar{} \textbar{} Binäre Zeichenketten der Länge 64 + \textbar{} \$2\^{}\{64\}\$ ca. \$1,8 x 10\^{}\{19\}\$ \textbar{} + \textbar{} Binäre Zeichenfolgen der Länge 128 \textbar{} + \$2\^{}\{128\}\$ ca. \$3,4 x 10\^{}\{38\}\$ \textbar{} \textbar{} Binäre + Zeichenfolgen der Länge 256 \textbar{} \$2\^{}\{256\}\$ ca. \$1,2 x + 10\^{}\{77\}\$ \textbar{} \textbar{} Anzahl der 75-stelligen Primzahlen + \textbar{} \$5,2 x 10\^{}\{72\}\$ \textbar{} \textbar{} Elektronen im + Universum \textbar{} \$8,37 x 10\^{}\{77\}\$ \textbar{} + + + \subsubsection{Wichtige Eigenschaften von + Verschlüsselungsalgorithmen} + + Nehmen wir an, ein Absender verschlüsselt Klartextnachrichten \$P\_1, + P\_2, ...\$ zu Chiffretextnachrichten \$C\_1, C\_2, ...\$ + + Dann sind die folgenden Eigenschaften des Verschlüsselungsalgorithmus + von besonderem Interesse + + \begin{itemize} + \item + Die Fehlerfortpflanzung charakterisiert die Auswirkungen von + Bit-Fehlern bei der Übertragung von Chiffretext zu rekonstruiertem + Klartext \$P\_1', P\_2', ...\$ + + \begin{itemize} + \item + Je nach Verschlüsselungsalgorithmus können pro fehlerhaftem + Chiffretext-Bit ein oder mehrere fehlerhafte Bits im rekonstruierten + Klartext vorhanden sein + \end{itemize} + \item + Die Synchronisierung charakterisiert die Auswirkungen verlorener + Chiffretext-Dateneinheiten auf den rekonstruierten Klartext + + \begin{itemize} + \item + Einige Verschlüsselungsalgorithmen können sich nicht von verlorenem + Chiffretext erholen und benötigen daher eine explizite + Neusynchronisierung im Falle verlorener Nachrichten + \item + Andere Algorithmen führen eine automatische Neusynchronisierung nach + 0 bis n (n je nach Algorithmus) Chiffretextbits durch. + \end{itemize} + \end{itemize} + + + \subsection{Klassifizierung von Verschlüsselungsalgorithmen: Drei + Dimensionen} + + \begin{itemize} + \item + Die Art der Operationen, die zur Umwandlung von Klartext in + Chiffretext verwendet werden + + \begin{itemize} + \item + Substitution, die jedes Element des Klartextes (Bit, Buchstabe, + Gruppe von Bits oder Buchstaben) in ein anderes Element umwandelt + \item + Transposition, die die Elemente des Klartextes neu anordnet + \end{itemize} + \item + Die Anzahl der verwendeten Schlüssel + + \begin{itemize} + \item + Symmetrische Chiffren, die denselben Schlüssel für die Ver- und + Entschlüsselung verwenden + \item + Asymmetrische Chiffren, bei denen unterschiedliche Schlüssel für die + Ver- und Entschlüsselung verwendet werden + \end{itemize} + \item + Die Art und Weise, in der der Klartext verarbeitet wird + + \begin{itemize} + \item + Stromchiffren arbeiten mit Bitströmen und verschlüsseln ein Bit nach + dem anderen + + \begin{itemize} + \item + Viele Stromchiffren basieren auf der Idee der linearen + rückgekoppelten Schieberegister, und bei vielen Algorithmen dieser + Klasse wurden Schwachstellen entdeckt, da es eine tiefgreifende + mathematische Theorie zu diesem Thema gibt. + \item + Die meisten Stromchiffren verbreiten keine Fehler, sind aber + anfällig für den Verlust der Synchronisation. + \end{itemize} + \item + Blockchiffren arbeiten mit Blöcken der Breite b, wobei b vom + jeweiligen Algorithmus abhängt. + \end{itemize} + \end{itemize} + + + \subsection{Kryptographische Algorithmen - + Überblick} + + Kryptografische Algorithmen + + \begin{itemize} + \item + Überblick + + \begin{itemize} + \item + Eigenschaften + \item + Kryptoanalyse + \end{itemize} + \item + Symmetrische Ver-/Entschlüsselung + + \begin{itemize} + \item + Funktionsweisen + \item + DES + \item + AES + \item + RC4 + \item + KASUMI + \end{itemize} + \item + Asymmetrische Ver-/Entschlüsselung + + \begin{itemize} + \item + Hintergrund + \item + RSA + \item + Diffie-Hellman + \item + ElGamal + \item + ECC + \end{itemize} + \item + Kryptographische Hash-Funktionen + + \begin{itemize} + \item + MDCs/MACs + \item + MD + \item + SHA-1/2/ + \item + CBC-MAC + \item + GCM-MAC + \end{itemize} + \end{itemize} + + + \section{Symmetrische Kryptographie} + + \begin{itemize} + \item + Modi der Verschlüsselung + \item + Datenverschlüsselungsstandard (DES) + \item + Erweiterter Verschlüsselungsstandard (AES) + \item + Die Blockchiffre RC + \item + KASUMI + \end{itemize} + + + \subsection{Symmetrische + Verschlüsselung} + + \begin{itemize} + \item + Allgemeine Beschreibung + + \begin{itemize} + \item + Derselbe Schlüssel KA,B wird für die Verschlüsselung und + Entschlüsselung von Nachrichten verwendet + \end{itemize} + \item + Schreibweise + + \begin{itemize} + \item + Wenn P die Klartextnachricht bezeichnet, bezeichnet \$E(K\_\{A,B\}, + P)\$ den Chiffretext und es gilt \$D(K\_\{A,B\}, E(K\_\{A,B\}, P)) = + P\$ + \item + Alternativ schreibt man manchmal \$\{P\}\emph{\{K}\{A,B\}\}\$ oder + \$E\_\{K\_\{A,B\}\}(P)\$ für \$E(K\_\{A,B\}, P)\$ + \end{itemize} + \item + Beispiele: DES, 3DES, AES, ... + \end{itemize} + + + \subsection{Symmetrische Blockchiffren - + Verschlüsselungsarten} + + Allgemeine Bemerkungen \& Notation + + \begin{itemize} + \item + Ein Klartext P wird in Blöcke \$P\_1, P\_2, ...\$ der Länge b bzw. j + zerlegt, wobei b die Blockgröße des Verschlüsselungsalgorithmus + bezeichnet und j \textless{} b + \item + Der Chiffretext C ist die Kombination von \$C\_1, C\_2, ...\$, wobei + \$c\_i\$ das Ergebnis der Verschlüsselung des i-ten Blocks der + Klartextnachricht bezeichnet + \item + Die Stellen, die eine Nachricht verschlüsseln und entschlüsseln, haben + sich auf einen Schlüssel K geeinigt. + \end{itemize} + + Elektronischer Codebuch-Modus (Electronic Code Book Mode: ECB) + + \begin{itemize} + \item + Jeder Block Pi der Länge b wird unabhängig verschlüsselt: \$C\_i = + E(K, p\_i)\$ + \item + Ein Bitfehler in einem Chiffretextblock \$C\_i\$ führt zu einem völlig + falsch wiederhergestellten Klartextblock \$P\_i'\$ + \item + Der Verlust der Synchronisation hat keine Auswirkungen, wenn + ganzzahlige Vielfache der Blockgröße b verloren gehen. Geht eine + andere Anzahl von Bits verloren, ist eine explizite Neusynchronisation + erforderlich. + \item + Nachteil: identische Klartextblöcke werden zu identischem Chiffretext + verschlüsselt! + \item + % \includegraphics{Assets/NetworkSecurity-electronic-code-book-mode.png} + \end{itemize} + + Cipher Block Chaining Modus (Cipher Block Chaining Mode: CBC) + + \begin{itemize} + \item + Vor der Verschlüsselung eines Klartextblocks pi wird dieser mit dem + vorangegangenen Chiffretextblock \$C\_\{i-1\}\$ XOR-verknüpft () + + \begin{itemize} + \item + \$C\_i = E(K, C\_\{i-1\} \textbackslash oplus p\_i)\$ + \item + \$P\_\{i'\} = C\_\{i-1\} \textbackslash oplus D(K, C\_i)\$ + \item + Um \$C\_1\$ zu berechnen, einigen sich beide Parteien auf einen + Anfangswert (IV) für \$C\_0\$ + \end{itemize} + \item + Eigenschaften + + \begin{itemize} + \item + Fehlerfortpflanzung: Ein verfälschter Chiffretextblock führt zu zwei + verfälschten Klartextblöcken, da \$P\_i'\$ mit \$C\_\{i-1\}\$ und + \$C\_i\$ berechnet wird + \item + Synchronisation: Wenn die Anzahl der verlorenen Bits ein + ganzzahliges Vielfaches von b ist, wird ein zusätzlicher Block + \$P\_\{i+1\}\$ verzerrt, bevor die Synchronisation wiederhergestellt + wird. Wenn eine andere Anzahl von Bits verloren geht, ist eine + explizite Neusynchronisation erforderlich. + \item + Vorteil: identische Klartextblöcke werden zu nicht-identischem + Chiffretext verschlüsselt. + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-cipher-block-chaining-mode.png} + \end{itemize} + + Chiffretext-Feedback-Modus (Ciphertext Feedback Mode: CFB) + + \begin{itemize} + \item + Ein Blockverschlüsselungsalgorithmus, der mit Blöcken der Größe b + arbeitet, kann in einen Algorithmus umgewandelt werden, der mit + Blöcken der Größe \$j (j\textless b)\$ arbeitet. + + \begin{itemize} + \item + \$S(j, x)\$ bezeichnen die \$j\$ höherwertigen Bits von \$x\$ + \item + \$P\_i\$, \$C\_i\$ den \$i\$-ten Block von Klartext und Geheimtext + der Länge \$j\$ bezeichnen + \item + IV ist ein Anfangswert, auf den sich beide Parteien geeinigt haben + \item + \$R\_1 = IV\$ + \item + \$R\_n = (R\_\{n-1\}*2\^{}j\textbackslash{} mod\textbackslash{} + 2\^{}b)\textbackslash oplus C\_\{n-1\}\$ + \item + \$C\_n = S(j,E\_K(R\_n))\textbackslash oplus P\_n\$ + \item + \$S(j,E\_K(R\_n))\textbackslash oplus C\_n = + S(j,E\_K(R\_n))\textbackslash oplus + S(j,E\_K(R\_n))\textbackslash oplus P\_n\$ + \item + \$S(j,E\_K(R\_n))\textbackslash oplus C\_n = P\_n\$ + \end{itemize} + \item + Ein gängiger Wert für j ist 8 für die Verschlüsselung von einem + Zeichen pro Schritt + \item + Eigenschaften von CFB + + \begin{itemize} + \item + Fehlerfortpflanzung: Da die Chiffretextblöcke schrittweise durch das + Register geschoben werden, verfälscht ein fehlerhafter Block + \$C\_i\$ den wiederhergestellten Klartextblock \$P\_i'\$ sowie die + folgenden \$\textbackslash lceil b / j\textbackslash rceil\$-Blöcke + \item + Synchronisation: Wenn die Anzahl der verlorenen Bits ein + ganzzahliges Vielfaches von j ist, werden \$\textbackslash lceil b / + j\textbackslash rceil\$ zusätzliche Blöcke verfälscht, bevor die + Synchronisation wiederhergestellt ist. Wenn eine beliebige andere + Anzahl von Bits verloren geht, ist eine explizite + Neusynchronisierung erforderlich. + \item + Nachteil: Die Verschlüsselungsfunktion E muss häufiger berechnet + werden, da eine Verschlüsselung von b Bit durchgeführt werden muss, + um j Bit des Klartextes zu verbergen. Beispiel: Bei Verwendung von + DES mit Verschlüsselung von jeweils einem Zeichen + \$\textbackslash Rightarrow\$ muss die Verschlüsselung 8-mal + häufiger durchgeführt werden + \end{itemize} + \end{itemize} + + Output-Feedback-Modus (OFB) + + \begin{itemize} + \item + Der Blockverschlüsselungsalgorithmus wird zur Erzeugung einer + Pseudozufallsfolge \$R\_i\$ verwendet, die nur von \$K\$ und \$IV\$ + abhängt. + + \begin{itemize} + \item + \$S(j, x)\$ bezeichnen die \$j\$ höherwertigen Bits von \$x\$ + \item + \$P\_i\$, \$C\_i\$ bezeichnen den \$i\$-ten Block von Klartext und + Chiffretext der Länge \$j\$ + \item + \$IV\$ sei ein Anfangswert, auf den sich beide Parteien geeinigt + haben + \item + \$R\_1 = IV\$ + \item + \$R\_n = (R\_\{n-1\}* 2\^{}j\textbackslash{} mod\textbackslash{} + 2\^{}b )\textbackslash oplus S(j,E\_K(R\_\{n-1\}))\$ // j-bit + Linksverschiebung + verschlüsselter alter Wert + \item + \$C\_n = S(j,E\_K(R\_n))\textbackslash oplus P\_n\$ + \item + \$S(j,E\_K(R\_n))\textbackslash oplus C\_n = + S(j,E\_K(R\_n))\textbackslash oplus + S(j,E\_K(R\_n))\textbackslash oplus P\_n\$ + \item + \$S(j,E\_K(R\_n))\textbackslash oplus C\_n = P\_n\$ + \end{itemize} + \item + Der Klartext wird mit der Pseudo-Zufallssequenz XOR-verknüpft, um den + Chiffretext zu erhalten und umgekehrt + \item + Eigenschaften von OFB + + \begin{itemize} + \item + Fehlerfortpflanzung: Einzelbitfehler führen nur zu Einzelbitfehlern + \$\textbackslash rightarrow\$ keine Fehlermultiplikation + \item + Synchronisierung: Wenn einige Bits verloren gehen, ist eine + explizite Re-Synchronisation erforderlich. + \item + Vorteil: Die Pseudo-Zufallsfolge kann vorberechnet werden, um die + Auswirkungen der Verschlüsselung auf die Ende-zu-Ende-Verzögerung + gering zu halten + \item + Nachteile + + \begin{itemize} + \item + Wie bei CFB muss die Verschlüsselungsfunktion E häufiger berechnet + werden, da eine Verschlüsselung von b Bit durchgeführt werden + muss, um j Bit des Klartextes zu verbergen + \item + Es ist für einen Angreifer möglich, bestimmte Bits des Klartextes + zu manipulieren + \end{itemize} + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-output-feedback-mode.png} + \end{itemize} + + Algorithmus-Übersicht + + \begin{itemize} + \item + Datenverschlüsselungsstandard (DES) + + \begin{itemize} + \item + Alter amerikanischer Standard aus den 70er Jahren + \item + Unsicher wegen der Schlüssel- und Blocklänge + \item + Grundlegender Aufbau + \item + Dreifache Verschlüsselung mit einer Blockchiffre, z.B. Triple-DES + \end{itemize} + \item + Erweiterter Verschlüsselungsstandard (AES) + + \begin{itemize} + \item + Offener Standardisierungsprozess mit internationaler Beteiligung + \item + Im Oktober 2000 wurde ein Algorithmus namens Rijndael für AES + vorgeschlagen + \item + Ankündigung des AES-Standards im November 2001 + \item + Siehe auch \href{http://www.nist.gov/aes/}{http://www.nist.gov/aes/} + \end{itemize} + \item + Andere populäre Algorithmen + + \begin{itemize} + \item + RC + \item + KASUMI + \end{itemize} + \end{itemize} + + + \subsection{Der Datenverschlüsselungsstandard + (DES)} + + Geschichte + + \begin{itemize} + \item + 1973 veröffentlichte das National Bureau of Standards (NBS, heute + National Institute of Standards and Technology, NIST) eine + Aufforderung zur Einreichung von Vorschlägen für einen nationalen + Verschlüsselungsstandard und forderte von dem Algorithmus, dass er + + \begin{itemize} + \item + ein hohes Maß an Sicherheit bieten, + \item + vollständig spezifiziert und leicht zu verstehen sein, + \item + Sicherheit nur durch seinen Schlüssel und nicht durch seine eigene + Geheimhaltung bieten, + \item + für alle Benutzer verfügbar sein, + \item + für den Einsatz in verschiedenen Anwendungen anpassbar sein, + \item + wirtschaftlich in elektronischen Geräten implementierbar sein, + \item + effizient in der Anwendung sein, + \item + validiert werden können und + \item + exportierbar sein. + \end{itemize} + \item + Keine der Einreichungen auf diese erste Aufforderung erfüllte diese + Kriterien auch nur annähernd. + \item + Auf eine zweite Aufforderung hin reichte IBM seinen Algorithmus + LUCIFER ein, eine symmetrische Blockchiffre, die mit Blöcken der Länge + 128 Bit unter Verwendung von Schlüsseln der Länge 128 Bit arbeitet; + dies war der einzige vielversprechende Kandidat. + \item + Die NBS bat die National Security Agency (NSA) um Hilfe bei der + Bewertung der Sicherheit des Algorithmus + + \begin{itemize} + \item + Die NSA reduzierte die Blockgröße auf 64 Bit, die Größe des + Schlüssels auf 56 Bit und änderte Details in den + Substitutionsfeldern des Algorithmus. + \item + Viele der Gründe der NSA für diese Änderungen wurden erst in den + frühen 1990er Jahren deutlich, lösten aber in den späten 1970er + Jahren große Besorgnis aus. + \end{itemize} + \item + Trotz aller Kritik wurde der Algorithmus 1977 als ,,Data Encryption + Standard'' in die Reihe der Federal Information Processing Standards + (FIPS PUB 46) aufgenommen und für die Verwendung in der gesamten nicht + klassifizierten Regierungskommunikation zugelassen. + \item + DES hat sich in den folgenden Jahren weithin durchgesetzt + \end{itemize} + + % \includegraphics{Assets/NetworkSecurity-des-algorithm.png} + + % \includegraphics{Assets/NetworkSecurity-des-single-iteration.png} + + + \subsubsection{DES - Einzelne + Iteration} + + \begin{itemize} + \item + Die rechten 32 Bit der zu verschlüsselnden Daten werden mit Hilfe + einer Expansions-/Permutationstabelle auf 48 Bit erweitert. + \item + Sowohl die linken als auch die rechten 28 Bit des Schlüssels (auch + Subkeys genannt) werden zirkulär nach links verschoben und der + resultierende Wert wird mit Hilfe einer + Permutations-/Kontraktionstabelle auf 48 Bit verkürzt. + \item + Die beiden oben genannten Werte werden XOR-verknüpft und in eine + Auswahl- und Ersetzungsbox eingegeben + + \begin{itemize} + \item + Intern wird diese Operation durch 8 so genannte s-Boxen realisiert, + von denen jede einen Sechs-Bit-Wert auf einen Vier-Bit-Wert gemäß + einer boxspezifischen Tabelle abbildet, was insgesamt zu einem + 32-Bit-Ausgang führt + \item + Das Design dieser s-boxes wurde von der NSA verstärkt, was in den + 1970er Jahren zu intensiven Diskussionen führte und in den 1990er + Jahren nach der Entdeckung der differentiellen Kryptoanalyse + verstanden wurde + \end{itemize} + \item + Der Ausgang des obigen Schritts wird erneut permutiert und mit den + linken 32 Bit der Daten XOR-verknüpft, was zu den neuen rechten 32 Bit + der Daten führt + \item + Die neuen linken 32 Bit der Daten sind der rechte Wert der vorherigen + Iteration + \end{itemize} + + + \subsubsection{DES - Entschlüsselung} + + \begin{itemize} + \item + Unter Verwendung der Abkürzung f(R, K) kann der + Verschlüsselungsprozess wie folgt geschrieben werden + + \begin{itemize} + \item + \$L\_i = R\_\{i-1\}\$ + \item + \$R\_i = L\_\{i-1\}\textbackslash oplus f(R\_\{i-1\}, K\_i)\$ + \item + Dieses Konzept (Aufteilung der Daten in zwei Hälften und + Organisation der Verschlüsselung gemäß den obigen Gleichungen) wird + in vielen Blockchiffren verwendet und wird als Feistel-Netzwerk + bezeichnet (nach seinem Erfinder H. Feistel) + \end{itemize} + \item + Der DES-Entschlüsselungsprozess ist im Wesentlichen derselbe wie die + Verschlüsselung. Er verwendet den Chiffretext als Eingabe für den + Verschlüsselungsalgorithmus, wendet aber die Unterschlüssel in + umgekehrter Reihenfolge an + \item + Die Ausgangswerte sind also + + \begin{itemize} + \item + \$L\_0' \textbar\textbar{} R\_0' =\$ InitialPermutation + (Chiffretext) + \item + chiffretext = InverseInitialPermutation (\$R\_\{16\} + \textbar\textbar{} L\_\{16\}\$) + \item + \$L\_0' \textbar\textbar{} R\_0' =\$ InitialPermutation + (InverseInitialPermutation + (\$R\_\{16\}\textbar\textbar L\_\{16\}))=R\_\{16\}\textbar\textbar L\_\{16\}\$ + \end{itemize} + \item + Nach einem Schritt der Entschlüsselung + + \begin{itemize} + \item + \$L\_1' = R\_0' = L\_\{16\} = R\_\{15\}\$ + \item + \$R\_1' = L\_0' \textbackslash oplus f(R\_0', + K\_\{16\})=R\_\{16\}\textbackslash oplus + f(R\_\{15\},K\_\{16\})={[}L\_\{15\}\textbackslash oplus + f(R\_\{15\},K\_\{16\}){]}\textbackslash oplus f(R\_\{15\},K\_\{16\}) + =L\_\{15\}\$ + \end{itemize} + \item + Diese Beziehung gilt für den gesamten Prozess als + + \begin{itemize} + \item + \$R\_\{i-1\} = L\_i\$ + \item + \$L\_\{i-1\} = R\_i\textbackslash oplus f(R\_\{i-1\}, K\_i) = + R\_i\textbackslash oplus f(L\_i, K\_i)\$ + \end{itemize} + \item + Der Ausgang der letzten Runde ist schließlich + + \begin{itemize} + \item + \$L\_\{16\}' \textbar\textbar{} R\_\{16\}' = R\_0 \textbar\textbar{} + L\_0\$ + \end{itemize} + \item + Nach der letzten Runde führt DES einen 32-Bit-Tausch und die inverse + Anfangspermutation durch + + \begin{itemize} + \item + InverseInitialPermutation(\$L\_0\textbar\textbar R\_0\$) = + InverseInitialPermutation(InitialPermutation(Klartext)) = Klartext + \end{itemize} + \end{itemize} + + + \subsubsection{DES - Sicherheit} + + \begin{itemize} + \item + Schwächen der Schlüssel + + \begin{itemize} + \item + Schwache Schlüssel: Vier Schlüssel sind schwach, da sie + Unterschlüssel erzeugen, die entweder alle 0 oder alle 1 enthalten. + \item + Halbschwache Schlüssel: Es gibt sechs Schlüsselpaare, die Klartext + zu identischem Chiffriertext verschlüsseln, da sie nur zwei + verschiedene Unterschlüssel erzeugen + \item + Möglicherweise schwache Schlüssel: Es gibt 48 Schlüssel, die nur + vier verschiedene Unterschlüssel erzeugen + \item + Insgesamt werden 64 Schlüssel von \$72057594037927936\$ als schwach + angesehen + \end{itemize} + \item + Algebraische Struktur + + \begin{itemize} + \item + Wäre DES geschlossen, dann gäbe es für jedes \$K\_1,K\_2\$ ein + \$K\_3\$, so dass: \$E(K\_2,E(K\_1,M))=E(K\_3,M)\$, also wäre die + doppelte Verschlüsselung nutzlos + \item + Wäre DES rein, dann gäbe es für jedes \$K\_1,K\_2,K\_3\$ ein + \$K\_4\$, so dass \$E(K\_3,E(K\_2,E(K\_1,M)))=E(K\_4,M)\$, also wäre + die dreifache Verschlüsselung nutzlos + \item + DES ist weder geschlossen noch rein, daher kann ein + Mehrfachverschlüsselungsschema verwendet werden, um die + Schlüssellänge zu erhöhen + \end{itemize} + \item + Differentielle Kryptoanalyse + + \begin{itemize} + \item + Im Jahr 1990 veröffentlichten E. Biham und A. Shamir diese + Analysemethode + \item + Sie sucht gezielt nach Unterschieden in Chiffretexten, deren + Klartexte bestimmte Unterschiede aufweisen, und versucht, daraus den + richtigen Schlüssel zu erraten + \item + Der grundlegende Ansatz benötigt einen ausgewählten Klartext + zusammen mit seinem Chiffretext + \item + DES mit 16 Runden ist gegen diesen Angriff immun, da der Angriff + \$2\^{}\{47\}\$ gewählte Klartexte oder (bei "Umwandlung" in einen + Angriff mit bekannten Klartexten) \$2\^{}55\$ bekannte Klartexte + benötigt. + \item + Die Entwickler von DES erklärten in den 1990er Jahren, dass sie in + den 1970er Jahren über diese Art von Angriffen Bescheid wussten und + dass die s-Boxen entsprechend entworfen wurden + \end{itemize} + \item + Schlüssellänge + + \begin{itemize} + \item + Da ein 56-Bit-Schlüssel in \$10,01\$ Stunden durchsucht werden kann, + wenn man \$10\^{}6\$ Verschlüsselungen / \$\textbackslash mu s\$ + durchführen kann (was heute möglich ist), kann DES nicht mehr als + ausreichend sicher angesehen werden. + \end{itemize} + \end{itemize} + + + \subsubsection{Erweiterung der Schlüssellänge von DES durch + Mehrfachverschlüsselung} + + \begin{itemize} + \item + Doppelter DES: Da DES nicht geschlossen ist, führt die doppelte + Verschlüsselung zu einer Chiffre, die 112-Bit-Schlüssel verwendet + + \begin{itemize} + \item + Leider kann sie mit einem Aufwand von \$2\^{}\{56\}\$ angegriffen + werden. + \item + Da \$C=E(K\_2,E(K\_1,P))\$ haben wir \$X:=E(K\_1,P)=D(K\_2,C)\$ + \item + Wenn ein Angreifer ein bekanntes Klartext/Chiffretext-Paar erhalten + kann, kann er zwei Tabellen erstellen (meet-in-the-middle-attack) + + \begin{itemize} + \item + Tabelle 1 enthält die Werte von \$X\$, wenn \$P\$ mit allen + möglichen Werten von \$K\$ verschlüsselt ist + \item + Tabelle 2 enthält die Werte von \$X\$, wenn \$C\$ mit allen + möglichen Werten von \$K\$ entschlüsselt wird + \item + Sortiere die beiden Tabellen und konstruiere Schlüssel + \$K\_\{T1\}\textbar\textbar K\_\{T2\}\$ für alle Kombinationen von + Einträgen, die den gleichen Wert ergeben. + \end{itemize} + \end{itemize} + \item + Da es für jeden beliebigen Klartext \$2\^{}\{64\}\$ mögliche + Chiffretext-Werte gibt, die mit Double-DES erzeugt werden könnten, + gibt es beim ersten bekannten Klartext/Chiffretext-Paar + durchschnittlich \$2\^{}\{112\}/2\^{}\{64\}=2\^{}\{48\}\$ Fehlalarme. + \item + Jedes weitere Klartext/Chiffretext-Paar verringert die Chance, einen + falschen Schlüssel zu erhalten, um den Faktor \$1/2\^{}\{64\}\$, so + dass bei zwei bekannten Blöcken die Chance \$2\^{}\{-16\}\$ beträgt. + \item + Der Aufwand, der erforderlich ist, um Double DES zu knacken, liegt + also in der Größenordnung von \$2\^{}\{56\}\$, was nur geringfügig + besser ist als der Aufwand von \$2\^{}\{55\}\$, der erforderlich ist, + um Single DES mit einem Angriff mit bekanntem Klartext zu knacken, und + weit entfernt von den \$2\^{}\{111\}\$, die wir von einer Chiffre mit + einer Schlüssellänge von 112 Bit erwarten würden! + \item + Diese Art von Angriff kann durch die Verwendung eines dreifachen + Verschlüsselungsschemas umgangen werden, wie es 1979 von W. Tuchman + vorgeschlagen wurde + + \begin{itemize} + \item + \$C=E(K\_3,D(K\_2,E(K\_1,P)))\$ + \item + Die Verwendung der Entschlüsselungsfunktion D in der Mitte + ermöglicht die Verwendung von Dreifachverschlüsselungsgeräten mit + Gegenstellen, die nur Einfachverschlüsselungsgeräte besitzen, indem + \$K\_1=K\_2=K\_3\$ gesetzt wird. + \item + Dreifachverschlüsselung kann mit zwei (Einstellung \$K\_1=K\_3\$) + oder drei verschiedenen Schlüsseln verwendet werden + \item + Bislang sind keine praktischen Angriffe gegen dieses Verfahren + bekannt + \item + Nachteil: die Leistung beträgt nur \$1/3\$ der einfachen + Verschlüsselung, so dass es besser sein könnte, gleich eine andere + Chiffre zu verwenden, die eine größere Schlüssellänge bietet + \end{itemize} + \end{itemize} + + + \subsection{Der fortgeschrittene Verschlüsselungsstandard + AES} + + \begin{itemize} + \item + Jan. 1997: Das National Institute of Standards and Technology (NIST) + der USA kündigt die Entwicklung des AES an. + + \begin{itemize} + \item + Das übergeordnete Ziel ist die Entwicklung eines Federal Information + Processing Standard (FIPS), der einen Verschlüsselungsalgorithmus + spezifiziert, der in der Lage ist, sensible Regierungsinformationen + bis weit ins nächste Jahrhundert hinein zu schützen. + \end{itemize} + \item + Sep. 1997: Offizieller Aufruf zur Einreichung von Algorithmen, offen + für jeden auf der Welt + + \begin{itemize} + \item + AES würde einen nicht klassifizierten, öffentlich zugänglichen + Verschlüsselungsalgorithmus bzw. -algorithmen spezifizieren, der + weltweit lizenzgebührenfrei erhältlich ist. + \end{itemize} + \item + Aug. 1998: Erste AES-Kandidatenkonferenz + + \begin{itemize} + \item + NIST gibt die Auswahl von 15 Kandidatenalgorithmen bekannt + \item + Aufforderung zu öffentlichen Kommentaren + \end{itemize} + \item + April 1999: + + \begin{itemize} + \item + Anhand der eingegangenen Analysen und Kommentare wählt das NIST fünf + Algorithmen als Kandidaten für die Endauswahl aus: MARS, RC6, + Rijndael, Serpent und Twofish + \end{itemize} + \item + Oktober 2000: Rijndael wird als Vorschlag des NIST für AES bekannt + gegeben + + \begin{itemize} + \item + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \setcounter{enumi}{25} + \item + November 2001: offizielle Ankündigung des AES-Standards + \end{enumerate} + \end{itemize} + \item + Rundenbasierte symmetrische Chiffre + \item + Keine Feistel-Struktur (unterschiedliche Verschlüsselungs- und + Entschlüsselungsfunktionen) + \item + Schlüssel- und Blocklängen + + \begin{itemize} + \item + Schlüssellänge: 128, 192, oder 256 Bit + \item + Blocklänge: 128, 192 oder 256 Bit (nur 128-Bit-Version + standardisiert) + \item + Anzahl der Runden: 10, 12, 14 + \end{itemize} + \end{itemize} + + Standardisierte AES-Konfigurationen \textbar{} Schlüsselgröße {[}bit{]} + \textbar{} Blocklänge {[}bit{]} \textbar{} \# Runden \textbar{} + \textbar{} -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- + \textbar{} -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{} + -\/-\/-\/-\/-\/-\/-\/- \textbar{} \textbar{} 128 \textbar{} 128 + \textbar{} 10 \textbar{} \textbar{} 192 \textbar{} 128 \textbar{} 12 + \textbar{} \textbar{} 256 \textbar{} 128 \textbar{} 14 \textbar{} + + \begin{itemize} + \item + Der Algorithmus arbeitet mit + + \begin{itemize} + \item + \$state{[}4, 4{]}\$: ein Byte-Array mit 4 Zeilen und 4 Spalten (für + 128-Bit-Blockgröße) + \item + \$key{[}4, 4{]}\$: ein Array mit 4 Zeilen und 4 Spalten (für + 128-Bit-Schlüsselgröße) + \end{itemize} + \item + Verschlüsselung: (für eine Block- und Schlüsselgröße von 128 Bit) in + den Runden \$1-9\$ werden vier verschiedene Operationen verwendet + + \begin{itemize} + \item + ByteSub: eine nicht-lineare Byte-Substitution durch eine feste + Tabelle (im Grunde eine s-Box) + \item + ShiftRow: die Zeilen des Zustands werden zyklisch um verschiedene + Offsets verschoben + \item + MixColumn: die Spalten von \$state{[}{]}\$ werden als Polynome über + \$GF(2\^{}8)\$ betrachtet und modulo \$x\^{}4+1\$ mit einer festen + Matrix multipliziert: \$\textbackslash begin\{pmatrix\} + 02\&03\&01\&01\textbackslash01\&02\&03\&01\textbackslash\textbackslash{} + 01\&01\&02\&03\textbackslash\textbackslash{} + 03\&01\&01\&02\textbackslash end\{pmatrix\}\$ + \item + RoundKey: ein Round-Key wird mit dem Status XORiert + \end{itemize} + \item + Round 10 macht keinen Gebrauch von der Operation MixColumn + \end{itemize} + + % \includegraphics{Assets/NetworkSecurity-rijndael-one-round.png} + + \begin{itemize} + \item + Entschlüsselung + + \begin{itemize} + \item + Rundenschlüssel und Operationen werden in umgekehrter Reihenfolge + angewendet + \item + Der MixColumn-Schritt kann nur durch Multiplikation mit der inversen + Matrix (auch über \$GF(2\^{}8)\$) invertiert werden + \item + \$\textbackslash begin\{pmatrix\} 0e\&0b\&0d\&09\textbackslash{} + 09\&0e\&0b\&0d\textbackslash{} 0d\&09\&0e\&0b\textbackslash{} + 0b\&0d\&09\&0e \textbackslash end\{pmatrix\}\$ + \item + Oft werden tabellarische vorberechnete Lösungen verwendet, die aber + mehr Platz benötigen + \end{itemize} + \end{itemize} + + + \subsubsection{AES - Sicherheit} + + \begin{itemize} + \item + Die einfache mathematische Struktur von AES ist der Hauptgrund für + seine Geschwindigkeit, führte aber auch zu Kritik + \item + Nur die ByteSub-Funktion ist wirklich nichtlinear und verhindert eine + effektive Analyse + \item + AES kann als eine große Matrix-Operation beschrieben werden + \item + Bereits während der Standardisierung wurden Angriffe für reduzierte + Versionen entwickelt + + \begin{itemize} + \item + Ein Angriff mit \$2\^{}\{32\}\$ gewähltem Klartext gegen eine + 7-Runden-Version von AES {[}GM00{]} + \item + Signifikante Reduktion der Komplexität auch für eine + 9-Runden-Version von AES mit 256-Schlüsselgröße mit einem + zugehörigen Schlüsselangriff + \end{itemize} + \item + 2011 wurde der erste Angriff gegen einen vollständigen AES bekannt + {[}BKR11{]} + + \begin{itemize} + \item + Schlüsselwiederherstellung in \$2\^{}\{126.1\}\$ für AES mit 128 + Bit, \$2\^{}\{189.7\}\$ für AES mit 192 Bit, \$2\^{}\{254.4\}\$ für + AES mit 256 Bit + \item + "Praktischer" Angriff (geht nicht von verwandten Schlüsseln aus), + aber + \item + nur ein kleiner Kratzer in Anbetracht von 10 Jahren + kryptographischer Forschung + \end{itemize} + \end{itemize} + + + \subsection{Der Stromchiffre-Algorithmus + RC4} + + \begin{itemize} + \item + RC4 ist eine Stromchiffre, die 1987 von Ron Rivest erfunden wurde. + \item + Sie war bis 1994 urheberrechtlich geschützt, als jemand sie anonym in + eine Mailingliste einstellte. + \item + RC4 wird im Output-Feedback-Modus (OFB) betrieben + + \begin{itemize} + \item + Der Verschlüsselungsalgorithmus erzeugt eine Pseudozufallsfolge + \$RC4(IV,K)\$, die nur vom Schlüssel K und einem + Initialisierungsvektor IV abhängt + \item + Der Klartext \$P\_i\$ wird dann mit der Pseudozufallssequenz + XOR-verknüpft, um den Chiffretext zu erhalten und umgekehrt + + \begin{itemize} + \item + \$C\_1 = P\_1\textbackslash oplus RC4 (IV\_1,K)\$ + \item + \$P\_1 = C\_1\textbackslash oplus RC4 (IV\_1,K)\$ + \end{itemize} + \item + Die Pseudo-Zufallsfolge wird oft auch als Keystream bezeichnet + \item + Entscheidend für die Sicherheit ist, dass der Keystream niemals + wiederverwendet wird!!! + + \begin{itemize} + \item + Wenn der Keystream wiederverwendet wird (d.h. \$IV\_1=IV\_2\$ mit + demselben \$K\$), dann kann das XOR zweier Klartexte erhalten + werden: \$C\_1\textbackslash oplus C\_2= P\_1\textbackslash oplus + RC4(IV, K)\textbackslash oplus P\_2\textbackslash oplus RC4(IV,K) + = P\_1\textbackslash oplus P\_2\$ + \end{itemize} + \end{itemize} + \item + RC4 verwendet einen Schlüssel variabler Länge bis zu 2048 Bit + + \begin{itemize} + \item + Eigentlich dient der Schlüssel als Seed für einen + Pseudo-Zufallsgenerator + \end{itemize} + \item + RC4 arbeitet mit zwei 256-Byte-Arrays: \$S{[}0,255{]}, K{[}0,255{]}\$ + + \begin{itemize} + \item + Schritt 1: Initialisierung der Arrays + + %\begin{Shaded} + % \begin{Highlighting}[] + % \ControlFlowTok{for}\NormalTok{ (i = }\DecValTok{0}\NormalTok{; i \textless{} }\DecValTok{256}\NormalTok{; i++)\{} + % \NormalTok{ S[i] = i; }\CommentTok{// Array S[] mit 0 bis 255 füllen} + % \NormalTok{\}} + % \CommentTok{// Füllen des Arrays K[] mit dem Schlüssel und IV durch Wiederholung, bis K[] gefüllt ist} + % \NormalTok{n = }\DecValTok{0}\NormalTok{;} + % \ControlFlowTok{for}\NormalTok{ (i =}\DecValTok{0}\NormalTok{; i \textless{} }\DecValTok{256}\NormalTok{; i++) \{} + % \NormalTok{ n = (n + S[i] + K[i]) MOD }\DecValTok{256}\NormalTok{; swap(S[i], S[n]); } + % \NormalTok{\}} + % \end{Highlighting} + %\end{Shaded} + \item + Schritt 2: Erzeugen des Schlüsselstroms (nach Initialisierung \$i = + 0; n = 0;\$) + + %\begin{Shaded} + % \begin{Highlighting}[] + % \NormalTok{i = (i + }\DecValTok{1}\NormalTok{) MOD }\DecValTok{256}\NormalTok{; n = (n + S[i]) MOD }\DecValTok{256}\NormalTok{;} + % \NormalTok{swap(S[i], S[n]);} + % \NormalTok{t = (S[i] + S[n]) MOD }\DecValTok{256}\NormalTok{;} + % \NormalTok{Z = S[t]; }\CommentTok{// Z enthält 8 Bit des durch eine Iteration erzeugten Schlüsselstroms} + % \end{Highlighting} + %\end{Shaded} + \item + Schritt 3: XOR-Verknüpfung des Schlüsselstroms mit dem Klartext oder + Chiffretext + \end{itemize} + \item + Sicherheit von RC4 + + \begin{itemize} + \item + Sicherheit gegen Brute-Force-Angriffe (Ausprobieren aller möglichen + Schlüssel) + + \begin{itemize} + \item + Die variable Schlüssellänge von bis zu 2048 Bit erlaubt es, sie + unpraktisch zu machen (zumindest mit den in unserem Universum + verfügbaren Ressourcen) + \item + Allerdings kann RC4 durch Verringerung der Schlüssellänge auch + beliebig unsicher gemacht werden! + \end{itemize} + \item + RSA Data Security, Inc. behauptet, RC4 sei immun gegen + differentielle und lineare Kryptoanalyse, und es seien keine kleinen + Zyklen bekannt + \end{itemize} + \item + RC4 mit 40-Bit-Schlüsseln hatte einen besonderen Exportstatus, selbst + als andere Chiffren nicht aus den USA exportiert werden durften + + \begin{itemize} + \item + Secure Socket Layer (SSL) verwendet RC4 mit 40-Bit-Schlüsseln als + Standardalgorithmus + \item + Die Schlüssellänge von 40 Bit ist nicht immun gegen + Brute-Force-Angriffe. + \end{itemize} + \item + Je nach Schlüsselplanungsmethode kann RC4 jedoch stark verwundbar + sein! {[}FMS01a, Riv01a, SIR01a{]} + \item + Es wird empfohlen, mindestens die ersten 3072 Bytes des + Schlüsselstroms zu verwerfen {[}Mir02, Kle08{]} + \item + Sollte eigentlich nicht mehr verwendet werden, auch nicht bei längeren + Schlüsseln + \end{itemize} + + + \subsection{KASUMI} + + \begin{itemize} + \item + Verwendet zur Verschlüsselung von Anrufen in GSM und UMTS, + implementiert f(8) und f(9) (auch A5/3, UEA1, UIA1 genannt) + \item + Ursprünglich standardisiert durch 3GPP im Jahr 2000 {[}ETS12{]} und + basierend auf MISTY1 von Mitsubishi + \item + Entwickelt für Hardware-Implementierung + + \begin{itemize} + \item + Schnelle Implementierung möglich + \item + \$\textless10k\$ Gatter + \end{itemize} + \item + 64-Bit-Blockgröße + \item + 128-Bit-Schlüssellänge + \item + 8 Runden Feistel-Netzwerk + \item + Sicherheitsspanne nicht sehr groß + \end{itemize} + + % \includegraphics{Assets/NetworkSecurity-kasumi-singe-iteration.png} + + \begin{itemize} + \item + Die linken 32 Bit der zu verschlüsselnden Daten werden durch zwei + nichtlineare Funktionen FO und FL verändert, die beide + Schlüsselmaterial verwenden + \item + Die Reihenfolge, in der FO und FL angewendet werden, hängt von der + Rundenzahl ab + \item + FL teilt die Daten in 16-Bit-Wörter auf, die mit Schlüsselmaterial + kombiniert, permutiert und mit den Originalwerten XOR-verknüpft werden + \item + FO ist ein 3-Runden-Feistel-Netzwerk mit einer Modifizierungsfunktion + FI, die selbst ein Feistel-ähnliches Netzwerk ist, das zwei s-Boxen + verwendet. + \item + Der Ausgang des obigen Schritts wird mit den rechten 32 Bit der Daten + XOR-verknüpft, was zu den neuen rechten 32 Bit der Daten führt + \item + Das neue linke 32-Bit der Daten ist der rechte Wert der vorherigen + Iteration + \end{itemize} + + + \subsubsection{KASUMI - + Sicherheitsdiskussion} + + \begin{itemize} + \item + Eine reduzierte Version von KASUMI (6 Runden) kann durch sogenannte + unmögliche differentielle Kryptoanalyse angegriffen werden, bei der + unmögliche Zustände der Chiffre aus Chiffretext/Klartext-Paaren + abgeleitet werden + + \begin{itemize} + \item + Erste Veröffentlichung bereits ein Jahr nach der Standardisierung + \item + Zeitkomplexität von \$2\^{}\{100\}\$ {[}Kue01{]} + \end{itemize} + \item + Für eine Vollversion von KASUMI sind verwandte Schlüsselangriffe + möglich + + \begin{itemize} + \item + Ausgewählter Klartextangriff, bei dem der Angreifer dieselben Daten + mit mehreren "verwandten" Schlüsseln verschlüsseln kann + \item + Zeitkomplexität von \$2\^{}\{76.1\}\$ {[}BDN05{]} und + \$2\^{}\{32\}\$ im besten Fall {[}DKS10{]} + \item + Allerdings sind die Bedingungen, unter denen Angreifer Zugang zu + verwandten Schlüsseln in 3G-Netzen haben, sehr selten + \item + Interessanterweise ist MISTY von diesen Angriffen nicht betroffen! + \end{itemize} + \item + ETSI hat jedoch SNOW 3G (UEA2 und UIA2) {[}ETS06{]} eingeführt, um auf + eine vollständige Verletzung von KASUMI vorbereitet zu sein + + \begin{itemize} + \item + Stromchiffre basierend auf LFSR, kann in 7.500 ASIC-Gattern + implementiert werden + \item + Aber auch anfällig für verwandte Schlüsselangriffe {[}KY11{]}. + \end{itemize} + \end{itemize} + + + \section{Asymmetrische + Kryptographie} + + Eine vorherige Beschäftigung mit der diskreten Mathematik wird dem Leser + jedoch helfen, die hier vorgestellten Konzepte zu verstehen.'' E. + Amoroso in einem anderen Zusammenhang {[}Amo94{]} + + \begin{itemize} + \item + Allgemeine Idee: + + \begin{itemize} + \item + Verwenden Sie zwei verschiedene Schlüssel \$-K\$ und \$+K\$ für die + Ver- und Entschlüsselung + \item + Bei einem zufälligen Chiffretext \$c=E(+K, m)\$ und \$+K\$ sollte es + nicht möglich sein, \$m = D(-K, c) = D(-K, E(+K, m))\$ zu berechnen. + + \begin{itemize} + \item + Dies impliziert, dass die Berechnung von \$-K\$ bei \$+K\$ nicht + möglich sein sollte. + \end{itemize} + \item + Der Schlüssel \$-K\$ ist nur einer Entität A bekannt und wird A's + privater Schlüssel \$-K\_A\$ genannt + \item + Der Schlüssel \$+K\$ kann öffentlich bekannt gegeben werden und wird + A's öffentlicher Schlüssel \$+K\_A\$ genannt + \end{itemize} + \item + Anwendungen: + + \begin{itemize} + \item + Verschlüsselung: + + \begin{itemize} + \item + Wenn B eine Nachricht mit dem öffentlichen Schlüssel \$+K\_A\$ von + A verschlüsselt, kann er sicher sein, dass nur A sie mit \$-K\_A\$ + entschlüsseln kann. + \end{itemize} + \item + Signieren: + + \begin{itemize} + \item + Wenn A eine Nachricht mit seinem eigenen privaten Schlüssel + \$-K\_A\$ verschlüsselt, kann jeder diese Signatur verifizieren, + indem er sie mit A's öffentlichem Schlüssel \$+K\_A\$ + entschlüsselt + \end{itemize} + \item + Achtung! Entscheidend ist, dass jeder nachprüfen kann, dass er + wirklich den öffentlichen Schlüssel von A kennt und nicht den + Schlüssel eines Gegners! + \end{itemize} + \item + Entwurf von asymmetrischen Kryptosystemen: + + \begin{itemize} + \item + Schwierigkeit: Finde einen Algorithmus und eine Methode, zwei + Schlüssel \$-K\$, \$+K\$ so zu konstruieren, dass es nicht möglich + ist, \$E(+K, m)\$ mit der Kenntnis von \$+K\$ zu entschlüsseln + \item + Beschränkungen: + + \begin{itemize} + \item + Die Schlüssellänge sollte ,,überschaubar'' sein + \item + Verschlüsselte Nachrichten sollten nicht beliebig länger sein als + unverschlüsselte Nachrichten (wir würden einen kleinen konstanten + Faktor tolerieren) + \item + Ver- und Entschlüsselung sollten nicht zu viele Ressourcen + verbrauchen (Zeit, Speicher) + \end{itemize} + \item + Grundlegende Idee: Man nehme ein Problem aus dem Bereich der + Mathematik/Informatik, das schwer zu lösen ist, wenn man nur \$+K\$ + kennt, aber leicht zu lösen, wenn man \$-K\$ kennt + + \begin{itemize} + \item + Knapsack-Probleme: Grundlage der ersten funktionierenden + Algorithmen, die sich leider fast alle als unsicher erwiesen haben + \item + Faktorisierungsproblem: Grundlage des RSA-Algorithmus + \item + Diskreter-Logarithmus-Problem: Grundlage von Diffie-Hellman und + ElGamal + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Einige mathematische + Hintergründe} + + \begin{itemize} + \item + Sei \$\textbackslash mathbb\{Z\}\$ die Menge der ganzen Zahlen, und + \$a,b,n\textbackslash in\textbackslash mathbb\{Z\}\$ + \item + Wir sagen, \$a\$ teilt \$b(a\textbar b)\$, wenn es eine ganze Zahl + \$k\textbackslash in\textbackslash mathbb\{Z\}\$ gibt, so dass + \$a\textbackslash times k=b\$ + \item + \$a\$ ist prim, wenn es positiv ist und die einzigen Teiler von a + \$1\$ und \$a\$ sind. + \item + \$r\$ ist der Rest von a geteilt durch \$n\$, wenn + \$r=a-\textbackslash lfloor a / n + \textbackslash rfloor\textbackslash times n\$, wobei + \$\textbackslash lfloor x\textbackslash rfloor\$ die größte ganze Zahl + kleiner oder gleich \$x\$ ist. + + \begin{itemize} + \item + Beispiel: 4 ist der Rest von 11 geteilt durch 7 als + \$4=11-\textbackslash lfloor + 11/7\textbackslash rfloor\textbackslash times 7\$ + \item + Wir können dies auch anders schreiben: \$a=q\textbackslash times n + + r\$ mit \$q=\textbackslash lfloor a/n\textbackslash rfloor\$ + \end{itemize} + \item + Für den Rest \$r\$ der Division von a durch n schreiben wir + \$a\textbackslash{} MOD\textbackslash{} n\$ + \item + Wir sagen, b ist kongruent \$a\textbackslash{} mod\textbackslash{} + n\$, wenn es bei der Division durch n den gleichen Rest wie a hat. + Also teilt n \$(a-b)\$, und wir schreiben \$b\textbackslash equiv + a\textbackslash{} mod\textbackslash{} n\$ + + \begin{itemize} + \item + Beispiele: \$4\textbackslash equiv 11\textbackslash{} + mod\textbackslash{} 7\$, \$25\textbackslash equiv 11\textbackslash{} + mod\textbackslash{} 7\$, \$11\textbackslash equiv 25\textbackslash{} + mod\textbackslash{} 7\$, \$11\textbackslash equiv 4\textbackslash{} + mod\textbackslash{} 7\$, \$-10\textbackslash equiv 4\textbackslash{} + mod\textbackslash{} 7\$ + \end{itemize} + \item + Da der Rest r der Division durch n immer kleiner als n ist, stellt man + manchmal die Menge \$\{x\textbackslash{} MOD\textbackslash{} n + \textbar{} x\textbackslash in\textbackslash mathbb\{Z\}\}\$ durch + Elemente der Menge \$\textbackslash mathbb\{Z\}\_n=\{0, 1, ..., + n-1\}\$ dar + \end{itemize} + + %\begin{longtable}[]{@{}ll@{}} + % \toprule + % Eigenschaft & Ausdruck\tabularnewline + % \midrule + % \endhead + % Kommutativgesetze & \$(a + b)\textbackslash{} MOD\textbackslash{} n = (b + % + a)\textbackslash{} MOD\textbackslash{} n\$\tabularnewline + % & \$(a \textbackslash times b)\textbackslash{} MOD\textbackslash{} n = + % (b \textbackslash times a)\textbackslash{} MOD\textbackslash{} + % n\$\tabularnewline + % Assoziativgesetze & \${[}(a + b) + c{]}\textbackslash{} + % MOD\textbackslash{} n = {[}a + (b + c){]}\textbackslash{} + % MOD\textbackslash{} n\$\tabularnewline + % & \${[}(a \textbackslash times b) \textbackslash times + % c{]}\textbackslash{} MOD\textbackslash{} n = {[}a \textbackslash times + % (b \textbackslash times c){]}\textbackslash{} MOD\textbackslash{} + % n\$\tabularnewline + % Distributivgesetz & \${[}a \textbackslash times (b + + % c){]}\textbackslash{} MOD\textbackslash{} n = {[}(a \textbackslash times + % b) + (a \textbackslash times c){]}\textbackslash{} MOD\textbackslash{} + % n\$\tabularnewline + % Identitäten & \$(0 + a)\textbackslash{} MOD\textbackslash{} n = + % a\textbackslash{} MOD\textbackslash{} n\$\tabularnewline + % & \$(1 \textbackslash times a)\textbackslash{} MOD\textbackslash{} n = + % a\textbackslash{} MOD\textbackslash{} n\$\tabularnewline + % Inverse & \$\textbackslash forall a \textbackslash in + % \textbackslash mathbb\{Z\}n: \textbackslash exists (-a) + % \textbackslash in \textbackslash mathbb\{Z\}n : a + (-a) + % \textbackslash equiv 0\textbackslash{} mod\textbackslash{} + % n\$\tabularnewline + % & p is prime \$\textbackslash Rightarrow \textbackslash forall a + % \textbackslash in \textbackslash mathbb\{Z\}p: \textbackslash exists + % (a-1) \textbackslash in \textbackslash mathbb\{Z\}p: a + % \textbackslash times (a-1) \textbackslash equiv 1\textbackslash{} + % mod\textbackslash{} p\$\tabularnewline + % \bottomrule + %\end{longtable} + + Größter gemeinsamer Teiler + + \begin{itemize} + \item + \$c = gcd(a, b) :\textbackslash Leftrightarrow ( c \textbar{} a) + \textbackslash wedge ( c \textbar{} b) \textbackslash wedge + {[}\textbackslash forall d: ( d \textbar{} a ) \textbackslash wedge ( + d \textbar{} b) \textbackslash Rightarrow ( d \textbar{} c ){]}\$ und + \$gcd(a, 0 ) : = \textbar{} a \textbar\$ + \item + Der gcd-Rekursionssatz : + + \begin{itemize} + \item + \$\textbackslash forall a, b \textbackslash in + \textbackslash mathbb\{Z\}\^{}+: gcd(a, b) = gcd(b, + a\textbackslash{} MOD\textbackslash{} b)\$ + \item + Beweis: + + \begin{itemize} + \item + Da \$gcd(a, b)\$ sowohl a als auch b teilt, teilt es auch jede + Linearkombination von ihnen, insbesondere \$(a- + \textbackslash lfloor a / b \textbackslash rfloor + \textbackslash times b) = a\textbackslash{} MOD\textbackslash{} + b\$, also \$gcd(a, b) \textbar{} gcd(b, a\textbackslash{} + MOD\textbackslash{} b)\$ + \item + Da \$gcd(b, a\textbackslash{} MOD\textbackslash{} b)\$ sowohl b + als auch \$a\textbackslash{} MOD\textbackslash{} b\$ teilt, teilt + es auch jede Linearkombination von beiden, insbesondere + \$\textbackslash lfloor a / b \textbackslash rfloor + \textbackslash times b + (a\textbackslash{} MOD\textbackslash{} b) + = a\$, also \$gcd(b, a\textbackslash{} MOD\textbackslash{} b) + \textbar{} gcd(a, b)\$ + \end{itemize} + \end{itemize} + \item + Euklidischer Algorithmus: + + \begin{itemize} + \item + Der euklidische Algorithmus berechnet aus a, b \$gcd(a, b)\$ + \end{itemize} + + %\begin{Shaded} + % \begin{Highlighting}[] + % \DataTypeTok{int}\NormalTok{ Euclid(}\DataTypeTok{int}\NormalTok{ a, b)\{} + % \ControlFlowTok{if}\NormalTok{ (b = }\DecValTok{0}\NormalTok{) \{ }\ControlFlowTok{return}\NormalTok{(a); \}} + % \NormalTok{ \{}\ControlFlowTok{return}\NormalTok{(Euclid(b, a\textbackslash{} MOD\textbackslash{} b);\} } + % \NormalTok{\}} + % \end{Highlighting} + %\end{Shaded} + \item + Erweiterter euklidischer Algorithmus: + + \begin{itemize} + \item + Der Algorithmus ExtendedEuclid berechnet für a, b d, m, n so, dass: + \$d = gcd(a, b) = m \textbackslash times a + n \textbackslash times + b\$ + \end{itemize} + + %\begin{Shaded} + % \begin{Highlighting}[] + % \KeywordTok{struct}\NormalTok{\{}\DataTypeTok{int}\NormalTok{ d, m, n\} ExtendedEuclid(}\DataTypeTok{int}\NormalTok{ a, b)} + %% \NormalTok{\{ }\DataTypeTok{int}\NormalTok{ d, d}\CharTok{\textquotesingle{},}\ErrorTok{ m, m}\CharTok{\textquotesingle{}}\NormalTok{, n, n}\CharTok{\textquotesingle{};} + % \ControlFlowTok{if}\NormalTok{ (b = }\DecValTok{0}\NormalTok{) \{}\ControlFlowTok{return}\NormalTok{(a, }\DecValTok{1}\NormalTok{, }\DecValTok{0}\NormalTok{); \}} + % \NormalTok{ (d}\CharTok{\textquotesingle{},}\ErrorTok{ m}\CharTok{\textquotesingle{}}\NormalTok{, n}\CharTok{\textquotesingle{})}\ErrorTok{ = ExtendedEuclid(b, a MOD b);} + % \NormalTok{ (d, m, n) = (d}\CharTok{\textquotesingle{},}\ErrorTok{ n}\CharTok{\textquotesingle{}}\NormalTok{, m}\CharTok{\textquotesingle{} }\ErrorTok{{-} \textbackslash{}lfloor a / b \textbackslash{}rfloor \textbackslash{}times n}\CharTok{\textquotesingle{}}\NormalTok{);} + % \ControlFlowTok{return}\NormalTok{(d, m, n); \}} + % \end{Highlighting} + %\end{Shaded} + + \begin{itemize} + \item + Beweis: (durch Induktion) + + \begin{itemize} + \item + Grundfall \$(a,0): gcd(a, 0) = a = 1 \textbackslash times a + 0 + \textbackslash times 0\$ + \item + Induktion von \$(b, a\textbackslash{} MOD\textbackslash{} b)\$ auf + \$(a, b)\$: + + \begin{itemize} + \item + ExtendedEuclid berechnet \$d', m', n'\$ korrekt + (Induktionshypothese) + \item + \$d=d'=m'\textbackslash times b+n'\textbackslash times + (a\textbackslash{} MOD\textbackslash{} b)=m'\textbackslash times + b+n'\textbackslash times (a-\textbackslash lfloor + a/b\textbackslash rfloor\textbackslash times + b)=n'\textbackslash times a+(m'-\textbackslash lfloor + a/b\textbackslash rfloor\textbackslash times + n')\textbackslash times b\$ + \end{itemize} + \end{itemize} + \item + Die Laufzeit von \$Euclid(a, b)\$ und \$ExtendedEuclid(a, b)\$ ist + von \$O(log\textbackslash{} b)\$ + + \begin{itemize} + \item + Beweis: siehe {[}Cor90a{]}, Abschnitt 33. + \end{itemize} + \item + Lemma 1: Sei \$a,b\textbackslash in\textbackslash mathbb\{N\}\$ und + \$d=gcd(a,b)\$. Dann gibt es + \$m,n\textbackslash in\textbackslash mathbb\{N\}\$ so, dass: + \$d=m\textbackslash times a+n \textbackslash times b\$ + \end{itemize} + \item + Theorem 1 (Euklid): Wenn eine Primzahl das Produkt zweier ganzer + Zahlen teilt, dann teilt sie mindestens eine der ganzen Zahlen: + \$p\textbar(a\textbackslash times b)\textbackslash Rightarrow + (p\textbar a)\textbackslash times(p\textbar b)\$ + + \begin{itemize} + \item + Der Beweis: Es sei \$p\textbar(a\textbackslash times b)\$ + + \begin{itemize} + \item + Wenn \$p\textbar a\$ dann sind wir fertig. + \item + Wenn nicht, dann \$gcd(p,a) = 1 + \textbackslash Rightarrow\textbackslash exists m, + n\textbackslash in\textbackslash mathbb\{N\}:1=m\textbackslash times + p+n\textbackslash times a \textbackslash Leftrightarrow + b=m\textbackslash times p \textbackslash times b + n + \textbackslash times a \textbackslash times b\$ + \item + Da \$p\textbar(a\textbackslash times b)\$, teilt p beide Summanden + der Gleichung und somit auch die Summe, die b ist + \end{itemize} + \end{itemize} + \item + Theorem 2 (Fundamentalsatz der Arithmetik): Die Faktorisierung in + Primzahlen ist bis zur Ordnung eindeutig. + + \begin{itemize} + \item + Der Beweis: + + \begin{itemize} + \item + Wir werden zeigen, dass jede ganze Zahl mit einer nicht + eindeutigen Faktorisierung einen eigenen Teiler mit einer nicht + eindeutigen Faktorisierung hat, was zu einem klaren Widerspruch + führt, wenn wir schließlich auf eine Primzahl reduziert haben. + \item + Nehmen wir an, dass n eine ganze Zahl mit einer nicht eindeutigen + Faktorisierung ist: \$n=p\_1\textbackslash times + p\_2\textbackslash times ...\textbackslash times p\_r=q\_1 + \textbackslash times q\_2\textbackslash times ... + \textbackslash times q\_s\$. Die Primzahlen sind nicht + notwendigerweise verschieden, aber die zweite Faktorisierung ist + nicht einfach eine Umordnung der ersten. Da \$p\_1\$ n dividiert, + dividiert es auch das Produkt \$q\_1\textbackslash times + q\_2\textbackslash times ... \textbackslash times q\_s\$. Durch + wiederholte Anwendung von Satz 1 zeigen wir, dass es mindestens + ein \$q\_i\$ gibt, das durch \$p\_1\$ teilbar ist. Gegebenenfalls + ordnen wir die \$q\_i\$'s so, dass es \$q\_1\$ ist. Da sowohl + \$p\_1\$ als auch \$q\_1\$ Primzahlen sind, müssen sie gleich + sein. Wir können also durch \$p\_1\$ dividieren und haben, dass + \$n/p\_1\$ eine nicht-eindeutige Faktorisierung hat. + \end{itemize} + \item + Wir verwenden Theorem 2, um die folgende Korollarie 1 zu beweisen + + \begin{itemize} + \item + Wenn \$gcd(c,m)=1\$ und \$(a\textbackslash times + c)\textbackslash equiv(b\textbackslash times c)mod\textbackslash{} + m\$, dann \$a\textbackslash equiv b\textbackslash{} + mod\textbackslash{} m\$ + \item + Der Beweis: Da \$(a\textbackslash times + c)\textbackslash equiv(b\textbackslash times c)mod\textbackslash{} + m\textbackslash Rightarrow\textbackslash exists + n\textbackslash in\textbackslash mathbb\{N\}:(a\textbackslash times + c)-(b\textbackslash times c)=n\textbackslash times m\$ + \item + \$\textbackslash Leftrightarrow ( a - b ) \textbackslash times c = + n \textbackslash times m\$ + \item + \$\textbackslash Leftrightarrow p\_1\textbackslash times + ...\textbackslash times p\_i\textbackslash times + q\_1\textbackslash times ...\textbackslash times + q\_j=r\_1\textbackslash times ...\textbackslash times + r\_k\textbackslash times s\_1\textbackslash times + ...\textbackslash times s\_l\$ + \item + Man beachte, dass die \$p\$'s, \$q\$'s, \$r\$'s und \$s\$'s + Primzahlen sind und nicht verschieden sein müssen, aber da + \$gcd(c,m)=1\$, gibt es keine Indizes g, h, so dass \$q\_g = + s\_h\$. + \item + Wir können also die Gleichung fortlaufend durch alle q's teilen, + ohne jemals ein \$s\$ zu ,,eliminieren'' und erhalten schließlich + etwas wie \$\textbackslash Leftrightarrow p\_1\textbackslash times + ...\textbackslash times p\_i=r\_1\textbackslash times + ...\textbackslash times r\_o\textbackslash times + s\_1\textbackslash times ...\textbackslash times s\_l\$ (beachten + Sie, dass es weniger r's geben wird) + \item + \$\textbackslash Leftrightarrow(a-b)=r\_1\textbackslash times + ...\textbackslash times r\_o\textbackslash times + m\textbackslash Rightarrow a \textbackslash equiv + b\textbackslash{} mod\textbackslash{} m\$ + \end{itemize} + \item + Bezeichne \$\textbackslash phi(n)\$ die Anzahl der positiven ganzen + Zahlen, die kleiner als n und relativ zu n prim sind + + \begin{itemize} + \item + Beispiele: \$\textbackslash phi(4) = 2\$, + \textbackslash phi(6)=2\$, \$\textbackslash phi(7)=6\$, + \$\textbackslash phi(15)=8\$ + \item + Wenn p eine Primzahl ist + \$\textbackslash Rightarrow\textbackslash phi(p)=p-1\$ + \end{itemize} + \end{itemize} + \item + Theorem 3 (Euler): Seien n und b positive und relativ primäre ganze + Zahlen, d.h. \$gcd(n, b) = 1 \textbackslash Rightarrow b + \textbackslash phi(n) \textbackslash equiv 1\textbackslash{} + mod\textbackslash{} n\$ + + \begin{itemize} + \item + Beweis: + + \begin{itemize} + \item + Sei \$t=\textbackslash phi(n)\$ und \$a\_1,...a\_t\$ seien die + positiven ganzen Zahlen kleiner als \$n\$, die relativ zu \$n\$ + prim sind. Definieren Sie \$r\_1,...,r\_t\$ als die Residuen von + \$b\textbackslash times a\_1\textbackslash{} mod\textbackslash{} n + , ..., b\textbackslash times a\_t\textbackslash{} + mod\textbackslash{} n\$, d.h.: \$b\textbackslash times a\_i + \textbackslash equiv r\_i\textbackslash{} mod\textbackslash{} n\$. + \item + Beachten Sie, dass \$i\textbackslash not= j + \textbackslash Rightarrow r\_i\textbackslash not= r\_j\$. Wäre + dies nicht der Fall, hätten wir \$b\textbackslash times + a\_i\textbackslash equiv b\textbackslash times + a\_j\textbackslash{} mod\textbackslash{} n\$ und da + \$gcd(b,n)=1\$, würde Korollar 1 \$a\_i\textbackslash equiv + a\_j\textbackslash{} mod\textbackslash{} n\$ implizieren, was + nicht sein kann, da \$a\_i\$ und \$a\_j\$ per Definition + verschiedene ganze Zahlen zwischen 0 und n sind + \item + Wir wissen auch, dass jedes \$r\_i\$ relativ prim zu n ist, denn + jeder gemeinsame Teiler k von \$r\_i\$ und \$n\$ , d.h. + \$n=k\textbackslash times m\$ und \$r\_i=p\_i\textbackslash times + k\$, müsste auch \$a\_i\$ teilen, + \item + da \$b\textbackslash times a\_i\$gleich (p\_i\textbackslash times + k)\textbackslash{} mod\textbackslash{} (k\textbackslash times + m)\textbackslash Rightarrow\textbackslash exists + s\textbackslash in\textbackslash mathbb\{N\}:(b\textbackslash times + a\_i)-(p\_i\textbackslash times k)=s\textbackslash times + k\textbackslash times m \textbackslash Leftrightarrow + (b\textbackslash times a\_i)=s\textbackslash times + k\textbackslash times m+(p\_i\textbackslash times k)\$ + \item + Da k jeden der Summanden auf der rechten Seite dividiert und k + nicht durch b dividiert (n und b sind relativ prim), müsste es + auch \$a\_i\$ dividieren, das relativ prim zu n sein soll + \item + Somit ist \$r\_1, ...,r\_t\$ eine Menge von + \$\textbackslash phi(n)\$ verschiedenen ganzen Zahlen, die relativ + prim zu \$n\$ sind. Das bedeutet, dass sie genau dasselbe sind wie + \$a\_1,...a\_t\$, nur dass sie in einer anderen Reihenfolge + stehen. Insbesondere wissen wir, dass \$r\_1\textbackslash times + ...\textbackslash times r\_t=a\_1\textbackslash times + ...\textbackslash times a\_t\$ + \item + Wir verwenden nun die Kongruenz \$r\_1\textbackslash times + ...\textbackslash times r\_t\textbackslash equiv + b\textbackslash times a\_1\textbackslash times + ...\textbackslash times b\textbackslash times a\_t\textbackslash{} + mod\textbackslash{} n\$ \$\textbackslash Leftrightarrow + r\_1\textbackslash times ...\textbackslash times + r\_t\textbackslash equiv b\_t\textbackslash times + a\_1\textbackslash times ...\textbackslash times + a\_t\textbackslash{} mod\textbackslash{} n\$ + \$\textbackslash Leftrightarrow r\_1\textbackslash times + ...\textbackslash times r\_t\textbackslash equiv + b\_\textbackslash times r\_1\textbackslash times + ...\textbackslash times r\_t\textbackslash{} mod\textbackslash{} + n\$ + \item + Da alle \$r\_i\$ relativ prim zu \$n\$ sind, können wir Korollar 1 + anwenden und durch ihr Produkt dividieren: \$1\textbackslash equiv + b\_t\textbackslash{} mod\textbackslash{} n + \textbackslash Leftrightarrow 1\textbackslash equiv + b\textbackslash phi(n)\textbackslash{} mod n\$ + \end{itemize} + \end{itemize} + \item + Satz 4 (Chinese Remainder Theorem): + + \begin{itemize} + \item + Seien \$m\_1,...,m\_r\$ positive ganze Zahlen, die paarweise relativ + prim sind, + \item + d.h. \$ganz i\textbackslash not= j:gcd(m\_i, m\_j) = 1\$. Seien + \$a\_1,...,a\_r\$ beliebige ganze Zahlen. + \item + Dann gibt es eine ganze Zahl a derart, dass: + + \begin{itemize} + \item + \$a\textbackslash equiv a\_1\textbackslash{} mod\textbackslash{} + m\_1\$ + \item + \$a\textbackslash equiv a\_2\textbackslash{} mod\textbackslash{} + m\_2\$ + \item + ... + \item + \$a\textbackslash equiv a\_r\textbackslash{} mod\textbackslash{} + m\_r\$ + \end{itemize} + \item + Außerdem ist a eindeutig modulo \$M := m\_1\textbackslash times + ...\textbackslash times m\_r\$ + \item + Beweis: + + \begin{itemize} + \item + Für alle \$i\textbackslash in\{1,...,r\}\$ definieren wir + \$M\_i:=(M/m\_i)\textbackslash phi(m\_i)\$ + \item + Da \$M\_i\$ per Definition relativ prim zu \$m\_i\$ ist, können + wir Theorem 3 anwenden und wissen, dass \$M\_i\textbackslash equiv + 1\textbackslash{} mod\textbackslash{} m\_i\$ + \item + Da \$M\_i\$ durch \$m\_j\$ für jedes \$j\textbackslash not= i\$ + teilbar ist, haben wir \$\textbackslash forall + j\textbackslash not= i:M\_i\textbackslash equiv 0\textbackslash{} + mod\textbackslash{} m\_j\$ + \item + Wir können nun die Lösung konstruieren, indem wir definieren: + \$a:= a\_1\textbackslash times M\_1+a\_2\textbackslash times + M\_2+...+a\_r\textbackslash times M\_r\$ + \item + Die beiden oben angeführten Argumente bezüglich der Kongruenzen + der \$M\_i\$ implizieren, dass a tatsächlich alle Kongruenzen + erfüllt. + \item + Um zu sehen, dass a eindeutig modulo \$M\$ ist, sei b eine + beliebige andere ganze Zahl, die die r Kongruenzen erfüllt. Da + \$a\textbackslash equiv c\textbackslash{} mod\textbackslash{} n\$ + und \$b\textbackslash equiv c\textbackslash{} mod\textbackslash{} + n \textbackslash Rightarrow a \textbackslash equiv + b\textbackslash{} mod\textbackslash{} n\$ haben wir + \$\textbackslash forall + i\textbackslash in\{1,...,r\}:a\textbackslash equiv + b\textbackslash{} mod\textbackslash{} + m\_i\textbackslash Rightarrow\textbackslash forall + i\textbackslash in\{1,. ...,r\}:m\_i\textbar(a-b) + \textbackslash Rightarrow M\textbar(a-b)\$, da die \$m\_i\$ + paarweise relativ prim sind \$\textbackslash Leftrightarrow + a\textbackslash equiv b\textbackslash{} mod\textbackslash{} M\$ + \end{itemize} + \end{itemize} + \item + Lemma 2: + + \begin{itemize} + \item + Wenn \$gcd(m,n)=1\$, dann ist + \$\textbackslash phi(m\textbackslash times + n)=\textbackslash phi(m)\textbackslash times \textbackslash phi(n)\$ + \item + Der Beweis: + + \begin{itemize} + \item + Sei a eine positive ganze Zahl, die kleiner als und relativ prim + zu \$m\textbackslash times n\$ ist. Mit anderen Worten: a ist eine + der ganzen Zahlen, die von + \$\textbackslash phi(m\textbackslash times n)\$ gezählt werden. + \item + Betrachten Sie die Entsprechung + \$a\textbackslash rightarrow(a\textbackslash{} MOD\textbackslash{} + m, a\textbackslash{} MOD\textbackslash{} n)\$. Die ganze Zahl a + ist relativ prim zu m und relativ prim zu n (andernfalls würde sie + \$m \textbackslash times n\$ teilen). Also ist + \$(a\textbackslash{} MOD\textbackslash{} m)\$ relativ prim zu m + und \$(a\textbackslash{} MOD\textbackslash{} n)\$ ist relativ prim + zu n, da: \$a=\textbackslash lfloor + a/m\textbackslash rfloor\textbackslash times m + + (a\textbackslash{} MOD\textbackslash{} m)\$, wenn es also einen + gemeinsamen Teiler von \$m\$ und \$(a\textbackslash{} + MOD\textbackslash{} m)\$ gäbe, würde dieser Teiler auch a teilen. + Somit entspricht jede Zahl a, die durch + \$\textbackslash phi(m\textbackslash times n )\$ gezählt wird, + einem Paar von zwei ganzen Zahlen \$(a\textbackslash{} + MOD\textbackslash{} m,a\textbackslash{} MOD\textbackslash{} n)\$, + wobei die erste durch \$\textbackslash phi(m)\$ und die zweite + durch \$\textbackslash phi(n)\$ gezählt wird. + \item + Aufgrund des zweiten Teils von Satz 4 ist die Einzigartigkeit der + Lösung \$a\textbackslash{} mod\textbackslash{} + (m\textbackslash times n)\$ der simultanen Kongruenzen: \$a + \textbackslash equiv(a\textbackslash{} mod\textbackslash{} + m)\textbackslash{} mod\textbackslash{} m\$ \$a + \textbackslash equiv(a\textbackslash{} MOD\textbackslash{} + n)\textbackslash{} mod\textbackslash{} n\$ können wir ableiten, + dass verschiedene ganze Zahlen, die durch + \$\textbackslash phi(m\textbackslash times n)\$ gezählt werden, + verschiedenen Paaren entsprechen: + + \begin{itemize} + \item + Um dies zu sehen, nehmen wir an, dass \$a\textbackslash not=b\$, + gezählt durch \$\textbackslash phi(m\textbackslash times n)\$, + demselben Paar \$(a\textbackslash{} MOD\textbackslash{} m, + a\textbackslash{} MOD\textbackslash{} n)\$ entspricht. Dies + führt zu einem Widerspruch, da b auch die Kongruenzen erfüllen + würde: \$b\textbackslash equiv (a\textbackslash{} + MOD\textbackslash{} m)\textbackslash{} mod\textbackslash{} m\$ + \$b\textbackslash equiv (a\textbackslash{} MOD\textbackslash{} + n)\textbackslash{} mod\textbackslash{} n\$ aber die Lösung + dieser Kongruenzen ist eindeutig modulo \$(m + \textbackslash times n)\$ + \item + Daher ist \$\textbackslash phi(m \textbackslash times n)\$ + höchstens die Anzahl solcher Paare: \$\textbackslash phi(m + \textbackslash times n)\textbackslash leq + \textbackslash phi(m)\textbackslash times + \textbackslash phi(n)\$ + \end{itemize} + \item + Betrachten wir nun ein Paar von ganzen Zahlen \$(b,c)\$, von denen + eine mit \$\textbackslash phi(m)\$ und die andere mit + \$\textbackslash phi(n)\$ gezählt wird: Mit Hilfe des ersten Teils + von Satz 4 können wir eine einzige positive ganze Zahl a + konstruieren, die kleiner als und relativ prim zu + \$m\textbackslash times n\$ ist: \$a\textbackslash equiv + b\textbackslash{} mod\textbackslash{} m\$ und + \$a\textbackslash equiv c\textbackslash{} mod\textbackslash{} n\$. + Die Anzahl solcher Paare ist also höchstens \$\textbackslash phi(m + \textbackslash times n):\textbackslash phi(m \textbackslash times + n)\textbackslash leq\textbackslash phi(m)\textbackslash times\textbackslash phi(n)\$ + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Der RSA Public Key + Algorithmus} + + \begin{itemize} + \item + Der RSA-Algorithmus wurde 1977 von R. Rivest, A. Shamir und L. Adleman + {[}RSA78{]} erfunden und basiert auf Theorem 3. + \item + Seien \$p, q\$ verschiedene große Primzahlen und + \$n=p\textbackslash times q\$. Nehmen wir an, wir haben auch zwei + ganze Zahlen e und d, so dass: \$d\textbackslash times e + \textbackslash equiv 1\textbackslash{} mod\textbackslash{} + \textbackslash phi(n)\$ + \item + M sei eine ganze Zahl, die die zu verschlüsselnde Nachricht darstellt, + wobei M positiv, kleiner als und relativ prim zu n ist. + + \begin{itemize} + \item + Beispiel: Verschlüsseln mit = 99, A = 10, B = 11, ..., Z = 35. Somit + würde ,,HELLO'' als 1714212124 kodiert werden. Falls erforderlich, + ist M in Blöcke kleinerer Nachrichten aufzuteilen: 17142 12124 + \end{itemize} + \item + Zum Verschlüsseln berechnen Sie: \$E = M\^{}e\textbackslash{} + MOD\textbackslash{} n\$ + + \begin{itemize} + \item + Dies kann mit dem Quadrat- und Multiplikationsalgorithmus effizient + durchgeführt werden + \end{itemize} + \item + Zum Entschlüsseln berechnet man: \$M'=E\^{}d\textbackslash{} + MOD\textbackslash{} n\$ + + \begin{itemize} + \item + Da \$d\textbackslash times e\textbackslash equiv 1\textbackslash{} + mod\textbackslash{} + \textbackslash phi(n)\textbackslash Rightarrow\textbackslash exists + k\textbackslash in\textbackslash mathbb\{Z\}:(d\textbackslash times + e)-1=k\textbackslash times\textbackslash phi(n)\textbackslash Leftrightarrow(d\textbackslash times + e)=k\textbackslash times\textbackslash phi(n)+1\$ + \item + haben wir: \$M'\textbackslash equiv E\^{}d\textbackslash equiv + M\^{}\{e\textbackslash times d\}\textbackslash equiv + M\^{}\{k\textbackslash times\textbackslash phi(n)+1\}\textbackslash equiv + 1\^{}k\textbackslash times M\textbackslash equiv M\textbackslash{} + mod\textbackslash{} n\$ + \end{itemize} + \item + Da \$(d\textbackslash times e)=(e\textbackslash times d)\$ + funktioniert die Operation auch in umgekehrter Richtung, d.h. man kann + mit d verschlüsseln und mit e entschlüsseln + + \begin{itemize} + \item + Diese Eigenschaft erlaubt es, die gleichen Schlüssel d und e zu + verwenden: + \item + den Empfang von Nachrichten, die mit dem eigenen öffentlichen + Schlüssel verschlüsselt wurden + \item + Senden von Nachrichten, die mit dem eigenen privaten Schlüssel + signiert wurden + \end{itemize} + \item + So richten Sie ein Schlüsselpaar für RSA ein: + + \begin{itemize} + \item + Wählen Sie zufällig zwei Primzahlen \$p\$ und \$q\$ (mit jeweils 100 + bis 200 Ziffern) + \item + Berechne \$n=p\textbackslash times + q,\textbackslash phi(n)=(p-1)\textbackslash times (q-1)\$ (Lemma 2) + \item + Wähle zufällig \$e\$, so dass \$gcd(e,\textbackslash phi(n))=1\$ + \item + Berechne mit dem erweiterten euklidischen Algorithmus d und c, so + dass: \$e\textbackslash times + d+\textbackslash phi(n)\textbackslash times c = 1\$, wobei zu + beachten ist, dass dies impliziert, dass \$e\textbackslash times + d\textbackslash equiv 1\textbackslash{} mod\textbackslash{} + \textbackslash phi(n)\$ + \item + Der öffentliche Schlüssel ist das Paar \$(e, n)\$ + \item + Der private Schlüssel ist das Paar \$(d, n)\$ + \end{itemize} + \item + Die Sicherheit des Verfahrens liegt in der Schwierigkeit der + Faktorisierung von \$n=p\textbackslash times q\$, da es einfach ist, + \$\textbackslash phi(n)\$ und dann \$d\$ zu berechnen, wenn \$p\$ und + \$q\$ bekannt sind. + \item + In diesem Kurs wird nicht gelehrt, warum es schwierig ist, große n zu + faktorisieren, da dies einen tiefen Einblick in die Mathematik + erfordern würde. + + \begin{itemize} + \item + Wenn p und q bestimmte Eigenschaften erfüllen, sind die besten + bekannten Algorithmen exponentiell zur Anzahl der Ziffern von n + \item + Bitte beachten Sie, dass es bei einer unglücklichen Wahl von p und q + Algorithmen geben könnte, die effizienter faktorisieren können, und + dass Ihre RSA-Verschlüsselung dann nicht mehr sicher ist: + + \begin{itemize} + \item + Daher sollten p und q ungefähr die gleiche Bitlänge haben und + ausreichend groß sein + \item + \$(p-q)\$ sollte nicht zu klein sein + \item + Wenn man einen kleinen Verschlüsselungsexponenten, z.B. 3, wählen + will, kann es zusätzliche Einschränkungen geben, z.B. \$gcd(p-1, + 3) = 1\$ und \$gcd(q-1,3)=1\$ + \end{itemize} + \item + Die Sicherheit von RSA hängt auch davon ab, dass die erzeugten + Primzahlen wirklich zufällig sind (wie jede Methode zur + Schlüsselerzeugung bei jedem Algorithmus). + \item + Moral: Wenn Sie RSA selbst implementieren wollen, bitten Sie einen + Mathematiker oder besser einen Kryptographen, Ihren Entwurf zu + überprüfen. + \end{itemize} + \end{itemize} + + + \subsection{Einige weitere mathematische + Hintergründe} + + \begin{itemize} + \item + Definition: endliche Gruppen + + \begin{itemize} + \item + Eine Gruppe ( S , \textbackslash oplus) ist eine Menge S zusammen + mit einer binären Operation \textbackslash oplus, für die die + folgende Eigenschaften gelten: + + \begin{itemize} + \item + Geschlossenheit: Für alle a, b \textbackslash in S , haben wir a + \textbackslash oplus b \textbackslash in S + \item + Identität: Es gibt ein Element e \textbackslash in S , so dass e + \textbackslash oplus a = a \textbackslash oplus e = a für alle a + \textbackslash in S + \item + Assoziativität: Für alle a, b, c \textbackslash in S , gilt ( a + \textbackslash oplus b ) \textbackslash oplus c = a + \textbackslash oplus ( b \textbackslash oplus c ) + \item + Inversen: Für jedes a \textbackslash in S , gibt es ein einziges + Element b \textbackslash in S , so dass dass a + \textbackslash oplus b = b \textbackslash oplus a = e + \end{itemize} + \item + Erfüllt eine Gruppe ( S , \textbackslash oplus) das Kommutativgesetz + \textbackslash forall a, b \textbackslash in S : a + \textbackslash oplus b = b \textbackslash oplus a dann nennt man sie + eine abelsche Gruppe + \item + Wenn eine Gruppe ( S , \textbackslash oplus) nur eine endliche Menge + von Elementen hat, d.h. \textbar S\textbar{} \textless{} + \textbackslash infty, dann wird sie eine endliche Gruppe genannt + \end{itemize} + \item + Beispiele: + + \begin{itemize} + \item + \$(\textbackslash mathbb\{Z\}\_n , +\_n)\$ + + \begin{itemize} + \item + mit + \$\textbackslash mathbb\{Z\}\_n:=\{{[}0{]}\_n,{[}1{]}\_n,...,{[}n-1{]}\_n\}\$ + \item + wobei \${[}a{]}\_n:=\{b \textbackslash in + \textbackslash mathbb\{Z\} \textbar{} b \textbackslash equiv a mod + n\}\$ und + \item + \$+\_n\$ ist so definiert, dass + \${[}a{]}\_n+\_n{[}b{]}\_n={[}a+b{]}\_n\$ + \item + eine endliche abelsche Gruppe ist. Für den Beweis siehe die + Tabelle mit den Eigenschaften der modularen Arithmetik + \end{itemize} + \item + \$(\textbackslash mathbb\{Z\}\^{}*\_n , \textbackslash times\_n)\$ + + \begin{itemize} + \item + mit \$\textbackslash mathbb\{Z\}\^{}*\_n + :=\{{[}a{]}\_n\textbackslash in \textbackslash mathbb\{Z\}\_n + \textbar{} gcd(a,n)=1\}\$, und + \item + \$\textbackslash times\_n\$ ist so definiert, dass + \${[}a{]}\_n\textbackslash times\_n + {[}b{]}\_n={[}a\textbackslash times b{]}\_n\$ + \item + eine endliche abelsche Gruppe ist. Man beachte, dass + \$\textbackslash mathbb\{Z\}\^{}*\_n\$ nur die Elemente von + \$\textbackslash mathbb\{Z\}\_n\$ enthält, die eine multiplikative + Inverse modulo n haben. Zum Beweis siehe Eigenschaften der + modularen Arithmetik + \item + Beispiel: + \$\textbackslash mathbb\{Z\}\^{}*\emph{\{15\}=\{{[}1{]}}\{15\},{[}2{]}\emph{\{15\},{[}4{]}}\{15\},{[}7{]}\emph{\{15\},{[}8{]}}\{15\},{[}11{]}\emph{\{15\},{[}13{]}}\{15\},{[}14{]}\_\{15\}\}\$, + als \$1\textbackslash times 1\textbackslash equiv 1 mod 15\$, \$2 + \textbackslash times 8 \textbackslash equiv 1 mod 15\$, \$4 + \textbackslash times 4 \textbackslash equiv 1 mod 15\$, \$7 + \textbackslash times 13 \textbackslash equiv 1 mod 15\$, \$11 + \textbackslash times 11 \textbackslash equiv 1 mod 15\$, \$14 + \textbackslash times 14 \textbackslash equiv 1 mod 15\$ + \end{itemize} + \end{itemize} + \item + Wenn klar ist, dass es sich um \$(\textbackslash mathbb\{Z\}\_n, + +\_n)\$ oder \$(\textbackslash mathbb\{Z\}\^{}*\_n, + \textbackslash times\_n)\$ handelt, werden Äquivalenzklassen + \${[}a{]}\_n\$ oft durch ihre repräsentativen Elemente a dargestellt + und \$+\_n\$ und \$\textbackslash times\_n\$ durch \$+\$ bzw. + \$\textbackslash times\$ bezeichnet. + + \begin{itemize} + \item + Definition: endliche Felder + + \begin{itemize} + \item + Ein Feld \$(S,\textbackslash oplus, \textbackslash otimes)\$ ist + eine Menge S zusammen mit zwei Operationen + \$\textbackslash oplus\$, \$\textbackslash otimes\$, so dass + + \begin{itemize} + \item + \$(S,\textbackslash oplus)\$ und + \$(S\textbackslash backslash\{e\_\{\textbackslash oplus\}\},\textbackslash otimes)\$ + sind kommutative Gruppen, d.h. nur das Identitätselement + bezüglich der Operation \$\textbackslash oplus\$ muss kein + Inverses bezüglich der Operation \$\textbackslash otimes\$ haben + \item + Für alle \$a,b,c\textbackslash in S\$ haben wir ein + \$\textbackslash otimes(b\textbackslash oplus + c)=(a\textbackslash otimes + b)\textbackslash oplus(a\textbackslash otimes c)\$ + \end{itemize} + \end{itemize} + \item + Wenn \$\textbar S\textbar\textless\textbackslash infty\$ dann heißt + \$(S,\textbackslash oplus,\textbackslash otimes)\$ ein endliches + Feld + \end{itemize} + \item + Beispiel: \$(\textbackslash mathbb\{Z\}\_p, +\_p, + \textbackslash times\_p)\$ ist ein endliches Feld für jede Primzahl p + \item + Definition: Primitive Wurzel, Generator + + \begin{itemize} + \item + Sei \$(S,\textbackslash circ)\$ eine Gruppe, \$g\textbackslash in + S\$ und \$g\^{}a:=g\textbackslash circ + g\textbackslash circ...\textbackslash circ g\$ (a mal mit + \$a\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$) + \item + Dann heißt g eine primitive Wurzel oder ein Generator von + \$(S,\textbackslash circ):\textbackslash Leftrightarrow\{g\^{}a\textbar1\textbackslash leq + a\textbackslash leq \textbar S\textbar\}=S\$ + \item + Beispiele: + + \begin{itemize} + \item + 1 ist eine primitive Wurzel von \$(\textbackslash mathbb\{Z\}\_n, + +\_n)\$ + \item + 3 ist eine Primitivwurzel von + \$(\textbackslash mathbb\{Z\}\^{}*\_7, \textbackslash times\_7)\$ + \end{itemize} + \item + Nicht alle Gruppen haben Primitivwurzeln, und diejenigen, die sie + haben, nennt man zyklische Gruppen + \end{itemize} + \item + Theorem 5: + + \begin{itemize} + \item + \$(\textbackslash mathbb\{Z\}\^{}*\_n, \textbackslash times\_n)\$ + hat eine primitive Wurzel \$\textbackslash Leftrightarrow + n\textbackslash in\{2,4,p,2\textbackslash times p\^{}e\}\$, wobei p + eine ungerade Primzahl ist und + \$e\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ + \end{itemize} + \item + Theorem 6: + + \begin{itemize} + \item + Wenn \$(S,\textbackslash circ)\$ eine Gruppe ist und + \$b\textbackslash in S\$, dann ist \$(S',\textbackslash circ)\$ mit + \$S'=\{b\^{}a\textbar a\textbackslash in\textbackslash mathbb\{Z\}\^{}+\}\$ + ebenfalls eine Gruppe. + \item + Da \$S'\textbackslash subseteq S, heißt (S',\textbackslash circ)\$ + eine Untergruppe von \$(S,\textbackslash circ)\$ + \item + Wenn b eine Urwurzel von \$(S,\textbackslash circ)\$ ist, dann ist + \$S'=S\$ + \end{itemize} + \item + Definition: Ordnung einer Gruppe und eines Elements + + \begin{itemize} + \item + Sei \$(S,\textbackslash circ)\$ eine Gruppe, \$e\textbackslash in + S\$ ihr Identitätselement und \$b\textbackslash in S\$ irgendein + Element von \$S\$: + + \begin{itemize} + \item + Dann heiße \$\textbar S\textbar\$ die Ordnung von + \$(S,\textbackslash circ)\$ + \item + Sei \$c\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ das + kleinste Element, so dass \$b\^{}c=e\$ ist (falls ein solches c + existiert, falls nicht, setze \$c=\textbackslash infty\$). Dann + wird c die Ordnung von b genannt. + \end{itemize} + \end{itemize} + \item + Theorem 7 (Lagrange): + + \begin{itemize} + \item + Ist G eine endliche Gruppe und H eine Untergruppe von G , so ist + \$\textbar H\textbar\$ Teiler von \$\textbar G\textbar\$. + \item + Wenn also \$b in G\$ ist, dann ist die Ordnung von b Teiler von + \$\textbar G\textbar\$. + \end{itemize} + \item + Theorem 8: + + \begin{itemize} + \item + Ist G eine zyklische endliche Gruppe der Ordnung n und d ist Teiler + von n, dann hat G genau \$\textbackslash phi(d)\$ Elemente der + Ordnung \$d\$. Insbesondere hat G \$\textbackslash phi(n)\$-Elemente + der Ordnung n. + \end{itemize} + \item + Die Theoreme 5, 7 und 8 sind die Grundlage des folgenden Algorithmus, + der eine zyklische Gruppe \$\textbackslash mathbb\{Z\}\^{}*\_p\$ und + eine Urwurzel g davon findet: + + \begin{itemize} + \item + Man wählt eine große Primzahl q, so dass \$p=2q+1\$ eine Primzahl + ist. + + \begin{itemize} + \item + Da \$p\$ prim ist, besagt Satz 5, dass + \$\textbackslash mathbb\{Z\}\^{}*\_p\$ zyklisch ist. + \item + Die Ordnung von \$\textbackslash mathbb\{Z\}\^{}*\_p\$ ist + \$2\textbackslash times q\$ und + \$\textbackslash phi(2\textbackslash times + q)=\textbackslash phi(2)\textbackslash times + \textbackslash phi(q)=q-1\$, da \$q\$ prim ist. + \item + Die Wahrscheinlichkeit, dass eine Primitivwurzel zufällig + ausgewählt wird, beträgt also \$(q-1)/2q \textbackslash approx + 1/2\$. + \item + Um effizient zu prüfen, ob ein zufällig gewähltes g eine Urwurzel + ist, müssen wir nur prüfen, ob \$g\^{}2\textbackslash equiv 1 mod + p\$ oder \$g\^{}q\textbackslash equiv 1 mod p\$ ist. Wenn nicht, + dann muss seine Ordnung + \$\textbar\textbackslash mathbb\{Z\}\^{}\emph{\_p\textbar\$ sein, + da Satz 7 besagt, dass die Ordnung von g + \$\textbar\textbackslash mathbb\{Z\}\^{}}\_p\textbar\$ teilen muss + \end{itemize} + \end{itemize} + \item + Definition: diskreter Logarithmus + + \begin{itemize} + \item + Sei p eine Primzahl, g eine Urwurzel von + \$(\textbackslash mathbb\{Z\}\^{}\emph{\_p,\textbackslash times\_p)\$ + und c ein beliebiges Element von + \$\textbackslash mathbb\{Z\}\^{}}\_p\$. Dann gibt es z so, dass: + \$g\^{}z\textbackslash equiv c mod p\$ + \item + z wird der diskrete Logarithmus von c modulo p zur Basis g genannt + \item + Beispiel 6 ist der diskrete Logarithmus von 1 modulo 7 zur Basis 3 + als \$3\^{}6\textbackslash equiv 1 mod 7\$ + \item + Die Berechnung des diskreten Logarithmus z bei gegebenem g, c und p + ist ein rechnerisch schwieriges Problem, und die asymptotische + Laufzeit der besten bekannten Algorithmen für dieses Problem ist + exponentiell zur Bitlänge von p + \end{itemize} + \end{itemize} + + + \subsection{Diffie-Hellman-Schlüsselaustausch} + + \begin{itemize} + \item + Der Diffie-Hellman-Schlüsselaustausch wurde erstmals in der + bahnbrechenden Arbeit {[}DH76{]} veröffentlicht, in der auch die + Grundidee der asymmetrischen Kryptographie vorgestellt wurde + \item + Der DH-Austausch in seiner Grundform ermöglicht es zwei Parteien A und + B, sich über einen öffentlichen Kanal auf ein gemeinsames Geheimnis zu + einigen: + + \begin{itemize} + \item + Öffentlicher Kanal bedeutet, dass ein potentieller Angreifer E (E + steht für Eavesdropper) alle zwischen A und B ausgetauschten + Nachrichten lesen kann + \item + Es ist wichtig, dass A und B sicher sein können, dass der Angreifer + nicht in der Lage ist, Nachrichten zu verändern, da er in diesem + Fall einen Man-in-the-Middle-Angriff starten könnte + \item + Die mathematische Grundlage für den DH-Austausch ist das Problem, + diskrete Logarithmen in endlichen Feldern zu finden. + \item + Der DH-Austausch ist kein asymmetrischer + Verschlüsselungsalgorithmus, wird aber dennoch hier vorgestellt, da + er gut zum mathematischen Charakter dieser Vorlesung passt... + \end{itemize} + \item + Wenn Alice (A) und Bob (B) sich auf ein gemeinsames Geheimnis s + einigen wollen und ihr einziges Kommunikationsmittel ein öffentlicher + Kanal ist, können sie wie folgt vorgehen: + + \begin{itemize} + \item + A wählt eine Primzahl p, eine primitive Wurzel g von + \$\textbackslash mathbb\{Z\}\^{}*\_p\$ und eine Zufallszahl q: + + \begin{itemize} + \item + A und B können sich vor der Kommunikation auf die Werte p und g + einigen, oder A wählt p und g und sendet sie mit seiner ersten + Nachricht + \item + A berechnet \$v=g\^{}q\textbackslash{} MOD\textbackslash{} p\$ und + sendet an \$B:\{p,g,v\}\$ + \end{itemize} + \item + B wählt eine Zufallszahl r: + + \begin{itemize} + \item + B berechnet \$w=g\^{}r\textbackslash{} MOD\textbackslash{} p\$ und + sendet an \$A:\{p,g,w\}\$ (oder einfach \$\{w\}\$) + \end{itemize} + \item + Beide Seiten errechnen das gemeinsame Geheimnis: + + \begin{itemize} + \item + A errechnet \$s=w\^{}q\textbackslash{} MOD\textbackslash{} p\$ + \item + B errechnet \$s'=v\^{}r\textbackslash{} MOD\textbackslash{} p\$ + \item + Da \$g\^{}\{q\textbackslash times r\}\textbackslash{} + MOD\textbackslash{} p = g\^{}\{r \textbackslash times + q\}\textbackslash{} MOD\textbackslash{} p\$ ist, gilt: \$s=s'\$ + \end{itemize} + \item + Ein Angreifer Eve, der den öffentlichen Kanal abhört, kann das + Geheimnis s nur berechnen, wenn er entweder q oder r berechnen kann, + die die diskreten Logarithmen von v, w modulo p zur Basis g sind. + \end{itemize} + \item + Wenn der Angreifer Eve in der Lage ist, Nachrichten auf dem + öffentlichen Kanal zu verändern, kann er einen + Man-in-the-Middle-Angriff starten: + + \begin{itemize} + \item + Eve generiert zwei Zufallszahlen \$q'\$ und \$r'\$: Eve berechnet + \$v'=g\^{}\{q'\}\textbackslash{} MOD\textbackslash{} p\$ und + \$w'=g\^{}\{r'\}\textbackslash{} MOD\textbackslash{} p\$ + \item + Wenn A \$\{p,g,v\}\$ sendet, fängt sie die Nachricht ab und sendet + an \$B:\{p,g,v'\}\$ + \item + Wenn B \$\{p,g,w\}\$ sendet, fängt sie die Nachricht ab und sendet + an \$A:\{p,g,w'\}\$ + \item + Wenn das angebliche ,,gemeinsame Geheimnis'' berechnet wird, + erhalten wir: + + \begin{itemize} + \item + A berechnet \$s\_1=w'\^{}q\textbackslash{} MOD\textbackslash{} p = + v\^{}\{r'\}\textbackslash{} MOD\textbackslash{} p\$, letzteres + berechnet von E + \item + B berechnet \$s\_2=v'\^{}r\textbackslash{} MOD\textbackslash{} p = + w\^{}\{q'\}\textbackslash{} MOD\textbackslash{} p\$, letzteres + berechnet von E + \item + A und E haben sich also auf ein gemeinsames Geheimnis \$s\_1\$ + geeinigt, und E und B haben sich auf ein gemeinsames Geheimnis + \$s\_2\$ geeinigt. + \end{itemize} + \item + Wenn das ,,gemeinsame Geheimnis'' nun von A und B verwendet wird, um + Nachrichten zu verschlüsseln, die über den öffentlichen Kanal + ausgetauscht werden sollen, kann E alle Nachrichten abfangen und + ent- bzw. wiederverschlüsseln, bevor er sie zwischen A und B + weiterleitet. + \end{itemize} + \item + Zwei Gegenmaßnahmen gegen den Man-in-the-Middle-Angriff: + + \begin{itemize} + \item + Das gemeinsame Geheimnis wird ,,authentifiziert'', nachdem es + vereinbart worden ist. + + \begin{itemize} + \item + Wir werden dies im Abschnitt über die Schlüsselverwaltung + behandeln + \end{itemize} + \item + A und B verwenden ein sogenanntes Interlock-Protokoll, nachdem sie + sich auf ein gemeinsames Geheimnis geeinigt haben: + + \begin{itemize} + \item + Dazu müssen sie Nachrichten austauschen, die E weiterleiten muss, + bevor sie sie entschlüsseln bzw. wieder verschlüsseln kann. + \item + Der Inhalt dieser Nachrichten muss von A und B überprüfbar sein. + \item + Dies zwingt E dazu, Nachrichten zu erfinden, und sie kann entdeckt + werden. + \item + Eine Technik, um zu verhindern, dass E die Nachrichten + entschlüsselt, besteht darin, sie in zwei Teile aufzuteilen und + den zweiten Teil vor dem ersten zu senden. + + \begin{itemize} + \item + Wenn der verwendete Verschlüsselungsalgorithmus bestimmte + Eigenschaften verhindert, kann E den zweiten Teil nicht + verschlüsseln, bevor sie den ersten erhält. + \item + Da A den ersten Teil erst senden wird, nachdem er eine Antwort + (den zweiten Teil) von B erhalten hat, ist E gezwungen, zwei + Nachrichten zu erfinden, bevor sie die ersten Teile erhalten + kann. + \end{itemize} + \end{itemize} + \end{itemize} + \item + Bemerkung: In der Praxis muss die Zahl g nicht unbedingt eine Urwurzel + von p sein, es genügt, wenn sie eine große Untergruppe von + \$\textbackslash mathbb\{Z\}\^{}*\_p\$ erzeugt + \end{itemize} + + + \subsection{ElGamal Algorithmus} + + \begin{itemize} + \item + Der ElGamal-Algorithmus kann sowohl für die Verschlüsselung als auch + für digitale Signaturen verwendet werden (siehe auch {[}ElG85a{]}). + \item + Wie der DH-Austausch basiert er auf der Schwierigkeit, diskrete + Logarithmen in endlichen Feldern zu berechnen + \item + Um ein Schlüsselpaar zu erstellen: + + \begin{itemize} + \item + Wähle eine große Primzahl p, einen Generator g der multiplikativen + Gruppe \$\textbackslash mathbb\{Z\}\^{}*\_p\$ und eine Zufallszahl + v, so dass \$1\textbackslash leq v\textbackslash leq p - 2\$. + Berechnen Sie: \$y=g\^{}v mod p\$ + \item + Der öffentliche Schlüssel ist \$( y, g, p )\$ + \item + Der private Schlüssel ist v + \end{itemize} + \item + So signieren Sie eine Nachricht m : + + \begin{itemize} + \item + Wähle eine Zufallszahl k so, dass k relativ prim zu \$p-1\$ ist. + \item + Berechne \$r=g\^{}k mod p\$ + \item + Berechne mit dem erweiterten euklidischen Algorithmus + \$k\^{}\{-1\}\$, den Kehrwert von \$k mod (p - 1)\$ + \item + Berechne \$s=k\^{}\{-1\} \textbackslash times ( m - v + \textbackslash times r) mod ( p - 1)\$ + \item + Die Signatur über die Nachricht ist \$( r, s )\$ + \end{itemize} + \item + Überprüfen einer Signatur \$( r , s )\$ über eine Nachricht m: + + \begin{itemize} + \item + Bestätige, dass \$y\^{}r \textbackslash times r\^{}s\textbackslash{} + MOD\textbackslash{} p = g\^{}m\textbackslash{} MOD\textbackslash{} + p\$ + \item + Der Beweis: Wir benötigen Folgendes + + \begin{itemize} + \item + Lemma 3: Sei p eine Primzahl und g ein Generator von + \$\textbackslash mathbb\{Z\}\^{}*\_p\$. Dann sei \$i + \textbackslash equiv j mod ( p -1) \textbackslash Rightarrow g i + \textbackslash equiv g j mod p\$ + \item + Beweis: \$i \textbackslash equiv j mod (p-1) + \textbackslash Rightarrow\$ es gibt \$k\textbackslash in + \textbackslash mathbb\{Z\}\^{}+\$ so, dass + \$(i-j)=(p-1)\textbackslash times k\$ + \item + Also \$g\^{}\{(i-j)\}=g\^{}\{(p-1)\textbackslash times k\} + \textbackslash equiv 1\^{}k\textbackslash equiv 1 mod p\$, wegen + Theorem 3 (Euler) \$\textbackslash Rightarrow g\^{}i + \textbackslash equiv g\^{}j mod p\$ + \end{itemize} + \item + Als \$s\textbackslash equiv + k\^{}\{-1\}\textbackslash times(m-v\textbackslash times r) mod + (p-1)\$ + + \begin{itemize} + \item + \$\textbackslash Leftrightarrow k \textbackslash times + s\textbackslash equiv m-v\textbackslash times r mod (p-1)\$ + \item + \$\textbackslash Leftrightarrow m \textbackslash equiv + v\textbackslash times r+k\textbackslash times s mod (p-1)\$ + \item + \$\textbackslash Rightarrow g\^{}m \textbackslash equiv + g\^{}\{(v\textbackslash times r+ k\textbackslash times s)\} mod + p\$ mit Lemma 3 + \item + \$\textbackslash Leftrightarrow g\^{}m \textbackslash equiv + g\^{}\{(v\textbackslash times r)\}\textbackslash times + g\^{}\{(k\textbackslash times s)\} mod p\$ + \item + \$\textbackslash Leftrightarrow g\^{}m \textbackslash equiv + y\^{}r\textbackslash times r\^{}s mod p\$ + \end{itemize} + \end{itemize} + \item + Sicherheit von ElGamal-Signaturen: + + \begin{itemize} + \item + Da der private Schlüssel v benötigt wird, um s berechnen zu können, + müsste ein Angreifer den diskreten Logarithmus von y modulo p zur + Basis g berechnen, um Signaturen zu fälschen + \item + Entscheidend für die Sicherheit ist, dass für jede Nachricht eine + neue Zufallszahl k gewählt wird, denn ein Angreifer kann das + Geheimnis v berechnen, wenn er zwei Nachrichten zusammen mit ihren + Signaturen auf der Basis des gleichen k erhält (siehe {[}Men97a{]}, + Anmerkung 11.66.ii) + \item + Um zu verhindern, dass ein Angreifer eine Nachricht M mit einer + passenden Signatur erstellen kann, ist es notwendig, die Nachricht M + nicht direkt zu signieren, sondern einen kryptographischen Hashwert + \$m=h(M)\$ davon zu signieren (diese werden bald behandelt, siehe + auch {[}Men97a{]}, Anmerkung 11.66.iii) + \end{itemize} + \item + Um eine Nachricht m mit dem öffentlichen Schlüssel \$(y,g,p)\$ zu + verschlüsseln: + + \begin{itemize} + \item + Wähle einen zufälligen + \$k\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ mit + \$k\textless p-1\$ + \item + Berechne \$r=g\^{}k\textbackslash{} MOD\textbackslash{} p\$ + \item + Berechne \$s=m\textbackslash times y\^{}k\textbackslash{} + MOD\textbackslash{} p\$ + \item + Der verschlüsselte Text ist \$(r,s)\$, der doppelt so lang ist wie m + \end{itemize} + \item + Entschlüsseln der Nachricht \$(r,s)\$ mit v: + + \begin{itemize} + \item + Verwenden Sie den privaten Schlüssel v zur Berechnung von + \$r\^{}\{(p-1-v)\}\textbackslash{} MOD\textbackslash{} + p=r\^{}\{(-v)\}\textbackslash{} MOD\textbackslash{} p\$ + \item + Wiederherstellung von m durch Berechnung von + \$m=r\^{}\{(-v)\}\textbackslash times s\textbackslash{} + MOD\textbackslash{} p\$ + \item + Beweis: \$r\^{}\{(-v)\}\textbackslash times s\textbackslash equiv + r\^{}\{(-v)\} \textbackslash times m \textbackslash times + y\^{}k\textbackslash equiv g\^{}\{(-vk)\}\textbackslash times m + \textbackslash times y\^{}k\textbackslash equiv g\^{}\{(-v + \textbackslash times k)\} \textbackslash times m\textbackslash times + g\^{}\{(v \textbackslash times k)\} \textbackslash equiv m mod p\$ + \end{itemize} + \item + Sicherheit: + + \begin{itemize} + \item + Die einzige bekannte Möglichkeit für einen Angreifer, m + wiederherzustellen, ist die Berechnung des diskreten Logarithmus v + von y modulo p zur Basis g + \item + Für jede Nachricht wird ein neues zufälliges k benötigt + ({[}Men97a{]}, Anmerkung 8.23.ii) + \end{itemize} + \end{itemize} + + + \subsection{Elliptische Kurven + Kryptographie} + + \begin{itemize} + \item + Die bisher vorgestellten Algorithmen wurden für die multiplikative + Gruppe \$(\textbackslash mathbb\{Z\}\^{}*\_p,\textbackslash times p)\$ + bzw. das Feld \$(\textbackslash mathbb\{Z\}\_p, +\_p, + \textbackslash times\_p)\$ entwickelt. + \item + In den 1980er Jahren wurde festgestellt, dass sie verallgemeinert und + auch für andere Gruppen und Felder verwendet werden können + \item + Die Hauptmotivation für diese Verallgemeinerung ist: + + \begin{itemize} + \item + Zahlreiche mathematische Forschungen auf dem Gebiet der + Primzahlprüfung, der Faktorisierung und der Berechnung diskreter + Logarithmen haben zu Techniken geführt, mit denen diese Probleme + effizienter gelöst werden können, wenn bestimmte Eigenschaften + erfüllt sind: + + \begin{itemize} + \item + Als 1977 die RSA-129-Aufgabe gestellt wurde, ging man davon aus, + dass es etwa 40 Billiarden Jahre dauern würde, die 129-stellige + Zahl (\$\textbackslash approx 428\$ Bit) zu faktorisieren. + \item + Im Jahr 1994 benötigte eine Gruppe von Computern, die über das + Internet vernetzt waren, 8 Monate, um die Zahl zu faktorisieren, + was etwa 5000 MIPS-Jahre entsprach. + \item + Fortschritte bei den Faktorisierungsalgorithmen ermöglichten 2009 + die Faktorisierung einer 232-stelligen Zahl (768 Bit) in etwa 1500 + AMD64-Jahren {[}KAFL10{]}. + \item + \$\textbackslash Rightarrow\$ die Schlüssellänge muss erhöht + werden (derzeit etwa 2048 Bit) + \end{itemize} + \item + Einige der effizienteren Verfahren beruhen auf bestimmten + Eigenschaften der algebraischen Strukturen + \$(\textbackslash mathbb\{Z\}\^{}*\_p,\textbackslash times p)\$ und + \$(\textbackslash mathbb\{Z\}\_p, +\_p, \textbackslash times\_p)\$ + \item + Verschiedene algebraische Strukturen können daher die gleiche + Sicherheit mit kürzeren Schlüssellängen bieten + \end{itemize} + \item + Eine sehr vielversprechende Struktur für die Kryptographie lässt sich + aus der Gruppe der Punkte auf einer elliptischen Kurve über einem + endlichen Feld gewinnen + + \begin{itemize} + \item + Die mathematischen Operationen in diesen Gruppen können sowohl in + Hardware als auch in Software effizient implementiert werden. + \item + Das Problem des diskreten Logarithmus gilt in der allgemeinen + Klasse, die sich aus der Gruppe der Punkte auf einer elliptischen + Kurve über einem endlichen Feld ergibt, als schwierig + \end{itemize} + \end{itemize} + + + \subsubsection{Gruppenelemente} + + \begin{itemize} + \item + Algebraische Gruppe bestehend aus + + \begin{itemize} + \item + Punkte auf der Weierstraß'schen Gleichung: \$y\^{}2 = x\^{}3 + ax + + b\$ + \item + Zusätzlicher Punkt O im ,,Unendlichen'' + \end{itemize} + \item + Kann über \$\textbackslash mathbb\{R\}\$ berechnet werden, aber in der + Kryptographie werden \$\textbackslash mathbb\{Z\}\_p\$ und + \$GF(2\^{}n)\$ verwendet + + \begin{itemize} + \item + Schon in \$\textbackslash mathbb\{R\}\$ beeinflussen Argumente die + Form erheblich: + + \begin{itemize} + \item + \$y\^{}2 = x\^{}3-3x+5\$ + % \includegraphics{Assets/NetworkSecurity-ecc-1.png} + \item + \$y\^{}2 = x\^{}3-40x+5\$ + % \includegraphics{Assets/NetworkSecurity-ecc-2.png} + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsubsection{Punktaddition} + + \begin{itemize} + \item + Addition von Elementen = Addition von Punkten auf der Kurve + \item + Geometrische Interpretation: + + \begin{itemize} + \item + Jeder Punkt \$P:(x,y)\$ hat einen Kehrwert \$-P:(x,-y)\$ + \item + Eine Linie durch zwei Punkte P und Q schneidet sich normalerweise + mit einem dritten Punkt R + \item + Im Allgemeinen ist die Summe von zwei Punkten P und Q gleich \$-R\$ + \item + % \includegraphics{Assets/NetworkSecurity-ecc-3.png} + \end{itemize} + \item + Addition (Sonderfälle) + + \begin{itemize} + \item + Der zusätzliche Punkt O ist das neutrale Element, d.h. \$P+O=P\$ + \item + \$P + (-P)\$: + + \begin{itemize} + \item + Wird der inverse Punkt zu P addiert, schneiden sich Linie und + Kurve im ,,Unendlichen'' + \item + Per Definition: \$P+(-P) = O\$ + \end{itemize} + \item + \$P+P\$: Die Summe zweier identischer Punkte P ist der Kehrwert des + Schnittpunkts mit der Tangente durch P: + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ecc-4.png} + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsubsection{Grundlagen des ECC - Algebraische + Addition} + + \begin{itemize} + \item + Wenn einer der Summanden O ist, ist die Summe der andere Summand + \item + Wenn die Summanden zueinander invers sind, ist die Summe O + \item + Für die allgemeineren Fälle ist die Steigung der Geraden: + \$\textbackslash alpha=\textbackslash begin\{cases\} + \textbackslash frac\{y\_Q-y\_P\}\{x\_Q-x\_P\} + \textbackslash quad\textbackslash text\{ for \} P\textbackslash not=-Q + \textbackslash keil P\textbackslash not=Q \textbackslash{} + \textbackslash frac\{3x\^{}2\_P +a\}\{2y\_P\} + \textbackslash quad\textbackslash text\{ for \} P=Q + \textbackslash end\{cases\}\$ + \item + Ergebnis der Punktaddition, wobei \$(x\_r,y\_r)\$ bereits der + Spiegelpunkt \$(-R)\$ ist + \end{itemize} + + + \subsubsection{Multiplikation} + + \begin{itemize} + \item + Multiplikation von natürlicher Zahl n und Punkt P durch mehrfache + wiederholte Additionen + \item + Zahlen werden in 2er-Potenzen gruppiert, um eine logarithmische + Laufzeit zu erreichen, z.B. \$25P = P + 8P + 16P\$ + \item + Dies ist nur möglich, wenn das n bekannt ist! + \item + Wenn n für \$nP = Q\$ unbekannt ist, muss ein Logarithmus gelöst + werden, was möglich ist, wenn die Koordinatenwerte aus + \$\textbackslash mathbb\{R\}\$ gewählt werden + \item + Für \$\textbackslash mathbb\{Z\}\_p\$ und \$GF(2\^{}n)\$ muss das + diskrete Logarithmusproblem für elliptische Kurven gelöst werden, was + nicht effizient durchgeführt werden kann! + \item + Hinweis: Es ist nicht definiert, wie zwei Punkte multipliziert werden, + sondern nur eine natürliche Zahl n und der Punkt P + \end{itemize} + + + \subsubsection{Kurven über + \$\textbackslash mathbb\{Z\}\_p\$} + + \begin{itemize} + \item + Über \$\textbackslash mathbb\{Z\}\_p\$ zerfällt die Kurve in eine + Menge von Punkten + \item + Für: \$y\^{}2=x\^{}3-3x+5\textbackslash{} mod\textbackslash{} 19\$ + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ecc-5.png} + \item + Hinweis: Für einige x-Werte gibt es keinen y-Wert! + \end{itemize} + \end{itemize} + + + \subsubsection{Berechnen Sie die y-Werte in + \$\textbackslash mathbb\{Z\}\_p\$} + + \begin{itemize} + \item + Im Allgemeinen etwas problematischer: Bestimmen Sie die y-Werte für + ein gegebenes x (da sein quadratischer Wert berechnet wird) durch + \$y\^{}2\textbackslash equiv f(x)\textbackslash{} mod\textbackslash{} + p\$ + \item + Daher wird p oft s.t. gewählt \$p\textbackslash equiv + 3\textbackslash{} mod\textbackslash{} 4\$ + \item + Dann wird y durch \$y\_1\textbackslash equiv + f(x)\^{}\{\textbackslash frac\{p+1\}\{4\}\}\$ und + \$y\_2\textbackslash equiv + -f(x)\^{}\{\textbackslash frac\{p+1\}\{4\}\}\$ berechnet, wenn und nur + wenn überhaupt eine Lösung existiert + \item + Kurzer Beweis: + + \begin{itemize} + \item + Aus dem Euler-Theorem 3 wissen wir, dass + \$f(x)\^{}\{p-1\}\textbackslash equiv 1\textbackslash{} + mod\textbackslash{} p\$ + \item + Die Quadratwurzel muss also 1 oder -1 sein + \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv\textbackslash pm + 1\textbackslash{} mod\textbackslash{} p\$ + \end{itemize} + \item + Fall 1: + \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv1\textbackslash{} + mod\textbackslash{} p\$ + + \begin{itemize} + \item + Multiplizieren Sie beide Seiten mit f(x): + \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv + f(x)\textbackslash equiv y\^{}2\textbackslash{} mod\textbackslash{} + p\$ + \item + Da \$p + 1\$ durch 4 teilbar ist, können wir die Quadratwurzel + ziehen, so dass + \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv + y\textbackslash{} mod\textbackslash{} p\$ + \end{itemize} + \item + Fall 2: In diesem Fall existiert keine Lösung für den gegebenen x-Wert + (wie von Euler gezeigt) + \end{itemize} + + + \subsubsection{Addition und Multiplikation in + \$\textbackslash mathbb\{Z\}\_p\$} + + \begin{itemize} + \item + Aufgrund des diskreten Strukturpunktes haben mathematische Operationen + keine geometrische Interpretation mehr, sondern + \item + Algebraische Addition ähnlich der Addition über + \$\textbackslash mathbb\{R\}\$ + \item + Wird der inverse Punkt zu P addiert, schneiden sich Linie und + ,,Kurve'' immer noch im ,,Unendlichen'' + \item + Alle x- und y-Werte werden mod p berechnet + \item + Division wird durch Multiplikation mit dem inversen Element des + Nenners ersetzt + + \begin{itemize} + \item + Verwendung des erweiterten euklidischen Algorithmus mit w und p zur + Ableitung der Inversen \$-w\$ + \end{itemize} + \item + Die algebraische Multiplikation einer natürlichen Zahl n und eines + Punktes P erfolgt ebenfalls durch wiederholte Addition von Summanden + der Potenz von 2 + \item + Das Problem des diskreten Logarithmus ist die Bestimmung einer + natürlichen Zahl n in \$nP=Q\$ für zwei bekannte Punkte P und Q + \end{itemize} + + + \subsubsection{Foundations of ECC - Größe der erzeugten + Gruppen} + + \begin{itemize} + \item + Bitte beachten Sie, dass die Ordnung einer durch einen Punkt auf einer + Kurve über \$\textbackslash mathbb\{Z\}\_p\$ erzeugten Gruppe nicht + \$p-1\$ ist! + \item + Die Bestimmung der exakten Ordnung ist nicht einfach, kann aber mit + Schoofs Algorithmus {[}Sch85{]} in logarithmischer Zeit durchgeführt + werden (erfordert viel mehr mathematischen Hintergrund als hier + gewünscht) + \item + Der Satz von Hasse über elliptische Kurven besagt jedoch, dass die + Gruppengröße n zwischen: \$p+1 - + 2\textbackslash sqrt\{p\}\textbackslash leq n\textbackslash leq + p+1+2\textbackslash sqrt\{p\}\$ liegen muss + \item + Wie bereits erwähnt: Es genügt, relativ große Gruppen zu erzeugen + \end{itemize} + + + \subsubsection{ECDH} + + \begin{itemize} + \item + Der Diffie-Hellman-Algorithmus kann leicht an elliptische Kurven + angepasst werden + \item + Wenn Alice (A) und Bob (B) sich auf ein gemeinsames Geheimnis s + einigen wollen: + + \begin{itemize} + \item + A und B einigen sich auf eine kryptographisch sichere elliptische + Kurve und einen Punkt P auf dieser Kurve + \item + A wählt eine Zufallszahl q: + + \begin{itemize} + \item + A berechnet \$Q=qP\$ und überträgt Q an Bob + \end{itemize} + \item + B wählt eine Zufallszahl r: + + \begin{itemize} + \item + B berechnet \$R=rP\$ und überträgt P an Alice + \end{itemize} + \item + Beide Seiten errechnen das gemeinsame Geheimnis: + + \begin{itemize} + \item + A errechnet \$S=qR\$ + \item + B errechnet \$S'=rQ\$ + \item + Da \$qrP=rqP\$ der geheime Punkt \$S=S'\$ + \end{itemize} + \end{itemize} + \item + Angreifer, die den öffentlichen Kanal abhören, können S nur berechnen, + wenn sie entweder q oder r berechnen können, die die diskreten + Logarithmen von Q und R für den Punkt P sind + \end{itemize} + + + \subsubsection{EC-Version des + ElGamal-Algorithmus} + + \begin{itemize} + \item + Die Anpassung von ElGamal für elliptische Kurven ist für die + Verschlüsselungsroutine recht einfach + \item + Ein Schlüsselpaar einrichten: + + \begin{itemize} + \item + Wählen Sie eine elliptische Kurve über einem endlichen Feld, einen + Punkt G, der eine große Gruppe erzeugt, und eine Zufallszahl v, so + dass \$1 \textless{} v \textless{} n\$, wobei n die Größe der + induzierten Gruppe bezeichnet, Berechnen Sie: \$Y = vG\$ + \item + Der öffentliche Schlüssel ist \$(Y,G,Kurve)\$ + \item + Der private Schlüssel ist v + \end{itemize} + \item + Um eine Nachricht zu verschlüsseln: + + \begin{itemize} + \item + Wähle eine zufällige + \$k\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ mit + \$k\textless n-1\$, berechne \$R=kG\$ + \item + Berechne \$S=M+kY\$, wobei M ein von der Nachricht abgeleiteter + Punkt ist + + \begin{itemize} + \item + Problem: Die Interpretation der Nachricht m als x-Koordinate von M + ist nicht ausreichend, da der y-Wert nicht existieren muss + \item + Lösung aus {[}Ko87{]}: Wähle eine Konstante c (z.B. 100) und + prüfe, ob \$cm\$ die x-Koordinate eines gültigen Punktes ist, wenn + nicht, versuche \$cm+1\$, dann \$cm+2\$ usw. + \item + Um m zu entschlüsseln: nimm den x-Wert von M und führe eine + ganzzahlige Division durch c durch (der Empfänger muss c ebenfalls + kennen) + \end{itemize} + \item + Der Chiffretext sind die Punkte \$(R,S)\$ + \item + Doppelt so lang wie m, wenn sie in so genannter komprimierter Form + gespeichert werden, d.h. nur die x-Koordinaten werden gespeichert + und ein einziges Bit, das angibt, ob die größere oder kleinere + entsprechende y-Koordinate verwendet werden soll + \end{itemize} + \item + Um eine Nachricht zu entschlüsseln: + + \begin{itemize} + \item + Ableitung von M durch Berechnung von \$S-vR\$ + \item + Beweis: \$S-vR=M+kY-vR =M+kvG-vkG= M+O= M\$ + \end{itemize} + \item + Eine Nachricht signieren: + + \begin{itemize} + \item + Wähle ein zufälliges + \$k\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ mit + \$k\textless n-1\$, berechne \$R = kG\$ + \item + Berechne \$s=k\^{}\{-1\}(m+rv) mod\textbackslash{} n\$, wobei \$r\$ + der x-Wert von R ist + \item + Die Signatur ist \$(r,s)\$, wiederum etwa doppelt so lang wie n + \end{itemize} + \item + Überprüfen einer signierten Nachricht: + + \begin{itemize} + \item + Prüfen, ob der Punkt \$P=ms\^{}\{-1\}G+rs\^{}\{-1\}Y\$ die + x-Koordinate r hat + \item + Anmerkung: \$s\^{}\{-1\}\$ wird durch den Erweiterten Euklidischen + Algorithmus mit den Eingaben s und n (der Ordnung der Gruppe) + berechnet. + \item + Beweis: \$ms\^{}\{-1\}G+rs\^{}\{-1\}Y = ms\^{}\{-1\}G+rs\^{}\{-1\}vG + = (m+rv)(s\^{}\{-1\})G = (ks)(s\^{}\{-1\})G = kG = R\$ + \end{itemize} + \item + Diskussion zur Sicherheit: + + \begin{itemize} + \item + Wie in der ursprünglichen Version von ElGamal ist es entscheidend, k + nicht zweimal zu verwenden + \item + Nachrichten sollten nicht direkt signiert werden + \item + Weitere Prüfungen können erforderlich sein, d.h. G darf nicht O + sein, ein gültiger Punkt auf der Kurve usw. (siehe {[}NIST09{]} für + weitere Details) + \end{itemize} + \end{itemize} + + + \subsubsection{Sicherheit} + + \begin{itemize} + \item + Die Sicherheit hängt stark von der gewählten Kurve und dem Punkt ab: + \item + Die Diskriminante der Kurve darf nicht Null sein, d.h. + \$4a\^{}3+27b\^{}2\textbackslash not\textbackslash equiv + 0\textbackslash{} mod\textbackslash{} p\$ sonst ist die Kurve + degradiert (eine sogenannte ,,singuläre Kurve'' ) + \item + Menezes et. al. haben einen subexponentiellen Algorithmus für + sogenannte ,,supersinguläre elliptische Kurven'' gefunden, der aber im + allgemeinen Fall nicht funktioniert {[}Men93a{]} + \item + Die konstruierten algebraischen Gruppen sollten so viele Elemente wie + möglich haben. + \item + In diesem Kurs wird nicht näher auf die Kryptographie elliptischer + Kurven eingegangen, da dies viel mehr Mathematik erfordert, als für + diesen Kurs erwünscht ist... + \item + Für Nicht-Kryptographen ist es am besten, sich auf vordefinierte + Kurven zu verlassen, z.B. {[}LM10{]} oder {[}NIST99{]} und Standards + wie ECDSA + \item + Viele Veröffentlichungen wählen die Parameter a und b so, dass sie + nachweislich durch einen Zufallsprozess gewählt werden (z.B. + veröffentlichen Sie x für \$h(x)=a\$ und \$y\$ für \$h(y) = b\$); so + soll sichergestellt werden, dass die Kurven keine kryptographische + Schwäche enthalten, die nur den Autoren bekannt ist + \item + Die Sicherheit ist abhängig von der Länge von p + + \begin{itemize} + \item + Schlüssellängen mit vergleichbaren Stärken nach {[}NIST12{]}: + \textbar{} Symmetrische Algorithmen \textbar{} RSA \textbar{} ECC + \textbar{} \textbar{} + -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- + \textbar{} -\/-\/-\/-\/- \textbar{} -\/-\/-\/-\/-\/-\/- \textbar{} + \textbar{} 112 \textbar{} 2048 \textbar{} 224-255 \textbar{} + \textbar{} 128 \textbar{} 3072 \textbar{} 256-383 \textbar{} + \textbar{} 192 \textbar{} 7680 \textbar{} 384-511 \textbar{} + \textbar{} 256 \textbar{} 15360 \textbar{} \textgreater{} 512 + \textbar{} + \end{itemize} + \item + Die Sicherheit hängt auch stark von der Implementierung ab! + + \begin{itemize} + \item + Die verschiedenen Fälle (z.B. mit O) in der ECC-Berechnung können + beobachtbar sein, d.h. Stromverbrauch und Zeitunterschiede + \item + Angreifer können Seitenkanalangriffe ableiten, wie in OpenSSL 0.9.8o + {[}BT11{]} + + \begin{itemize} + \item + Ein Angreifer kann die Bitlänge eines Wertes k in \$kP\$ ableiten, + indem er die für den Quadrat- und Multiplikationsalgorithmus + benötigte Zeit misst + \item + Der Algorithmus wurde in OpenSSL frühzeitig abgebrochen, wenn + keine weiteren Bits auf ,,1'' gesetzt wurden + \end{itemize} + \item + Angreifer könnten versuchen, ungültige Punkte zu generieren, um + Fakten über den verwendeten Schlüssel abzuleiten, wie in OpenSSL + 0.9.8g, was zu einer Wiederherstellung eines vollen 256-Bit + ECC-Schlüssels nach nur 633 Abfragen führte {[}BBP12{]} + \end{itemize} + \item + Lektion gelernt: Machen Sie es nicht selbst, es sei denn, Sie müssen + es tun und wissen, was Sie tun! + \end{itemize} + + + \subsubsection{Weitere Anmerkungen} + + \begin{itemize} + \item + Wie bereits erwähnt, ist es möglich, kryptographische elliptische + Kurven über \$G(2\^{}n)\$ zu konstruieren, was in + Hardware-Implementierungen schneller sein kann. + + \begin{itemize} + \item + Wir haben auf Details verzichtet, da dies nicht viele neue + Erkenntnisse gebracht hätte! + \end{itemize} + \item + Elliptische Kurven und ähnliche algebraische Gruppen sind ein aktives + Forschungsgebiet und ermöglichen weitere fortgeschrittene Anwendungen, + z.B: + + \begin{itemize} + \item + Sogenannte Edwards-Kurven werden derzeit diskutiert, da sie robuster + gegen Seitenkanalangriffe zu sein scheinen (z.B. {[}BLR08{]}) + \item + Bilineare Paarungen ermöglichen + + \begin{itemize} + \item + Programme zu verifizieren, dass sie zur selben Gruppe gehören, + ohne ihre Identität preiszugeben (Secret Handshakes, z.B. + {[}SM09{]}) + \item + Öffentliche Schlüssel können strukturiert werden, z.B. ,,Alice'' + als öffentlicher Schlüssel für Alice verwenden (Identitätsbasierte + Verschlüsselung, Grundlagen in {[}BF03{]}) + \end{itemize} + \end{itemize} + \item + Bevor Sie elliptische Kurvenkryptographie in einem Produkt einsetzen, + stellen Sie sicher, dass Sie keine Patente verletzen, da es noch viele + gültige Patente in diesem Bereich gibt! + \end{itemize} + + + \subsection{Schlussfolgerung} + + \begin{itemize} + \item + Asymmetrische Kryptographie erlaubt es, zwei verschiedene Schlüssel zu + verwenden: + + \begin{itemize} + \item + Verschlüsselung / Entschlüsselung + \item + Signieren / Überprüfen + \end{itemize} + \item + Die praktischsten Algorithmen, die immer noch als sicher gelten, sind: + + \begin{itemize} + \item + RSA, basierend auf der Schwierigkeit, diskrete Logarithmen zu + faktorisieren und zu lösen + \item + Diffie-Hellman (kein asymmetrischer Algorithmus, sondern ein + Schlüsselvereinbarungsprotokoll) + \item + ElGamal, wie DH basierend auf der Schwierigkeit, diskrete + Logarithmen zu berechnen + \end{itemize} + \item + Da ihre Sicherheit vollständig auf der Schwierigkeit bestimmter + mathematischer Probleme beruht, stellt der algorithmische Fortschritt + ihre größte Bedrohung dar. + \item + Praktische Überlegungen: + + \begin{itemize} + \item + Asymmetrische kryptografische Operationen sind um Größenordnungen + langsamer als symmetrische Operationen. + \item + Daher werden sie oft nicht für die Verschlüsselung/Signierung von + Massendaten verwendet. + \item + Symmetrische Verfahren werden zur Verschlüsselung / Berechnung eines + kryptografischen Hashwerts verwendet, während die asymmetrische + Kryptografie nur zur Verschlüsselung eines Schlüssels / Hashwerts + eingesetzt wird. + \end{itemize} + \end{itemize} + + + \section{Modifikationsprüfwerte} + + + \subsection{Motivation} + + \begin{itemize} + \item + In der Datenkommunikation ist es üblich, eine Art Fehlererkennungscode + für Nachrichten zu berechnen, mit dem der Empfänger überprüfen kann, + ob eine Nachricht während der Übertragung verändert wurde. + + \begin{itemize} + \item + Beispiele: Parität, Bit-Interleaved Parity, Cyclic Redundancy Check + (CRC) + \end{itemize} + \item + Dies führt zu dem Wunsch, einen ähnlichen Wert zu haben, der es + ermöglicht zu überprüfen, ob eine Nachricht während der Übertragung + verändert wurde. + \item + Es ist jedoch ein großer Unterschied, ob man davon ausgeht, dass die + Nachricht durch mehr oder weniger zufällige Fehler oder absichtlich + verändert wird: + + \begin{itemize} + \item + Wenn jemand eine Nachricht, die mit einem CRC-Wert geschützt ist, + absichtlich verändern will, kann er den CRC-Wert nach der + Veränderung neu berechnen oder die Nachricht so verändern, dass sie + den gleichen CRC-Wert ergibt. + \end{itemize} + \item + Ein Änderungsprüfwert muss also einige zusätzliche Eigenschaften + erfüllen, die es Angreifern unmöglich machen, ihn zu fälschen + + \begin{itemize} + \item + Zwei Hauptkategorien von Modifikationsprüfwerten: + + \begin{itemize} + \item + Modifikationserkennungscode (MDC) + \item + Nachrichten-Authentifizierungs-Code (MAC) + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Kryptographische + Hash-Funktionen} + + \begin{itemize} + \item + Definition: Hash-Funktion + + \begin{itemize} + \item + Eine Hash-Funktion ist eine Funktion h, die die folgenden zwei + Eigenschaften hat: + + \begin{itemize} + \item + Komprimierung: h bildet eine Eingabe x mit beliebiger endlicher + Bitlänge auf eine Ausgabe \$h(x)\$ mit fester Bitlänge n ab. + \item + Einfachheit der Berechnung: Bei h und x ist es einfach, \$h(x)\$ + zu berechnen. + \end{itemize} + \end{itemize} + \item + Definition: kryptografische Hash-Funktion + + \begin{itemize} + \item + Eine kryptografische Hash-Funktion h ist eine Hash-Funktion, die + zusätzlich unter anderem die folgenden Eigenschaften erfüllt: + + \begin{itemize} + \item + Pre-Image-Resistenz: für im Wesentlichen alle vorgegebenen + Ausgaben y ist es rechnerisch nicht möglich, ein x zu finden, so + dass \$h(x)=y\$ + \item + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \setcounter{enumi}{1} + \item + Vorabbild-Resistenz: Bei x ist es rechnerisch nicht möglich, + eine zweite Eingabe \$x'\$ mit \$x\textbackslash not= x'\$ zu + finden, so dass \$h(x)=h(x')\$ + \end{enumerate} + \item + Kollisionssicherheit: Es ist rechnerisch nicht möglich, ein + beliebiges Paar \$(x,x')\$ mit \$x\textbackslash not= x'\$ zu + finden, so dass \$h(x)=h(x')\$ + \end{itemize} + \item + Kryptographische Hash-Funktionen werden zur Berechnung von + Modification Detection Codes (MDC) verwendet + \end{itemize} + \end{itemize} + + + \subsection{Nachrichten-Authentifizierungs-Codes + (MAC)} + + \begin{itemize} + \item + Definition: Nachrichten-Authentifizierungs-Code + + \begin{itemize} + \item + Ein Message-Authentication-Code-Algorithmus ist eine Familie von + Funktionen \$h\_k\$, die durch einen geheimen Schlüssel k + parametrisiert sind und die folgenden Eigenschaften aufweisen: + + \begin{itemize} + \item + Komprimierung: hk bildet eine Eingabe x beliebiger endlicher + Bitlänge auf eine Ausgabe \$h\_k(x)\$ fester Bitlänge ab, genannt + MAC + \item + Einfache Berechnung: Bei k, x und einer bekannten Funktionsfamilie + \$h\_k\$ ist der Wert \$h\_k(x)\$ einfach zu berechnen + \item + Berechnungsresistenz: für jeden festen, erlaubten, aber + unbekannten Wert von k ist es bei null oder mehr Text-MAC-Paaren + \$(x\_i, h\_k(x\_i))\$ rechnerisch nicht möglich, ein + Text-MAC-Paar \$(x, h\_k(x))\$ für jede neue Eingabe + \$x\textbackslash not= x\_i\$ zu berechnen + \end{itemize} + \item + Bitte beachten Sie, dass Rechenresistenz die Eigenschaft der + Nicht-Wiederherstellung des Schlüssels impliziert, d.h. k kann nicht + aus Paaren \$(x\_i,h\_k(x\_i))\$ wiederhergestellt werden, aber + Rechenresistenz kann nicht aus der Nicht-Wiederherstellung des + Schlüssels abgeleitet werden, da der Schlüssel k nicht immer + wiederhergestellt werden muss, um neue MACs zu fälschen + \end{itemize} + \end{itemize} + + + \subsection{Ein einfacher Angriff gegen einen unsicheren + MAC} + + \begin{itemize} + \item + Betrachten wir zur Veranschaulichung die folgende MAC-Definition: + + \begin{itemize} + \item + Eingabe: Nachricht \$m=(x\_1,x\_2,...,x\_n)\$, wobei \$x\_i\$ + 64-Bit-Werte sind, und Schlüssel k + \item + Berechne \$\textbackslash delta(m):= x\_1\textbackslash oplus + x\_2\textbackslash oplus...\textbackslash oplus x\_n\$, wobei + \$\textbackslash oplus\$ die bitweise Exklusiv-Oder-Verknüpfung + bezeichnet + \item + Ausgabe: MAC \$C\_k(m):= E\_k(\textbackslash delta(m))\$ mit + \$E\_k(x)\$ für die DES-Verschlüsselung + \end{itemize} + \item + Die Schlüssellänge beträgt 56 Bit und die MAC-Länge 64 Bit, so dass + wir einen Aufwand von etwa \$2\^{}\{55\}\$ Operationen erwarten + würden, um den Schlüssel k zu erhalten und den MAC zu knacken (= + Nachrichten fälschen zu können). + \item + Leider ist die MAC-Definition unsicher: + + \begin{itemize} + \item + Angenommen, ein Angreifer Eve, der die zwischen Alice und Bob + ausgetauschten Nachrichten fälschen will, erhält eine Nachricht + \$(m,C\_k(m))\$, die von Alice mit dem mit Bob geteilten geheimen + Schlüssel k ,,geschützt'' wurde + \item + Eve kann eine Nachricht \$m'\$ konstruieren, die denselben MAC + ergibt: + + \begin{itemize} + \item + Sei \$y\_1,y\_2,...,y\_\{n-1\}\$ ein beliebiger 64-Bit-Wert + \item + Definiere \$y\_n:= y\_1\textbackslash oplus + y\_2\textbackslash oplus...\textbackslash oplus + y\_\{n-1\}\textbackslash oplus \textbackslash delta(m)\$, und + \$m':=(y\_1,y\_2,...,y\_n)\$ + \item + Wenn Bob \$(m',C\_k(m))\$ von Eve erhält, die vorgibt, Alice zu + sein, wird er es als von Alice stammend akzeptieren, da + \$C\_k(m)\$ ein gültiger MAC für \$m'\$ ist + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Anwendungen für kryptographische Hash-Funktionen und + MACs} + + \begin{itemize} + \item + Wichtigste Anwendung, die zum ursprünglichen Entwurf führte: + Integrität von Nachrichten + + \begin{itemize} + \item + Ein MDC stellt einen digitalen Fingerabdruck dar, der mit einem + privaten Schlüssel signiert werden kann, z. B. mit dem RSA- oder + ElGamal-Algorithmus, und es ist nicht möglich, zwei Nachrichten mit + demselben Fingerabdruck zu erstellen, so dass ein bestimmter + signierter Fingerabdruck von einem Angreifer nicht wiederverwendet + werden kann + \item + Ein MAC über eine Nachricht m bescheinigt direkt, dass der Absender + der Nachricht im Besitz des geheimen Schlüssels k ist und die + Nachricht ohne Kenntnis dieses Schlüssels nicht verändert worden + sein kann. + \end{itemize} + \item + Andere Anwendungen, die eine gewisse Vorsicht erfordern: + + \begin{itemize} + \item + Bestätigung von Wissen + \item + Schlüsselableitung + \item + Pseudo-Zufallszahlengenerierung + \end{itemize} + \item + Je nach Anwendung müssen weitere Anforderungen erfüllt werden: + + \begin{itemize} + \item + Partielle Vorabbild-Resistenz: auch wenn nur ein Teil der Eingabe, + z.B. t Bit, unbekannt ist, sollte es im Durchschnitt + \$2\^{}\{t-1\}\$ Operationen benötigen, um diese Bits zu finden + \end{itemize} + \end{itemize} + + + \subsection{Angriffe basierend auf dem + Geburtstagsphänomen} + + \begin{itemize} + \item + Das Geburtstagsphänomen: + + \begin{itemize} + \item + Wie viele Personen müssen sich in einem Raum befinden, damit die + Wahrscheinlichkeit, dass es mindestens zwei Personen mit demselben + Geburtstag gibt, größer als 0,5 ist? + \item + Der Einfachheit halber lassen wir den 29. Februar beiseite und + nehmen an, dass jeder Geburtstag gleich wahrscheinlich ist + \end{itemize} + \item + Definieren Sie \$P(n,k):= Pr\${[}mindestens ein Duplikat in k + Elementen, wobei jedes Element einen von n gleich wahrscheinlichen + Werten zwischen 1 und n annehmen kann {]} + \item + Definieren Sie \$Q(n,k):= Pr\${[}kein Duplikat in k Artikeln, jeder + Artikel zwischen 1 und n {]} + + \begin{itemize} + \item + Wir können das erste Element aus n möglichen Werten wählen, das + zweite Element aus \$n-1\$ möglichen Werten, usw. + \item + Die Anzahl der verschiedenen Möglichkeiten, k Elemente aus n Werten + ohne Duplikate auszuwählen, ist also: \$N=n \textbackslash times + (n-1)\textbackslash times ...\textbackslash times (n-k+1)= + n!\textbackslash backslash(n-k)!\$ + \item + Die Anzahl der verschiedenen Möglichkeiten, k Elemente aus n Werten + auszuwählen, mit oder ohne Duplikate, ist: \$n\^{}k\$ + \item + Also, \$Q(n,k)=N\textbackslash backslash + n\^{}k=n!\textbackslash backslash((n-k)! \textbackslash times + n\^{}k)\$ + \end{itemize} + \item + Wir haben: + \$P(n,k)=1-Q(n,k)=1-\textbackslash frac\{n!\}\{(n-k)!\textbackslash times + n\^{}k\}=1-\textbackslash frac\{n\textbackslash times(n-1)\textbackslash times...\textbackslash times(n-k+1)\}\{n\^{}k\}=1-{[}(1-\textbackslash frac\{1\}\{n\})\textbackslash times(1-\textbackslash frac\{2\}\{n\})\textbackslash times...\textbackslash times(1-\textbackslash frac\{k-1\}\{n\}){]}\$ + \item + Wir werden die folgende Ungleichung verwenden: \$(1-x) + \textbackslash leq e\^{}\{-x\}\$ für alle \$x \textbackslash geq 0\$ + \item + So: + \$P(n,k)\textgreater1-{[}(e\^{}\{-1/n\})\textbackslash times(e\^{}\{-2/n\})\textbackslash times...\textbackslash times(e\^{}\{-(k-1)/n\}){]}=1-e\^{}\{\textbackslash frac\{-k\textbackslash times(k-1)\}\{2n\}\}\$ + \item + Im letzten Schritt haben wir die Gleichheit: \$1+2+...+(k-1)=(k\^{}2 - + k)\textbackslash backslash 2\$ + + \begin{itemize} + \item + Übung: Beweisen Sie die obige Gleichheit durch Induktion + \end{itemize} + \item + Kehren wir zu unserer ursprünglichen Frage zurück: Wie viele Personen + k müssen sich in einem Raum befinden, damit mindestens zwei Personen + mit demselben Geburtstag (von \$n=365\$ möglichen) mit der + Wahrscheinlichkeit \$\textbackslash geq 0,5\$ vorhanden sind? + + \begin{itemize} + \item + Wir wollen also lösen: + \$\textbackslash frac\{1\}\{2\}=1-e\^{}\{\textbackslash frac\{-k\textbackslash times(k-1)\}\{2n\}\}\textbackslash Leftrightarrow + 2=e\^{}\{\textbackslash frac\{k\textbackslash times(k-1)\}\{2n\}\}\textbackslash Leftrightarrow + ln(2)=\textbackslash frac\{k\textbackslash times(k-1)\}\{2n\}\$ + \item + Für große k können wir \$k\textbackslash times(k-1)\$ durch + \$k\^{}2\$ approximieren, und wir erhalten: + \$k=\textbackslash sqrt\{2 ln(2)n\}\textbackslash approx + 1,18\textbackslash sqrt\{n\}\$ + \item + Für \$n=365\$ erhalten wir \$k=22,54\$, was der richtigen Antwort + recht nahe kommt 23 + \end{itemize} + \item + Was hat das mit MDCs zu tun? + \item + Wir haben gezeigt, dass bei n möglichen unterschiedlichen Werten die + Anzahl k der Werte, die man zufällig wählen muss, um mindestens ein + Paar identischer Werte zu erhalten, in der Größenordnung von + \$\textbackslash sqrt\{n\}\$ liegt. + \item + Betrachten wir nun den folgenden Angriff {[}Yuv79a{]}: + + \begin{itemize} + \item + Eve möchte, dass Alice eine Nachricht m1 signiert, die Alice + normalerweise nie signieren würde. Eve weiß, dass Alice die Funktion + MDC1(m) verwendet, um eine MDC von m zu berechnen, die eine Länge + von r Bit hat, bevor sie diese MDC mit ihrem privaten Schlüssel + signiert, was ihre digitale Signatur ergibt. + \item + Zunächst erzeugt Eve ihre Nachricht m1. Würde sie nun MDC1(m1) + berechnen und dann versuchen, eine zweite harmlose Nachricht m2 zu + finden, die zu demselben MDC führt, wäre ihr Suchaufwand im + durchschnittlichen Fall in der Größenordnung von \$2\^{}\{(r-1)\}\$. + \item + Stattdessen nimmt sie eine beliebige harmlose Nachricht m2 und + beginnt, Variationen m1' und m2' der beiden Nachrichten zu + produzieren, z.B. durch Hinzufügen von -Kombinationen oder + Variationen mit semantisch identischen Wörtern. + \end{itemize} + \item + Wie wir aus dem Geburtstagsphänomen gelernt haben, muss sie nur etwa + \$\textbackslash sqrt\{2\^{}r\}=2\^{}\{r/2\}\$ Variationen von jeder + der beiden Nachrichten produzieren, so dass die Wahrscheinlichkeit, + dass sie zwei Nachrichten m1' und m2' mit demselben MDC erhält, + mindestens 0,5 beträgt + \item + Da sie die Nachrichten zusammen mit ihren MDCs speichern muss, um eine + Übereinstimmung zu finden, liegt der Speicherbedarf ihres Angriffs in + der Größenordnung von \$2\^{}\{\textbackslash frac\{r\}\{2\}\}\$ und + der Rechenzeitbedarf in der gleichen Größenordnung + \item + Nachdem sie m1' und m2' mit \$MDC1(m1')=MDC1(m2')\$ gefunden hat, + fordert sie Alice auf, \$m2'\$ zu signieren. Eve kann dann diese + Unterschrift nehmen und behaupten, dass Alice \$m1'\$ unterschrieben + hat. + \item + Angriffe nach dieser Methode werden Geburtstagsangriffe genannt. + \item + Nehmen wir nun an, dass Alice RSA mit Schlüsseln der Länge 2048 Bit + und eine kryptographische Hashfunktion verwendet, die MDCs der Länge + 96 Bit erzeugt. + + \begin{itemize} + \item + Eves durchschnittlicher Aufwand, zwei Nachrichten m1' und m2' wie + oben beschrieben zu erzeugen, liegt in der Größenordnung von + \$2\^{}\{48\}\$, was heute machbar ist. Das Knacken von + RSA-Schlüsseln der Länge 2048 Bit ist mit den heutigen Algorithmen + und Technologien bei weitem nicht möglich. + \end{itemize} + \end{itemize} + + + \subsection{Übersicht über die gebräuchlichen + MDCs} + + \begin{itemize} + \item + Kryptografische Hash-Funktionen zur Erstellung von MDCs: + + \begin{itemize} + \item + Message Digest 5 (MD5): + + \begin{itemize} + \item + Erfunden von R. Rivest + \item + Nachfolger von MD + \end{itemize} + \item + Sicherer Hash-Algorithmus 1 (SHA-1): + + \begin{itemize} + \item + Erfunden von der National Security Agency (NSA) + \item + Der Entwurf wurde von MD inspiriert. + \end{itemize} + \item + Sicherer Hash-Algorithmus 2 (SHA-2, auch SHA-256 und SHA-512) + + \begin{itemize} + \item + Ebenfalls von der National Security Agency (NSA) entwickelt + \item + Auch Merkle-Dåmgard-Verfahren + \item + Größere Blockgröße \& komplexere Rundenfunktion + \end{itemize} + \item + Sicherer Hash-Algorithmus 3 (SHA-3, Keccak) + + \begin{itemize} + \item + Gewinner eines offenen Wettbewerbs + \item + Sogenannte Sponge-Konstruktion + \item + Vielseitiger als frühere Hash-Funktionen + \end{itemize} + \end{itemize} + \item + Nachrichten-Authentifizierungs-Codes (MACs): + + \begin{itemize} + \item + DES-CBC-MAC: + + \begin{itemize} + \item + Verwendet den Data Encryption Standard im Cipher Block Chaining + Modus + \item + Im Allgemeinen kann die CBC-MAC-Konstruktion mit jeder + Blockchiffre verwendet werden. + \end{itemize} + \item + MACs, die aus MDCs aufgebaut sind: + + \begin{itemize} + \item + Dieser sehr verbreitete Ansatz wirft einige kryptografische + Bedenken auf, da er einige implizite, aber nicht verifizierte + Annahmen über die Eigenschaften der MDCs trifft. + \end{itemize} + \end{itemize} + \item + Authentifizierte Verschlüsselung mit zugehörigen Daten (AEAD) + + \begin{itemize} + \item + Galois-Counter-Verfahren (GCM) + + \begin{itemize} + \item + Verwendet eine Blockchiffre zur Verschlüsselung und + Authentifizierung von Daten + \item + Schnell in Netzwerkanwendungen + \end{itemize} + \item + Sponge Wrap + + \begin{itemize} + \item + Verwendet eine SHA-3 ähnliche Hash-Funktion zur Verschlüsselung + und Authentifizierung von Daten + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Gemeinsame Struktur von kryptografischen + Hash-Funktionen} + + \begin{itemize} + \item + So wie viele der heutigen Blockchiffren der allgemeinen Struktur eines + Feistel-Netzwerks folgen, folgen auch viele der heute verwendeten + kryptografischen Hash-Funktionen einer gemeinsamen Struktur, der + sogenannten Merkle-Dåmgard-Struktur: + + \begin{itemize} + \item + Sei y eine beliebige Nachricht. Normalerweise wird die Länge der + Nachricht an die Nachricht angehängt und auf ein Vielfaches einer + Blockgröße b aufgefüllt. Bezeichnen wir + \$(y\_0,y\_1,...,y\_\{L-1\})\$ die resultierende Nachricht, die aus + L Blöcken der Größe b + \item + Die allgemeine Struktur ist wie folgt abgebildet: + % \includegraphics{Assets/NetworkSecurity-feistel.png} + \item + CV ist ein Verkettungswert, mit \$CV\_0:= IV\$ und \$MDC(y) := + CV\_L\$ + \item + f ist eine spezifische Kompressionsfunktion, die \$(n+b)\$ Bit auf n + Bit komprimiert + \end{itemize} + \item + Die Hash-Funktion H lässt sich wie folgt zusammenfassen: + + \begin{itemize} + \item + \$CV\_0 = IV =\$ anfänglicher n-Bit-Wert + \item + \$CV\_i = f(CV\_\{i -1\}, y\_\{i-1\}) + \textbackslash quad\textbackslash quad 1\textbackslash leq i + \textbackslash leq L\$ + \item + \$H(y) = CV\_L\$ + \end{itemize} + \item + Es wurde gezeigt {[}Mer89a{]}, dass, wenn die Kompressionsfunktion f + kollisionssicher ist, die resultierende iterierte Hash-Funktion H + ebenfalls kollisionssicher ist. + \item + Die Kryptoanalyse kryptographischer Hash-Funktionen konzentriert sich + daher auf die interne Struktur der Funktion f und die Suche nach + effizienten Techniken zur Erzeugung von Kollisionen bei einer einzigen + Ausführung von f + \item + In erster Linie durch Geburtstagsangriffe motiviert, ist ein gängiger + Mindestvorschlag für n , die Bitlänge des Hashwerts, 160 Bit, da dies + einen Aufwand der Größenordnung \$2\^{}\{80\}\$ für einen Angriff + impliziert, der heute als undurchführbar gilt + \end{itemize} + + + \subsection{Der Message Digest 5} + + \begin{itemize} + \item + MD5 folgt der zuvor skizzierten allgemeinen Struktur (z. B. + {[}Riv92a{]}): + + \begin{itemize} + \item + Die Nachricht y wird mit einer ,,1'' aufgefüllt, gefolgt von 0 bis + 511 ,,0'' Bits, so dass die Länge der resultierenden Nachricht + kongruent 448 modulo 512 ist + \item + Die Länge der ursprünglichen Nachricht wird als 64-Bit-Wert + hinzugefügt, so dass eine Nachricht entsteht, deren Länge ein + ganzzahliges Vielfaches von 512 Bit ist. + \item + Diese neue Nachricht wird in Blöcke der Länge \$b=512\$ Bit + unterteilt. + \item + Die Länge des Verkettungswertes ist \$n=128\$ Bit + + \begin{itemize} + \item + Der Verkettungswert ist ,,strukturiert'' als vier 32-Bit-Register + A, B, C, D + \item + Initialisierung: + + \begin{itemize} + \item + A := 0x 01 23 45 67 + \item + B := 0x 89 AB CD EF + \item + C := 0x FE DC BA 98 + \item + D := 0x 76 54 32 10 + \end{itemize} + \end{itemize} + \item + Jeder Block der Nachricht \$y\_i\$ wird mit dem Verkettungswert + \$CV\_i\$ mit der Funktion f verarbeitet, die intern durch 4 Runden + zu je 16 Schritten realisiert ist + + \begin{itemize} + \item + Jede Runde ist ähnlich aufgebaut und verwendet eine Tabelle T, die + 64 konstante Werte von je 32 Bit enthält, + \item + Jede der vier Runden verwendet eine bestimmte logische Funktion g + \end{itemize} + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-md5.png} + + \begin{itemize} + \item + Die Funktion g ist eine von vier verschiedenen logischen Funktionen + \item + \$y\_i{[}k{]}\$ bezeichnet das k-te\$ 32-Bit-Wort des + Nachrichtenblocks i + \item + \$T{[}j{]}\$ ist der j-te Eintrag der Tabelle t, wobei j bei jedem + Schritt modulo 64 inkrementiert wird + \item + CLS s bezeichnet die zyklische Linksverschiebung um s Bits, wobei s + einem bestimmten Schema folgt. + \end{itemize} + \item + Der MD5-MDC über eine Nachricht ist der Inhalt des Verkettungswertes + CV nach Verarbeitung des letzten Nachrichtenblocks. + \item + Sicherheit von MD5: + + \begin{itemize} + \item + Jedes Bit des 128-Bit-Hash-Codes ist eine Funktion eines jeden + Eingabebits + \item + 1996 veröffentlichte H. Dobbertin einen Angriff, der es erlaubt, + eine Kollision für die Funktion f zu erzeugen (realisiert durch die + oben beschriebenen 64 Schritte). + \item + Es dauerte bis 2004, bis eine erste Kollision gefunden wurde + {[}WLYF04{]}. + \item + Inzwischen ist es möglich, Kollisionen innerhalb von Sekunden auf + allgemeiner Hardware zu erzeugen {[}Kl06{]}. + \item + MD5 darf nicht in Betracht gezogen werden, wenn Kollisionssicherheit + erforderlich ist! + + \begin{itemize} + \item + Dies ist oft der Fall! + \item + Beispiele: Zwei Postskripte mit unterschiedlichen Texten, aber + gleichen Hashes {[}LD05{]}, Zertifikate, eines für eine gesicherte + Domain und eines für eine eigene Zertifizierungsstelle + {[}LWW05{]}, Jede Nachricht, die erweiterbar ist {[}KK06{]} + \end{itemize} + \item + Die Resistenz gegen Preimage-Angriffe ist mit 2123.4 Berechnungen + noch o.k{[}SA09{]} + \end{itemize} + \end{itemize} + + + \subsection{Der sichere Hash-Algorithmus + SHA-1} + + \begin{itemize} + \item + Auch SHA-1 folgt der gleichen Struktur wie oben beschrieben: + + \begin{itemize} + \item + SHA-1 arbeitet mit 512-Bit-Blöcken und erzeugt einen + 160-Bit-Hash-Wert. + \item + Da sein Design auch vom MD4-Algorithmus inspiriert wurde, ist seine + Initialisierung im Grunde dieselbe wie die von MD5: + + \begin{itemize} + \item + Die Daten werden aufgefüllt, ein Längenfeld wird hinzugefügt und + die resultierende Nachricht wird als Blöcke der Länge 512 Bit + verarbeitet. + \item + Der Verkettungswert ist als fünf 32-Bit-Register A, B, C, D, E + strukturiert + \item + Initialisierung: + + \begin{itemize} + \item + A = 0x 67 45 23 01 + \item + B = 0x EF CD AB 89 + \item + C = 0x 98 BA DC FE + \item + D = 0x 10 32 54 76 + \item + E = 0x C3 D2 E1 F + \end{itemize} + \item + Die Werte werden im Big-Endian-Format gespeichert. + \end{itemize} + \item + Jeder Block yi der Nachricht wird zusammen mit CVi in einem Modul + verarbeitet, das die Kompressionsfunktion f in vier Runden zu je 20 + Schritten realisiert. + + \begin{itemize} + \item + Die Runden haben eine ähnliche Struktur, aber jede Runde verwendet + eine andere primitive logische Funktion \$f\_1, f\_2, f\_3, + f\_4\$. + \item + Bei jedem Schritt wird eine feste additive Konstante \$K\_t\$ + verwendet, die während einer Runde unverändert bleibt + \end{itemize} + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-sha1.png} + + \begin{itemize} + \item + \$t\textbackslash in\{0,...,15\}\textbackslash Rightarrow W\_t:= + y\_i{[}t{]}\$ + \item + \$t\textbackslash in\{16,...,79\}\textbackslash Rightarrow + W\_t:=CLS\_1(W\_\{t-16\}\textbackslash oplus + W\_\{t-14\}\textbackslash oplus W\_\{t-8\} \textbackslash oplus + W\_\{t-3\})\$ + \item + Nach Schritt 79 wird jedes Register A, B, C, D, E modulo + \$2\^{}\{32\}\$ mit dem Wert des entsprechenden Registers vor + Schritt 0 addiert, um \$CV\_\{i+1\}\$ zu berechnen + \end{itemize} + \item + Der SHA-1-MDC über eine Nachricht ist der Inhalt des Verkettungswertes + CV nach Verarbeitung des letzten Nachrichtenblocks. + \item + Vergleich zwischen SHA-1 und MD5: + + \begin{itemize} + \item + Geschwindigkeit: SHA-1 ist etwa 25\% langsamer als MD5 (CV ist etwa + 25\% größer) + \item + Einfachheit und Kompaktheit: beide Algorithmen sind einfach zu + beschreiben und zu implementieren und erfordern keine großen + Programme oder Ersetzungstabellen + \end{itemize} + \item + Sicherheit von SHA-1: + + \begin{itemize} + \item + Da SHA-1 MDCs der Länge 160 Bit erzeugt, wird erwartet, dass es eine + bessere Sicherheit gegen Brute-Force- und Geburtstagsangriffe bietet + als MD5. + \item + Einige inhärente Schwächen von Merkle-Dåmgard-Konstruktionen, z. B. + {[}KK06{]}, sind vorhanden + \item + Im Februar 2005 veröffentlichten X. Wang et. al. einen Angriff, der + es erlaubt, eine Kollision mit einem Aufwand von \$2\^{}\{69\}\$ zu + finden, der in den folgenden Monaten auf \$2\^{}\{63\}\$ verbessert + und in {[}WYY05a{]} veröffentlicht wurde + \item + Die Forschung ging weiter (z.B. {[}Man11{]}), und im Februar 2017 + wurde die erste tatsächliche Kollision gefunden (demonstriert mit + einem veränderten PDF-Dokument) + \end{itemize} + \item + SHA-2-Familie + + \begin{itemize} + \item + Im Jahr 2001 veröffentlichte das NIST einen neuen Standard FIPS PUB + 180-2, der neue Varianten mit den Bezeichnungen SHA-256, SHA-384 und + SHA-512 {[}NIST02{]} mit 256, 384 und 512 Bits enthält. + + \begin{itemize} + \item + SHA-224 wurde im Jahr 2004 hinzugefügt. + \end{itemize} + \item + SHA-224 und SHA-384 sind verkürzte Versionen von SHA-256 und SHA-512 + mit unterschiedlichen Initialisierungswerten + \item + SHA-2 verwendet ebenfalls die Merkle-Dåmgard-Konstruktion mit einer + Blockgröße von 512 Bit (SHA-256) und 1024 Bit (SHA-512) + \item + Der interne Zustand ist in 8 Registern von 32 Bit (SHA-256) und 64 + Bit (SHA-512) organisiert + \item + 64 Runden (SHA-256) oder 80 Runden (SHA-512) + \end{itemize} + \item + Ein Schritt + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-sha-2.png} + \item + \$t\textbackslash in\{0, ..., 15\}\textbackslash Rightarrow + W\_t:=y\_i{[}t{]}\$ + \item + \$t\textbackslash in\{16, ..., r\}\textbackslash Rightarrow + W\_t:=W\_\{t-16\}\textbackslash oplus + \textbackslash delta\_0(W\_\{t-15\})\textbackslash oplus + W\_\{t-7\}\textbackslash oplus\textbackslash delta\_1(W\_\{t-2\})\$ + \item + \$K\_t\$ ist der gebrochene Teil der Kubikwurzel aus der t-ten + Primzahl + \item + Die ROTR- und Funktionen XOR-verknüpfen verschiedene Verschiebungen + des Eingangswertes + \item + Ch und Maj sind logische Kombinationen der Eingabewerte + \end{itemize} + \item + SHA-2-Familie + + \begin{itemize} + \item + Alles in allem sehr ähnlich zu SHA-1 + \item + Aufgrund der Größe und der komplizierteren Rundungsfunktionen etwa + 30-50 Prozent langsamer als SHA-1 (variiert für 64-Bit- und + 32-Bit-Systeme!) + \item + Sicherheitsdiskussion: + + \begin{itemize} + \item + Bereits 2004 wurde entdeckt, dass eine vereinfachte Version des + Algorithmus (mit XOR statt Addition und symmetrischen Konstanten) + hochkorrelierte Ausgaben erzeugt {[}GH04{]} + \item + Für rundenreduzierte Versionen von SHA-2 gibt es + Pre-Image-Angriffe, die schneller sind als Brute-Force, aber sehr + unpraktisch (z.B. {[}AGM09{]}) + \item + Auch wenn Größe und Komplexität derzeit keine Angriffe zulassen, + ist die Situation unangenehm + \item + Dies führte zur Notwendigkeit eines neuen SHA-3-Standards + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Der sichere Hash-Algorithmus + SHA-3} + + \begin{itemize} + \item + Sicherheitsbedenken bezüglich SHA-1 und SHA-2 führten zu einem offenen + Wettbewerb des NIST, der 2007 begann + + \begin{itemize} + \item + 5 Finalisten ohne nennenswerte Schwächen + \item + Oktober 2012: NIST gibt bekannt, dass Keccak zu SHA-3 wird + \item + 4 europäische Erfinder + \item + Einer davon ist Joan Daemen, der AES mitentwickelt hat + \item + SHA-3 ist sehr schnell, besonders in der Hardware + \item + Sehr gut dokumentiert und analysierbar + \end{itemize} + \item + Keccak basiert auf einer so genannten Schwammkonstruktion anstelle der + früheren Merkle-Dåmgard-Konstruktionen + + \begin{itemize} + \item + Vielseitiges Design, um fast alle symmetrischen kryptographischen + Funktionen zu implementieren (allerdings ist nur das Hashing + standardisiert) + \end{itemize} + \item + Arbeitet normalerweise in 2 Phasen + + \begin{itemize} + \item + ,,Absorbieren'' von Informationen beliebiger Länge in 1600 Bit des + internen Zustands + \item + ,,Auspressen'' (d.h. Ausgeben) von Hash-Daten beliebiger Länge (nur + 224, 256, 384 und 512 Bit standardisiert) + \end{itemize} + \item + Der interne Zustand ist in 2 Registern organisiert + + \begin{itemize} + \item + Ein Register der Größe r ist ,,public'': Eingabedaten werden in der + Absorptionsphase mit XOR verknüpft, Ausgabedaten werden in der + Quetschungsphase daraus abgeleitet + \item + Das Register der Größe c ist ,,privat''; Ein- und Ausgabe wirken + sich nicht direkt auf es aus. + \item + In Keccak ist die Größe der Register 1600 Bits (d.h. \$c+r=1600\$ + Bits) + \item + Die Größe von c ist doppelt so groß wie die Länge des Ausgangsblocks + \item + Beide Register werden mit ,,0'' initialisiert + \end{itemize} + \item + Das Hashing erfolgt durch eine Funktion f, die die Register liest und + einen neuen Zustand ausgibt + \item + Sponge-Konstruktion + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-sha-3.png} + \item + Absorptionsphase: \$k + 1\$ Eingabeblöcke der Größe r werden in den + Zustand gemischt + \item + Quetschphase: \$l + 1\$ Ausgangsblöcke der Größe r werden erzeugt + (oft nur einer) + \item + Der letzte Eingabe- und Ausgabeblock kann aufgefüllt oder + abgeschnitten werden. + \end{itemize} + \item + Die Funktion f + + \begin{itemize} + \item + Offensichtlich hängt die Sicherheit einer Sponge-Konstruktion von + der Sicherheit von f + \item + Keccak verwendet 24 Runden von 5 verschiedenen Unterfunktionen + \$(\textbackslash Sigma, \textbackslash ro,\textbackslash pi,$\chi$,$\iota$)\$, + um f zu implementieren. + \item + Die Unterfunktionen operieren auf einem ,,dreidimensionalen'' + Bit-Array a \${[}5{]}{[}5{]}{[}w{]}\$, wobei w entsprechend der + Größe r und c gewählt wird + \item + Alle Operationen werden über \$GF(2\^{}n)\$ durchgeführt. + \item + Jede der Unterfunktionen gewährleistet bestimmte Eigenschaften, z.B, + + \begin{itemize} + \item + Schnelle Diffusion der geänderten Bits im gesamten Zustand + (\$\textbackslash Sigma\$) + \item + Langfristige Diffusion (\$\textbackslash pi\$) + \item + Sicherstellung, dass f nichtlinear wird ($\chi$) + \item + Rundenspezifische Substitution ($\iota$) + \end{itemize} + \end{itemize} + \item + \$\textbackslash Sigma\$ wird zuerst ausgeführt, um sicherzustellen, + dass sich der geheime und der öffentliche Zustand schnell vermischen, + bevor andere Unterfunktionen angewendet werden. + \item + Sicherheit + + \begin{itemize} + \item + Derzeit gibt es keine nennenswerten Schwachstellen in SHA-3 + + \begin{itemize} + \item + Die bekanntesten Pre-Image-Angriffe funktionieren nur mit einer + Funktion f mit bis zu 8 Runden + \item + Zum Schutz vor internen Kollisionen sollten 11 Runden ausreichen. + \end{itemize} + \item + Im Vergleich zu SHA-1 und SHA-2 werden zusätzliche + Sicherheitseigenschaften garantiert, da der interne Zustand nie + öffentlich gemacht wird + + \begin{itemize} + \item + Verhindert Angriffe, bei denen beliebige Informationen zu einer + gültigen geheimen Nachricht hinzugefügt werden + \item + Bietet Chosen Target Forced Prefix (CTFP) Preimage-Resistenz + {[}KK06{]}, d.h. es ist nicht möglich, eine Nachricht + \$m=P\textbar\textbar S\$ zu konstruieren, wobei P fest und S + beliebig gewählt ist, s.t., \$H(m)=y\$ + \item + Für Merkle-Dåmgard-Konstruktionen ist dies nur so schwer wie die + Kollisionssicherheit + \item + Keine schnelle Möglichkeit, Multikollisionen schnell zu erzeugen + {[}Jou04{]} + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Cipher Block Chaining Message Authentication + Codes} + + \begin{itemize} + \item + Ein CBC-MAC wird berechnet, indem eine Nachricht im CBC-Modus + verschlüsselt wird und der letzte Chiffretextblock oder ein Teil davon + als MAC verwendet wird: + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-CBC-mac.png} + \end{itemize} + \item + Dieser MAC muss nicht mehr signiert werden, da er bereits mit einem + gemeinsamen Geheimnis K erzeugt wurde. + + \begin{itemize} + \item + Es ist jedoch nicht möglich zu sagen, wer genau einen MAC erstellt + hat, da jeder (Sender, Empfänger), der den geheimen Schlüssel K + kennt, dies tun kann + \end{itemize} + \item + Dieses Verfahren funktioniert mit jeder Blockchiffre (DES, IDEA, ...) + \item + Sicherheit von CBC-MAC: + + \begin{itemize} + \item + Da ein Angreifer K nicht kennt, ist ein Geburtstagsangriff sehr viel + schwieriger (wenn nicht gar unmöglich) zu starten + \item + Ein Angriff auf einen CBC-MAC erfordert bekannte Paare (Nachricht, + MAC) + \item + Dies ermöglicht kürzere MACs + \item + Ein CBC-MAC kann optional verstärkt werden, indem man sich auf einen + zweiten Schlüssel \$K'\textbackslash not= K\$ einigt und eine + dreifache Verschlüsselung des letzten Blocks durchführt: + \$MAC:=E(K,D(K',E(K,C\_\{n-1\})))\$ + \item + Dadurch verdoppelt sich der Schlüsselraum bei nur geringem + Rechenaufwand + \item + Die Konstruktion ist nicht sicher, wenn die Nachrichtenlängen + variieren! + \end{itemize} + \item + Es gibt auch einige Vorschläge, MDCs aus symmetrischen Blockchiffren + zu erzeugen, indem der Schlüssel auf einen festen (bekannten) Wert + gesetzt wird: + + \begin{itemize} + \item + Wegen der relativ kleinen Blockgröße von 64 Bit der meisten gängigen + Blockchiffren bieten diese Verfahren keine ausreichende Sicherheit + gegen Geburtstagsangriffe. + \item + Da symmetrische Blockchiffren mehr Rechenaufwand erfordern als + spezielle kryptografische Hash-Funktionen, sind diese Verfahren + relativ langsam. + \end{itemize} + \end{itemize} + + + \subsection{Konstruktion eines MAC aus einem + MDC} + + \begin{itemize} + \item + Grund für die Konstruktion von MACs aus MDCs Kryptografische + Hash-Funktionen laufen im Allgemeinen schneller ab als symmetrische + Blockchiffren + \item + Grundidee: ,,mix'' einen geheimen Schlüssel K mit der Eingabe und + berechne einen MDC + \item + Die Annahme, dass ein Angreifer K kennen muss, um einen gültigen MAC + zu erzeugen, wirft dennoch einige kryptografische Probleme auf + (zumindest für Merkle-Dåmgard-Hash-Funktionen): + + \begin{itemize} + \item + Die Konstruktion \$H(K\textbar\textbar m)\$ ist nicht sicher (siehe + Anmerkung 9.64 in {[}Men97a{]}) + \item + Die Konstruktion \$H(m\textbar\textbar K)\$ ist nicht sicher (siehe + Bemerkung 9.65 in {[}Men97a{]}) + \item + Die Konstruktion + \$H(K\textbar\textbar p\textbar\textbar m\textbar\textbar K)\$, bei + der p ein zusätzliches Auffüllfeld bezeichnet, bietet keine + ausreichende Sicherheit (siehe Anmerkung 9.66 in {[}Men97a{]}) + \end{itemize} + \item + Die am häufigsten verwendete Konstruktion ist: + \$H(K\textbackslash oplus p\_1\textbar\textbar{} + H(K\textbackslash oplus p\_2\textbar\textbar{} m))\$ + + \begin{itemize} + \item + Der Schlüssel wird mit 0's aufgefüllt, um den Schlüssel zu einem + Eingabeblock der kryptographischen Hashfunktion aufzufüllen + \item + Zwei verschiedene konstante Muster \$p\_1\$ und \$p\_2\$ werden mit + dem aufgefüllten Schlüssel XOR-verknüpft + \item + Dieses Schema scheint sicher zu sein (siehe Anmerkung 9.67 in + {[}Men97a{]}) + \item + Es wurde in RFC 2104 {[}Kra97a{]} standardisiert und wird HMAC + genannt. + \end{itemize} + \end{itemize} + + + \subsection{Authentifizierte Verschlüsselung mit zugehörigen Daten + (AEAD) + Modi} + + \begin{itemize} + \item + Normalerweise sind die Daten nicht authentifiziert oder verschlüsselt, + sondern verschlüsselt UND authentifiziert (Blöcke \$P\_0...P\_n\$) + \item + Manchmal müssen zusätzliche Daten authentifiziert werden (z.B. + Paketköpfe), im Folgenden mit \$A\_0...A\_m\$ bezeichnet + \item + führte zur Entwicklung von AEAD-Betriebsarten + \item + Beispiele hierfür sind + + \begin{itemize} + \item + Galois/Zähler-Modus (GCM) + \item + Zähler mit CBC-MAC (CCM) + \item + Offset-Codebuch-Modus (OCM) + \item + SpongeWrap - eine Methode zur Verwendung von Keccak für den + AEAD-Betrieb + \end{itemize} + \end{itemize} + + + \subsubsection{Galois/Zähler-Modus (GCM) + {[}MV04{]}} + + \begin{itemize} + \item + Beliebter AEAD-Modus + \item + NIST-Standard, Teil von IEEE 802.1AE, IPsec, TLS, SSH usw. + \item + Frei von Patenten + \item + Wird wegen seiner hohen Geschwindigkeit hauptsächlich in + Netzwerkanwendungen eingesetzt + + \begin{itemize} + \item + Äußerst effizient in der Hardware + \item + Prozessorunterstützung auf neueren x86-CPUs + \item + Zeitintensive Aufgaben können vorberechnet und parallelisiert werden + \item + Keine Notwendigkeit für Auffüllungen + \end{itemize} + \item + Verwendet konventionelle Blockchiffre mit 128-Bit-Blockgröße (z. B. + AES) + \item + Berechnet MAC durch Multiplikationen und Additionen in + \$GF(2\^{}\{128\})\$ über das irreduzible Polynom + \$x\^{}\{128\}+x\^{}\{7\}+x\^{}\{2\}+x+1\$ + \item + Erfordert nur \$n+1\$ Blockchiffre-Aufrufe pro Paket (n = Länge der + verschlüsselten und authentifizierten Daten) + \item + % \includegraphics{Assets/NetworkSecurity-gcm.png} + + \begin{itemize} + \item + \$I\_0\$ wird mit dem IV und einem Padding oder einem Hash des IV + initialisiert (wenn er nicht 96 Bit beträgt) + \item + \$\textbackslash circ H\$ ist \$GF(2\^{}\{128\})\$ Multiplikation + mit \$H=E(K,0\^{}\{128\})\$ + \item + Die Eingabeblöcke \$A\_m\$ und \$P\_n\$ werden auf 128 Bit + aufgefüllt + \item + \$A\_m\$ und \$C\_n\$ werden vor der Ausgabe auf die Originalgröße + gekürzt + \item + Die letzte Authentifizierung verwendet 64 Bit kodierte Bitlängen von + A und C + \end{itemize} + \item + Sicherheit + + \begin{itemize} + \item + Schneller Modus, erfordert aber einige Sorgfalt: + + \begin{itemize} + \item + Erwiesenermaßen sicher (unter bestimmten Voraussetzungen, z. B. + wenn die verwendete Blockchiffre nicht von Zufallszahlen + unterscheidbar ist), aber die Konstruktion ist anfällig: + \end{itemize} + \item + IVs MÜSSEN NICHT wiederverwendet werden, da sonst Datenströme + XOR-verknüpft werden können und das XOR der Datenströme + wiederhergestellt werden kann, was zu einer sofortigen + Wiederherstellung des geheimen Werts ,,H'' führen kann + \item + H hat einen möglichen schwachen Wert \$0\^{}\{128\}\$, in diesem + Fall wird die Authentifizierung nicht funktionieren, und wenn IVs + mit einer anderen Länge als 96 Bits verwendet werden, wird \$C\_0\$ + immer gleich sein! + \item + Einige andere Schlüssel erzeugen Hash-Schlüssel mit einer niedrigen + Ordnung, was vermieden werden muss... {[}Saa11{]} + \item + Erfolgreiche Fälschungsversuche können Informationen über H + durchsickern lassen, daher MÜSSEN kurze MAC-Längen vermieden oder + risikominimiert werden {[}Dwo07{]} + \item + Die erreichte Sicherheit ist nur \$2\^{}\{t-k\}\$ und nicht + \$2\^{}t\$ (für MAC-Länge t und Anzahl der Blöcke \$2\^{}k\$), da + Blöcke modifiziert werden können, um nur Teile des MAC zu ändern + {[}Fer05{]} + \end{itemize} + \end{itemize} + + + \subsubsection{Kleiner Exkurs: Rechenoperationen in + \$GF(2\^{}n)\$} + + \begin{itemize} + \item + Galoisfeld-Arithmetik definiert über Termen (z.B. + \$a\_3x\^{}3+a\_2x\^{}2+a\_1x+a\_0\$) + \item + Koeffizienten sind Elemente des Feldes + \$\textbackslash matbb\{Z\}\_2\$, d.h. entweder 0 oder 1 + \item + Oft werden nur die Koeffizienten gespeichert, so wird aus x\^{}4 + +x\^{}2 +x\^{}1 0x16 + \item + Die Addition in \$GF(2\^{}n)\$ ist einfach die Addition von Termen + + \begin{itemize} + \item + Da gleiche Koeffizienten auf 0 abbilden, einfach XOR der Werte! + \item + Extrem schnell in Hard- und Software! + \end{itemize} + \item + Multiplikation in \$GF(2\^{}n)\$ ist Polynommultiplikation und + anschließende Modulodivision durch ein irreduzibles Polynom vom Grad n + + \begin{itemize} + \item + Irreduzible Polynome sind nicht ohne Rest durch irgendein anderes + Polynom teilbar, außer durch ,,1'', ähnlich wie Primzahlen in GF + \item + Kann durch eine Reihe von Verschiebe- und XOR-Operationen + implementiert werden + \item + Sehr schnell in Hardware oder auf neueren Intel-CPUs (mit + CLMUL-Operationen) + \item + Modulo-Operation kann wie bei einer regulären CRC-Berechnung + durchgeführt werden + \end{itemize} + \item + Addition Beispiel: + + \begin{itemize} + \item + \$x\^{}3 +x+1 x\textbackslash oplus x\^{}2+x = x\^{}3 +x\^{}2 +1 + \textbackslash leftrightarrow\$ 0x0B XOR 0x06 = 0x0D + \end{itemize} + \item + Multiplikationsbeispiel (über \$x\^{}4 +x+1\$): + + \begin{itemize} + \item + \$x\^{}3 +x+1\textbackslash circ x\^{}2+x = + x\^{}5+x\^{}3+x\^{}2\textbackslash oplus + x\^{}4+x\^{}2+x\textbackslash{} MOD\textbackslash{} + x\^{}4+x+1=x\^{}5+x\^{}4+x\^{}3+x\textbackslash{} + MOD\textbackslash{} x\^{}4+x+1 = x\^{}3 +x\^{}2 +x+1\$ + \end{itemize} + \item + Elemente von \$GF(2\^{}n)\$ (mit Ausnahme von 1 und dem irreduziblen + Polynom) können ein Generator für die Gruppe sein + \item + Beispiel für x und das Polynom + \$x\^{}4+x+1:x,x\^{}2,x\^{}3,x+1,x\^{}2+x,x\^{}3+x\^{}2,x\^{}3+x+1,x\^{}2 + +1,x\^{}3+x,x\^{}2+x+1,x\^{}3+x\^{}2+x,x\^{}3+x\^{}2+x+1,x\^{}3+x\^{}2+1,x\^{}3+1,1,x,...\$ + \item + Andere Konzepte endlicher Gruppen gelten ebenfalls, z. B. hat jedes + Element ein multiplikatives inverses Element + + \begin{itemize} + \item + Kann durch eine angepasste Version des Erweiterten Euklidischen + Algorithmus gefunden werden + \end{itemize} + \end{itemize} + + + \subsection{SpongeWrap} + + \begin{itemize} + \item + Durch Verwendung von SHA-3 ist es auch möglich, ein AEAD-Konstrukt zu + implementieren {[}BDP11a{]} + \item + Die Konstruktion ist sehr einfach und vergleichsweise leicht zu + verstehen + \item + Verwendet den sogenannten Duplex-Modus für Sponge-Funktionen, bei dem + Schreib- und Leseoperationen verschachtelt werden + \item + Erfordert kein Auffüllen der Daten auf eine bestimmte Blockgröße + \item + Kann nicht parallelisiert werden + \item + Sicherheit: + + \begin{itemize} + \item + Noch nicht weit verbreitet, aber mehrere Aspekte haben sich als + genauso sicher wie SHA-3 im standardisierten Modus erwiesen + \item + Wenn die authentifizierten Daten A keine eindeutige IV enthalten, + wird derselbe Schlüsselstrom erzeugt (ermöglicht die + Wiederherstellung eines Blocks XOR-verschlüsselter Daten) + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-sponge-wrap.png} + + \begin{itemize} + \item + Vereinfachte Version, bei der die Länge von Schlüssel und MAC + kleiner sein muss als die Blockgröße + \item + Auffüllungen mit einem einzelnen ,,0''- oder ,,1''-Bit stellen + sicher, dass verschiedene Datenblocktypen gut voneinander getrennt + sind + \end{itemize} + \end{itemize} + + + \section{Zufallszahlengenerierung} + + + \subsection{Aufgaben der + Schlüsselverwaltung} + + \begin{itemize} + \item + Erzeugung: + + \begin{itemize} + \item + Für die Sicherheit ist es von entscheidender Bedeutung, dass die + Schlüssel mit einem wirklich zufälligen oder zumindest + pseudozufälligen Generierungsverfahren erzeugt werden (siehe unten). + \item + Andernfalls könnte ein Angreifer den Schlüsselgenerierungsprozess + reproduzieren und den zur Sicherung einer bestimmten Kommunikation + verwendeten Schlüssel leicht finden. + \end{itemize} + \item + Verteilung: + + \begin{itemize} + \item + Die Verteilung einiger anfänglicher Schlüssel muss in der Regel + manuell / "out of band" erfolgen. + \item + Die Verteilung von Sitzungsschlüsseln wird in der Regel während + eines Authentifizierungsaustauschs durchgeführt. + \item + Beispiele: Diffie-Hellman, Otway-Rees, Kerberos, X. + \end{itemize} + \item + Speicherung: + + \begin{itemize} + \item + Schlüssel, insbesondere Authentifizierungsschlüssel, sollten sicher + gespeichert werden: + + \begin{itemize} + \item + entweder verschlüsselt mit einer schwer zu erratenden Passphrase, + oder besser + \item + in einem sicheren Gerät wie einer Smart-Card + \end{itemize} + \end{itemize} + \item + Entzug: + + \begin{itemize} + \item + Wenn ein Schlüssel kompromittiert wurde, sollte es möglich sein, + diesen Schlüssel zu widerrufen, damit er nicht mehr missbraucht + werden kann (vgl. X.509). + \end{itemize} + \item + Vernichtung: + + \begin{itemize} + \item + Schlüssel, die nicht mehr verwendet werden (z. B. alte + Sitzungsschlüssel), sollten sicher vernichtet werden. + \end{itemize} + \item + Wiederherstellung: + + \begin{itemize} + \item + Wenn ein Schlüssel verloren gegangen ist (z. B. defekte Chipkarte, + Diskette, versehentliches Löschen), sollte er wiederhergestellt + werden können, um Datenverluste zu vermeiden. + \item + Die Wiederherstellung von Schlüsseln ist nicht zu verwechseln mit + der Schlüsselhinterlegung + \end{itemize} + \item + Hinterlegung: + + \begin{itemize} + \item + Mechanismen und Architekturen, die es staatlichen Stellen (und nur + diesen) ermöglichen sollen, Sitzungsschlüssel zu erhalten, um zu + Strafverfolgungszwecken die Kommunikation abzuhören / gespeicherte + Daten zu lesen + + \begin{itemize} + \item + Wenn ich meinen Schlüssel zurückbekomme, ist es + Schlüsselwiederherstellung, wenn du meinen Schlüssel + zurückbekommst, ist es Schlüsselhinterlegung...'') + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Zufalls- und + Pseudo-Zufallszahlengenerierung} + + \begin{itemize} + \item + Definition: ,,Ein Zufallsbitgenerator ist ein Gerät oder ein + Algorithmus, der eine Folge statistisch unabhängiger und + unverfälschter Binärziffern ausgibt.'' + \item + Bemerkung: Ein Zufallsbitgenerator kann zur Erzeugung gleichmäßig + verteilter Zufallszahlen verwendet werden, z. B. kann eine zufällige + ganze Zahl im Intervall \${[}0,n{]}\$ erhalten werden, indem eine + zufällige Bitfolge der Länge \$\textbackslash lfloor lg + n\textbackslash rfloor+1\$ erzeugt und in eine Zahl umgewandelt wird. + Ist die resultierende ganze Zahl größer als n, so kann sie verworfen + werden, und der Vorgang wird so lange wiederholt, bis eine ganze Zahl + im gewünschten Bereich erzeugt worden ist. + \item + Definition: Ein Pseudo-Zufallsbitgenerator (PRBG) ist ein + deterministischer Algorithmus, der bei einer wirklich zufälligen + Binärfolge der Länge k eine Binärfolge der Länge + \$m\textgreater\textgreater k\$ ausgibt, die ,,zufällig'' erscheint. + Die Eingabe in den PRBG wird als Seed bezeichnet, die Ausgabe als + pseudozufällige Bitfolge. + \item + Bemerkungen: + + \begin{itemize} + \item + Die Ausgabe eines PRBG ist nicht zufällig, tatsächlich ist die + Anzahl der möglichen Ausgabesequenzen der Länge m höchstens ein + kleiner Bruchteil \$2\^{}k/2\^{}m\$, da der PRBG immer dieselbe + Ausgabesequenz für einen (festen) Seed erzeugt + \item + Die Motivation für die Verwendung einer PRBG ist, dass es zu teuer + sein könnte, echte Zufallszahlen der Länge m zu erzeugen, z. B. + durch Münzwurf, so dass nur eine kleinere Menge von Zufallsbits + erzeugt wird und dann aus den k echten Zufallsbits eine + pseudozufällige Bitfolge erzeugt wird + \item + Um Vertrauen in die ,,Zufälligkeit'' einer Pseudo-Zufallsfolge zu + gewinnen, werden statistische Tests mit den erzeugten Folgen + durchgeführt + \end{itemize} + \item + Beispiel: + + \begin{itemize} + \item + Ein linearer Kongruenzgenerator erzeugt eine Pseudo-Zufallsfolge von + Zahlen \$y\_1,y\_2, ...\$ gemäß der linearen Rekursion \$y\_i= + a\textbackslash times y\_\{i-1\} + b\textbackslash{} + mod\textbackslash{} q\$, wobei \$a, b, q\$ Parameter sind, die den + PRBG charakterisieren + \item + Leider ist dieser Generator auch dann vorhersehbar, wenn \$a, b\$ + und \$q\$ unbekannt sind, und sollte daher nicht für + kryptographische Zwecke verwendet werden + \end{itemize} + \item + Sicherheitsanforderungen an PRBGs für die Verwendung in der + Kryptographie: + + \begin{itemize} + \item + Als Mindestsicherheitsanforderung sollte die Länge k des Seeds einer + PRBG so groß sein, dass eine Brute-Force-Suche über alle Seeds für + einen Angreifer nicht durchführbar ist + \item + Die Ausgabe einer PRBG sollte statistisch nicht von echten + Zufallssequenzen unterscheidbar sein. + \item + Die Ausgabebits sollten für einen Angreifer mit begrenzten + Ressourcen unvorhersehbar sein, wenn er den Seed nicht kennt. + \end{itemize} + \item + Definition: Ein PRBG besteht alle statistischen Polynomialzeit-Tests, + wenn kein deterministischer Polynomialzeit-Algorithmus zwischen einer + Ausgangssequenz des Generators und einer echten Zufallssequenz + derselben Länge mit einer Wahrscheinlichkeit deutlich größer als 0 + unterscheiden kann. + + \begin{itemize} + \item + Polynomialzeit-Algorithmus bedeutet, dass die Laufzeit des + Algorithmus durch ein Polynom in der Länge m der Sequenz begrenzt + ist + \end{itemize} + \item + Definition: Ein PRBG besteht den Next-Bit-Test, wenn es keinen + deterministischen Polynomialzeit-Algorithmus gibt, der bei Eingabe der + ersten m Bits einer Ausgangssequenz \$s\$ das \$(m+1)\$-te Bit + \$s\_\{m+1\}\$ der Ausgangssequenz mit einer Wahrscheinlichkeit + deutlich größer als 0 vorhersagen kann. + \item + Theorem (Universalität des Next-Bit-Tests): Wenn eine PRBG den + Next-Bit-Test \$\textbackslash Leftrightarrow\$ besteht, dann besteht + sie alle statistischen Polynomialzeittests + \item + Definition: Ein PRBG, der den Next-Bit-Test besteht - möglicherweise + unter einer plausiblen, aber unbewiesenen mathematischen Annahme wie + der Unlösbarkeit des Faktorisierungsproblems für große ganze Zahlen - + wird als kryptographisch sicherer Pseudo-Zufallsgenerator (CSPRBG) + bezeichnet + \end{itemize} + + + \subsection{Zufallszahlengenerierung} + + \begin{itemize} + \item + Hardware-basierte Zufallsbit-Generatoren basieren auf physikalischen + Phänomenen, wie: + + \begin{itemize} + \item + die verstrichene Zeit zwischen der Emission von Teilchen beim + radioaktiven Zerfall, + \item + thermisches Rauschen einer Halbleiterdiode oder eines Widerstandes, + \item + Frequenzinstabilität eines frei laufenden Oszillators, + \item + der Betrag, um den ein Metall-Isolator-Halbleiter-Kondensator + während eines bestimmten Zeitraums aufgeladen wird, + \item + Luftturbulenzen in einem versiegelten Festplattenlaufwerk, die + zufällige Schwankungen in den Sektor-Lese-Latenzen des + Festplattenlaufwerks verursachen, und + \item + Ton von einem Mikrofon oder Videoeingang von einer Kamera + \item + der Zustand einer ungeraden Anzahl von kreisförmig verbundenen + NOT-Gattern + \end{itemize} + \item + Ein hardwarebasierter Zufallsbitgenerator sollte idealerweise in einer + manipulationssicheren Vorrichtung untergebracht und so vor möglichen + Angreifern geschützt sein. + \item + Softwarebasierte Zufallsbit-Generatoren können auf Prozessen basieren + wie + + \begin{itemize} + \item + der Systemuhr, + \item + der verstrichenen Zeit zwischen Tastenanschlägen oder + Mausbewegungen, + \item + Inhalt von Eingabe-/Ausgabepuffern + \item + Benutzereingaben und + \item + Werte des Betriebssystems wie Systemauslastung und + Netzwerkstatistiken + \end{itemize} + \item + Idealerweise sollten mehrere Zufallsquellen ,,gemischt'' werden, z. B. + durch Verkettung ihrer Werte und Berechnung eines kryptografischen + Hashwerts für den kombinierten Wert, um zu verhindern, dass ein + Angreifer den Zufallswert erraten kann + + \begin{itemize} + \item + Wird z. B. nur die Systemuhr als Zufallsquelle verwendet, könnte ein + Angreifer die aus dieser Zufallsquelle gewonnenen Zufallszahlen + erraten, wenn er weiß, wann sie erzeugt wurden. + \end{itemize} + \item + Verzerrung: + + \begin{itemize} + \item + Betrachten wir einen Zufallsgenerator, der verzerrte, aber + unkorrelierte Bits erzeugt, z. B. 1en mit der Wahrscheinlichkeit + \$p\textbackslash not= 0,5\$ und 0en mit der Wahrscheinlichkeit + \$1-p\$, wobei p unbekannt, aber fest ist + \end{itemize} + \item + Die folgende Technik kann verwendet werden, um eine Zufallsfolge zu + erhalten, die unkorreliert und unverzerrt ist: + + \begin{itemize} + \item + Die Ausgangssequenz des Generators wird in Bitpaare gruppiert + \item + Alle Paare 00 und 11 werden verworfen. + \item + Für jedes Paar 10 erzeugt der unvoreingenommene Generator eine 1 und + für jedes Paar 01 eine 0. + \end{itemize} + \item + Ein weiteres praktisches (wenn auch nicht beweisbares) Verfahren zur + Entzerrung ist die Weiterleitung von Sequenzen, deren Bits korreliert + oder verzerrt sind, durch eine kryptografische Hash-Funktion wie MD5 + oder SHA-1 + \end{itemize} + + + \subsection{Statistische Tests für + Zufallszahlen} + + \begin{itemize} + \item + Mit den folgenden Tests lässt sich überprüfen, ob eine generierte + Zufalls- oder Pseudozufallsfolge bestimmte statistische Eigenschaften + nicht erfüllt: + + \begin{itemize} + \item + Monobit-Test: Gibt es gleich viele 1en wie 0en? + \item + Serieller Test (Zwei-Bit-Test): Gibt es gleich viele 00-, 01-, 10-, + 11-Paare? + \item + Poker-Test: Gibt es gleich viele Sequenzen ni der Länge q, die mit + \$q\$ den gleichen Wert haben, so dass \$\textbackslash lfloor + m/q\textbackslash rfloor\textbackslash geq 5\textbackslash times + (2\^{}q)\$ + \item + Test auf Durchläufe: Entspricht die Anzahl der Läufe (Sequenzen, die + nur entweder 0 oder 1 enthalten) unterschiedlicher Länge den + Erwartungen für Zufallszahlen? + \item + Autokorrelationstest: Gibt es Korrelationen zwischen der Sequenz und + (nicht-zyklischen) verschobenen Versionen davon? + \item + Maurer's Universal Test: Kann die Sequenz komprimiert werden? + \item + NIST SP 800-22: Standardisierte Testsuite, umfasst die oben + genannten und weitere fortgeschrittene Tests + \end{itemize} + \end{itemize} + + + \subsection{Sichere + Pseudo-Zufallszahlengenerierung} + + \begin{itemize} + \item + Es gibt eine Reihe von Algorithmen, die kryptografische + Hash-Funktionen oder Verschlüsselungsalgorithmen zur Erzeugung von + kryptografisch sicheren Pseudozufallszahlen verwenden. + + \begin{itemize} + \item + Obwohl diese Verfahren nicht als sicher bewiesen werden können, + scheinen sie für die meisten praktischen Situationen ausreichend + \end{itemize} + \item + Ein solcher Ansatz ist der Generator ANSI X9.17: + + \begin{itemize} + \item + Eingabe: ein zufälliger und geheimer 64-Bit-Seed s, eine ganze Zahl + m und ein 3-DES-Schlüssel K + \item + Ausgabe: m pseudo-zufällige 64-Bit-Strings \$y\_1,y\_2,...Y\_m\$ + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$q = E(K, Date\_Time)\$ + \item + For i von 1 bis m do + + \begin{enumerate} + \def\labelenumii{\arabic{enumii}.} + \item + \$x\_i = E(K, (q\textbackslash oplus s)\$ + \item + \$s = E(K, (x\_i\textbackslash oplus q)\$ + \end{enumerate} + \item + \$Return(x\_1,x\_2,...x\_m)\$ + \end{enumerate} + \item + Diese Methode ist eine vom U.S. Federal Information Processing + Standard (FIPS) zugelassene Methode zur pseudozufälligen Erzeugung + von Schlüsseln und Initialisierungsvektoren zur Verwendung mit DES + \end{itemize} + \item + Das RSA-PRBG ist ein CSPRBG unter der Annahme, dass das RSA-Problem + unlösbar ist: + + \begin{itemize} + \item + Ausgabe: eine pseudo-zufällige Bitfolge \$z\_1,z\_2,...,z\_k\$ der + Länge k + \end{itemize} + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + Setup-Prozedur: Erzeuge zwei geheime Primzahlen \$p, q\$, die für + die Verwendung mit RSA geeignet sind. Berechne + \$n=p\textbackslash times q\$ und + \$\textbackslash phi=(p-1)\textbackslash times(q-1)\$. Wähle eine + zufällige ganze Zahl e so, dass + \$1\textless e\textless\textbackslash phi\$ und + \$gcd(e,\textbackslash phi)=1\$ + \item + Wähle eine zufällige ganze Zahl \$y\_0\$ (den Keim) so, dass + \$y\_0\textbackslash in {[}1,n{]}\$ + \item + Für i von 1 bis k tun + + \begin{enumerate} + \def\labelenumii{\arabic{enumii}.} + \item + \$y\_i=(y\_\{i-1\})\^{}e\textbackslash{} mod\textbackslash{} n\$ + \item + \$z\_i =\$ das niedrigstwertige Bit von \$y\_i\$ + \end{enumerate} + \end{enumerate} + + \begin{itemize} + \item + Die Effizienz des Generators kann leicht verbessert werden, indem + man die letzten j Bits von jedem \$y\_i\$ nimmt, wobei + \$j=c\textbackslash times lg(lg(n))\$ und c eine Konstante ist + \item + Für eine gegebene Bitlänge m von n wurde jedoch noch kein + Wertebereich für die Konstante c ermittelt, in dem der Algorithmus + noch einen CSPRBG ergibt + \end{itemize} + \item + Der Blum-Blum-Shub-PRBG ist ein CSPRBG unter der Annahme, dass das + Problem der ganzzahligen Faktorisierung unlösbar ist: + + \begin{itemize} + \item + Ausgabe: eine pseudo-zufällige Bitfolge \$z\_1,z\_2,...,z\_k\$ der + Länge k + \end{itemize} + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + Setup-Prozedur: Erzeuge zwei große geheime und unterschiedliche + Primzahlen \$p,q\$, so dass \$p,q\$ jeweils kongruent 3 modulo 4 + sind, und lass \$n=p\textbackslash times q\$ + \item + Wähle eine zufällige ganze Zahl s (den Keim) so, dass + \$s\textbackslash in {[}1, n-1{]}\$ liegt, so dass \$gcd(s,n)=1\$ + und \$y\_0=s\^{}2\textbackslash{} mod\textbackslash{} n\$ + \item + Für i von 1 bis k tun + + \begin{enumerate} + \def\labelenumii{\arabic{enumii}.} + \item + \$y\_i = (y\_\{i-1\})\^{}2\textbackslash{} mod\textbackslash{} n\$ + \item + \$z\_i =\$ das niedrigstwertige Bit von \$y\_i\$ + \end{enumerate} + \end{enumerate} + + \begin{itemize} + \item + Die Effizienz des Generators kann mit der gleichen Methode wie beim + RSA-Generator verbessert werden, wobei ähnliche Einschränkungen für + die Konstante c gelten + \end{itemize} + \item + Dualer deterministischer Zufallsbitgenerator mit elliptischer Kurve: + + \begin{itemize} + \item + Basierend auf der Unlösbarkeit des Problems des diskreten + Logarithmus elliptischer Kurven + \item + Vereinfachte Version: + % \includegraphics{Assets/NetworkSecurity-dual-elliptic-curve-deterministic-random-bit-generator.png} + \item + Der Zustand t wird mit einem Generator P multipliziert, der x-Wert + des neuen Punktes wird zu t' + \item + Multiplikation mit einem anderen Punkt Q r Bits der Ausgabe können + erzeugt werden, die Anzahl der Bits hängt von der Kurve ab (zwischen + 240 und 504 Bits) + \item + Teil der Norm NIST 800-90A + \item + Sicherheit: + + \begin{itemize} + \item + Es wurde gezeigt, dass Angreifer den Zustand t ableiten können, + wenn P für eine Konstante e gleich eQ gewählt wird. + \item + Wir wissen nicht, wie die vordefinierten Punkte P und Q in NIST + 800-90A abgeleitet werden, also Vorsicht + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{CSPRNG-Sicherheit ist eine große + Sache!} + + \begin{itemize} + \item + Im September 2006 wurde Debian versehentlich so verändert, dass nur + die Prozess-ID verwendet wurde, um den OpenSSL CSPRNG zu füttern + + \begin{itemize} + \item + Nur 32.768 mögliche Werte! + \item + Wurde bis Mai 2008 nicht entdeckt + \end{itemize} + \item + Ein Scan von etwa 23 Millionen TLS- und SSH-Hosts zeigte, dass + + \begin{itemize} + \item + Mindestens 0,34\% der Hosts teilten Schlüssel aufgrund fehlerhafter + RNGs + \item + 0,50\% der gescannten TLS-Schlüssel aufgrund einer geringen + Zufälligkeit kompromittiert werden konnten + \item + und 1,06\% der SSH-Hosts... + \end{itemize} + \item + Überwachen Sie Ihren CSPRNG! + + \begin{itemize} + \item + Generieren Sie keine Zufallszahlen direkt nach dem Booten Ihres + Systems + \item + Verwenden Sie blockierende RNGs, d.h. solche, die nicht fortfahren, + bis sie genügend Entropie haben + \end{itemize} + \end{itemize} + + + \section{Kryptographische + Protokolle} + + \begin{itemize} + \item + Definition: Ein kryptographisches Protokoll ist definiert als eine + Reihe von Schritten und der Austausch von Nachrichten zwischen + mehreren Einheiten, um ein bestimmtes Sicherheitsziel zu erreichen. + \item + Eigenschaften eines Protokolls (im Allgemeinen): + + \begin{itemize} + \item + Jeder, der an dem Protokoll beteiligt ist, muss das Protokoll und + alle zu befolgenden Schritte im Voraus kennen + \item + Jeder, der an dem Protokoll beteiligt ist, muss zustimmen, es zu + befolgen. + \item + Das Protokoll muss eindeutig sein, d.h. jeder Schritt ist genau + definiert, und es gibt keine Möglichkeit für Missverständnisse + \item + Das Protokoll muss vollständig sein, d. h. es gibt für jede mögliche + Situation eine bestimmte Aktion. + \end{itemize} + \item + Zusätzliche Eigenschaft eines kryptographischen Protokolls: + + \begin{itemize} + \item + Es sollte nicht möglich sein, mehr zu tun oder zu erfahren als das, + was im Protokoll angegeben ist. + \end{itemize} + \end{itemize} + + + \subsection{Anwendungen von kryptographischen + Protokollen} + + \begin{itemize} + \item + Schlüsselaustausch + \item + Authentifizierung + + \begin{itemize} + \item + Authentifizierung der Datenherkunft + \item + Authentifizierung von Entitäten + \end{itemize} + \item + Kombinierte Authentifizierung und Schlüsselaustausch + \item + Aufteilung des Geheimnisses (alle Teile werden für die Rekonstruktion + benötigt) + \item + Gemeinsame Nutzung des Geheimnisses (m von n Teilen werden für die + Rekonstruktion benötigt) + \item + Zeitstempelung + \item + Schlüsselhinterlegung (Sicherstellung, dass nur eine befugte Stelle + Schlüssel wiederherstellen kann) + \item + Zero-Knowledge-Beweise (Nachweis der Kenntnis einer Information ohne + Offenlegung der Information) + \item + Blindsignaturen (nützlich für die Wahrung der Privatsphäre bei + Zeitstempeldiensten) + \item + Sichere Wahlen + \item + Elektronisches Geld + \end{itemize} + + + \subsection{Schlüsselaustausch} + + \begin{itemize} + \item + Das vorgestellte Diffie-Hellman-Protokoll ist unser erstes Beispiel + für ein kryptographisches Protokoll zum Schlüsselaustausch + \item + Bitte beachten Sie, dass es keine Authentifizierung realisiert: + + \begin{itemize} + \item + Weder Alice noch Bob wissen nach einem Protokolldurchlauf, mit wem + sie einen Schlüssel ausgetauscht haben + \item + Da dieser reine Schlüsselaustausch ohne Authentifizierung nicht + einmal die Vertraulichkeit der Kommunikation nach dem Austausch + garantieren kann, muss er mit Authentifizierung kombiniert werden + \end{itemize} + \item + Diese Trennung von Schlüsselaustausch und Authentifizierung des + Austauschs hat jedoch einen großen Vorteil, da sie es ermöglicht, die + Eigenschaft des perfekten Vorwärtsgeheimnisses (Perfect Forward + Secrecy, PFS) zu gewährleisten: + + \begin{itemize} + \item + Wenn ein Schlüsselaustausch PFS gewährleistet, kann die + Kompromittierung eines Schlüssels in der Zukunft keine Daten + kompromittieren, die mit anderen Schlüsseln geschützt wurden, die + vor dieser Kompromittierung ausgetauscht wurden. + \item + Beispiel: Stellen Sie sich vor, Alice und Bob signieren beide die + zur Berechnung von sk ausgetauschten Daten mit ihren privaten + Schlüsseln. Selbst die Kompromittierung eines privaten Schlüssels in + der Zukunft wird es nicht ermöglichen, aufgezeichnete Daten zu + entschlüsseln, die mit sk geschützt wurden. + \end{itemize} + \end{itemize} + + + \subsection{Authentifizierung der + Datenherkunft} + + Definition: Die Datenursprungsauthentifizierung ist der + Sicherheitsdienst, der es Entitäten ermöglicht, zu überprüfen, ob eine + Nachricht von einer bestimmten Entität stammt und nicht nachträglich + verändert wurde. Ein Synonym für diesen Dienst ist Datenintegrität. + + \begin{itemize} + \item + Die Beziehung zwischen Datenintegrität und kryptografischen + Protokollen ist zweifach: + + \begin{itemize} + \item + Es gibt kryptografische Protokolle zur Sicherstellung der + Datenintegrität. Sie umfassen in der Regel nur einen + Protokollschritt und sind daher nicht sehr ,,spannend'': + + \begin{itemize} + \item + Beispiel 1: Angenommen, jeder kennt den öffentlichen RSA-Schlüssel + von Alice und kann sicher sein, dass er den Schlüssel von Alice + wirklich kennt, dann kann Alice die Datenintegrität ihrer + Nachrichten sicherstellen, indem sie sie mit ihrem privaten + Schlüssel verschlüsselt. + \item + Beispiel 2: Alice kann auch einen MDC über ihre Nachricht + berechnen und den mit ihrem privaten Schlüssel verschlüsselten MDC + an die Nachricht anhängen + \end{itemize} + \item + Die Datenintegrität der ausgetauschten Nachrichten ist oft eine + wichtige Eigenschaft in kryptografischen Protokollen, daher ist die + Datenintegrität ein Baustein für kryptografische Protokolle + \end{itemize} + \end{itemize} + + + \subsection{Authentifizierung von + Entitäten} + + Definition: Entitätsauthentifizierung ist der Sicherheitsdienst, der es + Kommunikationspartnern ermöglicht, die Identität ihrer Peer-Entitäten zu + überprüfen. + + \begin{itemize} + \item + Die Entitätsauthentifizierung ist der grundlegendste + Sicherheitsdienst, da alle anderen Sicherheitsdienste auf ihr + aufbauen. + \item + Im Allgemeinen kann sie durch verschiedene Mittel erreicht werden: + + \begin{itemize} + \item + Wissen: z. B. Passwörter + \item + Besitz: z. B. physische Schlüssel oder Karten + \item + Unveränderliches Merkmal: z. B. biometrische Eigenschaften wie + Fingerabdruck usw. + \item + Ort: Es wird der Nachweis erbracht, dass sich eine Entität an einem + bestimmten Ort befindet (Beispiel: Menschen überprüfen selten die + Authentizität von Agenten in einer Bank) + \item + Delegation der Authentizität: Die überprüfende Stelle akzeptiert, + dass eine vertrauenswürdige Person die Authentifizierung bereits + vorgenommen hat. + \end{itemize} + \item + In Kommunikationsnetzen ist die direkte Überprüfung der oben genannten + Mittel schwierig oder unsicher, weshalb kryptographische Protokolle + erforderlich sind. + \item + Der Hauptgrund, warum die Authentifizierung von Entitäten mehr ist als + ein Austausch von (datenherkunfts-) authentischen Nachrichten, ist die + Aktualität: + + \begin{itemize} + \item + Selbst wenn Bob während einer Kommunikation authentische Nachrichten + von Alice erhält, kann er nicht sicher sein, ob: + + \begin{itemize} + \item + Alice zu diesem Zeitpunkt tatsächlich an der Kommunikation + teilnimmt, oder ob + \item + Eve alte Nachrichten von Alice abspielt + \end{itemize} + \item + Dies ist von besonderer Bedeutung, wenn die Authentifizierung nur + zum Zeitpunkt des Verbindungsaufbaus erfolgt: + + \begin{itemize} + \item + Beispiel: Übermittlung einer (möglicherweise verschlüsselten) PIN + beim Einloggen + \end{itemize} + \item + Zwei grundsätzliche Mittel zur Sicherstellung der Aktualität in + kryptographischen Protokollen: + + \begin{itemize} + \item + Zeitstempel (erfordern mehr oder weniger synchronisierte Uhren) + \item + Zufallszahlen (Challenge-Response-Austausch) + \end{itemize} + \end{itemize} + \item + Die meisten Authentifizierungsprotokolle erstellen auch einen geheimen + Sitzungsschlüssel zur Sicherung der Sitzung nach dem + Authentifizierungsaustausch + \item + Zwei Hauptkategorien von Protokollen für die Authentifizierung von + Entitäten: + + \begin{itemize} + \item + Arbitrierte Authentifizierung: ein Arbiter, auch vertrauenswürdige + dritte Partei (TTP) genannt, ist direkt an jedem + Authentifizierungsaustausch beteiligt + + \begin{itemize} + \item + Vorteile: + + \begin{itemize} + \item + Dies ermöglicht es zwei Parteien A und B, sich gegenseitig zu + authentifizieren, ohne ein vorher festgelegtes Geheimnis zu + kennen. + \item + Selbst wenn sich A und B nicht kennen, kann die symmetrische + Kryptographie verwendet werden. + \end{itemize} + \item + Nachteilig: + + \begin{itemize} + \item + Das TTP kann zu einem Engpass werden, die Verfügbarkeit des TTP + ist entscheidend + \item + Der TTP kann alle Authentifizierungsaktivitäten überwachen. + \end{itemize} + \end{itemize} + \item + Direkte Authentifizierung: A und B authentifizieren sich direkt + gegenseitig + + \begin{itemize} + \item + Vorteile: keine Online-Teilnahme einer dritten Partei erforderlich + und kein möglicher Leistungsengpass wird eingeführt + \item + Nachteile: erfordert asymmetrische Kryptographie oder im Voraus + festgelegte geheime Schlüssel + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Notation kryptographischer + Protokolle} + + %\begin{longtable}[]{@{}ll@{}} + % \toprule + % Notation & Bedeutung\tabularnewline + % \midrule + % \endhead + % \$A\$ & Name von A , analog für B, E, TTP, CA\tabularnewline + % \$CA\_A\$ & Zertifizierungsstelle von A\tabularnewline + % \$r\_A\$ & Zufallswert, gewählt von A\tabularnewline + % \$t\_A\$ & Zeitstempel erzeugt von A\tabularnewline + % \$(m\_1,...,m\_m)\$ & Verkettung von Nachrichten \$m\_1, + % ...,m\_n\$\tabularnewline + % \$A\textbackslash rightarrow B:m\$ & A sendet Nachricht m an + % B\tabularnewline + % \$K\_\{A,B\}\$ & Geheimer Schlüssel, nur A und B bekannt\tabularnewline + % \$+K\_A\$ & Öffentlicher Schlüssel von A\tabularnewline + % \$-K\_A\$ & Privater Schlüssel von A\tabularnewline + % \$\{m\}\_K\$ & Nachricht m verschlüsselt mit Schlüssel K , Synonym für + % \$E(K, m)\$\tabularnewline + % \$H(m)\$ & MDC über Nachricht m, berechnet mit Funktion H\tabularnewline + % \$A{[}m{]}\$ & Kurzschreibweise für + % \$(m,\{H(m)\}\_\{-K\_A\})\$\tabularnewline + % \$Cert\_\{-CK\_\{CA\}\}(+K\_A)\$ & Zertifikat der CA für den + % öffentlichen Schlüssel \$+K\_A\$ von A, signiert mit dem privaten + % Zertifizierungsschlüssel \$-CK\_\{CA\}\$\tabularnewline + % \$CA\textless{}\textgreater\$ & Kurzschreibweise für + % \$Cert\_\{-CK\_\{CA\}\}(+K\_A)\$\tabularnewline + % \bottomrule + %\end{longtable} + + + \subsection{Das + Needham-Schroeder-Protokoll} + + \begin{itemize} + \item + Erfunden im Jahr 1978 von Roger Needham und Michael Schroeder + {[}Nee78a{]} + \item + Das Protokoll basiert auf symmetrischer Verschlüsselung und nutzt eine + vertrauenswürdige dritte Partei (TTP) + \item + Angenommen, TTP teilt die geheimen Schlüssel KA,TTP und KB,TTP mit + Alice bzw. Bob: + + \begin{itemize} + \item + A erzeugt eine Zufallszahl rA und sendet die folgende Nachricht: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$A\textbackslash rightarrow TTP: (A, B, r\_A)\$ + \end{enumerate} + \item + TTP erzeugt einen Sitzungsschlüssel KA,B für die sichere + Kommunikation zwischen A und B und antwortet A: 2. + \$TTP\textbackslash rightarrow A:\{r\_A, B, K\_\{A,B\}, + \{K\_\{A,B\}, A\}\emph{\{K}\{B,TTP\}\}\}\emph{\{K}\{A,TTP\}\}\$ + \item + A entschlüsselt die Nachricht und extrahiert \$K\_\{A,B\}\$. Sie + bestätigt, dass \$r\_A\$ mit der von ihr im ersten Schritt + generierten Zahl identisch ist, so dass sie weiß, dass die Antwort + eine neue Antwort von TTP ist. Dann sendet sie an B: 3.) + \$A\textbackslash rightarrow B:\{K\_\{A,B\}, + A\}\emph{\{K}\{B,TTP\}\}\$ + \item + Bob entschlüsselt die Nachricht und erhält \$K\_\{A,B\}\$. Er + erzeugt dann eine Zufallszahl \$r\_B\$ und antwortet Alice: 4.) + \$B\textbackslash rightarrow A:\{r\_B\}\emph{\{K}\{A,B\}\}\$ + \item + Alice entschlüsselt die Nachricht, errechnet \$r\_\{B\}-1\$ und + antwortet mit: 5.) \$A\textbackslash rightarrow + B:\{r\_B-1\}\emph{\{K}\{A,B\}\}\$ + \item + Bob entschlüsselt die Nachricht und prüft, ob sie \$r\_B-1\$ + enthält. + \end{itemize} + \item + Diskussion: + + \begin{itemize} + \item + Der Austausch von \$r\_B\$ und \$r\_\{B-1\}\$ soll sicherstellen, + dass ein Angreifer, der versucht, sich als Alice auszugeben, keinen + vollständigen Protokolldurchlauf mit nachgespielten Nachrichten + durchführen kann + \item + Da jedoch alte Sitzungsschlüssel \$K\_\{A,B\}\$ gültig bleiben, kann + ein Angreifer, Eve, der es schafft, einen Sitzungsschlüssel + \$K\_\{A,B\}\$ in Erfahrung zu bringen, diesen später dazu + verwenden, sich als Alice auszugeben: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$E\textbackslash rightarrow B:\{K\_\{A,B\}, + A\}\emph{\{K}\{B,TTP\}\}\$ + \item + \$B\textbackslash rightarrow A:\{r\_B\}\emph{\{K}\{A,B\}\}\$ Eve + muss diese Nachricht abfangen + \item + \$E\textbackslash rightarrow B:\{r\_B -1\}\emph{\{K}\{A,B\}\}\$ + \end{enumerate} + + \begin{itemize} + \item + Eve gibt sich also als Alice aus, obwohl sie weder + \$K\_\{A,TTP\}\$ noch \$K\_\{B,TTP\}\$ kennt! + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Das Otway-Rees-Protokoll} + + \begin{itemize} + \item + Das oben beschriebene Sicherheitsproblem sowie einige andere wurden + von Needham und Schroeder behandelt. Ihre Lösung {[}Nee87a{]} ist im + Wesentlichen die gleiche wie die von Otway und Rees in der gleichen + Zeitschrift {[}Otw87a{]} vorgeschlagene: + + \begin{itemize} + \item + Alice generiert eine Nachricht, die eine Indexzahl \$i\_A\$, ihren + Namen A, Bobs Namen B und die gleichen Informationen plus eine + zusätzliche Zufallszahl \$r\_A\$ enthält, die mit dem Schlüssel + \$K\_\{A,TTP\}\$ verschlüsselt ist, den sie mit TTP teilt, und + sendet diese Nachricht an Bob: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$A\textbackslash rightarrow B:(i\_A, A, B,\{r\_A, i\_A, A, + B\}\emph{\{K}\{A,TTP\}\})\$ + \end{enumerate} + \item + Bob erzeugt eine Zufallszahl \$r\_B\$, verschlüsselt sie zusammen + mit \$i\_A\$, A und B mit dem Schlüssel \$K\_\{B,TTP\}\$, den er mit + TTP teilt, und sendet die Nachricht an TTP: 2. + \$B\textbackslash rightarrow TTP:(i\_A, A, + B,\{r\_A,i\_A,A,B\}\emph{\{K}\{A,TTP\}\},\{r\_B,i\_A,A,B\}\emph{\{K}\{B,TTP\}\})\$ + \item + TTP erzeugt einen neuen Sitzungsschlüssel KA,B und erstellt zwei + verschlüsselte Nachrichten, eine für Alice und eine für Bob, und + sendet sie an Bob: 3. \$TTP\textbackslash rightarrow + B:(i\_A,\{r\_A,K\_\{A,B\}\}\emph{\{K}\{A,TTP\}\},\{r\_B, + K\_\{A,B\}\}\emph{\{K}\{B,TTP\}\})\$ + \item + Bob entschlüsselt seinen Teil der Nachricht, verifiziert rB und + sendet Alices Teil der Nachricht an sie: 4. + \$B\textbackslash rightarrow + A:(i\_A,\{r\_A,K\_\{A,B\}\}\emph{\{K}\{A,TTP\}\})\$ + \item + Alice entschlüsselt die Nachricht und überprüft, ob sich \$i\_A\$ + und \$r\_A\$ während des Austauschs nicht geändert haben. Wenn + nicht, kann sie sicher sein, dass TTP ihr einen neuen + Sitzungsschlüssel \$K\_\{A,B\}\$ für die Kommunikation mit Bob + geschickt hat. Wenn sie nun diesen Schlüssel in einer + verschlüsselten Kommunikation mit Bob verwendet, kann sie sich + seiner Authentizität sicher sein. + \end{itemize} + \item + Diskussion: + + \begin{itemize} + \item + Die Indexzahl \$i\_A\$ schützt vor Replay-Attacken. Dies erfordert + jedoch, dass TTP überprüft, ob \$i\_A\$ größer ist als das letzte + \$i\_A\$, das er von Alice erhalten hat. + \item + Da TTP nur dann zwei Nachrichten generiert, wenn beide Teile der + Nachricht, die er erhält, die gleiche Indexnummer \$i\_A\$ und die + Namen \$A, B,\$ enthalten, können Alice und Bob sicher sein, dass + sie sich beide während des Protokolllaufs gegenüber TTP + authentifiziert haben. + \end{itemize} + \end{itemize} + + + \subsection{Kerberos} + + \begin{itemize} + \item + Kerberos ist ein Authentifizierungs- und Zugangskontrolldienst für + Workstation-Cluster, der in den späten 1980er Jahren am MIT entwickelt + wurde. + \item + Entwurfsziele: + + \begin{itemize} + \item + Sicherheit: Abhörer oder aktive Angreifer sollten nicht in der Lage + sein, die notwendigen Informationen zu erhalten, um sich beim + Zugriff auf einen Dienst als ein Benutzer auszugeben + \item + Zuverlässigkeit: Da jede Nutzung eines Dienstes eine vorherige + Authentifizierung erfordert, sollte Kerberos höchst zuverlässig und + verfügbar sein. + \item + Transparenz: Der Authentifizierungsprozess sollte für den Benutzer + transparent sein und nicht nur die Eingabe eines Passworts + erfordern. + \item + Skalierbarkeit: Das System sollte in der Lage sein, eine große + Anzahl von Clients und Servern zu unterstützen. + \end{itemize} + \item + Das Kerberos zugrunde liegende kryptografische Verfahren ist die + symmetrische Verschlüsselung (Kerberos V. 4 verwendet DES, V. 5 + erlaubt andere Algorithmen). + \item + Eine gute Anleitung zu den Überlegungen hinter dem Kerberos-Design + findet sich in {[}Bry88a{]}, wo das Protokoll in einer Reihe von + fiktiven Dialogen entwickelt wird + \item + Das grundlegende Anwendungsszenario von Kerberos ist ein Benutzer, + Alice, der auf einen oder mehrere verschiedene Dienste zugreifen + möchte, die von verschiedenen Servern \$S\_1, S\_2, ...\$ + bereitgestellt werden, die über ein unsicheres Netzwerk verbunden sind + \item + Kerberos befasst sich mit den folgenden Sicherheitsaspekten in diesem + Szenario: + + \begin{itemize} + \item + Authentifizierung: Alice authentifiziert sich bei einem + Authentifizierungsserver (AS), der eine zeitlich begrenzte + Genehmigung für den Zugang zu Diensten erteilt. Diese Erlaubnis wird + Ticket-granting ticket (TicketTGS) genannt und ist vergleichbar mit + einem zeitlich begrenzten Reisepass. + \item + Zugangskontrolle: Durch Vorlage ihres TicketTGS kann Alice einen + Ticket-gewährenden Server (TGS) anfordern, um Zugang zu einem Dienst + zu erhalten, der von einem bestimmten Server S1 bereitgestellt wird. + Der TGS entscheidet, ob der Zugang erlaubt wird und antwortet mit + einem TicketS1 für den Server S. + \item + Schlüsselaustausch: Der Authentifizierungsserver stellt einen + Sitzungsschlüssel für die Kommunikation zwischen Alice und TGS + bereit, und der TGS stellt einen Sitzungsschlüssel für die + Kommunikation zwischen Alice und S1 bereit. Die Verwendung dieser + Sitzungsschlüssel dient auch der Authentifizierung. + \end{itemize} + \end{itemize} + + Zugriff auf einen Dienst mit Kerberos - Protokollübersicht + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-Kerberos.png} + \item + Der Benutzer meldet sich an seiner Arbeitsstation an und fordert den + Zugriff auf einen Dienst an: + + \begin{itemize} + \item + Die Workstation repräsentiert ihn im Kerberos-Protokoll und sendet + die erste Nachricht an den Authentifizierungsserver AS, die seinen + Namen, den Namen eines geeigneten Ticket-Granting-Servers TGS und + einen Zeitstempel \$t\_A\$ enthält: + \end{itemize} + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$A\textbackslash rightarrow AS:(A, TGS, t\_A)\$ + \end{enumerate} + \item + Der AS prüft, ob A sich für den Zugang zu den Diensten + authentifizieren darf, generiert aus A's Passwort (das ihm bekannt + ist) den Schlüssel KA, extrahiert die Arbeitsplatzadresse \$Addr\_A\$ + der Anfrage, erstellt ein Ticket \$Ticket\_\{TGS\}\$ und einen + Sitzungsschlüssel \$K\_\{A,TGS\}\$ und sendet die folgende Nachricht + an A: 2. \$AS\textbackslash rightarrow A:\{K\_\{A,TGS\}, TGS, + t\_\{AS\}, LifetimeTicket\_\{TGS\}, Ticket\_\{TGS\}\}\emph{\{K\_A\}\$ + mit \$Ticket}\{TGS\}=\{K\_\{A,TGS\},A, Addr\_A, TGS, t\_\{AS\}, + LifetimeTicket\_\{TGS\}\}\emph{\{K}\{AS,TGS\}\}\$ + \item + Nach Erhalt dieser Nachricht fordert die Workstation Alice auf, ihr + Passwort einzugeben, berechnet daraus den Schlüssel \$K\_A\$ und + entschlüsselt die Nachricht mit diesem Schlüssel. Wenn Alice nicht ihr + ,,authentisches'' Passwort angibt, sind die extrahierten Werte + ,,Müll'' und der Rest des Protokolls schlägt fehl. + \item + Alice erstellt einen sogenannten Authenticator und sendet ihn zusammen + mit dem Ticket und dem Namen des Servers \$S1\$ an TGS: 3. + \$A\textbackslash rightarrow TGS:(S1, Ticket\_\{TGS\}, + Authenticator\_\{A,TGS\})\$ mit Authenticator + \$A,TGS=\{A,Addr\_A,t'\emph{A\}}\{K\_\{A,TGS\}\}\$ + \item + Nach Erhalt entschlüsselt TGS \$Ticket\_\{TGS\}\$, extrahiert daraus + den Schlüssel \$K\_\{A,TGS\}\$ und verwendet diesen Schlüssel zur + Entschlüsselung von \$Authenticator\_\{A,TGS\}\$. Wenn Name und + Adresse des Authentifikators und des Tickets übereinstimmen und der + Zeitstempel \$t'\emph{A\$ noch frisch ist, wird geprüft, ob A auf den + Dienst S1 zugreifen darf, und die folgende Nachricht erstellt: 4. + \$TGS\textbackslash rightarrow A:\{K}\{A,S1\}, S1, t\_\{TGS\}, + Ticket\_\{S1\}\}\emph{\{K}\{A,TGS\}\}\$ mit + \$Ticket\_\{S1\}=\{K\_\{A,S1\}, A, Addr\_A, S1, t\_\{TGS\}, + LifetimeTicket\_\{S1\}\}\emph{\{K}\{TGS,S\}\}\$ + \item + Alice entschlüsselt die Nachricht und verfügt nun über einen + Sitzungsschlüssel für die sichere Kommunikation mit S1. Sie sendet nun + eine Nachricht an S1, um ihm ihr Ticket und einen neuen + Authentifikator zu zeigen: 5. \$A\textbackslash rightarrow + S1:(Ticket\_\{S1\}, Authenticator\_\{A,S1\})\$ mit + \$Authenticator\_\{A,S1\}=\{A,Addr\_A, t''\emph{A\}}\{K\_\{A,S1\}\}\$ + \item + Nach Erhalt entschlüsselt S1 das Ticket mit dem Schlüssel + \$K\_\{TGS,S1\}\$, den er mit TGS teilt, und erhält den + Sitzungsschlüssel \$K\_\{A,S1\}\$ für die sichere Kommunikation mit A. + Mit diesem Schlüssel überprüft er den Authentifikator und antwortet A: + 6. \$S1\textbackslash rightarrow A:\{t'\,'\emph{A+1\}}\{K\_\{A,S\}\}\$ + \item + Durch Entschlüsselung dieser Nachricht und Überprüfung des enthaltenen + Wertes kann Alice nachweisen, dass sie wirklich mit S1 kommuniziert, + da nur er (neben TGS) den Schlüssel \$K\_\{TGS,S1\}\$ zur + Entschlüsselung von \$Ticket\_\{S1\}\$ kennt, der den + Sitzungsschlüssel \$K\_\{A,S1\}\$ enthält, und somit nur er in der + Lage ist, \$Authenticator\_\{A,S1\}\$ zu entschlüsseln und mit + \$t''\emph{\{A+1\}\$ verschlüsselt mit \$K}\{A,S\}\$ zu antworten + \item + Das oben beschriebene Protokoll ist der Kerberos-Dialog der Version 4. + + \begin{itemize} + \item + In diesem Protokoll wurden eine Reihe von Mängeln festgestellt, so + dass eine neue Version 5 des Protokolls definiert wurde, auf die wir + später eingehen werden... + \item + Wo liegt eigentlich das Problem? + \end{itemize} + \end{itemize} + + + \subsubsection{Kerberos für mehrere + Domänen} + + \begin{itemize} + \item + Stellen Sie sich eine Organisation mit Workstation-Clustern an zwei + verschiedenen Standorten vor, und stellen Sie sich vor, dass Benutzer + A von Standort 1 einen Server von Standort 2 benutzen möchte: + + \begin{itemize} + \item + Wenn beide Standorte ihre eigenen Kerberos-Server und + Benutzerdatenbanken (mit Passwörtern) verwenden, gibt es in der Tat + zwei verschiedene Domänen, in der Kerberos-Terminologie auch Realms + genannt. + \item + Um zu vermeiden, dass der Benutzer A in beiden Realms registriert + sein muss, ermöglicht Kerberos eine Inter-Realm-Authentifizierung. + \end{itemize} + \item + Die Inter-Realm-Authentifizierung erfordert, dass die + Ticket-erteilenden Server beider Domänen einen geheimen Schlüssel + \$K\_\{TGS1,TGS2\}\$ teilen. + + \begin{itemize} + \item + Die Grundidee ist, dass der TGS eines anderen Realms als normaler + Server angesehen wird, für den der TGS des lokalen Realms ein Ticket + ausstellen kann. + \item + Nachdem Alice das Ticket für den entfernten Realm erhalten hat, + fordert sie ein Ticket für den Dienst beim entfernten TGS an. + \item + Dies bedeutet jedoch, dass der entfernte Realm dem + Kerberos-Authentifizierungsdienst der Heimatdomäne eines + ,,besuchenden'' Benutzers vertrauen muss! + \item + Skalierbarkeitsproblem: n Realms benötigen + \$n\textbackslash times(n-1)/2\$ geheime Schlüssel! + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-multi-domain-kerberos.png} + \item + Nachrichten, die während eines Protokolllaufs mit mehreren Domänen + ausgetauscht werden: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$A\textbackslash rightarrow AS1:(A,TGS1, t\_A)\$ + \item + \$AS1\textbackslash rightarrow A:\{K\_\{A,TGS1\}, TGS1, t\_\{AS\}, + LifetimeTicket\_\{TGS1\}, Ticket\_\{TGS1\}\}\emph{\{K\_A\}\$ mit + \$Ticket}\{TGS1\}=\{K\_\{A,TGS1\}, A, Addr\_A, TGS1, t\_\{AS\}, + LifetimeTicket\_\{TGS1\}\}\emph{\{K}\{AS,TGS1\}\}\$ + \item + \$A\textbackslash rightarrow + TGS1:(TGS2,Ticket\_\{TGS1\},Authenticator\_\{A,TGS1\})\$ mit + \$Authenticator\_\{A,TGS1\}=\{A,Addr\_A,t'\emph{A\}}\{K\_\{A,TGS1\}\}\$ + \item + \$TGS1:\{K\_\{A,TGS2\}, TGS2, t\_\{TGS1\}, + Ticket\_\{TGS2\}\}\emph{\{K}\{A,TGS1\}\}\$ mit + \$Ticket\_\{TGS2\}=\{K\_\{A,TGS2\}, A, Addr\_A, TGS2, t\_\{TGS1\}, + LifetimeTicket\_\{TGS2\}\}\emph{\{K}\{TGS1,TGS2\}\}\$ + \item + \$A\textbackslash rightarrow + TGS2:(S2,Ticket\_\{TGS2\},Authenticator\_\{A,TGS2\})\$ mit + \$Authenticator\_\{A,TGS2\}=\{A,Addr\_A,t''\emph{A\}}\{K\_\{A,TGS2\}\}\$ + \item + \$TGS2\textbackslash rightarrow + A:\{K\_\{A,S2\},S2,t\_\{TGS2\},Ticket\_\{S2\}\}\emph{\{K}\{A,TGS2\}\}\$ + with \$Ticket\_\{S2\}=\{K\_\{A,S2\},A,Addr\_A,S2,t\_\{TGS2\}, + LifetimeTicket\_\{S2\}\}\emph{\{K}\{TGS2,S2\}\}\$ + \item + S2:(Ticket\_\{S2\}, Authentifikator\_\{A,S2\})\$ mit + \$Authentifikator\_\{A,S2\}=\{A,Addr\_A,t'''\emph{A\}}\{K\_\{A,S2\}\}\$ + \item + \$S2\textbackslash rightarrow + A:\{t'\,'\,'\emph{A+1\}}\{K\_\{A,S2\}\}\$ + \end{enumerate} + \end{itemize} + + + \subsubsection{Kerberos Version 5} + + \begin{itemize} + \item + Letzter Standard von 2005 (RFC 4120) + \item + Entwickelt als Reaktion auf Schwachstellen, die bei Kerberos v4 + bekannt wurden + + \begin{itemize} + \item + Enthält explizite Prüfsummen, um zu verifizieren, dass die + Nachrichten nicht verändert wurden + \item + Unterstützt mehrere Chiffren (andere als das unsichere DES) + \end{itemize} + \item + Einheitliches Nachrichtenformat - Nachrichten an den + Authentifizierungsserver und den Ticketvergabeserver sind sehr ähnlich + \item + Flexible ASN.1-Kodierung der Nachrichten, ermöglicht spätere + Erweiterungen + \item + Im Folgenden wird nur eine vereinfachte Version gezeigt, weit mehr + Funktionen sind standardisiert, z.B: + + \begin{itemize} + \item + Client-zu-Client gegenseitige Authentifizierung + \item + Vorauthentifizierte Tickets + \item + Erneuerung von Tickets + \item + Multidomain Kerberos + \end{itemize} + \item + Der Authentifizierungsdialog in Kerberos Version 5 ist ähnlich wie in + Version 4 + \item + Der Austausch des Authentifizierungsdienstes: Bei der ersten + Kontaktaufnahme sendet der Client A nicht nur Namen und Zeitstempel, + sondern auch eine Nonce n , die hilft, Wiederholungen zu vermeiden, + wenn sich die Zeit geändert hat; es ist auch möglich, mehrere Adressen + anzugeben + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$A\textbackslash rightarrow + AS:(A,TGS,t\_\{start\},t\_\{end\},n,Addr\_A, ...)\$ + \end{enumerate} + \item + Die Antwort enthält ein Klartext-Ticket und verschlüsselte + Informationen: 2. \$AS\textbackslash rightarrow A: + (A,Ticket\_\{TGS\},\{K\_\{A,TGS\}, + LastRequest,n,t\_\{expire\},t\_\{AS\},t\_\{start\},t\_\{end\},t\_\{renew\},TGS, + Addr\_A\}\emph{\{K\_A\})\$ mit \$Ticket}\{TGS\}=(TGS, + \{K\_\{A,TGS\},A,transited, t\_\{AS\}, + t\_\{start\},t\_\{end\},t\_\{renew\},Addr\_A,restrictions\}\emph{\{K}\{AS,TGS\}\})\$ + + \begin{itemize} + \item + LastRequest gibt den letzten Login des Benutzers an transited + enthält die Vertrauenskette Multidomain Kerberos Restriktionen für + den Benutzer können dem TGS und den Servern übergeben werden + \$t\_\{expire\}\$ und \$t\_\{end\}\$ enthalten verschiedene Zeiten, + um die Erneuerung von Tickets zu ermöglichen (wobei die Start- und + Endzeit einfach aktualisiert werden können) + \end{itemize} + \item + Der Dialog zum TGS ist mit dem Ausgangsdialog harmonisiert: Er enthält + zusätzlich Tickets und einen Authentifikator, der beweist, dass A + \$K\_\{A,TGS\}\$ kennt 3. \$Aufrechtes + TGS:(A,S1,t\_\{start\},t\_\{end\},n',Addr\_A,Authenticator\_\{A,TGS\}, + Tickets,...)\$ mit \$Authenticator\_\{A,TGS\}=\{A, CheckSum, + t\_\{A'\}, K\_\{A,TGS'\}, Seq\#,...\}\emph{\{K}\{A,TGS\}\}\$ Hinweis: + Der Authentifikator enthält jetzt eine kryptographische Prüfsumme! + \item + Die Antwort an A ist völlig analog zu Nachricht 2: 4. + \$TGS\textbackslash rightarrow + A:(A,Ticket\_\{S1\},\{K\_\{A,S1\},LastRequest, + n',t\_\{expire\},t\_\{TGS\},t\_\{start\},t\_\{end\},t\_\{renew\},S1,Addr\_A\}\emph{\{K}\{A,TGS\}\})\$ + \item + Der Austausch mit dem Server ist ebenfalls ähnlich wie bei Version 4, + aber mit dem Authentifikator ist eine explizite Prüfsumme möglich: 5. + \$A\textbackslash rightarrow S1:(Ticket\_\{S1\}, + Authenticator\_\{A,S1\})\$ mit + \$Authenticator\_\{A,S1\}=\{A,CheckSum,t\_\{A''\},K\_\{A,S1\}', Seq\#, + ...\}\emph{\{K}\{A,S1\}\}\$ + \item + Nach Erhalt entschlüsselt S1 das Ticket mit dem Schlüssel + \$K\_\{TGS,S1\}\$, den er mit TGS teilt, und erhält den + Sitzungsschlüssel \$K\_\{A,S1\}\$ für die sichere Kommunikation mit A. + Mit diesem Schlüssel überprüft er den Authentifikator und antwortet A: + 6. \$S1\textbackslash rightarrow + A:\{t\_\{S1\},K\_\{A,S1\}',Seq\#,...\}\emph{\{K}\{A,S1\}\}\$ + \item + Alles in allem behebt der Dialog mehrere potenzielle Schwachstellen, + während andere bestehen bleiben: + + \begin{itemize} + \item + Sequenznummern und Nonces ermöglichen eine zusätzliche + Replay-Prüfung, wenn sich die Zeitbasis ändert + \item + Explizite Prüfsummen verhindern die Änderung von Daten innerhalb von + Tickets + \item + Zentrale Server sind immer noch potentielle Single-Points-of-Failure + \item + Für den ersten Austausch ist immer noch eine gewisse + Zeitsynchronisierung erforderlich. + \end{itemize} + \end{itemize} + + + \subsection{Fortgeschrittene Methoden zur + Passwortauthentifizierung} + + \begin{itemize} + \item + Alle gezeigten Protokolle haben eine gemeinsame Schwäche: + + \begin{itemize} + \item + Passwörter müssen leicht zu merken und leicht einzugeben sein + \$\textbackslash rightarrow\$ Geringe Entropie + \item + Angreifer können schnell alle möglichen Kombinationen ausprobieren + \item + Offline, über Grafikkarten, Cloud-Computer, spezielle Hardware... + \item + Asymmetrische Situation + \end{itemize} + \item + Mögliche Lösungen: + + \begin{itemize} + \item + Schlüsselableitungsfunktionen + + \begin{itemize} + \item + Erschweren Brute-Force-Angriffe durch extrem häufiges Hashing + \item + Erfordert auch Aufwand durch legitime Geräte + \item + Nur linearer Sicherheitsgewinn + \item + Bessere Funktionen verbrauchen viel Speicher, um Angriffe mit + Grafikkarten und spezieller Hardware undurchführbar zu machen + \end{itemize} + \item + Passwort-authentifizierter Schlüsselaustausch (PAKE) + \end{itemize} + \item + Passwortauthentifizierter Schlüsselaustausch (PAKE) - Grundlegende + Idee + + \begin{itemize} + \item + Durchführen eines Schlüsselaustauschs mit asymmetrischer + Kryptographie + \item + Authentifizierung von Peers mit einem Passwort unter Verwendung + eines Zero Knowledge Proofs + \item + Die Peers können nur feststellen, ob die Passwörter übereinstimmen + oder nicht + \item + Keine weiteren Informationen, um effiziente Bruteforce-Suchen + durchzuführen + + \begin{itemize} + \item + Würde das Lösen schwieriger Probleme erfordern, z. B. eine Art + DH-Problem + \item + Macht Offline-Angriffe undurchführbar + \end{itemize} + \item + Online-Angriffe möglich, können aber entdeckt werden + \end{itemize} + \end{itemize} + + + \subsection{PAKE-Schemata: EKE} + + \begin{itemize} + \item + Ein einfaches erstes Protokoll ist Encrypted Key Exchange (EKE) + {[}BM92{]} + \item + Der Dialog beginnt damit, dass A ein privates/öffentliches + Schlüsselpaar zur einmaligen Verwendung erzeugt und den öffentlichen + Schlüssel \$+K\_\{ar\}\$ verschlüsselt mit dem Passwort \$K\_\{A,B\}\$ + an B sendet + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$A\textbackslash rightarrow B:A,\{+K\_\{ar\}\}\emph{\{K}\{A,B\}\}\$ + \end{enumerate} + \item + B wählt einen symmetrischen Sitzungsschlüssel \$K\_r\$ und sendet ihn + verschlüsselt mit dem öffentlichen Schlüssel und dem Passwort zurück + an A + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$B\textbackslash rightarrow + A:\{\{K\_r\}\emph{\{+K}\{ar\}\}\}\emph{\{K}\{A,B\}\}\$ + \end{enumerate} + \item + A und B teilen sich nun einen gemeinsamen Sitzungsschlüssel und + beweisen ihr Wissen darüber durch den Austausch von Nonces + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$A\textbackslash rightarrow B:\{r\_A\}\_\{K\_r\}\$ + \item + \$B\textbackslash rightarrow A:\{r\_A,r\_B\}\_\{K\_r\}\$ + \item + \$A\textbackslash rightarrow B:\{r\_B\}\_\{K\_r\}\$ + \end{enumerate} + \item + Nach diesem Schritt ist sichergestellt, dass beide \$K\_\{A,B\}\$ + gekannt haben müssen und es keinen Man-in-the-Middle-Angriff gegeben + hat + \end{itemize} + + + \subsubsection{Sicherheitsdiskussion} + + \begin{itemize} + \item + Resistenz gegen Offline-Angriffe hängt davon ab, dass \$+K\_\{ar\}\$ + nicht von Zufallszahlen zu unterscheiden ist + + \begin{itemize} + \item + Was bedeutet das für ECC? + \item + Für RSA schlagen die Autoren vor, e zu verschlüsseln und n im + Klartext zu senden + + \begin{itemize} + \item + n hat keine kleinen Primfaktoren und ist daher von Zufallszahlen + unterscheidbar + \item + Immer noch unsicher gegen Man-in-the-Middle-Angriffe, da Angreifer + n mit besonderen Eigenschaften wählen können (z.B. \$p-1\$ und + \$q-1\$ teilbar durch 3) + \item + Antwort von B ist von Zufallszahlen unterscheidbar + \item + Details sind in {[}Par97{]} oder {[}SR14{]} zu finden. + \end{itemize} + \end{itemize} + \item + Bietet keine perfekte Vorwärtsverschwiegenheit... + \item + Aber es gibt ein anderes Protokoll von den Autoren namens DH-EKE + \end{itemize} + + + \subsubsection{DH-EKE} + + \begin{itemize} + \item + DH-EKE ist im Grunde ein DH-Austausch mit cleverer Authentifizierung + \item + A sendet DH-Austausch verschlüsselt mit dem Passwort \$K\_\{A,B\}\$ + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$A\textbackslash rightarrow B:\{g\^{}\{ra\}\textbackslash{} + mod\textbackslash{} p\}\emph{\{K}\{A,B\}\}\$ + \end{enumerate} + \item + B antwortet mit seinem Teil des DH-Austauschs (verschlüsselt mit dem + Passwort \$K\_\{A,B\}\$) und verwendet den Sitzungsschlüssel + \$K\_S=g\^{}\{ra*rb\}\textbackslash{} mod\textbackslash{} p\$, um eine + verschlüsselte Nonce \$c\_b\$ zu senden 2. + \$B\textbackslash rightarrow A:\{g\^{}\{rb\}\textbackslash{} + mod\textbackslash{} p\}\emph{\{K}\{A,B\}\}\{c\_b\}\_\{K\_s\}\$ + \item + Beide Parteien beweisen ihre Kenntnis von \$K\_S\$ 3. + \$A\textbackslash rightarrow + B:\{c\_a\textbar\textbar c\_b\}\emph{\{K\_s\} 4. + \$B\textbackslash rightarrow A:\{c\_a\}}\{K\_s\}\$ + \end{itemize} + + + \subsubsection{Sicherheitsdiskussion 2} + + \begin{itemize} + \item + Wiederum müssen verschlüsselte Daten von Zufallsdaten ununterscheidbar + sein + + \begin{itemize} + \item + Der Wert p muss klug gewählt werden, d.h. \$p-1\$ muss nahe bei + \$2\^{}\{8*n\}\$ für ausreichend große natürliche Zahlen n liegen + \item + Um Angriffe auf kleine Gruppen leicht zu verhindern, sollte + \$(p-1)/2\$ ebenfalls eine Primzahl sein. + \item + ECC ist immer noch schwierig zu realisieren + \end{itemize} + \item + Bietet perfektes Vorwärtsgeheimnis + \item + Alles in allem ein nettes Verfahren, das jedoch patentiert werden + musste + + \begin{itemize} + \item + Keine breite Anpassung + \item + Führte zur Entwicklung zahlreicher anderer Verfahren + \end{itemize} + \end{itemize} + + + \subsubsection{SRP} + + \begin{itemize} + \item + Das heute am weitesten verbreitete Protokoll: Sicheres Fernkennwort + (SRP) + \item + Mehrere Versionen: Hier SRP-6a {[}Wu02{]} + \item + Initialisierung: + + \begin{itemize} + \item + Server B wählt eine Zufallszahl \$s\_\{A,B\}\$ + \item + berechnet \$x=H(s\_\{A,B\} \textbar\textbar{} Benutzername + \textbar\textbar{} Passwort)\$ und \$v=g\^{}x\textbackslash{} + mod\textbackslash{} p\$ + \item + Benutzer werden durch \$(Benutzername, s\_\{A,B\}, v)\$ + authentifiziert + \item + Der Server braucht das Passwort nicht zu speichern + \$\textbackslash rightarrow\$ kann nicht leicht erlangt werden, wenn + der Server kompromittiert wird! + \item + Server kann diese Werte auch nicht verwenden, um sich als Benutzer + auf anderen Servern auszugeben + \item + Die Eigenschaft wird als erweitertes PAKE-Schema bezeichnet + \end{itemize} + \end{itemize} + + + \subsubsection{SRP - Dialog} + + \begin{itemize} + \item + A initiiert die Verbindung durch Senden seines Benutzernamens + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$A\textbackslash rightarrow B: A\$ + \end{enumerate} + \item + B antwortet mit ausgewählten kryptographischen Parametern und einem + Verifizierer v, der durch einen DH-Austausch ,,geblendet'' ist 2. + \$B\textbackslash rightarrow A: p, g, s\_\{A,B\}, (H(g + \textbar\textbar{} p)*v + g\^{}\{rb\})\textbackslash{} + mod\textbackslash{} p\$ + \item + A berechnet den gemeinsamen Sitzungsschlüssel durch \$K\_S=(Y\_B-H(g + \textbar\textbar{} p)\emph{g\^{}x)\^{}\{ra+u}x\}\textbackslash{} + mod\textbackslash{} p\$, mit \$u=H(Y\_A\textbar\textbar Y\_B)\$, und + sendet seinen Teil des DH-Austauschs und eine Bestätigung zurück, dass + er \$K\_S\$ kennt 3. \$A\textbackslash rightarrow + B:g\^{}\{ra\}\textbackslash{} mod\textbackslash{} p, + H(Y\_A,Y\_B,K\_S)\$ + \item + B berechnet \$K\_S'=(Y\_A v\^{}u)\^{}\{rb\}\textbackslash{} + mod\textbackslash{} p\$ und beweist seine Kenntnis 4. + \$B\textbackslash rightarrow A:H(Y\_A, H(Y\_A,Y\_B,K\_S),K\_S')\$ + \item + \$K\_S'\$ und \$K\_S\$ stimmen überein, wenn es keinen + Man-in-the-Middle-Angriff gegeben hat + \end{itemize} + + + \subsubsection{SRP - Diskussion} + + \begin{itemize} + \item + Sicheres Schema + + \begin{itemize} + \item + Gegenseitige Authentifizierung zwischen Server und Client + \item + Erweiterung erhöht die Sicherheit in Client/Server-Szenarien + \item + Keine Unterstützung für ECC, da es Feldarithmetik erfordert + \end{itemize} + \item + Patentiert, aber frei zu verwenden + \item + Unterstützung für TLS, IPsec, ... + \end{itemize} + + + \subsection{X.509 - Einführung} + + \begin{itemize} + \item + X.509 ist eine internationale Empfehlung der ITU-T und gehört zur + X.500-Reihe, die Verzeichnisdienste definiert: + + \begin{itemize} + \item + Die erste Version von X.509 wurde 1988 standardisiert. + \item + Eine zweite Version, die 1993 standardisiert wurde, löste einige + Sicherheitsbedenken + \item + Eine dritte Version von X.509 wird derzeit von der IETF in RFC 4211 + gepflegt. + \end{itemize} + \item + X.509 definiert einen Rahmen für die Bereitstellung von + Authentifizierungsdiensten, der Folgendes umfasst: + + \begin{itemize} + \item + Zertifizierung von öffentlichen Schlüsseln und Handhabung von + Zertifikaten: + + \begin{itemize} + \item + Zertifikatsformat + \item + Zertifikats-Hierarchie + \item + Zertifikatswiderrufslisten + \end{itemize} + \item + Drei verschiedene Dialoge für die direkte Authentifizierung: + + \begin{itemize} + \item + Einseitige Authentifizierung, erfordert synchronisierte Uhren + \item + Gegenseitige Zwei-Wege-Authentifizierung, erfordert immer noch + synchronisierte Uhren + \item + Gegenseitige Drei-Wege-Authentifizierung, die vollständig auf + Zufallszahlen basiert + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsubsection{X.509 - Zertifikate mit öffentlichem + Schlüssel} + + % \includegraphics{Assets/NetworkSecurity-x509-certificates.png} + + \begin{itemize} + \item + Ein Public-Key-Zertifikat ist eine Art Reisepass, der bescheinigt, + dass ein öffentlicher Schlüssel zu einem bestimmten Namen gehört + \item + Zertifikate werden von Zertifizierungsstellen (CA) ausgestellt. + \item + Wenn alle Nutzer den öffentlichen Schlüssel der CA kennen, kann jeder + Nutzer jedes von dieser CA ausgestellte Zertifikat überprüfen. + \item + Zertifikate können die Online-Teilnahme eines TTP verhindern + \item + Die Sicherheit des privaten Schlüssels der CA ist entscheidend für die + Sicherheit aller Nutzer! + \item + Notation eines Zertifikats, das einen öffentlichen Schlüssel \$+K\_A\$ + an Benutzer A bindet, ausgestellt von der Zertifizierungsstelle CA + unter Verwendung ihres privaten Schlüssels \$-CK\_\{CA\}\$: + + \begin{itemize} + \item + \$Cert\_\{-CK\_\{CA\}\}(+K\_A) = CA{[}V, SN, AI, CA, T\_\{CA\}, A, + +K\_A{]}\$ mit: + + \begin{itemize} + \item + V = Versionsnummer + \item + SN = Seriennummer + \item + AI = Algorithmus-Bezeichner des verwendeten Signatur-Algorithmus + \item + CA = Name der Zertifizierungsstelle + \item + \$T\_\{CA\}\$ = Gültigkeitsdauer dieses Zertifikats + \item + A = Name, an den der öffentliche Schlüssel in diesem Zertifikat + gebunden ist + \item + \$+K\_A\$ = öffentlicher Schlüssel, der an einen Namen gebunden + wird + \end{itemize} + \item + Die Kurzschreibweise \$CA{[}m{]}\$ steht für + \$(m,\{H(m)\}\emph{\{-CK}\{CA\}\})\$ + \item + Eine andere Kurzschreibweise für \$Cert\_\{-CK\_\{CA\}\}(+K\_A)\$ + ist \$CA\textless{}\textgreater\$ + \end{itemize} + \end{itemize} + + + \subsubsection{X.509 - Zertifikatsketten \& + Zertifikatshierarchie} + + \begin{itemize} + \item + Betrachten wir nun zwei Benutzer Alice und Bob, die in verschiedenen + Ländern leben und sicher kommunizieren wollen: + + \begin{itemize} + \item + Die Wahrscheinlichkeit ist recht hoch, dass ihre öffentlichen + Schlüssel von verschiedenen CAs zertifiziert sind + \item + Nennen wir die Zertifizierungsstelle von Alice CA und die von Bob CB + \item + Wenn Alice CB nicht vertraut oder gar kennt, dann ist Bobs + Zertifikat \$CB\textless{}\textgreater\$ für sie nutzlos, dasselbe + gilt in der anderen Richtung + \end{itemize} + \item + Eine Lösung für dieses Problem ist die Konstruktion von + Zertifikatsketten: + + \begin{itemize} + \item + Stellen Sie sich einmal vor, dass CA und CB einander kennen und + einander vertrauen. + + \begin{itemize} + \item + Ein Beispiel aus der realen Welt für dieses Konzept ist das + gegenseitige Vertrauen zwischen Ländern hinsichtlich ihrer + Passausgabestellen + \end{itemize} + \item + Wenn CA den öffentlichen Schlüssel von CB mit einem Zertifikat + \$CA\textless{}\textgreater\$ und CB den öffentlichen Schlüssel von + CA mit einem Zertifikat \$CB\textless{}\textgreater\$ beglaubigt, + können A und B ihre Zertifikate anhand einer Zertifikatskette + überprüfen: + + \begin{itemize} + \item + Nachdem ihr \$CB\textless{}\textgreater\$ vorgelegt wurde, + versucht Alice herauszufinden, ob es ein Zertifikat + \$CA\textless{}\textgreater\$ gibt. + \item + Sie überprüft dann die Kette: \$CA\textless{}\textgreater, + CB\textless{}\textgreater\$ + \end{itemize} + \end{itemize} + \item + Zertifikatsketten müssen nicht auf eine Länge von zwei Zertifikaten + beschränkt sein: + + \begin{itemize} + \item + \$CA\textless{}\textgreater, CC\textless{}\textgreater, + CD\textless{}\textgreater, CE\textless{}\textgreater, + CG\textless{}\$ würde es Alice erlauben, das von CG ausgestellte + Zertifikat des Benutzers G zu überprüfen, auch wenn sie nur ihre + eigene Zertifizierungsstelle CA kennt und ihr vertraut. + \item + Tatsächlich wird das Vertrauen von A in den Schlüssel +KG durch eine + Vertrauenskette zwischen Zertifizierungsstellen hergestellt. + \item + Wenn Alice jedoch \$CG\textless{}\textgreater\$ vorgelegt wird, ist + es nicht offensichtlich, welche Zertifikate sie zur Überprüfung + benötigt + \end{itemize} + \item + X.509 schlägt daher vor, dass die Zertifizierungsstellen in einer + Zertifizierungshierarchie angeordnet werden, so dass die Navigation + einfach ist: + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-x509-hierarchy.png} + \end{itemize} + \item + Verbleibendes Problem: + + \begin{itemize} + \item + Zertifizierungspfade können ziemlich lang werden + \item + Die Kompromittierung eines einzigen Zwischenzertifikats reicht aus, + um die Sicherheit zu brechen + \end{itemize} + \item + Führt zu zwei Entwicklungen + + \begin{itemize} + \item + Kreuzzertifizierung: + + \begin{itemize} + \item + Ermöglicht das Signieren von Stammzertifikaten untereinander + \item + Erlaubt aber auch ,,Abkürzungen'' im Zertifikatswald + \item + Macht die Navigation komplexer, aber potenziell mehrwegfähig + \end{itemize} + \item + Anheften von Zertifikaten: + + \begin{itemize} + \item + Ermöglicht Anwendungen, z. B. Webbrowsern, zu lernen, dass Peers + nur Zertifikate von einer bestimmten CA verwenden + \item + Wird z. B. von Google Chrome verwendet, nachdem + Man-in-the-Middle-Angriffe auf google.com bekannt wurden + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsubsection{X.509 - + Zertifikatssperrung} + + \begin{itemize} + \item + Nehmen wir nun an, dass der private Schlüssel von Alice kompromittiert + wurde, z.B. weil Eve in ihren Computer eingebrochen ist, ihren + privaten Schlüssel aus einer Datei gelesen und das Passwort geknackt + hat, das sie zum Schutz des privaten Schlüssels verwendet hat: + + \begin{itemize} + \item + Wenn Alice feststellt, dass ihr privater Schlüssel kompromittiert + wurde, möchte sie unbedingt den Widerruf des entsprechenden + Zertifikats für den öffentlichen Schlüssel beantragen. + \item + Wenn das Zertifikat nicht widerrufen wird, könnte sich Eve bis zum + Ende der Gültigkeitsdauer des Zertifikats weiterhin als Alice + ausgeben. + \end{itemize} + \item + Eine noch schlimmere Situation tritt ein, wenn der private Schlüssel + einer Zertifizierungsstelle kompromittiert wird: + + \begin{itemize} + \item + Dies bedeutet, dass alle mit diesem Schlüssel signierten Zertifikate + widerrufen werden müssen! + \end{itemize} + \item + Der Widerruf von Zertifikaten wird durch das Führen von + Zertifikatswiderrufslisten (CRL) realisiert: + + \begin{itemize} + \item + CRLs werden im X.500-Verzeichnis gespeichert, oder Erweiterungen + können auf eine URL verweisen + \item + Bei der Überprüfung eines Zertifikats muss auch geprüft werden, ob + das Zertifikat noch nicht widerrufen wurde (Suche nach dem + Zertifikat in der CRL) + \item + Der Widerruf von Zertifikaten ist ein relativ langsamer und teurer + Vorgang + \end{itemize} + \end{itemize} + + + \subsubsection{X.509 - + Authentifizierungsprotokolle} + + \begin{itemize} + \item + Einweg-Authentifizierung: + + \begin{itemize} + \item + Wenn nur Alice sich gegenüber Bob authentifizieren will, sendet sie + folgende Nachricht an Bob: + \end{itemize} + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$(A{[}t\_A, r\_A, B, sgnData\_A, \{K\_\{A,B\}\}\emph{\{+KB\}{]}, + CA\textless{}\textgreater)\$, wobei \$sgnData\_A\$ optionale Daten + darstellt, die von \$A signiert werden sollen, + \{K}\{A,B\}\}\_\{+K\_B\}\$ ein optionaler Sitzungsschlüssel ist, der + mit Bobs öffentlichem Schlüssel verschlüsselt wird, und + \$CA\textless{}\textgreater\$ ebenfalls optional ist + \end{enumerate} + + \begin{itemize} + \item + Beim Empfang dieser Nachricht verifiziert Bob mit \$+K\_\{CA\}\$ das + enthaltene Zertifikat, extrahiert Alices öffentlichen Schlüssel, + überprüft Alices Signatur der Nachricht und die Aktualität der + Nachricht \$(t\_A)\$ und entschlüsselt optional den enthaltenen + Sitzungsschlüssel \$K\_\{A,B\}\$, den Alice vorgeschlagen hat + \end{itemize} + \item + Zwei-Wege-Authentifizierung: + + \begin{itemize} + \item + Wenn eine gegenseitige Authentifizierung erwünscht ist, dann + erstellt Bob eine ähnliche Nachricht: + \end{itemize} + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \setcounter{enumi}{1} + \item + \$(B{[}t\_B, r\_B, A, r\_A, sgnData\_B,\{K\_\{B,A\}\}\_\{+K\_A\}{]}, + CA\textless{}\textgreater)\$ der enthaltene Zeitstempel \$t\_B\$ ist + nicht wirklich erforderlich, da Alice überprüfen kann, ob die + signierte Nachricht die Zufallszahl \$r\_A\$ enthält + \end{enumerate} + \item + Drei-Wege-Authentifizierung: + + \begin{itemize} + \item + Wenn Alice und Bob nicht sicher sind, ob sie synchrone Uhren haben, + sendet Alice die folgende Nachricht an Bob: + \end{itemize} + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \setcounter{enumi}{2} + \item + \$A{[}r\_B{]}\$ + \end{enumerate} + + \begin{itemize} + \item + Die Rechtzeitigkeit der Teilnahme von Alice am + Authentifizierungsdialog wird also durch die Unterzeichnung der + ,,frischen'' Zufallszahl \$r\_B\$ nachgewiesen. + \end{itemize} + \item + Anmerkung zum Signaturalgorithmus: + + \begin{itemize} + \item + Wie aus der Verwendung von Zertifikaten ersichtlich, schlägt X.509 + vor, die Authentifizierungsnachrichten mit asymmetrischer + Kryptographie zu signieren. + \item + Das Authentifizierungsprotokoll selbst kann jedoch auch mit + symmetrischer Kryptographie eingesetzt werden: + + \begin{itemize} + \item + In diesem Fall müssen sich A und B vor jedem Protokolldurchlauf + auf einen geheimen Authentifizierungsschlüssel \$AK\_\{A,B\}\$ + geeinigt haben, und + \item + die Nachrichten werden durch Anhängen eines mit diesem Schlüssel + berechneten MAC signiert. + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Formale Validierung von kryptographischen + Protokollen} + + \begin{itemize} + \item + Wie wir am Beispiel des Needham-Schroeder-Protokolls gesehen haben, + ist die Sicherheit eines kryptografischen Protokolls nicht einfach zu + beurteilen: + + \begin{itemize} + \item + Es gibt viele weitere Beispiele für Protokollfehler in + kryptografischen Protokollen, die manchmal erst Jahre nach der + Veröffentlichung des Protokolls entdeckt wurden + + \begin{itemize} + \item + Eine frühe Version des X.509-Standards enthielt einen Fehler, der + dem Fehler im Needham-Schroeder-Protokoll ähnlich war. + \end{itemize} + \item + Daraus ergibt sich der Bedarf an formalen Methoden zur Analyse der + Eigenschaften von kryptographischen Protokollen + \end{itemize} + \item + Kategorien von formalen Validierungsmethoden für kryptografische + Protokolle: + + \begin{itemize} + \item + Allgemeine Ansätze zur Analyse spezifischer Protokolleigenschaften: + + \begin{itemize} + \item + Beispiele: Finite-State-Machine-basierte Ansätze, Prädikatenkalkül + erster Ordnung, Allzweck-Spezifikationssprachen + \item + Hauptnachteil: Sicherheit unterscheidet sich wesentlich von + Korrektheit, da für letztere keine böswillige Manipulation + angenommen werden muss + \end{itemize} + \end{itemize} + \item + Kategorien von formalen Validierungsmethoden für kryptographische + Protokolle: + + \begin{itemize} + \item + Expertensystembasierte Ansätze: + + \begin{itemize} + \item + Das Wissen menschlicher Experten wird in deduktive Regeln + formalisiert, die von einem Protokolldesigner zur Untersuchung + verschiedener Szenarien verwendet werden können. + \item + Hauptnachteil: nicht gut geeignet, um Schwachstellen in + kryptografischen Protokollen zu finden, die auf unbekannten + Angriffstechniken beruhen + \end{itemize} + \item + Algebraische Ansätze: + + \begin{itemize} + \item + Kryptografische Protokolle werden als algebraische Systeme + spezifiziert + \item + Die Analyse wird durchgeführt, indem algebraische + Termumschreibungseigenschaften des Modells untersucht werden und + geprüft wird, ob das Modell bestimmte erwünschte oder unerwünschte + Zustände erreichen kann + \end{itemize} + \item + Spezifische logikbasierte Ansätze: + + \begin{itemize} + \item + Ansätze dieser Klasse definieren einen Satz von Prädikaten und + eine Abbildung der während eines Protokolllaufs ausgetauschten + Nachrichten auf einen Satz von Formeln + \item + Ein generischer Satz von Regeln erlaubt es dann, das Wissen und + den Glauben zu analysieren, der von den Peer-Entitäten eines + kryptographischen Protokolls während eines Protokolllaufs erlangt + wird (recht erfolgreicher Ansatz: GNY-Logik {[}GNY90a{]}) + \end{itemize} + \end{itemize} + \end{itemize} + + + \section{Sichere + Gruppenkommunikation} + + + \section{Zugriffskontrolle} + + + \subsection{Was ist Zugangskontrolle?} + + \begin{itemize} + \item + Definition: Die Zugriffskontrolle umfasst die Mechanismen, die die + Vermittlung von Subjektanfragen für den Zugriff auf Objekte, wie sie + in einer bestimmten Sicherheitspolitik definiert sind, erzwingen. + \item + Ein wichtiges konzeptuelles Modell in diesem Zusammenhang ist der + Referenzmonitor: + \item + % \includegraphics{Assets/NetworkSecurity-reference-monitor.png} + \end{itemize} + + + \subsection{Sicherheitspolitik} + + \begin{itemize} + \item + Um Entscheidungen über die Zugriffskontrolle treffen zu können, muss + der Referenzmonitor die Sicherheitspolitik des Systems kennen + \item + Definition: Die Sicherheitspolitik eines Systems definiert die + Bedingungen, unter denen Subjektzugriffe auf Objekte durch die + Funktionalität des Systemreferenzmonitors vermittelt werden + \item + Bemerkungen: + + \begin{itemize} + \item + Die obige Definition wird gewöhnlich im Zusammenhang mit der + Sicherheit von Computern und Betriebssystemen gegeben. + \item + Der Referenzmonitor ist nur eine konzeptionelle Einheit, er muss + nicht unbedingt ein physisches oder logisches Gegenstück in einem + bestimmten System haben. + \item + Der Begriff Sicherheitspolitik wird oft auch in einem weiteren Sinne + verwendet, um eine Spezifikation aller Sicherheitsaspekte eines + Systems einschließlich Bedrohungen, Risiken, Sicherheitsziele, + Gegenmaßnahmen usw. zu beschreiben. + \end{itemize} + \end{itemize} + + + \subsection{Klassische Computersubjekte, Objekte und + Zugriffsarten} + + \begin{itemize} + \item + Definition: Ein Subjekt ist eine aktive Entität, die eine Anfrage nach + Ressourcen initiieren und diese Ressourcen nutzen kann, um eine + Aufgabe zu erfüllen. + \item + Definition: Ein Objekt ist ein passives Repository, das zur + Speicherung von Informationen dient + \item + Die beiden obigen Definitionen stammen aus der klassischen + Computerwissenschaft: + + \begin{itemize} + \item + Subjekte sind Prozesse, und Dateien, Verzeichnisse usw. sind + Objekte. + \end{itemize} + \item + Es ist jedoch nicht immer offensichtlich, Subjekte und Objekte im + Zusammenhang mit der Kommunikation zu identifizieren: + + \begin{itemize} + \item + Stellen Sie sich vor, eine Einheit sendet eine Nachricht an eine + andere Einheit: Ist die empfangende Einheit als Objekt zu + betrachten? + \end{itemize} + \item + Außerdem müssen wir wissen, was ein Zugriff ist und welche Arten von + Zugriffen es gibt: + + \begin{itemize} + \item + Beispiele aus der klassischen Informatik für Zugriffsarten: Lesen, + Schreiben, Ausführen + \item + Objektorientierte Sichtweise: Jede Methode eines Objekts definiert + eine Art des Zugriffs + \end{itemize} + \end{itemize} + + + \subsection{Sicherheitskennzeichen} + + \begin{itemize} + \item + Definition: Eine Sicherheitsstufe wird als hierarchisches Attribut zu + Entitäten eines Systems definiert, um deren Sensibilitätsgrad zu + kennzeichnen + + \begin{itemize} + \item + Beispiele: + + \begin{itemize} + \item + Militär: unklassifiziert \textless{} vertraulich \textless{} + geheim \textless{} streng geheim + \item + Kommerziell: öffentlich \textless{} sensibel \textless{} + proprietär \textless{} eingeschränkt + \end{itemize} + \end{itemize} + \item + Definition: Eine Sicherheitskategorie ist definiert als eine + nicht-hierarchische Gruppierung von Entitäten, um den Grad ihrer + Sensibilität zu kennzeichnen. + + \begin{itemize} + \item + Beispiel (Wirtschaft): Abteilung A, Abteilung B, Verwaltung usw. + \end{itemize} + \item + Definition: Eine Sicherheitskennzeichnung ist definiert als ein + Attribut, das mit Systemeinheiten verbunden ist, um deren + hierarchische Sensibilitätsstufe und Sicherheitskategorien zu + kennzeichnen. + + \begin{itemize} + \item + In Form von mathematischen Mengen: \$Labels = Levels + \textbackslash times Powerset(Categories)\$ + \end{itemize} + \item + Sicherheitslabels, die die Sicherheitsempfindlichkeit von: + + \begin{itemize} + \item + Subjekte werden Freigaben genannt + \item + Objekte werden Klassifizierungen genannt + \end{itemize} + \item + Ein wichtiges Konzept für die Spezifikation von Sicherheitspolitiken + sind binäre Relationen auf der Menge der Kennzeichnungen: + + \begin{itemize} + \item + Eine binäre Relation auf einer Menge S ist eine Teilmenge des + Kreuzprodukts \$S\textbackslash times S\$ + \item + Beispiel: + + \begin{itemize} + \item + Dominiert: \$Labels \textbackslash times Labels\$ + \item + Dominiert \$=\{(b1,b2) \textbar{} b1, b2 \textbackslash in Labels + \textbackslash wedge level(b1) \textbackslash geq level(b2) + \textbackslash wedge categories(b2) \textbackslash subseteq + categories(b1)\}\$ + \item + Wenn \$(b1, b2) \textbackslash in Dominates\$, schreiben wir auch + b1 dominates b + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Spezifikation der + Sicherheitspolitik} + + \begin{itemize} + \item + Formale Ausdrücke für Regeln der Sicherheitspolitik: + \item + Betrachten Sie die folgenden Zuordnungen: + + \begin{itemize} + \item + \$allow: Subjects \textbackslash times Accesses \textbackslash times + Objects \textbackslash rightarrow boolean\$ + \item + \$own: Subjects \textbackslash times Objects + \textbackslash rightarrow boolean\$ + \item + \$admin: Subjects \textbackslash rightarrow boolean\$ + \item + \$dominates: Labels \textbackslash times Labels + \textbackslash rightarrow boolean\$ + \end{itemize} + \item + Die oben genannten Zuordnungen können verwendet werden, um bekannte + Sicherheitsrichtlinien zu spezifizieren: + + \begin{itemize} + \item + \$ownership: \textbackslash forall s \textbackslash in Subjects, o + \textbackslash in Objects, a \textbackslash in Accesses: allow(s, o, + a) \textbackslash Leftrightarrow own(s, o)\$ + \item + \$own\_admin: \textbackslash forall s \textbackslash in Subjects, o + \textbackslash in Objects, a \textbackslash in Accesses: allow(s, o, + a) \textbackslash Leftrightarrow own(s, o) \textbackslash wedge + admin(s)\$ + \item + \$dom: \textbackslash forall s \textbackslash in Subjects, o + \textbackslash in Objects, a \textbackslash in Accesses: allow(s, o, + a) \textbackslash Leftrightarrow dominates(label(s), label(o))\$ + \end{itemize} + \item + Die dom-Policy erfordert ein System zur Speicherung und Verarbeitung + von Sicherheitskennzeichnungen für jede Entität, erlaubt aber + komplexere Zugriffskontrollschemata als die ownership- und + own\_admin-Policy + \end{itemize} + + + \subsection{Arten von + Zugriffskontrollmechanismen} + + \begin{itemize} + \item + Ein Zugriffskontrollmechanismus ist eine konkrete Umsetzung des + Referenzmonitor-Konzepts + \item + Es gibt zwei Haupttypen von Zugriffskontrollmechanismen: + + \begin{itemize} + \item + Diskretionäre Zugriffskontrolle umfasst diejenigen Verfahren und + Mechanismen, die die spezifizierte Vermittlung nach dem Ermessen der + einzelnen Benutzer durchsetzen + + \begin{itemize} + \item + Beispiel: Das Unix-Betriebssystem ermöglicht es den Benutzern, die + Zugriffsrechte für Dateien, die ihnen gehören, zu erteilen oder zu + entziehen (Lesen, Schreiben, Ausführen). + \end{itemize} + \item + Die obligatorische Zugriffskontrolle umfasst die Verfahren und + Mechanismen, die die angegebene Vermittlung nach dem Ermessen einer + zentralen Systemverwaltung durchsetzen. + \end{itemize} + \item + Beide Arten können kombiniert werden, wobei die obligatorischen + Zugriffskontrollentscheidungen in den meisten Fällen Vorrang vor den + diskretionären Entscheidungen haben + + \begin{itemize} + \item + Beispiel: + + \begin{itemize} + \item + Verwendung einer diskretionären Zugangskontrolle auf + Personalcomputern kombiniert mit einer obligatorischen + Zugangskontrolle für die Kommunikation + (\$\textbackslash rightarrow\$ Firewalls) + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Zugriffsmatrizen} + + \begin{itemize} + \item + Ein nützliches Konzept für die Beschreibung von + Zugangskontrollmechanismen ist die Zugangsmatrix: + + \begin{itemize} + \item + In einer Zugriffsmatrix für zwei Mengen von Subjekten und Objekten + entspricht jede Zeile einem Subjekt und jede Spalte einem Objekt + \item + Jede Zelle der Matrix definiert die Zugriffsrechte des + entsprechenden Subjekts auf das entsprechende Objekt + \end{itemize} + \end{itemize} + + %\begin{longtable}[]{@{}lllll@{}} + % \toprule + % & Object 1 & Object 2 & ... & Object M\tabularnewline + % \midrule + % \endhead + % Subject 1 & & & ... & \tabularnewline + % Subject 2 & & & ... & \tabularnewline + % ... & ... & ... & (Access Rights) & \tabularnewline + % Subject N & & & & \tabularnewline + % \bottomrule + %\end{longtable} + + + \subsection{Gemeinsame + Zugriffskontrollschemata} + + \begin{itemize} + \item + Zugriffskontroll-Listen (ACL): + + \begin{itemize} + \item + ACLs sind die Grundlage für ein Zugriffskontrollschema, bei dem für + jedes Objekt eine Liste gültiger Subjekte gespeichert wird, die + Zugriff auf dieses Objekt haben könnten (möglicherweise zusammen mit + der Art des erlaubten Zugriffs). + \item + ACLs werden in der Regel bei der diskretionären Zugriffskontrolle + verwendet, da es zu viele ACLs gibt, als dass sie von einer + zentralen Verwaltungseinrichtung verwaltet werden könnten. + \end{itemize} + \item + Fähigkeiten: + + \begin{itemize} + \item + Capabilities sind gewissermaßen das Gegenkonzept zu ACLs, da bei + Capabilities jedes Subjekt eine Liste von Zugriffsrechten auf + Objekte besitzt + \item + Der Vorteil (und die Gefahr) von Capabilities ist, dass ein Subjekt + einige seiner Capabilities an andere Subjekte weitergeben kann + \end{itemize} + \item + Label-basierte Zugriffskontrolle: + + \begin{itemize} + \item + Wenn Sicherheitslabels mit den Entitäten eines Systems gespeichert + und verarbeitet werden, können sie zur Durchführung einer + label-basierten Zugriffskontrolle verwendet werden + \item + Dieses Verfahren wird in der Regel als obligatorischer + Zugriffskontrollmechanismus verwendet. + \end{itemize} + \item + \$\textbackslash rightarrow\$ Die Datenintegrität von + Zugriffskontrolldatenstrukturen ist entscheidend! + \end{itemize} + + + \section{Integration von Sicherheitsdiensten in + Kommunikationsarchitekturen} + + + \subsection{Motivation: Was ist wo zu + tun?} + + \begin{itemize} + \item + Analog zur Methodik der Sicherheitsanalyse gibt es zwei Dimensionen, + die bei der Integration von Sicherheitsdiensten in + Kommunikationsarchitekturen zu beachten sind: + \item + Dimension 1: Welcher Sicherheitsdienst soll in welchem Knoten + realisiert werden? + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-Security-service-dim-1.png} + \end{itemize} + \item + Dimension 2: Welcher Sicherheitsdienst sollte in welcher Schicht + realisiert werden? + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-Security-service-dim-2.png} + \end{itemize} + \end{itemize} + + + \subsection{Ein pragmatisches Modell für sicheres und vernetztes + Rechnen} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-Sicheres-Netz-Modell.png} + \item + Anwendung: + + \begin{itemize} + \item + Ein Stück Software, das eine bestimmte Aufgabe erfüllt, z. B. + elektronische E-Mail, Webdienst, Textverarbeitung, Datenspeicherung + usw. + \end{itemize} + \item + Endsystem: + + \begin{itemize} + \item + Ein Gerät, das vom Personal Computer über den Server bis zum + Großrechner reicht. + \item + Für Sicherheitszwecke hat ein Endsystem in der Regel eine einzige + Richtlinienautorität. + \end{itemize} + \item + Teilnetz: + + \begin{itemize} + \item + Eine Sammlung von Kommunikationseinrichtungen, die unter der + Kontrolle einer Verwaltungsorganisation stehen, z. B. ein LAN, ein + Campusnetz, ein WAN usw. + \item + Für Sicherheitszwecke hat ein Teilnetz in der Regel eine + Richtlinienkompetenz. + \end{itemize} + \item + Internet: + + \begin{itemize} + \item + Eine Sammlung von miteinander verbundenen Teilnetzen + \item + Im Allgemeinen haben die Teilnetze, die in einem Inter-Netzwerk + verbunden sind, unterschiedliche Richtlinienautoritäten + \end{itemize} + \item + Es gibt vier Ebenen, auf denen unterschiedliche Anforderungen an + Sicherheitsprotokollelemente gestellt werden: + + \begin{itemize} + \item + Anwendungsebene: + + \begin{itemize} + \item + Sicherheitsprotokollelemente, die anwendungsabhängig sind + \end{itemize} + \item + Endsystem-Ebene: + + \begin{itemize} + \item + Bereitstellung von Schutz auf einer Endsystem-zu-Endsystem-Basis + \end{itemize} + \item + Teilnetzebene: + + \begin{itemize} + \item + Bereitstellung von Schutz über ein Teilnetz oder ein Zwischennetz, + das als weniger sicher gilt als andere Teile der Netzumgebung + \end{itemize} + \item + Verbindungsebene: + + \begin{itemize} + \item + Bereitstellung von Schutz innerhalb eines Teilnetzes, z. B. über + eine Verbindung, die als weniger vertrauenswürdig gilt als andere + Teile der Teilnetzumgebung + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Beziehungen zwischen Schichten und + Anforderungsniveaus} + + \begin{itemize} + \item + Die Beziehungen zwischen den Protokollschichten und den Stufen der + Sicherheitsanforderungen für die Protokollelemente sind nicht + eins-zu-eins: + + \begin{itemize} + \item + Sicherheitsmechanismen, die sowohl die Anforderungen der Endsystem- + als auch der Teilnetzebene erfüllen, können entweder in der + Transport- und/oder in der Netzwerkschicht realisiert werden. + \item + Die Anforderungen der Verbindungsebene können durch die Integration + von Sicherheitsmechanismen oder durch die Verwendung von + ,,speziellen Funktionen'' der Verbindungsschicht und/oder der + physikalischen Schicht erfüllt werden. + \item + % \includegraphics{Assets/NetworkSecurity-Layer-relationship.png} + \end{itemize} + \end{itemize} + + + \subsection{Allgemeine Überlegungen zur architektonischen + Platzierung} + + \begin{itemize} + \item + Verkehrsvermischung: + + \begin{itemize} + \item + Infolge des Multiplexing besteht auf niedrigeren Ebenen eine größere + Tendenz, Datenelemente von verschiedenen Quell-/Ziel-Benutzern + und/oder Anwendungen in einem Datenstrom zu vermischen + \item + Ein Sicherheitsdienst, der auf einer Schicht/Ebene realisiert wird, + behandelt den Verkehr dieser Schicht/Ebene gleich, was zu einer + unzureichenden Kontrolle der Sicherheitsmechanismen für Benutzer und + Anwendungen führt. + \item + Wenn eine Sicherheitspolitik eine differenziertere Behandlung + erfordert, sollte sie besser auf einer höheren Ebene realisiert + werden + \end{itemize} + \item + Wissen über die Route: + + \begin{itemize} + \item + Auf niedrigeren Ebenen ist in der Regel mehr Wissen über die + Sicherheitseigenschaften der verschiedenen Routen und Verbindungen + vorhanden. + \item + In Umgebungen, in denen diese Merkmale stark variieren, kann die + Platzierung von Sicherheit auf niedrigeren Ebenen Vorteile in Bezug + auf Effektivität und Effizienz haben + \item + Geeignete Sicherheitsdienste können auf der Basis von Teilnetzen + oder Verbindungen ausgewählt werden, so dass keine Kosten für + Sicherheit anfallen, wenn der Schutz unnötig ist. + \end{itemize} + \item + Anzahl der Schutzpunkte: + + \begin{itemize} + \item + Wenn die Sicherheit auf der Anwendungsebene angesiedelt wird, muss + die Sicherheit in jeder sensiblen Anwendung und jedem Endsystem + implementiert werden. + \item + Sicherheit auf der Verbindungsebene bedeutet, dass am Ende jeder + Netzverbindung, die als weniger vertrauenswürdig gilt, Sicherheit + implementiert werden muss. + \item + Wenn die Sicherheit in der Mitte der Architektur angesiedelt wird, + müssen die Sicherheitsmerkmale an weniger Stellen installiert + werden. + \end{itemize} + \item + Schutz der Protokoll-Header: + + \begin{itemize} + \item + Der Sicherheitsschutz auf höheren Ebenen kann die Protokollköpfe der + unteren Protokollschichten nicht schützen. + \item + Die Netzwerkinfrastruktur muss möglicherweise ebenfalls geschützt + werden. + \end{itemize} + \item + Quelle/Senke-Bindung: + + \begin{itemize} + \item + Sicherheitsdienste wie die Authentifizierung der Datenherkunft und + die Unleugbarkeit hängen von der Zuordnung der Daten zu ihrer Quelle + oder Senke ab. + \item + Dies wird am effizientesten auf höheren Ebenen erreicht, + insbesondere auf der Anwendungsebene. + \end{itemize} + \end{itemize} + + + \subsection{Überlegungen zu bestimmten + Ebenen} + + \begin{itemize} + \item + Anwendungsebene: + + \begin{itemize} + \item + Diese Stufe kann die einzige geeignete Stufe sein, zum Beispiel + weil: + + \begin{itemize} + \item + Ein Sicherheitsdienst ist anwendungsspezifisch, z.B. die + Zugriffskontrolle für einen vernetzten Dateispeicher + \item + Ein Sicherheitsdienst muss Anwendungs-Gateways durchqueren, z.B. + Integrität und/oder Vertraulichkeit von elektronischer Post + \item + Die Semantik der Daten ist wichtig, z.B. für + Nichtabstreitbarkeitsdienste - Es liegt außerhalb der Reichweite + eines Benutzers/Anwendungsprogrammierers, Sicherheit auf einer + niedrigeren Ebene zu integrieren + \end{itemize} + \end{itemize} + \item + Endsystem-Ebene: + + \begin{itemize} + \item + Diese Ebene ist geeignet, wenn davon ausgegangen wird, dass die + Endsysteme vertrauenswürdig sind und das Kommunikationsnetz als + nicht vertrauenswürdig angesehen wird. + \item + Weitere Vorteile der Sicherheit auf Endsystemebene: + + \begin{itemize} + \item + Die Sicherheitsdienste sind für die Anwendungen transparent. + \item + Die Verwaltung von Sicherheitsdiensten kann leichter in die Hände + eines Systemadministrators gelegt werden. + \end{itemize} + \end{itemize} + \item + Teilnetzebene: + + \begin{itemize} + \item + Auch wenn die auf dieser Ebene implementierte Sicherheit in der + gleichen Protokollschicht wie auf der Endsystemebene implementiert + werden kann, sollten diese nicht verwechselt werden: + + \begin{itemize} + \item + Mit der auf der Subnetzebene implementierten Sicherheit wird in + der Regel der gleiche Schutz für alle Endsysteme dieses Subnetzes + realisiert + \end{itemize} + \item + Es ist sehr üblich, dass ein Teilnetz in der Nähe eines Endsystems + als ebenso vertrauenswürdig angesehen wird, da es sich in denselben + Räumlichkeiten befindet und von denselben Behörden verwaltet wird. + \item + In den meisten Fällen gibt es weit weniger zu sichernde + Teilnetz-Gateways als Endsysteme. + \end{itemize} + \item + Verbindungsebene: + + \begin{itemize} + \item + Wenn es relativ wenige nicht vertrauenswürdige Verbindungen gibt, + kann es ausreichend und zudem einfacher und kostengünstiger sein, + das Netz auf der Verbindungsebene zu schützen. + \item + Darüber hinaus können auf der Verbindungsebene spezielle + Schutztechniken eingesetzt werden, z. B. Spreizspektrum oder + Frequenzsprungverfahren. + \item + Die Vertraulichkeit des Verkehrsflusses erfordert in der Regel einen + Schutz auf Verbindungsebene. + \end{itemize} + \end{itemize} + + + \subsection{Interaktionen zwischen menschlichen + Nutzern} + + \begin{itemize} + \item + Einige Netzsicherheitsdienste beinhalten eine direkte Interaktion mit + einem menschlichen Benutzer, der wichtigste davon ist die + Authentifizierung. + \item + Solche Interaktionen passen in keine der bisher vorgestellten + Architekturoptionen, da der Benutzer außerhalb der + Kommunikationseinrichtungen steht. + \item + Die Kommunikation zur Unterstützung der Authentifizierung kann auf + eine der folgenden Weisen erfolgen: + + \begin{itemize} + \item + Örtlich: + + \begin{itemize} + \item + Der menschliche Benutzer authentifiziert sich gegenüber dem + lokalen Endsystem + \item + Das Endsystem authentifiziert sich gegenüber dem entfernten + Endsystem und teilt die Identität des Benutzers mit + \item + Das entfernte System muss dem lokalen Endsystem vertrauen + \end{itemize} + \item + Unter Einbeziehung von Protokollelementen auf der Anwendungsschicht: + + \begin{itemize} + \item + Der Benutzer gibt einige Authentifizierungsinformationen an das + lokale System weiter, die sicher an das entfernte System + weitergeleitet werden + \end{itemize} + \item + Kombination der oben genannten Mittel: + + \begin{itemize} + \item + Beispiel: Kerberos + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Integration in untere Protokollschichten vs. + Anwendungen} + + \begin{itemize} + \item + Vorteile der Integration von Sicherheitsdiensten in niedrigere + Netzwerkschichten: + + \begin{itemize} + \item + Sicherheit: + + \begin{itemize} + \item + Auch das Netz selbst muss geschützt werden + \item + Sicherheitsmechanismen, die in den Netzelementen (insbesondere in + der Hardware) realisiert sind, sind für die Netznutzer oft + schwerer angreifbar + \end{itemize} + \item + Anwendungsunabhängigkeit: + + \begin{itemize} + \item + Grundlegende Netzsicherheitsdienste müssen nicht in jede einzelne + Anwendung integriert werden + \end{itemize} + \item + Dienstgüte (QoS): + + \begin{itemize} + \item + Die QoS-erhaltende Planung des Kommunikationssubsystems kann auch + die Verschlüsselung nebeneinander bestehender Datenströme planen. + \item + Beispiel: gleichzeitiger Sprachanruf und FTP-Übertragung + \end{itemize} + \item + Effizienz: + + \begin{itemize} + \item + Hardware-Unterstützung für rechenintensive Ver-/Entschlüsselung + kann leichter in die Protokollverarbeitung integriert werden + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Integration in Endsysteme vs. + Zwischensysteme} + + \begin{itemize} + \item + Integration in Endsysteme: + + \begin{itemize} + \item + Kann im Allgemeinen entweder auf der Anwendungs- oder der + Endsystemebene erfolgen + \item + In einigen speziellen Fällen kann auch ein Schutz auf + Verbindungsebene angebracht sein, z. B. bei der Verwendung eines + Modems zur Verbindung mit einem bestimmten Gerät + \end{itemize} + \item + Integration in Zwischensysteme + + \begin{itemize} + \item + Kann auf allen vier Ebenen erfolgen: + + \begin{itemize} + \item + Anwendungs-/,,Endsystem"-Ebene: zur Sicherung der + Verwaltungsschnittstellen von Zwischenknoten, nicht zur Sicherung + des Nutzdatenverkehrs + \item + Teilnetz-/Link-Ebene: zur Sicherung des Nutzdatenverkehrs + \end{itemize} + \end{itemize} + \item + Je nach den Sicherheitszielen kann eine Integration sowohl in + Endsystemen als auch in Zwischensystemen sinnvoll sein + \end{itemize} + + + \subsection{Beispiel: Authentifizierungsbeziehungen in + Inter-Netzwerken} + + % \includegraphics{Assets/NetworkSecurity-Authentication-relation-in-inter-networks.png} + + %\begin{longtable}[]{@{}ll@{}} + % \toprule + % Authentication Relation & Application for securing\tabularnewline + % \midrule + % \endhead + % Endsystem \$\textbackslash leftrightarrow\$ Endsystem & User + % Channels\tabularnewline + % Endsystem \$\textbackslash leftrightarrow\$ Intermediate System & + % Management Interfaces, Accounting\tabularnewline + % Intermediate \$\textbackslash leftrightarrow\$ Intermediate System & + % Network Operation: Signaling, Routing, Accounting, ...\tabularnewline + % \bottomrule + %\end{longtable} + + + \subsection{Schlussfolgerung} + + \begin{itemize} + \item + Die Integration von Sicherheitsdiensten in Kommunikationsarchitekturen + wird von zwei Hauptfragen geleitet: + + \begin{itemize} + \item + Welcher Sicherheitsdienst in welchem Knoten? + \item + Welcher Sicherheitsdienst in welcher Schicht? + \end{itemize} + \item + Diese Design-Entscheidungen können auch durch einen Blick auf ein + pragmatisches Modell der vernetzten Datenverarbeitung geleitet werden, + das vier verschiedene Ebenen unterscheidet, auf denen + Sicherheitsdienste realisiert werden können: + + \begin{itemize} + \item + Anwendungs-/Endsystem-/Subnetz-/Link-Ebene + \end{itemize} + \item + Da es verschiedene Gründe für und gegen jede Option gibt, gibt es + keine einheitliche Lösung für dieses Designproblem. + \item + In diesem Kurs werden wir daher einige Beispiele für die Integration + von Sicherheitsdiensten in Netzarchitekturen untersuchen, um die + Auswirkungen der getroffenen Designentscheidungen besser zu verstehen + \end{itemize} + + + \section{Sicherheitsprotokolle der + Datenübertragungsschicht} + + \begin{itemize} + \item + IEEE 802.1Q, IEEE 802.1X \& IEEE 802.1AE + \item + Point-to-Point Protocol (PPP) + \item + Point-to-Point Tunneling Protocol (PPTP) + \item + Layer 2 Tunneling Protocol (L2TP) + \item + Virtual Private Networks (VPN) + \end{itemize} + + + \subsection{Anwendungsbereich von Sicherheitsprotokollen der + Verbindungsschicht} + + \begin{itemize} + \item + Nach dem klassischen Verständnis des OSI-Modells stellt die + Verbindungsschicht einen gesicherten Datenübertragungsdienst zwischen + zwei gleichrangigen Einheiten bereit, die direkt über ein + Kommunikationsmedium miteinander verbunden sind. + \item + Ihre Hauptaufgaben sind: + + \begin{itemize} + \item + Fehlererkennung und -korrektur + \item + Medium Access Control (MAC, nicht zu verwechseln mit Message + Authentication Code) für gemeinsam genutzte Medien, z. B. Ethernet + usw. + \end{itemize} + \item + Nicht alle heutigen Netzwerktechnologien passen in dieses Modell: + + \begin{itemize} + \item + Einwahlverbindungen zu einem Internetdienstanbieter + \item + Lösungen für virtuelle private Netzwerke (VPN) + \end{itemize} + \item + In diesem Kurs geben wir uns mit der folgenden Definition zufrieden: + + \begin{itemize} + \item + Der Zweck eines Link-Layer-Sicherheitsprotokolls besteht darin, + bestimmte Sicherheitseigenschaften der Link-Layer-PDUs zu + gewährleisten, d. h. der PDUs der Protokollschicht, die die PDUs der + Netzwerkschicht (z. B. IP) tragen. + \end{itemize} + \end{itemize} + + + \subsection{IEEE 802.1} + + + \subsubsection{Die IEEE 802.1 Standardfamilie: Hintergrund und + Ziele} + + \begin{itemize} + \item + Das Institute of Electrical and Electronics Engineers (IEEE) 802 + LAN/MAN Standards Committee entwickelt Standards für lokale Netzwerke + und Metropolitan Area Networks. + \item + Die am weitesten verbreiteten Standards sind: + + \begin{itemize} + \item + Ethernet-Familie (802.3, allgemein als CSMA/CD bezeichnet), + \item + Drahtloses LAN (802.11) + \item + WIMAX (802.16) + \end{itemize} + \item + Die IEEE 802.1-Standards: + + \begin{itemize} + \item + Können mit verschiedenen IEEE 802.x Technologien verwendet werden + \item + Definieren unter anderem verschiedene explizite Sicherheitsdienste + oder Dienste, die zur Erreichung von Sicherheitszielen verwendet + werden können + \end{itemize} + \end{itemize} + + + \subsubsection{IEEE 802.1Q} + + Ziele und Dienste + + \begin{itemize} + \item + Der Standard IEEE 802.1Q: + + \begin{itemize} + \item + Ermöglicht die Schaffung von ,,miteinander verbundenen + IEEE-802-Standard-LANs mit unterschiedlichen oder identischen + Methoden der Medienzugriffskontrolle'', d. h. die Schaffung + separater virtueller lokaler Netzwerke (VLANs) über eine physische + Infrastruktur + \item + Obwohl es sich nicht um einen echten Sicherheitsstandard handelt, + wird er häufig verwendet, um verschiedene Benutzer und Dienste + voneinander zu trennen, z. B. nicht vertrauenswürdige Gastcomputer + von Unternehmensservern, ohne eine neue Infrastruktur einzurichten + \item + Wird verwendet, um Zugangskontrolle auf Verbindungsebene zu + realisieren + \end{itemize} + \end{itemize} + + Grundlegende Funktionsweise + + \begin{itemize} + \item + Jedes Netzwerkpaket wird mit einem VLAN-Tag versehen, der eine + 12-Bit-VLAN-ID enthält, die ein virtuelles Netzwerk identifiziert + \item + Switches stellen sicher, dass Pakete mit bestimmten VLAN-IDs nur an + bestimmte Netzwerk-Ports zugestellt werden, z.B. wird ein VLAN mit + internen Firmeninformationen nicht an einen öffentlich zugänglichen + Port zugestellt + \item + Die VLAN-ID ist nicht kryptografisch geschützt! + + \begin{itemize} + \item + VLAN IDs müssen auf andere Weise, d.h. physikalisch, gesichert + werden! + \item + Normalerweise werden VLAN-IDs am ersten vertrauenswürdigen Switch + eingefügt und am letzten vertrauenswürdigen Switch auf dem Weg durch + das Netzwerk entfernt + \end{itemize} + \end{itemize} + + Typisches Einführungsszenario + + \begin{itemize} + \item + Normalerweise wird das vertrauenswürdige innere Netzwerk durch + physische Mittel geschützt + \item + Verschiedene Ports zum vertrauenswürdigen Kern werden VLANs zugeordnet + \item + VLANs sind virtuell verbunden, dürfen aber nicht auf andere VLANs + zugreifen + \item + VLANs werden normalerweise gekoppelt durch + + \begin{itemize} + \item + Router, die mehrere Schnittstellen in den verschiedenen VLANs haben + \item + Router, die selbst zum vertrauenswürdigen Netzwerk gehören und + selbst getaggte Frames empfangen und senden können (kann gefährlich + sein, Wechselwirkung zwischen Routing und VLANs, siehe unten) + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ieee802.1q-scenario.png} + \end{itemize} + + Weitere Diskussion + + \begin{itemize} + \item + 802.1Q ermöglicht eine einfache Trennung verschiedener + Sicherheitsdomänen innerhalb eines vertrauenswürdigen Netzwerks + + \begin{itemize} + \item + Ermöglicht auch die Priorisierung bestimmter VLANs (z. B. um die + Verwaltung von Geräten zu ermöglichen, wenn der Rest des Netzes von + einem Angreifer überflutet wird) + \item + VLAN-Tags können gestapelt werden, z. B. um verschiedene Kunden zu + trennen, die eigene VLANs einrichten + \end{itemize} + \item + Diskussion über die Sicherheit: + + \begin{itemize} + \item + Die Sicherheit hängt davon ab, dass kein einziges Gerät in der + vertrauenswürdigen Domäne kompromittiert wird! + \item + Alle Switches müssen korrekt konfiguriert sein, d.h. kein einziger + Switch darf eingehenden Verkehr aus einem nicht vertrauenswürdigen + Netz zulassen, der bereits getaggt ist + \item + Paketfluten in einem VLAN können sich auch auf andere VLANs + auswirken + \item + Router, die an mehreren VLANs teilnehmen, können auf einer + Schnittstelle Pakete aus verschiedenen VLANs empfangen, aber + \item + Anstatt ein striktes Routing zu einer anderen Schnittstelle (z. B. + dem Internet) durchzuführen, könnte ein Angreifer diesen Router + nutzen, um über dieselbe Schnittstelle zurück in ein anderes VLAN zu + routen (sogenannter Layer-2-Proxy-Angriff) + \item + Kann sogar funktionieren, wenn VLAN 1 und VLAN 2 das gleiche + IP-Subnetz nutzen! + \end{itemize} + \end{itemize} + + + \subsubsection{IEEE 802.1X} + + Ziele + + \begin{itemize} + \item + Der Standard IEEE 802.1X: + + \begin{itemize} + \item + Ziel ist es, ,,den Zugang zu den von einem LAN angebotenen Diensten + auf diejenigen Benutzer und Geräte zu beschränken, die diese Dienste + nutzen dürfen'' + \end{itemize} + \item + Definiert eine portbasierte Netzwerkzugriffskontrolle, um ein Mittel + zur ,,Authentifizierung und Autorisierung von Geräten bereitzustellen, + die an einen LAN-Port mit Punkt-zu-Punkt-Verbindungseigenschaften + angeschlossen sind''. + \end{itemize} + + Kontrollierte und unkontrollierte Ports + + \begin{itemize} + \item + IEEE 802.1X führt den Begriff der zwei logischen Ports ein: + + \begin{itemize} + \item + Der unkontrollierte Port ermöglicht die Authentifizierung eines + Geräts + \item + Der kontrollierte Port ermöglicht es einem authentifizierten Gerät, + auf LAN-Dienste zuzugreifen + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ieee802.1X-ports.png} + \end{itemize} + + Rollen + + \begin{itemize} + \item + Es werden drei Hauptrollen unterschieden: + + \begin{itemize} + \item + Ein Gerät, das den von einem IEEE 802.1X LAN angebotenen Dienst + nutzen möchte, agiert als Supplicant, der den Zugriff auf den + kontrollierten Port anfordert + \item + Der Anschlusspunkt an die LAN-Infrastruktur (z. B. eine MAC-Brücke) + fungiert als Authentifikator, der den Supplicant auffordert, sich zu + authentifizieren. + \item + Der Authentifikator prüft die vom Antragsteller vorgelegten + Anmeldeinformationen nicht selbst, sondern leitet sie zur + Überprüfung an seinen Authentifizierungsserver weiter. + \end{itemize} + \item + Zugriff auf ein LAN mit IEEE 802.1X Sicherheitsmaßnahmen: + + \begin{itemize} + \item + Vor einer erfolgreichen Authentifizierung kann der Antragsteller auf + den unkontrollierten Port zugreifen: + + \begin{itemize} + \item + Der Port ist unkontrolliert in dem Sinne, dass er den Zugriff vor + der Authentifizierung erlaubt. + \item + Dieser Port erlaubt jedoch nur einen eingeschränkten Zugriff + \end{itemize} + \item + Die Authentifizierung kann durch den Supplicant oder den + Authenticator initiiert werden. + \item + Nach erfolgreicher Authentifizierung wird der kontrollierte Port + geöffnet. + \end{itemize} + \end{itemize} + + Sicherheitsprotokolle und Nachrichtenaustausch + + \begin{itemize} + \item + IEEE 802.1X definiert keine eigenen Sicherheitsprotokolle, sondern + befürwortet die Verwendung bestehender Protokolle: + + \begin{itemize} + \item + Das Extensible Authentication Protocol (EAP) kann eine grundlegende + Geräteauthentifizierung realisieren {[}RFC 3748{]}. + \item + Wenn die Aushandlung eines Sitzungsschlüssels während der + Authentifizierung erforderlich ist, wird die Verwendung des EAP TLS + Authentication Protocol empfohlen {[}RFC 5216{]}. + \item + Außerdem wird empfohlen, den Authentifizierungsserver mit dem Remote + Authentication Dial In User Service (RADIUS) {[}RFC 2865{]} zu + realisieren. + \end{itemize} + \item + Der Austausch von EAP Nachrichten zwischen Supplicant und + Authenticator wird mit dem EAP over LANs (EAPOL) Protokoll realisiert: + + \begin{itemize} + \item + EAPOL definiert die Verkapselungstechniken, die verwendet werden + sollen, um EAP-Pakete zwischen Supplicant Port Access Entities (PAE) + und Authenticator PAEs in einer LAN-Umgebung zu übertragen. + \item + EAPOL-Rahmenformate wurden für verschiedene Mitglieder der + 802.x-Protokollfamilie definiert, z. B. EAPOL für Ethernet, ... + \item + Zwischen Supplicant und Authenticator können RADIUS-Nachrichten + verwendet werden + \end{itemize} + \end{itemize} + + Beispiel für eine + 802.1X-Authentifizierung{]}(Assets/NetworkSecurity-ieee802.1X-example.png) + + + \subsubsection{IEEE 802.1AE} + + Ziele + + \begin{itemize} + \item + Der Standard IEEE 802.1AE wird auch als MAC-Sicherheit (MACsec) + bezeichnet: + + \begin{itemize} + \item + Ermöglicht autorisierten Systemen, die sich an LANs in einem + Netzwerk anschließen und diese miteinander verbinden, die + Vertraulichkeit der übertragenen Daten zu wahren und Maßnahmen gegen + Frames zu ergreifen, die von nicht autorisierten Geräten übertragen + oder verändert werden. '' + \item + Schützt Pakete durch kryptografische Mittel zwischen Geräten, z. B. + zwischen Switches oder einem Computer und einem Switch + \item + Setzt eine gültige Authentifizierung voraus und ist somit eine + Erweiterung von 802.1X + \item + Kryptografische Schlüssel werden auch während der + 802.1X-Authentifizierungsphase abgeleitet + \item + Kann Datenursprungsauthentifizierung und optional Vertraulichkeit + durchführen + \item + Unterstützt AES-128 und AES-256 in GCM, wobei die Unterstützung von + AES-128-GCM obligatorisch ist! + \end{itemize} + \end{itemize} + + Frame-Format + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ieee802.1AE-frame.png} + \item + Quell- und Zieladressen werden im Klartext gesendet + \item + VLAN-Tag, Typfeld und Nutzdaten werden ebenfalls verschlüsselt + \item + Ein neuer 8-16 Byte langer SecTAG wird eingefügt + + \begin{itemize} + \item + Beginnt mit 0x88e5, um ein Protokoll für ältere Geräte zu emulieren + \item + Enthält einen 4-Byte-Paketzähler (wird als IV verwendet, auch um + Replay-Angriffe abzuwehren) + \end{itemize} + \item + FCS wird durch einen kryptografischen MAC von 8-16 Byte ersetzt und + von MACsec berechnet, optional kann ein zusätzlicher CRC-FCS für + ältere Geräte hinzugefügt werden + \end{itemize} + + Diskussion über Sicherheit + + \begin{itemize} + \item + MACsec erlaubt es, Verbindungen zu sichern, z.B. zwischen Gebäuden auf + einem Campus + \item + Es bietet keinen Schutz gegen kompromittierte Geräte! + + \begin{itemize} + \item + Wenn es in Kombination mit 802.1Q verwendet wird, kann die + vertrauenswürdige Computerbasis immer noch ziemlich groß sein... + \item + Die Verwendung des GCM unterliegt den in Kapitel 5 beschriebenen + potenziellen Problemen + \item + Derzeit unterstützen nur hochwertige Switches MACsec! + \end{itemize} + \end{itemize} + + + \subsection{Punkt-zu-Punkt-Protokoll} + + Zweck und Aufgaben + + \begin{itemize} + \item + Große Teile des Internets beruhen auf Punkt-zu-Punkt-Verbindungen: + + \begin{itemize} + \item + Wide Area Network (WAN)-Verbindungen zwischen Routern + \item + Einwahlverbindungen von Hosts über Modems und Telefonleitungen + \end{itemize} + \item + Protokolle für diesen Zweck: + + \begin{itemize} + \item + Serial Line IP (SLIP): keine Fehlererkennung, unterstützt nur IP, + keine dynamische Adressvergabe, keine Authentifizierung {[}RFC + 1055{]} + \item + Point-to-Point Protocol (PPP): Nachfolger von SLIP, unterstützt IP, + IPX, ... + \item + % \includegraphics{Assets/NetworkSecurity-Point-to-Point.png} + \end{itemize} + \item + PPP {[}RFC 1661/1662{]} + + \begin{itemize} + \item + Schicht-2-Rahmenformat mit Rahmenbegrenzung und Fehlererkennung + \item + Kontrollprotokoll (Link Control Protocol, LCP) für + Verbindungsaufbau, -test, -aushandlung und -abbau + \item + Separate Netzwerkkontrollprotokolle (NCP) für unterstützte + Schicht-3-Protokolle + \end{itemize} + \end{itemize} + + Packet Format + + \begin{itemize} + \item + Zeichenorientierte (statt bitorientierte) + \$\textbackslash Rightarrow\$ byteausgerichtete Rahmen + \item + Code-Transparenz wird durch Zeichenstuffing erreicht + \item + Normalerweise werden nur unnummerierte Frames übertragen, in Szenarien + mit hoher Fehlerwahrscheinlichkeit (drahtlose Kommunikation) kann + jedoch ein zuverlässigerer Modus mit Sequenznummern und erneuten + Übertragungen ausgehandelt werden + \item + Unterstützte Protokolle für das Nutzdatenfeld sind u.a.: IP, IPX, + Appletalk + \item + Wenn nicht anders ausgehandelt, beträgt die maximale Nutzdatengröße + 1500 Byte. + \item + Zusätzliche Aushandlung unterstützt kleinere Paketköpfe + \item + % \includegraphics{Assets/NetworkSecurity-Punkt-zu-Punkt-Format.png} + \end{itemize} + + Eine typische PPP-Verbindung + + \begin{itemize} + \item + Nutzungsszenario ,,Internetzugang eines PCs über Modem'': + + \begin{itemize} + \item + Der Benutzer ruft den Internet Service Provider (ISP) über ein Modem + an und stellt eine ,,physikalische'' Verbindung über den ,,Plain Old + Telephone Service'' (POTS) her. + \item + Anrufer sendet mehrere LCP-Pakete in PPP-Frames, um die gewünschten + PPP-Parameter auszuwählen + \item + Sicherheitsspezifische Aushandlung (siehe unten) + \item + Austausch von NCP-Paketen zur Konfiguration der Netzwerkschicht: + + \begin{itemize} + \item + z.B. Konfiguration von IP einschließlich dynamischer Zuweisung + einer IP-Adresse über Dynamic Host Configuration Protocol (DHCP) + \end{itemize} + \item + Der Anrufer kann wie jeder andere Host mit einer festen Verbindung + zum Internet beliebige Internetdienste nutzen + \item + Beim Verbindungsabbau werden die zugewiesene IP-Adresse und die + Netzschichtverbindung freigegeben + \item + Die Schicht-2-Verbindung wird über LCP freigegeben und das Modem + baut die ,,physikalische'' Verbindung ab + \end{itemize} + \end{itemize} + + Link Control Protocol + + \begin{itemize} + \item + Rahmenformat des Link Control Protocol (LCP): + + \begin{itemize} + \item + Code: configure-request, configure-ack, configure-nack, + configure-reject, terminate-request, terminate-ack, code-reject, + protocol-reject, echo-request, echo-reply, discard-request + \item + Länge: gibt die Länge des LCP-Pakets einschließlich des Codefelds + usw. an + \item + Daten: null oder mehr Oktette befehlsspezifischer Daten + \item + % \includegraphics{Assets/NetworkSecurity-Point-to-Point-LCP.png} + \end{itemize} + \item + Die Konfigurationsprimitive von LCP ermöglichen die Konfiguration der + Verbindungsschicht: + + \begin{itemize} + \item + Es gibt verschiedene Optionen für dieses Primitiv zur Konfiguration + verschiedener Aspekte (max. Empfangseinheit, Protokollkompression, + Authentifizierung, ...) + \end{itemize} + \end{itemize} + + Sicherheitsdienste + + \begin{itemize} + \item + Die ursprüngliche Version von PPP {[}RFC 1661{]} schlägt die optionale + Ausführung eines Authentifizierungsprotokolls nach der + Verbindungsaufbauphase vor: + + \begin{itemize} + \item + Falls erforderlich, wird die Authentifizierung von einer + Peer-Entität über einen LCP Configuration-Request am Ende der + Verbindungsaufbauphase gefordert + \item + Ursprünglich sind zwei Authentifizierungsprotokolle definiert + worden: + + \begin{itemize} + \item + Passwort-Authentifizierungsprotokoll (PAP) + \item + Challenge-Handshake-Authentifizierungsprotokoll (CHAP) + \end{itemize} + \item + Inzwischen ist ein erweiterbares Protokoll definiert worden: + + \begin{itemize} + \item + Erweiterbares Authentifizierungsprotokoll (EAP) + \item + PPP EAP Transport Level Security Protocol (PPP-EAP-TLS) + \end{itemize} + \end{itemize} + \item + Außerdem kann nach der Authentifizierung eine Verschlüsselung + ausgehandelt werden: + + \begin{itemize} + \item + Protokolle: + + \begin{itemize} + \item + Encryption Control Protocol (ECP) zur Aushandlung + \item + PPP DES-Verschlüsselungsprotokoll (DESE) + \item + PPP-Dreifach-DES-Verschlüsselungsprotokoll (3DESE) + \end{itemize} + \end{itemize} + \end{itemize} + + Authentifizierungsprotokolle + + \begin{itemize} + \item + Passwort-Authentifizierungs-Protokoll (PAP): + + \begin{itemize} + \item + PAP wurde 1992 in RFC 1334 definiert. + \item + Das Protokoll ist sehr einfach: + + \begin{itemize} + \item + Voraussetzung: der Authentifikator kennt das Passwort der + Peer-Entität + \item + Am Ende der Verbindungsaufbauphase fordert eine Entität, + Authenticator genannt, die Peer-Entität auf, sich mit PAP zu + authentifizieren + \item + Die Peer-Entität sendet eine Authenticate-Request-Nachricht mit + ihrer Peer-ID und ihrem Passwort + \item + Der Authentifikator prüft, ob die bereitgestellten Informationen + korrekt sind und antwortet entweder mit einem Authenticate-ack + oder einem Authenticate-nack + \end{itemize} + \item + Da das Protokoll keinen kryptographischen Schutz bietet, ist es + unsicher. + \item + PAP wird in den aktualisierten RFCs für die PPP-Authentifizierung + nicht erwähnt {[}RFC1994{]}. + \end{itemize} + \item + Challenge Handshake Authentication Protocol (CHAP): + + \begin{itemize} + \item + CHAP ist ebenfalls in RFC 1334 und RFC 1994 definiert. + \item + Es verwirklicht ein einfaches Challenge-Response-Protokoll: + + \begin{itemize} + \item + Voraussetzung: Authentifikator und Peer-Entität teilen ein + Geheimnis + \item + Nach der Verbindungsaufbauphase sendet der Authentifikator (A) + eine Challenge-Nachricht, die einen Identifikator für diese + Challenge, eine Zufallszahl \$r\_A\$ und seinen Namen enthält, an + die Peer-Entität (B): \$A \textbackslash rightarrow B: (1, + Identifikator, r\_A, A)\$ + \item + Die Peer-Entität berechnet eine kryptografische Hash-Funktion über + ihren Namen, das gemeinsame Geheimnis \$K\_\{A,B\}\$ und die + Zufallszahl \$r\_A\$ und sendet die folgende Nachricht: \$B + \textbackslash rightarrow A: (2, Kennung, H(B, K\_\{A,B\}, r\_A), + B)\$ + \item + Beim Empfang dieser Nachricht berechnet der Authentifikator den + Hashwert neu und vergleicht ihn mit dem empfangenen Wert; wenn + beide Werte übereinstimmen, antwortet er mit einer Erfolgsmeldung + \item + RFC 1994 legt fest, dass MD5 als Hash-Funktion unterstützt werden + muss, aber die Verwendung anderer Hash-Funktionen kann + ausgehandelt werden + \end{itemize} + \end{itemize} + \item + CHAP-Nachrichtenformat: + + \begin{itemize} + \item + Code: 1 \textasciitilde{} Herausforderung / 2 \textasciitilde{} + Antwort / 3 \textasciitilde{} Erfolg / 4 \textasciitilde{} Fehler + \item + Identifier: ein Oktett, das bei jeder gesendeten Challenge geändert + werden muss + \item + Länge: die Gesamtlänge der CHAP-Nachricht in Oktetten + \item + Value Size: ein Oktett, das die Länge des Wertes angibt + \item + Wert: enthält die zufällige Herausforderung / die Antwort auf die + Herausforderung + \item + Name: ein oder mehrere Oktette, die das System identifizieren, das + das Paket erstellt hat; die Größe des Namens wird anhand des + Längenfeldes berechnet + \item + % \includegraphics{Assets/NetworkSecurity-Point-to-Point-CHAP1.png} + \item + Nachricht: + + \begin{itemize} + \item + Null oder mehr Oktette mit implementierungsabhängigem Inhalt + \item + Der Inhalt soll für den Menschen lesbar sein und hat keinen + Einfluss auf die Funktionsweise des Protokolls + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-Point-to-Point-CHAP2.png} + \end{itemize} + \item + Erweiterbares Authentifizierungsprotokoll (EAP): + + \begin{itemize} + \item + EAP ist ein allgemeines Protokoll für die PPP-Authentifizierung, das + mehrere Authentifizierungsmethoden unterstützt {[}RFC2284{]}. + \item + Die Hauptidee hinter EAP ist es, ein gemeinsames Protokoll + bereitzustellen, um komplexere Authentifizierungsmethoden als ,,1 + Frage + 1 Antwort'' durchzuführen. + \item + Das Protokoll bietet grundlegende Primitive: + + \begin{itemize} + \item + Anfrage, Antwort: weiter verfeinert durch Typfeld + typspezifische + Daten + \item + Success, Failure: zur Angabe des Ergebnisses eines + Authentifizierungsaustauschs + \end{itemize} + \item + Typ-Felder: + + \begin{itemize} + \item + Identität + \item + Benachrichtigung + \item + Nak (nur Antwort, zur Beantwortung inakzeptabler Anfragetypen) + \item + MD5 Challenge (dies entspricht CHAP) + \item + One-Time Password (OTP): definiert in {[}RFC2289{]} + \item + Generische Token-Karte + \item + EAP-TLS + \end{itemize} + \end{itemize} + \item + Einmaliges Kennwort (One-Time Password, OTP): + + \begin{itemize} + \item + Die Grundidee von OTP besteht darin, ein ,,Passwort'' zu + übermitteln, das nur für einen Durchlauf eines + Authentifizierungsdialogs verwendet werden kann + \item + Erstmalige Einrichtung: + + \begin{itemize} + \item + Der Authentifikator A sendet einen Seed-Wert rA und die + Peer-Entität B verkettet diesen mit seinem Passwort und berechnet + einen Hash-Wert: \$PW\_N = H\^{}N(r\_A, password\_B)\$ + \item + Das Paar \$(N, PW\_N)\$ wird ,,sicher'' an den Authentifikator + übertragen und beim Authentifikator gespeichert. + \end{itemize} + \item + Dialog zur Authentifizierung: + + \begin{itemize} + \item + \$A\textbackslash rightarrow B: N - 1\$ + \item + \$B\textbackslash rightarrow A: PW\_\{N-1\} := H\^{}\{N-1\}(r\_A, + Passwort\_B)\$ + \item + A prüft, ob \$H(PW\_\{N-1\}) = PW\_N\$, und speichert \$(N-1, + PW\_\{N-1\})\$ als neue Authentifizierungsinformation für B + \end{itemize} + \item + Sicherheit: Um dieses Verfahren zu brechen, müsste ein Angreifer ein + PWN abhören und \$H\^{}\{-1\}(PW\_N)\$ berechnen, was unpraktisch + ist. + \end{itemize} + \item + Generische Token-Karte: + + \begin{itemize} + \item + Im Grunde ein Challenge-Response-Dialog + \item + Eine Token-Karte wird verwendet, um eine Antwort auf eine + Herausforderung zu berechnen: + + \begin{itemize} + \item + Die Herausforderung wird dem Benutzer präsentiert, der sie in sein + Token-Card-Gerät eintippen muss. + \item + Die Token-Karte berechnet die Antwort und zeigt sie an. + \item + Der Benutzer gibt die Antwort in das System ein, das sie als + Antwort auf die Aufforderungsnachricht sendet. + \end{itemize} + \end{itemize} + \item + PPP-EAP-TLS: + + \begin{itemize} + \item + TLS steht für Transport Layer Security {[}RFC 2246{]}. + \item + Es wird also der Authentifizierungsdialog von TLS ausgeführt + \item + Dieser Dialog wird in Kapitel 12 über die Sicherheit der + Transportschicht im Detail erläutert. + \end{itemize} + \end{itemize} + + Verschlüsselungsprotokolle + + \begin{itemize} + \item + Nach dem Verbindungsaufbau und der Authentifizierungsphase kann die + Verschlüsselung für eine PPP-Verbindung ausgehandelt werden: + + \begin{itemize} + \item + Das Encryption Control Protocol (ECP) {[}RFC1968{]} ist für die + Konfiguration und Aktivierung von Datenverschlüsselungsalgorithmen + an beiden Enden der PPP-Verbindung zuständig: + + \begin{itemize} + \item + ECP verwendet das gleiche Rahmenformat wie LCP und führt zwei neue + Primitive ein: Reset-Request und Reset-Ack zur Anzeige von + Entschlüsselungsfehlern unabhängig für jede Richtung (nützlich für + die kryptographische Resynchronisation) + \item + Eine bestimmte Verschlüsselungsmethode wird mit dem + configure-Primitiv ausgehandelt, das eine Option zur Angabe von + DESE, 3DESE, Proprietär usw. enthält. + \item + Proprietäre Verschlüsselungsprotokolle werden durch einen + registrierten OUI (Organizational Unit Identifier) + einen + herstellerspezifischen Wert identifiziert. + \item + Genau ein ECP-Paket wird im PPP-Informationsfeld eines + Link-Layer-Pakets transportiert + \item + ECP-Pakete werden durch das PPP-Protokollfeld identifiziert: + + \begin{itemize} + \item + 0x8053 für ,,Standard'' Betrieb + \item + 0x8055 für die Verschlüsselung einzelner Verbindungsdaten auf + mehreren Verbindungen zum selben Ziel + \end{itemize} + \end{itemize} + \end{itemize} + \item + Das PPP DES Encryption Protocol (DESE): + + \begin{itemize} + \item + In diesem Kurs wird nur die aktualisierte Version DESEv2 + {[}RFC2419{]} behandelt + \item + % \includegraphics{Assets/NetworkSecurity-Point-to-Point-DESE.png} + \item + DESEv2 wird mit einer ECP-Konfigurationsanforderungsnachricht + ausgehandelt: + + \begin{itemize} + \item + Code: 1 \textasciitilde{} configure request + \item + Identifier: ändert sich mit jeder neuen Anfrage + \item + Länge: Gesamtlänge der Configure-Request-Nachricht + \item + Type: 3 \textasciitilde{} DESEv2 + \item + Länge': 10 (die Länge dieser Konfigurationsoption) + \item + Initial Nonce: ein Initialisierungsvektor für DES im CBC-Modus (8 + Oktette) + \end{itemize} + \end{itemize} + \item + PPP DESE v2 Nachrichtenformat: + + \begin{itemize} + \item + Adresse: 0x11111111 (bei HDLC-ähnlichem Framing) + \item + Steuerung: 0x00000011 (bei HDLC-ähnlicher Rahmung) + \item + Protokoll-ID: 0x0053 \textasciitilde{} DESE (Standard) / 0x0055 + \textasciitilde{} DESE (individuelle Verbindung) + \item + Sequenznummer: anfänglich 0, diese Nummer wird von der + verschlüsselnden Stelle bei jedem gesendeten Paket erhöht + \item + Chiffriertext: die verschlüsselten Protokoll- und Informationsfelder + eines PPP-Pakets + + \begin{itemize} + \item + Nachrichten werden vor der Verschlüsselung auf ein Vielfaches von + 8 Oktetten aufgefüllt + \item + die Verschlüsselung erfolgt mit DES im CBC-Modus + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-Point-to-Point-DESE2.png} + \end{itemize} + \item + PPP 3DES Encryption Protocol (3DESE): + + \begin{itemize} + \item + PPP 3DESE {[}RFC2420{]} ist dem PPP DESE sehr ähnlich + \item + PPP 3DESE wird mit einer Configure-Request-Nachricht ausgehandelt, + wobei das Type-Feld der Option auf 2 gesetzt ist (\textasciitilde{} + 3DESE) + \item + Die Verschlüsselung der PPP-Nutzdaten erfolgt wie bei DESE, mit dem + Unterschied, dass 3DES mit 3 verschiedenen Schlüsseln verwendet wird + \end{itemize} + \item + Alle PPP-Verschlüsselungsprotokolle gehen davon aus, dass vor der + Verschlüsselungsphase ein Sitzungsschlüssel für die + Verschlüsselung/Entschlüsselung von PPP-Paketen vereinbart wurde: + + \begin{itemize} + \item + Diese Annahme ist sinnvoll, da die Festlegung des Sitzungsschlüssels + eine Aufgabe ist, die während der Authentifizierungsphase erfüllt + werden sollte. + \item + Allerdings unterstützt nur das + PPP-EAP-TLS-Authentifizierungsprotokoll den Aufbau von + Sitzungsschlüsseln. + \end{itemize} + \end{itemize} + + + \subsubsection{Punkt-zu-Punkt-Tunneling-Protokoll + (PPTP)} + + \begin{itemize} + \item + PPP wurde ursprünglich für den Betrieb zwischen ,,direkt'' verbundenen + Einheiten entwickelt, d.h. Einheiten, die eine gemeinsame + Schicht-2-Verbindung haben + + \begin{itemize} + \item + Beispiel: ein PC und ein Einwahlrouter eines Internetanbieters, die + über das Telefonnetz mittels Modem verbunden sind + \end{itemize} + \item + Die Grundidee von PPTP besteht darin, die Reichweite des Protokolls + auf das gesamte Internet auszudehnen, indem der Transport von PPP-PDUs + in IP-Paketen definiert wird + + \begin{itemize} + \item + Die Nutzlast von PPTP-PDUs sind also PPP-Pakete (ohne + schicht-2-spezifische Felder wie HDLC-Flags, Bit-Einfügungen, + Steuerzeichen, CRC-Fehlerprüfwerte usw.) + \item + PPP-Pakete werden in GRE-Pakete (generische Routing-Kapselung) + eingekapselt, die wiederum in IP-Pakete eingekapselt werden: + \end{itemize} + \end{itemize} + + %\begin{longtable}[]{@{}l@{}} + % \toprule + % \endhead + % Media Header (e.g. Ethernet MAC header)\tabularnewline + % IP Header\tabularnewline + % GRE V.2 Header\tabularnewline + % PPP Packet\tabularnewline + % \bottomrule + %\end{longtable} + + + \subsubsection{PPTP: Freiwilliges vs. obligatorisches + Tunneling} + + \begin{itemize} + \item + PPTP realisiert einen ,,Tunnel'' über das Internet, der PPP-Pakete + überträgt. + \item + Ein solcher Tunnel kann zwischen verschiedenen Einheiten realisiert + werden: + + \begin{itemize} + \item + Einem Client-PC und einem PPTP Remote Access Server (RAS): + + \begin{itemize} + \item + Dies wird auch als freiwilliges Tunneling bezeichnet, da der + Client-PC aktiv an der PPTP-Verarbeitung beteiligt ist. + \item + Diese Variante ermöglicht die sichere Kommunikation zwischen einem + Client-PC und einem bestimmten Subnetz unter Verwendung beliebiger + Zugangs- und Zwischennetze + \end{itemize} + \item + Ein Point of Presence (POP) eines ISP und ein + PPTP-Fernzugangsserver: + + \begin{itemize} + \item + Dies wird auch als obligatorisches Tunneling bezeichnet, da der + Client-PC nicht an der Entscheidung beteiligt ist, ob PPTP + verwendet wird oder nicht. + \item + Auf diese Weise lässt sich Sicherheit auf Subnetzebene + realisieren, aber keine echte End-to-End-Sicherheit zwischen dem + Client-PC und dem RAS + \item + Beim obligatorischen Tunneling fungiert der ISP POP als + Proxy-Client für den RAS + \end{itemize} + \end{itemize} + \end{itemize} + + Obligatorische Tunneling-Protokollschichten + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-PPTP-Tunneling-Protocol.png} + \item + % \includegraphics{Assets/NetworkSecurity-PPTP-Tunneling-Protocol2.png} + \item + % \includegraphics{Assets/NetworkSecurity-PPTP-Packet-Construction-at-Client.png} + \end{itemize} + + + \subsubsection{PPTP / PPP Proprietäre Erweiterungen und einige + ,,Geschichte''} + + \begin{itemize} + \item + PPTP hat sich vor allem aufgrund der Unterstützung durch Microsoft + durchgesetzt: + + \begin{itemize} + \item + Es wurde unter aktiver Beteiligung von Microsoft entwickelt und ist + in {[}RFC2637{]} dokumentiert. + \item + Microsoft implementierte es als Teil seines Remote Access Service + (RAS) + \end{itemize} + \item + Microsoft hat weitere ,,proprietäre'' Erweiterungen für PPP + spezifiziert: + + \begin{itemize} + \item + Microsoft PPP CHAP-Erweiterungen {[}RFC2433{]} + \item + Microsoft Point to Point Encryption Protocol {[}RFC3078{]} + \end{itemize} + \item + Allerdings wurde eine Reihe von Schwachstellen in PPTP Version 1 und + auch in einer verbesserten Version 2 entdeckt {[}SM98a, SMW99a{]}: + + \begin{itemize} + \item + Ein allgemeiner Konsens, PPTP als Standardprotokoll zu übernehmen, + konnte in den in den IETF-Arbeitsgruppen nicht erreicht werden. + \item + Außerdem wurde ein ähnliches Protokoll (Layer 2 Forwarding, L2F) von + Cisco als konkurrierender Ansatz vorgeschlagen + \item + Infolgedessen wurde ein Kompromiss gefunden, der die Vorteile beider + Vorschläge in einem einzigen Protokoll zusammenfasst: Layer 2 + Tunneling Protocol (L2TP) + \end{itemize} + \end{itemize} + + + \subsubsection{Vergleich von PPTP und + L2TP} + + \begin{itemize} + \item + Beide Protokolle: + + \begin{itemize} + \item + verwenden PPP, um eine anfängliche Umhüllung für Benutzerpakete + bereitzustellen + \item + erweitern das PPP-Modell, indem sie erlauben, dass die Layer-2- und + PPP-Endpunkte sich auf verschiedenen Geräten befinden + \item + unterstützen freiwilliges und obligatorisches Tunneling + \end{itemize} + \item + Zugrundeliegendes Netzwerk: + + \begin{itemize} + \item + PPTP benötigt ein IP-Netzwerk für den Transport seiner PDUs + \item + L2TP unterstützt verschiedene Technologien: IP (unter Verwendung von + UDP), permanente virtuelle Schaltungen (PVCs) von Frame Relay, + virtuelle Schaltungen (VCs) von X.25 oder ATM VCs + \end{itemize} + \item + PPTP kann nur einen einzigen Tunnel zwischen Endpunkten unterstützen, + L2TP ermöglicht die Verwendung mehrerer Tunnel zwischen Endpunkten + + \begin{itemize} + \item + L2TP ermöglicht z. B. die Erstellung verschiedener Tunnel für + unterschiedliche Dienstqualitäten + \end{itemize} + \item + Beide Protokolle bieten eine Header-Kompression: + + \begin{itemize} + \item + Mit Header-Kompression kommt L2TP mit 4 Byte Overhead aus, im + Vergleich zu 6 Byte bei PPTP. + \end{itemize} + \item + L2TP ermöglicht eine Tunnelauthentifizierung, während PPTP dies nicht + tut. + \end{itemize} + + + \subsection{Virtuelle private + Netzwerke} + + \begin{itemize} + \item + Verschiedene Definitionen des Begriffs virtuelles privates Netzwerk + (VPN): + + \begin{itemize} + \item + Ein privates Netz, das innerhalb einer öffentlichen + Netzinfrastruktur, wie dem globalen Internet, aufgebaut ist. + \item + Eine Kommunikationsumgebung, in der der Zugang kontrolliert wird, um + Peer-Verbindungen nur innerhalb einer definierten + Interessengemeinschaft zuzulassen, und die durch eine Form der + Partitionierung eines gemeinsamen zugrundeliegenden + Kommunikationsmediums aufgebaut ist, wobei dieses zugrundeliegende + Kommunikationsmedium dem Netz Dienste auf nicht-exklusiver Basis + bereitstellt + \item + Ein logisches Computernetzwerk mit eingeschränkter Nutzung, das aus + den Systemressourcen eines relativ öffentlichen, physischen + Netzwerks (z. B. dem Internet) aufgebaut ist, oft unter Verwendung + von Verschlüsselung und oft durch Tunneln von Verbindungen des + virtuellen Netzwerks über das reale Netzwerk {[}RFC2828{]}. + \item + Anmerkung: Die beiden letzteren Definitionen beinhalten explizit + Sicherheitseigenschaften (kontrollierter Zugriff, Verschlüsselung), + die erste hingegen nicht. + \end{itemize} + \end{itemize} + + \begin{quote} + ,,Sicher, es ist viel billiger als eigene Frame-Relay-Verbindungen, aber + es funktioniert ungefähr so gut, wie wenn man sich auf dem Times Square + Watte in die Ohren steckt und so tut, als wäre sonst niemand da.'' + (Wired Magazine Feb. 1998) + \end{quote} + + Techniken zum Aufbau virtueller privater Netze + + \begin{itemize} + \item + Nutzung dedizierter Verbindungen (Cut-Through-Mechanismen): + + \begin{itemize} + \item + Virtuelle Verbindungen über ATM oder Frame Relay + \item + Multi-Protokoll über ATM (MPOA) + \item + Multiprotokoll-Etiketten-Vermittlung (MPLS) + \item + Sicherheitsdienste für Link Layer VPNs können effizient im Link + Layer Protokoll realisiert werden; ein Beispiel ist die ATM Security + Specification {[}ATM99a{]} + \end{itemize} + \item + Kontrolliertes Routenleck / Routenfilterung: + + \begin{itemize} + \item + Grundidee: Kontrolle der Routenausbreitung dahingehend, dass nur + bestimmte Netze Routen für andere Netze erhalten + \item + Damit soll ,,security by obscurity'' realisiert werden (also kein + wirklicher Schutz!) + \end{itemize} + \item + Tunneln: + + \begin{itemize} + \item + Generische Routing-Kapselung (GRE) + \item + PPP / PPTP / L2TP + \item + IPSec-Sicherheitsarchitektur für das Internet-Protokoll + \end{itemize} + \end{itemize} + + + \section{Die IPsec-Architektur für das + Internet-Protokoll} + + + \subsection{Überblick} + + \begin{itemize} + \item + Kurze Einführung in das Internet-Protokoll (IP) + \item + Sicherheitsprobleme von IP und Ziele von IPsec + \item + Die IPsec-Architektur: + + \begin{itemize} + \item + Modi des IPsec-Sicherheitsprotokolls: + + \begin{itemize} + \item + Transportmodus + \item + Tunnel-Modus + \end{itemize} + \item + Alternativen zur Implementierung + \item + IP-Sicherheitsrichtlinien-Datenbank (SPD) + \item + Sicherheitsvereinigungen (SA) und die SA-Datenbank (SADB) + \end{itemize} + \item + IPsec Sicherheitsprotokolle: + + \begin{itemize} + \item + Authentifizierungs-Header (AH) + \item + Encapsulating Security Payload (ESP) + \end{itemize} + \item + Entitätsauthentifizierung und der Internet-Schlüsselaustausch (IKE) + \end{itemize} + + + \subsection{Die TCP/IP-Protokollsuite} + + \begin{itemize} + \item + IP (Internet Protocol): unzuverlässiges, verbindungsloses + Netzwerkprotokoll + \item + TCP (Transmission Control Protocol): zuverlässiges, + verbindungsorientiertes Transportprotokoll, realisiert über IP + \item + UDP (User Datagram Protocol): unzuverlässiges, verbindungsloses + Transportprotokoll, bietet eine Anwendungsschnittstelle zu IP + \item + Beispiele für Anwendungsprotokolle : + + \begin{itemize} + \item + HTTP: Hypertext-Übertragungsprotokoll + \item + SMTP: Einfaches Mail-Übertragungsprotokoll + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-tcp-ip-suite.png} + \end{itemize} + + + \subsection{Das IPv4-Paketformat} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ipv4-packet-format.png} + \item + Version (Ver.): 4 bit + + \begin{itemize} + \item + Derzeit ist Version 4 weit verbreitet + \item + Version 6 ist bereits spezifiziert, aber es ist noch nicht klar, ob + sie jemals zum Einsatz kommen wird + \end{itemize} + \item + IP-Header-Länge (IHL): 4 Bit + + \begin{itemize} + \item + Länge des IP-Headers in 32-Bit-Wörtern + \end{itemize} + \item + Art des Dienstes (TOS): 8 Bit + + \begin{itemize} + \item + Dieses Feld könnte verwendet werden, um die Verkehrsanforderungen + eines Pakets anzugeben. + \item + Jetzt: DCSP und Explicit Congestion (EC) Indication + \end{itemize} + \item + Länge: 16 Bit + + \begin{itemize} + \item + Die Länge des Pakets einschließlich des Headers in Oktetten + \item + Dieses Feld ist, wie alle anderen Felder in der IP-Suite, in ,,big + endian'' Darstellung + \end{itemize} + \item + Kennung: 16 Bit + + \begin{itemize} + \item + Dient der ,,eindeutigen'' Identifizierung eines IP-Datagramms + \item + Wichtig für das Wiederzusammensetzen von fragmentierten + IP-Datagrammen + \end{itemize} + \item + Flaggen: 3 Bit + + \begin{itemize} + \item + Bit 1: nicht fragmentieren + \item + Bit 2: Datagramm fragmentiert + \item + Bit 3: reserviert für zukünftige Verwendung + \end{itemize} + \item + Fragmentierungs-Offset: 13 Bit + + \begin{itemize} + \item + Die Position dieses Pakets im entsprechenden IP-Datagramm + \end{itemize} + \item + Lebenszeit (TTL): 8 Bit + + \begin{itemize} + \item + An jedem verarbeitenden Netzknoten wird dieses Feld um eins + dekrementiert + \item + Wenn die TTL 0 erreicht, wird das Paket verworfen, um Paketschleifen + zu vermeiden. + \end{itemize} + \item + Protokoll: 8 Bit + + \begin{itemize} + \item + Gibt das (Transport-)Protokoll der Nutzlast an + \item + Wird vom empfangenden Endsystem verwendet, um Pakete zwischen + verschiedenen Transportprotokollen wie TCP, UDP, ... zu + entmultiplexen. + \end{itemize} + \item + Prüfsumme: 16 Bit + + \begin{itemize} + \item + Schutz vor Übertragungsfehlern + \item + Da es sich nicht um eine kryptografische Prüfsumme handelt, kann sie + leicht gefälscht werden. + \end{itemize} + \item + Quelladresse: 32 Bit + + \begin{itemize} + \item + Die IP-Adresse des Absenders dieses Pakets + \end{itemize} + \item + Zieladresse: 32 Bit + + \begin{itemize} + \item + Die IP-Adresse des vorgesehenen Empfängers dieses Pakets + \end{itemize} + \item + IP-Optionen: variable Länge + + \begin{itemize} + \item + Ein IP-Header kann optional zusätzliche Informationen enthalten. + \item + Da sie nicht Bestandteil von IPsec sind, werden sie in diesem Kurs + nicht behandelt. + \end{itemize} + \end{itemize} + + + \subsection{Sicherheitsprobleme des + Internet-Protokolls} + + \begin{itemize} + \item + Wenn eine Einheit ein IP-Paket empfängt, hat sie keine Garantie für: + + \begin{itemize} + \item + Authentifizierung der Datenherkunft / Datenintegrität: + + \begin{itemize} + \item + Das Paket wurde tatsächlich von der Einrichtung gesendet, auf die + die Quelladresse des Pakets verweist. + \item + Das Paket enthält den ursprünglichen Inhalt des Absenders, so dass + es während des Transports nicht verändert worden ist. + \item + Die empfangende Einrichtung ist tatsächlich die Einrichtung, an + die der Absender das Paket senden wollte. + \end{itemize} + \item + Vertraulichkeit: + + \begin{itemize} + \item + Die ursprünglichen Daten wurden auf dem Weg vom Absender zum + Empfänger nicht von Dritten eingesehen. + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Sicherheitsziele von + IPsec} + + \begin{itemize} + \item + IPsec zielt darauf ab, die folgenden Sicherheitsziele zu + gewährleisten: + + \begin{itemize} + \item + Authentifizierung der Datenherkunft / Verbindungslose + Datenintegrität: + + \begin{itemize} + \item + Es ist nicht möglich, ein IP-Datagramm mit einer maskierten + IP-Quell- oder Zieladresse zu senden, ohne dass der Empfänger dies + erkennen kann. + \item + Es ist nicht möglich, ein IP-Datagramm während der Übertragung zu + verändern, ohne dass der Empfänger diese Veränderung feststellen + kann. + \item + Wiedergabeschutz: Es ist nicht möglich, ein aufgezeichnetes + IP-Paket zu einem späteren Zeitpunkt erneut abzuspielen, ohne dass + der Empfänger dies erkennen kann. + \end{itemize} + \item + Vertraulichkeit: + + \begin{itemize} + \item + Es ist nicht möglich, den Inhalt von IP-Datagrammen zu belauschen + \item + Begrenzte Vertraulichkeit des Verkehrsflusses + \end{itemize} + \end{itemize} + \item + Sicherheitspolitik: + + \begin{itemize} + \item + Sender, Empfänger und Zwischenknoten können den erforderlichen + Schutz für ein IP-Paket gemäß einer lokalen Sicherheitsrichtlinie + festlegen + \item + Zwischenknoten und der Empfänger verwerfen IP-Pakete, die diese + Anforderungen nicht erfüllen + \end{itemize} + \end{itemize} + + + \subsection{Überblick über die + IPsec-Standardisierung} + + % \includegraphics{Assets/NetworkSecurity-IPsec-standardization.png} + + + \subsection{Überblick über die + IPsec-Architektur} + + \begin{itemize} + \item + RFC 4301 definiert die grundlegende Architektur von IPsec: + + \begin{itemize} + \item + Konzepte: + + \begin{itemize} + \item + Sicherheitsvereinigung (SA), Sicherheitsvereinigungsdatenbank + (SADB) + \item + Sicherheitsrichtlinien, Sicherheitsrichtlinien-Datenbank (SPD) + \end{itemize} + \item + Grundlegende IPsec-Protokolle: + + \begin{itemize} + \item + Authentifizierungs-Header (AH) + \item + Encapsulating Security Payload (ESP) + \end{itemize} + \item + Protokoll-Modi: + + \begin{itemize} + \item + Transport-Modus + \item + Tunnel-Modus + \end{itemize} + \item + Schlüsselmanagement-Verfahren: + + \begin{itemize} + \item + IKE \& IKEv + \end{itemize} + \end{itemize} + \item + RFC 4301 definiert die grundlegende Architektur von IPsec: + + \begin{itemize} + \item + Verwendung von verschiedenen kryptographischen Primitiven mit AH und + ESP: + + \begin{itemize} + \item + Verschlüsselung: 3DES-CBC, AES und andere + CBC-Verschlüsselungsalgorithmen, AES-Zählermodus + \item + Integrität: HMAC-MD5, HMAC-SHA-1, HMAC-SHA-2, HMAC- RIPEMD-160, + AES-GMAC, AES-CMAC, AES-XCBC... + \item + Authentifizierte Verschlüsselung: GCM und "Zähler mit CBC-MAC" + (CCM), beide für AES definiert + \end{itemize} + \end{itemize} + \item + Eine Sicherheitsassoziation (SA) ist eine Simplex- ,,Verbindung'', die + Sicherheitsdienste für den von ihr beförderten Verkehr bereitstellt. + + \begin{itemize} + \item + Sicherheitsdienste werden für eine SA entweder mit AH oder ESP + bereitgestellt, jedoch nicht mit beiden. + \item + Für bidirektionale Kommunikation sind zwei Sicherheitsverbindungen + erforderlich. + \item + Eine SA wird eindeutig durch ein Tripel identifiziert, das aus einem + Sicherheitsparameterindex (SPI), einer IP-Zieladresse und einer + Sicherheitsprotokollkennung (AH / ESP) besteht. + \item + Eine SA kann zwischen den folgenden Gegenstellen eingerichtet + werden: + + \begin{itemize} + \item + Host \$\textbackslash leftrightarrow\$ Host + \item + Host \$\textbackslash leftrightarrow\$ Gateway (oder andersherum) + \item + Gateway \$\textbackslash leftrightarrow\$ Gateway + \end{itemize} + \item + Es gibt zwei konzeptionelle Datenbanken, die mit SAs verbunden sind: + + \begin{itemize} + \item + Die Sicherheitsrichtliniendatenbank (SPD) legt fest, welche + Sicherheitsdienste für welche IP-Pakete auf welche Weise + bereitgestellt werden sollen. + \item + Die Sicherheitsassoziationsdatenbank (SADB) + \end{itemize} + \end{itemize} + \item + Protokollmodi - Eine SA ist immer von einem der folgenden Typen: + + \begin{itemize} + \item + Der Transportmodus kann nur zwischen den Endpunkten einer + Kommunikation verwendet werden: + + \begin{itemize} + \item + host \$\textbackslash leftrightarrow\$ host, oder + \item + Host \$\textbackslash leftrightarrow\$-Gateway, wenn das Gateway + ein Kommunikationsendpunkt ist (z. B. für die Netzverwaltung) + \end{itemize} + \item + Der Tunnelmodus kann für beliebige Peers verwendet werden. + \end{itemize} + \item + Der Unterschied zwischen den beiden Modi ist, dass: + + \begin{itemize} + \item + Im Transportmodus wird lediglich ein sicherheitsspezifischer Header + (+ eventueller Trailer) hinzugefügt: + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ipsec-transport-mode.png} + \end{itemize} + \item + Der Tunnelmodus kapselt IP-Pakete ein: Die Verkapselung von + IP-Paketen ermöglicht es einem Gateway, den Verkehr im Namen anderer + Entitäten zu schützen (z. B. Hosts eines Subnetzes usw.) + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ipsec-tunnel-mode.png} + \end{itemize} + \end{itemize} + \item + Der Authentifizierungs-Header (AH): + + \begin{itemize} + \item + Bietet Authentifizierung der Datenherkunft und Schutz vor + Wiederholung + \item + Wird als Header realisiert, der zwischen dem IP-Header und den zu + schützenden Daten eingefügt wird + \item + % \includegraphics{Assets/NetworkSecurity-ipsec-AH.png} + \end{itemize} + \item + Die einkapselnde Sicherheitsnutzlast (ESP): + + \begin{itemize} + \item + Bietet Authentifizierung der Datenherkunft, Vertraulichkeit und + Schutz vor Wiederholung + \item + Wird mit einem Header und einem Trailer realisiert, der die zu + schützenden Daten einkapselt + \item + % \includegraphics{Assets/NetworkSecurity-ipsec-ESP.png} + \end{itemize} + \item + Die Einrichtung von Sicherheitsvereinigungen wird mit: + + \begin{itemize} + \item + Internet Security Association Key Management Protocol (ISAKMP): + + \begin{itemize} + \item + Definiert einen generischen Rahmen für die + Schlüsselauthentifizierung, den Schlüsselaustausch und die + Aushandlung von Sicherheitsassoziationsparametern {[}RFC2408{]}. + \item + Definiert kein spezifisches Authentifizierungsprotokoll, aber + spezifiziert: + + \begin{itemize} + \item + Paketformate + \item + Zeitgeber für die Weiterleitung + \item + Anforderungen an den Nachrichtenaufbau + \end{itemize} + \item + Die Verwendung von ISAKMP für IPsec wird in {[}RFC2407{]} näher + beschrieben. + \end{itemize} + \item + Internet-Schlüsselaustausch (IKE): + + \begin{itemize} + \item + Definiert ein Authentifizierungs- und Schlüsselaustauschprotokoll + {[}RFC2409{]}. + \item + Ist konform zu ISAKMP und kann für verschiedene Anwendungen + verwendet werden + \item + Der Aufbau von IPsec SAs zwischen zwei Entitäten wird in zwei + Phasen realisiert: + + \begin{itemize} + \item + Einrichtung einer IKE SA (definiert, wie man IPsec SAs + einrichtet) + \item + Einrichtung von IPsec SAs + \end{itemize} + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{IPsec-Wiedergabeschutz (Replay + protection)} + + \begin{itemize} + \item + Sowohl AH- als auch ESP-geschützte IP-Pakete tragen eine + Sequenznummer, die einen Wiedergabeschutz realisiert: + + \begin{itemize} + \item + Beim Einrichten einer SA wird diese Sequenznummer auf Null + initialisiert. + \item + Die Sequenznummer wird mit jedem gesendeten IP-Paket erhöht + \item + Die Sequenznummer ist 32 Bit lang, es wird ein neuer + Sitzungsschlüssel benötigt, bevor ein Wrap-around erfolgt + \item + Der Empfänger eines IP-Pakets prüft, ob die Sequenznummer in einem + Fenster zulässiger Nummern enthalten ist + \item + % \includegraphics{Assets/NetworkSecurity-ipsec-replay-protection.png} + + \begin{itemize} + \item + (Paket mit Sequenznummer N kann noch akzeptiert werden) + \end{itemize} + \end{itemize} + \item + Wenn ein empfangenes Paket eine Sequenznummer hat, die: + + \begin{itemize} + \item + links vom aktuellen Fenster \$\textbackslash Rightarrow\$ liegt, + lehnt der Empfänger das Paket ab + \item + innerhalb des aktuellen Fensters \$\textbackslash Rightarrow\$ + liegt, nimmt der Empfänger das Paket an + \item + liegt rechts vom aktuellen Fenster \$\textbackslash Rightarrow\$ der + Empfänger nimmt das Paket an und schiebt das Fenster weiter + \item + Natürlich werden IP-Pakete nur akzeptiert, wenn sie die + Authentifizierungsprüfung bestehen und das Fenster wird niemals vor + dieser Prüfung weitergeschaltet + \end{itemize} + \item + Die minimale Fenstergröße beträgt 32 Pakete (64 Pakete werden + empfohlen) + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ipsec-replay-protection2.png} + + \begin{itemize} + \item + Paket mit Sequenznummer N kann nicht mehr akzeptiert werden + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{IPsec-Implementierungsalternativen: + Host-Implementierung} + + \begin{itemize} + \item + Vorteile der IPsec-Implementierung in Endsystemen: + + \begin{itemize} + \item + Bereitstellung von End-to-End-Sicherheitsdiensten + \item + Bereitstellung von Sicherheitsdiensten auf einer Per-Flow-Basis + \item + Fähigkeit, alle IPsec-Modi zu implementieren + \end{itemize} + \item + Zwei Hauptalternativen zur Integration: \textbar{} Integriertes + Betriebssystem \textbar{} ,,Bump'' im Stack \textbar{} \textbar{} + -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- + \textbar{} + -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- + \textbar{} \textbar{} Anwendung \textbar{} Anwendung \textbar{} + \textbar{} Transport \textbar{} Transport \textbar{} \textbar{} + Netzwerk + IPsec \textbar{} Netzwerk \textbar{} \textbar{} IPsec + \textbar{} \textbar{} Data Link \textbar{} Data Link \textbar{} + \textbar{} \textbar{} \textbar{} Echte Betriebssystemintegration ist + die Methode der Wahl, da sie die Duplizierung von Funktionalität + vermeidet \textbar{} Wenn das Betriebssystem nicht geändert werden + kann, wird IPsec über den Datenverbindungstreiber eingefügt \textbar{} + \end{itemize} + + + \subsection{IPsec-Implementierungsalternativen: + Router-Implementierung} + + \begin{itemize} + \item + Vorteile der IPsec-Implementierung in Routern: + + \begin{itemize} + \item + Möglichkeit, IP-Pakete zu sichern, die zwischen zwei Netzen über ein + öffentliches Netz wie das Internet fließen: + + \begin{itemize} + \item + Ermöglicht die Einrichtung virtueller privater Netzwerke (VPNs) + \item + Keine Notwendigkeit, IPsec in jedes Endsystem zu integrieren + \end{itemize} + \item + Fähigkeit zur Authentifizierung und Autorisierung des IP-Verkehrs, + der von entfernten Benutzern eingeht + \end{itemize} + \item + Zwei Hauptalternativen für die Implementierung: + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ipsec-router-implementation.png} + \end{itemize} + \end{itemize} + + + \subsection{Wann sollte welcher IPsec-Modus verwendet + werden?} + + \begin{itemize} + \item + In den meisten Fällen handelt es sich bei den Kommunikationsendpunkten + um Hosts (Workstations, Server), aber das ist nicht unbedingt der + Fall: + + \begin{itemize} + \item + Beispiel: ein Gateway wird über SNMP von einer Workstation verwaltet + \end{itemize} + \item + Der Transportmodus wird verwendet, wenn die ,,kryptografischen + Endpunkte'' auch die ,,Kommunikationsendpunkte'' der gesicherten + IP-Pakete sind + + \begin{itemize} + \item + Kryptografische Endpunkte: die Entitäten, die einen IPsec-Header (AH + oder ESP) erzeugen/verarbeiten + \item + Kommunikationsendpunkte: Quelle und Ziel eines IP-Pakets + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-communication-endpoints.png} + \end{itemize} + \end{itemize} + \item + Der Tunnelmodus wird verwendet, wenn mindestens ein + ,,kryptographischer Endpunkt'' nicht ein ,,Kommunikationsendpunkt'' + der gesicherten IP-Pakete ist + + \begin{itemize} + \item + Dies ermöglicht Gateways, die den IP-Verkehr im Namen anderer + Stellen sichern + \item + % \includegraphics{Assets/NetworkSecurity-communication-tunneling.png} + \end{itemize} + \item + Die obige Beschreibung der Anwendungsszenarien für den Tunnelmodus + umfasst auch den Fall, dass nur ein kryptografischer Endpunkt kein + Kommunikationsendpunkt ist: + + \begin{itemize} + \item + Beispiel: ein Sicherheitsgateway, das die Authentifizierung und/oder + die Vertraulichkeit des IP-Verkehrs zwischen einem lokalen Teilnetz + und einem über das Internet verbundenen Host sicherstellt (,,Road + Warrior Szenario'') + \item + % \includegraphics{Assets/NetworkSecurity-communication-tunnelung-2.png} + \end{itemize} + \end{itemize} + + + \subsection{Verschachtelung von + Sicherheitsassoziationen} + + \begin{itemize} + \item + Sicherheitsassoziationen können verschachtelt werden: + + \begin{itemize} + \item + Beispiel: Host A und Gateway RB führen eine Authentifizierung der + Datenherkunft durch und die Gateways RA und RB führen eine + Vertraulichkeit von Subnetz zu Subnetz durch + \item + % \includegraphics{Assets/NetworkSecurity-communication-nesting.png} + \end{itemize} + \item + Bei der Verschachtelung von SAs muss jedoch darauf geachtet werden, + dass keine ,,falsche Klammerung'' von SAs erfolgt, wie z. B. + ,,{[}({]})'' + + \begin{itemize} + \item + Ein Beispiel für eine gültige SA-Schachtelung: + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-communication-nesting-2.png} + \end{itemize} + \item + Ein Beispiel für ungültige SA-Schachtelungen: + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-communication-nesting-3.png} + \item + Da das Paket von RB nach RD getunnelt wird, kann das Gateway RC + den inneren IPsec-Header nicht verarbeiten + \item + Ein mögliches Ergebnis dieser fehlerhaften Konfiguration könnte + sein, dass das Paket zurück nach RC geroutet wird + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Grundschema der IPsec-Verarbeitung: Ausgehende + Pakete} + + \begin{itemize} + \item + Nehmen wir an, die IP-Schicht eines Knotens (Host/Gateway) wird + angewiesen, ein IP-Paket an einen anderen Knoten (Host/Gateway) zu + senden + \item + Um IPsec zu unterstützen, muss sie die folgenden Schritte durchführen: + + \begin{itemize} + \item + Feststellen, ob und wie das ausgehende Paket gesichert werden muss: + + \begin{itemize} + \item + Dies wird durch einen Lookup im SPD realisiert + \item + Wenn die Richtlinie ,,verwerfen'' vorschreibt, wird das Paket + verworfen \$\textbackslash Rightarrow\$ done + \item + Wenn das Paket nicht gesichert werden muss, dann sende es + \$\textbackslash Rightarrow\$ done + \end{itemize} + \item + Ermitteln, welche SA auf das Paket angewendet werden soll: + + \begin{itemize} + \item + Wenn es noch keine passende SA mit dem entsprechenden Knoten gibt, + dann fordere den Key Management Demon auf, einen IKE durchzuführen + \end{itemize} + \item + Die ermittelte (und eventuell neu erstellte) SA in der SADB + nachschlagen + \item + Führen Sie die von der SA festgelegte Sicherheitstransformation + durch, indem Sie den Algorithmus, seine Parameter und den Schlüssel, + wie in der SA angegeben, verwenden. + + \begin{itemize} + \item + Dies resultiert in der Konstruktion eines AH- oder ESP-Headers + \item + Eventuell wird auch ein neuer (äußerer) IP-Header erstellt + (Tunnelmodus) + \end{itemize} + \item + Senden Sie das resultierende IP-Paket \$\textbackslash Rightarrow\$ + done + \end{itemize} + \end{itemize} + + + \subsection{Grundschema der IPsec-Verarbeitung: Eingehende + Pakete} + + \begin{itemize} + \item + Nehmen wir an, die IP-Schicht eines Knotens (Host/Gateway) empfängt + ein IP-Paket von einem anderen Knoten (Host/Gateway) + \item + Um IPsec zu unterstützen, muss sie die folgenden Schritte durchführen: + + \begin{itemize} + \item + Feststellen, ob das Paket einen IPsec-Header enthält, den diese + Einheit verarbeiten soll: + + \begin{itemize} + \item + Wenn es einen solchen IPsec-Header gibt, dann suchen Sie die SA in + der SADB, die durch den SPI des IPsec-Headers spezifiziert ist, + und führen Sie die entsprechende IPsec-Verarbeitung durch + \item + Wenn die SA, auf die der SPI verweist, (noch) nicht existiert, + verwerfen Sie das Paket + \end{itemize} + \item + Ermitteln, ob und wie das Paket hätte geschützt werden sollen: + + \begin{itemize} + \item + Dies wird wiederum durch einen Lookup im SPD realisiert, wobei der + Lookup im Falle von getunnelten Paketen durch Auswertung des + inneren IP-Headers durchgeführt wird + \item + Wenn die Richtlinie ,,Verwerfen'' vorschreibt, wird das Paket + verworfen. + \item + Wenn der Schutz des Pakets nicht mit der Richtlinie übereinstimmt, + wird das Paket verworfen. + \item + Wenn das Paket ordnungsgemäß gesichert wurde, dann übergebe es an + die entsprechende Protokollinstanz (Netzwerk-/Transportschicht) + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Auswahl der + IPsec-Sicherheitspolitik} + + Die folgenden Selektoren, die aus den Headern der Netzwerk- und + Transportschicht extrahiert werden, ermöglichen die Auswahl einer + bestimmten Richtlinie im SPD: + + \begin{itemize} + \item + IP-Quelladresse: + + \begin{itemize} + \item + Bestimmter Host, Netzwerkpräfix, Adressbereich oder Platzhalter + \end{itemize} + \item + IP-Zieladresse: + + \begin{itemize} + \item + Bestimmter Host, Netzwerk-Präfix, Adressbereich oder Platzhalter + \item + Im Falle eingehender getunnelter Pakete wird der innere Header + ausgewertet + \end{itemize} + \item + Protokoll: + + \begin{itemize} + \item + Der Protokoll-Identifikator des Transportprotokolls für dieses Paket + \item + Dies ist möglicherweise nicht zugänglich, wenn ein Paket mit ESP + gesichert ist. + \end{itemize} + \item + Ports der oberen Schicht: + + \begin{itemize} + \item + Falls zugänglich, die Ports der oberen Schicht für die + sitzungsorientierte Policy-Auswahl + \end{itemize} + \end{itemize} + + + \subsection{IPsec Security Policy + Definition} + + \begin{itemize} + \item + Policy Selectors werden verwendet, um spezifische Policy-Definitionen + auszuwählen, spezifiziert: + + \begin{itemize} + \item + Wie die Einrichtung einer IKE SA zwischen zwei Knoten durchgeführt + werden soll: + + \begin{itemize} + \item + Identifizierung: DNS-Name oder andere Namenstypen, wie in der + IPsec-Domäne der Interpretation eines Protokolls zur Einrichtung + von SAs definiert + \item + Phase I-Modus: Hauptmodus oder aggressiver Modus (siehe unten) + \item + Schutzsuite(n): Angabe, wie die IKE-Authentifizierung durchgeführt + wird + \end{itemize} + \item + Welche und wie Sicherheitsdienste für IP-Pakete bereitgestellt + werden sollen: + + \begin{itemize} + \item + Selektoren, die bestimmte Flüsse identifizieren + \item + Sicherheitsattribute für jeden Fluss: + + \begin{itemize} + \item + Sicherheitsprotokoll: AH oder ESP + \item + Protokollmodus: Transport- oder Tunnelmodus + \item + Sicherheitstransformationen: kryptografische Algorithmen und + Parameter + \item + Andere Parameter: SA-Lebensdauer, Replay-Fenster + \end{itemize} + \item + Aktion: Verwerfen, Sichern, Umgehen + \end{itemize} + \end{itemize} + \item + Wenn bereits eine SA mit einem entsprechenden Sicherheitsendpunkt + eingerichtet ist, wird im SPD auf diese verwiesen. + \end{itemize} + + + \subsection{Die Encapsulating Security + Payload} + + \begin{itemize} + \item + ESP ist ein allgemeines Sicherheitsprotokoll, das IP-Paketen einen + Wiederholungsschutz und einen oder beide der folgenden + Sicherheitsdienste bietet: + + \begin{itemize} + \item + Vertraulichkeit durch Verschlüsselung der eingekapselten Pakete oder + nur ihrer Nutzlast + \item + Authentifizierung der Datenherkunft durch Erstellung und Hinzufügung + von MACs zu Paketen + \end{itemize} + \item + Die ESP-Definition gliedert sich in zwei Teile: + + \begin{itemize} + \item + Die Definition des Basisprotokolls {[}RFC4303{]}: + + \begin{itemize} + \item + Definition des Header- und Trailer-Formats + \item + Verarbeitung des Basisprotokolls + \item + Tunnel- und Transportmodusbetrieb + \end{itemize} + \item + Die Verwendung spezifischer kryptographischer Algorithmen mit ESP: + + \begin{itemize} + \item + Verschlüsselung: 3DES-CBC, AES-CBC, AES-Zählmodus, Verwendung + anderer Chiffren im CBC-Modus + \item + Authentifizierung: HMAC-MD5-96, HMAC-SHA-96,... + \end{itemize} + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ESP.png} + + \begin{itemize} + \item + Der ESP-Header folgt unmittelbar auf einen IP-Header oder einen + AH-Header + \item + Das Next-Header-Feld des vorangehenden Headers zeigt ,,50'' für ESP + an + \item + Das SPI-Feld gibt die SA an, die für dieses Paket verwendet werden + soll: + + \begin{itemize} + \item + Der SPI-Wert wird immer von der empfangenden Seite während der + SA-Aushandlung bestimmt, da der Empfänger das Paket verarbeiten + muss. + \end{itemize} + \item + Die Sequenznummer bietet, wie bereits erläutert, Schutz vor + Wiederholung. + \item + Wenn der verwendete kryptographische Algorithmus einen + Initialisierungsvektor benötigt, wird dieser in jedem Paket am + Anfang der Nutzlast im Klartext übertragen + \item + Das Pad-Feld dient der Sicherstellung: + + \begin{itemize} + \item + Auffüllen der Nutzlast bis zur erforderlichen Blocklänge der + verwendeten Chiffre + \item + Auffüllen der Nutzlast, um die Felder pad-length und next-header + rechtsbündig in die höherwertigen 16 Bit eines 32-Bit-Wortes + einzupassen + \end{itemize} + \item + Die Auffülllänge gibt die Anzahl der hinzugefügten Auffüllbytes an. + \item + Das next-header-Feld des ESP-Headers gibt die eingekapselte Nutzlast + an: + + \begin{itemize} + \item + Im Falle des Tunnelmodus: IP + \item + Im Falle des Transportmodus: ein beliebiges Protokoll der höheren + Schicht wie TCP, UDP, ... + \end{itemize} + \item + Das optionale Feld authentication-data enthält eine MAC, falls + vorhanden + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ESP-processing.png} + \item + % \includegraphics{Assets/NetworkSecurity-ESP-prepare-header.png} + \item + % \includegraphics{Assets/NetworkSecurity-ESP-inbound-processing.png} + \item + % \includegraphics{Assets/NetworkSecurity-ESP-inbound-processing-2.png} + \item + Beachten Sie, dass das entkapselte IP-Paket ein fragmentiertes Paket + sein kann: + + \begin{itemize} + \item + Dies kann vorkommen, wenn ESP von einem Router im Tunnelmodus + angewendet wurde. + \item + Um die Konformität mit der SA-Policy korrekt zu prüfen, müssen alle + zu diesem Paket gehörenden Fragmente vom Router empfangen werden, + bevor die Prüfung durchgeführt werden kann + \item + Beispiel: In einer SA sind nur Pakete an einen bestimmten Port + erlaubt + + \begin{itemize} + \item + Die erforderliche Port-Information ist nur im ersten Fragment des + IP-Pakets vorhanden + \end{itemize} + \end{itemize} + \item + Paketzustellung bedeutet Zustellung an die entsprechende + Verarbeitungseinheit: + + \begin{itemize} + \item + Wenn ein anderer IPsec-Header für diese Entität vorhanden ist + \$\textbackslash Rightarrow\$ IPsec-Verarbeitung + \item + Im Tunnelmodus \$\textbackslash Rightarrow\$ Übermittlung des Pakets + \item + Im Transportmodus \$\textbackslash Rightarrow\$ Aufruf des + entsprechenden Protokoll-Headers (TCP, UDP, etc.) + \end{itemize} + \item + Wenn ESP sowohl Vertraulichkeit als auch Authentifizierung bietet, + können für beide Dienste unterschiedliche Schlüssel verwendet werden. + + \begin{itemize} + \item + Dies muss während der Einrichtung der ESP-SA ausgehandelt werden. + \end{itemize} + \item + Beachten Sie, dass die Verwendung von ESP ohne Authentifizierung + unsicher ist... + + \begin{itemize} + \item + Kein zuverlässiger Schutz vor Wiederholungen + \item + Zumindest, wenn im CBC-Modus verwendet: + + \begin{itemize} + \item + Aktive Angriffe ermöglichen die Wiederherstellung von Nachrichten + \item + Beispiel: Bits umdrehen und prüfen, ob Fehlermeldungen erzeugt + werden + \item + Vollständige Wiederherstellung von Klartextblöcken + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Der + Authentifizierungs-Header} + + \begin{itemize} + \item + AH ist ein allgemeines Sicherheitsprotokoll, das IP-Paketen Schutz + bietet: + + \begin{itemize} + \item + Wiedergabeschutz + \item + Authentifizierung der Datenherkunft durch Erstellung und Hinzufügung + von MACs zu den Paketen + \end{itemize} + \item + Wie bei ESP ist die AH-Definition in zwei Teile aufgeteilt: + + \begin{itemize} + \item + Die Definition des Basisprotokolls {[}RFC4302{]}: + + \begin{itemize} + \item + Definition des Header-Formats + \item + Verarbeitung des Basisprotokolls + \item + Tunnel- und Transportmodusbetrieb + \end{itemize} + \item + Die Verwendung spezifischer kryptographischer Algorithmen bei AH: + + \begin{itemize} + \item + Authentifizierung: HMAC-MD5-96, HMAC-SHA1-96, HMAC-SHA2, ... + \item + Wenn sowohl ESP als auch AH von einer Stelle angewendet werden + sollen, wird immer zuerst ESP angewendet: + \end{itemize} + \item + Dies führt dazu, dass AH der äußere Header ist. + \item + ,,Vorteil'': der IP-Header kann auch durch AH geschützt werden + \item + Anmerkung: Für jede Richtung werden zwei SAs (je eine für AH, ESP) + benötigt. + \end{itemize} + \item + Im Tunnelmodus stellt die Nutzlast ein vollständiges IP-Paket dar + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-authentication-header.png} + \end{itemize} + \item + Obwohl AH auch den äußeren IP-Header schützt, dürfen einige seiner + Felder nicht geschützt werden, da sie sich während der Übertragung + ändern können: + + \begin{itemize} + \item + Dies gilt auch für veränderliche IPv4-Optionen oder + IPv6-Erweiterungen. + \item + Solche Felder werden bei der Berechnung des MAC als Null angenommen + \item + % \includegraphics{Assets/NetworkSecurity-authentication-header-2.png} + \end{itemize} + \item + Alle unveränderlichen Felder, Optionen und Erweiterungen (grau) sind + geschützt + \item + % \includegraphics{Assets/NetworkSecurity-AH-Ausgangsbearbeitung.png} + \item + % \includegraphics{Assets/NetworkSecurity-AH-prepare-header.png} + \item + % \includegraphics{Assets/NetworkSecurity-AH-inbound-processing-1.png} + \item + % \includegraphics{Assets/NetworkSecurity-AH-inbound-processing-2.png} + \end{itemize} + + + \subsection{IPsec's Verwendung von kryptographischen + Algorithmen} + + \begin{itemize} + \item + Vertraulichkeit (nur ESP): + + \begin{itemize} + \item + Die Verwendung von DES mit ESP {[}RFC4303{]} wird nicht mehr + empfohlen + \item + AES-CBC, definiert in RFC 3602, ist vielleicht "der" + Standardalgorithmus + \item + Der Initialisierungsvektor (IV) ist immer im Klartext enthalten, um + Synchronisationsprobleme zu vermeiden. + \item + Der gesamte IV soll zufällig sein + \item + Nehmen Sie KEINE weiteren IVs aus früheren Chiffretexten! + + \begin{itemize} + \item + Sicherheitsprobleme + \item + Synchronisationsprobleme + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ipsec-protect-payload.png} + \end{itemize} + \item + Authentifizierung der Datenherkunft (AH und ESP): + + \begin{itemize} + \item + Einige der Algorithmen zur Authentifizierung sind bereits definiert: + + \begin{itemize} + \item + HMAC-MD5-96 mit Schlüssellänge 128 Bit + \item + HMAC-SHA1-96 mit Schlüssellänge 160 Bit + \item + HMAC-RIPEMD160-96 mit einer Schlüssellänge von 160 Bit + \item + HMAC-SHA2 mit Schlüssellängen von 256, 384 und 512 Bit + \end{itemize} + \item + Alle diese Algorithmen verwenden die in {[}RFC2104{]} definierte + HMAC-Konstruktion: + + \begin{itemize} + \item + ipad = 0x36 wiederholt B mal (B = 64 für die oben genannten + Algorithmen) + \item + opad = 0x5C, B-mal wiederholt + \item + HMAC = H(Key XOR opad, H(Key XOR ipad, data)), wobei H die + verwendete kryptografische Hash-Funktion angibt + \end{itemize} + \item + Das ,,-96'' in den oben genannten Algorithmen bedeutet, dass die + Ausgabe der Hash-Funktion auf die 96 ganz linken Bits gekürzt wird + \item + SHA2 abgeschnitten auf die Hälfte der Schlüssellänge + \item + Dieser Wert erfüllt die meisten Sicherheitsanforderungen gut + \end{itemize} + \end{itemize} + + + \subsection{Aufbau von + Sicherheitsassoziationen} + + \begin{itemize} + \item + Bevor ein Paket durch IPsec geschützt werden kann, muss eine SA + zwischen den beiden ,,kryptographischen Endpunkten'', die den Schutz + bieten, eingerichtet werden + \item + Der Aufbau einer SA kann realisiert werden: + + \begin{itemize} + \item + Manuell, durch proprietäre Methoden der Systemverwaltung + \item + Dynamisch, durch ein standardisiertes Authentifizierungs- und + Schlüsselverwaltungsprotokoll + \item + Die manuelle Einrichtung sollte nur in sehr eingeschränkten + Konfigurationen (z.B. zwischen zwei verschlüsselnden Firewalls eines + VPN) und während einer Übergangsphase verwendet werden + \end{itemize} + \item + IPsec definiert eine standardisierte Methode für den SA-Aufbau: + + \begin{itemize} + \item + Internet Security Association and Key Management Protocol (ISAKMP) + + \begin{itemize} + \item + Definiert Protokollformate und Verfahren für die + Sicherheitsaushandlung + \end{itemize} + \item + Internet-Schlüsselaustausch (IKE) + + \begin{itemize} + \item + Definiert das Standard-Authentifizierungs- und + Schlüsselaustauschprotokoll von IPsec + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{ISAKMP - Einführung} + + \begin{itemize} + \item + Die IETF hat zwei RFCs zu ISAKMP für IPsec verabschiedet: + + \begin{itemize} + \item + RFC 2408, der das ISAKMP-Basisprotokoll definiert + \item + RFC 2407, der die ,,domain of interpretation'' (DOI) von IPsec für + ISAKMP definiert und die für IPsec spezifischen Nachrichtenformate + näher beschreibt + \end{itemize} + \item + Das ISAKMP-Basisprotokoll ist ein generisches Protokoll, das für + verschiedene Zwecke verwendet werden kann: + + \begin{itemize} + \item + Die für eine Anwendung von ISAKMP spezifischen Verfahren werden in + einem DOI-Dokument detailliert beschrieben. + \item + Es wurden weitere DOI-Dokumente erstellt: + + \begin{itemize} + \item + Group DOI für sichere Gruppenkommunikation {[}RFC6407{]} + \item + MAP DOI für die Verwendung von ISAKMP zum Aufbau von SAs zur + Sicherung des Mobile Application Protocol (MAP) von GSM (Internet + Draft, Nov. 2000) + \end{itemize} + \end{itemize} + \item + ISAKMP definiert zwei grundlegende Kategorien von Austauschvorgängen: + + \begin{itemize} + \item + Phase 1 Austausch, bei dem eine Art von ,,Master SA'' ausgehandelt + wird + \item + Phase 2 Austausch, der die ,,Master SA'' verwendet, um andere SAs zu + etablieren + \end{itemize} + \end{itemize} + + + \subsubsection{ISAKMP - Grundlegendes + Nachrichtenformat} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ISAKMP-format.png} + \item + Initiator \& Responder Cookie: + + \begin{itemize} + \item + Identifizieren einen ISAKMP-Austausch bzw. eine + Sicherheitsassoziation + \item + Dienen auch als begrenzter Schutz gegen Denial-of-Service-Angriffe + (siehe unten) + \end{itemize} + \item + Nächste Nutzlast: gibt an, welcher ISAKMP-Nutzlasttyp die erste + Nutzlast der Nachricht ist + \item + Major \& Minor Version: gibt die Version des ISAKMP-Protokolls an + \item + Austausch-Typ: + + \begin{itemize} + \item + Gibt die Art des verwendeten Austauschs an + \item + Es gibt fünf vordefinierte generische Austauschtypen, weitere Typen + können pro DOI definiert werden + \end{itemize} + \item + Flags: + + \begin{itemize} + \item + Encrypt: wenn auf eins gesetzt, wird die Nutzlast nach dem Header + verschlüsselt + \item + Commit: wird für die Schlüsselsynchronisation verwendet + \item + Authenticate only: wenn auf eins gesetzt, wird nur der Schutz der + Datenursprungsauthentifizierung auf die ISAKMP-Nutzdaten angewendet + und keine Verschlüsselung durchgeführt + \end{itemize} + \item + Nachrichten-ID: + + \begin{itemize} + \item + Dient zur Identifizierung von Nachrichten, die zu verschiedenen + Austauschen gehören + \end{itemize} + \item + Nachrichtenlänge: + + \begin{itemize} + \item + Gesamtlänge der Nachricht (Header + Payload) + \end{itemize} + \item + Nutzlast: + + \begin{itemize} + \item + Die Nutzlast einer ISAKMP-Nachricht kann tatsächlich mehrere + ,,verkettete'' Nutzlasten enthalten + \item + Der Nutzlasttyp der ersten Nutzlast in der Nachricht wird im + nächsten Nutzlastfeld des ISAKMP-Headers angegeben + \item + Alle ISAKMP-Nutzdaten haben einen gemeinsamen Nutzdaten-Header: + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ISAKMP-payload.png} + \item + Next Header: der Payload-Typ des nächsten Payloads in der + Nachricht + \item + Payload Length: Gesamtlänge der aktuellen Payload (einschließlich + dieses Headers) + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsubsection{ISAKMP - Begrenzter Schutz vor Denial of + Service} + + \begin{itemize} + \item + Die Initiator- und Responder-Cookies dienen auch als Schutz gegen + einfache Denial-of-Service-Angriffe: + + \begin{itemize} + \item + Authentifizierung und Schlüsselaustausch erfordern oft ,,teure'' + Berechnungen, z.B. Potenzierung (für Diffie-Hellman + Schlüsselaustausch) + \item + Um zu verhindern, dass ein Angreifer eine ISAKMP-Einheit mit + gefälschten Nachrichten von gefälschten Quelladressen überschwemmen + und diese teuren Operationen verursachen kann, wird das folgende + Schema verwendet: + + \begin{itemize} + \item + Die initiierende ISAKMP-Entität erzeugt einen Initiator-Cookie: + \$CKY-I = H(Secret\_\{Initiator\}, Address\_\{Responder\}, + t\_\{Initiator\})\$ + \item + Der Responder generiert sein eigenes Cookie: \$CKY-R = + H(Secret\_\{Responder\}, Address\_\{Initiator\}, + t\_\{Responder\})\$ + \item + Beide Entitäten schließen immer beide Cookies ein und überprüfen + immer ihr eigenes Cookie, bevor sie eine teure Operation + durchführen + \item + Der oben erwähnte Angriff wird daher nicht erfolgreich sein, da + der Angreifer eine Antwort von dem angegriffenen System erhalten + muss, um ein Cookie von ihm zu erhalten + \end{itemize} + \item + ISAKMP spezifiziert die genaue Cookie-Erzeugungsmethode nicht + \end{itemize} + \end{itemize} + + + \subsubsection{ISAKMP - Nutzdatenarten} + + \begin{itemize} + \item + RFC 2408 definiert verschiedene Nutzdaten von ISAKMP (Liste ist nicht + vollständig): + + \begin{itemize} + \item + Generische Payloads: Hash, Signatur, Nonce, Vendor ID, + Schlüsselaustausch + \item + Spezifische Payloads: SA, Zertifikat, Zertifikatsanforderung, + Identifikation + \item + Abhängige und gekapselte Nutzdaten: + + \begin{itemize} + \item + Proposal-Payload: beschreibt einen Vorschlag für die + SA-Verhandlung + \item + Transform-Payload: beschreibt eine Transformation eines Proposals + \end{itemize} + \item + Außerdem gibt es eine generische Attribut-Nutzlast: + + \begin{itemize} + \item + Dies ist eigentlich kein ISAKMP-Payload, sondern ein Payload, der + innerhalb der ISAKMP-Payloads erscheint. + \item + Alle Attribut-Payloads haben eine gemeinsame Struktur: + \item + % \includegraphics{Assets/NetworkSecurity-ISAKMP-payload-types.png} + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsubsection{ISAKMP - Die + Sicherheits-Assoziations-Nutzdaten} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ISAKMP-security-payload.png} + \item + Domain of Interpretation definiert die Anwendungsdomäne für die + auszuhandelnde SA, z.B. IPsec + \item + Situation ist ein DOI-spezifisches Feld, das die Situation angibt, in + der die aktuelle Verhandlung stattfindet (z. B. Notruf vs. normaler + Anruf) + \item + Auf den SA-Payload folgen ein oder mehrere Proposal-Payloads + \end{itemize} + + + \subsubsection{ISAKMP - Die + Vorschlagsnutzdaten} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ISAKMP-proposal-payload.png} + \item + Proposal \# wird verwendet, um Richtlinien auszudrücken und Vorschläge + auszuhandeln: + + \begin{itemize} + \item + Wenn zwei oder mehr Vorschläge die gleiche Nummer tragen, wird ein + logisches UND realisiert. + \item + Unterschiedliche Werte für Proposal \# realisieren logisches OR mit + absteigender Priorität + \end{itemize} + \item + Protocol ID gibt den Protokoll-Identifikator der aktuellen Verhandlung + an, z. B. AH oder ESP (für IPsec) + \item + SPI Size gibt die Länge des enthaltenen SPI-Wertes an + \item + Number of Transforms (Anzahl der Transformationen) gibt an, wie viele + Transformationen zu diesem Vorschlag gehören (diese folgen unmittelbar + auf die Nutzlast des Vorschlags) + \end{itemize} + + + \subsubsection{ISAKMP - Die + Transformations-Nutzdaten} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-ISAKMP-transform-payload.png} + \item + Eine Transform-Payload spezifiziert einen bestimmten + Sicherheitsmechanismus, auch Transform genannt, der zur Sicherung des + Kommunikationskanals verwendet werden soll. + \item + Jede in einem Vorschlag aufgeführte Transformation hat eine eindeutige + Transform \# + \item + Jede Transformation wird durch eine Transform-ID eindeutig + identifiziert, z.B. 3DES, AES, MD5, SHA-1, etc. + + \begin{itemize} + \item + Die Transformations-IDs werden in einem DOI-Dokument angegeben. + \end{itemize} + \item + Die SA-Attribute geben die Attribute an, die für die im Feld Transform + ID angegebene Transformation definiert sind. + \end{itemize} + + + \subsubsection{ISAKMP - SA-Verhandlung} + + \begin{itemize} + \item + Inhalt des Next Payload-Feldes von SA-, Proposal- und + Transform-Payloads: + + \begin{itemize} + \item + Das Next-Payload-Feld einer SA-Payload gibt nicht die unmittelbar + folgende Proposal-Payload an, da diese implizit ist. + \item + Das Gleiche gilt für Proposal- und Transform-Payloads + \end{itemize} + \item + Die Proposal-Payload gibt der initiierenden Entität die Möglichkeit, + der antwortenden Entität die Sicherheitsprotokolle und zugehörigen + Sicherheitsmechanismen zur Verwendung mit der auszuhandelnden + Sicherheitsassoziation zu präsentieren. + \item + Wenn die SA-Etablierung für eine kombinierte Schutzsuite ausgehandelt + wird, die aus mehreren Protokollen besteht, muss es mehrere + Proposal-Payloads geben, die jeweils die gleiche Proposal-Nummer + haben. + \item + Diese Vorschläge müssen als eine Einheit betrachtet werden und dürfen + nicht durch einen Vorschlag mit einer anderen Vorschlagsnummer + getrennt werden. + \item + Dieses erste Beispiel zeigt eine ESP- UND AH-Schutzsuite: + + \begin{itemize} + \item + Das erste Protokoll wird mit zwei von der vorschlagenden Stelle + unterstützten Transformationen dargestellt, ESP mit: + + \begin{itemize} + \item + Transformation 1 als 3DES + \item + Umwandlung 2 als AES + \item + Der Responder muss zwischen den beiden für ESP vorgeschlagenen + Transformationen wählen. + \end{itemize} + \item + Das zweite Protokoll ist AH und wird mit einer einzigen + Transformation angeboten: + + \begin{itemize} + \item + Umwandlung 1 als SHA + \end{itemize} + \item + Die resultierende Schutzsuite ist entweder + + \begin{itemize} + \item + 3DES und SHA, oder + \item + AES und SHA, je nachdem, welche ESP-Transformation vom Responder + gewählt wurde + \end{itemize} + \item + In diesem Fall folgen auf die SA-Nutzdaten die folgenden Nutzdaten: + + \begin{itemize} + \item + {[}Vorschlag 1, ESP, (Transform 1, 3DES, ...), (Transform 2, + AES){]} {[}Vorschlag 1, AH, (Transform 1, SHA){]} + \end{itemize} + \item + Bitte beachten Sie, dass dies zu zwei SAs pro Richtung führt! + \end{itemize} + \item + Dieses zweite Beispiel zeigt einen Vorschlag für zwei verschiedene + Schutzsuiten: + + \begin{itemize} + \item + Die erste Schutzsuite wird vorgestellt mit: + + \begin{itemize} + \item + einer Transformation (MD5) für das erste Protokoll (AH), und + \item + eine Umwandlung (3DES) für das zweite Protokoll (ESP) + \end{itemize} + \item + Die zweite Schutzsuite wird mit zwei Transformationen für ein + einziges Protokoll (ESP) vorgestellt: + + \begin{itemize} + \item + 3DES, oder + \item + AES + \end{itemize} + \item + Bitte beachten Sie, dass es nicht möglich ist, festzulegen, dass + Transformation 1 und Transformation 2 für eine Instanz einer + Protokollspezifikation verwendet werden müssen. + \item + In diesem Fall folgen auf den SA-Payload die folgenden Payloads: + + \begin{itemize} + \item + {[}Vorschlag 1, AH, (Transform 1, MD5, ...){]} {[}Vorschlag 1, + ESP, (Transform 1, 3DES, ...){]} {[}Vorschlag 2, ESP, (Transform1, + 3DES, ...), (Transform 2, AES, ...){]} + \end{itemize} + \item + Bitte beachten Sie, dass Vorschlag 1 zu zwei SAs pro Richtung führt. + \end{itemize} + \item + Bei der Beantwortung einer Security-Association-Nutzlast muss der + Antwortende eine Security-Association-Nutzlast mit dem ausgewählten + Vorschlag senden, der aus mehreren Proposal-Nutzlasten und den + zugehörigen Transform-Nutzlasten bestehen kann + \item + Jede der Proposal-Payloads muss eine einzelne Transform-Payload + enthalten, die dem Protokoll zugeordnet ist. + \item + Der Antwortende sollte das Feld Proposal \# in der Proposal-Payload + und das Feld Transform \# in jeder Transform-Payload des ausgewählten + Vorschlags beibehalten. + + \begin{itemize} + \item + Die Beibehaltung der Vorschlags- und Transformationsnummern sollte + die Protokollverarbeitung des Initiators beschleunigen, da die + Auswahl des Antwortenden nicht mit jeder angebotenen Option + verglichen werden muss. + \item + Diese Werte ermöglichen es dem Initiator, den Vergleich direkt und + schnell durchzuführen. + \end{itemize} + \item + Der Initiator muss überprüfen, ob die vom Responder empfangene + SA-Nutzlast mit einem der ursprünglich gesendeten Vorschläge + übereinstimmt + \end{itemize} + + + \subsubsection{ISAKMP - Session Key + Establishment} + + \begin{itemize} + \item + ISAKMP baut 4 verschiedene Schlüssel mit einem + Authentifizierungsaustausch auf: + + \begin{itemize} + \item + SKEYID ist eine Zeichenkette, die aus geheimem Material abgeleitet + wird, das nur den aktiven Teilnehmern des Austauschs bekannt ist und + als ,,Hauptschlüssel'' dient. + + \begin{itemize} + \item + Die Berechnung von SKEYID ist abhängig von der + Authentifizierungsmethode + \end{itemize} + \item + SKEYID\_e ist das Schlüsselmaterial, das von der ISAKMP SA zum + Schutz der Vertraulichkeit ihrer Nachrichten verwendet wird + \item + SKEYID\_a ist das Schlüsselmaterial, das von der ISAKMP SA zur + Authentifizierung ihrer Nachrichten verwendet wird + \item + SKEYID\_d ist das Verschlüsselungsmaterial, das zur Ableitung von + Schlüsseln für Nicht-ISAKMP-Sicherheitsassoziationen verwendet wird. + \end{itemize} + \end{itemize} + + + \subsection{IKE - Einführung} + + \begin{itemize} + \item + Während ISAKMP die grundlegenden Datenformate und Verfahren zur + Aushandlung beliebiger SAs definiert, spezifiziert der Internet Key + Exchange das standardisierte Protokoll zur Aushandlung von IPsec SAs + \item + IKE definiert fünf Austauschvorgänge: + + \begin{itemize} + \item + Phase-1-Austausch für die Einrichtung einer IKE SA : + + \begin{itemize} + \item + Main-Mode-Austausch, der durch 6 ausgetauschte Nachrichten + realisiert wird + \item + Aggressive mode exchange, der nur 3 Nachrichten benötigt + \end{itemize} + \item + Phase 2 Austausch für die Einrichtung von IPsec SAs: + + \begin{itemize} + \item + Quick-Mode-Austausch, der mit 3 Nachrichten realisiert wird + \end{itemize} + \item + Andere Austausche: + + \begin{itemize} + \item + Informationsaustausch zur Übermittlung von Status- und + Fehlermeldungen + \item + Neuer Gruppenaustausch zur Vereinbarung von privaten + Diffie-Hellman-Gruppen + \end{itemize} + \end{itemize} + \item + Hinweis: Auf den folgenden Folien steht HMAC(K, x \textbar{} y + \textbar{} ...) für H(K, p 1 , H(K, p 2 , x, y, ...)), wobei p 1 und p + 2 Auffüllmuster bezeichnen + \end{itemize} + + + \subsubsection{IKE - Berechnung von + IKE-Sitzungsschlüsseln} + + \begin{itemize} + \item + IKE baut vier verschiedene Schlüssel mit einem + Authentifizierungsaustausch auf: + + \begin{itemize} + \item + SKEYID ist eine Zeichenkette, die aus geheimem Material abgeleitet + wird, das nur den aktiven Teilnehmern des Austauschs bekannt ist, + und die als ,,Hauptschlüssel'' dient. + + \begin{itemize} + \item + Die Berechnung von SKEYID ist abhängig von der + Authentifizierungsmethode + \end{itemize} + \item + SKEYID\_d ist das Keying-Material, das zur Ableitung von Schlüsseln + für Nicht-IKE-SAs verwendet wird + + \begin{itemize} + \item + SKEYID\_d = \$HMAC(SKEYID, g\^{}\{xy\} \textbar{} CKY-I \textbar{} + CKY-R \textbar{} 0)\$, wobei \$g\^{}\{xy\}\$ das gemeinsame + Diffie-Hellman-Geheimnis bezeichnet + \end{itemize} + \item + SKEYID\_a ist das Schlüsselmaterial, das von der IKE SA zur + Authentifizierung ihrer Nachrichten verwendet wird + + \begin{itemize} + \item + SKEYID\_a = \$HMAC(SKEYID, SKEYID\_d \textbar{} g\^{}\{xy\} + \textbar{} CKY-I \textbar{} CKY-R \textbar{} 1)\$ + \end{itemize} + \item + SKEYID\_e ist das Schlüsselmaterial, das von der IKE SA zum Schutz + der Vertraulichkeit ihrer Nachrichten verwendet wird + + \begin{itemize} + \item + SKEYID\_e = \$HMAC(SKEYID, SKEYID\_a \textbar{} g\^{}\{xy\} + \textbar{} CKY-I \textbar{} CKY-R \textbar{} 2)\$ + \end{itemize} + \end{itemize} + \item + Falls erforderlich, werden die Schlüssel nach der folgenden Methode + erweitert: + + \begin{itemize} + \item + \$K=(K\_1 \textbar{} K\_2 \textbar{} ...)\$ mit \$K\_i = + HMAC(SKEYID, K\_\{i-1\})\$ und \$K\_0 = 0\$ + \end{itemize} + \end{itemize} + + + \subsubsection{IKE - + Authentifizierungsmethoden} + + \begin{itemize} + \item + Phase 1 IKE-Austausche werden mit Hilfe von zwei Hash-Werten Hash-I + und Hash-R authentifiziert, die vom Initiator und vom Responder + erstellt werden: + + \begin{itemize} + \item + Hash-I = HMAC(SKEYID, gx \textbar{} gy \textbar{} CKY-I \textbar{} + CKY-R \textbar{} SA-Angebot \textbar{} ID-I) + \item + Hash-R = HMAC(SKEYID, gy \textbar{} gx \textbar{} CKY-R \textbar{} + CKY-I \textbar{} SA-offer \textbar{} ID-R) wobei gx, gy die + ausgetauschten öffentlichen Diffie-Hellman-Werte bezeichnen ID-I, + ID-R bezeichnen die Identität des Initiators und des Responders + SA-offer bezeichnet die Nutzdaten bezüglich der SA-Verhandlung + \end{itemize} + \item + IKE unterstützt vier verschiedene Methoden der Authentifizierung: + + \begin{itemize} + \item + Pre-shared Key: + + \begin{itemize} + \item + SKYEID = \$HMAC(K\_\{Initiator\}, Responder , r\_\{Initiator\} + \textbar{} r\_\{Responder\})\$ + \end{itemize} + \item + Zwei verschiedene Formen der Authentifizierung mit + Public-Key-Verschlüsselung: + + \begin{itemize} + \item + SKEYID = \$HMAC(H(r\_\{Initiator\}, r\_\{Responder\}), CKY-I + \textbar{} CKY-R) + \end{itemize} + \item + Digitale Unterschrift: + + \begin{itemize} + \item + SKEYID = \$HMAC((r\_\{Initiator\} \textbar{} r\_\{Responder\}), + g\^{}\{xy\})\$ + \item + Da in diesem Fall SKEYID selbst keine Authentifizierung bietet, + werden die Werte Hash-I und Hash-R vom Initiator/Responder + signiert + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsubsection{IKE - Main Mode Austausch mit Pre-Shared + Key} + + \begin{itemize} + \item + Die folgenden Beschreibungen listen die ausgetauschten ISAKMP- und + IKE-Payloads auf, wenn verschiedene ,,Flavors'' der + IKE-Authentifizierung durchgeführt werden: + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-IKE-exchange-payloads.png} + \item + \$N\_i, N\_r\$ bezeichnen \$r\_\{Initiiator\}, r\_\{Responder\}\$ + (IKE-Notation) + \item + \$ID\_i, ID\_r\$ bezeichnen die Identität des Initiators und des + Responders + \item + \$KE\$ bezeichnet die öffentlichen Werte eines DH-Austausches + \end{itemize} + \item + Bitte beachten Sie, dass Hash-I und Hash-R nicht signiert werden + müssen, da sie bereits ,,ein authentisches Geheimnis'' (Pre-Shared + Key) enthalten + \end{itemize} + + + \subsubsection{IKE - Hauptmodus Austausch mit + Signaturen} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-IKE-exchange-payload-signature.png} + + \begin{itemize} + \item + \$(m)\$ gibt an, dass m optional ist + \item + \$I{[}m{]}\$ bedeutet, dass I m signiert + \end{itemize} + \item + Bitte beachten Sie, dass Hash-I und Hash-R signiert werden müssen, da + sie nichts enthalten, von dem bekannt ist, dass es authentisch ist + \end{itemize} + + + \subsubsection{IKE - Main Mode Exchange mit Public Key + Encryption} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-IKE-exchange-public-key.png} + + \begin{itemize} + \item + wobei: \$\{m\}\_\{+KI\}\$ bedeutet, dass m mit dem öffentlichen + Schlüssel \$+K\_I\$ verschlüsselt ist + \item + Bitte beachten Sie, dass Hash-I und Hash-R nicht signiert werden + müssen, da sie die ausgetauschten Zufallszahlen Ni bzw. Nr + ,,enthalten''. + + \begin{itemize} + \item + Jede Entität beweist also ihre Authentizität, indem sie die + empfangene Zufallszahl ( Ni oder Nr ) mit ihrem privaten Schlüssel + entschlüsselt + \end{itemize} + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-IKE-exchange-public-key-2.png} + + \begin{itemize} + \item + wobei: \$\{m\}\_\{+KI\}\$ bedeutet, dass m mit dem öffentlichen + Schlüssel \$+K\_I\$ verschlüsselt ist + \item + \$\{m\}\_\{K\_i\}\$ bedeutet, dass m mit dem symmetrischen Schlüssel + \$K\_i\$ mit \$K\_i=H(N\_i, CKY-I)\$ und \$K\_r=H(N\_r,CKY-R)\$ + verschlüsselt ist + \item + Bitte beachten Sie, dass alle bisher beschriebenen Schemata einen + Schutz der Identität vor Abhörern im Internet bieten, da die IDs und + Zertifikate nicht im Klartext gesendet werden: + \item + Die IP-Adressen der ausgetauschten Pakete sind jedoch immer + lesbar... + \end{itemize} + \end{itemize} + + + \subsubsection{IKE - Aggressiver Modus Austausch mit Pre-Shared + Key} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-IKE-aggressive-mode.png} + \item + Da die Identität des Initiators und des Responders gesendet werden + muss, bevor ein Sitzungsschlüssel erstellt werden kann, kann der + Austausch im aggressiven Modus keinen Identitätsschutz vor Abhörern + bieten + \item + Ähnliche Varianten des aggressiven Modus gibt es auch für die + Authentifizierung mit: + + \begin{itemize} + \item + Digitale Signatur + \item + Verschlüsselung mit öffentlichem Schlüssel + \end{itemize} + \end{itemize} + + + \subsubsection{IKE - Quick Mode + Exchange} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-IKE-quick-mode.png} + \item + \$Hash1 = HMAC(SKEYID\_a, M-ID \textbar{} SA \textbar{} Ni \textbar{} + {[} \textbar{} KE {]} {[} \textbar{} ID\_\{ci\} \textbar{} + ID\_\{cr\}{]} )\$ + \item + \$Hash2 = HMAC(SKEYID\_a, M-ID \textbar{} N\_i \textbar{} SA + \textbar{} N\_r \textbar{} {[} \textbar{} KE {]} {[} \textbar{} + ID\_\{ci\} \textbar{} ID\_\{cr\}{]} ) + \item + \$Hash3 = HMAC(SKEYID\_a, 0 \textbar{} M-ID \textbar{} N\_i \textbar{} + N\_r)\$ + \item + Die optionale Einbeziehung der Identitäten \$ID\_\{ci\}\$ und + \$ID\_\{cr\}\$ ermöglicht es ISAKMP-Entitäten, eine SA im Namen + anderer Clients einzurichten (Gateway-Szenario) + \item + Die optionalen Schlüsselaustausch-Payloads KE ermöglichen die + Durchführung eines neuen DH-Austauschs, wenn perfekte Forward Secrecy + gewünscht ist + \item + Sitzungsschlüsselmaterial \$= HMAC(SKEYID\_d, {[} g\^{}\{xy\} + \textbar{} {]} protocol \textbar{} SPI \textbar{} N\_i \textbar{} + N\_r)\$ + \end{itemize} + + + \subsection{Weitere Probleme mit + IPsec} + + \begin{itemize} + \item + Komprimierung: + + \begin{itemize} + \item + Wenn Verschlüsselung verwendet wird, dann können die resultierenden + IP-Pakete nicht in der Verbindungsschicht komprimiert werden, z.B. + bei einer Verbindung zu einem ISP über Modem + \item + Daher wurde das IP Payload Compression Protocol (PCP) definiert + \item + PCP kann mit IPsec verwendet werden: + + \begin{itemize} + \item + In der IPsec-Policy-Definition kann PCP festgelegt werden. + \item + Die IKE SA-Verhandlung ermöglicht die Aufnahme von PCP in die + Vorschläge + \end{itemize} + \end{itemize} + \item + Interoperabilitätsprobleme bei End-to-End-Sicherheit mit + Header-Verarbeitung in Zwischenknoten: + + \begin{itemize} + \item + Interoperabilität mit Firewalls: + + \begin{itemize} + \item + Die Ende-zu-Ende-Verschlüsselung kollidiert mit der Notwendigkeit + von Firewalls, die Protokoll-Header der oberen Schichten in + IP-Paketen zu prüfen. + \end{itemize} + \item + Interoperabilität mit Network Address Translation (NAT): + + \begin{itemize} + \item + Verschlüsselte Pakete lassen weder eine Analyse noch eine Änderung + der Adressen zu. + \item + Authentifizierte Pakete werden verworfen, wenn die Quell- oder + Zieladresse geändert wird. + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Schlussfolgerung} + + \begin{itemize} + \item + IPsec ist die Sicherheitsarchitektur der IETF für das + Internet-Protokoll + \item + Sie bietet die folgenden Sicherheitsdienste für IP-Pakete: + + \begin{itemize} + \item + Authentifizierung der Datenherkunft + \item + Schutz vor Wiederholung + \item + Vertraulichkeit + \end{itemize} + \item + Es kann in Endsystemen oder Zwischensystemen realisiert werden: + + \begin{itemize} + \item + Implementierung im Endsystem: Integriertes Betriebssystem oder + ,,bump in the stack'' + \item + Gateway-Implementierung: Integrierter Router oder ,,bump in the + wire'' + \end{itemize} + \item + Es wurden zwei grundlegende Sicherheitsprotokolle definiert: + + \begin{itemize} + \item + Authentifizierungs-Header (AH) + \item + Encapsulating security payload (ESP) + \end{itemize} + \item + SA-Verhandlung und Schlüsselverwaltung werden mit folgenden + Protokollen realisiert: + + \begin{itemize} + \item + Internet security association key management protocol (ISAKMP) + \item + Internet-Schlüsselaustausch (IKE) + \end{itemize} + \end{itemize} + + + \subsection{Neue Wege in der + IPsec-Entwicklung} + + \begin{itemize} + \item + Internet-Schlüsselaustausch Version 2 + + \begin{itemize} + \item + Basierend auf den Erkenntnissen aus IKEv1 + \item + Wesentliche Vereinfachungen + \end{itemize} + \item + Netzwerkadressübersetzung (NAT) + + \begin{itemize} + \item + Beispiel für Probleme mit NAT und IPsec + \item + NAT-Überwindung + \item + Bound-End-to-End Tunnel Mode (BEET) + \end{itemize} + \item + Konfiguration von großen IPsec-Infrastrukturen + \end{itemize} + + + \subsection{Internet Key Exchange Protocol Version 2 + {[}RFC5996{]}} + + Zusätzliche Designziele zu IKEv1 + + \begin{itemize} + \item + Konsolidierung von mehreren IKEv1-RFCs (und mehreren Erweiterungen) + + \begin{itemize} + \item + Erleichterung für Entwickler und Prüfer + \item + Klärung mehrerer unspezifischer Punkte + \end{itemize} + \item + Vereinfachungen + + \begin{itemize} + \item + Anzahl der verschiedenen Schlüsselaustauschverfahren auf eines + reduziert + \item + Verschlüsselung wie in ESP + \item + Einfacher Anfrage/Antwort-Mechanismus + \end{itemize} + \item + Verringerung der Latenzzeit + \item + Aushandlung von Verkehrsselektoren + \item + Graceful Changes, damit bestehende IKEv1-Software aufgerüstet werden + kann + \end{itemize} + + + \subsubsection{IKEv2 - + Schlüsselaustauschverfahren} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-IKEv2-exchange-procedure.png} + + \begin{itemize} + \item + \$K\$ Schlüssel abgeleitet durch \$PRF(PRF(N\_i \textbar\textbar{} + N\_r, g\^{}\{ir\}), N\_i \textbar\textbar{} N\_r \textbar\textbar{} + SPI\_i \textbar\textbar{} SPI\_r)\$ + \item + \$PRF\$ ,,irgendeine'' Pseudozufallsfunktion - in der Regel eine + asymmetrische HMAC SIG-Signatur oder MAC über die ersten beiden + Nachrichten + \item + \$SAEx\$ ein Huckepack- ,,Quick-Mode-Austausch'' + \end{itemize} + \item + Nur ein einziger Austauschtyp + \item + Vier Nachrichten werden ausgetauscht \$(= 2 * RTT)\$ + \item + Initiator löst alle erneuten Übertragungen aus + \end{itemize} + + + \subsubsection{IKEv2 - Eigenschaften des + Schlüsselaustauschverfahrens} + + \begin{itemize} + \item + Der erste SA-Austausch erfolgt huckepack + + \begin{itemize} + \item + Geringere Latenz, da eine RTT eingespart wird + \end{itemize} + \item + Nachricht 4 sollte huckepack mit Nachricht 2 ausgetauscht werden, aber + + \begin{itemize} + \item + Nachricht 3 verifiziert, dass Initiator Nachricht 2 erhalten hat + (SPI \textasciitilde{} Cookie) + + \begin{itemize} + \item + Dient als DoS-Schutz, wenn anschließend rechenintensive Aufgaben + durchgeführt werden + \end{itemize} + \item + Identität des Responders wird erst nach Verifizierung des Initiators + offengelegt + + \begin{itemize} + \item + Schützt vor dem Scannen nach einer Partei mit einer bestimmten ID + \end{itemize} + \item + Initiator weiß nicht, wann es sicher ist, Daten zu senden + + \begin{itemize} + \item + (Pakete können in falscher Reihenfolge empfangen werden) + \end{itemize} + \item + Würde eine kompliziertere Strategie zur erneuten Übertragung + erfordern + \item + Responder kann nicht über eine Policy für die Child SA entscheiden + \end{itemize} + \end{itemize} + + + \subsubsection{IKEv2 - Zusätzliche + Funktionen} + + \begin{itemize} + \item + Zusätzlicher DoS-Schutz + + \begin{itemize} + \item + Im Falle eines DoS-Angriffs kann der Responder den Initiator + auffordern, ein zustandsloses Cookie zu senden + \item + Fügt dem Austausch 2 zusätzliche Nachrichten hinzu + \end{itemize} + \item + Dead Peer Detection + + \begin{itemize} + \item + Regelmäßige IKE-Anfragen, um festzustellen, ob die SA gelöscht + werden kann + \end{itemize} + \item + Flexiblere Verhandlungstechniken + + \begin{itemize} + \item + Möglichkeit der Angabe: ,,Verwenden Sie eine dieser Chiffren mit + einem dieser Authentifizierungsalgorithmen'' (es müssen nicht mehr + alle Kombinationen aufgezählt werden) + \item + Verkehrsselektoren können eingegrenzt werden + + \begin{itemize} + \item + Initiator: ,,Ich möchte 192.168.0.0/16 für meinen Tunnelmodus + verwenden'' + \item + Antwortgeber: ,,OK, aber Sie dürfen nur 192.168.78.0/24 + verwenden'' + \item + Kann verwendet werden, um den Responder dem Initiator einen + Adressbereich zuweisen zu lassen (in einfachen Situationen ohne / + mit Hilfe von DHCP; siehe auch unten) + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Netzwerk-Adressübersetzung + (NAT)} + + \begin{itemize} + \item + Heutzutage ein häufiges Problem: ISP stellt nur eine einzige + IP-Adresse zur Verfügung, es sollen aber mehrere Geräte angeschlossen + werden + \item + Lösung: Ein Router wird verwendet, um mehrere interne (private) + Adressen auf eine einzige externe (öffentliche) Adresse abzubilden + \item + Häufigster Ansatz (vereinfacht): + + \begin{itemize} + \item + Für Pakete, die von der privaten Seite kommen: + + \begin{itemize} + \item + Der Router schreibt die TCP/UDP-Quellports auf einen eindeutigen + Wert pro IP-Flow um + \item + Speichert den neuen Quellport in einer Tabelle mit der + Quelladresse und dem alten Quellport + \item + Ersetzt die Quell-IP-Adresse durch die externe Adresse + \end{itemize} + \item + Für Pakete, die von der öffentlichen Seite kommen: + + \begin{itemize} + \item + Der Router sucht den IP-Fluss nach dem TCP/UDP-Zielport ab + \item + Ersetzt die Zieladresse und den Port durch die alten Werte + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsubsection{NAT - Ein Beispiel} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-NAT-example.png} + \item + NAT ändert die Quelladresse eines jeden Pakets in eine öffentliche + IP-Adresse mit anderen ("umgeschriebenen") Quellports + \end{itemize} + + + \subsubsection{Probleme mit NAT und IPsec - + NAT-Traversal} + + \begin{itemize} + \item + Probleme: + + \begin{itemize} + \item + AH kann per Definition nicht mit NAT verwendet werden + \item + ESP bietet kein ,,wiederbeschreibbares Feld'' (wie Portnummer) + \item + TCP/UDP-Portnummern werden verschlüsselt oder authentifiziert (oder + beides) + \end{itemize} + \item + Lösung für ESP: ESP-Pakete in normale UDP-Pakete einkapseln + {[}RFC3948{]} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-NAT-encap-ESP.png} + \end{itemize} + \item + UDP-Header enthält nur Portnummern und leere Prüfsumme + + \begin{itemize} + \item + Fügt 8 Byte Overhead hinzu + \item + Einziger Zweck: dem NAT-Gerät etwas zum ,,Umschreiben'' geben (um + die Empfänger der Pakete in der Antwort unterscheiden zu können) + \item + Port 4500 reserviert für NAT-T (NAT-Traversal) + \end{itemize} + \item + Im Transport-Modus: + + \begin{itemize} + \item + Innere UDP/TCP-Prüfsumme hängt von der ursprünglichen Quelladresse + ab (Layering-Verletzung in der ursprünglichen TCP/IP-Suite) + \item + Muss wiederhergestellt werden + \end{itemize} + \item + Wann ist NAT-T zu verwenden? + + \begin{itemize} + \item + NAT-Situation muss von IKE erkannt werden + \item + Erfolgt durch IKEv1-Erweiterung {[}RFC3947{]} und IKEv2 + \item + IKE verwendet NAT-T, wenn der IKE-Quellport nicht 500 ist + \item + Funktioniert nicht immer, dann ist eine manuelle Konfiguration + erforderlich + \end{itemize} + \item + Timeout-Probleme und Keep-Alives + + \begin{itemize} + \item + ESP-Pakete werden nicht periodisch ausgetauscht + \item + NAT-T-Ströme können im Router eine Zeitüberschreitung verursachen + \item + Eingehende Pakete können dann nicht zugestellt werden + \item + Regelmäßige Keep-Alive-Pakete stellen sicher, dass der Router seinen + Status beibehält + \item + Einfaches UDP-Paket an Port 4500 mit einem einzigen 0xFF-Oktett + \end{itemize} + \end{itemize} + + + \subsubsection{Probleme mit NAT und IPsec - + BEET-Modus} + + \begin{itemize} + \item + Welche Adressen soll Alice verwenden, um Pakete an Bob, Charlie und + Dave zu senden? + \item + Weder die externen noch die internen Adressen dürfen eindeutig sein! + + \begin{itemize} + \item + Bobs und Charlies Pakete haben beide die gleiche externe Adresse + \item + Bobs und Daves Pakete haben beide dieselbe interne Adresse + \item + % \includegraphics{Assets/NetworkSecurity-NAT-BEET-mode.png} + \item + Die Verwendung interner oder externer Adressen ist unsicher (Warum?) + \item + Die Unterscheidung erfordert virtuelle Adressen... + \end{itemize} + \item + Virtuelle IP-Adressen zuweisen oder aushandeln + + \begin{itemize} + \item + Alice muss jedem ihrer Peers eindeutige virtuelle Adressen zuweisen + \item + Dies kann manuell geschehen, oder + \item + durch DHCP über IKE, oder + \item + durch Aushandlung von Verkehrsselektoren (IKEv2) + \item + L2TP über IPsec ausführen + \end{itemize} + \item + IPsec-Tunnelmodus ist erforderlich + + \begin{itemize} + \item + Externer IP-Header trägt entweder eine öffentliche IP-Adresse oder + eine private NAT-Adresse + \item + Interner IP Header trägt virtuelle IP-Adresse + \item + Führt zu (mindestens!) 28 Bytes Overhead pro Paket in + NAT-Situationen + \item + \textbar{} IP Header \textbar{} UDP Header \textbar{} ESP Header + \textbar{} IP Header \textbar{} geschützte Daten \textbar{} + \end{itemize} + \item + Aber eigentlich sind nur Adressfelder im inneren IP-Header + erforderlich (alle anderen Felder können vom externen Header + abgeleitet werden) + \item + Beide virtuellen Adressfelder verwenden immer dieselben Adressen (kein + Multiplexing wie in üblichen Tunnelmodusszenarien) + \item + Die Beschränkung auf zwei Adressen im Tunnel ermöglicht eine statische + Bindung während der IKE-Aushandlung + \item + Der Bound-End-to-End-Tunnel (BEET)-Modus {[}NiMe08{]} verhält sich + semantisch wie eine Tunnelmodus-Assoziation mit einem Verkehrsselektor + für einen einzelnen Host (/32) + \item + Die übertragenen ESP-Pakete sind äquivalent zu Transport + (!)-Modus-Paketen (virtuelle Adressen werden nie in Paketen + übertragen) + \item + Der innere Header wird durch den ESP-Entkapselungsprozess + wiederhergestellt. + \item + Unterscheidet zwischen der Erreichbarkeit eines Hosts (externe + IP-Adresse) und seiner Identität (virtuelle IP-Adresse) + \item + Hosts können nun zwischen verschiedenen Standorten hin- und herwandern + und ihre virtuelle IP-Adresse beibehalten (dies ermöglicht zusätzlich + eine bessere Unterstützung der Mobilität) + \end{itemize} + + + \subsection{Konfiguration großer + IPsec-Infrastrukturen} + + \begin{itemize} + \item + Kommunikationsinfrastrukturen von Unternehmen und Behörden: + \item + Kann komplexe Overlay-Topologien bilden + + \begin{itemize} + \item + Verschachtelt + \item + Kreisläufe + \item + Mehrere Sicherheitsgateways pro privatem Netzwerk + \item + Mehrere private Netze pro Gateway + \item + Private Adressbereiche in privaten Netzen + \item + QoS und sicheres IP-Multicast können erforderlich sein + \end{itemize} + \item + Kann bis zu Tausende von Sicherheits-Gateways haben + \item + Kann sich dynamisch ändern + + \begin{itemize} + \item + Hinzufügen und Entfernen von Sicherheitsgateways + \item + Ausfälle von Verbindungen und Knoten + \item + Denial-of-Service-Angriffe + \item + Mobile Sicherheitsgateways (z. B. für die Kommunikation im + Katastrophenfall) + \end{itemize} + \item + Muss natürlich sicher sein ... + \end{itemize} + + + \subsection{Probleme bei der manuellen Konfiguration der + IPsec-Infrastruktur} + + \begin{itemize} + \item + Die IETF hat keine Methode zur automatischen Konfiguration und zum + Einsatz von IPsec in großen Szenarien definiert + \item + Daher werden Sicherheits-Gateways in der Regel manuell konfiguriert + + \begin{itemize} + \item + Die Anzahl der Sicherheitsrichtlinieneinträge wächst quadratisch mit + der Anzahl der Sicherheitsgateways + \item + Problem der Skalierbarkeit + + \begin{itemize} + \item + Der Administrationsaufwand wächst \$\textbackslash Rightarrow\$ + Die Kosten steigen + \item + Administratoren machen potenziell mehr Konfigurationsfehler, z.B. + vergessen, einen Eintrag aus einem SPD zu löschen oder einen zu + großen IP-Bereich zuzulassen, usw. \$\textbackslash Rightarrow\$ + Mögliche Sicherheitsprobleme + \end{itemize} + \end{itemize} + \item + Problem der Agilität + + \begin{itemize} + \item + Keine dynamische Anpassung der VPN-Topologie + \item + Begrenzte Unterstützung mobiler Sicherheits-Gateways + \end{itemize} + \end{itemize} + + + \subsection{Automatische IPsec-Konfiguration - einige + Anforderungen} + + \begin{itemize} + \item + Funktionelle Anforderungen + + \begin{itemize} + \item + Muss manuelle Eingriffe minimieren + \item + Muss auch komplexe Infrastrukturen unterstützen (verschachtelte + Topologien mit privaten Adressbereichen usw.) + \item + Muss nur Unicast verwenden (da Multicast usw. nicht weit verbreitet + ist) + \end{itemize} + \item + Nicht-funktionale Anforderungen + + \begin{itemize} + \item + Muss robust sein, d. h. stabil auf schwierige Netzbedingungen + reagieren + \item + Sie muss sicher sein, insbesondere darf sie nicht schwächer sein als + eine manuell konfigurierte IPsec-Infrastruktur + \item + Sie muss in Bezug auf die Anzahl der Sicherheits-Gateways skalierbar + sein + \item + Es muss sich schnell an neue Topologien anpassen können. + \end{itemize} + \end{itemize} + + + \subsection{Verschiedene Ansätze für die automatische + IPsec-Konfiguration} + + \begin{itemize} + \item + IPsec-Richtlinienverteilung über zentrale Server + \item + Gruppenverschlüsseltes Transport-VPN (GET) + \item + Tunnel-Endpunkt-Erkennung (TED) + \item + Dynamisches Mehrpunkt-VPN (DMVPN) + \item + Proaktives Multicast-basiertes IPsec-Erkennungsprotokoll + \item + Soziales VPN + \item + Sicheres OverLay für IPsec-Erkennung (SOLID) + \end{itemize} + + + \subsubsection{IPsec-Richtlinienverteilung durch zentrale + Server} + + \begin{itemize} + \item + Einfacher, gemeinsamer Ansatz zur Konfiguration einer großen Anzahl + von Sicherheits-Gateways + \item + Zentraler Policy Server statisch in jedem Gateway konfiguriert + \item + Jedes Gateway kontaktiert den Policy Server, um SPD zu aktualisieren + \item + Beispiel: Microsoft Active Directory, verschiedene Militärprodukte + \item + Einige offensichtliche Probleme: + + \begin{itemize} + \item + Administratoren müssen die zentrale Datenbank manuell bearbeiten + \item + Verschachtelte Topologien sind schwer zu realisieren + \item + Skalierbarkeitsprobleme aufgrund von Engpässen + \item + Verfügbarkeit ist schwer zu garantieren (Single Point of Failure) + \item + Dynamische Topologien erfordern, dass neue Richtlinien proaktiv an + die Sicherheitsgateways übermittelt werden (auch wenn sie derzeit + vielleicht nicht verwendet werden) + \item + Viele Richtlinieneinträge werden höchstwahrscheinlich nie verwendet + (kein Verkehr) + \end{itemize} + \end{itemize} + + + \subsubsection{Tunnel Endpoint Discovery + (TED)} + + \begin{itemize} + \item + Proprietärer Ansatz von Cisco {[}Fluh01{]} + \item + Sicherheitsassoziationen werden reaktiv erstellt + + \begin{itemize} + \item + Alice sendet Paket an Bob + \item + Gateway A erkennt, dass keine gültige SA vorhanden ist + \item + Verwerfen des Pakets und Senden des IKE-Pakets an Bob + \item + Gateway B fängt IKE-Paket ab + \item + Richtet SA zu Gateway A ein + \item + Nachfolgende Pakete zwischen Alice und Bob können übertragen werden + \end{itemize} + \item + Ziemlich leistungsfähiger, sicherer Ansatz, aber + + \begin{itemize} + \item + Routing muss im Transportnetz durchgeführt werden + \item + Keine privaten IP-Adressbereiche + \item + Keine verschachtelten Topologien + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-TED.png} + \end{itemize} + + + \subsubsection{Gruppenverschlüsseltes Transport-VPN + (GET)} + + \begin{itemize} + \item + Cisco Produktbranding mehrerer IPsec-Komponenten {[}Bhai08{]} + \item + Sicherheits-Gateways kontaktieren zentralen IKE-Server + \item + IKE-Server verteilt symmetrische Schlüssel (bevorzugt über Multicast) + \item + Alle Sicherheitsgateways einer Gruppe verwenden dieselbe SA + (einschließlich SPI, Schlüssel) + \item + Wiederholungsschutz durch Zeitfenster (1-100 Sekunden) + + \begin{itemize} + \item + Sliding-Window-Mechanismus funktioniert nicht, da mehrere Absender + denselben SPI verwenden + \end{itemize} + \item + Zusätzliche Probleme mit zentralen Policy-Servern: + + \begin{itemize} + \item + schwacher Wiedergabeschutz + \item + Die Kompromittierung eines einzelnen Gateways beeinträchtigt das + gesamte VPN + \item + Rekeying durch symmetrischen Austausch \$\textbackslash Rightarrow\$ + kann nicht von kompromittierten Schlüsseln wiederhergestellt werden + \item + Perfektes Vorwärtsgeheimnis nicht verfügbar + \end{itemize} + \item + Einziger Vorteil: Ermöglicht Multicast-Netzwerkprivatisierung + \item + % \includegraphics{Assets/NetworkSecurity-GET.png} + \end{itemize} + + + \subsubsection{Proaktives Multicast-basiertes + IPsec-Erkennungsprotokoll} + + \begin{itemize} + \item + Ansatz wurde für militärische Anwendungen entwickelt {[}Tran06{]} + \item + Sicherheits-Gateways kündigen periodisch private Netzwerke an + \item + Erfolgt durch Transportnetzwerk-Multicast + \item + Nachrichten werden durch einen vorab geteilten symmetrischen Schlüssel + geschützt + \item + Vorteile: Unterstützt private Adressbereiche, Multicast innerhalb des + VPN + \item + Probleme: + + \begin{itemize} + \item + Erfordert Transportnetz-Multicast + \item + Verschachtelte Topologien funktionieren nicht + \item + Anzahl der empfangenen Nachrichten kann ziemlich groß sein + \item + Ein kompromittiertes Gateway führt zu einer nicht + wiederherstellbaren Kompromittierung des VPN + \item + Replay-Schutz nicht berücksichtigt + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-proactive-multicast-discovery.png} + \end{itemize} + + + \subsubsection{Soziales VPN} + + \begin{itemize} + \item + Akademischer Ansatz {[}FBJW08{]} + \item + Verwendet Facebook als ,,policy'' Server zum Austausch von IKE + Zertifikaten + + \begin{itemize} + \item + Man kann mit Freunden kommunizieren + \end{itemize} + \item + Agilität durch Peer-to-Peer-Netzwerk + + \begin{itemize} + \item + Schaut in einer verteilten Hash-Tabelle nach der externen IP-Adresse + des Ziels + \end{itemize} + \item + Probleme + + \begin{itemize} + \item + Keine Gateway-Funktionalität (nur Ende-zu-Ende) + \item + Keine verschachtelten Topologien + \item + Ziemlich großer Paket-Overhead + \item + Schlechte Skalierbarkeit im Falle vieler potentieller + Kommunikationspartner + \item + Sicherheit + + \begin{itemize} + \item + Vertrauen Sie Facebook? + \item + Wissen Sie, ob die Person in Facebook wirklich die ist, die sie + behauptet? + \item + Überhaupt keine Verifizierung möglich + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsubsection{Dynamisches Mehrpunkt-VPN + (DMVPN)} + + \begin{itemize} + \item + Ein weiterer Ansatz von Cisco {[}Bhai08{]} + \item + VPN ist aufgeteilt in + + \begin{itemize} + \item + Statische Kern-Gateways (,,Hubs'') + \item + Dynamische periphere Gateways (,,Spokes'') + \end{itemize} + \item + Hubs können OSPF-Routing zwischen den anderen nutzen + \item + Spokes kontaktieren vorkonfigurierte Hubs für den Zugang zum VPN + \item + Dynamische ,,Spoke-to-Spoke''-Verbindungen optimieren den Datenfluss + \item + % \includegraphics{Assets/NetworkSecurity-DMVPN.png} + \end{itemize} + + + \paragraph{Dynamisches Mehrpunkt-VPN (DMVPN) - + Diskussion} + + \begin{itemize} + \item + Vorteile + + \begin{itemize} + \item + Ansatz ermöglicht dynamischere Topologien + \item + Kann private Adressen verwenden + \end{itemize} + \item + Nachteilig + + \begin{itemize} + \item + Erfordert immer noch erheblichen Konfigurationsaufwand + + \begin{itemize} + \item + Kernnetz muss manuell konfiguriert werden + \item + Spokes müssen mit den Adressen der Hubs konfiguriert werden + \item + Macht z.B. einen einfachen Wechsel zu einem neuen ISP unmöglich + \end{itemize} + \item + Spokes können nicht verschachtelt werden + \item + Spokes können sich nicht zwischen ,,Hubs'' bewegen + + \begin{itemize} + \item + Hub verhält sich wie MobileIP Home Agent für Spoke + \end{itemize} + \item + Ausfall von ,,Hubs'' kritisch für deren ,,Spokes'' + \end{itemize} + \end{itemize} + + + \subsubsection{Sicheres OverLay für IPsec-Erkennung + (SOLID)} + + \begin{itemize} + \item + Komplexer Ansatz, verspricht einfache Implementierung {[}RSS10{]} + \item + Sicherheitsgateways bilden ein strukturiertes Overlay-Netzwerk + + \begin{itemize} + \item + Verbindet Sicherheitsgateways so, dass das VPN effizient nach einer + Zieladresse durchsucht werden kann + \end{itemize} + \item + Erfordert nur sehr wenige proaktiv erstellte IPsec-Verbindungen + + \begin{itemize} + \item + Minimale Konnektivität ermöglicht eine reaktive Erkennung von + Sicherheitsgateways + \item + Sich bewegende Sicherheitsgateways müssen nicht alle anderen über + die aktuelle externe IP-Adresse informieren + \end{itemize} + \item + Drei Aufgaben zu erfüllen + + \begin{itemize} + \item + Topologie-Kontrolle + + \begin{itemize} + \item + Proaktiver Aufbau einer VPN-Struktur zur schnellen Erkennung + \end{itemize} + \item + Erkennung von Sicherheitsgateways + + \begin{itemize} + \item + Jedes Mal, wenn ein Client-Computer ein Paket sendet und keine + gültige SA gefunden wird + \item + Muss das entsprechende Sicherheits-Gateway finden, um reaktiv eine + SA zu erstellen + \end{itemize} + \item + Weiterleitung von Datenpaketen + + \begin{itemize} + \item + Suche nach einem effizienten Weg zur Weiterleitung von Paketen + durch das Overlay + \end{itemize} + \end{itemize} + \end{itemize} + + + \paragraph{SOLID - + Topologie-Kontrolle} + + \begin{itemize} + \item + Mechanismen zur Topologiekontrolle + + \begin{itemize} + \item + Kontinuierliche Aktualisierung der VPN-Struktur zur Anpassung an + Veränderungen + \end{itemize} + \item + In SOLID werden proaktiv SAs erstellt, um eine künstliche Ringstruktur + zu bilden + \item + Sicherheitsgateways sind nach inneren Adressen geordnet + \item + Gateways, die nicht direkt im Transportnetz kommunizieren können, + werden durch virtuelle Pfade verbunden \$\textbackslash Rightarrow\$ + Verschachtelte Strukturen werden abgeflacht, um eine einfache + Erkennung zu ermöglichen + \item + % \includegraphics{Assets/NetworkSecurity-SOLID-topology.png} + \end{itemize} + + + \paragraph{SOLID - Erkennung} + + \begin{itemize} + \item + Reaktive Erkennung, um ein Sicherheits-Gateway für eine bestimmte + Client-IP-Adresse zu finden + \item + Suchanfragen werden an das (bereits zugeordnete) Gateway + weitergeleitet, dessen innere IP-Adresse der gesuchten IP-Adresse ,,am + ähnlichsten'' ist + + \begin{itemize} + \item + Ein einfacher Mechanismus stellt sicher, dass das korrekte + entsprechende Sicherheits-Gateway gefunden wird + \item + Die Pakete werden entlang der Ringstruktur gesendet + \item + Benötigt \$O(n)\$ Overlay Hops, um das Ziel zu erreichen (wobei n + die Anzahl der Netzwerke in der VPN-Topologie ist) + \end{itemize} + \item + \$\textbackslash Rightarrow\$ Kürzere ,,Suchpfade'' erforderlich + \end{itemize} + + + \paragraph{SOLID - Mehr + Topologiekontrolle} + + \begin{itemize} + \item + Erweiterte Topologiekontrolle schafft zusätzliche SAs + \item + IP-Adressraum des VPN wird in Bereiche unterteilt + + \begin{itemize} + \item + Exponentiell wachsende Größe der Bereiche + \end{itemize} + \item + Zu jedem Bereich wird mindestens eine SA proaktiv von jedem Gateway + gehalten + \item + Anzahl der zusätzlichen SAs wächst in \$O(log\textbackslash{} n)\$ + \item + Aufgrund der Konstruktionstechnik Entdeckung in + \$O(log\textbackslash{} n)\$ Overlay Hops + \$\textbackslash Rightarrow\$ Ansatz skaliert gut mit Anzahl der + Netzwerke + \item + % \includegraphics{Assets/NetworkSecurity-SOLID-topology-control.png} + \end{itemize} + + + \paragraph{SOLID - Weiterleitung von + Datenpaketen} + + \begin{itemize} + \item + Nach der anfänglichen Erkennung müssen die Datenpakete weitergeleitet + werden + \item + Senden von Daten entlang des Entdeckungspfades möglich + + \begin{itemize} + \item + Länge wieder \$O(log\textbackslash{} n)\$ Overlay-Hops + \item + Zu ineffizient, wenn viele Pakete geroutet werden müssen + \item + Wird nur anfangs verwendet + \end{itemize} + \item + Nachfolgend wird der Pfad optimiert + + \begin{itemize} + \item + Optimierung erfolgt, wenn Gateway feststellt, dass es Pakete für + zwei Gateways weiterleitet, die sich im gleichen Netz befinden + \item + Führt in zyklusfreien VPNs zu optimalen Routen in Bezug auf die + Anzahl der Overlay-Sprünge + \item + Kleine Zyklen können lokal umgangen werden + \end{itemize} + \end{itemize} + + + \paragraph{SOLID - Eigenschaften und + Ergebnisse} + + \begin{itemize} + \item + Kann komplexe Infrastrukturen innerhalb von Sekunden oder Minuten + konfigurieren + \item + Erfordert keine manuelle Interaktion + \item + Erfordert keine besonderen Eigenschaften des Transportnetzes + \item + Robustheit + + \begin{itemize} + \item + Kein einzelner Ausfallpunkt + \item + Wenn das Netzwerk aufgeteilt wird, können die Teile unabhängig + voneinander arbeiten + \end{itemize} + \item + Keine Schwächung der von Standard-IPsec gebotenen Sicherheit + \item + Gute Skalierbarkeit mit der Anzahl der privaten Netze, keine Engpässe + \item + Wenn Sicherheitsgateways umziehen, müssen nur zwei SAs + wiederhergestellt werden, um die Erreichbarkeit zu gewährleisten + \end{itemize} + + + \paragraph{SOLID - Simulative + Bewertung} + + \begin{itemize} + \item + SOLID kann in OMNeT++ evaluiert werden + \item + Ermöglicht Tests von komplexen Szenarien + \end{itemize} + + + \paragraph{SOLID - Sonstige + Forschung} + + \begin{itemize} + \item + SOLID wird in der Gruppe Telematik/Computernetzwerke erforscht + \item + Entwicklung von Prototypen + \item + Verfügbarkeit + + \begin{itemize} + \item + Schutz des wichtigeren Kernnetzes vor DoS-Angriffen + \item + Schaffung eines mehrschichtigen VPN, das bestimmte Verkehrsflüsse + zwischen Sicherheits-Gateways verhindert + \end{itemize} + \item + Zugriffskontrolle + \item + Robustheit + + \begin{itemize} + \item + Proaktive Wiederherstellung bei Netzwerkausfällen + \end{itemize} + \item + Anwendungsschicht-Multicast + + \begin{itemize} + \item + Ermöglicht sicheres Multicast über reine Unicast-Netze + \end{itemize} + \end{itemize} + + + \section{Sicherheitsprotokolle der + Transportschicht} + + + \subsection{Anwendungsbereich von Sicherheitsprotokollen der + Transportschicht} + + \begin{itemize} + \item + Die Transportschicht sorgt für die Kommunikation zwischen + Anwendungsprozessen (anstelle der Kommunikation zwischen Endsystemen) + und ihre Hauptaufgaben sind: + + \begin{itemize} + \item + Isolierung höherer Protokollschichten von der Technologie, der + Struktur und den Unzulänglichkeiten der eingesetzten + Kommunikationstechnik + \item + Transparente Übertragung von Nutzdaten + \item + Globale Adressierung von Anwendungsprozessen, unabhängig von + Adressen der unteren Schichten (Ethernet-Adressen, Telefonnummern + usw.) + \item + Gesamtziel: Bereitstellung eines effizienten und zuverlässigen + Dienstes + \end{itemize} + \item + Sicherheitsprotokolle der Transportschicht zielen darauf ab, den + Dienst der Transportschicht zu verbessern, indem sie zusätzliche + Sicherheitseigenschaften gewährleisten + + \begin{itemize} + \item + Da sie in der Regel einen zuverlässigen Transportdienst voraussetzen + und darauf aufbauen, stellen sie nach der Terminologie des + OSI-Referenzmodells (Open Systems Interconnection) eigentlich + Sitzungsschichtprotokolle dar. + \item + Da OSI jedoch nicht mehr ,,en vogue'' ist, werden sie als + Sicherheitsprotokolle der Transportschicht bezeichnet + \end{itemize} + \end{itemize} + + + \subsection{Das Secure Socket Layer (SSL) + Protokoll} + + \begin{itemize} + \item + SSL wurde ursprünglich in erster Linie zum Schutz von HTTP-Sitzungen + entwickelt: + + \begin{itemize} + \item + In den frühen 1990er Jahren gab es ein ähnliches Protokoll namens + S-HTTP + \item + Da jedoch S-HTTP-fähige Browser nicht kostenlos waren und SSL + Version 2.0 in den Browsern von Netscape Communications enthalten + war, setzte es sich schnell durch. + \item + SSL v.2 enthielt einige Schwachstellen, weshalb die Microsoft + Corporation ein konkurrierendes Protokoll namens Private + Communication Technology (PCT) entwickelte. + \item + Netscape verbesserte das Protokoll und SSL v.3 wurde zum + De-facto-Standardprotokoll für die Sicherung des HTTP-Verkehrs. + \item + Dennoch kann SSL eingesetzt werden, um beliebige Anwendungen zu + sichern, die über TCP laufen. + \item + 1996 beschloss die IETF, ein allgemeines Transport Layer Security + (TLS) Protokoll zu spezifizieren, das auf SSL basiert + \end{itemize} + \end{itemize} + + + \subsection{SSL-Sicherheitsdienste} + + \begin{itemize} + \item + Peer-Entity-Authentifizierung: + + \begin{itemize} + \item + Vor jeder Kommunikation zwischen einem Client und einem Server wird + ein Authentifizierungsprotokoll ausgeführt, um die Peer-Entitäten zu + authentifizieren. + \item + Nach erfolgreichem Abschluss des Authentifizierungsdialogs wird eine + SSL-Sitzung zwischen den Peer-Entities aufgebaut. + \end{itemize} + \item + Vertraulichkeit der Benutzerdaten: + + \begin{itemize} + \item + Falls beim Aufbau der Sitzung vereinbart, werden die Benutzerdaten + verschlüsselt. + \item + Es können verschiedene Verschlüsselungsalgorithmen ausgehandelt + werden: RC4, DES, 3DES, IDEA + \end{itemize} + \item + Integrität der Benutzerdaten: + + \begin{itemize} + \item + Ein MAC, der auf einer kryptografischen Hash-Funktion basiert, wird + an die Benutzerdaten angehängt. + \item + Der MAC wird mit einem ausgehandelten Geheimnis im + Präfix-Suffix-Modus errechnet. + \item + Für die MAC-Berechnung kann entweder MD5 oder SHA ausgehandelt + werden. + \end{itemize} + \end{itemize} + + + \subsection{SSL-Sitzungs- und + Verbindungsstatus} + + \begin{itemize} + \item + Sitzungsstatus: + + \begin{itemize} + \item + Sitzungskennzeichen: eine vom Server gewählte Bytefolge + \item + Peer-Zertifikat: X.509 v.3 Zertifikat der Gegenstelle (optional) + \item + Komprimierungsmethode: Algorithmus zur Komprimierung der Daten vor + der Verschlüsselung + \item + Cipher spec: spezifiziert kryptographische Algorithmen und Parameter + \item + Hauptgeheimnis: ein ausgehandeltes gemeinsames Geheimnis mit einer + Länge von 48 Byte + \item + Ist wiederaufnehmbar: ein Kennzeichen, das angibt, ob die Sitzung + neue Verbindungen unterstützt + \end{itemize} + \item + Verbindungsstatus: + + \begin{itemize} + \item + Server und Client random: von Server und Client gewählte Bytefolgen + \item + Server write MAC secret: wird in MAC-Berechnungen des Servers + verwendet + \item + Client write MAC secret: wird bei MAC-Berechnungen durch den Client + verwendet + \item + Server-Schreibschlüssel: wird für die Verschlüsselung durch den + Server und die Entschlüsselung durch den Client verwendet + \item + Client write key: wird für die Verschlüsselung durch den Client und + die Entschlüsselung durch den Server verwendet + \end{itemize} + \end{itemize} + + + \subsection{Architektur des + SSL-Protokolls} + + % \includegraphics{Assets/NetworkSecurity-ssl-protocol-architecture.png} + + \begin{itemize} + \item + SSL ist als eine mehrschichtige und modulare Protokollarchitektur + aufgebaut: + + \begin{itemize} + \item + Handshake: Authentifizierung und Aushandlung von Parametern + \item + Change Cipherspec: Signalisierung von Übergängen in der + Verschlüsselungsstrategie + \item + Alert: Signalisierung von Fehlerzuständen + \item + Application Data: Schnittstelle für den transparenten Zugriff auf + das Record-Protokoll + \item + Aufzeichnung: + + \begin{itemize} + \item + Fragmentierung der Nutzdaten in Klartextsätze der Länge + \$\textless{} 2\^{}\{14\}\$ + \item + Komprimierung (optional) von Klartextsätzen + \item + Verschlüsselung und Integritätsschutz (beides optional) + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{SSL-Record-Protokoll} + + % \includegraphics{Assets/NetworkSecurity-SSL-record-protocol.png} + + \begin{itemize} + \item + Inhaltstyp: + + \begin{itemize} + \item + Ändern Cipherspec. (20) + \item + Warnung (21) + \item + Handshake (22) + \item + Anwendungsdaten (23) + \end{itemize} + \item + Version: die Protokollversion von SSL (major = 3, minor = 0) + \item + Länge: die Länge der Daten in Bytes, darf nicht größer sein als + \$2\^{}\{14\} + 2\^{}\{10\}\$ + \end{itemize} + + + \subsection{Verarbeitung des + SSL-Datensatzprotokolls} + + \begin{itemize} + \item + Absendende Seite: + + \begin{itemize} + \item + Die Datensatzschicht fragmentiert zunächst die Nutzdaten in + Datensätze mit einer maximalen Länge von \$2\^{}\{14\}\$ Oktetten, + wobei mehrere Nachrichten desselben Inhaltstyps zu einem Datensatz + zusammengefasst werden können + \item + Nach der Fragmentierung werden die Daten des Datensatzes + komprimiert, der Standardalgorithmus hierfür ist null + (\textasciitilde{} keine Komprimierung), und er darf die Länge des + Datensatzes nicht um mehr als \$2\^{}\{10\}\$ Oktette erhöhen + \item + Ein Nachrichtenauthentifizierungscode wird an die Datensatzdaten + angehängt: + + \begin{itemize} + \item + \$MAC = H(MAC\_write\_secret + pad\_2 + H(MAC\_write\_secret + + pad\_1 + seqnum + length + data))\$ + \item + Man beachte, dass seqnum nicht übertragen wird, da es implizit + bekannt ist und das zugrundeliegende TCP einen gesicherten Dienst + bietet + \end{itemize} + \item + Die Daten des Datensatzes und der MAC werden mit dem in der + aktuellen Chiffriervorschrift definierten + Verschlüsselungsalgorithmus verschlüsselt (dies kann ein vorheriges + Auffüllen erfordern) + \end{itemize} + \item + Empfängerseite: + + \begin{itemize} + \item + Der Datensatz wird entschlüsselt, auf Integrität geprüft, + dekomprimiert, de-fragmentiert und an die Anwendung oder das + SSL-Protokoll der höheren Schicht übergeben + \end{itemize} + \end{itemize} + + + \subsection{SSL Handshake Protokoll: + Einführung} + + \begin{itemize} + \item + Das SSL-Handshake-Protokoll wird verwendet, um die + Peer-Authentifizierung und die kryptographischen Parameter für eine + SSL-Sitzung festzulegen. + \item + Eine SSL-Sitzung kann so ausgehandelt werden, dass sie wieder + aufgenommen werden kann: + + \begin{itemize} + \item + Die Wiederaufnahme und Duplizierung von SSL-Sitzungen ermöglicht die + Wiederverwendung des etablierten Sicherheitskontextes. + \item + Dies ist für die Absicherung des HTTP-Verkehrs sehr wichtig, da in + der Regel für jedes Element einer Webseite eine eigene + TCP-Verbindung aufgebaut wird. + + \begin{itemize} + \item + Seit HTTP 1.1 werden persistente TCP-Verbindungen verwendet. + \item + Dennoch ist die Wiederaufnahme von SSL-Sitzungen sehr sinnvoll, da + persistente TCP-Verbindungen nach dem Herunterladen aller + Elemente, die zu einer Seite gehören, und einer gewissen Zeit der + Inaktivität des Benutzers geschlossen werden können. + \end{itemize} + \item + Bei der Wiederaufnahme / Duplizierung einer bestehenden Sitzung wird + ein abgekürzter Handshake durchgeführt + \end{itemize} + \end{itemize} + + + \subsection{SSL Handshake Protokoll: Vollständiger + Handshake} + + %\begin{longtable}[]{@{}lll@{}} + % \toprule + % Client & & Server\tabularnewline + % \midrule + % \endhead + % ClientHello & -\/-\/-\textgreater{} & \tabularnewline + % & & ServerHello\tabularnewline + % & & {[}ServerCertificate{]}\tabularnewline + % & & {[}CertificateRequest{]}\tabularnewline + % & & {[}ServerKeyExchange{]}\tabularnewline + % & \textless-\/-\/- & ServerHelloDone\tabularnewline + % {[}ClientCertificate{]} & & \tabularnewline + % ClientKeyExchange & & \tabularnewline + % {[}CertificateVerify{]} & & \tabularnewline + % ChangeCipherSpec & & \tabularnewline + % Finished & -\/-\/-\textgreater{} & \tabularnewline + % & & ChangeCipherSpec\tabularnewline + % & \textless-\/-\/- & Finished\tabularnewline + % \bottomrule + %\end{longtable} + + {[}...{]} kennzeichnet optionale Nachrichten + + + \subsection{SSL Handshake Protokoll: Abgekürzter + Handshake} + + %\begin{longtable}[]{@{}lll@{}} + % \toprule + % Client & & Server\tabularnewline + % \midrule + % \endhead + % ClientHello(SessionID) & -\/-\/-\textgreater{} & \tabularnewline + % & & ServerHello(SessionID)\tabularnewline + % & & ChangeCipherSpec\tabularnewline + % & \textless-\/-\/- & Finished\tabularnewline + % ChangeCipherSpec & & \tabularnewline + % Finished & -\/-\/-\textgreater{} & \tabularnewline + % \bottomrule + %\end{longtable} + + \begin{itemize} + \item + Die Nachricht "Finished" enthält eine MAC, die entweder auf MD5 oder + SHA basiert und das Master-Secret enthält, das zuvor zwischen Client + und Server festgelegt wurde. + \item + Wenn der Server die Sitzung nicht fortsetzen kann / beschließt, sie + nicht fortzusetzen, antwortet er mit den Nachrichten des vollständigen + Handshake + \end{itemize} + + + \subsection{SSL-Handshake-Protokoll: Kryptografische + Aspekte} + + \begin{itemize} + \item + SSL unterstützt drei Methoden zur Erstellung von Sitzungsschlüsseln: + + \begin{itemize} + \item + RSA: ein Pre-Master-Geheimnis wird vom Client zufällig generiert und + mit dem öffentlichen Schlüssel des Servers verschlüsselt an den + Server gesendet + \item + Diffie-Hellman: Es wird ein Standard-Diffie-Hellman-Austausch + durchgeführt, und das ermittelte gemeinsame Geheimnis wird als + Pre-Master-Secret verwendet. + \item + Fortezza: eine unveröffentlichte, von der NSA entwickelte + Sicherheitstechnologie, die eine Schlüsselhinterlegung unterstützt + und in diesem Kurs nicht behandelt wird + \end{itemize} + \item + Da SSL in erster Linie für die Sicherung des HTTP-Verkehrs entwickelt + wurde, ist das ,,Standardanwendungsszenario'' ein Client, der auf + einen authentischen Webserver zugreifen möchte: + + \begin{itemize} + \item + In diesem Fall sendet der Webserver sein Zertifikat mit dem + öffentlichen Schlüssel nach der ServerHello-Nachricht + \item + Das Server-Zertifikat kann die öffentlichen DH-Werte des Servers + enthalten oder der Server kann sie in der optionalen + ServerKeyExchange-Nachricht senden + \item + Der Client verwendet das Zertifikat des Servers / die empfangenen + DH-Werte / seine Fortezza-Karte, um einen RSA- / DH- / + Fortezza-basierten Schlüsselaustausch durchzuführen. + \end{itemize} + \item + Das Pre-Master-Secret und die Zufallszahlen, die der Client und der + Server in ihren Hallo-Nachrichten angeben, werden verwendet, um das + Master-Secret der Länge 48 Byte zu generieren. + \item + Berechnung des Master-Geheimnisses: + + \begin{itemize} + \item + Master-Geheimnis = MD5(vor-Master-Geheimnis + SHA('A' + + vor-Master-Geheimnis + ClientHello.random + ServerHello.random)) + + MD5(Vor-Hauptgeheimnis + SHA('BB' + Vor-Hauptgeheimnis + + ClientHello.random + ServerHello.random)) + MD5(pre-master-secret + + SHA('CCC' + pre-master-secret + ClientHello.random + + ServerHello.random)) + \end{itemize} + \item + Die Verwendung von MD5 und SHA zur Generierung des Master-Geheimnisses + wird als sicher angesehen, selbst wenn eine der kryptografischen + Hash-Funktionen ,,defekt'' ist. + \item + Um die Sitzungsschlüssel aus dem Master-Secret zu berechnen, wird in + einem ersten Schritt eine ausreichende Menge an Schlüsselmaterial aus + dem Master-Secret und den Zufallszahlen von Client und Server erzeugt: + + \begin{itemize} + \item + key\_block = MD5(master-secret + SHA('A' + master-secret + + ClientHello.random + ServerHello.random)) + MD5(master-secret + + SHA('BB' + master-secret + ClientHello.random + ServerHello.random)) + + {[}...{]} + \end{itemize} + \item + Anschließend wird das Material des Sitzungsschlüssels fortlaufend aus + dem key\_block entnommen: + + \begin{itemize} + \item + client\_write\_MAC\_secret = key\_block{[}1, + CipherSpec.hash\_size{]} + \item + server\_write\_MAC\_secret = key\_block{[}i 1 , i 1 + + CipherSpec.hash\_size - 1{]} + \item + client\_write\_key = key\_block{[}i 2 , i 2 + + CipherSpec.key\_material - 1{]} + \item + server\_write\_key = key\_block{[}i 3 , i 3 + + CipherSpec.key\_material - 1{]} + \item + client\_write\_IV = key\_block{[}i 4 , i 4 + CipherSpec.IV\_size - + 1{]} + \item + server\_write\_IV = key\_block{[}i 5 , i 5 + CipherSpec.IV\_size - + 1{]} + \end{itemize} + \item + Authentifizierung von und mit dem Pre-Master-Secret: + + \begin{itemize} + \item + SSL unterstützt Schlüsselerstellung ohne Authentifizierung (anonym), + in diesem Fall können Man-in-the-Middle-Angriffe nicht abgewehrt + werden + \item + Bei Verwendung des RSA-basierten Schlüsselaustauschs: + + \begin{itemize} + \item + Der Client verschlüsselt das Pre-Master-Secret mit dem + öffentlichen Schlüssel des Servers, der durch eine + Zertifikatskette überprüft werden kann. + \item + Der Client weiß, dass nur der Server das Pre-Master-Secret + entschlüsseln kann. Wenn der Server also die fertige Nachricht mit + dem Master-Secret sendet, kann der Client die Server-Authentizität + ableiten. + \item + Der Server kann aus dem empfangenen Pre-Master-Secret keine + Client-Authentizität ableiten. + \item + Wenn Client-Authentizität erforderlich ist, sendet der Client + zusätzlich sein Zertifikat und eine CertificateVerify-Nachricht, + die eine Signatur über einen Hash (MD5 oder SHA) des + Master-Geheimnisses und aller vor der CertificateVerify-Nachricht + ausgetauschten Handshake-Nachrichten enthält + \end{itemize} + \item + Beim DH-Key-Austausch wird die Authentizität aus den DH-Werten + abgeleitet, die im Zertifikat des Servers (und des Clients) + enthalten und signiert sind + \end{itemize} + \end{itemize} + + + \subsection{SSL Handshake Protokoll: Eine + Sicherheitslücke} + + \begin{itemize} + \item + 1998 entdeckte D. Bleichenbacher eine Schwachstelle im + Verschlüsselungsstandard PKCS \#1 (v.1.5), der im + SSL-Handshake-Verfahren verwendet wird + \item + Wenn der Client das Pre-Master-Secret mit dem öffentlichen Schlüssel + des Servers verschlüsselt, verwendet er PKCS \#1, um es vor der + Verschlüsselung zu formatieren: + + \begin{itemize} + \item + EM = 0x02 \textbar{} PS \textbar{} 0x00 \textbar{} M + + \begin{itemize} + \item + wobei PS eine Auffüllzeichenfolge von mindestens 8 pseudozufällig + erzeugten Nicht-Null-Oktetts und M die zu verschlüsselnde + Nachricht (= Pre-Master-Secret) bezeichnet + \item + (PS wird verwendet, um eine Zufallskomponente hinzuzufügen und M + auf die Modulusgröße des verwendeten Schlüssels aufzufüllen) + \end{itemize} + \item + Dann wird EM verschlüsselt: \$C = E(+K\_\{Server\}, EM)\$ + \item + Nachdem der Server C entschlüsselt hat, prüft er, ob das erste + Oktett gleich 0x ist und ob es ein 0x00-Oktett gibt; wenn diese + Prüfung fehlschlägt, antwortet er mit einer Fehlermeldung + \item + Diese Fehlermeldung kann von einem Angreifer genutzt werden, um + einen ,,Orakel-Angriff'' zu starten. + \end{itemize} + \item + Ein Orakel-Angriff gegen das SSL-Handshake-Protokoll {[}BKS98a{]}: + + \begin{itemize} + \item + Betrachten wir einen Angreifer (Eve), der einen SSL-Handshake-Dialog + belauscht hat und das Pre-Master-Secret (und damit alle anderen + abgeleiteten Geheimnisse), das zwischen Alice (Client) und Bob + (Server) ausgetauscht wurde, wiederherstellen möchte + \item + Eve hat die verschlüsselte Nachricht C, die das Pre-Master-Secret + enthält, erfolgreich abgehört und möchte nun den Klartext + wiederherstellen + \item + Eve generiert eine Reihe zusammenhängender Chiffretexte \$C\_1 , + C\_2 , ...\$: + + \begin{itemize} + \item + \$C\_i = C\textbackslash times R\_i\^{}e\textbackslash{} + mod\textbackslash{} n\$, wobei \$(e, n)\$ der öffentliche + Schlüssel von Bob ist + \item + Die \$R\_i\$ werden adaptiv ausgewählt, abhängig von älteren + ,,guten'' \$R\_i\$, die von Bob verarbeitet wurden, ohne + Fehlermeldungen zu erzeugen (was anzeigt, dass sie zu einer + gültigen PKCS-1-Nachricht entschlüsselt wurden) + \item + Die \$C\_i\$ werden an Bob übermittelt, und es werden entsprechend + neue \$C\_i\$ erzeugt + \item + Aus dem ,,guten'' \$R\_i\$ leitet Eve bestimmte Bits der + entsprechenden Nachricht \$M\_i= C\_i\^{}d = M\textbackslash times + R\_i\textbackslash{} mod\textbackslash{} n\$ ab, basierend auf der + PKCS \#1 Verschlüsselungsmethode + \end{itemize} + \item + Aus den abgeleiteten Bits von \$M\textbackslash times + R\_i\textbackslash{} mod\textbackslash{} n\$ für hinreichend viele + \$R\_i\$ kann Eve die Größe des Intervalls reduzieren, das die + unbekannte Nachricht M enthalten muss + \item + Im Wesentlichen halbiert jeder ,,gute'' Chiffretext das betreffende + Intervall, so dass Eve mit genügend ,,guten'' Chiffretexten in der + Lage ist, M + \item + Mit PKCS \#1 Version 1.5 (wie ursprünglich in SSL V.3.0 verwendet) + wird ungefähr einer von \$2\^{}\{16\}\$ bis \$2\^{}\{18\}\$ zufällig + ausgewählten Chiffretexten ,,gut'' sein. + \item + Typischerweise beträgt die Gesamtzahl der erforderlichen + Chiffretexte bei einem \$1024\$-Bit-Modul etwa \$2\^{}\{20\}\$, und + dies ist auch die Anzahl der Abfragen an Bob + \item + Nach der Durchführung von etwa 1 Million gefälschter + SSL-Handshake-Dialoge (die alle entweder von Bob oder Eve + unterbrochen werden) ist Eve also in der Lage, das Pre-Master-Secret + und alle abgeleiteten Schlüssel einer zuvor eingerichteten + SSL-Sitzung zwischen Alice und Bob wiederherzustellen. Subtile + Protokollinteraktionen (hier: SSL und PKCS \#1) können zum Versagen + eines Sicherheitsprotokolls führen, selbst wenn der grundlegende + kryptographische Algorithmus (hier: RSA) selbst nicht gebrochen ist! + \end{itemize} + \item + Gegenmassnahmen: + + \begin{itemize} + \item + Regelmäßiger Wechsel der öffentlichen Schlüsselpaare + (\$\textbackslash Rightarrow\$-Overhead) + \item + Verringerung der Wahrscheinlichkeit, ,,gute'' Chiffriertexte zu + erhalten, indem das Format der entschlüsselten Chiffriertexte + gründlich überprüft und dem Client ein identisches Verhalten + (Fehlermeldung, Zeitverhalten usw.) gezeigt wird + \item + Der Kunde muss den Klartext kennen, bevor er antwortet, ob die + Nachricht erfolgreich entschlüsselt werden konnte. + \item + Hinzufügen einer Struktur zum Klartext, z. B. durch Hinzufügen eines + Hashwerts zum Klartext: + + \begin{itemize} + \item + Achtung: Es ist eine gewisse Vorsicht geboten, um Anfälligkeiten + für eine andere Klasse von Angriffen zu vermeiden {[}Cop96a{]}. + \end{itemize} + \item + Änderung des Verschlüsselungsprotokolls für öffentliche Schlüssel, + d.h. Überarbeitung von PKCS \#1: + + \begin{itemize} + \item + PKCS \#1 Version 2.1 bereitet den Klartext vor der Verschlüsselung + mit einer Methode vor, die als optimales asymmetrisches + Verschlüsselungs-Padding (OAEP) bezeichnet wird, um die PKCS \#1 + Entschlüsselungsprozedur ,,plaintext aware'' zu machen, was + bedeutet, dass es nicht möglich ist, einen gültigen Chiffretext zu + konstruieren, ohne den entsprechenden Klartext zu kennen + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{SSL-Chiffre-Suiten} + + \begin{itemize} + \item + Kein Schutz (Standard-Suite): + + \begin{itemize} + \item + CipherSuite SSL\_NULL\_WITH\_NULL\_NULL = \{ 0x00,0x00 \} + \end{itemize} + \item + Der Server stellt einen für die Verschlüsselung geeigneten + RSA-Schlüssel bereit: + + \begin{itemize} + \item + SSL\_RSA\_WITH\_NULL\_MD5 = \{ 0x00,0x01 \} + \item + SSL\_RSA\_WITH\_NULL\_SHA = \{ 0x00,0x02 \} + \item + SSL\_RSA\_EXPORT\_WITH\_RC4\_40\_MD5 = \{ 0x00,0x03 \} + \item + SSL\_RSA\_WITH\_RC4\_128\_MD5 = \{ 0x00,0x04 \} + \item + SSL\_RSA\_WITH\_RC4\_128\_SHA = \{ 0x00,0x05 \} + \item + SSL\_RSA\_EXPORT\_WITH\_RC2\_CBC\_40\_MD5 = \{ 0x00,0x06 \} + \item + SSL\_RSA\_WITH\_IDEA\_CBC\_SHA = \{ 0x00,0x07 \} + \item + SSL\_RSA\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x08 \} + \item + SSL\_RSA\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x09 \} + \item + SSL\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x0A \} + \end{itemize} + \item + Cipher-Suites mit authentifiziertem DH-Schlüssel-Austausch + + \begin{itemize} + \item + SSL\_DH\_DSS\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x0B \} + \item + SSL\_DH\_DSS\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x0C \} + \item + SSL\_DH\_DSS\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x0D \} + \item + SSL\_DH\_RSA\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x0E \} + \item + SSL\_DH\_RSA\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x0F \} + \item + SSL\_DH\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x10 \} + \item + SSL\_DHE\_DSS\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x11 \} + \item + SSL\_DHE\_DSS\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x12 \} + \item + SSL\_DHE\_DSS\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x13 \} + \item + SSL\_DHE\_RSA\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x14 \} + \item + SSL\_DHE\_RSA\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x15 \} + \item + SSL\_DHE\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x16 \} + \end{itemize} + \end{itemize} + + (DH steht für Suites, bei denen die öffentlichen DH-Werte in einem von + einer CA signierten Zertifikat enthalten sind, DHE für Suites, bei denen + sie mit einem öffentlichen Schlüssel signiert sind, der von einer CA + zertifiziert ist) + + \begin{itemize} + \item + Von der Verwendung der folgenden Chiffriersuiten ohne jegliche + Authentifizierung der Entität wird dringend abgeraten, da sie anfällig + für Man-in-the-Middle-Angriffe sind: + + \begin{itemize} + \item + SSL\_DH\_anon\_EXPORT\_WITH\_RC4\_40\_MD5 = \{ 0x00,0x17 \} + \item + SSL\_DH\_anon\_WITH\_RC4\_128\_MD5 = \{ 0x00,0x18 \} + \item + SSL\_DH\_anon\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x19 \} + \item + SSL\_DH\_anon\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x1A \} + \item + SSL\_DH\_anon\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x1B \} + \end{itemize} + \item + Die letzte Cipher Suite ist für den Fortezza-Token: + + \begin{itemize} + \item + SSL\_FORTEZZA\_DMS\_WITH\_NULL\_SHA = \{ 0x00,0x1C \} + \item + SSL\_FORTEZZA\_DMS\_WITH\_FORTEZZA\_CBC\_SHA = \{ 0x00,0x1D \} + \end{itemize} + \end{itemize} + + (Diese Cipher-Suites müssen natürlich nicht auswendig gelernt werden und + werden hier nur aufgeführt, um die Flexibilität des SSL-Protokolls zu + verdeutlichen) + + + \subsection{Das Transport Layer + Security-Protokoll} + + \begin{itemize} + \item + 1996 gründete die IETF eine Arbeitsgruppe zur Definition eines + Transport Layer Security (TLS) Protokolls: + + \begin{itemize} + \item + Offiziell wurde angekündigt, die Protokolle SSL, SSH und PCT als + Input zu nehmen. + \item + Der im Dezember 1996 veröffentlichte Entwurf der TLS + V.1.0-Spezifikation war jedoch im Wesentlichen identisch mit der SSL + V.3.0-Spezifikation + \end{itemize} + \item + Eigentlich war es von Anfang an die Absicht der Arbeitsgruppe, TLS auf + SSL V.3.0 mit den folgenden Änderungen aufzubauen: + + \begin{itemize} + \item + Die HMAC-Konstruktion zur Berechnung kryptographischer Hash-Werte + sollte anstelle von Hashing im Präfix- und Suffix-Modus übernommen + werden. + \item + Die auf Fortezza basierenden Chiffrier-Suiten von SSL sollten + entfernt werden, da sie eine unveröffentlichte Technologie enthalten + \item + Ein auf dem DSS (Digital Signature Standard) basierender Dialog zur + Authentifizierung und zum Schlüsselaustausch sollte aufgenommen + werden. + \item + Das TLS-Record-Protokoll und das Handshake-Protokoll sollten + getrennt und in separaten Dokumenten klarer spezifiziert werden, was + bisher nicht geschehen ist. + \end{itemize} + \item + Um die Exportfähigkeit von TLS-konformen Produkten zu erreichen, wurde + in einigen Chiffriersuiten die Verwendung von Schlüsseln mit einer auf + 40 Bit reduzierten Entropie vorgeschrieben. + + \begin{itemize} + \item + Von der Verwendung dieser Cipher-Suites wird dringend abgeraten, da + sie praktisch keinen Schutz der Vertraulichkeit von Daten bieten. + \end{itemize} + \item + Ab TLS 1.2 (RFC 5246): + + \begin{itemize} + \item + Schlüsselaustausch-Algorithmen: + + \begin{itemize} + \item + DH oder ECDH Austausch ohne oder mit DSS / RSA / ECDSA Signaturen + \item + DH-Austausch mit zertifizierten öffentlichen DH-Parametern + \item + RSA-basierter Schlüsselaustausch + \item + keine + \end{itemize} + \item + Verschlüsselungsalgorithmen: AES / 3DES in CBC / CCM /GCM, RC4, null + \item + Hash-Algorithmen: MD5, SHA-1, SHA-256, SHA-384, SHA-512, null + \item + Premaster Secret: Keine MD5/SHA-1 Kombination, sondern nur SHA-256! + \end{itemize} + \item + Was die Protokollfunktionen betrifft, ist TLS im Wesentlichen dasselbe + wie SSL + \item + Sicherheit: + + \begin{itemize} + \item + In SSL 3.0 und TLS 1.0 ist der Initialisierungsvektor eines im + CBC-Modus verschlüsselten Datensatzes der letzte Block des + vorherigen Datensatzes + \item + Wenn ein Angreifer den Inhalt des vorherigen Datensatzes + kontrolliert, kann er einen adaptiven Klartextangriff durchführen, + um den Inhalt des nächsten Datensatzes herauszufinden. + \item + Durchführbar für Webverkehr, d. h. Erzeugen von Verkehr mit + JavaScript und Beobachten von außen, führt zum sogenannten + BEAST-Angriff (Browser Exploit Against SSL/TLS) {[}RD10{]}. + \item + Auch für VPN-Verkehr machbar + \item + Abgeschwächt durch TLS 1.1, wo explizite IVs verwendet werden + \item + 2009 wurde eine sogenannte TLS-Neuverhandlungsschwachstelle + identifiziert + + \begin{itemize} + \item + Angreifer können sie nutzen, um einer legitimen Sitzung durch + einen Man-in-the-Middle-Angriff Daten voranzustellen (Details in + {[}Zo11{]}) + \item + Die Auswirkungen hängen stark von dem verwendeten + Anwendungsprotokoll ab + \end{itemize} + \item + Bei HTTPS führt dies zu mehreren Ausnutzungsmöglichkeiten, z. B, + + \begin{itemize} + \item + Angreifer injeziert: + \texttt{GET\ /ebanking/transfer?what=LotsOfMoney\&to=eve\ HTTP/1.1\ \textless{}crlf\textgreater{}\ X-Ignore:\ \textless{}no\ crlf\textgreater{}} + \item + Alice sendet: \texttt{GET\ /ebanking/start.html\ HTTP/1.1} + \item + Die Anfrage wird in eine valide HTTP Anfrage umgewandelt: + \texttt{GET\ /ebanking/transfer?what=LotsOfMoney\&to=eve\ HTTP/1.1\ \textless{}crlf\textgreater{}\ X-Ignore:\ GET\ /ebanking/start.html\ HTTP/1.1} + \end{itemize} + \item + Abgeschwächt durch Identifizierung neu ausgehandelter Sitzungen mit + einer anderen ID {[}RRDO10{]} + \end{itemize} + \end{itemize} + + + \subsection{Das Datagram Transport Layer Security + Protokoll} + + \begin{itemize} + \item + TLS bietet sichere Kommunikation über ein zuverlässiges + Transportprotokoll + \item + DTLS ist so angepasst, dass es über unzuverlässige Transportprotokolle + wie z.B. UDP funktioniert + \item + Wird zum Schutz verwendet: + + \begin{itemize} + \item + Sprach- und Videodaten in Echtzeit, insbesondere Voice-over-IP + \item + Getunnelte TCP-Daten (da TCP über TCP eine schlechte Idee für die + Leistung ist) + \end{itemize} + \item + DTLS basiert derzeit auf TLS 1.2, enthält jedoch einige Änderungen: + + \begin{itemize} + \item + Bietet + + \begin{itemize} + \item + Nachrichtenwiederholungen, um verlorenen Handshake-Paketen + entgegenzuwirken + \item + Eigener Fragmentierungsmechanismus, um große Handshake-Pakete zu + ermöglichen + \end{itemize} + \item + Hinzufügen von Sequenznummern, um neu geordnete Datenpakete zu + ermöglichen (und Verbot von Stromchiffren, z. B. RC4) + \item + Fügt einen Mechanismus hinzu, um zu erkennen, dass ein Client die + ,,Verbindung'' mit denselben Ports neu gestartet hat (z. B. nach + einem Anwendungsabsturz) + \item + Fügt einen Wiedergabeschutz durch ein gleitendes Fenster hinzu (wie + bei IPsec) + \item + Fügt eine Cookie-basierte DoS-Abwehr hinzu (wie bei IKEv2) + \end{itemize} + \end{itemize} + + + \subsection{Das Secure + Shell-Protokoll} + + \begin{itemize} + \item + Secure Shell (SSH) Version 1 wurde ursprünglich von Tatu Ylönen an der + Universität Helsinki in Finnland entwickelt. + \item + Da der Autor auch eine kostenlose Implementierung mit Quellcode zur + Verfügung stellte, fand das Protokoll weite Verbreitung im Internet + \item + Später wurde die Entwicklung von SSH durch den Autor kommerzialisiert. + \item + Nichtsdestotrotz sind immer noch kostenlose Versionen verfügbar, wobei + die am weitesten verbreitete Version OpenSSH ist + \item + 1997 wurde eine Spezifikation der Version 2.0 von SSH bei der IETF + eingereicht und seitdem in einer Reihe von Internet-Entwürfen + verfeinert + \item + SSH wurde ursprünglich entwickelt, um einen sicheren Ersatz für die + Unix r-Tools (rlogin, rsh, rcp und rdist) zu bieten, und stellt somit + ein Protokoll der Anwendungs- oder Sitzungsschicht dar. + \item + Da SSH jedoch auch ein allgemeines Sicherheitsprotokoll der + Transportschicht enthält und Tunneling-Fähigkeiten bietet, wird es in + diesem Kapitel als Sicherheitsprotokoll der Transportschicht behandelt + \end{itemize} + + + \subsection{SSH Version 2} + + \begin{itemize} + \item + SSH Version 2 ist in mehreren separaten Dokumenten spezifiziert, z.B.: + + \begin{itemize} + \item + SSH Protocol Assigned Numbers {[}LL06{]} + \item + SSH-Protokollarchitektur {[}YL06a{]} + \item + SSH-Authentifizierungsprotokoll {[}YL06b{]} + \item + SSH-Transportschichtprotokoll {[}YL06c{]} + \item + SSH-Verbindungsprotokoll {[}YL06d{]} + \end{itemize} + \item + SSH-Architektur: + + \begin{itemize} + \item + SSH verfolgt einen Client-Server-Ansatz + \item + Jeder SSH-Server hat mindestens einen Host-Schlüssel + \item + SSH Version 2 bietet zwei verschiedene Vertrauensmodelle: + + \begin{itemize} + \item + Jeder Client hat eine lokale Datenbank, die jeden Hostnamen mit + dem entsprechenden öffentlichen Hostschlüssel verknüpft + \item + Die Zuordnung von Hostname zu öffentlichem Schlüssel wird von + einer Zertifizierungsstelle zertifiziert, und jeder Client kennt + den öffentlichen Schlüssel der Zertifizierungsstelle + \end{itemize} + \item + Das Protokoll ermöglicht die vollständige Aushandlung von + Algorithmen und Formaten für Verschlüsselung, Integrität, + Schlüsselaustausch, Komprimierung und öffentliche Schlüssel + \end{itemize} + \end{itemize} + + + \subsection{SSH-Transportprotokoll} + + \begin{itemize} + \item + SSH verwendet ein zuverlässiges Transportprotokoll (normalerweise + TCP). + \item + Es bietet die folgenden Dienste: + + \begin{itemize} + \item + Verschlüsselung von Benutzerdaten + \item + Authentifizierung der Datenherkunft (Integrität) + \item + Server-Authentifizierung (nur Host-Authentifizierung) + \item + Komprimierung der Benutzerdaten vor der Verschlüsselung + \end{itemize} + \item + Unterstützte Algorithmen: + + \begin{itemize} + \item + Verschlüsselung: + + \begin{itemize} + \item + AES, 3DES, Blowfish, Twofish, Serpent, IDEA und CAST in CBC + \item + AES in GCM {[}IS09{]} + \item + Arcfour (,,vermutlich'' kompatibel mit dem ,,unveröffentlichten'' + RC4) + \item + keine (nicht empfohlen) + \end{itemize} + \item + Integrität: + + \begin{itemize} + \item + HMAC mit MD5, SHA-1, SHA-256 oder SHA-512 + \item + keine (nicht empfohlen) + \end{itemize} + \item + Schlüsselaustausch: + + \begin{itemize} + \item + Diffie-Hellman mit SHA-1 und zwei vordefinierten Gruppen + \item + ECDH mit mehreren vordefinierten NIST-Gruppen {[}SG09{]} + (obligatorisch drei Kurven über $\mathbb{Z}_p$) + \item + Öffentlicher Schlüssel: RSA, DSS, ECC (in mehreren Varianten + {[}SG09{]}) + \end{itemize} + \item + Komprimierung: keine, zlib (siehe RFCs 1950, 1951) + \end{itemize} + \end{itemize} + + + \subsection{SSH-Transportprotokoll + Paketformat} + + % \includegraphics{Assets/NetworkSecurity-ssh-transport-protocol-packet.png} + + \begin{itemize} + \item + Das Paketformat ist nicht 32-Bit-wortorientiert + \item + Felder des Pakets: + + \begin{itemize} + \item + Paketlänge: die Länge des Pakets selbst, ohne dieses Längenfeld und + den MAC + \item + Padding length: Länge des Padding-Feldes, muss zwischen vier und 255 + liegen + \item + Payload: die eigentliche Nutzlast des Pakets, wenn Komprimierung + ausgehandelt wurde, wird dieses Feld komprimiert + \item + Padding: dieses Feld besteht aus zufällig ausgewählten Oktetten, um + die Nutzlast auf ein ganzzahliges Vielfaches von 8 oder der + Blockgröße des Verschlüsselungsalgorithmus aufzufüllen, je nachdem, + welcher Wert größer ist + \item + MAC: Wurde die Nachrichtenauthentifizierung ausgehandelt, enthält + dieses Feld den MAC des gesamten Pakets ohne das MAC-Feld selbst; + soll das Paket verschlüsselt werden, wird der MAC vor der + Verschlüsselung wie folgt berechnet + + \begin{itemize} + \item + MAC = HMAC(shared\_secret, seq\_number \textbar\textbar{} + unencrypted\_packet), wobei seq\_number eine 32-Bit-Sequenznummer + für jedes Paket bezeichnet + \end{itemize} + \end{itemize} + \item + Verschlüsselung: wenn Verschlüsselung ausgehandelt wird, wird das + gesamte Paket ohne MAC nach der MAC-Berechnung verschlüsselt + \end{itemize} + + + \subsection{SSH-Aushandlung, Schlüsselaustausch und + Server-Authentifizierung} + + \begin{itemize} + \item + Algorithmus-Aushandlung: + + \begin{itemize} + \item + Jede Entität sendet ein Paket (bezeichnet als kexinit ) mit einer + Spezifikation der von ihr unterstützten Methoden in der Reihenfolge + ihrer Präferenz + \item + Beide Entitäten iterieren über die Liste des Clients und wählen den + ersten Algorithmus, der auch vom Server unterstützt wird + \item + Diese Methode wird verwendet, um Folgendes auszuhandeln: + Server-Host-Schlüssel-Algorithmus (\textasciitilde{} + Server-Authentifizierung) sowie Verschlüsselungs-, MAC- und + Kompressionsalgorithmus + \item + Zusätzlich kann jede Entität ein Schlüsselaustauschpaket + entsprechend einer Vermutung über den bevorzugten + Schlüsselaustauschalgorithmus der anderen Entität anhängen + \item + Ist eine Vermutung richtig, wird das entsprechende + Schlüsselaustauschpaket als erstes Schlüsselaustauschpaket der + anderen Entität akzeptiert + \item + Falsche Vermutungen werden ignoriert und neue + Schlüsselaustauschpakete werden nach Aushandlung des Algorithmus + gesendet + \end{itemize} + \item + Für den Schlüsselaustausch definiert {[}YL06c{]} nur eine Methode: + + \begin{itemize} + \item + Diffie-Hellman mit SHA-1 und zwei vordefinierten Gruppen (1024 und + 2048 Bit) + \item + Z.B. \$p = 2\^{}\{1024\} -2\^{}\{960\} - 1 + + (2\^{}\{64\}\textbackslash times \textbackslash lfloor 2894 + \textbackslash times \textbackslash pi + + 129093\textbackslash rfloor); g = 2\$ + \end{itemize} + \item + Wenn der Schlüsselaustausch mit der vordefinierten DH-Gruppe + durchgeführt wird: + + \begin{itemize} + \item + Der Client wählt eine Zufallszahl \$x\$, berechnet + \$e=g\^{}x\textbackslash{} mod\textbackslash{} p\$ und sendet \$e\$ + an den Server + \item + Der Server wählt eine Zufallszahl \$y\$, errechnet + \$f=g\^{}y\textbackslash{} mod\textbackslash{} p\$ + \item + Nach dem Empfang von \$e\$ berechnet der Server ferner + \$K=e\^{}y\textbackslash{} mod\textbackslash{} p\$ und einen + Hash-Wert \$h = Hash(version\_C, version\_S, kexinit\_C, kexinit\_S, + +K\_S, e, f, K)\$, wobei version und kexinit die + Versionsinformationen des Clients und des Servers sowie die + anfänglichen Algorithmus-Aushandlungsmeldungen bezeichnen + \item + Der Server signiert h mit seinem privaten Host-Schlüssel - KS und + sendet dem Client eine Nachricht mit \$(+K\_S, f, s)\$. + \item + Beim Empfang prüft der Client den Host-Schlüssel \$+K\_S\$, + berechnet \$K=f\^{}x\textbackslash{} mod\textbackslash{} p\$ sowie + den Hash-Wert \$h\$ und prüft dann die Signatur \$s\$ über \$h\$ + \end{itemize} + \item + Nach diesen Prüfungen kann der Client sicher sein, dass er tatsächlich + ein geheimes K mit dem Host ausgehandelt hat, der \$-K\_S\$ kennt. + \item + Der Server-Host kann jedoch keine Rückschlüsse auf die Authentizität + des Clients ziehen; zu diesem Zweck wird das + SSH-Authentifizierungsprotokoll verwendet + \end{itemize} + + + \subsection{SSH-Sitzungsschlüssel-Ableitung} + + \begin{itemize} + \item + Die Methode des Schlüsselaustauschs ermöglicht es, ein gemeinsames + Geheimnis K und den Hash-Wert h zu ermitteln, die zur Ableitung der + SSH-Sitzungsschlüssel verwendet werden: + + \begin{itemize} + \item + Der Hashwert h des anfänglichen Schlüsselaustauschs wird auch als + session\_id verwendet + \item + \$IV\_\{Client2Server\}\$ = Hash(K, h, ,,A'', session\_id) // + Initialisierungsvektor + \item + \$IV\_\{Server2Client\}\$ = Hash(K, h, ,,B'', session\_id) // + Initialisierungsvektor + \item + \$EK\_\{Client2Server\}\$ = Hash(K, h, ,,C'', session\_id) // + Verschlüsselungsschlüssel + \item + \$EK\_\{Server2Client\}\$ = Hash(K, h, ,,D'', session\_id) // + Chiffrierschlüssel + \item + \$IK\_\{Client2Server\}\$ = Hash(K, h, ,,E'', session\_id) // + Integritätsschlüssel + \item + \$IK\_\{Server2Client\}\$ = Hash(K, h, ,,F'', session\_id) // + Integritätsschlüssel + \end{itemize} + \item + Die Schlüsseldaten werden am Anfang der Hash-Ausgabe entnommen + \item + Wenn mehr Schlüsselbits benötigt werden als von der Hash-Funktion + erzeugt werden: + + \begin{itemize} + \item + K1 = Hash(K, h, x, session\_id) // x = ,,A'', ,,B'', usw. + \item + K2 = Hash(K, h, K1) + \item + K2 = Hash(K, h, K1, K2) + \item + XK = K1 \textbar\textbar{} K2 \textbar\textbar{} ... + \end{itemize} + \end{itemize} + + + \subsection{SSH-Authentifizierungsprotokoll} + + \begin{itemize} + \item + Das SSH-Authentifizierungsprotokoll dient zur Überprüfung der + Identität des Clients und ist für die Ausführung über das + SSH-Transportprotokoll vorgesehen + \item + Das Protokoll unterstützt standardmäßig die folgenden + Authentifizierungsmethoden: + + \begin{itemize} + \item + Öffentlicher Schlüssel: Der Benutzer erzeugt und sendet eine + Signatur mit einem öffentlichen Schlüssel pro Benutzer an den Server + \item + \$Client\textbackslash rightarrow Server: E(-K\_\{Benutzer\}, + (session\_id, 50, Name\_\{Benutzer\}, Service, ,,publickey'', True, + PublicKeyAlgorithmName, +K\_\{Benutzer\}))\$ + \item + Kennwort: Übertragung eines Kennworts pro Benutzer in der + verschlüsselten SSH-Sitzung (das Kennwort wird dem Server im + Klartext präsentiert, aber mit Verschlüsselung des + SSH-Transportprotokolls übertragen) + \item + Host-basiert: analog zum öffentlichen Schlüssel, aber mit einem + öffentlichen Schlüssel pro Host + \item + Keine: wird verwendet, um den Server nach unterstützten Methoden zu + fragen und wenn keine Authentifizierung erforderlich ist (der Server + antwortet direkt mit einer Erfolgsmeldung) + \end{itemize} + \item + Wenn die Authentifizierungsnachricht des Clients erfolgreich geprüft + wurde, antwortet der Server mit einer + ssh\_msg\_userauth\_success-Nachricht + \end{itemize} + + + \subsection{SSH-Verbindungsprotokoll} + + \begin{itemize} + \item + Das SSH-Verbindungsprotokoll läuft auf dem SSH-Transportprotokoll und + bietet folgende Dienste: + + \begin{itemize} + \item + Interaktive Anmeldesitzungen + \item + Fernausführung von Befehlen + \item + Weitergeleitete TCP/IP-Verbindungen + \item + Weitergeleitete X11-Verbindungen + \end{itemize} + \item + Für jeden der oben genannten Dienste werden ein oder mehrere + ,,Kanäle'' eingerichtet, und alle Kanäle werden in eine einzige + verschlüsselte und integritätsgeschützte + SSH-Transportprotokollverbindung gemultiplext: + + \begin{itemize} + \item + Beide Seiten können die Eröffnung eines Kanals beantragen, und die + Kanäle werden durch Nummern beim Sender und beim Empfänger + gekennzeichnet. + \item + Kanäle sind typisiert, z. B. ,,session'', ,,x11'', + ,,forwarded-tcpip'', ,,direct-tcpip'' ... + \item + Kanäle werden durch einen Fenstermechanismus kontrolliert, und es + dürfen keine Daten über einen Kanal gesendet werden, bevor ,,window + space'' verfügbar ist + \end{itemize} + \item + Öffnen eines Kanals: + + \begin{itemize} + \item + Beide Seiten können die Nachricht ssh\_msg\_channel\_open senden, + die mit dem Nachrichtencode 90 und den folgenden Parametern + signalisiert wird: + + \begin{itemize} + \item + Kanaltyp: ist vom Datentyp String, z.B. ,,session'', ,,x11'', etc. + \item + Absenderkanal: ist ein lokaler Bezeichner vom Typ uint32 und wird + vom Anforderer dieses Kanals gewählt + \item + initial window size: ist vom Typ uint32 und gibt an, wie viele + Bytes an den Initiator gesendet werden dürfen, bevor das Fenster + vergrößert werden muss + \item + maximale Paketgröße: ist vom Typ uint32 und legt die maximale + Paketgröße fest, die der Initiator für diesen Kanal zu akzeptieren + bereit ist + \item + weitere Parameter, die vom Typ des Kanals abhängen, können folgen + \end{itemize} + \item + Wenn der Empfänger dieser Nachricht die Kanalanfrage nicht annehmen + will, antwortet er mit der Nachricht + ssh\_msg\_channel\_open\_failure (Code 92): + + \begin{itemize} + \item + Empfängerkanal: die vom Absender in der Öffnungsanfrage angegebene + ID + \item + reason code: ist vom Typ uint32 und gibt den Grund für die + Ablehnung an + \item + additional textual information: ist vom Typ string + \item + language tag: ist vom Typ string und entspricht dem RFC 1766 + \end{itemize} + \item + Wenn der Empfänger dieser Nachricht die Kanalanfrage annehmen will, + antwortet er mit der Nachricht ssh\_msg\_channel\_open\_confirmation + (Code 91) und den folgenden Parametern + + \begin{itemize} + \item + Empfänger-Kanal: die vom Absender in der Öffnungsanforderung + angegebene ID + \item + Absenderkanal: die dem Kanal vom Antwortenden gegebene Kennung + \item + initial window size: ist vom Typ uint32 und gibt an, wie viele + Bytes an den Responder gesendet werden können, bevor das Fenster + vergrößert werden muss + \item + maximum packet size: ist vom Typ uint32 und legt die maximale + Paketgröße fest, die der Responder für diesen Kanal zu akzeptieren + bereit ist + \item + weitere Parameter, die vom Kanaltyp abhängen, können folgen + \end{itemize} + \end{itemize} + \item + Sobald ein Kanal geöffnet ist, sind die folgenden Aktionen möglich: + + \begin{itemize} + \item + Datenübertragung (allerdings sollte die empfangende Seite wissen, + ,,was mit den Daten zu tun ist'', was eine weitere vorherige + Aushandlung erfordern kann) + \item + Kanaltypspezifische Anfragen + \item + Schließung des Kanals + \end{itemize} + \item + Für die Datenübertragung sind die folgenden Nachrichten definiert: + + \begin{itemize} + \item + ssh\_msg\_channel\_data: mit den beiden Parametern Empfängerkanal, + Daten + \item + ssh\_msg\_channel\_extended\_data: erlaubt die zusätzliche Angabe + eines Datentypcodes und ist nützlich, um Fehler zu signalisieren, + z.B. bei interaktiven Shells + \item + ssh\_msg\_channel\_window\_adjust: erlaubt es, das + Flusskontrollfenster des Empfängerkanals um die angegebene Anzahl + von Bytes zu erweitern + \end{itemize} + \item + Schließen von Kanälen: + + \begin{itemize} + \item + Wenn eine Peer-Entität keine Daten mehr an einen Kanal senden will, + sollte sie dies der anderen Seite mit der Nachricht + ssh\_msg\_channel\_eof signalisieren + \item + Wenn eine der beiden Seiten einen Kanal beenden möchte, sendet sie + die Nachricht ssh\_msg\_channel\_close mit dem Parameter recipient + channel + \item + Beim Empfang der Nachricht ssh\_msg\_channel\_close muss eine + Peer-Entität mit einer ähnlichen Nachricht antworten, es sei denn, + sie hat bereits die Schließung dieses Kanals beantragt. + \item + Sowohl nach dem Empfang als auch nach dem Senden der Nachricht + ssh\_msg\_channel\_close für einen bestimmten Kanal kann die ID + dieses Kanals wiederverwendet werden. + \end{itemize} + \item + Kanaltypspezifische Anfragen erlauben es, bestimmte Eigenschaften + eines Kanals anzufordern, z. B. dass die empfangende Seite weiß, wie + sie die über diesen Kanal gesendeten Daten verarbeiten soll, und + werden mit signalisiert: + + \begin{itemize} + \item + ssh\_msg\_channel\_request: mit den Parametern recipient channel, + request type (string), want reply (bool) und weiteren + anfragespezifischen Parametern + \item + ssh\_msg\_channel\_success: mit dem Parameter recipient channel + \item + ssh\_msg\_channel\_failure: mit dem Parameter recipient channel + \end{itemize} + \item + Beispiel 1 - Anfordern einer interaktiven Sitzung und Starten einer + Shell darin: + + \begin{itemize} + \item + Zunächst wird ein Kanal vom Typ ,,session'' geöffnet + \item + Ein Pseudo-Terminal wird angefordert, indem eine + ssh\_msg\_channel\_request-Nachricht gesendet wird, wobei der + Anforderungstyp auf ,,pty-req'' gesetzt wird + \item + Falls erforderlich, können Umgebungsvariablen gesetzt werden, indem + ssh\_msg\_channel\_request-Nachrichten mit dem Anforderungstyp + ,,env'' gesendet werden. + \item + Dann wird der Start eines Shell-Prozesses über eine + ssh\_msg\_channel\_request-Nachricht mit dem Request-Typ ,,shell'' + gefordert (dies führt normalerweise zum Start der Standard-Shell für + den Benutzer, wie sie in /etc/passwd definiert ist) + \item + Anfordern einer interaktiven Sitzung und Starten einer Shell darin: + \textbar{} SSH Client \textbar{} \textbar{} SSH Server \textbar{} + \textbar{} + -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- + \textbar{} -\/-\/-\/- \textbar{} + -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- + \textbar{} \textbar{} ssh\_msg\_channel\_open (,,session'', 20, + 2048, 512) \textbar{} -\/-\/-\textgreater{} \textbar{} \textbar{} + \textbar{} \textless-\/-\/- \textbar{} + ssh\_msg\_channel\_open\_confirmation(20, 31, 1024, 256) \textbar{} + \textbar{} ssh\_msg\_channel\_request (31, ,,pty-req'', false, ...) + \textbar{} -\/-\/-\textgreater{} \textbar{} \textbar{} + ssh\_msg\_channel\_request (31, ,,env'', false, ,,home'', + ,,/home/username'') \textbar{} -\/-\/-\textgreater{} \textbar{} + \textbar{} ssh\_msg\_channel\_request (31, ,,shell'', true, ...) + \textbar{} -\/-\/-\textgreater{} \textbar{} \textbar{} \textbar{} + \textless-\/-\/- \textbar{} ssh\_msg\_channel\_success(20) + \textbar{} + + {[}Nutzdatenaustausch findet ab jetzt statt...{]} + \end{itemize} + \end{itemize} + + + \subsection{SSH-Verbindungsprotokoll + II} + + \begin{itemize} + \item + Beispiel 2 - Anforderung der X11-Weiterleitung: + + \begin{itemize} + \item + Zuerst wird ein Kanal des Typs ,,session'' geöffnet + \item + Die X11-Weiterleitung wird durch Senden einer + ssh\_msg\_channel\_request-Nachricht mit dem Anforderungstyp + ,,x11-req'' angefordert + \item + Wenn später eine Anwendung auf dem Server gestartet wird, die auf + das Terminal des Client-Rechners zugreifen muss (der X11-Server, der + auf dem Client-Rechner läuft), wird ein neuer Kanal über + ssh\_msg\_channel\_open geöffnet, wobei der Kanaltyp auf ,,x11'' und + die IP-Adresse und Portnummer des Absenders als zusätzliche + Parameter gesetzt werden + \end{itemize} + \item + Beispiel 3 - Einrichtung einer TCP/IP-Portweiterleitung: + + \begin{itemize} + \item + Eine Partei muss die Portweiterleitung von ihrem eigenen Ende in die + andere Richtung nicht explizit anfordern. Wenn sie jedoch + Verbindungen zu einem Port auf der anderen Seite an ihre eigene + Seite weiterleiten lassen möchte, muss sie dies explizit über eine + ssh\_msg\_global\_request-Nachricht mit den Parametern + ,,tcpip-forward'', want-reply, zu bindende Adresse (,,0.0.0.0'' für + jede Quelladresse) und zu bindende Portnummer anfordern (diese + Anforderung wird normalerweise vom Client gesendet) + \item + Wenn eine Verbindung zu einem Port kommt, für den eine Weiterleitung + angefordert wurde, wird ein neuer Kanal über ssh\_msg\_channel\_open + mit dem Typ ,,forwarded-tcpip'' und den Adressen des Ports, der + verbunden wurde, sowie des ursprünglichen Quellports als Parameter + geöffnet (diese Nachricht wird normalerweise vom Server gesendet) + \item + Wenn eine Verbindung zu einem (Client-)Port kommt, der lokal als + weitergeleitet eingestellt ist, wird ein neuer Kanal angefordert, + wobei der Typ auf ,,direct-tcpip'' gesetzt wird und die folgenden + Adressinformationen in zusätzlichen Parametern angegeben werden: + + \begin{itemize} + \item + host to connect, port to connect: Adresse, mit der der Empfänger + diesen Kanal verbinden soll + \item + Absender-IP-Adresse, Absender-Port: Quelladresse der Verbindung + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Schlussfolgerung} + + \begin{itemize} + \item + Sowohl SSL, TLS als auch SSH eignen sich für die Sicherung der + Internet-Kommunikation in der (oberen) Transportschicht: + + \begin{itemize} + \item + Alle drei Sicherheitsprotokolle arbeiten mit einem zuverlässigen + Transportdienst, z. B. TCP, und benötigen diesen. + \item + Es gibt eine datagrammorientierte Variante von TLS, genannt DTLS + \item + Obwohl SSH in / oberhalb der Transportschicht arbeitet, ist die + Server-Authentifizierung hostbasiert und nicht anwendungsbasiert. + \item + Sicherheitsprotokolle der Transportschicht bieten echten + End-to-End-Schutz für Benutzerdaten, die zwischen + Anwendungsprozessen ausgetauscht werden. + \item + Außerdem können sie mit der Paketfilterung der heutigen Firewalls + zusammenarbeiten. + \item + Die Protokoll-Header-Felder von Protokollen der unteren Schicht + können jedoch nicht auf diese Weise geschützt werden, so dass sie + keine Gegenmaßnahmen für Bedrohungen der Netzinfrastruktur selbst + bieten. + \end{itemize} + \end{itemize} + + + \section{Sicherheitsaspekte der mobilen + Kommunikation} + + \begin{itemize} + \item + Die mobile Kommunikation ist mit den gleichen Bedrohungen konfrontiert + wie ihr stationäres Pendant: + + \begin{itemize} + \item + Maskerade, Abhören, Verletzung von Berechtigungen, Verlust oder + Veränderung von übertragenen Informationen, Ablehnung von + Kommunikationsakten, Fälschung von Informationen, Sabotage + \item + Es müssen also ähnliche Maßnahmen wie in Festnetzen ergriffen + werden. + \end{itemize} + \item + Es gibt jedoch einige spezifische Probleme, die sich aus der Mobilität + von Benutzern und/oder Geräten ergeben: + + \begin{itemize} + \item + Einige bereits bestehende Bedrohungen werden noch gefährlicher: + + \begin{itemize} + \item + Die drahtlose Kommunikation ist für Abhörmaßnahmen leichter + zugänglich. + \item + Das Fehlen einer physischen Verbindung macht den Zugang zu + Diensten einfacher + \end{itemize} + \item + Einige neue Schwierigkeiten bei der Realisierung von + Sicherheitsdiensten: + + \begin{itemize} + \item + Die Authentifizierung muss neu eingerichtet werden, wenn das + mobile Gerät umzieht. + \item + Die Schlüsselverwaltung wird schwieriger, da die Identitäten der + Peers nicht im Voraus festgelegt werden können. + \end{itemize} + \item + Eine völlig neue Bedrohung: + + \begin{itemize} + \item + Der Standort eines Geräts/Nutzers wird zu einer wichtigeren + Information, die abzuhören und damit zu schützen sich lohnt + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsection{Standortdatenschutz in + Mobilfunknetzen} + + \begin{itemize} + \item + In den heutigen Mobilfunknetzen gibt es keinen angemessenen Schutz des + Standortes: + + \begin{itemize} + \item + GSM / UMTS / LTE: + + \begin{itemize} + \item + Aktive Angreifer können IMSIs auf der Luftschnittstelle sammeln + \item + Die Betreiber des besuchten Netzes können den Standort der Nutzer + teilweise verfolgen. + \item + Die Betreiber des Heimatnetzes können den Standort des Nutzers + vollständig verfolgen. + \item + Zumindest kommunizierende Endsysteme können den Standort eines + mobilen Geräts jedoch nicht in Erfahrung bringen + \end{itemize} + \end{itemize} + \item + Drahtloses LAN: + + \begin{itemize} + \item + Kein Datenschutz für den Standort, da die (weltweit eindeutige) + MAC-Adresse in jedem MAC-Frame immer im Klartext enthalten ist + \end{itemize} + \item + Das grundlegende Problem des Datenschutzes: + + \begin{itemize} + \item + Ein mobiles Gerät sollte erreichbar sein + \item + Keine (einzelne) Entität im Netz sollte in der Lage sein, den + Standort eines mobilen Geräts zu verfolgen + \end{itemize} + \item + Einige grundlegende Ansätze zur Lösung dieses Problems + {[}Müller99a{]}: + + \begin{itemize} + \item + Broadcast von Nachrichten: + + \begin{itemize} + \item + Jede Nachricht wird an jeden möglichen Empfänger gesendet + \item + Wenn Vertraulichkeit erforderlich ist, wird die Nachricht + asymmetrisch verschlüsselt + \item + Dieser Ansatz ist nicht gut skalierbar für große Netzwerke / hohe + Last + \end{itemize} + \item + Temporäre Pseudonyme: + + \begin{itemize} + \item + Mobile Geräte verwenden Pseudonyme, die regelmäßig gewechselt + werden + \item + Um das mobile Gerät zu erreichen, ist jedoch eine + Abbildungsinstanz erforderlich, die die Geschichte der Pseudonyme + des Mobiltelefons verfolgen kann. + \end{itemize} + \item + Gemischte Netzwerke: + + \begin{itemize} + \item + Nachrichten werden über verschiedene Entitäten (Mixes) geleitet + und jede Entität kann nur einen Teil der Nachrichtenroute erfahren + (siehe unten) + \end{itemize} + \end{itemize} + \item + Adressierungsschemata für standortbezogenen Datenschutz mit Broadcast: + + \begin{itemize} + \item + Explizite Adressen: + + \begin{itemize} + \item + Jede Entität, die eine explizite Adresse "sieht", kann die + adressierte Entität bestimmen + \end{itemize} + \item + Implizite Adressen: + + \begin{itemize} + \item + Eine implizite Adresse identifiziert kein bestimmtes Gerät oder + einen bestimmten Ort, sondern benennt lediglich eine Einheit, ohne + dass dem Namen eine weitere Bedeutung beigemessen wird. + \item + Sichtbare implizite Adressen: + + \begin{itemize} + \item + Entitäten, die mehrere Vorkommen einer Adresse sehen, können auf + Gleichheit prüfen + \end{itemize} + \item + Unsichtbare implizite Adressen: + + \begin{itemize} + \item + Nur die adressierte Einheit kann die Gleichheit der Adresse + überprüfen. + \item + Dies erfordert Operationen mit öffentlichen Schlüsseln: + \$ImplAddr\_A =\{r\_B, r\_A\}\_\{+K\_A\}\$ wobei \$r\_A\$ von + der adressierten Entität gewählt wird und \$r\_B\$ ein + Zufallswert ist, der von einer Entität \$B\$ erzeugt wird, die + unsichtbar auf die Entität \$A\$ verweisen will + \end{itemize} + \end{itemize} + \end{itemize} + \item + Vorübergehende Pseudonyme: + + \begin{itemize} + \item + Der Standort eines Gerätes A wird nicht mehr mit seiner Kennung + \$ID\_A\$, sondern mit einem wechselnden Pseudonym \$P\_A(t)\$ + gespeichert. + + \begin{itemize} + \item + Beispiel: VLRs in GSM kennen und speichern möglicherweise nur die + TMSI (die eine Art temporäres Pseudonym ist) + \end{itemize} + \item + Die Zuordnung einer IDA zum aktuellen Pseudonym \$P\_A(t)\$ wird in + einem vertrauenswürdigen Gerät gespeichert + + \begin{itemize} + \item + Beispiel: GSM HLRs könnten als vertrauenswürdige Geräte realisiert + werden + \end{itemize} + \item + Wenn ein eingehender Anruf an den aktuellen Standort von Gerät A + weitergeleitet werden muss: + + \begin{itemize} + \item + Der Netzbetreiber von Gerät A fragt das vertrauenswürdige Gerät + nach dem aktuellen Pseudonym \$P\_A(t)\$ + \item + Das Netz leitet den Anruf dann an den aktuellen Standort von A + weiter, indem es das temporäre Pseudonym in einer + Standortdatenbank nachschlägt. + \item + Es ist wichtig, dass die Einrichtungen, die einen Anruf + weiterleiten, nichts über die ursprüngliche Adresse der + Rufaufbau-Nachricht erfahren können (\$\textbackslash rightarrow\$ + implizite Adressen) + \item + Die Verwendung von Mischungen (siehe unten) kann einen + zusätzlichen Schutz gegen Angriffe von kolludierenden + Netzeinheiten bieten + \end{itemize} + \end{itemize} + \item + Kommunikations-Mixe: + + \begin{itemize} + \item + Das Konzept wurde 1981 von D. Chaum für nicht zurückverfolgbare + E-Mail-Kommunikation erfunden + \item + Ein Mix verbirgt die Kommunikationsbeziehungen zwischen Absendern + und Empfängern: + + \begin{itemize} + \item + Er puffert eingehende Nachrichten, die asymmetrisch verschlüsselt + sind, so dass nur der Mix sie entschlüsseln kann. + \item + Er verändert das "Aussehen" von Nachrichten, indem er sie + entschlüsselt + \item + Er ändert die Reihenfolge der Nachrichten und leitet sie in + Stapeln weiter. + \item + Wenn jedoch der Mix kompromittiert wird, kann ein Angreifer + "alles" erfahren. + \end{itemize} + \item + Die Sicherheit kann durch kaskadierende Mixe erhöht werden. + \item + Beispiel: A sendet eine Nachricht m an B über zwei Mixe M1 und M2 + + \begin{itemize} + \item + \$A\textbackslash rightarrow M1: \{r\_1 ,\{r\_2 ,\{r\_3 , + m\}\emph{\{+K\_B\}\}}\{+K\_\{M2\}\}\}\emph{\{+K}\{M1\}\}\$ + \item + \$M1\textbackslash rightarrow M2:\{r\_2 ,\{r\_3 , + m\}\emph{\{+K\_B\}\}}\{+K\{M2\}\}\$ + \item + \$M2\textbackslash rightarrow B: \{r\_3 , m\}\_\{+K\_B\}\$ + \item + Es ist wichtig, dass die Mischungen "genug" Nachrichten + verarbeiten + \end{itemize} + \item + Dieses Konzept lässt sich auf die mobile Kommunikation übertragen + {[}Müller99a{]} + \end{itemize} + \end{itemize} + + + \section{Sicherheit von drahtlosen lokalen + Netzen} + + + \subsection{IEEE 802.11} + + \begin{itemize} + \item + IEEE 802.11 {[}IEEE12{]} standardisiert die Medienzugriffskontrolle + (MAC) und die physikalischen Eigenschaften eines drahtlosen lokalen + Netzwerks (LAN). + \item + Der Standard umfasst mehrere physikalische Schichteinheiten: + + \begin{itemize} + \item + Derzeit zwischen 1-300 Mbit/s + \item + 2,4-GHz-Band und 5-GHz-Band + \item + Viele verschiedene Modulationsverfahren + \end{itemize} + \item + Die Übertragung im lizenzfreien 2,4-GHz-Band impliziert: + + \begin{itemize} + \item + Medium-Sharing mit unfreiwilligen 802.11-Geräten + \item + Überlappung von logisch getrennten Wireless LANs + \item + Überlappung mit Nicht-802.11-Geräten + \end{itemize} + \item + Die Medienzugriffskontrolle (MAC) unterstützt sowohl den Betrieb unter + Kontrolle eines Access Points als auch zwischen unabhängigen + Stationen. + \item + In diesem Kurs werden wir uns hauptsächlich auf die + (Un-)Sicherheitsaspekte des Standards konzentrieren! + \end{itemize} + + 802.11 - Architektur eines Infrastrukturnetzes + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-802.11-network-architecture.png} + \item + Station (STA): Endgerät mit Zugriffsmechanismen auf das drahtlose + Medium und Funkkontakt zum Access Point + \item + Basic Service Set (BSS): Gruppe von Stationen, die dieselbe + Funkfrequenz verwenden + \item + Zugangspunkt: Station, die in das drahtlose LAN und das + Verteilungssystem integriert ist + \item + Portal: Brücke zu anderen (kabelgebundenen) Netzwerken + \item + Verteilungssystem: Verbindungsnetz zur Bildung eines logischen Netzes + (Extended Service Set, ESS), das auf mehreren BSS basiert + \end{itemize} + + 802.11 - Architektur eines Ad-Hoc-Netzes + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-802.11-ad-hoc-architecture.png} + \item + Station (STA): Endgerät mit Zugriffsmechanismen auf das drahtlose + Medium + \item + Basic Service Set (BSS): Gruppe von Stationen, die dieselbe + Funkfrequenz verwenden + \item + Ad-Hoc-Netze ermöglichen die direkte Kommunikation zwischen + Endsystemen innerhalb einer begrenzten Reichweite + \item + Da es keine Infrastruktur gibt, ist keine Kommunikation zwischen + verschiedenen BSSs möglich + \end{itemize} + + Sicherheitsdienste von IEEE 802.11 + + \begin{itemize} + \item + Die Sicherheitsdienste von IEEE 802.11 wurden ursprünglich wie folgt + realisiert: + + \begin{itemize} + \item + Authentifizierungsdienst für Entitäten + \item + Wired Equivalent Privacy (WEP) Mechanismus + \end{itemize} + \item + WEP soll die folgenden Sicherheitsdienste bieten + + \begin{itemize} + \item + Vertraulichkeit + \item + Authentifizierung der Datenherkunft / Datenintegrität + \item + Zugangskontrolle in Verbindung mit Schichtenmanagement + \end{itemize} + \item + WEP verwendet die folgenden Algorithmen: + + \begin{itemize} + \item + Die RC4-Stromchiffre (siehe Kapitel 3) + \item + Die CRC-Prüfsumme (Cyclic Redundancy Code) zur Fehlererkennung + \end{itemize} + \end{itemize} + + + \subsection{Der zyklische + Redundanzcode} + + \begin{itemize} + \item + Der zyklische Redundanzcode (CRC) ist ein Fehlererkennungscode + \item + Mathematische Grundlage: + + \begin{itemize} + \item + Bitstrings werden als Darstellungen von Polynomen mit den + Koeffizienten 0 und 1 behandelt \$\textbackslash Rightarrow\$ Ein + Bitstring, der eine Nachricht M darstellt, wird als M(x) + interpretiert + \item + Polynomarithmetik wird modulo 2 durchgeführt + \$\textbackslash Rightarrow\$ Addition und Subtraktion sind + identisch mit XOR + \end{itemize} + \item + CRC-Berechnung für eine Nachricht \$M(x)\$: + + \begin{itemize} + \item + A und B einigen sich auf ein Polynom \$G(x)\$; üblicherweise ist + \$G(x)\$ standardisiert + \item + Sei \$n\$ der Grad von \$G(x)\$, d.h. die Länge von \$G(x)\$ sei + \$n+1\$ + \item + Wenn dann \$\textbackslash frac\{M(x)\textbackslash times + 2\^{}n\}\{G(x)\}=Q(x)+\textbackslash frac\{R(x)\}\{G(x)\}\$ gilt + \$\textbackslash frac\{M(x)\textbackslash times 2\^{}n + +R(x)\}\{G(x)\}\$ wobei \$R(x)\$ der Rest von \$M(x)\$ geteilt durch + \$G(x)\$ ist + \item + Normalerweise wird \$R(x)\$ vor der Übertragung an \$M(x)\$ + angehängt, und \$Q(x)\$ ist nicht von Interesse, da es nur geprüft + wird, wenn \$\textbackslash frac\{M(x)\textbackslash times + 2\^{}n+R(x)\}\{G(x)\}\$ mit Rest \$0\$ dividiert + \end{itemize} + \item + Betrachten wir nun zwei Nachrichten \$M\_1\$ und \$M\_2\$ mit CRCs + \$R\_1\$ und \$R\_2\$: + + \begin{itemize} + \item + Da \$\textbackslash frac\{M\_1(x)\textbackslash times + 2\^{}n+R\_1(x)\}\{G(x)\}\$ und + \$\textbackslash frac\{M\_2(x)\textbackslash times + 2\^{}n+R\_2(x)\}\{G(x)\}\$ mit dem Rest \$0\$ teilen, teilt sich + auch \$\textbackslash frac\{M\_1(x)\textbackslash times 2\^{}n + +R\_1(x)+M\_2(x)\textbackslash times 2\^{}n +R\_2(x)\}\{G(x)\} + =\textbackslash frac\{(M\_1(x)+M\_2(x))\textbackslash times 2\^{}n + +(R\_1(x)+R\_2(x))\}\{G(x)\}\$ teilt mit Rest \$0\$ + \item + \$\textbackslash Rightarrow\$ CRC ist linear, d.h. \$CRC(M\_1 + + M\_2) = CRC(M\_1) + CRC(M\_2)\$ + \end{itemize} + \item + Diese Eigenschaft macht CRC schwach für kryptographische Zwecke! + \end{itemize} + + + \subsection{IEEE 802.11 + Entity-Authentifizierung} + + \begin{itemize} + \item + Ursprünglich gibt es die IEEE 802.11-Authentifizierung in zwei + ,,Geschmacksrichtungen'': + + \begin{itemize} + \item + Offene System-Authentifizierung: ,,Im Wesentlichen handelt es sich + um einen Null-Authentifizierungsalgorithmus.'' (IEEE 802.11) + \item + Shared-Key-Authentifizierung: + + \begin{itemize} + \item + Die ,,Shared-Key-Authentifizierung unterstützt die + Authentifizierung von STAs entweder als Mitglied derer, die einen + gemeinsamen geheimen Schlüssel kennen, oder als Mitglied derer, + die ihn nicht kennen.'' (IEEE 802.11, Abschnitt 8.1.2) + \item + Es wird davon ausgegangen, dass der erforderliche geheime, + gemeinsam genutzte Schlüssel den teilnehmenden STAs über einen + sicheren, von IEEE 802.11 unabhängigen Kanal übermittelt wurde. + \end{itemize} + \end{itemize} + \end{itemize} + + IEEE 802.11's Shared Key Authentication Dialog: + + \begin{itemize} + \item + Die Authentifizierung sollte zwischen Stationen und Zugangspunkten + erfolgen und könnte auch zwischen beliebigen Stationen durchgeführt + werden. + \item + Bei der Authentifizierung fungiert eine Station als Requestor (A) und + die andere als Responder (B) + \item + Der Authentifizierungsdialog: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$A \textbackslash rightarrow B: (Authentifizierung, 1, ID\_A)\$ + \item + \$B \textbackslash rightarrow A: (Authentifizierung, 2, r\_B)\$ + \item + \$A \textbackslash rightarrow B: \{Authentifizierung, 3, + r\_B\}\emph{\{K}\{A,B\}\}\$ + \item + \$B \textbackslash rightarrow A: (Authentifizierung, 4, + erfolgreich)\$ + \end{enumerate} + \item + Die gegenseitige Authentifizierung erfordert zwei unabhängige + Protokolldurchläufe, einen in jeder Richtung + \item + Aber: ein Angreifer kann sich nach dem Abhören eines + Protokolldurchlaufs ausgeben, da er einen gültigen Schlüsselstrom aus + den Nachrichten 2 und 3 erhalten kann! + \end{itemize} + + + \subsection{IEEE 802.11's Wired Equivalence + Privacy} + + \begin{itemize} + \item + IEEE 802.11's WEP verwendet RC4 als Pseudo-Zufallsbit-Generator + (PRNG): + + \begin{itemize} + \item + Für jede zu schützende Nachricht M wird ein + 24-Bit-Initialisierungsvektor (IV) mit dem gemeinsamen Schlüssel + \$K\_\{BSS\}\$ verkettet, um den Seed des PRNG zu bilden. + \item + Der Integritätsprüfwert (ICV) von M wird mit CRC berechnet und an + die Nachricht angehängt (,,\textbar\textbar'') + \item + Die resultierende Nachricht \$(M \textbar\textbar{} ICV)\$ wird mit + dem von \$RC4(IV \textbar\textbar{} K\_\{BSS\})\$ erzeugten + Schlüsselstrom XOR-verknüpft (,,\$\textbackslash oplus\$'') + \item + % \includegraphics{Assets/NetworkSecurity-802.11-wep-encryption.png} + \end{itemize} + \item + Da die IV mit jeder Nachricht im Klartext gesendet wird, kann jeder + Empfänger, der \$K\_\{BSS\}\$ kennt, den entsprechenden Schlüsselstrom + zur Entschlüsselung einer Nachricht erzeugen. + + \begin{itemize} + \item + Dadurch wird die wichtige Eigenschaft der Selbstsynchronisation von + WEP gewährleistet + \item + Der Entschlüsselungsprozess ist im Grunde die Umkehrung der + Verschlüsselung: + \item + % \includegraphics{Assets/NetworkSecurity-802.11-wep-decryption.png} + \end{itemize} + \end{itemize} + + + \subsection{Die Sicherheitsansprüche von IEEE + 802.11} + + \begin{itemize} + \item + WEP wurde entwickelt, um die folgenden Sicherheitseigenschaften zu + gewährleisten: + + \begin{itemize} + \item + Vertraulichkeit: + + \begin{itemize} + \item + Nur Stationen, die über \$K\_\{BSS\}\$ verfügen, können mit WEP + geschützte Nachrichten lesen + \end{itemize} + \item + Authentifizierung der Datenherkunft / Datenintegrität: + + \begin{itemize} + \item + Böswillige Veränderungen von WEP-geschützten Nachrichten können + erkannt werden + \end{itemize} + \item + Zugriffskontrolle in Verbindung mit Schichtenmanagement: + + \begin{itemize} + \item + Wenn in der Schichtenverwaltung so eingestellt, werden nur + WEP-geschützte Nachrichten von Empfängern akzeptiert + \item + Somit können Stationen, die \$K\_\{BSS\}\$ nicht kennen, nicht an + solche Empfänger senden + \end{itemize} + \end{itemize} + \item + Leider trifft keine der obigen Behauptungen zu... + \end{itemize} + + + \subsubsection{Schwachstelle \#1: Die + Schlüssel} + + \begin{itemize} + \item + IEEE 802.11 sieht keine Schlüsselverwaltung vor: + + \begin{itemize} + \item + Manuelle Verwaltung ist fehleranfällig und unsicher + \item + Die gemeinsame Verwendung eines Schlüssels für alle Stationen eines + BSS führt zu zusätzlichen Sicherheitsproblemen + \item + Als Folge der manuellen Schlüsselverwaltung werden die Schlüssel + selten geändert. + \item + Eine weitere Folge ist, dass die ,,Sicherheit'' oft sogar + ausgeschaltet ist! + \end{itemize} + \item + Schlüssellänge: + + \begin{itemize} + \item + Die im ursprünglichen Standard festgelegte Schlüssellänge von 40 Bit + bietet nur geringe Sicherheit + \item + Der Grund dafür war die Exportierbarkeit + \item + Wireless LAN-Karten erlauben oft auch Schlüssel der Länge 104 Bit, + aber das macht die Situation nicht besser, wie wir später sehen + werden + \end{itemize} + \end{itemize} + + + \subsubsection{Schwachstelle \#2: WEP-Vertraulichkeit ist + unsicher} + + \begin{itemize} + \item + Selbst mit gut verteilten und langen Schlüsseln ist WEP unsicher + \item + Der Grund dafür ist die Wiederverwendung des Schlüsselstroms: + + \begin{itemize} + \item + Erinnern Sie sich, dass die Verschlüsselung mit jeder Nachricht neu + synchronisiert wird, indem eine IV der Länge 24 Bit an + \$K\_\{BSS\}\$ angehängt und der PRNG neu initialisiert wird + \item + Betrachten wir zwei Klartexte M 1 und M 2, die mit demselben IV 1 + verschlüsselt wurden: + + \begin{itemize} + \item + \$C\_1 = P\_1 \textbackslash oplus RC4 (IV\_1 , K\_\{BSS\})\$ + \item + \$C\_2 = P\_2 \textbackslash oplus RC4 (IV\_1 , K\_\{BSS\})\$ + dann: + \item + \$C\_1 \textbackslash oplus C\_2 = (P\_1 \textbackslash oplus RC4 + (IV\_1, K\_\{BSS\})) \textbackslash oplus + (P\_2\textbackslash oplus RC4 (IV\_1 , K\_\{BSS\})) = P\_1 + \textbackslash oplus P\_2\$ + \end{itemize} + \item + Wenn also ein Angreifer z.B. \$P\_1\$ und \$C\_1\$ kennt, kann er + \$P\_2\$ aus \$C\_2\$ wiederherstellen, ohne den Schlüssel + \$K\_\{BSS\}\$ zu kennen. + + \begin{itemize} + \item + Kryptographen nennen dies einen Angriff mit bekanntem Klartext + \end{itemize} + \end{itemize} + \item + Wie oft kommt die Wiederverwendung des Schlüsselstroms vor? + + \begin{itemize} + \item + In der Praxis recht häufig, da viele Implementierungen die IV + schlecht wählen + \item + Selbst bei optimaler Wahl, da die IV-Länge 24 Bit beträgt, wird eine + stark ausgelastete Basisstation eines 11-Mbit/s-WLAN den verfügbaren + Speicherplatz in einem halben Tag erschöpfen + \end{itemize} + \end{itemize} + + + \subsubsection{Schwachstelle \#3: WEP-Datenintegrität ist + unsicher} + + \begin{itemize} + \item + Erinnern Sie sich, dass CRC eine lineare Funktion ist und RC4 + ebenfalls linear ist + \item + Nehmen wir an, A sendet eine verschlüsselte Nachricht an B, die von + einem Angreifer E abgefangen wird: + + \begin{itemize} + \item + \$A \textbackslash rightarrow B: (IV, C) mit C = RC4(IV, K\_\{BSS\}) + \textbackslash oplus (M, CRC(M))\$ + \end{itemize} + \item + Der Angreifer E kann einen neuen Chiffretext \$C'\$ konstruieren, der + zu einer Nachricht \$M'\$ mit einer gültigen Prüfsumme \$CRC(M')\$ + entschlüsselt wird: + + \begin{itemize} + \item + E wählt eine beliebige Nachricht \$\textbackslash delta\$ mit der + gleichen Länge + \item + \$C' = C \textbackslash oplus (\textbackslash delta, + CRC(\textbackslash delta)) = RC4(IV, K\_\{BSS\}) + \textbackslash oplus (M, CRC(M)) \textbackslash oplus + (\textbackslash delta, CRC(\textbackslash delta))\$ + \item + \$= RC4(IV, K\_\{BSS\}) \textbackslash oplus (M \textbackslash oplus + \textbackslash delta, CRC(M) \textbackslash oplus + CRC(\textbackslash delta))\$ + \item + \$= RC4(IV, K\_\{BSS\}) \textbackslash oplus (M \textbackslash oplus + \textbackslash delta, CRC(M \textbackslash oplus + \textbackslash delta))\$ + \item + \$= RC4(IV, K\_\{BSS\}) \textbackslash oplus (M', CRC(M'))\$ + \item + Man beachte, dass \$E\$ \$M'\$ nicht kennt, da es \$M\$ nicht kennt. + \item + Dennoch führt ein ,,1'' an Position \$n\$ in + \$\textbackslash delta\$ zu einem umgedrehten Bit an Position n in + \$M'\$, so dass E kontrollierte Änderungen an \$M\$ vornehmen kann + \item + \$\textbackslash Rightarrow\$ Datenherkunftsauthentifizierung / + Datenintegrität von WEP ist unsicher! + \end{itemize} + \end{itemize} + + + \subsubsection{Schwachstelle \#4: WEP-Zugangskontrolle ist + unsicher} + + \begin{itemize} + \item + Erinnern Sie sich, dass die Integritätsfunktion ohne einen Schlüssel + berechnet wird + \item + Betrachten wir einen Angreifer, der ein Klartext-Chiffretext-Paar in + Erfahrung bringt: + + \begin{itemize} + \item + Da der Angreifer \$M\$ und \$C=RC4(IV, + K\_\{BSS\})\textbackslash oplus (M, CRC(M))\$ kennt, kann er den zur + Erzeugung von \$C\$ verwendeten Schlüsselstrom berechnen + \item + Wenn \$E\$ später eine Nachricht \$M'\$ senden will, kann er \$C' = + RC4(IV, K\_\{BSS\})\textbackslash oplus (M', CRC(M'))\$ berechnen + und die Nachricht \$(IV, C')\$ senden. + \item + Da die Wiederverwendung alter IV-Werte möglich ist, ohne beim + Empfänger einen Alarm auszulösen, handelt es sich um eine gültige + Nachricht + \item + Eine ,,Anwendung'' für diesen Angriff ist die unbefugte Nutzung von + Netzwerkressourcen: + + \begin{itemize} + \item + Der Angreifer sendet IP-Pakete, die für das Internet bestimmt + sind, an den Zugangspunkt, der sie entsprechend weiterleitet und + dem Angreifer freien Zugang zum Internet gewährt + \end{itemize} + \end{itemize} + \item + \$\textbackslash Rightarrow\$ WEP Access Control kann mit bekanntem + Klartext umgangen werden + \end{itemize} + + + \subsubsection{Schwachstelle Nr. 5: Schwachstelle in der + RC4-Schlüsselberechnung} + + \begin{itemize} + \item + Anfang August 2001 wurde ein weiterer Angriff auf WEP entdeckt: + + \begin{itemize} + \item + Der gemeinsame Schlüssel kann in weniger als 15 Minuten + wiederhergestellt werden, vorausgesetzt, dass etwa 4 bis 6 Millionen + Pakete wiederhergestellt wurden. + \item + Bei dem Angriff handelt es sich um einen Angriff mit verwandten + Schlüsseln, bei dem die Verwendung von RC4 durch WEP ausgenutzt + wird: + + \begin{itemize} + \item + RC4 ist anfällig für die Ableitung von Bits eines Schlüssels, + wenn: + + \begin{itemize} + \item + viele Nachrichten mit einem Schlüsselstrom verschlüsselt werden, + der aus einem variablen Initialisierungsvektor und einem festen + Schlüssel erzeugt wird, und + \item + die Initialisierungsvektoren und der Klartext der ersten beiden + Oktette für die verschlüsselten Nachrichten bekannt sind + \end{itemize} + \item + Die IV für den Schlüsselstrom wird mit jedem Paket im Klartext + übertragen. + \item + Die ersten beiden Oktette eines verschlüsselten Datenpakets können + erraten werden + \end{itemize} + \item + Der Angriff ist in {[}SMF01a{]} und {[}SIR01a{]} beschrieben und + wurde später so verfeinert, dass er noch schneller funktioniert + {[}TWP07{]}. + \item + R. Rivest kommentiert dies {[}Riv01a{]}: ,,Diejenigen, die die + RC4-basierten WEP- oder WEP2-Protokolle verwenden, um die + Vertraulichkeit ihrer 802.11-Kommunikation zu gewährleisten, sollten + diese Protokolle als gebrochen betrachten {[}...{]}'' + \end{itemize} + \end{itemize} + + + \subsection{Schlussfolgerungen zu den Unzulänglichkeiten von IEEE + 802.11} + + \begin{itemize} + \item + Das ursprüngliche IEEE 802.11 bietet keine ausreichende Sicherheit: + + \begin{itemize} + \item + Fehlende Schlüsselverwaltung macht die Nutzung der + Sicherheitsmechanismen mühsam und führt dazu, dass die Schlüssel + selten gewechselt werden oder sogar die Sicherheit ausgeschaltet ist + \item + Sowohl die Entity-Authentifizierung als auch die Verschlüsselung + beruhen auf einem Schlüssel, der von allen Stationen eines + Basisdienstes gemeinsam genutzt wird + \item + Unsicheres Protokoll zur Entitätsauthentifizierung + \item + Wiederverwendung des Schlüsselstroms ermöglicht Angriffe mit + bekanntem Klartext + \item + Lineare Integritätsfunktion ermöglicht die Fälschung von ICVs + \item + Unverschlüsselte Integritätsfunktion ermöglicht die Umgehung der + Zugangskontrolle durch Erstellung gültiger Nachrichten aus einem + bekannten Klartext-Chiffretext-Paar + \item + Schwachstelle in der RC4-Schlüsselplanung ermöglicht die + Kryptoanalyse von Schlüsseln + \end{itemize} + \item + Selbst mit IEEE 802.1X und individuellen Schlüsseln bleibt das + Protokoll schwach + \item + Einige vorgeschlagene Gegenmaßnahmen: + + \begin{itemize} + \item + Platzieren Sie Ihr IEEE 802.11 Netzwerk außerhalb Ihrer Internet + Firewall + \item + Vertrauen Sie keinem Host, der über IEEE 802.11 verbunden ist. + \item + Verwenden Sie zusätzlich andere Sicherheitsprotokolle, z. B. PPTP, + L2TP, IPSec, SSH, ... + \end{itemize} + \end{itemize} + + + \subsection{Interlude: Sicherheit in öffentlichen + WLAN-Hotspots} + + Welche Sicherheit können Sie in einem öffentlichen WLAN-Hotspot + erwarten? + + \begin{itemize} + \item + Bei den meisten Hotspots: Leider fast keine! + \item + Wenn Sie außer der Eingabe eines Benutzernamens und eines Passworts + auf einer Webseite keine weiteren Sicherheitsparameter konfigurieren + müssen, können Sie Folgendes erwarten: + + \begin{itemize} + \item + Der Hotspot-Betreiber prüft Ihre Authentizität bei der Anmeldung + (oft mit SSL geschützt, um das Abhören Ihres Passworts zu + verhindern) + \item + Nur authentifizierte Clients erhalten den Dienst, da die + Paketfilterung den Zugriff auf die Anmeldeseite nur bei + erfolgreicher Authentifizierung zulässt. + \item + Nach Überprüfung der Anmeldeauthentifizierung: keine weiteren + Sicherheitsmaßnahmen + \item + Kein Schutz für Ihre Benutzerdaten: + + \begin{itemize} + \item + Alles kann abgefangen und manipuliert werden + \item + Sie können zwar eigene Maßnahmen ergreifen, z.B. VPN oder SSL, + aber die Konfiguration ist oft mühsam oder wird vom + Kommunikationspartner gar nicht unterstützt und die Leistung wird + durch zusätzlichen (pro-Paket-) Overhead beeinträchtigt + \end{itemize} + \item + Plus: Ihre Sitzung kann durch die Verwendung Ihrer MAC- und + IP-Adressen gestohlen werden! + \end{itemize} + \item + Konsequenz: bessere WLAN-Sicherheit ist dringend erforderlich + \end{itemize} + + + \subsection{Fixing WLAN Security: IEEE 802.11i, WPA und + WPA} + + \begin{itemize} + \item + Umfang: Definition der Interaktion zwischen 802.1X und 802.11 + Standards + \item + TGi definiert zwei Klassen von Sicherheitsalgorithmen für 802.11: + + \begin{itemize} + \item + Pre-RSN Sicherheitsnetzwerk (\textbackslash rightarrow WEP) + \item + Robustes Sicherheitsnetzwerk (RSN) + \end{itemize} + \item + Die RSN-Sicherheit besteht aus zwei grundlegenden Teilsystemen: + + \begin{itemize} + \item + Mechanismen zum Schutz der Daten: + + \begin{itemize} + \item + TKIP - schnelles Re-Keying, um WEP für ein Minimum an Datenschutz + zu verbessern (Marketingname WPA) + \item + AES-Verschlüsselung - robuster Datenschutz für lange Zeit + (Marketingname WPA2) + \end{itemize} + \end{itemize} + \item + Verwaltung von Sicherheitsvereinbarungen: + + \begin{itemize} + \item + Unternehmensmodus - basierend auf 802.1X + \item + Persönlicher Modus - basierend auf Pre-Shared Keys + \end{itemize} + \end{itemize} + + (das meiste Material über 802.11i ist aus {[}WM02a{]} entnommen) + + + \subsection{WPA-Schlüsselverwaltung} + + \begin{itemize} + \item + Im Gegensatz zum ursprünglichen 802.11: paarweise Schlüssel zwischen + STA und BS, zusätzliche Gruppenschlüssel für Multi- und + Broadcast-Pakete sowie Station-to-Station-Link (STSL)-Schlüssel + \item + Das erste Geheimnis: der 256 Bit Pairwise Master Key (PMK) + + \begin{itemize} + \item + Unternehmensmodus: Verwendet 802.1X-Authentifizierung und + installiert einen neuen Schlüssel, der BS und Client bekannt ist, z. + B. durch EAP-TTLS + \item + Persönlicher Modus: Verwendet einen Pre-Shared Key (PSK), der dem BS + und vielen STAs bekannt ist. + + \begin{itemize} + \item + Explizit durch 64 zufällige Hex-Zeichen oder implizit durch ein + Passwort gegeben + \item + Wenn Passwort: PMK = PBKDF2(Passwort, SSID, 4096, 256) + \item + Wobei PBKDF2 die passwortbasierte Schlüsselableitungsfunktion 2 + aus {[}RFC2898{]} mit einer Salz-SSID und einer Ausgangslänge von + 256 Bit ist + \item + impliziert 2 * 4096 Berechnungen von HMAC-SHA1, um Brute-Force zu + verlangsamen + \end{itemize} + \end{itemize} + \item + PMK ist ein Vertrauensanker für die Authentifizierung per EAPOL (EAP + over LAN) Handshake, wird aber nie direkt verwendet... + \item + Für aktuelle kryptographische Protokolle wird ein kurzzeitiger 512 Bit + Pairwise Transient Key (PTK) wie folgt generiert + + \begin{itemize} + \item + \$PTK = PRF(PMK, ,,Paarweise Schlüsselerweiterung'', + min(Addr\_\{BS\}, Addr\_\{STA\}) \textbar\textbar{} + max(Addr\_\{BS\}, Addr\_\{STA\}) \textbar\textbar{} min(r\_\{BS\}, + r\_\{STA\}) \textbar\textbar{} max(r\_\{BS\}, r\_\{STA\}))\$ + \item + Dabei ist \$PRF(K, A, B)\$ die verkettete Ausgabe von \$HMAC-SHA1(K, + A \textbar\textbar{} '0' \textbar\textbar{} B \textbar\textbar{} + i)\$ über einen laufenden Index i + \end{itemize} + \item + Der PTK wird aufgeteilt in: + + \begin{itemize} + \item + EAPOL-Schlüssel-Bestätigungsschlüssel (KCK, erste 128 Bits), + + \begin{itemize} + \item + Wird zum Schutz der Integrität von EAPOL-Nachrichten verwendet + \item + Durch HMAC-MD5 (veraltet), HMAC-SHA1-128, AES-128-CMAC + \end{itemize} + \item + EAPOL Key Encryption Key (KEK, zweite 128 Bits), + + \begin{itemize} + \item + Wird zur Verschlüsselung neuer Schlüssel in EAPOL-Nachrichten + verwendet + \item + Mit RC4 (veraltet), AES im Key Wrap Mode {[}RFC3394{]} + \end{itemize} + \item + Ein Temporal Key (TK) zum Schutz des Datenverkehrs (ab Bit 256)! + \end{itemize} + \item + Initialer Dialog mit BS: + + \begin{itemize} + \item + EAPOL (EAP over LAN) 4-Wege-Handshake wird verwendet, um + + \begin{itemize} + \item + Überprüfung der gegenseitigen Kenntnis des PMK + \item + Initiiert durch BS, um Schlüssel zu installieren (gruppenweise und + paarweise) + \end{itemize} + \item + Vereinfachter Handshake funktioniert wie folgt: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$BS\textbackslash rightarrow STA: (1, r\_\{BS\} , PMKID, + install\textbackslash{} new\textbackslash{} PTK)\$ + \item + \$STA BS: (2, r\_\{STA\}, MAC\_\{KCK\})\$ + \item + \$BS STA: (3, r\_\{BS\}, MAC\_\{KCK\}, \{TK\}\_\{KEK\})\$ + \item + \$STA BS: (4, r\_\{STA\}, MAC\_\{KCK\})\$ + \end{enumerate} + \item + Wobei PMKID den PMK identifiziert: obere 128 Bit von + \$HMAC-SHA-256(PMK, "PMK Name" \textbar\textbar{} Addr\_\{BS\} + \textbar\textbar{} Addr\_\{STA\} )\$ + \end{itemize} + \end{itemize} + + + \subsection{Eine Zwischenlösung: Temporal Key Integrity + Protokoll} + + \begin{itemize} + \item + Ziele des Entwurfs: + + \begin{itemize} + \item + Schnelle Lösung für das bestehende WEP-Problem, betreibt WEP als + Unterkomponente + \item + Kann in Software implementiert werden, nutzt vorhandene WEP-Hardware + wieder + \item + Anforderungen an vorhandene AP-Hardware: + + \begin{itemize} + \item + 33 oder 25 MHz ARM7 oder i486, die bereits vor TKIP mit 90\% + CPU-Auslastung laufen + \item + Nur als Software/Firmware-Upgrade gedacht + \item + Keine unangemessene Beeinträchtigung der Leistung + \end{itemize} + \end{itemize} + \item + Wichtigste Konzepte: + + \begin{itemize} + \item + Nachrichtenintegritätscode (MIC) + \item + Gegenmaßnahmen im Falle von MIC-Fehlern + \item + Sequenzzähler + \item + Dynamische Schlüsselverwaltung (Re-Keying) + \item + Schlüsselmischung + \end{itemize} + \item + TKIP erfüllt die Kriterien für einen guten Standard: alle sind damit + unzufrieden... + \item + % \includegraphics{Assets/NetworkSecurity-tkip-mpdu-data-format.png} + \end{itemize} + + Message Integrity Code Funktion Michael + + \begin{itemize} + \item + Schützt vor Fälschungen: + + \begin{itemize} + \item + Muss billig sein: CPU-Budget 5 Anweisungen / Byte + \item + Leider schwach: ein \$2\^{}\{29\}\$ Nachrichtenangriff existiert + \item + Wird über MSDUs berechnet, während WEP über MPDUs läuft + \item + Verwendet zwei 64-Bit-Schlüssel, einen in jeder Verbindungsrichtung + \item + Erfordert Gegenmaßnahmen: + + \begin{itemize} + \item + Rekey on active attack (nur wenige Fehlalarme, da CRC zuerst + geprüft wird) + \item + Ratenbegrenzung auf eine Neuverschlüsselung pro Minute + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-tkip-rekey.png} + \end{itemize} + \end{itemize} + + Wiederholungsschutz und RC4-Schlüsselplanung + + \begin{itemize} + \item + Replay-Schutz: + + \begin{itemize} + \item + Zurücksetzen der Paket-Sequenz \# auf 0 bei Wiederholung + \item + Erhöhen der Sequenz \# um 1 bei jedem Paket + \item + Verwerfen aller Pakete, die außerhalb der Sequenz empfangen werden + \end{itemize} + \item + Umgehen Sie die Schwächen der WEP-Verschlüsselung: + + \begin{itemize} + \item + Erstellen Sie einen besseren paketweisen Verschlüsselungsschlüssel, + indem Sie Angriffe mit schwachen Schlüsseln verhindern und WEP IV + und paketweisen Schlüssel dekorrelieren + \item + muss auf vorhandener Hardware effizient sein + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-tkip-replay-protection.png} + \end{itemize} + + TKIP-Verarbeitung beim Sender + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-tkip-processing.png} + \end{itemize} + + TKIP-Verarbeitung auf der Empfängerseite + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-tkip-receiver.png} + \end{itemize} + + + \subsection{Die langfristige Lösung: AES-basierter + WLAN-Schutz} + + \begin{itemize} + \item + Zählermodus mit CBC-MAC (CCMP): + + \begin{itemize} + \item + Obligatorisch zu implementieren: die langfristige Lösung + \item + Ein völlig neues Protokoll mit wenigen Zugeständnissen an WEP + \item + Bietet: Datenvertraulichkeit, Authentifizierung der Datenherkunft, + Schutz vor Wiederholungen + \item + Basiert auf AES in Counter Mode Encryption mit CBC-MAC (CCM) + + \begin{itemize} + \item + Verwendung von CBC-MAC zur Berechnung einer MIC für den + Klartext-Header, die Länge des Klartext-Headers und die Nutzdaten + \item + Verwenden Sie den CTR-Modus, um die Payload mit den Zählerwerten + 1, 2, 3, ... zu verschlüsseln. + \item + Verwenden Sie den CTR-Modus, um die MIC mit dem Zählerwert 0 zu + verschlüsseln. + \end{itemize} + \item + AES-Overhead erfordert neue AP-Hardware + \item + Der AES-Overhead erfordert möglicherweise neue STA-Hardware für + Handheld-Geräte, aber theoretisch nicht für PCs (dies erhöht jedoch + die CPU-Last und den Energieverbrauch), praktisch aufgrund fehlender + Treiber für beide + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-aes-ccmp-frame-format.png} + \end{itemize} + + + \subsection{Vergleich WEP, TKIP und + CCMP} + + %\begin{longtable}[]{@{}llll@{}} + % \toprule + % & WEP & TKIP & CCMP\tabularnewline + % \midrule + % \endhead + % Cipher & RC4 & RC4 & AES\tabularnewline + % Key Size & 40 or 104 bits & 104 bits & 128 bits encrypt, 64 bit + % auth.\tabularnewline + % Key Life & 24-bit IV, wrap & 48-bit IV & 48-bit IV\tabularnewline + % Packet Key & Concat. & Mixing Fnc. & Not Needed\tabularnewline + % Integrity & & & \tabularnewline + % Data & CRC-32 & Michael & CCM\tabularnewline + % Header & None & Michael & CCM\tabularnewline + % Replay & None & Use IV & Use IV\tabularnewline + % Key Mgmt. & None & EAP-based & EAP-based\tabularnewline + % \bottomrule + %\end{longtable} + + TKIP ist derzeit veraltet, AES wird empfohlen. + + + \section{Sicherheit von GSM- und + UMTS-Netzen} + + + \subsection{GSM-Übersicht} + + \begin{itemize} + \item + Die GSM-Normen: + + \begin{itemize} + \item + Akronym: + + \begin{itemize} + \item + früher: Groupe Spéciale Mobile (gegründet 1982) + \item + jetzt: Globales System für mobile Kommunikation + \end{itemize} + \item + Gesamteuropäische Norm (ETSI) + \item + Gleichzeitige Einführung wesentlicher Dienste in drei Phasen (1991, + 1994, 1996) durch die europäischen Telekommunikationsverwaltungen + (Deutschland: D1 und D2) \$\textbackslash rightarrow\$ nahtloses + Roaming innerhalb Europas möglich + \item + Heute nutzen viele Anbieter in der ganzen Welt GSM (mehr als 130 + Länder in Asien, Afrika, Europa, Australien, Amerika) + \end{itemize} + \item + Merkmale: + + \begin{itemize} + \item + Echte mobile, drahtlose Kommunikation mit Unterstützung für Sprache + und Daten + \item + Weltweite Konnektivität und internationale Mobilität mit eindeutigen + Adressen + \item + Sicherheitsfunktionen: + + \begin{itemize} + \item + Vertraulichkeit auf der Luftschnittstelle + \item + Zugangskontrolle und Benutzerauthentifizierung + \end{itemize} + \end{itemize} + \item + GSM bietet die folgenden Sicherheitsfunktionen {[}ETSI93a, ETSI94a{]}: + + \begin{itemize} + \item + Vertraulichkeit der Identität des Teilnehmers: + + \begin{itemize} + \item + Schutz vor einem Eindringling, der versucht zu identifizieren, + welcher Teilnehmer eine bestimmte Ressource auf dem Funkpfad + benutzt (z.B. Verkehrskanal oder Signalisierungsressourcen), indem + er den Signalisierungsaustausch auf dem Funkpfad abhört + \item + Vertraulichkeit für Signalisierungs- und Benutzerdaten + \item + Schutz gegen die Rückverfolgung des Standorts eines Teilnehmers + \end{itemize} + \item + Authentifizierung der Identität des Teilnehmers: Schutz des Netzes + vor unbefugter Nutzung + \item + Vertraulichkeit des Signalisierungsinformations-Elements: + Geheimhaltung von Signalisierungsdaten auf der Funkstrecke + \item + Vertraulichkeit der Benutzerdaten: Geheimhaltung von Nutzdaten auf + der Funkstrecke + \item + Es werden jedoch nur Lauschangriffe auf die Funkverbindung zwischen + dem Mobiltelefon und den Basisstationen berücksichtigt! + \end{itemize} + \end{itemize} + + Einige GSM-Abkürzungen \textbar{} \textbar{} \textbar{} \textbar{} + -\/-\/-\/-\/-\/- \textbar{} + -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- + \textbar{} \textbar{} AuC \textbar{} Authentication center \textbar{} + \textbar{} BSC \textbar{} Basisstations-Controller \textbar{} \textbar{} + BTS \textbar{} Basis-Transceiver-Station \textbar{} \textbar{} IMSI + \textbar{} Internationale mobile Teilnehmerkennung \textbar{} \textbar{} + HLR \textbar{} Heimatstandortregister \textbar{} \textbar{} LAI + \textbar{} Standortbereichskennung \textbar{} \textbar{} MS \textbar{} + Mobile Station (z. B. ein Mobiltelefon) \textbar{} \textbar{} MSC + \textbar{} Mobile Vermittlungsstelle \textbar{} \textbar{} MSISDN + \textbar{} Mobile subscriber international ISDN number \textbar{} + \textbar{} TMSI \textbar{} Temporäre mobile Teilnehmerkennung \textbar{} + \textbar{} VLR \textbar{} Register für Besucherstandorte \textbar{} + + % \includegraphics{Assets/NetworkSecurity-gsm-authentication.png} + + % \includegraphics{Assets/NetworkSecurity-gsm-authentication-2.png} + + \begin{itemize} + \item + \$K\_i\$: Authentifizierungsschlüssel des einzelnen Teilnehmers + \item + \$SRES\$: Signierte Antwort + \end{itemize} + + Der grundlegende (anfängliche) Authentifizierungsdialog: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$MS \textbackslash rightarrow VLR: (IMSI\_\{MS\})\$ + \item + \$VLR \textbackslash rightarrow AuC: (IMSI\_\{MS\})\$ + \item + \$AuC \textbackslash rightarrow VLR: (IMSI\_\{MS\}, K\_\{BSC,MS\}, + R\_\{AUC\}, SRES\_\{AUC\})\$ + \item + \$VLR \textbackslash rightarrow MS: (R\_\{AUC:1\})\$ + \item + \$MS \textbackslash rightarrow VLR: (SRES\_\{AUC:1\})\$ + \item + \$VLR \textbackslash rightarrow MS: (LAI\_1 , TMSI\_\{MS:1\})\$ + \end{enumerate} + + \begin{itemize} + \item + Bemerkungen: + + \begin{itemize} + \item + \$SRES\_\{AUC\} = A3(K\_\{AUC,MS\}, R\_\{AUC\});\$ A3 ist ein + Algorithmus + \item + \$K\_\{BSC,MS\} = A8(K\_\{AUC,MS\}, R\_\{AUC\});\$ A8 ist ein + Algorithmus + \item + \$R\_\{AUC\}, SRES\_\{AUC\}\$ sind Arrays mit mehreren Werten + \end{itemize} + \item + Dialog zur Wiederauthentifizierung mit demselben VLR: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$MS \textbackslash rightarrow VLR: (LAI\_1 , TMSI\_\{MS:n\})\$ + \item + \$VLR \textbackslash rightarrow MS: (R\_\{AUC:i\})\$ + \item + \$MS \textbackslash rightarrow VLR: (SRES\_\{AUC:i\})\$ + \item + \$VLR \textbackslash rightarrow MS: (LAI\_1, TMSI\_\{MS:n+1\})\$ + \end{enumerate} + \item + Bemerkungen: + + \begin{itemize} + \item + Die Standortbereichskennung \$LAI\_1\$ ermöglicht die Erkennung + eines MS ,,coming in'' aus einem anderen Bereich + \item + Nach erfolgreicher Authentifizierung wird eine neue temporäre mobile + Teilnehmeridentität \$TMSI\_\{MS:n+1\}\$ zugewiesen + \end{itemize} + \item + Re-Authentifizierungsdialog mit Übergabe an das neue \$VLR\_2\$: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + \$MS \textbackslash rightarrow VLR\_2: (LAI\_1, TMSI\_\{MS:n\})\$ + \item + \$VLR\_2\$Rechtspfeil VLR\_1: (LAI\_1, TMSI\_\{MS:n\})\$ + \item + \$VLR\_1 \textbackslash rightarrow VLR\_2: (TMSI\_\{MS:n\}, + IMSI\_\{MS\}, K\_\{BSC,MS\}, R\_\{AUC\}, SRES\_\{AUC\})\$ + \item + \$VLR\_2 \textbackslash rightarrow MS: (R\_\{AUC:i\})\$ + \item + \$MS \textbackslash rightarrow VLR\_2: (SRES\_\{AUC:i\})\$ + \item + \$VLR\_2 \textbackslash rightarrow MS: (LAI\_2, TMSI\_\{MS:n+1\})\$ + \end{enumerate} + \item + Bemerkungen: + + \begin{itemize} + \item + Nur unbenutzte \$R\_\{AUC\}, ...\$ werden an \$VLR\_2\$ übertragen + \item + Dieses Schema kann nicht verwendet werden, und es ist ein + Anfangsdialog erforderlich: + + \begin{itemize} + \item + Wenn \$TMSI\_\{MS:n\}\$ bei \$VLR\_1\$ nicht verfügbar ist, oder + \item + wenn \$VLR\_2\$ nicht in der Lage ist, \$VLR\_1\$ zu kontaktieren + \end{itemize} + \item + Wenn \$VLR\_1\$ und \$VLR\_2\$ zu verschiedenen Netzbetreibern + gehören, kann der Handover nicht durchgeführt werden und die + Verbindung wird unterbrochen + \end{itemize} + \item + Nur das Mobiltelefon authentifiziert sich gegenüber dem Netz + \item + Die Authentifizierung basiert auf einem Challenge-Response-Verfahren: + + \begin{itemize} + \item + Das AuC im Heimatnetz erzeugt Challenge-Response-Paare + \item + Der MSC/VLR im besuchten Netz prüft diese + \item + Challenge-Response-Vektoren werden ungeschützt im + Signalisierungsnetz übertragen + \end{itemize} + \item + Die permanente Identifikation des Mobiltelefons (IMSI) wird nur dann + über die Funkverbindung gesendet, wenn dies unvermeidlich ist: + + \begin{itemize} + \item + Dies ermöglicht einen teilweisen Schutz des Standorts. + \item + Da die IMSI manchmal im Klartext gesendet wird, ist es dennoch + möglich, den Standort einiger Einheiten zu erfahren + \item + Ein Angreifer könnte sich als Basisstation ausgeben und die Handys + ausdrücklich auffordern, ihre IMSI zu senden! + \end{itemize} + \item + Grundsätzlich besteht Vertrauen zwischen allen Betreibern! + \end{itemize} + + + \subsection{General Packet Radio Service + (GPRS)} + + \begin{itemize} + \item + GPRS (General Packet Radio Service, allgemeiner Paketfunkdienst): + + \begin{itemize} + \item + Datenübertragung in GSM-Netzen auf der Basis von Paketvermittlung + \item + Nutzung freier Slots der Funkkanäle nur bei sendebereiten + Datenpaketen (z.B. 115 kbit/s bei temporärer Nutzung von 8 Slots) + \end{itemize} + \item + GPRS-Netzelemente: + + \begin{itemize} + \item + GGSN (Gateway GPRS Support Node): Interworking-Einheit zwischen GPRS + und PDN (Packet Data Network) + \item + SGSN (Serving GPRS Support Node): Unterstützt die MS (Standort, + Abrechnung, Sicherheit, entspricht im Grunde dem MSC) + \item + GR (GPRS Register): Verwaltet Benutzeradressen (entspricht HLR) + \end{itemize} + \end{itemize} + + (allgemeine GPRS-Beschreibung entnommen aus {[}Sch03a{]}) + + % \includegraphics{Assets/NetworkSecurity-gprs-logical-architecture.png} + + % \includegraphics{Assets/NetworkSecurity-gprs-protocol-architecture.png} + + \begin{itemize} + \item + SNDCP: Subnetwork Dependent Convergence Protocol + \item + GTP: GPRS Tunnelling Protocol + \end{itemize} + + GPRS-Sicherheit + + \begin{itemize} + \item + Sicherheitsziele: + + \begin{itemize} + \item + Schutz vor unbefugter Nutzung des GPRS-Dienstes (Authentifizierung) + \item + Gewährleistung der Vertraulichkeit der Benutzeridentität (temporäre + Identifizierung und Verschlüsselung) + \item + Gewährleistung der Vertraulichkeit von Benutzerdaten + (Verschlüsselung) + \end{itemize} + \item + Realisierung von Sicherheitsdiensten: + + \begin{itemize} + \item + Die Authentifizierung ist grundsätzlich identisch mit der + GSM-Authentifizierung: + + \begin{itemize} + \item + SGSN ist die Peer-Entität + \item + Zwei separate temporäre Identitäten werden für GSM/GPRS verwendet + \item + Nach erfolgreicher Authentifizierung wird die Verschlüsselung + eingeschaltet + \end{itemize} + \item + Die Vertraulichkeit der Benutzeridentität ist ähnlich wie bei GSM: + + \begin{itemize} + \item + Die meiste Zeit wird nur die Paket-TMSI (P-TMSI) über die Luft + gesendet. + \item + Optional können P-TMSI ,,Signaturen'' zwischen MS und SGSN + verwendet werden, um die Re-Authentifizierung zu beschleunigen + \end{itemize} + \item + Die Vertraulichkeit der Benutzerdaten wird zwischen MS und SGSN + realisiert: + + \begin{itemize} + \item + Unterschied zu GSM, wo nur zwischen MS und BTS verschlüsselt wird + \item + Die Verschlüsselung wird in der LLC-Protokollschicht realisiert + \end{itemize} + \end{itemize} + \end{itemize} + + % \includegraphics{Assets/NetworkSecurity-gprs-handover-execution.png} + + \begin{itemize} + \item + GPRS unterstützt ein ,,optimiertes Handover'' einschließlich + Re-Authentifizierung (dies könnte jedoch eine Schwäche der P-TMSI + ,,Signatur'' verhindern) + \end{itemize} + + + \subsection{UMTS Sicherheits + Architektur} + + % \includegraphics{Assets/NetworkSecurity-umts-security-architecture.png} + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + Netzzugangssicherheit: Schutz vor Angriffen auf die Funkschnittstelle + \item + Sicherheit der Netzdomäne: Schutz vor Angriffen auf das drahtgebundene + Netz + \item + Sicherheit der Benutzerdomäne: sicherer Zugang zu den Mobilstationen + \item + Sicherheit der Anwendungsdomäne: sicherer Nachrichtenaustausch für + Anwendungen + \item + Sichtbarkeit und Konfigurierbarkeit der Sicherheit: Information des + Benutzers über den sicheren Betrieb + \end{enumerate} + + + \subsubsection{Aktueller Stand der + UMTS-Sicherheitsarchitektur} + + \begin{itemize} + \item + Sicherheit beim Netzzugang: Derzeit der am weitesten entwickelte Teil + der UMTS-Sicherheit (siehe unten) + \item + Netzbereichssicherheit: Dieser Teil ist größtenteils noch ausbaufähig + (in Spezifikationen bis Release 5) + \item + Sicherheit der Benutzerdomäne: + + \begin{itemize} + \item + Verlangt grundsätzlich, dass sich der Benutzer gegenüber seinem User + Services Identity Module (USIM) authentifiziert, z.B. durch Eingabe + einer PIN + \item + Optional kann ein Terminal die Authentifizierung des USIM verlangen. + \end{itemize} + \item + Anwendungsbereichssicherheit: + + \begin{itemize} + \item + Definiert ein Sicherheitsprotokoll, das zwischen den auf dem + Endgerät/USIM laufenden Anwendungen und einem System im Netz + verwendet wird (3GPP TS 23.048) + \item + Liegt etwas außerhalb des Bereichs der Mobilfunksicherheit + \end{itemize} + \item + Sichtbarkeit und Konfigurierbarkeit der Sicherheit: Definiert + Anforderungen, damit der Benutzer die Kontrolle über die + Sicherheitsmerkmale hat + \item + Im Folgenden konzentrieren wir uns auf die Netzzugangssicherheit + \end{itemize} + + + \subsubsection{UMTS-Netzzugangssicherheitsdienste} + + \begin{itemize} + \item + Vertraulichkeit der Benutzeridentität: + + \begin{itemize} + \item + Vertraulichkeit der Benutzeridentität: die Eigenschaft, dass die + permanente Benutzeridentität (IMSI) eines Benutzers, dem ein Dienst + bereitgestellt wird, auf der Funkzugangsverbindung nicht abgehört + werden kann + \item + Vertraulichkeit des Benutzerstandorts: die Eigenschaft, dass die + Anwesenheit oder die Ankunft eines Benutzers in einem bestimmten + Gebiet nicht durch Abhören der Funkzugangsverbindung ermittelt + werden kann + \item + Unverfolgbarkeit des Benutzers: die Eigenschaft, dass ein + Eindringling durch Abhören der Funkzugangsverbindung nicht ableiten + kann, ob verschiedene Dienste an denselben Benutzer geliefert werden + \end{itemize} + \item + Authentifizierung der Entität: + + \begin{itemize} + \item + Benutzerauthentifizierung: die Eigenschaft, dass das dienende Netz + die Identität des Benutzers bestätigt + \item + Netzauthentifizierung: die Eigenschaft, dass der Benutzer bestätigt, + dass er mit einem dienenden Netz verbunden ist, das von dem HE des + Benutzers autorisiert ist, ihm Dienste zu liefern; dies schließt die + Garantie ein, dass diese Autorisierung aktuell ist. + \end{itemize} + \item + Vertraulichkeit: + + \begin{itemize} + \item + Vereinbarung über den Chiffrieralgorithmus: die Eigenschaft, dass + der MS und der SN den Algorithmus, den sie später verwenden sollen, + sicher aushandeln können + \item + Chiffrierschlüssel-Vereinbarung: die Eigenschaft, dass der MS und + der SN sich auf einen Chiffrierschlüssel einigen, den sie später + verwenden können + \item + Vertraulichkeit der Nutzdaten: die Eigenschaft, dass Nutzdaten an + der Funkzugangsschnittstelle nicht abgehört werden können + \item + Vertraulichkeit der Signalisierungsdaten: die Eigenschaft, dass + Signalisierungsdaten auf der Funkzugangsschnittstelle nicht abgehört + werden können + \end{itemize} + \item + Integrität der Daten: + + \begin{itemize} + \item + Vereinbarung eines Integritätsalgorithmus + \item + Integritätsschlüssel-Vereinbarung + \item + Datenintegrität und Ursprungsauthentifizierung von + Signalisierungsdaten: die Eigenschaft, dass die empfangende Einheit + (MS oder SN) in der Lage ist, zu überprüfen, dass + Signalisierungsdaten seit dem Versand durch die sendende Einheit (SN + oder MS) nicht auf unautorisierte Weise verändert wurden und dass + der Datenursprung der empfangenen Signalisierungsdaten tatsächlich + der behauptete ist + \end{itemize} + \end{itemize} + + Einige UMTS-Authentifizierungsabkürzungen + + %\begin{longtable}[]{@{}ll@{}} + % \toprule + % \endhead + % AK & Anonymitätsschlüssel\tabularnewline + % AMF & Authentifizierungs-Management-Feld\tabularnewline + % AUTN & Authentifizierungs-Token\tabularnewline + % AV & Authentifizierungsvektor\tabularnewline + % CK & Cipher Key\tabularnewline + % HE & Heimatumgebung\tabularnewline + % IK & Integritätsschlüssel\tabularnewline + % RAND & Zufällige Herausforderung\tabularnewline + %% SQN & Sequenznummer\tabularnewline + % SN & Dienendes Netzwerk\tabularnewline + % USIM & Benutzerdienste-Identitätsmodul\tabularnewline + % XRES & Erwartete Antwort\tabularnewline + % \bottomrule + %\end{longtable} + + + \subsubsection{Überblick über den + UMTS-Authentifizierungsmechanismus} + + \begin{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-umts-authentication-mechanism.png} + \item + % \includegraphics{Assets/NetworkSecurity-umts-authentication-vectors.png} + + \begin{itemize} + \item + Der HE/AuC beginnt mit der Erzeugung einer neuen Sequenznummer SQN + und einer unvorhersehbaren Herausforderung RAND + + \begin{itemize} + \item + Für jeden Benutzer führt die HE/AuC einen Zähler \$SQN\_\{HE\}\$ + \end{itemize} + \item + Ein Authentifizierungs- und Schlüsselverwaltungsfeld AMF ist im + Authentifizierungs-Token jedes Authentifizierungsvektors enthalten. + \item + Anschließend werden die folgenden Werte berechnet: + + \begin{itemize} + \item + ein Nachrichtenauthentifizierungscode \$MAC = f1\_K(SQN + \textbar\textbar{} RAND \textbar\textbar{} AMF)\$, wobei f1 eine + Nachrichtenauthentifizierungsfunktion ist + \item + eine erwartete Antwort \$XRES = f2\_K(RAND)\$, wobei f2 eine + (möglicherweise verkürzte) Nachrichtenauthentifizierungsfunktion + ist + \item + ein Chiffrierschlüssel \$CK = f3\_K(RAND)\$, wobei f3 eine + Schlüsselerzeugungsfunktion ist + \item + ein Integritätsschlüssel \$IK = f4\_K(RAND)\$, wobei f4 eine + Schlüsselerzeugungsfunktion ist + \item + ein Anonymitätsschlüssel \$AK = f5\_K(RAND)\$, wobei f5 eine + Schlüsselerzeugungsfunktion ist + \end{itemize} + \item + Schließlich wird das Authentifizierungstoken \$AUTN = SQN + \textbackslash oplus AK \textbar\textbar{} AMF \textbar\textbar{} + MAC\$ konstruiert + \end{itemize} + \item + % \includegraphics{Assets/NetworkSecurity-umts-user-authentication-usim.png} + + \begin{itemize} + \item + Nach Erhalt von RAND und AUTN berechnet das USIM: + \item + berechnet es den Anonymitätsschlüssel \$AK = f5\_K (RAND)\$ + \item + ruft die Sequenznummer \$SQN = (SQN \textbackslash oplus AK) + \textbackslash oplus AK\$ ab + \item + errechnet \$XMAC = f1\_K (SQN \textbar\textbar{} RAND + \textbar\textbar{} AMF)\$ und + \item + vergleicht dies mit MAC, das in AUTN enthalten ist + \item + Wenn sie unterschiedlich sind, sendet der Benutzer die Ablehnung der + Benutzerauthentifizierung mit Angabe der Ursache an den VLR/SGSN + zurück, und der Benutzer bricht das Verfahren ab. + \item + Wenn die MAC korrekt ist, prüft das USIM, ob die empfangene + Sequenznummer SQN im richtigen Bereich liegt: + + \begin{itemize} + \item + Liegt die Sequenznummer nicht im korrekten Bereich, sendet das + USIM einen Synchronisationsfehler an den VLR/SGSN zurück, + einschließlich eines entsprechenden Parameters, und bricht das + Verfahren ab. + \end{itemize} + \item + Wenn die Sequenznummer im korrekten Bereich liegt, berechnet das + USIM: + + \begin{itemize} + \item + die Authentifizierungsantwort \$RES = f2\_K(RAND)\$ + \item + den Chiffrierschlüssel \$CK = f3\_K(RAND)\$ und den + Integritätsschlüssel \$IK = f4\_K(RAND)\$ + \end{itemize} + \end{itemize} + \end{itemize} + + + \subsubsection{Schlussfolgerungen zur Sicherheit in UMTS + Release'99} + + \begin{itemize} + \item + Die Sicherheit von UMTS Release '99 ist der Sicherheit von GSM sehr + ähnlich: + + \begin{itemize} + \item + Der Heimat-AUC generiert Challenge-Response-Vektoren + \item + Die Challenge-Response-Vektoren werden ungeschützt über das + Signalisierungsnetz an ein besuchtes Netz übertragen, das die + Authentizität eines Handys überprüfen muss. + \item + Anders als bei GSM authentifiziert sich das Netz auch gegenüber dem + Mobiltelefon + \item + Die IMSI, die einen Benutzer eindeutig identifiziert: + + \begin{itemize} + \item + wird immer noch dem besuchten Netz offenbart + \item + kann immer noch von einem Angreifer, der sich als Basisstation + ausgibt, abgefragt werden, da es in diesem Fall keine + Netzauthentifizierung gibt! + \end{itemize} + \item + Das Sicherheitsmodell setzt weiterhin Vertrauen zwischen allen + Netzbetreibern voraus + \item + Vertraulichkeit ist nur auf der Funkstrecke gegeben + \end{itemize} + \item + Zusammenfassend lässt sich sagen, dass UMTS Release'99 genauso sicher + sein soll wie ein unsicheres Festnetz + \end{itemize} + + + \subsection{Sicherheit in LTE-Netzen} + + \begin{itemize} + \item + Eine Weiterentwicklung von UMTS, so dass viele der Sicherheitskonzepte + gleich geblieben sind + + \begin{itemize} + \item + Das Protokoll zur Authentifizierung und Schlüsselvereinbarung (AKA) + ist im Wesentlichen dasselbe wie bei UMTS. + \item + Allerdings wird ein Master Key KASME abgeleitet, der dann zur + Ableitung von Integritäts- und Verschlüsselungsschlüsseln verwendet + wird + \end{itemize} + \item + Bemerkenswerte Unterschiede: + + \begin{itemize} + \item + GSM-SIMs dürfen nicht mehr auf das Netz zugreifen + \item + KASUMI wird nicht mehr verwendet, stattdessen werden SNOW, AES oder + ZUC (ein chinesischer Stream Cipher, der für LTE entwickelt wurde) + eingesetzt + \item + Das zugehörige Festnetz (Evolved Packet Core genannt) ist + vollständig paketvermittelt und normalerweise durch IPsec und IKEv2 + geschützt. + \item + Heim-eNBs + \end{itemize} + \item + Allerdings oft neue Namen für sehr ähnliche Dinge, z.B., + + \begin{itemize} + \item + Anstelle der TMSI wird eine Globally Unique Temporary Identity + (GUTI) verwendet, die aus Folgendem besteht: + + \begin{itemize} + \item + Einer PLMN-ID, MMEI und einer M-TMSI + \item + Damit werden das Public Land Mobile Network (PLMN), die Mobility + Management Entity (MME), vergleichbar mit der MSC in GSM/UMTS, und + das mobile Gerät (M-TMSI) identifiziert + \end{itemize} + \end{itemize} + \end{itemize} + + + \section{Referenzen} + + \begin{itemize} + \item + {[}AES01a{]} National Institute of Standards and Technology - + Specification for the Advanced Encryption Standard (AES) + \item + {[}DR97a{]} J. Daemen, V. Rijmen - AES Proposal: Rijndael + \href{http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf}{http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf} + \item + {[}FMS01a{]} S. Fluhrer, I. Mantin, A. Shamir - Weaknesses in the Key + Scheduling Algorithm of RC4. Eighth Annual Workshop on Selected Areas + in Cryptography + \item + {[}Riv01a{]} R. Rivest. - RSA Security Response to Weaknesses in Key + Scheduling Algorithm of RC4. + \href{http://www.rsa.com/rsalabs/node.asp}{http://www.rsa.com/rsalabs/node.asp} + \item + {[}SIR01a{]} A. Stubblefield, J. Ioannidis, A. D. Rubin. - Using the + Fluhrer, Mantin, and Shamir Attack to Break WEP. AT\&T Labs Technical + Report TD-4ZCPZZ + \item + {[}FKLS00{]} N. Ferguson, J. Kelsey, S. Lucks, B. Schneier, M. Stay, + D.Wagner, D. Whiting - Improved cryptanalysis of Rijndael. In FSE'00, + volume 1978 of Lecture Notes in Computer Science. Springer, 2000. + \item + {[}GM00{]} H. Gilbert and M. Minier - A Collision Attack on 7 Rounds + of Rijndael. In AES Candidate Conference, 2000. + \item + {[}BKR11{]} A. Bogdanov, D. Khovratovich, C. Rechberger - Biclique + cryptanalysis of the full AES. In ASIACRYPT'11, 2001. + \item + {[}Mir02{]} I. Mironov - (Not so) random shuffles of RC4. In Advances + in Cryptology - CRYPTO 2002 + \item + {[}Kle08{]} A.Klein. - Attacks on the RC4 stream cipher. In Designs, + Codes and Cryptography + \item + {[}ETS12{]} ETSI/SAGE - Specification of the 3GPP confidentiality and + integrity algorithms; Document 2: Kasumi specification + \item + {[}Kue01{]} U. Kühn. - Cryptanalysis of Reduced-Round MISTY. In + Advances in Cryptology - EUROCRYPT 2001 + \item + {[}BDN05{]} E. Biham, O. Dunkelman, N. Keller - A Related-Key + Rectangle Attack on the Full KASUMI , In ASIACRYPT 2005 + \item + {[}DKS10{]} O. Dunkelman, N. Keller, A. Shamir - A practical-time + related-key attack on the KASUMI cryptosystem used in GSM and 3G + telephony. In CRYPTO'10 + \item + {[}ETS06{]} ETSI/SAGE - Specification of the 3GPP Confidentiality and + Integrity Algorithms UEA2 \& UIA2. Document 2: SNOW 3G Specification + \item + {[}KY11{]} A. Kircanski A.M. Youssef. - On the Sliding Property of + SNOW 3G and SNOW 2.0 IET Inf. Secur. + \item + {[}Amo94{]} E. G. Amorosi. - Fundamentals of Computer Security + Technology + \item + {[}Cha95{]} Brent Chapman and Elizabeth Zwicky - Building Internet + Firewalls + \item + {[}For94b{]} Warwick Ford. - Computer Communications Security - + Principles, Standard Protocols and Techniques. + \item + {[}Gar96{]} Simson Garfinkel and Gene Spafford - Practical Internet \& + Unix Security + \item + {[}Men97a{]} A. J. Menezes, P. C. Van Oorschot, S. A. Vanstone - + Handbook of Applied Cryptography. CRC Press Series on Discrete + Mathematics and Its Applications + \item + {[}SR14{]} G. Schäfer, M. Rossberg - Netzsicherheit + \item + {[}Sch96{]} B. Schneier - Applied Cryptography Second Edition: + Protocols, Algorithms and Source Code in C + \item + {[}Sta13{]} W. Stallings - Cryptography and Network Security: + Principles and Practice + \item + {[}Sti05{]} D. R. Stinson - Cryptography: Theory and Practice + (Discrete Mathematics and Its Applications) + \item + {[}Bre88a{]} D. M. Bressoud. - Factorization and Primality Testing + \item + {[}Cor90a{]} T. H. Cormen, C. E. Leiserson, R. L. Rivest. Introduction + to Algorithms. + \item + {[}DH76{]} W. Diffie, M. E. Hellman - New Directions in Cryptography + \item + {[}ElG85a{]} T. ElGamal - A Public Key Cryptosystem and a Signature + Scheme based on Discrete Logarithms. + \item + {[}Kob87a{]} N. Koblitz - A Course in Number Theory and Cryptography + \item + {[}Men93a{]} A. J. Menezes - Elliptic Curve Public Key Cryptosystems. + \item + {[}Niv80a{]} I. Niven, H. Zuckerman - An Introduction to the Theory of + Numbers + \item + {[}RSA78{]} R. Rivest, A. Shamir und L. Adleman - A Method for + Obtaining Digital Signatures and Public Key Cryptosystems + \item + {[}KAFL10{]} T. Kleinjung, K. Aoki, J. Franke, A. Lenstra, E. Thomé, + J. Bos, P. Gaudry, A. Kruppa, P. Montgomery, D. Osvik, H. Te Riele, + A.Timofeev, P. Zimmermann - Factorization of a 768-bit RSA modulus + \item + {[}LM10{]} M. Lochter, J. Merkle - Elliptic Curve Cryptography (ECC) + Brainpool Standard Curves and Curve Generation + \item + {[}NIST99{]} NIST - Recommended Elliptic Curves for Federal Government + Use + \item + {[}NIST12{]} NIST - Recommendation for Key Management: Part 1: General + (Revision 3) + \item + {[}Ko87{]} N. Koblitz - Elliptic Curve Cryptosystems + \item + {[}BBP12{]} B.B. Brumley, M. Barbosa, D. Page, F. Vercauteren - + Practical realisation and elimination of an ECC-related software bug + attack + \item + {[}BT11{]} B.B. Brumley, N. Tuveri - Remote timing attacks are still + practical + \item + {[}BLR08{]} D. Bernstein, T. Lange, R. Rezaeian Farashahi - Binary + Edwards Curves + \item + {[}NIST09{]} NIST - Digital Signature Standard (DSS) + \item + {[}SM09{]} A. Sorniotti, R. Molva - A provably secure secret handshake + with dynamic controlled matching + \item + {[}BF03{]} D. Boneh, M. Franklin - Identity-Based Encryption from the + Weil Pairing + \item + {[}Sch85{]} R. Schoof - Elliptic Curves over Finite Fields and the + Computation of Square Roots mod p + \item + {[}Kra97a{]} H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing + for Message Authentication. Internet RFC 2104, February 1997. + \item + {[}Mer89a{]} R. Merkle. One Way Hash Functions and DES. Proceedings of + Crypto `89, Springer, 1989 + \item + {[}Men97a{]} A. J. Menezes, P. C. Van Oorschot, S. A. Vanstone. + Handbook of Applied Cryptography, CRC Press Series on Discrete + Mathematics and Its Applications, Hardcover, 816 pages, CRC Press, + 1997 + \item + {[}NIST02{]} National Institute of Standards and Technology (NIST). + Secure Hash Standard. Federal Information Processing Standards + Publication (FIPS PUB), 180-2, 2002 + \item + {[}Riv92a{]} R. L. Rivest. The MD5 Message Digest Algorithm. Internet + RFC 1321, April 1992 + \item + {[}Rob96a{]} M. Robshaw. On Recent Results for MD2, MD4 and MD5. RSA + Laboratories' Bulletin, No. 4, November 1996 + \item + {[}WYY05a{]} X. Wang, Y. L. Yin, H. Yu. Finding collisions in the full + SHA-1. In Advances in Cryptology - CRYPTO'05, pages 18-36, 2005 + \item + {[}Yuv79a{]} G. Yuval. How to Swindle Rabin. Cryptologia, July 1979. + \item + {[}WLYF04{]} X. Wang, D. Feng, X. Lai, H. Yu. Collisions for Hash + Functions MD4, MD5, HAVAL-128 and RIPEMD. IACR Eprint archive, 2004. + \item + {[}LWW05{]} A. Lenstra, X. Wang, B. de Weger. Colliding X.509 + Certificates. Cryptology ePrint Archive: Report 2005/067. 2005 + \item + {[}LD05{]} S. Lucks, M. Daum. The Story of Alice and her Boss. In Rump + session of Eurocrypt'05. 2005. + \item + {[}Kl06{]} V. Klima. Tunnels in Hash Functions: MD5 Collisions Within + a Minute (extended abstract), Cryptology ePrint Archive: Report + 2006/105, 2006 + \item + {[}SA09{]} Y. Sasaki, K. Aoki. Finding Preimages in Full MD5 Faster + Than Exhaustive Search. Advances in Cryptology - EUROCRYPT'09. 2009 + \item + {[}Man11{]} M. Manuel. Classification and Generation of Disturbance + Vectors for Collision Attacks against SHA-1. Journal Designs, Codes + and Cryptography. Volume 59, Issue 1-3, pages 247-263, 2011 + \item + {[}GH04{]} H. Gilbert, H. Handschuh. Security Analysis of SHA-256 and + Sisters. Lecture Notes in Computer Science, 2004, Volume 3006/2004, + pages 175-193. 2004 + \item + {[}AGM09{]} K. Aoki, J. Guo, K. Matusiewicz, V. Sasaki, L. Wang. + Preimages for Step-Reduced SHA-2. Advances in Cryptology - ASIACRYPT + 2009. pages 578-597, 2009 + \item + {[}KK06{]} J. Kelsey, T. Kohno. Herding Hash Functions and the + Nostradamus Attack. Advances in Cryptology - EUROCRYPT'06. 2006 + \item + {[}Jou04{]} A. Joux: Multicollisions in Iterated Hash Functions. + Application to Cascaded Constructions. CRYPTO 2004: pages 306-316. + 2004 + \item + {[}MV04{]} D. McGrew, J. Viega. The Security and Performance of the + Galois/Counter Mode (GCM) of Operation (Full Version). + \href{http://eprint.iacr.org/2004/193.}{http://eprint.iacr.org/2004/193.} + \item + {[}Fer05{]} N. Ferguson. Authentication weaknesses in GCM. 2005 + \item + {[}Dwo07{]} M. Dworkin. Recommendation for Block Cipher Modes of + Operation: Galois/Counter Mode (GCM) and GMAC. NIST Special + Publication 800-38D. 2007 + \item + {[}Saa11{]} M. Saarinen. GCM, GHASH and Weak Keys. Cryptology ePrint + Archive, Report 2011/202, + \href{http://eprint.iacr.org/2011/202,}{http://eprint.iacr.org/2011/202,} + 2011 + \item + {[}BDP07{]} G. Bertoni, J. Daemen, M. Peeters, G. Van Assche. Sponge + Functions. Ecrypt Hash Workshop 2007 + \item + {[}BDP11a{]} G. Bertoni, J. Daemen, M. Peeters, G. Van Assche. + Cryptographic sponge functions. Research report. Version 0.1. 2011 + \item + {[}BDP11b{]} G. Bertoni, J. Daemen, M. Peeters, G. Van Assche. The + Keccak reference. Research report. Version 3.0. 2011 + \item + {[}BM92{]} BELLOVIN, S.; MERRITT, M.: Encrypted Key Exchange: + Password-Based Protocols Secure Against Dictionary Attacks. In: IEEE + Computer Society Symposium on Research in Security and Privacy, 1992 + \item + {[}Bry88{]} BRYANT, R.: Designing an Authentication System: A Dialogue + in Four Scenes. 1988. Project Athena, Massachusetts Institute of + Technology, Cambridge, USA + \item + {[}GNY90{]} GONG, L.; NEEDHAM, R. M.; YAHALOM, R.: Reasoning About + Belief in Cryptographic Protocols. In: Symposium on Research in + Security and Privacy IEEE Computer Society, IEEE Computer Society + Press, May 1990 + \item + {[}KNT94{]} KOHL, J.; NEUMAN, B.; TS'O, T.: The Evolution of the + Kerberos Authentication Service. In: BRAZIER, F.; JOHANSEN, D. (Eds): + Distributed Open Systems, IEEE Computer Society Press, 1994 + \item + {[}NS78{]} NEEDHAM, R. M.; SCHROEDER, M. D.: Using Encryption for + Authentication in Large Networks of Computers. In: Communications of + the ACM, 1978 + \item + {[}NS87{]} NEEDHAM, R.; SCHROEDER, M.: Authentication Revisited. In: + Operating Systems Review, 1987 + \item + {[}NYH+05{]} NEUMAN, C.; YU, T.; HARTMAN, S. ; RAEBURN, K.: The + Kerberos Network Authentication Service (V5)\_. 2005. - RFC 4120, + IETF, Status: Standard, + \href{https://tools.ietf.org/html/rfc4120}{https://tools.ietf.org/html/rfc4120} + \item + {[}OR87{]} OTWAY, D.; REES, O.: Efficient and Timely Mutual + Authentication. In: Operating Systems Review, 1987 + \item + {[}Pat97{]} PATEL, S.: Number Theoretic Attacks On Secure Password + Schemes. In: IEEE Symposium on Security and Privacy, 1997 + \item + {[}Sch05{]} SCHAAD, J.: Internet X.509 Public Key Infrastructure + Certificate Request Message Format (CRMF). September 2005. - RFC 4211, + IETF, Status: Proposed Standard, + \href{https://tools.ietf.org/html/rfc4211}{https://tools.ietf.org/html/rfc4211} + \item + {[}RFC1661{]} W. Simpson. \emph{The Point-to-Point Protocol (PPP).} + RFC 1661, 1994. + \item + {[}RFC1968{]} G. Meyer. \emph{The PPP Encryption Control Protocol + (ECP).} RFC 1968, 1996. + \item + {[}RFC1994{]} W. Simpson. \emph{PPP Challenge Handshake Authentication + Protocol (CHAP).} RFC 1994 (obsoletes RFC 1334), 1996. + \item + {[}RFC2284{]} L. Blunk, J. Vollbrecht. \emph{PPP Extensible + Authentication Protocol (EAP).} RFC 2284, 1998. + \item + {[}RFC2289{]} N. Haller, C. Metz, P. Nesser, M. Straw. \emph{A + One-Time Password System.} RFC 2289, 1998. + \item + {[}RFC2341{]} A. Valencia, M. Littlewood, T. Kolar. \emph{Cisco Layer + Two Forwarding Protocol (L2F).} RFC 2341, 1998. + \item + {[}RFC2419{]} K. Sklower, G. Meyer. \emph{The PPP DES Encryption + Protocol, Version 2 (DESE-bis).} RFC 2419 (obsoletes RFC 1969), 1998. + \item + {[}RFC2420{]} H. Kummert. \emph{The PPP Triple-DES Encryption Protocol + (3DESE).} RFC 2420, 1998. + \item + {[}RFC2433{]} G. Zorn, S. Cobb. \emph{Microsoft PPP CHAP Extensions.} + RFC 2433, 1998. + \item + {[}RFC2637{]} K. Hamzeh, G. Pall , W. Verthein, J. Taarud, W. Little, + G. Zorn. \emph{Point-to-Point Tunneling Protocol (PPTP).} RFC 2637, + 1999. + \item + {[}RFC2661{]} W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, + B. Palter. \emph{Layer Two Tunneling Protocol (L2TP).} RFC 2661, 1999. + \item + {[}RFC2828{]} R. Shirey. \emph{Internet Security Glossary.} RFC 2828, + 2000. + \item + {[}RFC3078{]} G. Pall, G. Zorn. \emph{Microsoft Point to Point + Encryption Protocol (MPPE).} RFC 3078, 2001. + \item + {[}SM98a{]} B. Schneier, Mudge. \emph{Cryptanalysis of Microsoft's + Point-to-Point Tunneling Protocol (PPTP).} Proceedings of the 5th ACM + Conference on Communications and Computer Security, ACM Press, 1998. + \item + {[}SMW99a{]} B. Schneier, Mudge, D. Wagner. \emph{Cryptanalysis of + Microsoft's PPTP Authentication Extensions (MSCHAPv2).} Counterpane + Systems, 1999. + \item + {[}FH98a{]} P. Ferguson, G. Huston. \emph{What is a VPN?} The Internet + Protocol Journal, Cisco Systems. 1998. + \item + {[}ATM99a{]} ATM Forum. \emph{ATM Security Specification Version 1.0.} + AF-SEC-0100.000, + \item + {[}RFC2401{]} R. Atkinson, S. Kent. Security Architecture for the + Internet Protocol. RFC 2401, Internet Engineering Taskforce (IETF), + 1998. + \item + {[}RFC2402{]} R. Atkinson, S. Kent. IP Authentication Header (AH). RFC + 2402, IETF, 1998. {[}RFC2403{]} C. Madson, R. Glenn. The Use of + HMAC-MD5-96 within ESP and AH. RFC 2403, IETF, 1998. + \item + {[}RFC2404{]} C. Madson, R. Glenn. The Use of HMAC-SHA-1-96 within ESP + and AH. RFC 2404, IETF, 1998. + \item + {[}RFC2405{]} C. Madson, N. Doraswami. The ESP DES-CBC Cipher + Algorithm With Explicit IV. RFC 2405, IETF, 1998. + \item + {[}RFC2406{]} R. Atkinson, S. Kent. IP Encapsulating Security Payload + (ESP). RFC 2406, IETF, 1998. + \item + {[}RFC2407{]} D. Piper. The Internet IP Security Domain of + Interpretation for ISAKMP. RFC 2407, IETF, 1998. + \item + {[}RFC2408{]} D. Maughan, M. Schertler, M. Schneider, J. Turner. + Internet Security Association and Key Management Protocol (ISAKMP). + RFC 2408, - IETF, 1998. + \item + {[}RFC2409{]} D. Harkins, D. Carrel. The Internet Key Exchange (IKE). + RFC 2409, IETF, 1998. + \item + {[}RFC2857{]} A. Keromytis, N. Provos. The Use of HMAC-RIPEMD-160-96 + within ESP and AH. RFC 2857, IETF, 2000. + \item + {[}RFC3947{]} T. Kivinen, B. Swander, A. Huttunen, V. Volpe: + \emph{Negotiation of NAT-Traversal in the IKE.} RFC 3947, IETF, 2005. + \item + {[}RFC3948{]} A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M. + Stenberg: \emph{UDP Encapsulation of IPsec ESP Packets.} RFC 3948, + IETF, 2005. + \item + {[}RFC4306{]} C. Kaufman: \emph{Internet Key Exchange (IKEv2) + Protocol.} RFC 4306, Internet Engineering Taskforce (IETF), 2005. + \item + {[}NiMe08{]} P. Nikander, J. Melen: \emph{A Bound End-to-End Tunnel + (BEET) mode for ESP.} Internet-Draft, IETF Network Working Group, + 2008. + \item + {[}Bhai08{]} Y. Bhaiji: \emph{Network Security Technologies and + Solutions} , Cisco Press, 2008. + \item + {[}Fluh01{]} S. Fluhrer: \emph{Tunnel Endpoint Discovery.} Expired + Internet-Draft, IETF IPSP Working Group, 2001. + \item + {[}Tran06{]} T.H. Tran: \emph{Proactive Multicast-Based IPSEC + Discovery Protocol and Multicast Extension.} Military Communications + Conference, 2006. + \item + {[}FBJW08{]} R. Figueiredo, P. O. Boykin, P. St. Juste, D. Wolinsky: + \emph{Social VPNs: Integrating Overlay and Social Networks for + Seamless P2P Networking'.} IEEE WETICE/COPS, 2008. + \item + {[}RSS10{]} M. Rossberg, T. Strufe, G. Schaefer: \emph{Distributed + Automatic Configuration of Complex IPsec-Infrastructures.} Journal of + Network and Systems Management, Volume 18, Issue 3, 2010. + \item + {[}RSSM09{]} M. Rossberg, W. Steudel, G.Schaefer, M. Martius: + \emph{Eine Software-Architektur zur Konstruktion flexibler + IPsec-Infrastrukturen.} BSI 11. Deutscher IT-Sicherheitskongress, + 2009. + \item + {[}BKS98a{]} D. Bleichenbacher, B. Kaliski, J. Staddon. \emph{Recent + Results on PKCS \#1: RSA Encryption Standard.} RSA Laboratories' + Bulletin 7, 1998 + \item + {[}Cop96a{]} D. Coppersmith, M. K. Franklin, J. Patarin, M. K. Reiter. + \emph{Low Exponent RSA with Related Messages.} In Advance in + Cryptology -\/- Eurocrypt'96, U. Maurer, Ed., vol. 1070 of Lectures + Notes in Computer Science, Springer-Verlag, 1996 + \item + {[}FKK96a{]} A. O. Freier, P. Karlton, P. C. Kocher. \emph{The SSL + Protocol Version 3.0.} Netscape Communications Corporation, 1996 + \item + {[}DA99{]} T. Dierks, C. Allen. \emph{The TLS Protocol Version 1.0.} + RFC 2246, 1999 + \item + {[}DR08{]} T. Dierks, E. Rescorla. \emph{The Transport Layer Security + (TLS) Protocol Version 1.2.} RFC 5246, 2008 + \item + {[}RD10{]} J. Rizzo, T. Duong, Practical Padding Oracle Attacks, 4th + USENIX conference on Offensive technologies (WOOT), 2010 + \item + {[}RRDO10{]} E. Rescorla, M. Ray, S. Dispensa, N. Oskov. + \emph{Transport Layer Security (TLS) Renegotiation Indication + Extension} , RFC 5746. 2010 + \item + {[}Zo11{]} T. Zoller. \emph{TLS \& SSLv3 renegotiation vulnerability.} + Technical report, G-SEC. 2011 + \item + {[}RM12{]} E. Rescorla, N. Modadugu. \emph{Datagram Transport Layer + Security Version 1.2.} RFC 6347, 2012 + \item + {[}LL06{]} S. Lehtinen, C. Lonvick. \emph{The Secure Shell (SSH) + Protocol Assigned Numbers.} RFC 4250, 2006 + \item + {[}YL06a{]} T. Ylonen, C. Lonvick. \emph{The Secure Shell (SSH) + Protocol Architecture.} RFC 4251, 2006 + \item + {[}YL06b{]} T. Ylonen, C. Lonvick. \emph{The Secure Shell (SSH) + Authentication Protocol.} RFC 4252, 2006 -{[}YL06c{]} T. Ylonen, C. + Lonvick. \emph{The Secure Shell (SSH) Transport Layer Protocol} , RFC + 4253, 2006 -{[}YL06d{]} T. Ylonen, C. Lonvick. \emph{The Secure Shell + (SSH) Connection Protocol.} RFC 4254, 2006 -{[}SG09{]} D. Stebila, J. + Green. \emph{Elliptic Curve Algorithm Integration in the Secure Shell + Transport Layer} , RFC 5656. 2009 -{[}IS09{]} K. Igoe, J. Solinas. + \emph{AES Galois Counter Mode for the Secure Shell Transport Layer + Protocol.} RFC 5647. 2009 + \item + {[}Müller99a{]} G. Müller, K. Rannenberg (Ed.). \emph{Multilateral + Security in Communications.} Addison-Wesley-Longman, 1999 + \item + {[}BGW01a{]} N. Borisov, I. Goldberg, D. Wagner. Intercepting Mobile + Communications: The Insecurity of 802.11. 7th ACM SIGMOBILE Annual + International Conference on Mobile Computing and Networking (MOBICOM), + Rome, Italy, July 2001 + \item + {[}FMS01a{]} S. Fluhrer, I. Mantin, A. Shamir. Weaknesses in the Key + Scheduling Algorithm of RC4. Eighth Annual Workshop on Selected Areas + in Cryptography, August 2001 {[}IEEE12{]} IEEE. Wireless LAN Medium + Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE Std + 802.11-2012, The Institute of Electrical and Electronics Engineers + (IEEE), 2012 + \item + {[}Riv01a{]} R. Rivest. RSA Security Response to Weaknesses in Key + Scheduling Algorithm of RC4. + \href{http://www.rsa.com/rsalabs/technotes/wep.html}{http://www.rsa.com/rsalabs/technotes/wep.html}, + 2001 + \item + {[}SIR01a{]} A. Stubblefield, J. Ioannidis, A. D. Rubin. Using the + Fluhrer, Mantin, and Shamir Attack to Break WEP. AT\&T Labs Technical + Report TD-4ZCPZZ, August 2001 + \item + {[}TWP07{]} E. Tews, R. P. Weinmann, A. Pyshkin. Breaking 104 bit WEP + in less than 60 seconds. Information Security Applications, 188-202, + 2007 + \item + {[}WM02a{]} N. C. Winget, T. Moore, D. Stanley, J. Walker. IEEE + 802.11i Overview. NIST 802.11 Wireless LAN Security Workshop, Falls + Church, Virginia, December 4-5, 2002 + \item + {[}RFC2898{]}B. Kaliski. PKCS \#5: Password-Based Cryptography + Specification Version 2.0. IETF Request for Comments 2898, 2000 + \item + {[}RFC3394{]}J. Schaad, R. Housley. Advanced Encryption Standard (AES) + Key Wrap Algorithm. IETF Request for Comments 3394, 2002 + \item + {[}3GPP00a{]} 3GPP. 3G Security: Security Architecture (Release 1999). + 3rd Generation Partnership Project, Technical Specification Group + Services and System Aspects, 2000 + \item + {[}3GPP02a{]} 3GPP. 3G Security: Security Architecture (Release 5), + 2002 + \item + {[}3GPP02b{]} 3GPP. Security Mechanisms for the (U)SIM application + toolkit, December 2002 + \item + {[}ETSI93a{]} ETSI TC-GSM. GSM Security Aspects (GSM 02.09). + Recommendation GSM, European Telecommunications Standards Institute + (ETSI), 1993 + \item + {[}ETSI94a{]} ETSI TC-SMG. European Digital Cellular + Telecommunications System (Phase 2): Security Related Network + Functions (GSM 03.20). ETS 300 534, European Telecommunications + Standards Institute (ETSI), 1994 + \item + {[}Les02a{]} Lescuyer, P. UMTS -- Grundlagen, Architektur und + Standard. dpunkt.verlag, 2002 + \item + {[}Sch03a{]} J. Schiller. Mobile Communications - The Course. + \href{http://www.inf.fu-berlin.de/inst/ag-tech/resources/mobilecommunications.htm}{http://www.inf.fu-berlin.de/inst/ag-tech/resources/mobilecommunications.htm} + \item + {[}Sch03b{]} J. Schiller. Mobile Communications. second edition, + Addison-Wesley, 2003 + \end{itemize} + \end{multicols} \end{document} \ No newline at end of file