From 7c5c22e9351e884c953b4f4256b9484ed4bf379f Mon Sep 17 00:00:00 2001 From: wieerwill Date: Thu, 10 Mar 2022 10:40:21 +0100 Subject: [PATCH] Formatierung einheitlich --- Network Security - Cheatsheet.pdf | 4 +- Network Security - Cheatsheet.tex | 4523 +++++++++++++---------------- 2 files changed, 2032 insertions(+), 2495 deletions(-) diff --git a/Network Security - Cheatsheet.pdf b/Network Security - Cheatsheet.pdf index 15a6a71..762c14e 100644 --- a/Network Security - Cheatsheet.pdf +++ b/Network Security - Cheatsheet.pdf @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:cc2df2a8ea31996ba097027b53117d16b693bf581777a45c3384398b9c0f06f4 -size 725534 +oid sha256:ab70a8de46b27afded62df0e49b7a36f4f6e3f14c3d0dea85d92708ac56f18d7 +size 726287 diff --git a/Network Security - Cheatsheet.tex b/Network Security - Cheatsheet.tex index 5e5a25d..6280e6f 100644 --- a/Network Security - Cheatsheet.tex +++ b/Network Security - Cheatsheet.tex @@ -2081,7 +2081,7 @@ \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: + \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) @@ -2094,111 +2094,69 @@ \section{Zufallszahlengenerierung} \subsection{Aufgaben der Schlüsselverwaltung} \begin{itemize*} - \item Erzeugung: + \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. + \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 + \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: + \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. + \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: + \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. + \item Schlüssel, insbesondere Authentifizierungsschlüssel, sollten sicher gespeichert werden + \item entweder verschlüsselt mit einer schwer zu erratenden Passphrase, oder besser + \item in einem sicheren Gerät wie einer Smart-Card \end{itemize*} + \item Entzug: 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) + \item Vernichtung: Schlüssel, die nicht mehr verwendet werden (z. B. alte Sitzungsschlüssel), sollten sicher vernichtet werden \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 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: + \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*} + \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*} - - \subsection{Zufalls- und - Pseudo-Zufallszahlengenerierung} - + \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 $\lfloor lg - n\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>> k$ ausgibt, die ,,zufällig'' erscheint. - Die Eingabe in den PRBG wird als Seed bezeichnet, die Ausgabe als - pseudozufällige Bitfolge. - \item Bemerkungen: + \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 $\lfloor lg n\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>> 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: + \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\times y_{i-1} + b\ mod\ 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: + \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 $\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 + \item Definition: Ein PRBG besteht alle statistischen Polynomialzeit-Tests, wenn kein deterministischer olynomialzeit-Algorithmus zwischen einer Ausgangssequenz des Generators und einer echten Zufallssequenz derselben Länge mit einer Wahrscheinlichkeit deutlich größer als 0 unterscheiden kann + \item Polynomialzeit-Algorithmus bedeutet, dass die Laufzeit des Algorithmus durch ein Polynom in der Länge m der Sequenz begrenzt ist + \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 $\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: + \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, @@ -2208,11 +2166,8 @@ \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 + \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, @@ -2220,38 +2175,26 @@ \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 + \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: + \item Verzerrung \begin{itemize*} \item Betrachten wir einen Zufallsgenerator, der verzerrte, aber unkorrelierte Bits erzeugt, z. B. 1en mit der Wahrscheinlichkeit $p\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: + \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 + \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} - + \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: + \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? @@ -2263,52 +2206,54 @@ \end{itemize*} \end{itemize*} - - \subsection{Sichere - Pseudo-Zufallszahlengenerierung} - + \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: + \item Es gibt eine Reihe von Algorithmen, die kryptografische Hash-Funktionen oder Verschlüsselungsalgorithmen zur Erzeugung von kryptografisch sicheren Pseudozufallszahlen verwenden + \item Obwohl diese Verfahren nicht als sicher bewiesen werden können, scheinen sie für die meisten praktischen Situationen ausreichend + \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\oplus s)$ \item $s = E(K, (x_i\oplus q)$ \end{enumerate*} \item $Return(x_1,x_2,...x_m)$ \end{enumerate*} + \begin{enumerate*} + \item $q = E(K, Date_Time)$ + \item For i von 1 bis m do + \begin{enumerate*} + \item $x_i = E(K, (q\oplus s)$ + \item $s = E(K, (x_i\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: + \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\times q$ und $\phi=(p-1)\times(q-1)$. Wähle eine zufällige ganze Zahl e so, dass $1\textless e\textless\phi$ und $gcd(e,\phi)=1$ \item Wähle eine zufällige ganze Zahl $y_0$ (den Keim) so, dass $y_0\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\ mod\ n$ \item $z_i =$ das niedrigstwertige Bit von $y_i$ \end{enumerate*} + \begin{enumerate*} + \item $y_i=(y_{i-1})^e\ mod\ 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\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: + \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\times q$ \item Wähle eine zufällige ganze Zahl s (den Keim) so, dass $s\in ,,1, n-1''$ liegt, so dass $gcd(s,n)=1$ und $y_0=s^2\ mod\ n$ \item Für i von 1 bis k tun - \begin{enumerate*} \def\labelenumii{\arabic{enumii}.} \item $y_i = (y_{i-1})^2\ mod\ n$ \item $z_i =$ das niedrigstwertige Bit von $y_i$ \end{enumerate*} + \begin{enumerate*} + \item $y_i = (y_{i-1})^2\ mod\ 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 @@ -2321,14 +2266,14 @@ \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*} + \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!} - + \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 @@ -2349,10 +2294,7 @@ \end{itemize*} \end{itemize*} - - \section{Kryptographische - Protokolle} - + \section{Kryptographische Protokolle} \begin{itemize*} \item Definition: Ein kryptographisches Protokoll ist definiert als eine Reihe von Schritten und der Austausch von Nachrichten zwischen @@ -2370,10 +2312,7 @@ \end{itemize*} \end{itemize*} - - \subsection{Anwendungen von kryptographischen - Protokollen} - + \subsection{Anwendungen von kryptographischen Protokollen} \begin{itemize*} \item Schlüsselaustausch \item Authentifizierung @@ -2382,113 +2321,103 @@ \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 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 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: + \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: + \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. + \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. + \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: + \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*} + \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. + \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: + \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 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. + \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: + \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*} + \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*} + \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*} + \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: + \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*} + \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*} + \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} + \subsection{Notation kryptographischer Protokolle} %\begin{longtable}[]{@{}ll@{}} % \toprule @@ -2519,20 +2448,16 @@ % \bottomrule %\end{longtable} - - \subsection{Das - Needham-Schroeder-Protokoll} - + \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: + \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\rightarrow TTP: (A, B, r_A)$ \end{enumerate*} + \begin{enumerate*} + \item $A\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\rightarrow A:{r_A, B, K_{A,B}, {K_{A,B}, A}_{{K}{B,TTP}}}_{{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\rightarrow B:{K_{A,B}, A}_{{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\rightarrow A:{r_B}_{{K}{A,B}}$ @@ -2543,14 +2468,18 @@ \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\rightarrow B:{K_{A,B}, A}_{{K}{B,TTP}}$ \item $B\rightarrow A:{r_B}_{{K}{A,B}}$ Eve muss diese Nachricht abfangen \item $E\rightarrow B:{r_B -1}_{{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*} + \begin{enumerate*} + \item $E\rightarrow B:{K_{A,B}, A}_{{K}{B,TTP}}$ + \item $B\rightarrow A:{r_B}_{{K}{A,B}}$ Eve muss diese Nachricht abfangen + \item $E\rightarrow B:{r_B -1}_{{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 @@ -2558,7 +2487,9 @@ 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\rightarrow B:(i_A, A, B,{r_A, i_A, A, B}_{{K}{A,TTP}})$ \end{enumerate*} + \begin{enumerate*} + \item $A\rightarrow B:(i_A, A, B,{r_A, i_A, A, B}_{{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\rightarrow TTP:(i_A, A, B,{r_A,i_A,A,B}_{{K}{A,TTP}},{r_B,i_A,A,B}_{{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\rightarrow B:(i_A,{r_A,K_{A,B}}_{{K}{A,TTP}},{r_B, K_{A,B}}_{{K}{B,TTP}})$ \item Bob entschlüsselt seinen Teil der Nachricht, verifiziert rB und sendet Alices Teil der Nachricht an sie: 4. $B\rightarrow A:(i_A,{r_A,K_{A,B}}_{{K}{A,TTP}})$ @@ -2571,13 +2502,9 @@ \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 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 @@ -2585,18 +2512,10 @@ \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: + \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. @@ -2605,58 +2524,22 @@ \end{itemize*} Zugriff auf einen Dienst mit Kerberos - Protokollübersicht - \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Kerberos.png} - \item Der Benutzer meldet sich an seiner Arbeitsstation an und fordert den - Zugriff auf einen Dienst an: + \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\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\rightarrow A:{ K_{A,TGS}, TGS, t_{AS}, LifetimeTicket_{TGS}, Ticket_{TGS}}_{K_A}$ mit $Ticket_{TGS}={K_{A,TGS},A, Addr_A, TGS, t_{AS}, LifetimeTicket_{TGS}}_{{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\rightarrow TGS:(S1, Ticket_{TGS}, - Authenticator_{A,TGS})$ mit Authenticator - $A,TGS={A,Addr_A,t'_{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_A'$ noch frisch ist, wird geprüft, ob A auf den - Dienst S1 zugreifen darf, und die folgende Nachricht erstellt: 4. - $TGS\rightarrow A:{{K}{A,S1}, S1, t_{TGS}, Ticket_{S1}}_{{K}{A,TGS}}$ mit $Ticket_{S1}={K_{A,S1}, A, Addr_A, S1, t_{TGS}, LifetimeTicket_{S1}}_{{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\rightarrow - S1:(Ticket_{S1}, Authenticator_{A,S1})$ mit - $Authenticator_{A,S1}={A,Addr_A, t''_{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\rightarrow A:{t'\,'_{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_{A+1}''$ verschlüsselt mit $K_{A,S}$ zu antworten + \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\rightarrow A:{ K_{A,TGS}, TGS, t_{AS}, LifetimeTicket_{TGS}, Ticket_{TGS}}_{K_A}$ mit $Ticket_{TGS}={K_{A,TGS},A, Addr_A, TGS, t_{AS}, LifetimeTicket_{TGS}}_{{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\rightarrow TGS:(S1, Ticket_{TGS}, Authenticator_{A,TGS})$ mit Authenticator $A,TGS={A,Addr_A,t'_{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_A'$ noch frisch ist, wird geprüft, ob A auf den Dienst S1 zugreifen darf, und die folgende Nachricht erstellt: 4. $TGS\rightarrow A:{{K}{A,S1}, S1, t_{TGS}, Ticket_{S1}}_{{K}{A,TGS}}$ mit $Ticket_{S1}={K_{A,S1}, A, Addr_A, S1, t_{TGS}, LifetimeTicket_{S1}}_{{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\rightarrow S1:(Ticket_{S1}, Authenticator_{A,S1})$ mit $Authenticator_{A,S1}={A,Addr_A, t''_{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\rightarrow A:{t'\,'_{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_{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... @@ -2664,21 +2547,14 @@ \end{itemize*} \end{itemize*} - - \subsubsection{Kerberos für mehrere - Domänen} - + \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: + \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. + \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. @@ -2686,8 +2562,7 @@ \item Skalierbarkeitsproblem: n Realms benötigen $n\times(n-1)/2$ geheime Schlüssel! \end{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-multi-domain-kerberos.png} - \item Nachrichten, die während eines Protokolllaufs mit mehreren Domänen - ausgetauscht werden: + \item Nachrichten, die während eines Protokolllaufs mit mehreren Domänen ausgetauscht werden \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item $A\rightarrow AS1:(A,TGS1, t_A)$ @@ -2701,65 +2576,37 @@ \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 + \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: + \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 + \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\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\rightarrow A: (A,Ticket_{TGS},{K_{A,TGS}, LastRequest,n,t_{expire},t_{AS},t_{start},t_{end},t_{renew},TGS, Addr_A}_{K_A})$ mit $Ticket_{TGS}=(TGS, {K_{A,TGS},A,transited, t_{AS}, t_{start},t_{end},t_{renew},Addr_A,restrictions}_{{K}{AS,TGS}})$ + \item Die Antwort enthält ein Klartext-Ticket und verschlüsselte Informationen: 2. $AS\rightarrow A: (A,Ticket_{TGS},{K_{A,TGS}, LastRequest,n,t_{expire},t_{AS},t_{start},t_{end},t_{renew},TGS, Addr_A}_{K_A})$ mit $Ticket_{TGS}=(TGS, {K_{A,TGS},A,transited, t_{AS}, t_{start},t_{end},t_{renew},Addr_A,restrictions}_{{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\#,...}_{{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\rightarrow - A:(A,Ticket_{S1},{K_{A,S1},LastRequest, - n',t_{expire},t_{TGS},t_{start},t_{end},t_{renew},S1,Addr_A}_{{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\rightarrow S1:(Ticket_{S1}, - Authenticator_{A,S1})$ mit - $Authenticator_{A,S1}={A,CheckSum,t_{A''},K_{A,S1}', Seq\#, - ...}_{{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\rightarrow - A:{t_{S1},K_{A,S1}',Seq\#,...}_{{K}{A,S1}}$ - \item Alles in allem behebt der Dialog mehrere potenzielle Schwachstellen, - während andere bestehen bleiben: + \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\#,...}_{{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\rightarrow A:(A,Ticket_{S1},{K_{A,S1},LastRequest, n',t_{expire},t_{TGS},t_{start},t_{end},t_{renew},S1,Addr_A}_{{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\rightarrow S1:(Ticket_{S1}, Authenticator_{A,S1})$ mit $Authenticator_{A,S1}={A,CheckSum,t_{A''},K_{A,S1}', Seq\#, ...}_{{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\rightarrow A:{t_{S1},K_{A,S1}',Seq\#,...}_{{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 @@ -2768,10 +2615,7 @@ \end{itemize*} \end{itemize*} - - \subsection{Fortgeschrittene Methoden zur - Passwortauthentifizierung} - + \subsection{Fortgeschrittene Methoden zur Passwortauthentifizierung} \begin{itemize*} \item Alle gezeigten Protokolle haben eine gemeinsame Schwäche: \begin{itemize*} @@ -2783,114 +2627,95 @@ \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*} + \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 + \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*} + \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 + \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\rightarrow B:A,{+K_{ar}}_{{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 + \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\rightarrow A:{{K_r}_{{+K}{ar}}}_{{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 + \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\rightarrow B:{r_A}_{K_r}$ \item $B\rightarrow A:{r_A,r_B}_{K_r}$ \item $A\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 + \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 + \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*} + \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\rightarrow B:{g^{ra}\ mod\ p}_{{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}\ mod\ p$, um eine - verschlüsselte Nonce $c_b$ zu senden - 2. $B\rightarrow A:{g^{rb}\ mod\ p}_{{K}{A,B}}{c_b}_{K_s}$ - \item Beide Parteien beweisen ihre Kenntnis von $K_S$ - 3. $A\rightarrow B:{c_a|| c_b}_{K_s}$ - 4. $B\rightarrow A:{c_a}{K_s}$ + \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}\ mod\ p$, um eine verschlüsselte Nonce $c_b$ zu senden 2. $B\rightarrow A:{g^{rb}\ mod\ p}_{{K}{A,B}}{c_b}_{K_s}$ + \item Beide Parteien beweisen ihre Kenntnis von $K_S$ 3. $A\rightarrow B:{c_a|| c_b}_{K_s}$ 4. $B\rightarrow A:{c_a}{K_s}$ \end{itemize*} \subsubsection{Sicherheitsdiskussion 2} \begin{itemize*} - \item Wiederum müssen verschlüsselte Daten von Zufallsdaten ununterscheidbar - sein + \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 + \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 Das heute am weitesten verbreitete Protokoll: Sicheres Fernkennwort (SRP) \item Mehrere Versionen: Hier SRP-6a ,,Wu02'' \item Initialisierung: \begin{itemize*} @@ -2903,34 +2728,19 @@ \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\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\rightarrow A: p, g, s_{A,B}, (H(g - || p)*v + g^{rb})\ mod\ p$ - \item A berechnet den gemeinsamen Sitzungsschlüssel durch $K_S=(Y_B-H(g - || p)_{g^x)^{ra+u}x}\ mod\ p$, mit $u=H(Y_A|| Y_B)$, und - sendet seinen Teil des DH-Austauschs und eine Bestätigung zurück, dass - er $K_S$ kennt 3. $A\rightarrow - B:g^{ra}\ mod\ p, - H(Y_A,Y_B,K_S)$ - \item B berechnet $K_S'=(Y_A v^u)^{rb}\ mod\ p$ und beweist seine Kenntnis 4. - $B\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 + \item B antwortet mit ausgewählten kryptographischen Parametern und einem Verifizierer v, der durch einen DH-Austausch ,,geblendet'' ist 2. $B\rightarrow A: p, g, s_{A,B}, (H(g || p)*v + g^{rb})\ mod\ p$ + \item A berechnet den gemeinsamen Sitzungsschlüssel durch $K_S=(Y_B-H(g || p)_{g^x)^{ra+u}x}\ mod\ p$, mit $u=H(Y_A|| Y_B)$, und sendet seinen Teil des DH-Austauschs und eine Bestätigung zurück, dass er $K_S$ kennt 3. $A\rightarrow B:g^{ra}\ mod\ p, H(Y_A,Y_B,K_S)$ + \item B berechnet $K_S'=(Y_A v^u)^{rb}\ mod\ p$ und beweist seine Kenntnis 4. $B\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*} @@ -2942,19 +2752,15 @@ \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: + \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: + \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*} @@ -2971,57 +2777,58 @@ \end{itemize*} \end{itemize*} - \subsubsection{X.509 - Zertifikate mit öffentlichem Schlüssel} % \includegraphics[width=\linewidth]{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 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 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}$: + \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*} + \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)}_{{-CK}{CA}})$ \item Eine andere Kurzschreibweise für $Cert_{-CK_{CA}}(+K_A)$ ist $CA<>$ \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: + \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<>$ 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: + \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*} + \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<>$ und CB den öffentlichen Schlüssel von CA mit einem Zertifikat $CB<>$ beglaubigt, können A und B ihre Zertifikate anhand einer Zertifikatskette überprüfen: - \begin{itemize*} \item Nachdem ihr $CB<>$ vorgelegt wurde, versucht Alice herauszufinden, ob es ein Zertifikat $CA<>$ gibt. \item Sie überprüft dann die Kette: $CA<>, CB<>$ \end{itemize*} + \begin{itemize*} + \item Nachdem ihr $CB<>$ vorgelegt wurde, versucht Alice herauszufinden, ob es ein Zertifikat $CA<>$ gibt. + \item Sie überprüft dann die Kette: $CA<>, CB<>$ + \end{itemize*} \end{itemize*} - \item Zertifikatsketten müssen nicht auf eine Länge von zwei Zertifikaten - beschränkt sein: + \item Zertifikatsketten müssen nicht auf eine Länge von zwei Zertifikaten beschränkt sein \begin{itemize*} \item $CA<>, CC<>, CD<>, CE<>, CG<$ 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<>$ 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: + \item X.509 schlägt daher vor, dass die Zertifizierungsstellen in einer Zertifizierungshierarchie angeordnet werden, so dass die Navigation einfach ist: % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-x509-hierarchy.png} \item Verbleibendes Problem: \begin{itemize*} @@ -3031,19 +2838,22 @@ \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*} + \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*} + \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: + \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. @@ -3062,17 +2872,13 @@ \end{itemize*} \end{itemize*} - - \subsubsection{X.509 - - Authentifizierungsprotokolle} - + \subsubsection{X.509 - Authentifizierungsprotokolle} \begin{itemize*} - \item Einweg-Authentifizierung: + \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}}_{+KB}'', CA<>)$, 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<>$ ebenfalls optional ist \end{enumerate*} \begin{itemize*} @@ -3083,7 +2889,6 @@ \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<>)$ 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*} @@ -3092,7 +2897,6 @@ \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*} @@ -3103,70 +2907,68 @@ \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*} + \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} - + \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: + \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*} + \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*} + \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: + \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*} + \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*} + \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*} + \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{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 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[width=\linewidth]{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: + \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. @@ -3174,55 +2976,40 @@ \end{itemize*} \end{itemize*} - - \subsection{Klassische Computersubjekte, Objekte und - Zugriffsarten} - + \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: + \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: + \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: + \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 + \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 < vertraulich < geheim < streng geheim \item Kommerziell: öffentlich < sensibel < proprietär < eingeschränkt \end{itemize*} + \begin{itemize*} + \item Militär: unklassifiziert < vertraulich < geheim < streng geheim + \item Kommerziell: öffentlich < sensibel < proprietär < 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. + \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. + \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 \times Powerset(Categories)$ \end{itemize*} @@ -3231,19 +3018,19 @@ \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: + \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\times S$ \item Beispiel: - \begin{itemize*} \item Dominiert: $Labels \times Labels$ \item Dominiert $={(b1,b2) | b1, b2 \in Labels \wedge level(b1) \geq level(b2) \wedge categories(b2) \subseteq categories(b1)}$ \item Wenn $(b1, b2) \in Dominates$, schreiben wir auch b1 dominates b \end{itemize*} + \begin{itemize*} + \item Dominiert: $Labels \times Labels$ + \item Dominiert $={(b1,b2) | b1, b2 \in Labels \wedge level(b1) \geq level(b2) \wedge categories(b2) \subseteq categories(b1)}$ + \item Wenn $(b1, b2) \in Dominates$, schreiben wir auch b1 dominates b + \end{itemize*} \end{itemize*} \end{itemize*} - - \subsection{Spezifikation der - Sicherheitspolitik} - + \subsection{Spezifikation der Sicherheitspolitik} \begin{itemize*} \item Formale Ausdrücke für Regeln der Sicherheitspolitik: \item Betrachten Sie die folgenden Zuordnungen: @@ -3263,13 +3050,9 @@ \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} - + \subsection{Arten von Zugriffskontrollmechanismen} \begin{itemize*} - \item Ein Zugriffskontrollmechanismus ist eine konkrete Umsetzung des - Referenzmonitor-Konzepts + \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 @@ -3278,23 +3061,16 @@ \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 + \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 ($\rightarrow$ Firewalls) - \end{itemize*} + \item Verwendung einer diskretionären Zugangskontrolle auf Personalcomputern kombiniert mit einer obligatorischen Zugangskontrolle für die Kommunikation ($\rightarrow$ Firewalls) \end{itemize*} \end{itemize*} - \subsection{Zugriffsmatrizen} - \begin{itemize*} - \item Ein nützliches Konzept für die Beschreibung von - Zugangskontrollmechanismen ist die Zugangsmatrix: + \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 @@ -3313,60 +3089,40 @@ % \bottomrule %\end{longtable} - - \subsection{Gemeinsame - Zugriffskontrollschemata} - + \subsection{Gemeinsame Zugriffskontrollschemata} \begin{itemize*} - \item Zugriffskontroll-Listen (ACL): + \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: + \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: + \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 $\rightarrow$ Die Datenintegrität von - Zugriffskontrolldatenstrukturen ist entscheidend! + \item $\rightarrow$ Die Datenintegrität von Zugriffskontrolldatenstrukturen ist entscheidend! \end{itemize*} - - \section{Integration von Sicherheitsdiensten in - Kommunikationsarchitekturen} - - - \subsection{Motivation: Was ist wo zu - tun?} - + \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? + \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? % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Security-service-dim-1.png} - \item Dimension 2: Welcher Sicherheitsdienst sollte in welcher Schicht - realisiert werden? + \item Dimension 2: Welcher Sicherheitsdienst sollte in welcher Schicht realisiert werden? % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Security-service-dim-2.png} \end{itemize*} - - \subsection{Ein pragmatisches Modell für sicheres und vernetztes - Rechnen} - + \subsection{Ein pragmatisches Modell für sicheres und vernetztes Rechnen} \begin{itemize*} %\item \includegraphics[width=\linewidth]{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 Anwendung: Ein Stück Software, das eine bestimmte Aufgabe erfüllt, z. B. elektronische E-Mail, Webdienst, Textverarbeitung, Datenspeicherung usw. \item Endsystem: \begin{itemize*} \item Ein Gerät, das vom Personal Computer über den Server bis zum Großrechner reicht. @@ -3382,28 +3138,18 @@ \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: + \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*} + \item Anwendungsebene: Sicherheitsprotokollelemente, die anwendungsabhängig sind + \item Endsystem-Ebene: Bereitstellung von Schutz auf einer Endsystem-zu-Endsystem-Basis + \item Teilnetzebene: Bereitstellung von Schutz über ein Teilnetz oder ein Zwischennetz, das als weniger sicher gilt als andere Teile der Netzumgebung + \item Verbindungsebene: 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*} - - \subsection{Beziehungen zwischen Schichten und - Anforderungsniveaus} - + \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: + \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. @@ -3411,10 +3157,7 @@ \end{itemize*} \end{itemize*} - - \subsection{Allgemeine Überlegungen zur architektonischen - Platzierung} - + \subsection{Allgemeine Überlegungen zur architektonischen Platzierung} \begin{itemize*} \item Verkehrsvermischung: \begin{itemize*} @@ -3446,26 +3189,32 @@ \end{itemize*} \end{itemize*} - - \subsection{Überlegungen zu bestimmten - Ebenen} - + \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*} + \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*} + \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*} + \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*} @@ -3477,51 +3226,55 @@ \end{itemize*} \end{itemize*} - - \subsection{Interaktionen zwischen menschlichen - Nutzern} - + \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: + \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*} + \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*} + \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*} + \begin{itemize*} + \item Beispiel: Kerberos + \end{itemize*} \end{itemize*} \end{itemize*} - - \subsection{Integration in untere Protokollschichten vs. - Anwendungen} - + \subsection{Integration in untere Protokollschichten vs. Anwendungen} \begin{itemize*} - \item Vorteile der Integration von Sicherheitsdiensten in niedrigere - Netzwerkschichten: + \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*} + \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*} + \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*} + \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*} + \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} + \subsection{Integration in Endsysteme vs. Zwischensysteme} \begin{itemize*} \item Integration in Endsysteme: @@ -3532,15 +3285,15 @@ \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*} + \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 + \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} + \subsection{Beispiel: Authentifizierungsbeziehungen in Inter-Netzwerken} % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Authentication-relation-in-inter-networks.png} @@ -3558,31 +3311,21 @@ % \bottomrule %\end{longtable} - \subsection{Schlussfolgerung} - \begin{itemize*} - \item Die Integration von Sicherheitsdiensten in Kommunikationsarchitekturen - wird von zwei Hauptfragen geleitet: + \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: + \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 + \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 @@ -3592,13 +3335,9 @@ \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 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 @@ -3615,17 +3354,10 @@ \end{itemize*} \end{itemize*} - \subsection{IEEE 802.1} - - - \subsubsection{Die IEEE 802.1 Standardfamilie: Hintergrund und - Ziele} - + \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 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), @@ -3639,11 +3371,8 @@ \end{itemize*} \end{itemize*} - \subsubsection{IEEE 802.1Q} - Ziele und Dienste - \begin{itemize*} \item Der Standard IEEE 802.1Q: \begin{itemize*} @@ -3654,14 +3383,9 @@ \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 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! @@ -3670,13 +3394,10 @@ \end{itemize*} Typisches Einführungsszenario - \begin{itemize*} - \item Normalerweise wird das vertrauenswürdige innere Netzwerk durch - physische Mittel geschützt + \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 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 @@ -3686,10 +3407,8 @@ \end{itemize*} Weitere Diskussion - \begin{itemize*} - \item 802.1Q ermöglicht eine einfache Trennung verschiedener - Sicherheitsdomänen innerhalb eines vertrauenswürdigen Netzwerks + \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 @@ -3705,11 +3424,8 @@ \end{itemize*} \end{itemize*} - \subsubsection{IEEE 802.1X} - Ziele - \begin{itemize*} \item Der Standard IEEE 802.1X: \begin{itemize*} @@ -3722,7 +3438,6 @@ \end{itemize*} Kontrollierte und unkontrollierte Ports - \begin{itemize*} \item IEEE 802.1X führt den Begriff der zwei logischen Ports ein: \begin{itemize*} @@ -3733,7 +3448,6 @@ \end{itemize*} Rollen - \begin{itemize*} \item Es werden drei Hauptrollen unterschieden: \begin{itemize*} @@ -3744,24 +3458,24 @@ \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*} + \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: + \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: + \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, ... @@ -3769,17 +3483,11 @@ \end{itemize*} \end{itemize*} - Beispiel für eine - 802.1X-Authentifizierung''(Assets/NetworkSecurity-ieee802.1X-example.png) - - + 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: + \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 @@ -3791,7 +3499,6 @@ \end{itemize*} Frame-Format - \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ieee802.1AE-frame.png} \item Quell- und Zieladressen werden im Klartext gesendet @@ -3801,16 +3508,12 @@ \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 + \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 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... @@ -3819,11 +3522,8 @@ \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*} @@ -3845,25 +3545,17 @@ \end{itemize*} Packet Format - \begin{itemize*} - \item Zeichenorientierte (statt bitorientierte) - $\Rightarrow$ byteausgerichtete Rahmen + \item Zeichenorientierte (statt bitorientierte) $\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 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[width=\linewidth]{Assets/NetworkSecurity-Punkt-zu-Punkt-Format.png} \end{itemize*} Eine typische PPP-Verbindung - \begin{itemize*} \item Nutzungsszenario ,,Internetzugang eines PCs über Modem'': \begin{itemize*} @@ -3871,7 +3563,9 @@ \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*} + \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 @@ -3879,7 +3573,6 @@ \end{itemize*} Link Control Protocol - \begin{itemize*} \item Rahmenformat des Link Control Protocol (LCP): \begin{itemize*} @@ -3896,7 +3589,6 @@ \end{itemize*} Sicherheitsdienste - \begin{itemize*} \item Die ursprüngliche Version von PPP ,,RFC 1661'' schlägt die optionale Ausführung eines Authentifizierungsprotokolls nach der @@ -3904,34 +3596,54 @@ \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*} + \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*} + \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*} + \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''. + \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 \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 \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*} + \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 \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 \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*} @@ -3943,7 +3655,10 @@ \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[width=\linewidth]{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*} + \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[width=\linewidth]{Assets/NetworkSecurity-Point-to-Point-CHAP2.png} \end{itemize*} \item Erweiterbares Authentifizierungsprotokoll (EAP): @@ -3951,24 +3666,46 @@ \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*} + \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*} + \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*} + \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\rightarrow B: N - 1$ \item $B\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*} + \begin{itemize*} + \item $A\rightarrow B: N - 1$ + \item $B\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*} + \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*} @@ -3979,21 +3716,35 @@ \end{itemize*} Verschlüsselungsprotokolle - \begin{itemize*} - \item Nach dem Verbindungsaufbau und der Authentifizierungsphase kann die - Verschlüsselung für eine PPP-Verbindung ausgehandelt werden: + \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*} + \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[width=\linewidth]{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*} + \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*} @@ -4002,7 +3753,10 @@ \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*} + \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[width=\linewidth]{Assets/NetworkSecurity-Point-to-Point-DESE2.png} \end{itemize*} \item PPP 3DES Encryption Protocol (3DESE): @@ -4020,20 +3774,13 @@ \end{itemize*} \end{itemize*} - - \subsubsection{Punkt-zu-Punkt-Tunneling-Protokoll - (PPTP)} - + \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 + \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 + \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: @@ -4050,50 +3797,45 @@ % \bottomrule %\end{longtable} - - \subsubsection{PPTP: Freiwilliges vs. obligatorisches - Tunneling} - + \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: + \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*} + \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*} + \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[width=\linewidth]{Assets/NetworkSecurity-PPTP-Tunneling-Protocol.png} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-PPTP-Tunneling-Protocol2.png} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-PPTP-Packet-Construction-at-Client.png} %\end{itemize*} - - \subsubsection{PPTP / PPP Proprietäre Erweiterungen und einige - ,,Geschichte''} - + \subsubsection{PPTP / PPP Proprietäre Erweiterungen und einige ,,Geschichte''} \begin{itemize*} - \item PPTP hat sich vor allem aufgrund der Unterstützung durch Microsoft - durchgesetzt: + \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: + \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'': + \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 @@ -4101,10 +3843,7 @@ \end{itemize*} \end{itemize*} - - \subsubsection{Vergleich von PPTP und - L2TP} - + \subsubsection{Vergleich von PPTP und L2TP} \begin{itemize*} \item Beide Protokolle: \begin{itemize*} @@ -4117,8 +3856,7 @@ \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 + \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*} @@ -4126,17 +3864,12 @@ \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. + \item L2TP ermöglicht eine Tunnelauthentifizierung, während PPTP dies nicht tut. \end{itemize*} - - \subsection{Virtuelle private - Netzwerke} - + \subsection{Virtuelle private Netzwerke} \begin{itemize*} - \item Verschiedene Definitionen des Begriffs virtuelles privates Netzwerk - (VPN): + \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 @@ -4153,7 +3886,6 @@ \end{quote} Techniken zum Aufbau virtueller privater Netze - \begin{itemize*} \item Nutzung dedizierter Verbindungen (Cut-Through-Mechanismen): \begin{itemize*} @@ -4175,20 +3907,18 @@ \end{itemize*} \end{itemize*} - - \section{Die IPsec-Architektur für das - Internet-Protokoll} - - + \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*} + \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) @@ -4201,16 +3931,11 @@ \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 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 @@ -4219,9 +3944,7 @@ %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-tcp-ip-suite.png} \end{itemize*} - \subsection{Das IPv4-Paketformat} - \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipv4-packet-format.png} \item Version (Ver.): 4 bit @@ -4288,32 +4011,38 @@ \end{itemize*} \end{itemize*} - - \subsection{Sicherheitsprobleme des - Internet-Protokolls} - + \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*} + \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*} + \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} - + \subsection{Sicherheitsziele von IPsec} \begin{itemize*} - \item IPsec zielt darauf ab, die folgenden Sicherheitsziele zu - gewährleisten: + \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*} + \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*} + \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*} @@ -4322,16 +4051,10 @@ \end{itemize*} \end{itemize*} - - \subsection{Überblick über die - IPsec-Standardisierung} - + \subsection{Überblick über die IPsec-Standardisierung} % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IPsec-standardization.png} - - \subsection{Überblick über die - IPsec-Architektur} - + \subsection{Überblick über die IPsec-Architektur} \begin{itemize*} \item RFC 4301 definiert die grundlegende Architektur von IPsec: \begin{itemize*} @@ -4429,10 +4152,7 @@ \end{itemize*} \end{itemize*} - - \subsection{IPsec-Wiedergabeschutz (Replay - protection)} - + \subsection{IPsec-Wiedergabeschutz (Replay protection)} \begin{itemize*} \item Sowohl AH- als auch ESP-geschützte IP-Pakete tragen eine Sequenznummer, die einen Wiedergabeschutz realisiert: @@ -4443,7 +4163,8 @@ \item Der Empfänger eines IP-Pakets prüft, ob die Sequenznummer in einem Fenster zulässiger Nummern enthalten ist % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-replay-protection.png} \begin{itemize*} - \item (Paket mit Sequenznummer N kann noch akzeptiert werden) \end{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*} @@ -4452,18 +4173,14 @@ \item liegt rechts vom aktuellen Fenster $\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) + \item Die minimale Fenstergröße beträgt 32 Pakete (64 Pakete werden empfohlen) \begin{itemize*} % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-replay-protection2.png} \item Paket mit Sequenznummer N kann nicht mehr akzeptiert werden \end{itemize*} \end{itemize*} - - \subsection{IPsec-Implementierungsalternativen: - Host-Implementierung} - + \subsection{IPsec-Implementierungsalternativen: Host-Implementierung} \begin{itemize*} \item Vorteile der IPsec-Implementierung in Endsystemen: \begin{itemize*} @@ -4471,75 +4188,59 @@ \item Bereitstellung von Sicherheitsdiensten auf einer Per-Flow-Basis \item Fähigkeit, alle IPsec-Modi zu implementieren \end{itemize*} - \item Zwei Hauptalternativen zur Integration: | Integriertes - Betriebssystem | ,,Bump'' im Stack | | - -------------------------------------------------------------------------------------------------------------- - | - --------------------------------------------------------------------------------------------------------- - | | Anwendung | Anwendung | - | Transport | Transport | | - Netzwerk + IPsec | Netzwerk | | IPsec - | | Data Link | Data Link | - | | | Echte Betriebssystemintegration ist - die Methode der Wahl, da sie die Duplizierung von Funktionalität - vermeidet | Wenn das Betriebssystem nicht geändert werden - kann, wird IPsec über den Datenverbindungstreiber eingefügt | + \item Zwei Hauptalternativen zur Integration: \end{itemize*} + \begin{tabular}{c|c} + Integriertes Betriebssystem & ,,Bump'' im Stack \\\hline + Anwendung & Anwendung \\ + Transport & Transport \\ + Netzwerk + IPsec & Netzwerk \\ + IPsec & \\ + Data Link & Data Link \\ + Echte Betriebssystemintegration ist die Methode der Wahl, da sie die Duplizierung von Funktionalität + vermeidet & Wenn das Betriebssystem nicht geändert werden kann, wird IPsec über den Datenverbindungstreiber eingefügt + \end{tabular} - - \subsection{IPsec-Implementierungsalternativen: - Router-Implementierung} - + \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*} + \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: % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-router-implementation.png} \end{itemize*} - - \subsection{Wann sollte welcher IPsec-Modus verwendet - werden?} - + \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: + \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 + \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 % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-communication-endpoints.png} \end{itemize*} - \item Der Tunnelmodus wird verwendet, wenn mindestens ein - ,,kryptographischer Endpunkt'' nicht ein ,,Kommunikationsendpunkt'' - der gesicherten IP-Pakete ist + \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[width=\linewidth]{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: + \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[width=\linewidth]{Assets/NetworkSecurity-communication-tunnelung-2.png} \end{itemize*} \end{itemize*} - - \subsection{Verschachtelung von - Sicherheitsassoziationen} - + \subsection{Verschachtelung von Sicherheitsassoziationen} \begin{itemize*} \item Sicherheitsassoziationen können verschachtelt werden: \begin{itemize*} @@ -4556,24 +4257,21 @@ \end{itemize*} \end{itemize*} - - \subsection{Grundschema der IPsec-Verarbeitung: Ausgehende - Pakete} - + \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: + \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: + \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 $\Rightarrow$ done \item Wenn das Paket nicht gesichert werden muss, dann sende es $\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 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*} @@ -4584,7 +4282,6 @@ \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) @@ -4605,12 +4302,8 @@ \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: - + 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*} @@ -4632,7 +4325,6 @@ \end{itemize*} \end{itemize*} - \subsection{IPsec Security Policy Definition} \begin{itemize*} \item Policy Selectors werden verwendet, um spezifische Policy-Definitionen auszuwählen, spezifiziert: @@ -4736,7 +4428,6 @@ \end{itemize*} \end{itemize*} - \subsection{Der Authentifizierungs-Header} \begin{itemize*} \item AH ist ein allgemeines Sicherheitsprotokoll, das IP-Paketen Schutz bietet: @@ -4794,65 +4485,70 @@ \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*} + \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*} + \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} - + \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: + \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: + \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*} + \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*} + \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: + \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*} + \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: + \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} - + \subsubsection{ISAKMP - Grundlegendes Nachrichtenformat} \begin{itemize*} \item % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-format.png} \item Initiator \& Responder Cookie: @@ -4860,8 +4556,7 @@ \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 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*} @@ -4874,14 +4569,8 @@ \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 Nachrichten-ID: Dient zur Identifizierung von Nachrichten, die zu verschiedenen Austauschen gehören + \item Nachrichtenlänge: Gesamtlänge der Nachricht (Header + Payload) \item Nutzlast: \begin{itemize*} \item Die Nutzlast einer ISAKMP-Nachricht kann tatsächlich mehrere ,,verkettete'' Nutzlasten enthalten @@ -4895,7 +4584,6 @@ \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: @@ -4912,1667 +4600,1607 @@ \end{itemize*} \end{itemize*} - \subsubsection{ISAKMP - Nutzdatenarten} - \begin{itemize*} - \item RFC 2408 definiert verschiedene Nutzdaten von ISAKMP (Liste ist nicht - vollständig): + \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*} + \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[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-payload-types.png} \end{itemize*} + \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[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-payload-types.png} \end{itemize*} \end{itemize*} + \end{itemize*} + + \subsubsection{ISAKMP - Die Sicherheits-Assoziations-Nutzdaten} + \begin{itemize*} + %\item \includegraphics[width=\linewidth]{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 - Sicherheits-Assoziations-Nutzdaten} + \subsubsection{ISAKMP - Die Vorschlagsnutzdaten} + \begin{itemize*} + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-proposal-payload.png} + \item Proposal \# wird verwendet, um Richtlinien auszudrücken und Vorschläge auszuhandeln: \begin{itemize*} - %\item \includegraphics[width=\linewidth]{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 + \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[width=\linewidth]{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. + \item Die Transformations-IDs werden in einem DOI-Dokument angegeben + \item Die SA-Attribute geben die Attribute an, die für die im Feld Transform ID angegebene Transformation definiert sind. + \end{itemize*} - \subsubsection{ISAKMP - Die - Vorschlagsnutzdaten} + \subsubsection{ISAKMP - SA-Verhandlung} + \begin{itemize*} + \item Inhalt des Next Payload-Feldes von SA-, Proposal- und Transform-Payloads: \begin{itemize*} - %\item \includegraphics[width=\linewidth]{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[width=\linewidth]{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. + \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*} - - \subsubsection{ISAKMP - SA-Verhandlung} + \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 Inhalt des Next Payload-Feldes von SA-, Proposal- und - Transform-Payloads: + \item Das erste Protokoll wird mit zwei von der vorschlagenden Stelle unterstützten Transformationen dargestellt, ESP mit: \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 + \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 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: + \item Das zweite Protokoll ist AH und wird mit einer einzigen Transformation angeboten: \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! + \item Umwandlung 1 als SHA \end{itemize*} - \item Dieses zweite Beispiel zeigt einen Vorschlag für zwei verschiedene - Schutzsuiten: + \item Die resultierende Schutzsuite ist entweder \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. + \item 3DES und SHA, oder + \item AES und SHA, je nachdem, welche ESP-Transformation vom Responder gewählt wurde \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. + \item In diesem Fall folgen auf die SA-Nutzdaten die folgenden Nutzdaten: \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. + \item ,,Vorschlag 1, ESP, (Transform 1, 3DES, ...), (Transform 2, AES)'' ,,Vorschlag 1, AH, (Transform 1, SHA)'' \end{itemize*} - \item Der Initiator muss überprüfen, ob die vom Responder empfangene - SA-Nutzlast mit einem der ursprünglich gesendeten Vorschläge - übereinstimmt + \item Bitte beachten Sie, dass dies zu zwei SAs pro Richtung führt! \end{itemize*} - - \subsubsection{ISAKMP - Session Key - Establishment} + \item Dieses zweite Beispiel zeigt einen Vorschlag für zwei verschiedene + Schutzsuiten: \begin{itemize*} - \item ISAKMP baut 4 verschiedene Schlüssel mit einem - Authentifizierungsaustausch auf: + \item Die erste Schutzsuite wird vorgestellt mit: \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. + \item einer Transformation (MD5) für das erste Protokoll (AH), und + \item eine Umwandlung (3DES) für das zweite Protokoll (ESP) \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: + \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 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*} + \item ,,Vorschlag 1, AH, (Transform 1, MD5, ...)'' ,,Vorschlag 1, ESP, (Transform 1, 3DES, ...)'' ,,Vorschlag 2, ESP, (Transform1, 3DES, ...), (Transform 2, AES, ...)'' \end{itemize*} - \item Hinweis: Auf den folgenden Folien steht HMAC(K, x | y - | ...) für H(K, p 1 , H(K, p 2 , x, y, ...)), wobei p 1 und p - 2 Auffüllmuster bezeichnen + \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{IKE - Berechnung von - IKE-Sitzungsschlüsseln} + \subsubsection{ISAKMP - Session Key Establishment} + \begin{itemize*} + \item ISAKMP baut 4 verschiedene Schlüssel mit einem Authentifizierungsaustausch auf: \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} | CKY-I | CKY-R | 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 | g^{xy} | CKY-I | CKY-R | 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 | g^{xy} | CKY-I | CKY-R | 2)$ - \end{itemize*} - \end{itemize*} - \item Falls erforderlich, werden die Schlüssel nach der folgenden Methode - erweitert: - \begin{itemize*} - \item $K=(K_1 | K_2 | ...)$ mit $K_i = HMAC(SKEYID, K_{i-1})$ und $K_0 = 0$ - \end{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. + \item Die Berechnung von SKEYID ist abhängig von der Authentifizierungsmethode + \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*} - \subsubsection{IKE - - Authentifizierungsmethoden} + \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 IKE-Austausche werden mit Hilfe von zwei Hash-Werten Hash-I - und Hash-R authentifiziert, die vom Initiator und vom Responder - erstellt werden: + \item Phase-1-Austausch für die Einrichtung einer IKE SA : \begin{itemize*} - \item Hash-I = HMAC(SKEYID, gx | gy | CKY-I | CKY-R | SA-Angebot | ID-I) - \item Hash-R = HMAC(SKEYID, gy | gx | CKY-R | CKY-I | SA-offer | 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 + \item Main-Mode-Austausch, der durch 6 ausgetauschte Nachrichten realisiert wird + \item Aggressive mode exchange, der nur 3 Nachrichten benötigt \end{itemize*} - \item IKE unterstützt vier verschiedene Methoden der Authentifizierung: + \item Phase 2 Austausch für die Einrichtung von IPsec SAs: \begin{itemize*} - \item Pre-shared Key: - \begin{itemize*} - \item SKYEID = $HMAC(K_{Initiator}, Responder , r_{Initiator} | 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 | CKY-R)$ - \end{itemize*} - \item Digitale Unterschrift: - \begin{itemize*} - \item $SKEYID = HMAC((r_{Initiator} | 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*} + \item Quick-Mode-Austausch, der mit 3 Nachrichten realisiert wird \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: + \item Andere Austausche: \begin{itemize*} - % \item \includegraphics[width=\linewidth]{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 + \item Informationsaustausch zur Übermittlung von Status- und Fehlermeldungen + \item Neuer Gruppenaustausch zur Vereinbarung von privaten Diffie-Hellman-Gruppen \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*} + \item Hinweis: Auf den folgenden Folien steht HMAC(K, x | y | ...) 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 - Hauptmodus Austausch mit Signaturen} + \subsubsection{IKE - Berechnung von IKE-Sitzungsschlüsseln} + \begin{itemize*} + \item IKE baut vier verschiedene Schlüssel mit einem Authentifizierungsaustausch auf: \begin{itemize*} - \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKE-exchange-payload-signature.png} + \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 $(m)$ gibt an, dass m optional ist - \item $I,,m''$ bedeutet, dass I m signiert + \item Die Berechnung von SKEYID ist abhängig von der Authentifizierungsmethode \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[width=\linewidth]{Assets/NetworkSecurity-IKE-exchange-public-key.png} + \item SKEYID\_d ist das Keying-Material, das zur Ableitung von Schlüsseln für Nicht-IKE-SAs verwendet wird \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*} + \item $SKEYID_d = HMAC(SKEYID, g^{xy} | CKY-I | CKY-R | 0)$, wobei $g^{xy}$ das gemeinsame Diffie-Hellman-Geheimnis bezeichnet \end{itemize*} - %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKE-exchange-public-key-2.png} + \item SKEYID\_a ist das Schlüsselmaterial, das von der IKE SA zur Authentifizierung ihrer Nachrichten verwendet wird \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... + \item SKEYID\_a = $HMAC(SKEYID, SKEYID_d | g^{xy} | CKY-I | CKY-R | 1)$ \end{itemize*} - \end{itemize*} - - \subsubsection{IKE - Aggressiver Modus Austausch mit Pre-Shared Key} - \begin{itemize*} - %\item \includegraphics[width=\linewidth]{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: + \item SKEYID\_e ist das Schlüsselmaterial, das von der IKE SA zum Schutz der Vertraulichkeit ihrer Nachrichten verwendet wird \begin{itemize*} - \item Digitale Signatur - \item Verschlüsselung mit öffentlichem Schlüssel + \item SKEYID\_e = $HMAC(SKEYID, SKEYID_a | g^{xy} | CKY-I | CKY-R | 2)$ \end{itemize*} \end{itemize*} - - \subsubsection{IKE - Quick Mode - Exchange} + \item Falls erforderlich, werden die Schlüssel nach der folgenden Methode erweitert: \begin{itemize*} - %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKE-quick-mode.png} - \item $Hash1 = HMAC(SKEYID_a, M-ID | SA | Ni | ,, | KE '' ,, | ID_{ci} | ID_{cr}'' )$ - \item $Hash2 = HMAC(SKEYID_a, M-ID | N_i | SA | N_r | ,, | KE '' ,, | ID_{ci} | ID_{cr}'' )$ - \item $Hash3 = HMAC(SKEYID_a, 0 | M-ID | N_i | 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} | '' protocol | SPI | N_i | - N_r)$ + \item $K=(K_1 | K_2 | ...)$ mit $K_i = HMAC(SKEYID, K_{i-1})$ und $K_0 = 0$ \end{itemize*} + \end{itemize*} - \subsection{Weitere Probleme mit IPsec} + \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 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*} + \item Hash-I = HMAC(SKEYID, gx | gy | CKY-I | CKY-R | SA-Angebot | ID-I) + \item Hash-R = HMAC(SKEYID, gy | gx | CKY-R | CKY-I | SA-offer | 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*} - - \subsection{Schlussfolgerung} + \item IKE unterstützt vier verschiedene Methoden der Authentifizierung: \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: + \item Pre-shared Key: \begin{itemize*} - \item Implementierung im Endsystem: Integriertes Betriebssystem oder ,,bump in the stack'' - \item Gateway-Implementierung: Integrierter Router oder ,,bump in the wire'' + \item SKYEID = $HMAC(K_{Initiator}, Responder , r_{Initiator} | r_{Responder})$ \end{itemize*} - \item Es wurden zwei grundlegende Sicherheitsprotokolle definiert: + \item Zwei verschiedene Formen der Authentifizierung mit Public-Key-Verschlüsselung: \begin{itemize*} - \item Authentifizierungs-Header (AH) - \item Encapsulating security payload (ESP) + \item $SKEYID = HMAC(H(r_{Initiator}, r_{Responder}), CKY-I | CKY-R)$ \end{itemize*} - \item SA-Verhandlung und Schlüsselverwaltung werden mit folgenden - Protokollen realisiert: + \item Digitale Unterschrift: \begin{itemize*} - \item Internet security association key management protocol (ISAKMP) - \item Internet-Schlüsselaustausch (IKE) + \item $SKEYID = HMAC((r_{Initiator} | 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*} - \subsection{Neue Wege in der - IPsec-Entwicklung} + \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 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 + % \item \includegraphics[width=\linewidth]{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*} - \subsection{Internet Key Exchange Protocol Version 2 - ,,RFC5996''} - Zusätzliche Designziele zu IKEv1 + \subsubsection{IKE - Hauptmodus Austausch mit Signaturen} + \begin{itemize*} + \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKE-exchange-payload-signature.png} \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 + \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{IKEv2 - - Schlüsselaustauschverfahren} + \subsubsection{IKE - Main Mode Exchange mit Public Key Encryption} + \begin{itemize*} + \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKE-exchange-public-key.png} \begin{itemize*} - \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKEv2-exchange-procedure.png} - \begin{itemize*} - \item $K$ Schlüssel abgeleitet durch $PRF(PRF(N_i || N_r, g^{ir}), N_i || N_r || SPI_i || 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 + \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*} - \subsubsection{IKEv2 - Eigenschaften des Schlüsselaustauschverfahrens} + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKE-exchange-public-key-2.png} \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*} + \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{IKEv2 - Zusätzliche Funktionen} + \subsubsection{IKE - Aggressiver Modus Austausch mit Pre-Shared Key} + \begin{itemize*} + %\item \includegraphics[width=\linewidth]{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 Zusätzlicher DoS-Schutz + \item Digitale Signatur + \item Verschlüsselung mit öffentlichem Schlüssel + \end{itemize*} + \end{itemize*} + + \subsubsection{IKE - Quick Mode Exchange} + \begin{itemize*} + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKE-quick-mode.png} + \item $Hash1 = HMAC(SKEYID_a, M-ID | SA | Ni | ,, | KE '' ,, | ID_{ci} | ID_{cr}'' )$ + \item $Hash2 = HMAC(SKEYID_a, M-ID | N_i | SA | N_r | ,, | KE '' ,, | ID_{ci} | ID_{cr}'' )$ + \item $Hash3 = HMAC(SKEYID_a, 0 | M-ID | N_i | 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} | '' protocol | SPI | N_i | + 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 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 + \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*} - \item Dead Peer Detection + \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 Regelmäßige IKE-Anfragen, um festzustellen, ob die SA gelöscht werden kann + \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 Flexiblere Verhandlungstechniken + \item Interoperabilität mit Network Address Translation (NAT): \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*} + \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{Netzwerk-Adressübersetzung (NAT)} + \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 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*} + \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*} - \subsubsection{NAT - Ein Beispiel} + \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 \includegraphics[width=\linewidth]{Assets/NetworkSecurity-NAT-example.png} - \item NAT ändert die Quelladresse eines jeden Pakets in eine öffentliche IP-Adresse mit anderen ("umgeschriebenen") Quellports + \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*} - \subsubsection{Probleme mit NAT und IPsec - NAT-Traversal} + \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 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 - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-NAT-encap-ESP.png} - \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*} + \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{Probleme mit NAT und IPsec - - BEET-Modus} + \subsubsection{IKEv2 - Schlüsselaustauschverfahren} + \begin{itemize*} + \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKEv2-exchange-procedure.png} \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[width=\linewidth]{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 + \item $K$ Schlüssel abgeleitet durch $PRF(PRF(N_i || N_r, g^{ir}), N_i || N_r || SPI_i || 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 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 | IP Header | UDP Header | ESP Header | IP Header | geschützte Daten | + \item Dient als DoS-Schutz, wenn anschließend rechenintensive Aufgaben durchgeführt werden \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 + \item Identität des Responders wird erst nach Verifizierung des Initiators offengelegt \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 + \item Schützt vor dem Scannen nach einer Partei mit einer bestimmten ID \end{itemize*} - \item Kann bis zu Tausende von Sicherheits-Gateways haben - \item Kann sich dynamisch ändern + \item Initiator weiß nicht, wann es sicher ist, Daten zu senden \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) + \item (Pakete können in falscher Reihenfolge empfangen werden) \end{itemize*} - \item Muss natürlich sicher sein ... + \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*} - \subsection{Probleme bei der manuellen Konfiguration der - IPsec-Infrastruktur} + \subsubsection{IKEv2 - Zusätzliche Funktionen} + \begin{itemize*} + \item Zusätzlicher DoS-Schutz \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 $\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. $\Rightarrow$ Mögliche Sicherheitsprobleme \end{itemize*} - \end{itemize*} - \item Problem der Agilität + \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 Keine dynamische Anpassung der VPN-Topologie - \item Begrenzte Unterstützung mobiler Sicherheits-Gateways + \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{Automatische IPsec-Konfiguration - einige - Anforderungen} + \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 Funktionelle Anforderungen + \item Für Pakete, die von der privaten Seite kommen: \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) + \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 Nicht-funktionale Anforderungen + \item Für Pakete, die von der öffentlichen Seite kommen: \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. + \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[width=\linewidth]{Assets/NetworkSecurity-NAT-example.png} + \item NAT ändert die Quelladresse eines jeden Pakets in eine öffentliche IP-Adresse mit anderen ("umgeschriebenen") Quellports + \end{itemize*} - \subsection{Verschiedene Ansätze für die automatische - IPsec-Konfiguration} + \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 + % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-NAT-encap-ESP.png} + \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 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) + \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{IPsec-Richtlinienverteilung durch zentrale - Server} + \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 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*} + \item Bobs und Charlies Pakete haben beide die gleiche externe Adresse + \item Bobs und Daves Pakete haben beide dieselbe interne Adresse + % \item \includegraphics[width=\linewidth]{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 | IP Header | UDP Header | ESP Header | IP Header | geschützte Daten | \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*} - \subsubsection{Tunnel Endpoint Discovery - (TED)} + \subsection{Konfiguration großer IPsec-Infrastrukturen} + \begin{itemize*} + \item Kommunikationsinfrastrukturen von Unternehmen und Behörden: + \item Kann komplexe Overlay-Topologien bilden \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[width=\linewidth]{Assets/NetworkSecurity-TED.png} + \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 $\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. $\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[width=\linewidth]{Assets/NetworkSecurity-TED.png} + \end{itemize*} - \subsubsection{Gruppenverschlüsseltes Transport-VPN - (GET)} + \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 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 $\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[width=\linewidth]{Assets/NetworkSecurity-GET.png} + \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 $\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[width=\linewidth]{Assets/NetworkSecurity-GET.png} + \end{itemize*} - \subsubsection{Proaktives Multicast-basiertes - IPsec-Erkennungsprotokoll} + \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 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[width=\linewidth]{Assets/NetworkSecurity-proactive-multicast-discovery.png} + \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[width=\linewidth]{Assets/NetworkSecurity-proactive-multicast-discovery.png} + \end{itemize*} - \subsubsection{Soziales VPN} + \subsubsection{Soziales VPN} + \begin{itemize*} + \item Akademischer Ansatz ,,FBJW08'' + \item Verwendet Facebook als ,,policy'' Server zum Austausch von IKE Zertifikaten \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 + \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 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*} + \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)} + \subsubsection{Dynamisches Mehrpunkt-VPN (DMVPN)} + \begin{itemize*} + \item Ein weiterer Ansatz von Cisco ,,Bhai08'' + \item VPN ist aufgeteilt in \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[width=\linewidth]{Assets/NetworkSecurity-DMVPN.png} + \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[width=\linewidth]{Assets/NetworkSecurity-DMVPN.png} + \end{itemize*} - \paragraph{Dynamisches Mehrpunkt-VPN (DMVPN) - - Diskussion} + \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 Vorteile + \item Erfordert immer noch erheblichen Konfigurationsaufwand \begin{itemize*} - \item Ansatz ermöglicht dynamischere Topologien - \item Kann private Adressen verwenden + \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 Nachteilig + \item Spokes können nicht verschachtelt werden + \item Spokes können sich nicht zwischen ,,Hubs'' bewegen \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'' + \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)} + \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 Komplexer Ansatz, verspricht einfache Implementierung ,,RSS10'' - \item Sicherheitsgateways bilden ein strukturiertes Overlay-Netzwerk + \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 Verbindet Sicherheitsgateways so, dass das VPN effizient nach einer Zieladresse durchsucht werden kann + \item Proaktiver Aufbau einer VPN-Struktur zur schnellen Erkennung \end{itemize*} - \item Erfordert nur sehr wenige proaktiv erstellte IPsec-Verbindungen + \item Erkennung von Sicherheitsgateways \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 + \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 Drei Aufgaben zu erfüllen + \item Weiterleitung von Datenpaketen \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*} + \item Suche nach einem effizienten Weg zur Weiterleitung von Paketen durch das Overlay \end{itemize*} \end{itemize*} + \end{itemize*} - \paragraph{SOLID - - Topologie-Kontrolle} + \paragraph{SOLID - Topologie-Kontrolle} + \begin{itemize*} + \item Mechanismen zur Topologiekontrolle \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 $\Rightarrow$ - Verschachtelte Strukturen werden abgeflacht, um eine einfache - Erkennung zu ermöglichen - %\item \includegraphics[width=\linewidth]{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 $\Rightarrow$ Kürzere ,,Suchpfade'' erforderlich + \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 $\Rightarrow$ Verschachtelte Strukturen werden abgeflacht, um eine einfache Erkennung zu ermöglichen + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-SOLID-topology.png} + \end{itemize*} - \paragraph{SOLID - Mehr - Topologiekontrolle} + \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 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\ n)$ - \item Aufgrund der Konstruktionstechnik Entdeckung in - $O(log\ n)$ Overlay Hops - $\Rightarrow$ Ansatz skaliert gut mit Anzahl der - Netzwerke - %\item \includegraphics[width=\linewidth]{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\ 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*} + \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 $\Rightarrow$ Kürzere ,,Suchpfade'' erforderlich + \end{itemize*} - \paragraph{SOLID - Eigenschaften und - Ergebnisse} + \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 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 + \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\ n)$ + \item Aufgrund der Konstruktionstechnik Entdeckung in $O(log\ n)$ Overlay Hops $\Rightarrow$ Ansatz skaliert gut mit Anzahl der Netzwerke + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-SOLID-topology-control.png} + \end{itemize*} - \paragraph{SOLID - Simulative - Bewertung} + \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\ 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 SOLID kann in OMNeT++ evaluiert werden - \item Ermöglicht Tests von komplexen Szenarien + \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 - Sonstige - Forschung} + \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 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*} + \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*} - \section{Sicherheitsprotokolle der - Transportschicht} + \paragraph{SOLID - Simulative Bewertung} + \begin{itemize*} + \item SOLID kann in OMNeT++ evaluiert werden + \item Ermöglicht Tests von komplexen Szenarien + \end{itemize*} - \subsection{Anwendungsbereich von Sicherheitsprotokollen der - Transportschicht} + \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 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*} + \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{Das Secure Socket Layer (SSL) - Protokoll} + \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 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*} + \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{SSL-Sicherheitsdienste} + \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 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*} + \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-Sitzungs- und - Verbindungsstatus} + \subsection{SSL-Sicherheitsdienste} + \begin{itemize*} + \item Peer-Entity-Authentifizierung: \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*} + \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[width=\linewidth]{Assets/NetworkSecurity-ssl-protocol-architecture.png} + \subsection{Architektur des SSL-Protokolls} + % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ssl-protocol-architecture.png} + \begin{itemize*} + \item SSL ist als eine mehrschichtige und modulare Protokollarchitektur + aufgebaut: \begin{itemize*} - \item SSL ist als eine mehrschichtige und modulare Protokollarchitektur - aufgebaut: + \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 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 $< 2^{14}$ \item Komprimierung (optional) von Klartextsätzen \item Verschlüsselung und Integritätsschutz (beides optional) \end{itemize*} + \item Fragmentierung der Nutzdaten in Klartextsätze der Länge $< 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[width=\linewidth]{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 & --->{} & \tabularnewline + % & & ServerHello\tabularnewline + % & & ,,ServerCertificate''\tabularnewline + % & & ,,CertificateRequest''\tabularnewline + % & & ,,ServerKeyExchange''\tabularnewline + % & \textless--- & ServerHelloDone\tabularnewline + % ,,ClientCertificate'' & & \tabularnewline + % ClientKeyExchange & & \tabularnewline + % ,,CertificateVerify'' & & \tabularnewline + % ChangeCipherSpec & & \tabularnewline + % Finished & --->{} & \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) & --->{} & \tabularnewline + % & & ServerHello(SessionID)\tabularnewline + % & & ChangeCipherSpec\tabularnewline + % & \textless--- & Finished\tabularnewline + % ChangeCipherSpec & & \tabularnewline + % Finished & --->{} & \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-Record-Protokoll} - % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-SSL-record-protocol.png} + \subsection{SSL-Handshake-Protokoll: Kryptografische Aspekte} + \begin{itemize*} + \item SSL unterstützt drei Methoden zur Erstellung von Sitzungsschlüsseln: \begin{itemize*} - \item Inhaltstyp: + \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 | PS | 0x00 | 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 Ändern Cipherspec. (20) - \item Warnung (21) - \item Handshake (22) - \item Anwendungsdaten (23) + \item $C_i = C\times R_i^e\ mod\ 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\times R_i\ mod\ n$ ab, basierend auf der PKCS \#1 Verschlüsselungsmethode \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}$ + \item Aus den abgeleiteten Bits von $M\times R_i\ mod\ 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*} - - \subsection{Verarbeitung des - SSL-Datensatzprotokolls} + \item Gegenmassnahmen: \begin{itemize*} - \item Absendende Seite: + \item Regelmäßiger Wechsel der öffentlichen Schlüsselpaare ($\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 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) + \item Achtung: Es ist eine gewisse Vorsicht geboten, um Anfälligkeiten für eine andere Klasse von Angriffen zu vermeiden ,,Cop96a''. \end{itemize*} - \item Empfängerseite: + \item Änderung des Verschlüsselungsprotokolls für öffentliche Schlüssel, d.h. Überarbeitung von PKCS \#1: \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 + \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 Handshake Protokoll: - Einführung} + \subsection{SSL-Chiffre-Suiten} + \begin{itemize*} + \item Kein Schutz (Standard-Suite): \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*} + \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{SSL Handshake Protokoll: Vollständiger - Handshake} - %\begin{longtable}[]{@{}lll@{}} - % \toprule - % Client & & Server\tabularnewline - % \midrule - % \endhead - % ClientHello & --->{} & \tabularnewline - % & & ServerHello\tabularnewline - % & & ,,ServerCertificate''\tabularnewline - % & & ,,CertificateRequest''\tabularnewline - % & & ,,ServerKeyExchange''\tabularnewline - % & \textless--- & ServerHelloDone\tabularnewline - % ,,ClientCertificate'' & & \tabularnewline - % ClientKeyExchange & & \tabularnewline - % ,,CertificateVerify'' & & \tabularnewline - % ChangeCipherSpec & & \tabularnewline - % Finished & --->{} & \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) & --->{} & \tabularnewline - % & & ServerHello(SessionID)\tabularnewline - % & & ChangeCipherSpec\tabularnewline - % & \textless--- & Finished\tabularnewline - % ChangeCipherSpec & & \tabularnewline - % Finished & --->{} & \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: + \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 key\_block = MD5(master-secret + SHA('A' + master-secret + ClientHello.random + ServerHello.random)) + MD5(master-secret + SHA('BB' + master-secret + ClientHello.random + ServerHello.random)) + ,,...'' + \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 Anschließend wird das Material des Sitzungsschlüssels fortlaufend aus dem key\_block entnommen: + \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 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'' + \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 Authentifizierung von und mit dem Pre-Master-Secret: + \item Bei HTTPS führt dies zu mehreren Ausnutzungsmöglichkeiten, z. B, \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 + \item Angreifer injeziert: \texttt{GET\ /ebanking/transfer?what=LotsOfMoney\&to=eve\ HTTP/1.1\ {}\ X-Ignore:\ {}} + \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\ {}\ 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{SSL Handshake Protokoll: Eine - Sicherheitslücke} + \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 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 | PS | 0x00 | 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\times R_i^e\ mod\ 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\times R_i\ mod\ n$ ab, basierend auf der PKCS \#1 Verschlüsselungsmethode \end{itemize*} - \item Aus den abgeleiteten Bits von $M\times R_i\ mod\ 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: + \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 Regelmäßiger Wechsel der öffentlichen Schlüsselpaare ($\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*} + \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{SSL-Chiffre-Suiten} + \subsection{SSH Version 2} + \begin{itemize*} + \item SSH Version 2 ist in mehreren separaten Dokumenten spezifiziert, z.B.: \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*} + \item SSH Protocol Assigned Numbers ,,LL06'' + \item SSH-Protokollarchitektur ,,YL06a'' + \item SSH-Authentifizierungsprotokoll ,,YL06b'' + \item SSH-Transportschichtprotokoll ,,YL06c'' + \item SSH-Verbindungsprotokoll ,,YL06d'' \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) + \item SSH-Architektur: \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: + \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 SSL\_FORTEZZA\_DMS\_WITH\_NULL\_SHA = { 0x00,0x1C } - \item SSL\_FORTEZZA\_DMS\_WITH\_FORTEZZA\_CBC\_SHA = { 0x00,0x1D } + \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*} - (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) + \end{itemize*} - \subsection{Das Transport Layer - Security-Protokoll} + \subsection{SSH-Transportprotokoll} + \begin{itemize*} + \item SSH verwendet ein zuverlässiges Transportprotokoll (normalerweise TCP). + \item Es bietet die folgenden Dienste: \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. + \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 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): + \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 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! + \item HMAC mit MD5, SHA-1, SHA-256 oder SHA-512 + \item keine (nicht empfohlen) \end{itemize*} - \item Was die Protokollfunktionen betrifft, ist TLS im Wesentlichen dasselbe - wie SSL - \item Sicherheit: + \item Schlüsselaustausch: \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\ {}\ X-Ignore:\ {}} - \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\ {}\ X-Ignore:\ GET\ /ebanking/start.html\ HTTP/1.1} \end{itemize*} - \item Abgeschwächt durch Identifizierung neu ausgehandelter Sitzungen mit einer anderen ID ,,RRDO10'' + \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{Das Datagram Transport Layer Security - Protokoll} + \subsection{SSH-Transportprotokoll Paketformat} + % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ssh-transport-protocol-packet.png} + \begin{itemize*} + \item Das Paketformat ist nicht 32-Bit-wortorientiert + \item Felder des Pakets: \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: + \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 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) + \item MAC = HMAC(shared\_secret, seq\_number || 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{Das Secure - Shell-Protokoll} + \subsection{SSH-Aushandlung, Schlüsselaustausch und Server-Authentifizierung} + \begin{itemize*} + \item Algorithmus-Aushandlung: \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 + \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*} - - \subsection{SSH Version 2} + \item Für den Schlüsselaustausch definiert ,,YL06c'' nur eine Methode: \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*} + \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}\times \lfloor 2894 \times \pi + 129093\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\ mod\ p$ und sendet $e$ an den Server + \item Der Server wählt eine Zufallszahl $y$, errechnet $f=g^y\ mod\ p$ + \item Nach dem Empfang von $e$ berechnet der Server ferner $K=e^y\ mod\ 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\ mod\ 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-Transportprotokoll} + \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 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*} + \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 || K2 || ... \end{itemize*} + \end{itemize*} - \subsection{SSH-Transportprotokoll - Paketformat} - % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ssh-transport-protocol-packet.png} + \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 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 || 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 + \item Öffentlicher Schlüssel: Der Benutzer erzeugt und sendet eine Signatur mit einem öffentlichen Schlüssel pro Benutzer an den Server + \item $Client\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-Aushandlung, Schlüsselaustausch und - Server-Authentifizierung} + \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 Algorithmus-Aushandlung: + \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 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 + \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 Für den Schlüsselaustausch definiert ,,YL06c'' nur eine Methode: + \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 Diffie-Hellman mit SHA-1 und zwei vordefinierten Gruppen (1024 und 2048 Bit) - \item Z.B. $p = 2^{1024} -2^{960} - 1 + (2^{64}\times \lfloor 2894 \times \pi + 129093\rfloor); g = 2$ + \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 Schlüsselaustausch mit der vordefinierten DH-Gruppe - durchgeführt wird: + \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 Der Client wählt eine Zufallszahl $x$, berechnet $e=g^x\ mod\ p$ und sendet $e$ an den Server - \item Der Server wählt eine Zufallszahl $y$, errechnet $f=g^y\ mod\ p$ - \item Nach dem Empfang von $e$ berechnet der Server ferner $K=e^y\ mod\ 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\ mod\ p$ sowie den Hash-Wert $h$ und prüft dann die Signatur $s$ über $h$ + \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*} - \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*} + \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: - \subsection{SSH-Sitzungsschlüssel-Ableitung} + | SSH Client | | SSH Server | | -------------------------------------------------------------------------- | ---- | ---------------------------------------------------- | | ssh\_msg\_channel\_open (,,session'', 20, 2048, 512) | --->{} | | | \textless--- | ssh\_msg\_channel\_open\_confirmation(20, 31, 1024, 256) | | ssh\_msg\_channel\_request (31, ,,pty-req'', false, ...) | --->{} | | ssh\_msg\_channel\_request (31, ,,env'', false, ,,home'', ,,/home/username'') | --->{} | | ssh\_msg\_channel\_request (31, ,,shell'', true, ...) | --->{} | | | \textless--- | ssh\_msg\_channel\_success(20) | + ,,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 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: + \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 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 || K2 || ... + \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{SSH-Authentifizierungsprotokoll} + \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 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\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 + \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*} - \subsection{SSH-Verbindungsprotokoll} + \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 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: + \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 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. + \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 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: + \item Einige neue Schwierigkeiten bei der Realisierung von Sicherheitsdiensten: \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 + \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 Beispiel 1 - Anfordern einer interaktiven Sitzung und Starten einer - Shell darin: + \item Eine völlig neue Bedrohung: \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: | SSH Client | | SSH Server | | -------------------------------------------------------------------------- | ---- | ---------------------------------------------------- | | ssh\_msg\_channel\_open (,,session'', 20, 2048, 512) | --->{} | | | \textless--- | ssh\_msg\_channel\_open\_confirmation(20, 31, 1024, 256) | | ssh\_msg\_channel\_request (31, ,,pty-req'', false, ...) | --->{} | | ssh\_msg\_channel\_request (31, ,,env'', false, ,,home'', ,,/home/username'') | --->{} | | ssh\_msg\_channel\_request (31, ,,shell'', true, ...) | --->{} | | | \textless--- | ssh\_msg\_channel\_success(20) | - ,,Nutzdatenaustausch findet ab jetzt statt...'' + \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{SSH-Verbindungsprotokoll - II} + \subsection{Standortdatenschutz in Mobilfunknetzen} + \begin{itemize*} + \item In den heutigen Mobilfunknetzen gibt es keinen angemessenen Schutz des Standortes: \begin{itemize*} - \item Beispiel 2 - Anforderung der X11-Weiterleitung: + \item GSM / UMTS / LTE: \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*} + \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*} - - \subsection{Schlussfolgerung} + \item Drahtloses LAN: \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*} + \item Kein Datenschutz für den Standort, da die (weltweit eindeutige) MAC-Adresse in jedem MAC-Frame immer im Klartext enthalten ist \end{itemize*} - - \section{Sicherheitsaspekte der mobilen - Kommunikation} + \item Das grundlegende Problem des Datenschutzes: \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*} + \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*} - - \subsection{Standortdatenschutz in - Mobilfunknetzen} + \item Einige grundlegende Ansätze zur Lösung dieses Problems + ,,Müller99a'': \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: + \item Broadcast von Nachrichten: \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 + \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 Einige grundlegende Ansätze zur Lösung dieses Problems - ,,Müller99a'': + \item Temporäre Pseudonyme: \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*} + \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 Adressierungsschemata für standortbezogenen Datenschutz mit Broadcast: + \item Gemischte Netzwerke: \begin{itemize*} - \item Explizite Adressen: 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: 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 + \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: 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: 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*} + \begin{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. @@ -6613,16 +6241,10 @@ \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 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 @@ -6635,47 +6257,32 @@ \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! + \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[width=\linewidth]{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 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 + \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[width=\linewidth]{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 + \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: + \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 @@ -6693,10 +6300,7 @@ \end{itemize*} \end{itemize*} - - \subsection{Der zyklische - Redundanzcode} - + \subsection{Der zyklische Redundanzcode} \begin{itemize*} \item Der zyklische Redundanzcode (CRC) ist ein Fehlererkennungscode \item Mathematische Grundlage: @@ -6711,8 +6315,7 @@ \item Wenn dann $\frac{M(x)\times 2^n}{G(x)}=Q(x)+\frac{R(x)}{G(x)}$ gilt $\frac{M(x)\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 $\frac{M(x)\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$: + \item Betrachten wir nun zwei Nachrichten $M_1$ und $M_2$ mit CRCs $R_1$ und $R_2$: \begin{itemize*} \item Da $\frac{M_1(x)\times 2^n+R_1(x)}{G(x)}$ und $\frac{M_2(x)\times 2^n+R_2(x)}{G(x)}$ mit dem Rest $0$ teilen, teilt sich auch $\frac{M_1(x)\times 2^n +R_1(x)+M_2(x)\times 2^n +R_2(x)}{G(x)} =\frac{(M_1(x)+M_2(x))\times 2^n +(R_1(x)+R_2(x))}{G(x)}$ teilt mit Rest $0$ \item $\Rightarrow$ CRC ist linear, d.h. $CRC(M_1 + M_2) = CRC(M_1) + CRC(M_2)$ @@ -6720,59 +6323,44 @@ \item Diese Eigenschaft macht CRC schwach für kryptographische Zwecke! \end{itemize*} - - \subsection{IEEE 802.11 - Entity-Authentifizierung} - + \subsection{IEEE 802.11 Entity-Authentifizierung} \begin{itemize*} - \item Ursprünglich gibt es die IEEE 802.11-Authentifizierung in zwei - ,,Geschmacksrichtungen'': + \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*} + \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 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 \rightarrow B: (Authentifizierung, 1, ID_A)$ \item $B \rightarrow A: (Authentifizierung, 2, r_B)$ \item $A \rightarrow B: {Authentifizierung, 3, r_B}_{{K}{A,B}}$ \item $B \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! + \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} - + \subsection{IEEE 802.11's Wired Equivalence Privacy} \begin{itemize*} - \item IEEE 802.11's WEP verwendet RC4 als Pseudo-Zufallsbit-Generator - (PRNG): + \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 (,,||'') \item Die resultierende Nachricht $(M || ICV)$ wird mit dem von $RC4(IV || K_{BSS})$ erzeugten Schlüsselstrom XOR-verknüpft (,,$\oplus$'') % \item \includegraphics[width=\linewidth]{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. + \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: @@ -6780,28 +6368,28 @@ \end{itemize*} \end{itemize*} - - \subsection{Die Sicherheitsansprüche von IEEE - 802.11} - + \subsection{Die Sicherheitsansprüche von IEEE 802.11} \begin{itemize*} - \item WEP wurde entwickelt, um die folgenden Sicherheitseigenschaften zu - gewährleisten: + \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*} + \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*} + \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*} + \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} - + \subsubsection{Schwachstelle \#1: Die Schlüssel} \begin{itemize*} \item IEEE 802.11 sieht keine Schlüsselverwaltung vor: \begin{itemize*} @@ -6818,19 +6406,22 @@ \end{itemize*} \end{itemize*} - - \subsubsection{Schwachstelle \#2: WEP-Vertraulichkeit ist - unsicher} - + \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 \oplus RC4 (IV_1 , K_{BSS})$ \item $C_2 = P_2 \oplus RC4 (IV_1 , K_{BSS})$ dann: \item $C_1 \oplus C_2 = (P_1 \oplus RC4 (IV_1, K_{BSS})) \oplus (P_2\oplus RC4 (IV_1 , K_{BSS})) = P_1 \oplus P_2$ \end{itemize*} + \begin{itemize*} + \item $C_1 = P_1 \oplus RC4 (IV_1 , K_{BSS})$ + \item $C_2 = P_2 \oplus RC4 (IV_1 , K_{BSS})$ dann: + \item $C_1 \oplus C_2 = (P_1 \oplus RC4 (IV_1, K_{BSS})) \oplus (P_2\oplus RC4 (IV_1 , K_{BSS})) = P_1 \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*} + \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*} @@ -6839,21 +6430,14 @@ \end{itemize*} \end{itemize*} - - \subsubsection{Schwachstelle \#3: WEP-Datenintegrität ist - unsicher} - + \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: + \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 \rightarrow B: (IV, C) mit C = RC4(IV, K_{BSS}) \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: + \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 $\delta$ mit der gleichen Länge \item $C' = C \oplus (\delta, CRC(\delta)) = RC4(IV, K_{BSS}) \oplus (M, CRC(M)) \oplus (\delta, CRC(\delta))$ @@ -6866,46 +6450,43 @@ \end{itemize*} \end{itemize*} - - \subsubsection{Schwachstelle \#4: WEP-Zugangskontrolle ist - unsicher} - + \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: + \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})\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})\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*} + \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 $\Rightarrow$ WEP Access Control kann mit bekanntem - Klartext umgangen werden + \item $\Rightarrow$ WEP Access Control kann mit bekanntem Klartext umgangen werden \end{itemize*} - - \subsubsection{Schwachstelle Nr. 5: Schwachstelle in der - RC4-Schlüsselberechnung} - + \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*} + \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} - + \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*} @@ -6917,8 +6498,7 @@ \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 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 @@ -6927,36 +6507,28 @@ \end{itemize*} \end{itemize*} - - \subsection{Interlude: Sicherheit in öffentlichen - WLAN-Hotspots} - - Welche Sicherheit können Sie in einem öffentlichen WLAN-Hotspot - erwarten? - + \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: + \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*} + \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} - + \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 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 ($\rightarrow$ WEP) @@ -6976,16 +6548,11 @@ \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 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 @@ -6998,8 +6565,7 @@ \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 + \item Für aktuelle kryptographische Protokolle wird ein kurzzeitiger 512 Bit Pairwise Transient Key (PTK) wie folgt generiert \begin{itemize*} \item $PTK = PRF(PMK, \text{,,Paarweise Schlüsselerweiterung''}, min(Addr_{BS}, Addr_{STA}) || max(Addr_{BS}, Addr_{STA}) || min(r_{BS}, r_{STA}) || max(r_{BS}, r_{STA}))$ \item Dabei ist $PRF(K, A, B)$ die verkettete Ausgabe von $HMAC-SHA1(K, A || '0' || B || i)$ über einen laufenden Index i @@ -7036,17 +6602,18 @@ \end{itemize*} \end{itemize*} - - \subsection{Eine Zwischenlösung: Temporal Key Integrity - Protokoll} - + \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*} + \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*} @@ -7056,13 +6623,11 @@ \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 TKIP erfüllt die Kriterien für einen guten Standard: alle sind damit unzufrieden... %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-tkip-mpdu-data-format.png} \end{itemize*} Message Integrity Code Funktion Michael - \begin{itemize*} \item Schützt vor Fälschungen: \begin{itemize*} @@ -7071,13 +6636,15 @@ \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*} + \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[width=\linewidth]{Assets/NetworkSecurity-tkip-rekey.png} \end{itemize*} \end{itemize*} Wiederholungsschutz und RC4-Schlüsselplanung - \begin{itemize*} \item Replay-Schutz: \begin{itemize*} @@ -7099,10 +6666,7 @@ TKIP-Verarbeitung auf der Empfängerseite %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-tkip-receiver.png} - - \subsection{Die langfristige Lösung: AES-basierter - WLAN-Schutz} - + \subsection{Die langfristige Lösung: AES-basierter WLAN-Schutz} \begin{itemize*} \item Zählermodus mit CBC-MAC (CCMP): \begin{itemize*} @@ -7110,17 +6674,18 @@ \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*} + \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[width=\linewidth]{Assets/NetworkSecurity-aes-ccmp-frame-format.png} \end{itemize*} - - \subsection{Vergleich WEP, TKIP und - CCMP} - + \subsection{Vergleich WEP, TKIP und CCMP} %\begin{longtable}[]{@{}llll@{}} % \toprule % & WEP & TKIP & CCMP\tabularnewline @@ -7141,7 +6706,6 @@ TKIP ist derzeit veraltet, AES wird empfohlen. - \section{Sicherheit von GSM- und UMTS-Netzen} \subsection{GSM-Übersicht} \begin{itemize*} @@ -7207,7 +6771,6 @@ Der grundlegende (anfängliche) Authentifizierungsdialog: \begin{enumerate*} - \def\labelenumi{\arabic{enumi}.} \item $MS \rightarrow VLR: (IMSI_{MS})$ \item $VLR \rightarrow AuC: (IMSI_{MS})$ \item $AuC \rightarrow VLR: (IMSI_{MS}, K_{BSC,MS}, @@ -7226,7 +6789,6 @@ \end{itemize*} \item Dialog zur Wiederauthentifizierung mit demselben VLR: \begin{enumerate*} - \def\labelenumi{\arabic{enumi}.} \item $MS \rightarrow VLR: (LAI_1 , TMSI_{MS:n})$ \item $VLR \rightarrow MS: (R_{AUC:i})$ \item $MS \rightarrow VLR: (SRES_{AUC:i})$ @@ -7239,7 +6801,6 @@ \end{itemize*} \item Re-Authentifizierungsdialog mit Übergabe an das neue $VLR_2$: \begin{enumerate*} - \def\labelenumi{\arabic{enumi}.} \item $MS \rightarrow VLR_2: (LAI_1, TMSI_{MS:n})$ \item $VLR_2 \rightarrow VLR_1: (LAI_1, TMSI_{MS:n})$ \item $VLR_1 \rightarrow VLR_2: (TMSI_{MS:n}, IMSI_{MS}, K_{BSC,MS}, R_{AUC}, SRES_{AUC})$ @@ -7273,9 +6834,7 @@ \item Grundsätzlich besteht Vertrauen zwischen allen Betreibern! \end{itemize*} - \subsection{General Packet Radio Service - (GPRS)} - + \subsection{General Packet Radio Service (GPRS)} \begin{itemize*} \item GPRS (General Packet Radio Service, allgemeiner Paketfunkdienst): \begin{itemize*} @@ -7332,33 +6891,23 @@ % \includegraphics[width=\linewidth]{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) + \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[width=\linewidth]{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 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 + \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 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 @@ -7369,34 +6918,31 @@ \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 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: + \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: + \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: + \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: + \item Integrität der Daten \begin{itemize*} \item Vereinbarung eines Integritätsalgorithmus \item Integritätsschlüssel-Vereinbarung @@ -7424,9 +6970,7 @@ % \bottomrule %\end{longtable} - \subsubsection{Überblick über den UMTS-Authentifizierungsmechanismus} - \begin{itemize*} \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-umts-authentication-mechanism.png} \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-umts-authentication-vectors.png} @@ -7466,13 +7010,9 @@ \end{itemize*} \end{itemize*} - - \subsubsection{Schlussfolgerungen zur Sicherheit in UMTS - Release'99} - + \subsubsection{Schlussfolgerungen zur Sicherheit in UMTS Release'99} \begin{itemize*} - \item Die Sicherheit von UMTS Release '99 ist der Sicherheit von GSM sehr - ähnlich: + \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. @@ -7485,15 +7025,12 @@ \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 + \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 + \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