Symmetrische Kryptographie
This commit is contained in:
parent
7c5c22e935
commit
0f4411be51
BIN
Network Security - Cheatsheet.pdf
(Stored with Git LFS)
BIN
Network Security - Cheatsheet.pdf
(Stored with Git LFS)
Binary file not shown.
@ -259,20 +259,11 @@
|
||||
|
||||
\subsection{Kommunikationssicherheit}
|
||||
\begin{itemize*}
|
||||
\item Sicherheitsdienst
|
||||
\begin{itemize*}
|
||||
\item abstrakter Dienst, der bestimmte Sicherheitseigenschaft gewährleisten soll
|
||||
\item Sicherheitsdienst kann sowohl mit Hilfe von kryptografischen Algorithmen und Protokollen als auch mit herkömmlichen Mitteln realisiert werden
|
||||
\begin{itemize*}
|
||||
\item Man kann ein elektronisches Dokument auf einem USB-Stick vertraulich halten, indem man es in einem verschlüsselten Format auf dem Datenträger speichert und den Datenträger in einem Tresor wegschließt.
|
||||
\item i.d.R. ist Kombination aus kryptografischen und anderen Mitteln am effektivsten
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\item Kryptographischer Algorithmus
|
||||
\begin{itemize*}
|
||||
\item mathematische Umwandlung von Eingabedaten in Ausgabedaten
|
||||
\item krypt. Algorithmen werden in krypt. Protokollen verwendet
|
||||
\end{itemize*}
|
||||
\item Sicherheitsdienst: abstrakter Dienst, der bestimmte Sicherheitseigenschaft gewährleisten soll
|
||||
\item Sicherheitsdienst kann sowohl mit Hilfe von kryptografischen Algorithmen und Protokollen als auch mit herkömmlichen Mitteln realisiert werden
|
||||
\item Dokument auf USB-Stick vertraulich, indem es verschlüsselt gespeichert und Datenträger in Tresor verschlossen
|
||||
\item i.d.R. ist Kombination aus kryptografischen und anderen Mitteln am effektivsten
|
||||
\item Kryptographischer Algorithmus: mathematische Umwandlung von Eingabedaten in Ausgabedaten
|
||||
\item Kryptografisches Protokoll: Reihe von Schritten und Austausch von Nachrichten %zwischen mehreren Einheiten, um ein bestimmtes Sicherheitsziel zu erreichen
|
||||
\end{itemize*}
|
||||
|
||||
@ -300,34 +291,33 @@
|
||||
|
||||
\subsection{Sicherheitsunterstützende Mechanismen}
|
||||
\begin{description*}
|
||||
\item[Schlüsselverwaltung] Alle Aspekte des Lebenszyklus von kryptografischen Schlüsseln
|
||||
\item[Schlüsselverwaltung] alle Aspekte des Lebenszyklus von kryptografischen Schlüsseln
|
||||
\item[Zufallszahlengenerierung] Generierung von kryptographisch sicheren Zufallszahlen
|
||||
\item[Ereigniserkennung/Sicherheitsprüfpfad] Erkennung und Aufzeichnung von Ereignissen, die zur Erkennung von Angriffen oder Bedingungen, die von Angriffen ausgenutzt werden könnten, verwendet werden können
|
||||
\item[Ereigniserkennung/Sicherheitsprüfpfad] Erkennung und Aufzeichnung von Ereignissen, zur Erkennung von Angriffen oder Bedingungen, die von Angriffen ausgenutzt werden könnten
|
||||
\item[Erkennung von Eindringlingen] Analyse der aufgezeichneten Sicherheitsdaten, um erfolgreiche Einbrüche oder Angriffe zu erkennen
|
||||
\item[Beglaubigung] Registrierung von Daten durch eine vertrauenswürdige dritte Partei, die später bestimmte Eigenschaften der Daten bestätigen kann
|
||||
\item[Beglaubigung] Registrierung durch vertrauenswürdige Partei, die bestimmte Eigenschaften der Daten bestätigen kann
|
||||
\item[Traffic Padding \& Cover Traffic] Erzeugung von gefälschtem Verkehr, um die Analyse des Verkehrsflusses zu verhindern
|
||||
\item[Routing-Kontrolle] Beeinflussung des Routings von PDUs in einem Netzwerk
|
||||
\item[Routing-Kontrolle] Beeinflussung des Routings von PDUs in Netzwerk
|
||||
\end{description*}
|
||||
|
||||
|
||||
\subsection{Kryptologie}
|
||||
\begin{description*}
|
||||
\item Wissenschaft, die sich mit sicherer und meist geheimer Kommunikation beschäftigt
|
||||
\item[Kryptographie] die Lehre von den Prinzipien und Techniken, mit denen Informationen in verschlüsseltem Text verborgen und später von legitimen Nutzern mit Hilfe eines geheimen Schlüssels offengelegt werden können
|
||||
\item[Kryptologie] Wissenschaft, die sich mit sicherer und meist geheimer Kommunikation beschäftigt
|
||||
\item[Kryptographie] die Lehre, mit der Informationen in verschlüsseltem Text verborgen und später von legitimen Nutzern mit Hilfe eines geheimen Schlüssels offengelegt werden können
|
||||
\item[Kryptoanalyse] die Wissenschaft der Wiedergewinnung von Informationen aus Chiffren ohne Kenntnis des Schlüssels
|
||||
\item[Chiffre] Methode zur Umwandlung einer Nachricht (Klartext), um ihre Bedeutung zu verschleiern
|
||||
\item[Verschlüsselung] von Daten: Umwandlung von Klartextdaten in Chiffretext, um deren Bedeutung zu verbergen
|
||||
\item[Signierung] von Daten: Berechnung eines Prüfwerts oder digitalen Signatur für gegebenen Klartext oder Geheimtext, der anderen Stellen, die auf die signierten Daten zugreifen können, überprüft werden kann
|
||||
\item[Symmetrische] Kryptografie, die 1 Schlüssel für die Ver-/Entschlüsselung oder die Signierung/Prüfung verwendet
|
||||
\item[Asymmetrische] Kryptografie mit 2 verschiedenen Schlüsseln für die Ver-/Entschlüsselung oder die Unterzeichnung/Prüfung
|
||||
\item[Kryptografische Hash-Funktionen] mit 0 Schlüsseln ("Schlüssel" ist keine separate Eingabe, sondern wird an die Daten "angehängt" oder mit ihnen "vermischt")
|
||||
\item[Kryptografische Hash-Funktionen] mit 0 Schlüsseln (,,Schlüssel'' wird an Daten ,,angehängt'' oder ,,vermischt'')
|
||||
\end{description*}
|
||||
|
||||
\subsection{Kryptoanalyse}
|
||||
\begin{itemize*}
|
||||
\item Arten der Kryptoanalyse
|
||||
\begin{itemize*}
|
||||
\item Nur Chiffretext: bestimmte Muster können im Chiffretext erhalten bleiben
|
||||
\item Nur Chiffretext: bestimmte Muster können erhalten bleiben
|
||||
\item Bekannte Chiffretext-Klartext-Paare
|
||||
\item Gewählter Klartext oder gewählter Chiffretext
|
||||
\item Differentielle Kryptoanalyse und lineare Kryptoanalyse
|
||||
@ -335,8 +325,9 @@
|
||||
\end{itemize*}
|
||||
\item Kryptoanalyse der Public-Key-Kryptographie
|
||||
\begin{itemize*}
|
||||
\item dass ein Schlüssel öffentlich zugänglich ist, kann ausgenutzt werden
|
||||
\item Kryptoanalyse öffentlicher Schlüssel zielt eher darauf ab, das Kryptosystem selbst zu knacken und ist näher an der reinen mathematischen Forschung als an der klassischen Kryptoanalyse
|
||||
\item Schlüssel öffentlich zugänglich, kann ausgenutzt werden
|
||||
\item zielt eher darauf ab, das Kryptosystem selbst zu knacken
|
||||
\item näher an reinen mathematischen Forschung als klassische Kryptoanalyse
|
||||
\item Berechnung von diskreten Logarithmen
|
||||
\item Faktorisierung von großen ganzen Zahlen
|
||||
\end{itemize*}
|
||||
@ -344,98 +335,53 @@
|
||||
|
||||
\subsubsection{Brute-Force-Angriff}
|
||||
\begin{itemize*}
|
||||
\item Der Brute-Force-Angriff probiert alle möglichen Schlüssel aus, bis er einen verständlichen Klartext findet
|
||||
\item Jeder kryptographische Algorithmus kann theoretisch mit Brute Force angegriffen werden
|
||||
\item Im Durchschnitt muss die Hälfte aller möglichen Schlüssel ausprobiert werden
|
||||
\item probiert alle möglichen Schlüssel aus, bis er verständlichen Klartext findet
|
||||
\item Jeder kryptog. Algorithmus kann mit BF angegriffen werden
|
||||
\item Im Durchschnitt Hälfte aller möglichen Schlüssel ausprobieren
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Wie groß ist groß?}
|
||||
Referenzzahlen zum Vergleich relativer Größenordnungen
|
||||
\begin{tabular}{l|l}
|
||||
Referenz & Größe \\
|
||||
Referenz & Größe \\\hline
|
||||
Sekunden in einem Jahr & ca. $3 *10^7$ \\
|
||||
Taktzyklen pro Jahr (50 MHz Computer) & ca. $1,6 *10^{15}$ \\
|
||||
Binäre Zeichenketten der Länge 64 & $2^{64}$ ca. $1,8 * 10^{19}$ \\
|
||||
Binäre Zeichenfolgen der Länge 128 & $2^{128}$ ca. $3,4 * 10^{38}$ \\
|
||||
Binäre Zeichenfolgen der Länge 256 & $2^{256}$ ca. $1,2 * 10^{77}$ \\
|
||||
Anzahl der 75-stelligen Primzahlen & $5,2 * 10^{72}$ \\
|
||||
Elektronen im Universum & $8,37 * 10^{77}$
|
||||
\end{tabular}
|
||||
|
||||
\subsubsection{Wichtige Eigenschaften von Verschlüsselungsalgorithmen}
|
||||
Nehmen wir an, ein Absender verschlüsselt Klartextnachrichten $P_1, P_2, ...$ zu Chiffretextnachrichten $C_1, C_2, ...$
|
||||
|
||||
Dann sind die folgenden Eigenschaften des Verschlüsselungsalgorithmus von besonderem Interesse
|
||||
|
||||
\begin{itemize*}
|
||||
\item Die Fehlerfortpflanzung charakterisiert die Auswirkungen von Bit-Fehlern bei der Übertragung von Chiffretext zu rekonstruiertem Klartext $P_1', P_2', ...$
|
||||
\begin{itemize*}
|
||||
\item Je nach Verschlüsselungsalgorithmus können pro fehlerhaftem Chiffretext-Bit ein oder mehrere fehlerhafte Bits im rekonstruierten Klartext vorhanden sein
|
||||
\end{itemize*}
|
||||
\item Die Synchronisierung charakterisiert die Auswirkungen verlorener Chiffretext-Dateneinheiten auf den rekonstruierten Klartext
|
||||
\begin{itemize*}
|
||||
\item Einige Verschlüsselungsalgorithmen können sich nicht von verlorenem Chiffretext erholen und benötigen daher eine explizite Neusynchronisierung im Falle verlorener Nachrichten
|
||||
\item Andere Algorithmen führen eine automatische Neusynchronisierung nach 0 bis n (n je nach Algorithmus) Chiffretextbits durch.
|
||||
\end{itemize*}
|
||||
\item \textbf{Fehlerfortpflanzung} charakterisiert Auswirkungen von Bit-Fehlern bei Übertragung von Chiffretext zu rekonstruiertem Klartext
|
||||
\item Je nach Verschlüsselungsalgorithmus können pro fehlerhaftem Chiffretext-Bit ein oder mehrere fehlerhafte Bits im rekonstruierten Klartext vorhanden sein
|
||||
\item \textbf{Synchronisierung} charakterisiert die Auswirkungen verlorener Chiffretext-Dateneinheiten auf den rekonstruierten Klartext
|
||||
\item Einige Verschlüsselungsalgorithmen können sich nicht von verlorenem Chiffretext erholen und benötigen daher eine explizite Neusynchronisierung im Falle verlorener Nachrichten
|
||||
\item Andere Algorithmen führen eine automatische Neusynchronisierung nach 0 bis n (n je nach Algorithmus) Chiffretextbits durch.
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{Klassifizierung von Verschlüsselungsalgorithmen: Drei Dimensionen}
|
||||
\subsection{Klassifizierung von Verschlüsselungsalgorithmen}
|
||||
\begin{itemize*}
|
||||
\item Die Art der Operationen, die zur Umwandlung von Klartext in Chiffretext verwendet werden
|
||||
\begin{itemize*}
|
||||
\item Substitution, die jedes Element des Klartextes (Bit, Buchstabe, Gruppe von Bits oder Buchstaben) in ein anderes Element umwandelt
|
||||
\item Transposition, die die Elemente des Klartextes neu anordnet
|
||||
\end{itemize*}
|
||||
\item Die Anzahl der verwendeten Schlüssel
|
||||
\begin{itemize*}
|
||||
\item Symmetrische Chiffren, die denselben Schlüssel für die Ver- und Entschlüsselung verwenden
|
||||
\item Asymmetrische Chiffren, bei denen unterschiedliche Schlüssel für die Ver- und Entschlüsselung verwendet werden
|
||||
\end{itemize*}
|
||||
\item Die Art und Weise, in der der Klartext verarbeitet wird
|
||||
\begin{itemize*}
|
||||
\item Stromchiffren arbeiten mit Bitströmen und verschlüsseln ein Bit nach dem anderen
|
||||
\item Art der Operationen
|
||||
\begin{description*}
|
||||
\item[Substitution] jedes Element des Klartextes in anderes Element umwandeln
|
||||
\item[Transposition] Elemente des Klartextes neu anordnen
|
||||
\end{description*}
|
||||
\item Anzahl der verwendeten Schlüssel
|
||||
\begin{description*}
|
||||
\item[Symmetrisch] denselben Schlüssel
|
||||
\item[Asymmetrisch] unterschiedliche Schlüssel
|
||||
\end{description*}
|
||||
\item Art und Weise, in der Klartext verarbeitet wird
|
||||
\begin{description*}
|
||||
\item[Stromchiffren] arbeiten mit Bitströmen und verschlüsseln ein Bit nach dem anderen
|
||||
\begin{itemize*}
|
||||
\item Viele Stromchiffren basieren auf der Idee der linearen rückgekoppelten Schieberegister, und bei vielen Algorithmen dieser Klasse wurden Schwachstellen entdeckt, da es eine tiefgreifende mathematische Theorie zu diesem Thema gibt.
|
||||
\item Die meisten Stromchiffren verbreiten keine Fehler, sind aber anfällig für den Verlust der Synchronisation.
|
||||
\item Idee lineare rückgekoppelter Schieberegister
|
||||
\item meiste Stromchiffren verbreiten keine Fehler
|
||||
\item anfällig für den Verlust der Synchronisation
|
||||
\end{itemize*}
|
||||
\item Blockchiffren arbeiten mit Blöcken der Breite b, wobei b vom jeweiligen Algorithmus abhängt.
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{Kryptographische Algorithmen - Überblick}
|
||||
Kryptografische Algorithmen
|
||||
\begin{itemize*}
|
||||
\item Überblick
|
||||
\begin{itemize*}
|
||||
\item Eigenschaften
|
||||
\item Kryptoanalyse
|
||||
\end{itemize*}
|
||||
\item Symmetrische Ver-/Entschlüsselung
|
||||
\begin{itemize*}
|
||||
\item Funktionsweisen
|
||||
\item DES
|
||||
\item AES
|
||||
\item RC4
|
||||
\item KASUMI
|
||||
\end{itemize*}
|
||||
\item Asymmetrische Ver-/Entschlüsselung
|
||||
\begin{itemize*}
|
||||
\item Hintergrund
|
||||
\item RSA
|
||||
\item Diffie-Hellman
|
||||
\item ElGamal
|
||||
\item ECC
|
||||
\end{itemize*}
|
||||
\item Kryptographische Hash-Funktionen
|
||||
\begin{itemize*}
|
||||
\item MDCs/MACs
|
||||
\item MD
|
||||
\item SHA-1/2/
|
||||
\item CBC-MAC
|
||||
\item GCM-MAC
|
||||
\end{itemize*}
|
||||
\item[Blockchiffren] arbeiten mit Blöcken der Breite b, wobei b vom jeweiligen Algorithmus abhängt
|
||||
\end{description*}
|
||||
\end{itemize*}
|
||||
|
||||
\section{Symmetrische Kryptographie}
|
||||
@ -443,46 +389,40 @@
|
||||
\begin{itemize*}
|
||||
\item Derselbe Schlüssel KA,B wird für die Verschlüsselung und Entschlüsselung von Nachrichten verwendet
|
||||
\item Wenn P die Klartextnachricht bezeichnet, bezeichnet $E(K_{A,B}, P)$ den Chiffretext und es gilt $D(K_{A,B}, E(K_{A,B}, P)) = P$
|
||||
\item Alternativ schreibt man manchmal $P_{K_{A,B}}$ oder $E_{K_{A,B}}(P)$ für $E(K_{A,B}, P)$
|
||||
\item Alternativ schreibt man manchmal $P_{K_{A,B}}$ oder $E_{K_{A,B}}(P)$
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Symmetrische Blockchiffren - Verschlüsselungsarten}
|
||||
Allgemeine Bemerkungen \& Notation
|
||||
\subsection{Symmetrische Block-Verschlüsselungsarten}
|
||||
\subsubsection{Electronic Code Book Mode: ECB}
|
||||
\begin{itemize*}
|
||||
\item Ein Klartext P wird in Blöcke $P_1, P_2, ...$ der Länge b bzw. j zerlegt, wobei b die Blockgröße des Verschlüsselungsalgorithmus bezeichnet und j < b
|
||||
\item Der Chiffretext C ist die Kombination von $C_1, C_2, ...$, wobei $c_i$ das Ergebnis der Verschlüsselung des i-ten Blocks der Klartextnachricht bezeichnet
|
||||
\item Die Stellen, die eine Nachricht verschlüsseln und entschlüsseln, haben sich auf einen Schlüssel K geeinigt.
|
||||
\item Jeder Block $P_i$ der Länge $b$ wird unabhängig verschlüsselt: $C_i = E(K, p_i)$
|
||||
\item Bitfehler in Chiffretextblock $C_i$ führt zu völlig falsch wiederhergestellten Klartextblock $P_i'$
|
||||
\item Verlust der Synchronisation hat keine Auswirkungen, wenn ganzzahlige Vielfache der Blockgröße b verloren gehen% Geht eine andere Anzahl von Bits verloren, ist eine explizite Neusynchronisation erforderlich.
|
||||
\item Nachteil: identische Klartextblöcke werden zu identischem Chiffretext verschlüsselt
|
||||
\end{itemize*}
|
||||
\begin{center}
|
||||
\includegraphics[width=.6\linewidth]{Assets/NetworkSecurity-electronic-code-book-mode.png}
|
||||
\end{center}
|
||||
|
||||
Elektronischer Codebuch-Modus (Electronic Code Book Mode: ECB)
|
||||
\subsubsection{Cipher Block Chaining Mode: CBC}
|
||||
\begin{itemize*}
|
||||
\item Jeder Block Pi der Länge b wird unabhängig verschlüsselt: $C_i = E(K, p_i)$
|
||||
\item Ein Bitfehler in einem Chiffretextblock $C_i$ führt zu einem völlig falsch wiederhergestellten Klartextblock $P_i'$
|
||||
\item Der Verlust der Synchronisation hat keine Auswirkungen, wenn ganzzahlige Vielfache der Blockgröße b verloren gehen. Geht eine andere Anzahl von Bits verloren, ist eine explizite Neusynchronisation erforderlich.
|
||||
\item Nachteil: identische Klartextblöcke werden zu identischem Chiffretext verschlüsselt!
|
||||
%\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-electronic-code-book-mode.png}
|
||||
\end{itemize*}
|
||||
|
||||
Cipher Block Chaining Modus (Cipher Block Chaining Mode: CBC)
|
||||
\begin{itemize*}
|
||||
\item Vor der Verschlüsselung eines Klartextblocks pi wird dieser mit dem vorangegangenen Chiffretextblock $C_{i-1}$ XOR-verknüpft ()
|
||||
\item Vor Verschlüsselung eines Klartextblocks $P_i$ wird dieser mit dem vorangegangenen Chiffretextblock $C_{i-1}$ XOR-verknüpft
|
||||
\begin{itemize*}
|
||||
\item $C_i = E(K, C_{i-1} \oplus p_i)$
|
||||
\item $C_i = E(K, C_{i-1} \oplus P_i)$
|
||||
\item $P_{i'} = C_{i-1} \oplus D(K, C_i)$
|
||||
\item Um $C_1$ zu berechnen, einigen sich beide Parteien auf einen Anfangswert (IV) für $C_0$
|
||||
\end{itemize*}
|
||||
\item Eigenschaften
|
||||
\begin{itemize*}
|
||||
\item Fehlerfortpflanzung: Ein verfälschter Chiffretextblock führt zu zwei verfälschten Klartextblöcken, da $P_i'$ mit $C_{i-1}$ und $C_i$ berechnet wird
|
||||
\item Synchronisation: Wenn die Anzahl der verlorenen Bits ein ganzzahliges Vielfaches von b ist, wird ein zusätzlicher Block $P_{i+1}$ verzerrt, bevor die Synchronisation wiederhergestellt wird. Wenn eine andere Anzahl von Bits verloren geht, ist eine explizite Neusynchronisation erforderlich.
|
||||
\item Vorteil: identische Klartextblöcke werden zu nicht-identischem Chiffretext verschlüsselt.
|
||||
\end{itemize*}
|
||||
%\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-cipher-block-chaining-mode.png}
|
||||
\item Fehlerfortpflanzung: Ein verfälschter Chiffretextblock führt zu zwei verfälschten Klartextblöcken, da $P_i'$ mit $C_{i-1}$ und $C_i$ berechnet wird
|
||||
\item Synchronisation: Wenn die Anzahl der verlorenen Bits ein ganzzahliges Vielfaches von b ist, wird ein zusätzlicher Block $P_{i+1}$ verzerrt, bevor die Synchronisation wiederhergestellt wird %Wenn eine andere Anzahl von Bits verloren geht, ist eine explizite Neusynchronisation erforderlich
|
||||
\item Vorteil: identische Klartextblöcke werden zu nicht-identischem Chiffretext verschlüsselt
|
||||
\end{itemize*}
|
||||
\begin{center}
|
||||
\includegraphics[width=.6\linewidth]{Assets/NetworkSecurity-cipher-block-chaining-mode.png}
|
||||
\end{center}
|
||||
|
||||
Chiffretext-Feedback-Modus (Ciphertext Feedback Mode: CFB)
|
||||
\subsubsection{Ciphertext Feedback Mode: CFB}
|
||||
\begin{itemize*}
|
||||
\item Ein Blockverschlüsselungsalgorithmus, der mit Blöcken der Größe b arbeitet, kann in einen Algorithmus umgewandelt werden, der mit Blöcken der Größe $j (j\textless b)$ arbeitet.
|
||||
\item Ein Blockverschlüsselungsalgorithmus, der mit Blöcken der Größe b arbeitet, kann in einen Algorithmus umgewandelt werden, der mit Blöcken der Größe $j (j<b)$ arbeitet
|
||||
\begin{itemize*}
|
||||
\item $S(j, x)$ bezeichnen die $j$ höherwertigen Bits von $x$
|
||||
\item $P_i$, $C_i$ den $i$-ten Block von Klartext und Geheimtext der Länge $j$ bezeichnen
|
||||
@ -494,17 +434,14 @@
|
||||
\item $S(j,E_K(R_n))\oplus C_n = P_n$
|
||||
\end{itemize*}
|
||||
\item Ein gängiger Wert für j ist 8 für die Verschlüsselung von einem Zeichen pro Schritt
|
||||
\item Eigenschaften von CFB
|
||||
\begin{itemize*}
|
||||
\item Fehlerfortpflanzung: Da die Chiffretextblöcke schrittweise durch das Register geschoben werden, verfälscht ein fehlerhafter Block $C_i$ den wiederhergestellten Klartextblock $P_i'$ sowie die folgenden $\lceil b / j\rceil$-Blöcke
|
||||
\item Synchronisation: Wenn die Anzahl der verlorenen Bits ein ganzzahliges Vielfaches von j ist, werden $\lceil b / j\rceil$ zusätzliche Blöcke verfälscht, bevor die Synchronisation wiederhergestellt ist. Wenn eine beliebige andere Anzahl von Bits verloren geht, ist eine explizite Neusynchronisierung erforderlich.
|
||||
\item Nachteil: Die Verschlüsselungsfunktion E muss häufiger berechnet werden, da eine Verschlüsselung von b Bit durchgeführt werden muss, um j Bit des Klartextes zu verbergen. Beispiel: Bei Verwendung von DES mit Verschlüsselung von jeweils einem Zeichen $\Rightarrow$ muss die Verschlüsselung 8-mal häufiger durchgeführt werden
|
||||
\end{itemize*}
|
||||
\item Fehlerfortpflanzung: Da die Chiffretextblöcke schrittweise durch das Register geschoben werden, verfälscht ein fehlerhafter Block $C_i$ den wiederhergestellten Klartextblock $P_i'$ sowie die folgenden $\lceil b / j\rceil$-Blöcke
|
||||
\item Synchronisation: Wenn die Anzahl der verlorenen Bits ein ganzzahliges Vielfaches von j ist, werden $\lceil b / j\rceil$ zusätzliche Blöcke verfälscht, bevor die Synchronisation wiederhergestellt ist% Wenn eine beliebige andere Anzahl von Bits verloren geht, ist eine explizite Neusynchronisierung erforderlich
|
||||
\item Nachteil: Die Verschlüsselungsfunktion E muss häufiger berechnet werden, da eine Verschlüsselung von $b$ Bit durchgeführt werden muss, um $j$ Bit des Klartextes zu verbergen. Beispiel: Bei Verwendung von DES mit Verschlüsselung von jeweils einem Zeichen $\Rightarrow$ muss die Verschlüsselung 8-mal häufiger durchgeführt werden
|
||||
\end{itemize*}
|
||||
|
||||
Output-Feedback-Modus (OFB)
|
||||
\subsubsection{Output-Feedback-Modus: OFB}
|
||||
\begin{itemize*}
|
||||
\item Der Blockverschlüsselungsalgorithmus wird zur Erzeugung einer Pseudozufallsfolge $R_i$ verwendet, die nur von $K$ und $IV$ abhängt.
|
||||
\item Der Blockverschlüsselungsalgorithmus wird zur Erzeugung einer Pseudozufallsfolge $R_i$ verwendet, die nur von $K$ und $IV$ abhängt
|
||||
\begin{itemize*}
|
||||
\item $S(j, x)$ bezeichnen die $j$ höherwertigen Bits von $x$
|
||||
\item $P_i$, $C_i$ bezeichnen den $i$-ten Block von Klartext und Chiffretext der Länge $j$
|
||||
@ -516,51 +453,45 @@
|
||||
\item $S(j,E_K(R_n))\oplus C_n = P_n$
|
||||
\end{itemize*}
|
||||
\item Der Klartext wird mit der Pseudo-Zufallssequenz XOR-verknüpft, um den Chiffretext zu erhalten und umgekehrt
|
||||
\item Eigenschaften von OFB
|
||||
\begin{itemize*}
|
||||
\item Fehlerfortpflanzung: Einzelbitfehler führen nur zu Einzelbitfehlern $\rightarrow$ keine Fehlermultiplikation
|
||||
\item Synchronisierung: Wenn einige Bits verloren gehen, ist eine explizite Re-Synchronisation erforderlich.
|
||||
\item Vorteil: Die Pseudo-Zufallsfolge kann vorberechnet werden, um die Auswirkungen der Verschlüsselung auf die Ende-zu-Ende-Verzögerung gering zu halten
|
||||
\item Nachteile
|
||||
\begin{itemize*}
|
||||
\item Wie bei CFB muss die Verschlüsselungsfunktion E häufiger berechnet werden, da eine Verschlüsselung von b Bit durchgeführt werden muss, um j Bit des Klartextes zu verbergen
|
||||
\item Es ist für einen Angreifer möglich, bestimmte Bits des Klartextes zu manipulieren
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
%\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-output-feedback-mode.png}
|
||||
\item Fehlerfortpflanzung: Einzelbitfehler führen nur zu Einzelbitfehlern $\rightarrow$ keine Fehlermultiplikation
|
||||
\item Synchronisierung: Wenn einige Bits verloren gehen, ist eine explizite Re-Synchronisation erforderlich
|
||||
\item Vorteil: Die Pseudo-Zufallsfolge kann vorberechnet werden, um die Auswirkungen der Verschlüsselung auf die Ende-zu-Ende-Verzögerung gering zu halten
|
||||
\item Wie bei CFB muss die Verschlüsselungsfunktion E häufiger berechnet werden, da eine Verschlüsselung von b Bit durchgeführt werden muss, um j Bit des Klartextes zu verbergen
|
||||
\item Es ist für einen Angreifer möglich, bestimmte Bits des Klartextes zu manipulieren
|
||||
\end{itemize*}
|
||||
\begin{center}
|
||||
\includegraphics[width=.6\linewidth]{Assets/NetworkSecurity-output-feedback-mode.png}
|
||||
\end{center}
|
||||
|
||||
\subsection{Der Datenverschlüsselungsstandard (DES)}
|
||||
|
||||
Geschichte
|
||||
\subsection{Datenverschlüsselungsstandard (DES)}
|
||||
\begin{itemize*}
|
||||
\item symmetrische Blockchiffre mit Blöcken der Länge 128 Bit
|
||||
\item unter Verwendung von Schlüsseln der Länge 128 Bit arbeitet
|
||||
\item NSA reduzierte die Blockgröße auf 64 Bit, die Größe des Schlüssels auf 56 Bit und änderte Details in den Substitutionsfeldern des Algorithmus
|
||||
\item unter Verwendung von Schlüsseln der Länge 128 Bit
|
||||
\item NSA reduzierte Blockgröße auf 64 Bit, die Größe des Schlüssels auf 56 Bit und änderte Details in den Substitutionsfeldern des Algorithmus
|
||||
\end{itemize*}
|
||||
% \includegraphics[width=\linewidth]{Assets/NetworkSecurity-des-algorithm.png}
|
||||
% \includegraphics[width=\linewidth]{Assets/NetworkSecurity-des-single-iteration.png}
|
||||
\begin{center}
|
||||
\includegraphics[width=.6\linewidth]{Assets/NetworkSecurity-des-single-iteration.png}
|
||||
\end{center}
|
||||
|
||||
\subsubsection{DES - Einzelne Iteration}
|
||||
\begin{itemize*}
|
||||
\item Die rechten 32 Bit der zu verschlüsselnden Daten werden mit Hilfe einer Expansions-/Permutationstabelle auf 48 Bit erweitert.
|
||||
\item Sowohl die linken als auch die rechten 28 Bit des Schlüssels (auch Subkeys genannt) werden zirkulär nach links verschoben und der resultierende Wert wird mit Hilfe einer Permutations-/Kontraktionstabelle auf 48 Bit verkürzt.
|
||||
\item Die beiden oben genannten Werte werden XOR-verknüpft und in eine Auswahl- und Ersetzungsbox eingegeben
|
||||
\begin{itemize*}
|
||||
\item Intern wird diese Operation durch 8 so genannte s-Boxen realisiert, von denen jede einen Sechs-Bit-Wert auf einen Vier-Bit-Wert gemäß einer boxspezifischen Tabelle abbildet, was insgesamt zu einem 32-Bit-Ausgang führt
|
||||
\item Das Design dieser s-boxes wurde von der NSA verstärkt, was in den 1970er Jahren zu intensiven Diskussionen führte und in den 1990er Jahren nach der Entdeckung der differentiellen Kryptoanalyse verstanden wurde
|
||||
\end{itemize*}
|
||||
\item Der Ausgang des obigen Schritts wird erneut permutiert und mit den linken 32 Bit der Daten XOR-verknüpft, was zu den neuen rechten 32 Bit der Daten führt
|
||||
\item Die rechten 32 Bit der zu verschlüsselnden Daten werden mit Hilfe einer Expansions-/Permutationstabelle auf 48 Bit erweitert
|
||||
\item linke und rechte 28 Bit des Schlüssels werden zirkulär nach links verschoben und der resultierende Wert wird mit Hilfe einer Permutations-/Kontraktionstabelle auf 48 Bit verkürzt
|
||||
\item beide oben genannten Werte XOR-verknüpft und in Auswahl- und Ersetzungsbox eingegeben
|
||||
\item Intern wird diese Operation durch 8 so genannte s-Boxen realisiert, von denen jede einen Sechs-Bit-Wert auf einen Vier-Bit-Wert gemäß einer boxspezifischen Tabelle abbildet, was insgesamt zu einem 32-Bit-Ausgang führt
|
||||
\item Ausgang des obigen Schritts wird erneut permutiert und mit den linken 32 Bit der Daten XOR-verknüpft, was zu den neuen rechten 32 Bit der Daten führt
|
||||
\item Die neuen linken 32 Bit der Daten sind der rechte Wert der vorherigen Iteration
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{DES - Entschlüsselung}
|
||||
\begin{itemize*}
|
||||
\item Unter Verwendung der Abkürzung f(R, K) kann der Verschlüsselungsprozess wie folgt geschrieben werden
|
||||
\item Unter Verwendung der Abkürzung $f(R, K)$ kann der Verschlüsselungsprozess wie folgt geschrieben werden
|
||||
\begin{itemize*}
|
||||
\item $L_i = R_{i-1}$
|
||||
\item $R_i = L_{i-1}\oplus f(R_{i-1}, K_i)$
|
||||
\item Dieses Konzept (Aufteilung der Daten in zwei Hälften und Organisation der Verschlüsselung gemäß den obigen Gleichungen) wird in vielen Blockchiffren verwendet und wird als Feistel-Netzwerk bezeichnet (nach seinem Erfinder H. Feistel)
|
||||
\item Aufteilung der Daten in zwei Hälften und Organisation der Verschlüsselung gemäß den obigen Gleichungen
|
||||
\item Dieses Konzept wird in vielen Blockchiffren verwendet und wird als Feistel-Netzwerk bezeichnet
|
||||
\end{itemize*}
|
||||
\item Der DES-Entschlüsselungsprozess ist im Wesentlichen derselbe wie die Verschlüsselung. Er verwendet den Chiffretext als Eingabe für den Verschlüsselungsalgorithmus, wendet aber die Unterschlüssel in umgekehrter Reihenfolge an
|
||||
\item Die Ausgangswerte sind also
|
||||
@ -590,7 +521,6 @@
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsubsection{DES - Sicherheit}
|
||||
\begin{itemize*}
|
||||
\item Schwächen der Schlüssel
|
||||
@ -611,16 +541,16 @@
|
||||
\item Im Jahr 1990 veröffentlichten E. Biham und A. Shamir diese Analysemethode
|
||||
\item Sie sucht gezielt nach Unterschieden in Chiffretexten, deren Klartexte bestimmte Unterschiede aufweisen, und versucht, daraus den richtigen Schlüssel zu erraten
|
||||
\item Der grundlegende Ansatz benötigt einen ausgewählten Klartext zusammen mit seinem Chiffretext
|
||||
\item DES mit 16 Runden ist gegen diesen Angriff immun, da der Angriff $2^{47}$ gewählte Klartexte oder (bei "Umwandlung" in einen Angriff mit bekannten Klartexten) $2^55$ bekannte Klartexte benötigt.
|
||||
\item DES mit 16 Runden ist gegen diesen Angriff immun, da der Angriff $2^{47}$ gewählte Klartexte oder $2^{55}$ bekannte Klartexte benötigt
|
||||
\item Die Entwickler von DES erklärten in den 1990er Jahren, dass sie in den 1970er Jahren über diese Art von Angriffen Bescheid wussten und dass die s-Boxen entsprechend entworfen wurden
|
||||
\end{itemize*}
|
||||
\item Schlüssellänge
|
||||
\begin{itemize*}
|
||||
\item Da ein 56-Bit-Schlüssel in $10,01$ Stunden durchsucht werden kann, wenn man $10^6$ Verschlüsselungen / $\mu s$ durchführen kann (was heute möglich ist), kann DES nicht mehr als ausreichend sicher angesehen werden.
|
||||
\item Da 56-Bit-Schlüssel in $10,01$ Stunden durchsucht werden kann, wenn man $10^6$ Verschlüsselungen/$\mu s$ durchführen kann, kann DES nicht mehr als ausreichend sicher angesehen werden.
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Erweiterung der Schlüssellänge von DES durch Mehrfachverschlüsselung}
|
||||
\subsubsection{Erweiterung der Schlüssellänge von DES}
|
||||
\begin{itemize*}
|
||||
\item Doppelter DES: Da DES nicht geschlossen ist, führt die doppelte Verschlüsselung zu einer Chiffre, die 112-Bit-Schlüssel verwendet
|
||||
\begin{itemize*}
|
||||
@ -635,70 +565,46 @@
|
||||
\end{itemize*}
|
||||
\item Da es für jeden beliebigen Klartext $2^{64}$ mögliche Chiffretext-Werte gibt, die mit Double-DES erzeugt werden könnten, gibt es beim ersten bekannten Klartext/Chiffretext-Paar durchschnittlich $2^{112}/2^{64}=2^{48}$ Fehlalarme.
|
||||
\item Jedes weitere Klartext/Chiffretext-Paar verringert die Chance, einen falschen Schlüssel zu erhalten, um den Faktor $1/2^{64}$, so dass bei zwei bekannten Blöcken die Chance $2^{-16}$ beträgt.
|
||||
\item Der Aufwand, der erforderlich ist, um Double DES zu knacken, liegt also in der Größenordnung von $2^{56}$, was nur geringfügig besser ist als der Aufwand von $2^{55}$, der erforderlich ist, um Single DES mit einem Angriff mit bekanntem Klartext zu knacken, und weit entfernt von den $2^{111}$, die wir von einer Chiffre mit einer Schlüssellänge von 112 Bit erwarten würden!
|
||||
\item Der Aufwand, der erforderlich ist, um Double DES zu knacken, liegt also in der Größenordnung von $2^{56}$, was nur geringfügig besser ist als der Aufwand von $2^{55}$, der erforderlich ist, um Single DES mit einem Angriff mit bekanntem Klartext zu knacken, und weit entfernt von den $2^{111}$, die wir von einer Chiffre mit einer Schlüssellänge von 112 Bit erwarten würden
|
||||
\item Diese Art von Angriff kann durch die Verwendung eines dreifachen Verschlüsselungsschemas umgangen werden, wie es 1979 von W. Tuchman vorgeschlagen wurde
|
||||
\begin{itemize*}
|
||||
\item $C=E(K_3,D(K_2,E(K_1,P)))$
|
||||
\item Die Verwendung der Entschlüsselungsfunktion D in der Mitte ermöglicht die Verwendung von Dreifachverschlüsselungsgeräten mit Gegenstellen, die nur Einfachverschlüsselungsgeräte besitzen, indem $K_1=K_2=K_3$ gesetzt wird.
|
||||
\item Dreifachverschlüsselung kann mit zwei (Einstellung $K_1=K_3$) oder drei verschiedenen Schlüsseln verwendet werden
|
||||
\item Bislang sind keine praktischen Angriffe gegen dieses Verfahren bekannt
|
||||
\item Nachteil: die Leistung beträgt nur $1/3$ der einfachen Verschlüsselung, so dass es besser sein könnte, gleich eine andere Chiffre zu verwenden, die eine größere Schlüssellänge bietet
|
||||
\end{itemize*}
|
||||
\item $C=E(K_3,D(K_2,E(K_1,P)))$
|
||||
\item Die Verwendung der Entschlüsselungsfunktion D in der Mitte ermöglicht die Verwendung von Dreifachverschlüsselungsgeräten mit Gegenstellen, die nur Einfachverschlüsselungsgeräte besitzen, indem $K_1=K_2=K_3$ gesetzt wird.
|
||||
\item Dreifachverschlüsselung kann mit zwei (Einstellung $K_1=K_3$) oder drei verschiedenen Schlüsseln verwendet werden
|
||||
\item Bislang sind keine praktischen Angriffe gegen dieses Verfahren bekannt
|
||||
\item Nachteil: die Leistung beträgt nur $1/3$ der einfachen Verschlüsselung, so dass es besser sein könnte, gleich eine andere Chiffre zu verwenden, die eine größere Schlüssellänge bietet
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Der fortgeschrittene Verschlüsselungsstandard AES}
|
||||
\subsection{fortgeschrittener Verschlüsselungsstandard AES}
|
||||
\begin{itemize*}
|
||||
\item Jan. 1997: Das National Institute of Standards and Technology (NIST)
|
||||
der USA kündigt die Entwicklung des AES an.
|
||||
\item Das übergeordnete Ziel ist die Entwicklung eines Federal Information Processing Standard (FIPS), der einen Verschlüsselungsalgorithmus spezifiziert, der in der Lage ist, sensible Regierungsinformationen bis weit ins nächste Jahrhundert hinein zu schützen.
|
||||
\item Sep. 1997: Offizieller Aufruf zur Einreichung von Algorithmen, offen
|
||||
für jeden auf der Welt
|
||||
\item AES würde einen nicht klassifizierten, öffentlich zugänglichen Verschlüsselungsalgorithmus bzw. -algorithmen spezifizieren, der weltweit lizenzgebührenfrei erhältlich ist.
|
||||
\item Aug. 1998: Erste AES-Kandidatenkonferenz
|
||||
\begin{itemize*}
|
||||
\item NIST gibt die Auswahl von 15 Kandidatenalgorithmen bekannt
|
||||
\item Aufforderung zu öffentlichen Kommentaren
|
||||
\end{itemize*}
|
||||
\item April 1999: Anhand der eingegangenen Analysen und Kommentare wählt das NIST fünf Algorithmen als Kandidaten für die Endauswahl aus: MARS, RC6, Rijndael, Serpent und Twofish
|
||||
\item Oktober 2000: Rijndael wird als Vorschlag des NIST für AES bekannt gegeben
|
||||
\item Rundenbasierte symmetrische Chiffre
|
||||
\item Keine Feistel-Struktur (unterschiedliche Verschlüsselungs- und
|
||||
Entschlüsselungsfunktionen)
|
||||
\item Keine Feistel-Struktur (unterschiedliche Verschlüsselungs- und Entschlüsselungsfunktionen)
|
||||
\item Schlüssellänge: 128, 192, oder 256 Bit
|
||||
\item Blocklänge: 128, 192 oder 256 Bit (nur 128-Bit-Version standardisiert)
|
||||
\item Blocklänge: 128, 192 oder 256 Bit (nur 128 standardisiert)
|
||||
\item Anzahl der Runden: 10, 12, 14
|
||||
\end{itemize*}
|
||||
|
||||
\begin{itemize*}
|
||||
\item Der Algorithmus arbeitet mit
|
||||
\begin{itemize*}
|
||||
\item $state,,4, 4''$: ein Byte-Array mit 4 Zeilen und 4 Spalten (für 128-Bit-Blockgröße)
|
||||
\item $key,,4, 4''$: ein Array mit 4 Zeilen und 4 Spalten (für 128-Bit-Schlüsselgröße)
|
||||
\item $state[4, 4]$: ein Byte-Array mit 4 Zeilen und 4 Spalten (für 128-Bit-Blockgröße)
|
||||
\item $key[4, 4]$: ein Array mit 4 Zeilen und 4 Spalten (für 128-Bit-Schlüsselgröße)
|
||||
\end{itemize*}
|
||||
\item Verschlüsselung: (für eine Block- und Schlüsselgröße von 128 Bit) in
|
||||
den Runden $1-9$ werden vier verschiedene Operationen verwendet
|
||||
\begin{itemize*}
|
||||
\item ByteSub: eine nicht-lineare Byte-Substitution durch eine feste Tabelle (im Grunde eine s-Box)
|
||||
\item ShiftRow: die Zeilen des Zustands werden zyklisch um verschiedene Offsets verschoben
|
||||
\item MixColumn: die Spalten von $state,,''$ werden als Polynome über $GF(2^8)$ betrachtet und modulo $x^4+1$ mit einer festen Matrix multipliziert: $\begin{pmatrix} 02&03&01&01\\ 01&02&03&01 \\ 01&01&02&03\\ 03&01&01&02 \end{pmatrix}$
|
||||
\item RoundKey: ein Round-Key wird mit dem Status XORiert
|
||||
\end{itemize*}
|
||||
\item Round 10 macht keinen Gebrauch von der Operation MixColumn
|
||||
\end{itemize*}
|
||||
|
||||
% \includegraphics[width=\linewidth]{Assets/NetworkSecurity-rijndael-one-round.png}
|
||||
|
||||
\begin{itemize*}
|
||||
\item Verschlüsselung: (für eine Block- und Schlüsselgröße von 128 Bit) in Runden $1-9$ werden vier Operationen verwendet
|
||||
\begin{description*}
|
||||
\item[ByteSub] eine nicht-lineare Byte-Substitution durch eine feste Tabelle (s-Box)
|
||||
\item[ShiftRow] die Zeilen des Zustands werden zyklisch um verschiedene Offsets verschoben
|
||||
\item[MixColumn] die Spalten von $state[]$ werden als Polynome über $GF(2^8)$ betrachtet und modulo $x^4+1$ mit einer festen Matrix multipliziert: $\begin{pmatrix} 02&03&01&01\\ 01&02&03&01 \\ 01&01&02&03\\ 03&01&01&02 \end{pmatrix}$
|
||||
\item[RoundKey] ein Round-Key wird mit dem Status XORiert
|
||||
\item[-] Runde 10 macht keinen Gebrauch von der Operation MixColumn
|
||||
\end{description*}
|
||||
% \includegraphics[width=\linewidth]{Assets/NetworkSecurity-rijndael-one-round.png}
|
||||
\item Entschlüsselung
|
||||
\begin{itemize*}
|
||||
\item Rundenschlüssel und Operationen werden in umgekehrter Reihenfolge angewendet
|
||||
\item Der MixColumn-Schritt kann nur durch Multiplikation mit der inversen Matrix (auch über $GF(2^8)$) invertiert werden
|
||||
\item $\begin{pmatrix} 0e&0b&0d&09\\ 09&0e&0b&0d\\ 0d&09&0e&0b\\ 0b&0d&09&0e \end{pmatrix}$
|
||||
\item Oft werden tabellarische vorberechnete Lösungen verwendet, die aber mehr Platz benötigen
|
||||
\item Oft werden tabellarische vorberechnete Lösungen verwendet, die mehr Platz benötigen
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsubsection{AES - Sicherheit}
|
||||
\begin{itemize*}
|
||||
\item Die einfache mathematische Struktur von AES ist der Hauptgrund für seine Geschwindigkeit, führte aber auch zu Kritik
|
||||
@ -706,108 +612,93 @@
|
||||
\item AES kann als eine große Matrix-Operation beschrieben werden
|
||||
\item Bereits während der Standardisierung wurden Angriffe für reduzierte Versionen entwickelt
|
||||
\begin{itemize*}
|
||||
\item Ein Angriff mit $2^{32}$ gewähltem Klartext gegen eine 7-Runden-Version von AES ,,GM00''
|
||||
\item Ein Angriff mit $2^{32}$ gewähltem Klartext gegen eine 7-Runden-Version von AES
|
||||
\item Signifikante Reduktion der Komplexität auch für eine 9-Runden-Version von AES mit 256-Schlüsselgröße mit einem zugehörigen Schlüsselangriff
|
||||
\end{itemize*}
|
||||
\item 2011 wurde der erste Angriff gegen einen vollständigen AES bekannt ,,BKR11''
|
||||
\item 2011 wurde der erste Angriff gegen vollständigen AES bekannt
|
||||
\begin{itemize*}
|
||||
\item Schlüsselwiederherstellung in $2^{126.1}$ für AES mit 128 Bit, $2^{189.7}$ für AES mit 192 Bit, $2^{254.4}$ für AES mit 256 Bit
|
||||
\item "Praktischer" Angriff (geht nicht von verwandten Schlüsseln aus), aber
|
||||
\item ,,Praktischer,, Angriff (geht nicht von verwandten Schlüsseln aus)
|
||||
\item nur ein kleiner Kratzer in Anbetracht von 10 Jahren kryptographischer Forschung
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{Der Stromchiffre-Algorithmus RC4}
|
||||
\subsection{Stromchiffre-Algorithmus RC4}
|
||||
\begin{itemize*}
|
||||
\item RC4 ist eine Stromchiffre, die 1987 von Ron Rivest erfunden wurde.
|
||||
\item Sie war bis 1994 urheberrechtlich geschützt, als jemand sie anonym in
|
||||
eine Mailingliste einstellte.
|
||||
\item Stromchiffre, die 1987 von Ron Rivest erfunden wurde
|
||||
\item RC4 wird im Output-Feedback-Modus (OFB) betrieben
|
||||
\begin{itemize*}
|
||||
\item Der Verschlüsselungsalgorithmus erzeugt eine Pseudozufallsfolge $RC4(IV,K)$, die nur vom Schlüssel K und einem Initialisierungsvektor IV abhängt
|
||||
\item Der Klartext $P_i$ wird dann mit der Pseudozufallssequenz XOR-verknüpft, um den Chiffretext zu erhalten und umgekehrt
|
||||
\begin{itemize*}
|
||||
\item $C_1 = P_1\oplus RC4 (IV_1,K)$
|
||||
\item $P_1 = C_1\oplus RC4 (IV_1,K)$
|
||||
\end{itemize*}
|
||||
\item Die Pseudo-Zufallsfolge wird oft auch als Keystream bezeichnet
|
||||
\item Entscheidend für die Sicherheit ist, dass der Keystream niemals wiederverwendet wird!
|
||||
\item Wenn der Keystream wiederverwendet wird (d.h. $IV_1=IV_2$ mit demselben $K$), dann kann das XOR zweier Klartexte erhalten werden: $C_1\oplus C_2= P_1\oplus RC4(IV, K)\oplus P_2\oplus RC4(IV,K) = P_1\oplus P_2$
|
||||
\item $C_1 = P_1\oplus RC4 (IV_1,K)$
|
||||
\item $P_1 = C_1\oplus RC4 (IV_1,K)$
|
||||
\end{itemize*}
|
||||
\item Pseudo-Zufallsfolge wird oft als Keystream bezeichnet
|
||||
\item Entscheidend für Sicherheit, dass Keystream niemals wiederverwendet wird
|
||||
\item Wenn der Keystream wiederverwendet wird (d.h. $IV_1=IV_2$ mit demselben $K$), dann kann das XOR zweier Klartexte erhalten werden %$C_1\oplus C_2= P_1\oplus RC4(IV, K)\oplus P_2\oplus RC4(IV,K) = P_1\oplus P_2$
|
||||
\item RC4 verwendet einen Schlüssel variabler Länge bis zu 2048 Bit
|
||||
\item Eigentlich dient der Schlüssel als Seed für einen Pseudo-Zufallsgenerator
|
||||
\item Eig. dient Schlüssel als Seed für Pseudo-Zufallsgenerator
|
||||
\item RC4 arbeitet mit zwei 256-Byte-Arrays: $S,,0,255'', K,,0,255''$
|
||||
\begin{itemize*}
|
||||
\item Schritt 1: Initialisierung der Arrays
|
||||
\begin{enumerate*}
|
||||
\item Initialisierung der Arrays
|
||||
%\begin{Shaded} % \begin{Highlighting}[] % \ControlFlowTok{for}\NormalTok{ (i = }\DecValTok{0}\NormalTok{; i < }\DecValTok{256}\NormalTok{; i++){} % \NormalTok{ S[i] = i; }\CommentTok{// Array S[] mit 0 bis 255 füllen} % \NormalTok{}} % \CommentTok{// Füllen des Arrays K[] mit dem Schlüssel und IV durch Wiederholung, bis K[] gefüllt ist} % \NormalTok{n = }\DecValTok{0}\NormalTok{;} % \ControlFlowTok{for}\NormalTok{ (i =}\DecValTok{0}\NormalTok{; i < }\DecValTok{256}\NormalTok{; i++) {} % \NormalTok{ n = (n + S[i] + K[i]) MOD }\DecValTok{256}\NormalTok{; swap(S[i], S[n]); } % \NormalTok{}} % \end{Highlighting} %\end{Shaded}
|
||||
\item Schritt 2: Erzeugen des Schlüsselstroms (nach Initialisierung $i = 0; n = 0;$)
|
||||
\item Erzeugen des Schlüsselstroms (nach Init $i=0;n=0;$)
|
||||
%\begin{Shaded} % \begin{Highlighting}[] % \NormalTok{i = (i + }\DecValTok{1}\NormalTok{) MOD }\DecValTok{256}\NormalTok{; n = (n + S[i]) MOD }\DecValTok{256}\NormalTok{;} % \NormalTok{swap(S[i], S[n]);} % \NormalTok{t = (S[i] + S[n]) MOD }\DecValTok{256}\NormalTok{;} % \NormalTok{Z = S[t]; }\CommentTok{// Z enthält 8 Bit des durch eine Iteration erzeugten Schlüsselstroms} % \end{Highlighting} %\end{Shaded}
|
||||
\item Schritt 3: XOR-Verknüpfung des Schlüsselstroms mit dem Klartext oder Chiffretext
|
||||
\end{itemize*}
|
||||
\item XOR-Verknüpfung des Schlüsselstroms mit dem Klartext oder Chiffretext
|
||||
\end{enumerate*}
|
||||
\item Sicherheit von RC4
|
||||
\begin{itemize*}
|
||||
\item Sicherheit gegen Brute-Force-Angriffe (Ausprobieren aller möglichen Schlüssel)
|
||||
\item Die variable Schlüssellänge von bis zu 2048 Bit erlaubt es, sie unpraktisch zu machen (zumindest mit den in unserem Universum verfügbaren Ressourcen)
|
||||
\item Allerdings kann RC4 durch Verringerung der Schlüssellänge auch beliebig unsicher gemacht werden!
|
||||
\item RSA Data Security, Inc. behauptet, RC4 sei immun gegen differentielle und lineare Kryptoanalyse, und es seien keine kleinen Zyklen bekannt
|
||||
\item Sicherheit gegen Brute-Force-Angriffe
|
||||
\item variable Schlüssellänge bis 2048 Bit
|
||||
\item durch Verringerung der Schlüssellänge auch beliebig unsicher werden
|
||||
\item RSA Data Security Inc. behauptet, RC4 sei immun gegen differentielle und lineare Kryptoanalyse und es seien keine kleinen Zyklen bekannt
|
||||
\end{itemize*}
|
||||
\item RC4 mit 40-Bit-Schlüsseln hatte einen besonderen Exportstatus, selbst als andere Chiffren nicht aus den USA exportiert werden durften
|
||||
\item RC4 mit 40-Bit-Schlüsseln hatte einen besonderen Exportstatus%, selbst als andere Chiffren nicht aus den USA exportiert werden durften
|
||||
\begin{itemize*}
|
||||
\item Secure Socket Layer (SSL) verwendet RC4 mit 40-Bit-Schlüsseln als Standardalgorithmus
|
||||
\item Die Schlüssellänge von 40 Bit ist nicht immun gegen Brute-Force-Angriffe.
|
||||
\item Schlüssellänge von 40 Bit ist nicht immun gegen Brute-Force
|
||||
\end{itemize*}
|
||||
\item Je nach Schlüsselplanungsmethode kann RC4 jedoch stark verwundbar sein! ,,FMS01a, Riv01a, SIR01a''
|
||||
\item Es wird empfohlen, mindestens die ersten 3072 Bytes des Schlüsselstroms zu verwerfen ,,Mir02, Kle08''
|
||||
\item Sollte eigentlich nicht mehr verwendet werden, auch nicht bei längeren Schlüsseln
|
||||
\item Je nach Schlüsselplanungsmethode kann RC4 stark verwundbar sein
|
||||
\item empfohlen min. erste 3072 Bytes des Schlüsselstroms zu verwerfen
|
||||
\item sollte nicht mehr verwendet werden, auch nicht bei längeren Schlüsseln
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{KASUMI}
|
||||
\begin{itemize*}
|
||||
\item Verwendet zur Verschlüsselung von Anrufen in GSM und UMTS, implementiert f(8) und f(9) (auch A5/3, UEA1, UIA1 genannt)
|
||||
\item Ursprünglich standardisiert durch 3GPP im Jahr 2000 ,,ETS12'' und basierend auf MISTY1 von Mitsubishi
|
||||
\item Entwickelt für Hardware-Implementierung
|
||||
\begin{itemize*}
|
||||
\item Schnelle Implementierung möglich
|
||||
\item $\textless10k$ Gatter
|
||||
\end{itemize*}
|
||||
\item Verwendet zur Verschlüsselung von Anrufen in GSM und UMTS
|
||||
\item Entwickelt für Hardware-Implementierung ($<10k$ Gatter)
|
||||
\item Schnelle Implementierung möglich
|
||||
\item 64-Bit-Blockgröße
|
||||
\item 128-Bit-Schlüssellänge
|
||||
\item 8 Runden Feistel-Netzwerk
|
||||
\item Sicherheitsspanne nicht sehr groß
|
||||
\end{itemize*}
|
||||
|
||||
% \includegraphics[width=\linewidth]{Assets/NetworkSecurity-kasumi-singe-iteration.png}
|
||||
|
||||
\begin{itemize*}
|
||||
\item Die linken 32 Bit der zu verschlüsselnden Daten werden durch zwei nichtlineare Funktionen FO und FL verändert, die beide Schlüsselmaterial verwenden
|
||||
\item Die Reihenfolge, in der FO und FL angewendet werden, hängt von der Rundenzahl ab
|
||||
\item \includegraphics[width=.6\linewidth]{Assets/NetworkSecurity-kasumi-singe-iteration.png}
|
||||
\item linke 32 Bit der zu verschlüsselnden Daten werden durch zwei nichtlineare Funktionen FO und FL verändert, die beide Schlüsselmaterial verwenden
|
||||
\item Reihenfolge, in der FO und FL angewendet werden, hängt von Rundenzahl ab
|
||||
\item FL teilt die Daten in 16-Bit-Wörter auf, die mit Schlüsselmaterial kombiniert, permutiert und mit den Originalwerten XOR-verknüpft werden
|
||||
\item FO ist ein 3-Runden-Feistel-Netzwerk mit einer Modifizierungsfunktion FI, die selbst ein Feistel-ähnliches Netzwerk ist, das zwei s-Boxen verwendet.
|
||||
\item FO ist ein 3-Runden-Feistel-Netzwerk mit einer Modifizierungsfunktion FI, die selbst ein Feistel-ähnliches Netzwerk ist, das zwei s-Boxen verwendet
|
||||
\item Der Ausgang des obigen Schritts wird mit den rechten 32 Bit der Daten XOR-verknüpft, was zu den neuen rechten 32 Bit der Daten führt
|
||||
\item Das neue linke 32-Bit der Daten ist der rechte Wert der vorherigen Iteration
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{KASUMI - Sicherheitsdiskussion}
|
||||
\subsubsection{KASUMI - Sicherheit}
|
||||
\begin{itemize*}
|
||||
\item Eine reduzierte Version von KASUMI (6 Runden) kann durch sogenannte unmögliche differentielle Kryptoanalyse angegriffen werden, bei der unmögliche Zustände der Chiffre aus Chiffretext/Klartext-Paaren abgeleitet werden
|
||||
\item reduzierte Version (6 Runden) kann durch unmögliche differentielle Kryptoanalyse angegriffen werden, bei der unmögliche Zustände der Chiffre aus Chiffretext/Klartext-Paaren abgeleitet werden
|
||||
\begin{itemize*}
|
||||
\item Erste Veröffentlichung bereits ein Jahr nach der Standardisierung
|
||||
\item Zeitkomplexität von $2^{100}$ ,,Kue01''
|
||||
\item Zeitkomplexität von $2^{100}$
|
||||
\end{itemize*}
|
||||
\item Für eine Vollversion von KASUMI sind verwandte Schlüsselangriffe möglich
|
||||
\item Für Vollversion von KASUMI verwandte Schlüsselangriffe möglich
|
||||
\begin{itemize*}
|
||||
\item Ausgewählter Klartextangriff, bei dem der Angreifer dieselben Daten mit mehreren "verwandten" Schlüsseln verschlüsseln kann
|
||||
\item Zeitkomplexität von $2^{76.1}$ ,,BDN05'' und $2^{32}$ im besten Fall ,,DKS10''
|
||||
\item Allerdings sind die Bedingungen, unter denen Angreifer Zugang zu verwandten Schlüsseln in 3G-Netzen haben, sehr selten
|
||||
\item Interessanterweise ist MISTY von diesen Angriffen nicht betroffen!
|
||||
\item Ausgewählter Klartextangriff, bei dem der Angreifer dieselben Daten mit mehreren ,,verwandten'' Schlüsseln verschlüsseln kann
|
||||
\item Zeitkomplexität von $2^{76.1}$ und $2^{32}$ im besten Fall
|
||||
\item Bedingungen, unter denen Angreifer Zugang zu verwandten Schlüsseln in 3G-Netzen haben, sehr selten
|
||||
%\item MISTY von diesen Angriffen nicht betroffen
|
||||
\end{itemize*}
|
||||
\item ETSI hat jedoch SNOW 3G (UEA2 und UIA2) ,,ETS06'' eingeführt, um auf
|
||||
eine vollständige Verletzung von KASUMI vorbereitet zu sein
|
||||
\item ETSI hat jedoch SNOW 3G eingeführt, um auf eine vollständige Verletzung von KASUMI vorbereitet zu sein
|
||||
\begin{itemize*}
|
||||
\item Stromchiffre basierend auf LFSR, kann in 7.500 ASIC-Gattern implementiert werden
|
||||
\item Aber auch anfällig für verwandte Schlüsselangriffe ,,KY11''.
|
||||
\item Stromchiffre basierend auf LFSR, in 7.500 ASIC-Gattern implementiert
|
||||
\item anfällig für verwandte Schlüsselangriffe
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
@ -1116,7 +1007,7 @@
|
||||
\item Für alle $a,b,c\in S$ haben wir ein $\otimes(b\oplus c)=(a\otimes b)\oplus(a\otimes c)$
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\item Wenn $| S|\textless\infty$ dann heißt $(S,\oplus,\otimes)$ ein endliches Feld
|
||||
\item Wenn $| S|<\infty$ dann heißt $(S,\oplus,\otimes)$ ein endliches Feld
|
||||
\end{itemize*}
|
||||
\item Beispiel: $(\mathbb{Z}_p, +_p, \times_p)$ ist ein endliches Feld für jede Primzahl p
|
||||
\item Definition: Primitive Wurzel, Generator
|
||||
@ -1286,7 +1177,7 @@
|
||||
\item Um eine Nachricht m mit dem öffentlichen Schlüssel $(y,g,p)$ zu
|
||||
verschlüsseln:
|
||||
\begin{itemize*}
|
||||
\item Wähle einen zufälligen $k\in\mathbb{Z}^+$ mit $k\textless p-1$
|
||||
\item Wähle einen zufälligen $k\in\mathbb{Z}^+$ mit $k< p-1$
|
||||
\item Berechne $r=g^k\ mod\ p$
|
||||
\item Berechne $s=m\times y^k\ mod\ p$
|
||||
\item Der verschlüsselte Text ist $(r,s)$, der doppelt so lang ist wie m
|
||||
@ -1458,7 +1349,7 @@
|
||||
\end{itemize*}
|
||||
\item Um eine Nachricht zu verschlüsseln:
|
||||
\begin{itemize*}
|
||||
\item Wähle eine zufällige $k\in\mathbb{Z}^+$ mit $k\textless n-1$, berechne $R=kG$
|
||||
\item Wähle eine zufällige $k\in\mathbb{Z}^+$ mit $k< n-1$, berechne $R=kG$
|
||||
\item Berechne $S=M+kY$, wobei M ein von der Nachricht abgeleiteter Punkt ist
|
||||
\begin{itemize*}
|
||||
\item Problem: Die Interpretation der Nachricht m als x-Koordinate von M ist nicht ausreichend, da der y-Wert nicht existieren muss
|
||||
@ -1475,7 +1366,7 @@
|
||||
\end{itemize*}
|
||||
\item Eine Nachricht signieren:
|
||||
\begin{itemize*}
|
||||
\item Wähle ein zufälliges $k\in\mathbb{Z}^+$ mit $k\textless n-1$, berechne $R = kG$
|
||||
\item Wähle ein zufälliges $k\in\mathbb{Z}^+$ mit $k< n-1$, berechne $R = kG$
|
||||
\item Berechne $s=k^{-1}(m+rv) mod\ n$, wobei $r$ der x-Wert von R ist
|
||||
\item Die Signatur ist $(r,s)$, wiederum etwa doppelt so lang wie n
|
||||
\end{itemize*}
|
||||
@ -2101,7 +1992,7 @@
|
||||
\end{itemize*}
|
||||
\item Verteilung
|
||||
\begin{itemize*}
|
||||
\item Die Verteilung einiger anfänglicher Schlüssel muss in der Regel manuell / "out of band" erfolgen
|
||||
\item Die Verteilung 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*}
|
||||
@ -2230,7 +2121,7 @@
|
||||
\item Ausgabe: eine pseudo-zufällige Bitfolge $z_1,z_2,...,z_k$ der Länge k
|
||||
\end{itemize*}
|
||||
\begin{enumerate*}
|
||||
\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 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< e<\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*}
|
||||
@ -3286,7 +3177,7 @@
|
||||
\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 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*}
|
||||
@ -4084,7 +3975,7 @@
|
||||
\begin{itemize*}
|
||||
\item Verschlüsselung: 3DES-CBC, AES und andere CBC-Verschlüsselungsalgorithmen, AES-Zählermodus
|
||||
\item Integrität: HMAC-MD5, HMAC-SHA-1, HMAC-SHA-2, HMAC- RIPEMD-160, AES-GMAC, AES-CMAC, AES-XCBC...
|
||||
\item Authentifizierte Verschlüsselung: GCM und "Zähler mit CBC-MAC" (CCM), beide für AES definiert
|
||||
\item Authentifizierte Verschlüsselung: GCM und ,,Zähler mit CBC-MAC,, (CCM), beide für AES definiert
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\item Eine Sicherheitsassoziation (SA) ist eine Simplex- ,,Verbindung'', die Sicherheitsdienste für den von ihr beförderten Verkehr bereitstellt.
|
||||
@ -4472,7 +4363,7 @@
|
||||
\item Vertraulichkeit (nur ESP):
|
||||
\begin{itemize*}
|
||||
\item Die Verwendung von DES mit ESP ,,RFC4303'' wird nicht mehr empfohlen
|
||||
\item AES-CBC, definiert in RFC 3602, ist vielleicht "der" Standardalgorithmus
|
||||
\item AES-CBC, definiert in RFC 3602, ist vielleicht ,,der,, Standardalgorithmus
|
||||
\item Der Initialisierungsvektor (IV) ist immer im Klartext enthalten, um Synchronisationsprobleme zu vermeiden.
|
||||
\item Der gesamte IV soll zufällig sein
|
||||
\item Nehmen Sie KEINE weiteren IVs aus früheren Chiffretexten!
|
||||
@ -5035,7 +4926,7 @@
|
||||
\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
|
||||
\item NAT ändert die Quelladresse eines jeden Pakets in eine öffentliche IP-Adresse mit anderen (,,umgeschriebenen,,) Quellports
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Probleme mit NAT und IPsec - NAT-Traversal}
|
||||
@ -5602,14 +5493,14 @@
|
||||
% & & ,,ServerCertificate''\tabularnewline
|
||||
% & & ,,CertificateRequest''\tabularnewline
|
||||
% & & ,,ServerKeyExchange''\tabularnewline
|
||||
% & \textless--- & ServerHelloDone\tabularnewline
|
||||
% & <--- & ServerHelloDone\tabularnewline
|
||||
% ,,ClientCertificate'' & & \tabularnewline
|
||||
% ClientKeyExchange & & \tabularnewline
|
||||
% ,,CertificateVerify'' & & \tabularnewline
|
||||
% ChangeCipherSpec & & \tabularnewline
|
||||
% Finished & --->{} & \tabularnewline
|
||||
% & & ChangeCipherSpec\tabularnewline
|
||||
% & \textless--- & Finished\tabularnewline
|
||||
% & <--- & Finished\tabularnewline
|
||||
% \bottomrule
|
||||
%\end{longtable}
|
||||
,,...'' kennzeichnet optionale Nachrichten
|
||||
@ -5623,13 +5514,13 @@
|
||||
% ClientHello(SessionID) & --->{} & \tabularnewline
|
||||
% & & ServerHello(SessionID)\tabularnewline
|
||||
% & & ChangeCipherSpec\tabularnewline
|
||||
% & \textless--- & Finished\tabularnewline
|
||||
% & <--- & 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 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*}
|
||||
|
||||
@ -6081,7 +5972,7 @@
|
||||
\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) |
|
||||
| SSH Client | | SSH Server | | -------------------------------------------------------------------------- | ---- | ---------------------------------------------------- | | ssh\_msg\_channel\_open (,,session'', 20, 2048, 512) | --->{} | | | <--- | 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, ...) | --->{} | | | <--- | ssh\_msg\_channel\_success(20) |
|
||||
,,Nutzdatenaustausch findet ab jetzt statt...''
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
@ -6187,7 +6078,7 @@
|
||||
\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
|
||||
\item Explizite Adressen: Jede Entität, die eine explizite Adresse ,,sieht,,, kann die adressierte Entität bestimmen
|
||||
\end{itemize*}
|
||||
\item Implizite Adressen:
|
||||
\begin{itemize*}
|
||||
@ -6225,9 +6116,9 @@
|
||||
\item Ein Mix verbirgt die Kommunikationsbeziehungen zwischen Absendern und Empfängern:
|
||||
\begin{itemize*}
|
||||
\item Er puffert eingehende Nachrichten, die asymmetrisch verschlüsselt sind, so dass nur der Mix sie entschlüsseln kann.
|
||||
\item Er verändert das "Aussehen" von Nachrichten, indem er sie entschlüsselt
|
||||
\item Er verändert das ,,Aussehen,, von Nachrichten, indem er sie entschlüsselt
|
||||
\item Er ändert die Reihenfolge der Nachrichten und leitet sie in Stapeln weiter.
|
||||
\item Wenn jedoch der Mix kompromittiert wird, kann ein Angreifer "alles" erfahren.
|
||||
\item Wenn jedoch der Mix kompromittiert wird, kann ein Angreifer ,,alles,, erfahren.
|
||||
\end{itemize*}
|
||||
\item Die Sicherheit kann durch kaskadierende Mixe erhöht werden.
|
||||
\item Beispiel: A sendet eine Nachricht m an B über zwei Mixe M1 und M2
|
||||
@ -6235,7 +6126,7 @@
|
||||
\item $A\rightarrow M1: {r_1 ,{r_2 ,{r_3 , m}_{{+K_B}}}{+K_{M2}}}_{{+K}{M1}}$
|
||||
\item $M1\rightarrow M2:{r_2 ,{r_3 , m}_{{+K_B}}}{+K{M2}}$
|
||||
\item $M2\rightarrow B: {r_3 , m}_{+K_B}$
|
||||
\item Es ist wichtig, dass die Mischungen "genug" Nachrichten verarbeiten
|
||||
\item Es ist wichtig, dass die Mischungen ,,genug,, Nachrichten verarbeiten
|
||||
\end{itemize*}
|
||||
\item Dieses Konzept lässt sich auf die mobile Kommunikation übertragen ,,Müller99a''
|
||||
\end{itemize*}
|
||||
@ -6598,7 +6489,7 @@
|
||||
\item $BS STA: (3, r_{BS}, MAC_{KCK}, {TK}_{KEK})$
|
||||
\item $STA BS: (4, r_{STA}, MAC_{KCK})$
|
||||
\end{enumerate*}
|
||||
\item Wobei PMKID den PMK identifiziert: obere 128 Bit von $HMAC-SHA-256(PMK, "PMK Name" || Addr_{BS} || Addr_{STA} )$
|
||||
\item Wobei PMKID den PMK identifiziert: obere 128 Bit von $HMAC-SHA-256(PMK, ,,PMK Name,, || Addr_{BS} || Addr_{STA} )$
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user