diff --git a/Network Security - Cheatsheet.pdf b/Network Security - Cheatsheet.pdf index ea6c76b..a7e1555 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:66c299f18c74f71c283633dc8bf87d99fe06c203296fe5c455d249c7fecc430a -size 713790 +oid sha256:e3cfae058b61418bf5d5ca71741b7321a8ac2263215203404cc6d4bc6f001967 +size 703729 diff --git a/Network Security - Cheatsheet.tex b/Network Security - Cheatsheet.tex index 92bd64a..1277a5d 100644 --- a/Network Security - Cheatsheet.tex +++ b/Network Security - Cheatsheet.tex @@ -127,650 +127,240 @@ \setlength{\columnsep}{2pt} \section{Einleitung} - \subsection{Was ist eine Bedrohung in einem Kommunikationsnetz?} - \begin{itemize*} - \item Abstrakte Definition + \subsection{Sicherheitsziele} + \begin{description*} + \item[Vertraulichkeit] Confidentiality, Anonymität \begin{itemize*} - \item Eine Bedrohung in einem Kommunikationsnetz ist ein mögliches Ereignis oder eine Folge von Aktionen, die zu einer Verletzung eines oder mehrerer Sicherheitsziele führen können. - \item Die tatsächliche Realisierung einer Bedrohung wird als Angriff bezeichnet. + \item nur bestimmtem Personenkreis zugänglich + %\item Die Vertraulichkeit von Entitäten wird auch als Anonymität bezeichnet \end{itemize*} - \item - Beispiele - + \item[Integrität der Daten] Data Integrity \begin{itemize*} - \item Ein Hacker bricht in einen Firmencomputer ein - \item Offenlegung von E-Mails während der Übertragung - \item Jemand ändert Finanzbuchhaltungsdaten - \item Ein Hacker, der eine Website vorübergehend außer Betrieb setzt - \item Jemand, der Dienstleistungen in Anspruch nimmt oder Waren im Namen anderer bestellt + \item jede Veränderung von Daten zu erkennen + %\item Dies setzt voraus, dass der Ersteller bestimmter Daten identifiziert werden kann \end{itemize*} - \item - Was sind Sicherheitsziele? - + \item[Rechenschaftspflicht] Accountability \begin{itemize*} - \item Sicherheitsziele können definiert werden - \item in Abhängigkeit von der Anwendungsumgebung oder - \item auf eine allgemeinere, technische Weise + \item für Kommunikationsereignis verantwortliche Stelle identifizieren \end{itemize*} - \end{itemize*} - - - \subsection{Sicherheitsziele in Abhängigkeit von der - Anwendungsumgebung} - - \begin{itemize*} - \item - Bankwesen - + \item[Verfügbarkeit] Availability \begin{itemize*} - \item Schutz vor betrügerischen oder versehentlichen Änderungen von Transaktionen - \item Identifizierung von Kunden bei Privatkundentransaktionen - \item Schutz von PINs vor Offenlegung - \item Sicherstellung der Privatsphäre der Kunden + \item Dienste sollten verfügbar sein und korrekt funktionieren \end{itemize*} - \item - Elektronischer Handel - + \item[Kontrollierter Zugang] Controlled Access \begin{itemize*} - \item Sicherstellung der Herkunft und Integrität von Transaktionen - \item Schutz der Privatsphäre von Unternehmen - \item Rechtsverbindliche elektronische Signaturen für Transaktionen bereitstellen + \item nur autorisierte Stellen erhalten Zugriff \end{itemize*} - \item - Regierung + \end{description*} + \subsection{Bedrohungen} + \begin{description*} + \item[Maskerade] oder Man-in-the-Middle-Angriff \begin{itemize*} - \item Schutz vor Offenlegung sensibler Informationen - \item Bereitstellung elektronischer Signaturen für Regierungsdokumente + \item Entität gibt sich als eine andere Entität aus \end{itemize*} - \item - Öffentliche Telekommunikationsanbieter - + \item[Lauschangriff] Eavesdropping \begin{itemize*} - \item Beschränken Sie den Zugang zu Verwaltungsfunktionen auf autorisiertes Personal - \item Schutz vor Dienstunterbrechungen - \item Schutz der Privatsphäre der Teilnehmer + \item Entität liest Informationen, die sie nicht lesen soll \end{itemize*} - \item - Firmen-/Privatnetzwerke - + \item[Verletzung der Berechtigung] Authorization Violation \begin{itemize*} - \item Schutz der Privatsphäre von Unternehmen/Personen - \item Sicherstellung der Authentizität von Nachrichten + \item Entität nutzt Dienst, für die sie nicht vorgesehen ist \end{itemize*} - \item - Alle Netzwerke - - \begin{itemize*} - \item Verhinderung des Eindringens von außen (wer will schon Hacker?) - \end{itemize*} - \item - Manchmal werden Sicherheitsziele auch als Sicherheitsvorgaben - bezeichnet - \end{itemize*} - - - \subsection{Sicherheitsziele technisch - definiert} - - \begin{itemize*} - \item - \textbf{Vertraulichkeit (Confidentiality)} - - \begin{itemize*} - \item Übertragene oder gespeicherte Daten sollten nur einem bestimmten Personenkreis zugänglich gemacht werden. - \item Die Vertraulichkeit von Entitäten wird auch als Anonymität bezeichnet. - \end{itemize*} - \item - \textbf{Integrität der Daten (Data Integrity)} - - \begin{itemize*} - \item Es sollte möglich sein, jede Veränderung von Daten zu erkennen. - \item Dies setzt voraus, dass der Ersteller bestimmter Daten identifiziert werden kann. - \end{itemize*} - \item - \textbf{Rechenschaftspflicht (Accountability)} - - \begin{itemize*} - \item Es sollte möglich sein, die für ein Kommunikationsereignis verantwortliche Stelle zu identifizieren. - \end{itemize*} - \item - \textbf{Verfügbarkeit (Availability)} - - \begin{itemize*} - \item Die Dienste sollten verfügbar sein und korrekt funktionieren. - \end{itemize*} - \item - \textbf{Kontrollierter Zugang (Controlled Access)} - - \begin{itemize*} - \item Nur autorisierte Stellen sollten auf bestimmte Dienste oder Informationen zugreifen können. - \end{itemize*} - \end{itemize*} - - - \subsection{Technisch definierte - Bedrohungen} - - \begin{itemize*} - \item - \textbf{Maskerade (oder Man-in-the-Middle-Angriff, Masquerade)} - - \begin{itemize*} - \item Eine Entität gibt sich als eine andere Entität aus - \end{itemize*} - \item - \textbf{Lauschangriff (Eavesdropping)} - - \begin{itemize*} - \item Eine Entität liest Informationen, die sie nicht lesen soll - \end{itemize*} - \item - \textbf{Verletzung der Berechtigung (Authorization Violation)} - - \begin{itemize*} - \item Eine Entität nutzt einen Dienst oder Ressourcen, für die sie nicht vorgesehen ist - \end{itemize*} - \item - \textbf{Verlust oder Veränderung} von (übertragenen) Informationen - (Loss or Modification of (transmitted) Information) - + \item[Verlust oder Veränderung] von (übertragenen) Informationen \begin{itemize*} \item Daten werden verändert oder zerstört \end{itemize*} - \item - \textbf{Verweigerung von Kommunikationsakten (Denial of Communication - Acts, Repudiation)} - + \item[Verweigerung von Kommunikationsakten] Denial of Communication Acts, Repudiation \begin{itemize*} - \item Ein Unternehmen leugnet fälschlicherweise seine Teilnahme an einer Kommunikationshandlung + \item Enität leugnet fälschlicherweise seine Teilnahme %an einer Kommunikationshandlung \end{itemize*} - \item - \textbf{Fälschung von Informationen (Forgery of Information)} - + \item[Fälschung von Informationen] Forgery of Information \begin{itemize*} - \item Ein Unternehmen erstellt neue Informationen im Namen eines anderen Unternehmens + \item Entität erstellt neue Informationen im Namen anderer Entität \end{itemize*} - \item - \textbf{Sabotage (oder Denial-of-Service-Angriffe)} - + \item[Sabotage] oder Denial-of-Service-Angriffe \begin{itemize*} - \item Jede Aktion, die darauf abzielt, die Verfügbarkeit und/oder das ordnungsgemäße Funktionieren von Diensten oder Systemen zu beeinträchtigen. + \item Verfügbarkeit und ordnungsgemäße Funktionieren beeinträchtigen \end{itemize*} + \end{description*} + + \subsection{Analyse der Netzwerksicherheit} + \begin{itemize*} + \item Risikopotenzial der allgemeinen Bedrohungen für nutzenden Einheiten + \item Aufwand (Ressourcen, Zeit...) zur Durchführung bekannter Angriffe + \item Es ist im Allgemeinen unmöglich, unbekannte Angriffe zu bewerten + \item kann besser nach den feinkörnigeren Angriffen auf der Nachrichtenebene strukturiert werden \end{itemize*} - - \subsection{Bedrohungen und technische - Sicherheitsziele} - - Diese Bedrohungen werden oft kombiniert, um einen Angriff durchzuführen! - - %\begin{longtable}[]{@{}llllllll@{}} - % \toprule - % Technische Sicherheitsziele & Maskerade & Abhören & - % Autorisierungsverletzung & Verlust oder Modifikation von (übertragenen) - % Informationen & Denial of Communication-Aktionen & Fälschung von - % Informationen & Sabotage (z.B. durch Überlastung)\tabularnewline - % \midrule - % \endhead - % Vertraulichkeit & x & x & x & & & & \tabularnewline - % Datenintegrität & x & & x & x & x & x & \tabularnewline - % Rechenschaftspflicht & x & & x & & x & x & \tabularnewline - % Verfügbarkeit & x & & x & x & & & x\tabularnewline - % Kontrollierter Zugriff & x & & x & & & x & \tabularnewline - % \bottomrule - %\end{longtable} - - - \subsection{Analyse der - Netzwerksicherheit} - + \subsection{Angriffe auf Nachrichtenebene} \begin{itemize*} - \item - Um geeignete Gegenmaßnahmen gegen Bedrohungen ergreifen zu können, - müssen diese für eine gegebene Netzkonfiguration angemessen bewertet - werden. - \item - Daher ist eine detaillierte Netzsicherheitsanalyse erforderlich, die - + \item Passive Angriffe: Lauschangriff + \item Aktive Angriffe: Verzögerung/Löschen/Einfügen/Modifizieren von PDUs (Protocol Data Units) + \item erfolgreiche Durchführung erfordert \begin{itemize*} - \item das Risikopotenzial der allgemeinen Bedrohungen für die ein Netz nutzenden Einheiten bewertet und - \item den Aufwand (Ressourcen, Zeit usw.) abschätzt, der zur Durchführung bekannter Angriffe erforderlich ist. - \item Achtung! Es ist im Allgemeinen unmöglich, unbekannte Angriffe zu bewerten! - \end{itemize*} - \item - Eine detaillierte Sicherheitsanalyse einer bestimmten - Netzkonfiguration / spezifischen Protokollarchitektur - - \begin{itemize*} - \item kann auch erforderlich sein, um die Finanzkontrolleure eines Unternehmens davon zu überzeugen, Mittel für Sicherheitsverbesserungen bereitzustellen, und - \item kann besser nach den feinkörnigeren Angriffen auf der Nachrichtenebene strukturiert werden. + \item keine erkennbaren Nebeneffekte auf andere Kommunikationen% (Verbindungen/verbindungslose Übertragungen) + \item keine Nebenwirkungen auf andere PDUs der gleichen Verbindung %verbindungslosen Datenübertragung zwischen den gleichen Entitäten \end{itemize*} + %\item Eine Sicherheitsanalyse einer Protokollarchitektur muss diese Angriffe entsprechend den Schichten der Architektur analysieren \end{itemize*} - - \subsection{Angriffe auf die Kommunikation auf der - Nachrichtenebene} - + \subsection{Schutzmaßnahmen der Informationssicherheit} \begin{itemize*} - \item - Passive Angriffe - - \begin{itemize*} - \item Lauschangriff - \end{itemize*} - \item - Aktive Angriffe - - \begin{itemize*} - \item Verzögerung von PDUs (Protocol Data Units) - \item Wiederholung von PDUs - \item Löschung von PDUs - \item Modifikation von PDUs - \item Einfügung von PDUs - \end{itemize*} - \item - Die erfolgreiche Durchführung eines der oben genannten Angriffe - erfordert - - \begin{itemize*} - \item Es gibt keine erkennbaren Nebeneffekte auf andere Kommunikationen (Verbindungen/verbindungslose Übertragungen) - \item Es gibt keine Nebenwirkungen auf andere PDUs der gleichen Verbindung/verbindungslosen Datenübertragung zwischen den gleichen Entitäten - \end{itemize*} - \item - Eine Sicherheitsanalyse einer Protokollarchitektur muss diese Angriffe - entsprechend den Schichten der Architektur analysieren - \end{itemize*} - - - \subsection{Schutzmaßnahmen gegen Bedrohungen der - Informationssicherheit} - - \begin{itemize*} - \item - Physische Sicherheit - + \item Physische Sicherheit \begin{itemize*} \item Schlösser oder andere physische Zugangskontrollen \item Manipulationssicherung empfindlicher Geräte \item Umweltkontrollen \end{itemize*} - \item - Personelle Sicherheit - + \item Personelle Sicherheit \begin{itemize*} \item Identifizierung von sensiblen Positionen \item Verfahren zur Überprüfung der Mitarbeiter \item Sicherheitsschulung und -bewusstsein \end{itemize*} - \item - Administrative Sicherheit - + \item Administrative Sicherheit \begin{itemize*} \item Kontrolle des Imports von Fremdsoftware \item Verfahren zur Untersuchung von Sicherheitsverstößen \item Überprüfung von Prüfpfaden \item Überprüfung von Kontrollen der Rechenschaftspflicht \end{itemize*} - \item - Strahlungssicherheit - + \item Strahlungssicherheit \begin{itemize*} \item Kontrolle von Funkfrequenzen und anderen elektromagnetischen Abstrahlungen \item Bezeichnet als TEMPEST-Schutz \end{itemize*} - \item - Mediensicherheit - + \item Mediensicherheit \begin{itemize*} \item Absicherung der Speicherung von Informationen \item Kontrolle der Kennzeichnung, Vervielfältigung und Vernichtung von sensiblen Informationen \item Sicherstellen, dass Medien mit sensiblen Informationen sicher vernichtet werden \item Scannen von Medien auf Viren \end{itemize*} - \item - Lebenszyklus-Kontrollen - + \item Lebenszyklus-Kontrollen \begin{itemize*} \item Vertrauenswürdiger Systementwurf, -implementierung, -bewertung und -übernahme \item Programmierstandards und -kontrollen \item Kontrollen der Dokumentation \end{itemize*} - \item - Computer-Sicherheit - + \item Computer-Sicherheit \begin{itemize*} \item Schutz von Informationen während der Speicherung/Verarbeitung in einem Computersystem \item Schutz der Datenverarbeitungsgeräte selbst \end{itemize*} - \item - Sicherheit der Kommunikation - + \item Sicherheit der Kommunikation \begin{itemize*} \item Schutz von Informationen während des Transports von einem System zu einem anderen \item Schutz der Kommunikationsinfrastruktur selbst \end{itemize*} \end{itemize*} - - \subsection{Kommunikationssicherheit: Einige - Terminologie} - + \subsection{Kommunikationssicherheit} \begin{itemize*} - \item - Sicherheitsdienst - + \item Sicherheitsdienst \begin{itemize*} - \item Ein abstrakter Dienst, der eine bestimmte Sicherheitseigenschaft gewährleisten soll. - \item Ein Sicherheitsdienst kann sowohl mit Hilfe von kryptografischen Algorithmen und Protokollen als auch mit herkömmlichen Mitteln realisiert werden - \begin{itemize*} \item Man kann ein elektronisches Dokument auf einem USB-Stick vertraulich halten, indem man es in einem verschlüsselten Format auf dem Datenträger speichert und den Datenträger in einem Tresor wegschließt. \item In der Regel ist eine Kombination aus kryptografischen und anderen Mitteln am effektivsten \end{itemize*} + \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 - + \item Kryptographischer Algorithmus \begin{itemize*} - \item Eine mathematische Umwandlung von Eingabedaten (z. B. Daten, Schlüssel) in Ausgabedaten - \item Kryptografische Algorithmen werden in kryptografischen Protokollen verwendet. - \end{itemize*} - \item - Kryptografisches Protokoll - - \begin{itemize*} - \item Eine Reihe von Schritten und der Austausch von Nachrichten zwischen mehreren Einheiten, um ein bestimmtes Sicherheitsziel zu erreichen + \item mathematische Umwandlung von Eingabedaten in Ausgabedaten + \item krypt. Algorithmen werden in krypt. Protokollen verwendet \end{itemize*} + \item Kryptografisches Protokoll: Reihe von Schritten und Austausch von Nachrichten %zwischen mehreren Einheiten, um ein bestimmtes Sicherheitsziel zu erreichen \end{itemize*} - - \subsection{Sicherheitsdienste - - Überblick} - - \begin{itemize*} - \item - \textbf{Authentifizierung (Authentication)} - + \subsection{Sicherheitsdienste - Überblick} + \begin{description*} + \item[Authentifizierung] Authentication \begin{itemize*} - \item Der grundlegendste Sicherheitsdienst, der sicherstellt, dass eine Entität tatsächlich die Identität besitzt, die sie vorgibt zu haben + \item grundlegendste Sicherheitsdienst, + \item Entität besitzt Identität, die sie vorgibt zu haben \end{itemize*} - \item - \textbf{Integrität (Integrity)} - + \item[Integrität] Integrity \begin{itemize*} - \item In gewisser Weise der "kleine Bruder" des Authentifizierungsdienstes, da er sicherstellt, dass Daten, die von bestimmten Entitäten erstellt wurden, nicht unentdeckt verändert werden können + \item Daten nicht unentdeckt verändern können \end{itemize*} - \item - \textbf{Vertraulichkeit (Confidentiality)} - + \item[Vertraulichkeit] Confidentiality \begin{itemize*} - \item Der beliebteste Sicherheitsdienst, der die Geheimhaltung der geschützten Daten gewährleistet + \item Geheimhaltung geschützter Daten \end{itemize*} - \item - \textbf{Zugriffskontrolle (Access Control)} - + \item[Zugriffskontrolle] Access Control \begin{itemize*} - \item Kontrolliert, dass jede Identität nur auf die Dienste und Informationen zugreift, zu denen sie berechtigt ist + \item Zugriff auf Dienste/Information nur mit Berechtigung %Kontrolliert, dass jede Identität nur auf die Dienste und Informationen zugreift, zu denen sie berechtigt ist \end{itemize*} - \item - \textbf{Nicht-Abstreitbarkeit (Non Repudiation)} + \item[Nicht-Abstreitbarkeit] Non Repudiation %Schützt davor, dass an einem Kommunikationsaustausch beteiligte Entitäten später fälschlicherweise abstreiten können, dass der Austausch stattgefunden hat + \end{description*} - \begin{itemize*} - \item Schützt davor, dass an einem Kommunikationsaustausch beteiligte Entitäten später fälschlicherweise abstreiten können, dass der Austausch stattgefunden hat - \end{itemize*} - \end{itemize*} + \subsection{Sicherheitsunterstützende Mechanismen} + \begin{description*} + \item[Schlüsselverwaltung] Alle Aspekte des Lebenszyklus von kryptografischen Schlüsseln + \item[Zufallszahlengenerierung] Generierung von kryptographisch sicheren Zufallszahlen + \item[Ereigniserkennung/Sicherheitsprüfpfad] Erkennung und Aufzeichnung von Ereignissen, die zur Erkennung von Angriffen oder Bedingungen, die von Angriffen ausgenutzt werden könnten, verwendet werden können + \item[Erkennung von Eindringlingen] Analyse der aufgezeichneten Sicherheitsdaten, um erfolgreiche Einbrüche oder Angriffe zu erkennen + \item[Beglaubigung] Registrierung von Daten durch eine vertrauenswürdige dritte Partei, die später bestimmte Eigenschaften 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 + \end{description*} - \subsection{Sicherheitsunterstützende - Mechanismen} - - \begin{itemize*} - \item - Allgemeine Mechanismen - - \begin{itemize*} - \item Schlüsselverwaltung: Alle Aspekte des Lebenszyklus von kryptografischen Schlüsseln - \item Zufallszahlengenerierung: Generierung von kryptographisch sicheren Zufallszahlen - \item Ereigniserkennung / Sicherheitsprüfpfad: Erkennung und Aufzeichnung von Ereignissen, die zur Erkennung von Angriffen oder Bedingungen, die von Angriffen ausgenutzt werden könnten, verwendet werden können - \item Erkennung von Eindringlingen: Analyse der aufgezeichneten Sicherheitsdaten, um erfolgreiche Einbrüche oder Angriffe zu erkennen - \item Beglaubigung: Registrierung von Daten durch eine vertrauenswürdige dritte Partei, die später bestimmte Eigenschaften (Inhalt, Ersteller, Erstellungszeitpunkt) der Daten bestätigen kann - \end{itemize*} - \item - Kommunikationsspezifische Mechanismen - - \begin{itemize*} - \item Traffic Padding \& Cover Traffic: Erzeugung von gefälschtem Verkehr, um die Analyse des Verkehrsflusses zu verhindern - \item Routing-Kontrolle: Beeinflussung des Routings von PDUs in einem Netzwerk - \end{itemize*} - \end{itemize*} - - - \subsection{Kryptologie - Definition und - Terminologie} - - \begin{itemize*} - \item - Kryptologie - - \begin{itemize*} + \subsection{Kryptologie} + \begin{description*} \item Wissenschaft, die sich mit sicherer und meist geheimer Kommunikation beschäftigt - \item Der Begriff leitet sich von den griechischen Wörtern kryptós (verborgen) und lógos (Wort) ab. - \item Kryptologie umfasst - \begin{itemize*} \item Kryptographie ( gráphein = schreiben): die Lehre von den Prinzipien und Techniken, mit denen Informationen in verschlüsseltem Text verborgen und später von legitimen Nutzern mit Hilfe eines geheimen Schlüssels offengelegt werden können \item Kryptoanalyse ( analýein = lýsen, losbinden): die Wissenschaft (und Kunst) der Wiedergewinnung von Informationen aus Chiffren ohne Kenntnis des Schlýssels \end{itemize*} - \end{itemize*} - \item - Chiffre (Quelle Encyclopaedia Britannica) - - \begin{itemize*} - \item Methode zur Umwandlung einer Nachricht (Klartext), um ihre Bedeutung zu verschleiern - \item Wird auch als Synonym für den verborgenen Chiffretext verwendet. - \item Chiffren sind eine Klasse von kryptografischen Algorithmen - \item Die Umwandlung erfolgt in der Regel mit der Nachricht und einem (geheimen) Schlüssel als Eingabe - \end{itemize*} - \end{itemize*} - - - \subsection{Kryptologie - einige historische - Anmerkungen} - - \begin{itemize*} - \item - 400 v. Chr.: Die Spartaner verwenden ein Chiffriergerät namens Scytale - für die Kommunikation zwischen militärischen Befehlshabern. - - \begin{itemize*} - \item Die Scytale bestand aus einem spitz zulaufenden Stab, um den spiralförmig ein Streifen Pergament oder Leder gewickelt war, auf den die Nachricht geschrieben wurde - \item Beim Aufwickeln wurden die Buchstaben der Reihe nach durcheinander gewürfelt und bildeten die Chiffre. - \item Wurde der Streifen um einen anderen Stab mit den gleichen Proportionen wie das Original gewickelt, kam der Klartext wieder zum Vorschein - \end{itemize*} - \item - Im 4. Jahrhundert v. Chr: - - \begin{itemize*} - \item Aeneas Tacticus (Grieche) schreibt "Über die Verteidigung von Festungen", wobei ein Kapitel der Kryptographie gewidmet ist - \item Polybius (Grieche) erfindet eine Methode zur Kodierung von Buchstaben in Symbolpaaren mit Hilfe eines Geräts namens Polybius-Schachbrett, das eine bi-literale Substitution ermöglicht und viele Elemente späterer Kryptosysteme vorwegnimmt - \end{itemize*} - \item - Die Römer verwendeten eine monoalphabetische Substitution mit - einfacher zyklischer Verschiebung des Alphabets: - - \begin{itemize*} - \item Julius Caesar verwendete eine Verschiebung von drei Buchstaben (A ergibt D, ..., Z ergibt C) - \item Augustus Caesar verwendete eine einzige Verschiebung (A ergibt B, ...) - \end{itemize*} - \item - Die Araber waren die ersten, die die Prinzipien der Kryptographie - verstanden und die Anfänge der Kryptoanalyse entdeckten: - - \begin{itemize*} - \item Entwurf und Verwendung von Substitutions- und Transpositions-Chiffren - \item Entdeckung der Verwendung von Buchstabenhäufigkeitsverteilungen und wahrscheinlichen Klartexten in der Kryptoanalyse - \item Bis 1412 n. Chr. enthält Al-Kalka-Shandi in seiner Enzyklopädie Subh al-a'sha eine elementare und respektable Behandlung mehrerer kryptographischer Systeme und ihrer Kryptoanalyse - \end{itemize*} - \item - Europäische Kryptographie: - - \begin{itemize*} - \item Die Entwicklung begann im Kirchenstaat und in den italienischen Stadtstaaten im Mittelalter - \item Die ersten Chiffren verwendeten nur Vokalsubstitutionen - \item 1397: Gabriele de Lavinde von Parma verfasst das erste europäische Handbuch zur Kryptographie, das eine Zusammenstellung von Chiffren sowie eine Reihe von Schlüsseln für 24 Korrespondenten enthält und Symbole für Buchstaben, Zahlen und mehrere zweistellige Codeäquivalente für Wörter und Namen umfasst - \item Code-Vokabulare, Nomenklatoren genannt, wurden für mehrere Jahrhunderte zur Hauptstütze der diplomatischen Kommunikation der meisten europäischen Regierungen - \item 1470: Leon Battista Alberti veröffentlicht Trattati In Cifra, in denen er die erste Chiffrierscheibe beschreibt und bereits vorschreibt, die Scheibe regelmäßig neu einzustellen, wobei er den Begriff der Polyalphabetizität entwickelt - \item 1563: Giambattista della Porta liefert eine abgewandelte Form einer quadratischen Tabelle und das früheste Beispiel einer digraphischen Chiffre (2-Buchstaben-Substitution) - \item 1586: Blaise de Vigenère veröffentlicht Traicté des chiffres, das die ihm zugeschriebene quadratische Tabelle enthält - \item Bis 1860 wurden große Codes für die diplomatische Kommunikation verwendet, und Chiffren wurden nur in der militärischen Kommunikation eingesetzt (außer auf hoher Kommandoebene), da es schwierig war, Codebücher im Feld zu schützen. - \end{itemize*} - \item - Entwicklungen während der Weltkriege 1 und 2: - - \begin{itemize*} - \item Während des 1. Weltkriegs: Chiffriersysteme wurden hauptsächlich für die taktische Kommunikation verwendet und die Kommunikation auf hoher Ebene wurde durch Codes geschützt. - \item 1920: Die Kommunikationsbedürfnisse der Telekommunikation und die Weiterentwicklung der elektromechanischen Technik führen zu einer wahren Revolution bei den Verschlüsselungsgeräten - der Entwicklung von Rotor-Chiffriermaschinen: - \begin{itemize*} \item Das Rotorprinzip wird unabhängig voneinander von E. E. Hebern (USA), H. A. Koch (Niederlande) und A. Scherbius (Deutschland) entdeckt \item Rotor-Chiffriermaschinen kaskadieren eine Sammlung von Chiffrierscheiben, um eine polyalphabetische Substitution von hoher Komplexität zu realisieren \item Die Kryptoanalyse der taktischen Kommunikation spielt während des Zweiten Weltkriegs eine sehr wichtige Rolle. Die größten Erfolge sind die britische und polnische Lösung der deutschen Enigma- und der beiden Fernschreiber-Chiffren sowie die amerikanische Kryptoanalyse der japanischen Chiffren. \end{itemize*} - \end{itemize*} - \item - Entwicklungen nach dem 2. Weltkrieg: - - \begin{itemize*} - \item Die moderne Elektronik ermöglicht noch komplexere Chiffren, die zunächst den Rotorprinzipien folgen (und deren Schwächen einbeziehen) - \item Die meisten Informationen über elektronische Chiffriermaschinen, die von verschiedenen nationalen Kryptodiensten verwendet wurden, sind nicht öffentlich zugänglich. - \item Ende der 1960er Jahre war die kommerziell verfügbare Kryptographie kaum bekannt, und starke Kryptographie war den nationalen Behörden vorbehalten - \item 1973-1977: Entwicklung des Data Encryption Standard (DES) - \item 1976-1978: Entdeckung der Public-Key-Kryptografie - \item 1976: W. Diffie und M. Hellman veröffentlichen "New Directions in Cryptography" (Neue Wege in der Kryptographie), in dem sie die Konzepte der Public-Key-Kryptographie einführen und ein Verfahren zum Austausch von Schlüsseln über unsichere Kanäle beschreiben. - \item R. Merkle entdeckt unabhängig das Prinzip des öffentlichen Schlüssels, seine ersten Veröffentlichungen erscheinen jedoch erst 1978, da der Veröffentlichungsprozess langsam ist - \item 1978: R. L. Rivest, A. Shamir und A. M. Adleman veröffentlichen "A Method for Obtaining Digital Signatures and Public Key Cryptosystems", das den ersten funktionierenden und sicheren Public-Key-Algorithmus RSA enthält - \end{itemize*} - \end{itemize*} - - - \section{Grundlagen der - Kryptographie} - - \begin{itemize*} - \item - Überblick über kryptografische Algorithmen - \item - Angriffe auf die Kryptographie - \item - Eigenschaften von Verschlüsselungsalgorithmen - \item - Klassifizierung von Verschlüsselungsalgorithmen - \end{itemize*} - - - \subsection{Kryptographische Algorithmen: - Überblick} - - \begin{itemize*} - \item - In diesem Kurs stehen zwei Hauptanwendungen kryptographischer - Algorithmen im Mittelpunkt des Interesses - - \begin{itemize*} - \item Verschlüsselung von Daten: Umwandlung von Klartextdaten in Chiffretext, um deren Bedeutung zu verbergen - \item Signierung von Daten: Berechnung eines Prüfwerts oder einer digitalen Signatur für einen gegebenen Klartext oder Geheimtext, der von einigen oder allen Stellen, die auf die signierten Daten zugreifen können, überprüft werden kann - \end{itemize*} - \item - Einige kryptografische Algorithmen können für beide Zwecke verwendet - werden, andere sind nur für einen der beiden Zwecke sicher und/oder - effizient. - \item - Hauptkategorien von kryptografischen Algorithmen - - \begin{itemize*} - \item Symmetrische Kryptografie, die 1 Schlüssel für die Ver-/Entschlüsselung oder die Signierung/Prüfung verwendet - \item Asymmetrische Kryptografie mit 2 verschiedenen Schlüsseln für die Ver-/Entschlüsselung oder die Unterzeichnung/Prüfung - \item Kryptografische Hash-Funktionen mit 0 Schlüsseln (der "Schlüssel" ist keine separate Eingabe, sondern wird an die Daten "angehängt" oder mit ihnen "vermischt"). - \end{itemize*} - \end{itemize*} - - - \subsection{Angriff auf die - Kryptographie} - + \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[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") + \end{description*} \subsection{Kryptoanalyse} - \begin{itemize*} - \item - Kryptoanalyse ist der Versuch, den Klartext und/oder den Schlüssel - herauszufinden. - \item - Arten der Kryptoanalyse - + \item Arten der Kryptoanalyse \begin{itemize*} - \item Nur Chiffretext: bestimmte Muster des Klartextes können im Chiffretext erhalten bleiben (Häufigkeit von Buchstaben, Digraphen usw.) + \item Nur Chiffretext: bestimmte Muster können im Chiffretext erhalten bleiben \item Bekannte Chiffretext-Klartext-Paare \item Gewählter Klartext oder gewählter Chiffretext \item Differentielle Kryptoanalyse und lineare Kryptoanalyse \item Neuere Entwicklung: verwandte Schlüsselanalyse \end{itemize*} - \item - Kryptoanalyse der Public-Key-Kryptographie - + \item Kryptoanalyse der Public-Key-Kryptographie \begin{itemize*} - \item Die Tatsache, dass ein Schlüssel öffentlich zugänglich ist, kann ausgenutzt werden - \item Die Kryptoanalyse öffentlicher Schlüssel zielt eher darauf ab, das Kryptosystem selbst zu knacken und ist näher an der reinen mathematischen Forschung als an der klassischen Kryptoanalyse. - \item Wichtige Richtungen - \begin{itemize*} \item Berechnung von diskreten Logarithmen \item Faktorisierung von großen ganzen Zahlen \end{itemize*} + \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 Berechnung von diskreten Logarithmen + \item Faktorisierung von großen ganzen Zahlen \end{itemize*} \end{itemize*} - \subsubsection{Brute-Force-Angriff} - \begin{itemize*} - \item - Der Brute-Force-Angriff probiert alle möglichen Schlüssel aus, bis er - einen verständlichen Klartext findet - - \begin{itemize*} + \item 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 - \end{itemize*} \end{itemize*} - Durchschnittlich benötigte Zeit für erschöpfende Schlüsselsuche - - %\begin{longtable}[]{@{}llll@{}} - % \toprule - % Schlüsselgröße {[}bit{]} & Anzahl der Schlüssel & Benötigte Zeit bei 1 - % \$Verschlüsselung/\textbackslash mu\$s & Zeitbedarf bei 10\^{}6 - % Verschlüsselung /\$\textbackslash mu\$s\tabularnewline - % \midrule - % \endhead - % 56 & \$2\^{}\{56\} = 7,2\textbackslash times 10\^{}\{16\}\$ & - % \$2\^{}\{55\}\textbackslash mu s = 1142\$ Jahre & \$10,01\$ - % Stunden\tabularnewline - % 128 & \$2\^{}\{128\} = 3,4 x 10\^{}\{38\}\$ & - % \$2\^{}\{127\}\textbackslash mu s = 5,4 x 10\^{}\{24\}\$ Jahre & \$5,4 x - % 10\^{}\{18\}\$ Jahre\tabularnewline - % 256 & \$2\^{}\{256\} = 1.2 x 10\^{}\{77\} & - % \$2\^{}\{255\}\textbackslash mu s = 3,7 x 10\^{}\{63\}\$ Jahre & \$3,7 x - % 10\^{}\{57\}\$ Jahre\tabularnewline - % \bottomrule - %\end{longtable} - - \subsubsection{Wie groß ist groß?} - - Referenzzahlen zum Vergleich relativer Größenordnungen \textbar{} - Referenz \textbar{} Größe \textbar{} \textbar{} - -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- - \textbar{} - -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- - \textbar{} \textbar{} Sekunden in einem Jahr \textbar{} ca. \$3 x - 10\^{}7\$ \textbar{} \textbar{} Sekunden seit der Entstehung des - Sonnensystems \textbar{} ca. \$2 x 10\^{}\{17\}\$ \textbar{} \textbar{} - Taktzyklen pro Jahr (50 MHz Computer) \textbar{} ca. \$1,6 x - 10\^{}\{15\}\$ \textbar{} \textbar{} Binäre Zeichenketten der Länge 64 - \textbar{} \$2\^{}\{64\}\$ ca. \$1,8 x 10\^{}\{19\}\$ \textbar{} - \textbar{} Binäre Zeichenfolgen der Länge 128 \textbar{} - \$2\^{}\{128\}\$ ca. \$3,4 x 10\^{}\{38\}\$ \textbar{} \textbar{} Binäre - Zeichenfolgen der Länge 256 \textbar{} \$2\^{}\{256\}\$ ca. \$1,2 x - 10\^{}\{77\}\$ \textbar{} \textbar{} Anzahl der 75-stelligen Primzahlen - \textbar{} \$5,2 x 10\^{}\{72\}\$ \textbar{} \textbar{} Elektronen im - Universum \textbar{} \$8,37 x 10\^{}\{77\}\$ \textbar{} - + Referenzzahlen zum Vergleich relativer Größenordnungen + \begin{tabular}{l|l} + Referenz & Größe \\ + Sekunden in einem Jahr & ca. \$3 x10\^{}7\$ \\ + Taktzyklen pro Jahr (50 MHz Computer) & ca. \$1,6 x10\^{}\{15\}\$ \\ + Binäre Zeichenketten der Länge 64& \$2\^{}\{64\}\$ ca. \$1,8 x 10\^{}\{19\}\$ \\ + Binäre Zeichenfolgen der Länge 128 & \$2\^{}\{128\}\$ ca. \$3,4 x 10\^{}\{38\}\$ \\ + Binäre Zeichenfolgen der Länge 256 & \$2\^{}\{256\}\$ ca. \$1,2 x 10\^{}\{77\}\$ \\ + Anzahl der 75-stelligen Primzahlen & \$5,2 x 10\^{}\{72\}\$ \\ + Elektronen im Universum & \$8,37 x 10\^{}\{77\}\$ + \end{tabular} \subsubsection{Wichtige Eigenschaften von Verschlüsselungsalgorithmen} @@ -782,18 +372,14 @@ von besonderem Interesse \begin{itemize*} - \item - Die Fehlerfortpflanzung charakterisiert die Auswirkungen von + \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 + \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. @@ -805,24 +391,18 @@ Dimensionen} \begin{itemize*} - \item - Die Art der Operationen, die zur Umwandlung von Klartext in + \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 - + \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 - + \item Die Art und Weise, in der der Klartext verarbeitet wird \begin{itemize*} \item Stromchiffren arbeiten mit Bitströmen und verschlüsseln ein Bit nach dem anderen \begin{itemize*} \item Viele Stromchiffren basieren auf der Idee der linearen rückgekoppelten Schieberegister, und bei vielen Algorithmen dieser Klasse wurden Schwachstellen entdeckt, da es eine tiefgreifende mathematische Theorie zu diesem Thema gibt. \item Die meisten Stromchiffren verbreiten keine Fehler, sind aber anfällig für den Verlust der Synchronisation. \end{itemize*} @@ -837,16 +417,12 @@ Kryptografische Algorithmen \begin{itemize*} - \item - Überblick - + \item Überblick \begin{itemize*} \item Eigenschaften \item Kryptoanalyse \end{itemize*} - \item - Symmetrische Ver-/Entschlüsselung - + \item Symmetrische Ver-/Entschlüsselung \begin{itemize*} \item Funktionsweisen \item DES @@ -854,9 +430,7 @@ \item RC4 \item KASUMI \end{itemize*} - \item - Asymmetrische Ver-/Entschlüsselung - + \item Asymmetrische Ver-/Entschlüsselung \begin{itemize*} \item Hintergrund \item RSA @@ -864,9 +438,7 @@ \item ElGamal \item ECC \end{itemize*} - \item - Kryptographische Hash-Funktionen - + \item Kryptographische Hash-Funktionen \begin{itemize*} \item MDCs/MACs \item MD @@ -880,16 +452,11 @@ \section{Symmetrische Kryptographie} \begin{itemize*} - \item - Modi der Verschlüsselung - \item - Datenverschlüsselungsstandard (DES) - \item - Erweiterter Verschlüsselungsstandard (AES) - \item - Die Blockchiffre RC - \item - KASUMI + \item Modi der Verschlüsselung + \item Datenverschlüsselungsstandard (DES) + \item Erweiterter Verschlüsselungsstandard (AES) + \item Die Blockchiffre RC + \item KASUMI \end{itemize*} @@ -897,21 +464,16 @@ Verschlüsselung} \begin{itemize*} - \item - Allgemeine Beschreibung - + \item Allgemeine Beschreibung \begin{itemize*} \item Derselbe Schlüssel KA,B wird für die Verschlüsselung und Entschlüsselung von Nachrichten verwendet \end{itemize*} - \item - Schreibweise - + \item Schreibweise \begin{itemize*} \item Wenn P die Klartextnachricht bezeichnet, bezeichnet \$E(K\_\{A,B\}, P)\$ den Chiffretext und es gilt \$D(K\_\{A,B\}, E(K\_\{A,B\}, P)) = P\$ \item Alternativ schreibt man manchmal \$\{P\}\emph{\{K}\{A,B\}\}\$ oder \$E\_\{K\_\{A,B\}\}(P)\$ für \$E(K\_\{A,B\}, P)\$ \end{itemize*} - \item - Beispiele: DES, 3DES, AES, ... + \item Beispiele: DES, 3DES, AES, ... \end{itemize*} @@ -921,35 +483,28 @@ Allgemeine Bemerkungen \& Notation \begin{itemize*} - \item - Ein Klartext P wird in Blöcke \$P\_1, P\_2, ...\$ der Länge b bzw. j + \item Ein Klartext P wird in Blöcke \$P\_1, P\_2, ...\$ der Länge b bzw. j zerlegt, wobei b die Blockgröße des Verschlüsselungsalgorithmus bezeichnet und j \textless{} b - \item - Der Chiffretext C ist die Kombination von \$C\_1, C\_2, ...\$, wobei + \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 + \item Die Stellen, die eine Nachricht verschlüsseln und entschlüsseln, haben sich auf einen Schlüssel K geeinigt. \end{itemize*} Elektronischer Codebuch-Modus (Electronic Code Book Mode: ECB) \begin{itemize*} - \item - Jeder Block Pi der Länge b wird unabhängig verschlüsselt: \$C\_i = + \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 + \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 + \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 + \item Nachteil: identische Klartextblöcke werden zu identischem Chiffretext verschlüsselt! %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-electronic-code-book-mode.png} \end{itemize*} @@ -957,18 +512,14 @@ Cipher Block Chaining Modus (Cipher Block Chaining Mode: CBC) \begin{itemize*} - \item - Vor der Verschlüsselung eines Klartextblocks pi wird dieser mit dem + \item Vor der Verschlüsselung eines Klartextblocks pi wird dieser mit dem vorangegangenen Chiffretextblock \$C\_\{i-1\}\$ XOR-verknüpft () - \begin{itemize*} \item \$C\_i = E(K, C\_\{i-1\} \textbackslash oplus p\_i)\$ \item \$P\_\{i'\} = C\_\{i-1\} \textbackslash oplus D(K, C\_i)\$ \item Um \$C\_1\$ zu berechnen, einigen sich beide Parteien auf einen Anfangswert (IV) für \$C\_0\$ \end{itemize*} - \item - Eigenschaften - + \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. @@ -980,11 +531,9 @@ Chiffretext-Feedback-Modus (Ciphertext Feedback Mode: CFB) \begin{itemize*} - \item - Ein Blockverschlüsselungsalgorithmus, der mit Blöcken der Größe b + \item Ein Blockverschlüsselungsalgorithmus, der mit Blöcken der Größe b arbeitet, kann in einen Algorithmus umgewandelt werden, der mit Blöcken der Größe \$j (j\textless b)\$ arbeitet. - \begin{itemize*} \item \$S(j, x)\$ bezeichnen die \$j\$ höherwertigen Bits von \$x\$ \item \$P\_i\$, \$C\_i\$ den \$i\$-ten Block von Klartext und Geheimtext der Länge \$j\$ bezeichnen @@ -995,12 +544,9 @@ \item \$S(j,E\_K(R\_n))\textbackslash oplus C\_n = S(j,E\_K(R\_n))\textbackslash oplus S(j,E\_K(R\_n))\textbackslash oplus P\_n\$ \item \$S(j,E\_K(R\_n))\textbackslash oplus C\_n = P\_n\$ \end{itemize*} - \item - Ein gängiger Wert für j ist 8 für die Verschlüsselung von einem + \item Ein gängiger Wert für j ist 8 für die Verschlüsselung von einem Zeichen pro Schritt - \item - Eigenschaften von CFB - + \item Eigenschaften von CFB \begin{itemize*} \item Fehlerfortpflanzung: Da die Chiffretextblöcke schrittweise durch das Register geschoben werden, verfälscht ein fehlerhafter Block \$C\_i\$ den wiederhergestellten Klartextblock \$P\_i'\$ sowie die folgenden \$\textbackslash lceil b / j\textbackslash rceil\$-Blöcke \item Synchronisation: Wenn die Anzahl der verlorenen Bits ein ganzzahliges Vielfaches von j ist, werden \$\textbackslash lceil b / j\textbackslash rceil\$ zusätzliche Blöcke verfälscht, bevor die Synchronisation wiederhergestellt ist. Wenn eine beliebige andere Anzahl von Bits verloren geht, ist eine explizite Neusynchronisierung erforderlich. @@ -1011,11 +557,9 @@ Output-Feedback-Modus (OFB) \begin{itemize*} - \item - Der Blockverschlüsselungsalgorithmus wird zur Erzeugung einer + \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\$ @@ -1026,12 +570,9 @@ \item \$S(j,E\_K(R\_n))\textbackslash oplus C\_n = S(j,E\_K(R\_n))\textbackslash oplus S(j,E\_K(R\_n))\textbackslash oplus P\_n\$ \item \$S(j,E\_K(R\_n))\textbackslash oplus C\_n = P\_n\$ \end{itemize*} - \item - Der Klartext wird mit der Pseudo-Zufallssequenz XOR-verknüpft, um den + \item Der Klartext wird mit der Pseudo-Zufallssequenz XOR-verknüpft, um den Chiffretext zu erhalten und umgekehrt - \item - Eigenschaften von OFB - + \item Eigenschaften von OFB \begin{itemize*} \item Fehlerfortpflanzung: Einzelbitfehler führen nur zu Einzelbitfehlern \$\textbackslash rightarrow\$ keine Fehlermultiplikation \item Synchronisierung: Wenn einige Bits verloren gehen, ist eine explizite Re-Synchronisation erforderlich. @@ -1045,27 +586,21 @@ Algorithmus-Übersicht \begin{itemize*} - \item - Datenverschlüsselungsstandard (DES) - + \item Datenverschlüsselungsstandard (DES) \begin{itemize*} \item Alter amerikanischer Standard aus den 70er Jahren \item Unsicher wegen der Schlüssel- und Blocklänge \item Grundlegender Aufbau \item Dreifache Verschlüsselung mit einer Blockchiffre, z.B. Triple-DES \end{itemize*} - \item - Erweiterter Verschlüsselungsstandard (AES) - + \item Erweiterter Verschlüsselungsstandard (AES) \begin{itemize*} \item Offener Standardisierungsprozess mit internationaler Beteiligung \item Im Oktober 2000 wurde ein Algorithmus namens Rijndael für AES vorgeschlagen \item Ankündigung des AES-Standards im November 2001 \item Siehe auch \href{http://www.nist.gov/aes/}{http://www.nist.gov/aes/} \end{itemize*} - \item - Andere populäre Algorithmen - + \item Andere populäre Algorithmen \begin{itemize*} \item RC \item KASUMI @@ -1079,12 +614,10 @@ Geschichte \begin{itemize*} - \item - 1973 veröffentlichte das National Bureau of Standards (NBS, heute + \item 1973 veröffentlichte das National Bureau of Standards (NBS, heute National Institute of Standards and Technology, NIST) eine Aufforderung zur Einreichung von Vorschlägen für einen nationalen Verschlüsselungsstandard und forderte von dem Algorithmus, dass er - \begin{itemize*} \item ein hohes Maß an Sicherheit bieten, \item vollständig spezifiziert und leicht zu verstehen sein, @@ -1096,29 +629,23 @@ \item validiert werden können und \item exportierbar sein. \end{itemize*} - \item - Keine der Einreichungen auf diese erste Aufforderung erfüllte diese + \item Keine der Einreichungen auf diese erste Aufforderung erfüllte diese Kriterien auch nur annähernd. - \item - Auf eine zweite Aufforderung hin reichte IBM seinen Algorithmus + \item Auf eine zweite Aufforderung hin reichte IBM seinen Algorithmus LUCIFER ein, eine symmetrische Blockchiffre, die mit Blöcken der Länge 128 Bit unter Verwendung von Schlüsseln der Länge 128 Bit arbeitet; dies war der einzige vielversprechende Kandidat. - \item - Die NBS bat die National Security Agency (NSA) um Hilfe bei der + \item Die NBS bat die National Security Agency (NSA) um Hilfe bei der Bewertung der Sicherheit des Algorithmus - \begin{itemize*} \item Die NSA reduzierte die Blockgröße auf 64 Bit, die Größe des Schlüssels auf 56 Bit und änderte Details in den Substitutionsfeldern des Algorithmus. \item Viele der Gründe der NSA für diese Änderungen wurden erst in den frühen 1990er Jahren deutlich, lösten aber in den späten 1970er Jahren große Besorgnis aus. \end{itemize*} - \item - Trotz aller Kritik wurde der Algorithmus 1977 als ,,Data Encryption + \item Trotz aller Kritik wurde der Algorithmus 1977 als ,,Data Encryption Standard'' in die Reihe der Federal Information Processing Standards (FIPS PUB 46) aufgenommen und für die Verwendung in der gesamten nicht klassifizierten Regierungskommunikation zugelassen. - \item - DES hat sich in den folgenden Jahren weithin durchgesetzt + \item DES hat sich in den folgenden Jahren weithin durchgesetzt \end{itemize*} % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-des-algorithm.png} @@ -1130,28 +657,22 @@ Iteration} \begin{itemize*} - \item - Die rechten 32 Bit der zu verschlüsselnden Daten werden mit Hilfe + \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 + \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 + \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 + \item Der Ausgang des obigen Schritts wird erneut permutiert und mit den linken 32 Bit der Daten XOR-verknüpft, was zu den neuen rechten 32 Bit der Daten führt - \item - Die neuen linken 32 Bit der Daten sind der rechte Wert der vorherigen + \item Die neuen linken 32 Bit der Daten sind der rechte Wert der vorherigen Iteration \end{itemize*} @@ -1159,52 +680,39 @@ \subsubsection{DES - Entschlüsselung} \begin{itemize*} - \item - Unter Verwendung der Abkürzung f(R, K) kann der + \item Unter Verwendung der Abkürzung f(R, K) kann der Verschlüsselungsprozess wie folgt geschrieben werden - \begin{itemize*} \item \$L\_i = R\_\{i-1\}\$ \item \$R\_i = L\_\{i-1\}\textbackslash oplus f(R\_\{i-1\}, K\_i)\$ \item Dieses Konzept (Aufteilung der Daten in zwei Hälften und Organisation der Verschlüsselung gemäß den obigen Gleichungen) wird in vielen Blockchiffren verwendet und wird als Feistel-Netzwerk bezeichnet (nach seinem Erfinder H. Feistel) \end{itemize*} - \item - Der DES-Entschlüsselungsprozess ist im Wesentlichen derselbe wie die + \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 - + \item Die Ausgangswerte sind also \begin{itemize*} - \item \$L\_0' \textbar\textbar{} R\_0' =\$ InitialPermutation (Chiffretext) - \item chiffretext = InverseInitialPermutation (\$R\_\{16\} \textbar\textbar{} L\_\{16\}\$) - \item \$L\_0' \textbar\textbar{} R\_0' =\$ InitialPermutation (InverseInitialPermutation (\$R\_\{16\}\textbar\textbar L\_\{16\}))=R\_\{16\}\textbar\textbar L\_\{16\}\$ + \item \$L\_0' \textbar| R\_0' =\$ InitialPermutation (Chiffretext) + \item chiffretext = InverseInitialPermutation (\$R\_\{16\} \textbar| L\_\{16\}\$) + \item \$L\_0' \textbar| R\_0' =\$ InitialPermutation (InverseInitialPermutation (\$R\_\{16\}\textbar\textbar L\_\{16\}))=R\_\{16\}\textbar\textbar L\_\{16\}\$ \end{itemize*} - \item - Nach einem Schritt der Entschlüsselung - + \item Nach einem Schritt der Entschlüsselung \begin{itemize*} \item \$L\_1' = R\_0' = L\_\{16\} = R\_\{15\}\$ \item \$R\_1' = L\_0' \textbackslash oplus f(R\_0', K\_\{16\})=R\_\{16\}\textbackslash oplus f(R\_\{15\},K\_\{16\})={[}L\_\{15\}\textbackslash oplus f(R\_\{15\},K\_\{16\}){]}\textbackslash oplus f(R\_\{15\},K\_\{16\}) =L\_\{15\}\$ \end{itemize*} - \item - Diese Beziehung gilt für den gesamten Prozess als - + \item Diese Beziehung gilt für den gesamten Prozess als \begin{itemize*} \item \$R\_\{i-1\} = L\_i\$ \item \$L\_\{i-1\} = R\_i\textbackslash oplus f(R\_\{i-1\}, K\_i) = R\_i\textbackslash oplus f(L\_i, K\_i)\$ \end{itemize*} - \item - Der Ausgang der letzten Runde ist schließlich - + \item Der Ausgang der letzten Runde ist schließlich \begin{itemize*} - \item \$L\_\{16\}' \textbar\textbar{} R\_\{16\}' = R\_0 \textbar\textbar{} L\_0\$ + \item \$L\_\{16\}' \textbar| R\_\{16\}' = R\_0 \textbar| L\_0\$ \end{itemize*} - \item - Nach der letzten Runde führt DES einen 32-Bit-Tausch und die inverse + \item Nach der letzten Runde führt DES einen 32-Bit-Tausch und die inverse Anfangspermutation durch - \begin{itemize*} \item InverseInitialPermutation(\$L\_0\textbar\textbar R\_0\$) = InverseInitialPermutation(InitialPermutation(Klartext)) = Klartext \end{itemize*} @@ -1214,26 +722,20 @@ \subsubsection{DES - Sicherheit} \begin{itemize*} - \item - Schwächen der Schlüssel - + \item Schwächen der Schlüssel \begin{itemize*} \item Schwache Schlüssel: Vier Schlüssel sind schwach, da sie Unterschlüssel erzeugen, die entweder alle 0 oder alle 1 enthalten. \item Halbschwache Schlüssel: Es gibt sechs Schlüsselpaare, die Klartext zu identischem Chiffriertext verschlüsseln, da sie nur zwei verschiedene Unterschlüssel erzeugen \item Möglicherweise schwache Schlüssel: Es gibt 48 Schlüssel, die nur vier verschiedene Unterschlüssel erzeugen \item Insgesamt werden 64 Schlüssel von \$72057594037927936\$ als schwach angesehen \end{itemize*} - \item - Algebraische Struktur - + \item Algebraische Struktur \begin{itemize*} \item Wäre DES geschlossen, dann gäbe es für jedes \$K\_1,K\_2\$ ein \$K\_3\$, so dass: \$E(K\_2,E(K\_1,M))=E(K\_3,M)\$, also wäre die doppelte Verschlüsselung nutzlos \item Wäre DES rein, dann gäbe es für jedes \$K\_1,K\_2,K\_3\$ ein \$K\_4\$, so dass \$E(K\_3,E(K\_2,E(K\_1,M)))=E(K\_4,M)\$, also wäre die dreifache Verschlüsselung nutzlos \item DES ist weder geschlossen noch rein, daher kann ein Mehrfachverschlüsselungsschema verwendet werden, um die Schlüssellänge zu erhöhen \end{itemize*} - \item - Differentielle Kryptoanalyse - + \item Differentielle Kryptoanalyse \begin{itemize*} \item Im Jahr 1990 veröffentlichten E. Biham und A. Shamir diese Analysemethode \item Sie sucht gezielt nach Unterschieden in Chiffretexten, deren Klartexte bestimmte Unterschiede aufweisen, und versucht, daraus den richtigen Schlüssel zu erraten @@ -1241,9 +743,7 @@ \item DES mit 16 Runden ist gegen diesen Angriff immun, da der Angriff \$2\^{}\{47\}\$ gewählte Klartexte oder (bei "Umwandlung" in einen Angriff mit bekannten Klartexten) \$2\^{}55\$ bekannte Klartexte benötigt. \item Die Entwickler von DES erklärten in den 1990er Jahren, dass sie in den 1970er Jahren über diese Art von Angriffen Bescheid wussten und dass die s-Boxen entsprechend entworfen wurden \end{itemize*} - \item - Schlüssellänge - + \item Schlüssellänge \begin{itemize*} \item Da ein 56-Bit-Schlüssel in \$10,01\$ Stunden durchsucht werden kann, wenn man \$10\^{}6\$ Verschlüsselungen / \$\textbackslash mu s\$ durchführen kann (was heute möglich ist), kann DES nicht mehr als ausreichend sicher angesehen werden. \end{itemize*} @@ -1254,37 +754,30 @@ Mehrfachverschlüsselung} \begin{itemize*} - \item - Doppelter DES: Da DES nicht geschlossen ist, führt die doppelte + \item Doppelter DES: Da DES nicht geschlossen ist, führt die doppelte Verschlüsselung zu einer Chiffre, die 112-Bit-Schlüssel verwendet - \begin{itemize*} \item Leider kann sie mit einem Aufwand von \$2\^{}\{56\}\$ angegriffen werden. \item Da \$C=E(K\_2,E(K\_1,P))\$ haben wir \$X:=E(K\_1,P)=D(K\_2,C)\$ \item Wenn ein Angreifer ein bekanntes Klartext/Chiffretext-Paar erhalten kann, kann er zwei Tabellen erstellen (meet-in-the-middle-attack) \begin{itemize*} \item Tabelle 1 enthält die Werte von \$X\$, wenn \$P\$ mit allen möglichen Werten von \$K\$ verschlüsselt ist \item Tabelle 2 enthält die Werte von \$X\$, wenn \$C\$ mit allen möglichen Werten von \$K\$ entschlüsselt wird \item Sortiere die beiden Tabellen und konstruiere Schlüssel \$K\_\{T1\}\textbar\textbar K\_\{T2\}\$ für alle Kombinationen von Einträgen, die den gleichen Wert ergeben. \end{itemize*} \end{itemize*} - \item - Da es für jeden beliebigen Klartext \$2\^{}\{64\}\$ mögliche + \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 + \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 + \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 + \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. @@ -1299,48 +792,34 @@ AES} \begin{itemize*} - \item - Jan. 1997: Das National Institute of Standards and Technology (NIST) + \item Jan. 1997: Das National Institute of Standards and Technology (NIST) der USA kündigt die Entwicklung des AES an. - \begin{itemize*} \item Das übergeordnete Ziel ist die Entwicklung eines Federal Information Processing Standard (FIPS), der einen Verschlüsselungsalgorithmus spezifiziert, der in der Lage ist, sensible Regierungsinformationen bis weit ins nächste Jahrhundert hinein zu schützen. \end{itemize*} - \item - Sep. 1997: Offizieller Aufruf zur Einreichung von Algorithmen, offen + \item Sep. 1997: Offizieller Aufruf zur Einreichung von Algorithmen, offen für jeden auf der Welt - \begin{itemize*} \item AES würde einen nicht klassifizierten, öffentlich zugänglichen Verschlüsselungsalgorithmus bzw. -algorithmen spezifizieren, der weltweit lizenzgebührenfrei erhältlich ist. \end{itemize*} - \item - Aug. 1998: Erste AES-Kandidatenkonferenz - + \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: - + \item April 1999: \begin{itemize*} \item Anhand der eingegangenen Analysen und Kommentare wählt das NIST fünf Algorithmen als Kandidaten für die Endauswahl aus: MARS, RC6, Rijndael, Serpent und Twofish \end{itemize*} - \item - Oktober 2000: Rijndael wird als Vorschlag des NIST für AES bekannt + \item Oktober 2000: Rijndael wird als Vorschlag des NIST für AES bekannt gegeben - \begin{itemize*} \item \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \setcounter{enumi}{25} \item November 2001: offizielle Ankündigung des AES-Standards \end{enumerate*} \end{itemize*} - \item - Rundenbasierte symmetrische Chiffre - \item - Keine Feistel-Struktur (unterschiedliche Verschlüsselungs- und + \item Rundenbasierte symmetrische Chiffre + \item Keine Feistel-Struktur (unterschiedliche Verschlüsselungs- und Entschlüsselungsfunktionen) - \item - Schlüssel- und Blocklängen - + \item Schlüssel- und Blocklängen \begin{itemize*} \item Schlüssellänge: 128, 192, oder 256 Bit \item Blocklänge: 128, 192 oder 256 Bit (nur 128-Bit-Version standardisiert) @@ -1348,42 +827,35 @@ \end{itemize*} \end{itemize*} - Standardisierte AES-Konfigurationen \textbar{} Schlüsselgröße {[}bit{]} - \textbar{} Blocklänge {[}bit{]} \textbar{} \# Runden \textbar{} - \textbar{} -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- - \textbar{} -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{} - -\/-\/-\/-\/-\/-\/-\/- \textbar{} \textbar{} 128 \textbar{} 128 - \textbar{} 10 \textbar{} \textbar{} 192 \textbar{} 128 \textbar{} 12 - \textbar{} \textbar{} 256 \textbar{} 128 \textbar{} 14 \textbar{} + Standardisierte AES-Konfigurationen | Schlüsselgröße {[}bit{]} + | Blocklänge {[}bit{]} | \# Runden | + | -------------------- + | ---------------- | + -------- | | 128 | 128 + | 10 | | 192 | 128 | 12 + | | 256 | 128 | 14 | \begin{itemize*} - \item - Der Algorithmus arbeitet mit - + \item Der Algorithmus arbeitet mit \begin{itemize*} \item \$state{[}4, 4{]}\$: ein Byte-Array mit 4 Zeilen und 4 Spalten (für 128-Bit-Blockgröße) \item \$key{[}4, 4{]}\$: ein Array mit 4 Zeilen und 4 Spalten (für 128-Bit-Schlüsselgröße) \end{itemize*} - \item - Verschlüsselung: (für eine Block- und Schlüsselgröße von 128 Bit) in + \item Verschlüsselung: (für eine Block- und Schlüsselgröße von 128 Bit) in den Runden \$1-9\$ werden vier verschiedene Operationen verwendet - \begin{itemize*} \item ByteSub: eine nicht-lineare Byte-Substitution durch eine feste Tabelle (im Grunde eine s-Box) \item ShiftRow: die Zeilen des Zustands werden zyklisch um verschiedene Offsets verschoben \item MixColumn: die Spalten von \$state{[}{]}\$ werden als Polynome über \$GF(2\^{}8)\$ betrachtet und modulo \$x\^{}4+1\$ mit einer festen Matrix multipliziert: \$\textbackslash begin\{pmatrix\} 02\&03\&01\&01\textbackslash01\&02\&03\&01\textbackslash\textbackslash{} 01\&01\&02\&03\textbackslash\textbackslash{} 03\&01\&01\&02\textbackslash end\{pmatrix\}\$ \item RoundKey: ein Round-Key wird mit dem Status XORiert \end{itemize*} - \item - Round 10 macht keinen Gebrauch von der Operation MixColumn + \item Round 10 macht keinen Gebrauch von der Operation MixColumn \end{itemize*} % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-rijndael-one-round.png} \begin{itemize*} - \item - Entschlüsselung - + \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 @@ -1396,26 +868,19 @@ \subsubsection{AES - Sicherheit} \begin{itemize*} - \item - Die einfache mathematische Struktur von AES ist der Hauptgrund für + \item Die einfache mathematische Struktur von AES ist der Hauptgrund für seine Geschwindigkeit, führte aber auch zu Kritik - \item - Nur die ByteSub-Funktion ist wirklich nichtlinear und verhindert eine + \item Nur die ByteSub-Funktion ist wirklich nichtlinear und verhindert eine effektive Analyse - \item - AES kann als eine große Matrix-Operation beschrieben werden - \item - Bereits während der Standardisierung wurden Angriffe für reduzierte + \item AES kann als eine große Matrix-Operation beschrieben werden + \item Bereits während der Standardisierung wurden Angriffe für reduzierte Versionen entwickelt - \begin{itemize*} \item Ein Angriff mit \$2\^{}\{32\}\$ gewähltem Klartext gegen eine 7-Runden-Version von AES {[}GM00{]} \item Signifikante Reduktion der Komplexität auch für eine 9-Runden-Version von AES mit 256-Schlüsselgröße mit einem zugehörigen Schlüsselangriff \end{itemize*} - \item - 2011 wurde der erste Angriff gegen einen vollständigen AES bekannt + \item 2011 wurde der erste Angriff gegen einen vollständigen AES bekannt {[}BKR11{]} - \begin{itemize*} \item Schlüsselwiederherstellung in \$2\^{}\{126.1\}\$ für AES mit 128 Bit, \$2\^{}\{189.7\}\$ für AES mit 192 Bit, \$2\^{}\{254.4\}\$ für AES mit 256 Bit \item "Praktischer" Angriff (geht nicht von verwandten Schlüsseln aus), aber @@ -1428,14 +893,10 @@ 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 + \item RC4 ist eine Stromchiffre, die 1987 von Ron Rivest erfunden wurde. + \item Sie war bis 1994 urheberrechtlich geschützt, als jemand sie anonym in eine Mailingliste einstellte. - \item - RC4 wird im Output-Feedback-Modus (OFB) betrieben - + \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 @@ -1444,15 +905,11 @@ \item Entscheidend für die Sicherheit ist, dass der Keystream niemals wiederverwendet wird!!! \begin{itemize*} \item Wenn der Keystream wiederverwendet wird (d.h. \$IV\_1=IV\_2\$ mit demselben \$K\$), dann kann das XOR zweier Klartexte erhalten werden: \$C\_1\textbackslash oplus C\_2= P\_1\textbackslash oplus RC4(IV, K)\textbackslash oplus P\_2\textbackslash oplus RC4(IV,K) = P\_1\textbackslash oplus P\_2\$ \end{itemize*} \end{itemize*} - \item - RC4 verwendet einen Schlüssel variabler Länge bis zu 2048 Bit - + \item RC4 verwendet einen Schlüssel variabler Länge bis zu 2048 Bit \begin{itemize*} \item Eigentlich dient der Schlüssel als Seed für einen Pseudo-Zufallsgenerator \end{itemize*} - \item - RC4 arbeitet mit zwei 256-Byte-Arrays: \$S{[}0,255{]}, K{[}0,255{]}\$ - + \item RC4 arbeitet mit zwei 256-Byte-Arrays: \$S{[}0,255{]}, K{[}0,255{]}\$ \begin{itemize*} \item Schritt 1: Initialisierung der Arrays %\begin{Shaded} % \begin{Highlighting}[] % \ControlFlowTok{for}\NormalTok{ (i = }\DecValTok{0}\NormalTok{; i \textless{} }\DecValTok{256}\NormalTok{; i++)\{} % \NormalTok{ S[i] = i; }\CommentTok{// Array S[] mit 0 bis 255 füllen} % \NormalTok{\}} % \CommentTok{// Füllen des Arrays K[] mit dem Schlüssel und IV durch Wiederholung, bis K[] gefüllt ist} % \NormalTok{n = }\DecValTok{0}\NormalTok{;} % \ControlFlowTok{for}\NormalTok{ (i =}\DecValTok{0}\NormalTok{; i \textless{} }\DecValTok{256}\NormalTok{; i++) \{} % \NormalTok{ n = (n + S[i] + K[i]) MOD }\DecValTok{256}\NormalTok{; swap(S[i], S[n]); } % \NormalTok{\}} % \end{Highlighting} %\end{Shaded} @@ -1460,30 +917,23 @@ %\begin{Shaded} % \begin{Highlighting}[] % \NormalTok{i = (i + }\DecValTok{1}\NormalTok{) MOD }\DecValTok{256}\NormalTok{; n = (n + S[i]) MOD }\DecValTok{256}\NormalTok{;} % \NormalTok{swap(S[i], S[n]);} % \NormalTok{t = (S[i] + S[n]) MOD }\DecValTok{256}\NormalTok{;} % \NormalTok{Z = S[t]; }\CommentTok{// Z enthält 8 Bit des durch eine Iteration erzeugten Schlüsselstroms} % \end{Highlighting} %\end{Shaded} \item Schritt 3: XOR-Verknüpfung des Schlüsselstroms mit dem Klartext oder Chiffretext \end{itemize*} - \item - Sicherheit von RC4 - + \item Sicherheit von RC4 \begin{itemize*} \item Sicherheit gegen Brute-Force-Angriffe (Ausprobieren aller möglichen Schlüssel) \begin{itemize*} \item Die variable Schlüssellänge von bis zu 2048 Bit erlaubt es, sie unpraktisch zu machen (zumindest mit den in unserem Universum verfügbaren Ressourcen) \item Allerdings kann RC4 durch Verringerung der Schlüssellänge auch beliebig unsicher gemacht werden! \end{itemize*} \item RSA Data Security, Inc. behauptet, RC4 sei immun gegen differentielle und lineare Kryptoanalyse, und es seien keine kleinen Zyklen bekannt \end{itemize*} - \item - RC4 mit 40-Bit-Schlüsseln hatte einen besonderen Exportstatus, selbst + \item RC4 mit 40-Bit-Schlüsseln hatte einen besonderen Exportstatus, selbst als andere Chiffren nicht aus den USA exportiert werden durften - \begin{itemize*} \item Secure Socket Layer (SSL) verwendet RC4 mit 40-Bit-Schlüsseln als Standardalgorithmus \item Die Schlüssellänge von 40 Bit ist nicht immun gegen Brute-Force-Angriffe. \end{itemize*} - \item - Je nach Schlüsselplanungsmethode kann RC4 jedoch stark verwundbar + \item Je nach Schlüsselplanungsmethode kann RC4 jedoch stark verwundbar sein! {[}FMS01a, Riv01a, SIR01a{]} - \item - Es wird empfohlen, mindestens die ersten 3072 Bytes des + \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 + \item Sollte eigentlich nicht mehr verwendet werden, auch nicht bei längeren Schlüsseln \end{itemize*} @@ -1491,51 +941,37 @@ \subsection{KASUMI} \begin{itemize*} - \item - Verwendet zur Verschlüsselung von Anrufen in GSM und UMTS, + \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 + \item Ursprünglich standardisiert durch 3GPP im Jahr 2000 {[}ETS12{]} und basierend auf MISTY1 von Mitsubishi - \item - Entwickelt für Hardware-Implementierung - + \item Entwickelt für Hardware-Implementierung \begin{itemize*} \item Schnelle Implementierung möglich \item \$\textless10k\$ Gatter \end{itemize*} - \item - 64-Bit-Blockgröße - \item - 128-Bit-Schlüssellänge - \item - 8 Runden Feistel-Netzwerk - \item - Sicherheitsspanne nicht sehr groß + \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 + \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 + \item Die Reihenfolge, in der FO und FL angewendet werden, hängt von der Rundenzahl ab - \item - FL teilt die Daten in 16-Bit-Wörter auf, die mit Schlüsselmaterial + \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 + \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 + \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 + \item Das neue linke 32-Bit der Daten ist der rechte Wert der vorherigen Iteration \end{itemize*} @@ -1544,30 +980,24 @@ Sicherheitsdiskussion} \begin{itemize*} - \item - Eine reduzierte Version von KASUMI (6 Runden) kann durch sogenannte + \item Eine reduzierte Version von KASUMI (6 Runden) kann durch sogenannte unmögliche differentielle Kryptoanalyse angegriffen werden, bei der unmögliche Zustände der Chiffre aus Chiffretext/Klartext-Paaren abgeleitet werden - \begin{itemize*} \item Erste Veröffentlichung bereits ein Jahr nach der Standardisierung \item Zeitkomplexität von \$2\^{}\{100\}\$ {[}Kue01{]} \end{itemize*} - \item - Für eine Vollversion von KASUMI sind verwandte Schlüsselangriffe + \item Für eine Vollversion von KASUMI sind verwandte Schlüsselangriffe möglich - \begin{itemize*} \item Ausgewählter Klartextangriff, bei dem der Angreifer dieselben Daten mit mehreren "verwandten" Schlüsseln verschlüsseln kann \item Zeitkomplexität von \$2\^{}\{76.1\}\$ {[}BDN05{]} und \$2\^{}\{32\}\$ im besten Fall {[}DKS10{]} \item Allerdings sind die Bedingungen, unter denen Angreifer Zugang zu verwandten Schlüsseln in 3G-Netzen haben, sehr selten \item Interessanterweise ist MISTY von diesen Angriffen nicht betroffen! \end{itemize*} - \item - ETSI hat jedoch SNOW 3G (UEA2 und UIA2) {[}ETS06{]} eingeführt, um auf + \item ETSI hat jedoch SNOW 3G (UEA2 und UIA2) {[}ETS06{]} eingeführt, um auf eine vollständige Verletzung von KASUMI vorbereitet zu sein - \begin{itemize*} \item Stromchiffre basierend auf LFSR, kann in 7.500 ASIC-Gattern implementiert werden \item Aber auch anfällig für verwandte Schlüsselangriffe {[}KY11{]}. @@ -1583,9 +1013,7 @@ Amoroso in einem anderen Zusammenhang {[}Amo94{]} \begin{itemize*} - \item - Allgemeine Idee: - + \item Allgemeine Idee: \begin{itemize*} \item Verwenden Sie zwei verschiedene Schlüssel \$-K\$ und \$+K\$ für die Ver- und Entschlüsselung \item Bei einem zufälligen Chiffretext \$c=E(+K, m)\$ und \$+K\$ sollte es nicht möglich sein, \$m = D(-K, c) = D(-K, E(+K, m))\$ zu berechnen. @@ -1593,9 +1021,7 @@ \item Der Schlüssel \$-K\$ ist nur einer Entität A bekannt und wird A's privater Schlüssel \$-K\_A\$ genannt \item Der Schlüssel \$+K\$ kann öffentlich bekannt gegeben werden und wird A's öffentlicher Schlüssel \$+K\_A\$ genannt \end{itemize*} - \item - Anwendungen: - + \item Anwendungen: \begin{itemize*} \item Verschlüsselung: \begin{itemize*} \item Wenn B eine Nachricht mit dem öffentlichen Schlüssel \$+K\_A\$ von A verschlüsselt, kann er sicher sein, dass nur A sie mit \$-K\_A\$ entschlüsseln kann. \end{itemize*} @@ -1603,9 +1029,7 @@ \begin{itemize*} \item Wenn A eine Nachricht mit seinem eigenen privaten Schlüssel \$-K\_A\$ verschlüsselt, kann jeder diese Signatur verifizieren, indem er sie mit A's öffentlichem Schlüssel \$+K\_A\$ entschlüsselt \end{itemize*} \item Achtung! Entscheidend ist, dass jeder nachprüfen kann, dass er wirklich den öffentlichen Schlüssel von A kennt und nicht den Schlüssel eines Gegners! \end{itemize*} - \item - Entwurf von asymmetrischen Kryptosystemen: - + \item Entwurf von asymmetrischen Kryptosystemen: \begin{itemize*} \item Schwierigkeit: Finde einen Algorithmus und eine Methode, zwei Schlüssel \$-K\$, \$+K\$ so zu konstruieren, dass es nicht möglich ist, \$E(+K, m)\$ mit der Kenntnis von \$+K\$ zu entschlüsseln \item Beschränkungen: @@ -1620,43 +1044,34 @@ Hintergründe} \begin{itemize*} - \item - Sei \$\textbackslash mathbb\{Z\}\$ die Menge der ganzen Zahlen, und + \item Sei \$\textbackslash mathbb\{Z\}\$ die Menge der ganzen Zahlen, und \$a,b,n\textbackslash in\textbackslash mathbb\{Z\}\$ - \item - Wir sagen, \$a\$ teilt \$b(a\textbar b)\$, wenn es eine ganze Zahl + \item Wir sagen, \$a\$ teilt \$b(a\textbar b)\$, wenn es eine ganze Zahl \$k\textbackslash in\textbackslash mathbb\{Z\}\$ gibt, so dass \$a\textbackslash times k=b\$ - \item - \$a\$ ist prim, wenn es positiv ist und die einzigen Teiler von a + \item \$a\$ ist prim, wenn es positiv ist und die einzigen Teiler von a \$1\$ und \$a\$ sind. - \item - \$r\$ ist der Rest von a geteilt durch \$n\$, wenn + \item \$r\$ ist der Rest von a geteilt durch \$n\$, wenn \$r=a-\textbackslash lfloor a / n \textbackslash rfloor\textbackslash times n\$, wobei \$\textbackslash lfloor x\textbackslash rfloor\$ die größte ganze Zahl kleiner oder gleich \$x\$ ist. - \begin{itemize*} \item Beispiel: 4 ist der Rest von 11 geteilt durch 7 als \$4=11-\textbackslash lfloor 11/7\textbackslash rfloor\textbackslash times 7\$ \item Wir können dies auch anders schreiben: \$a=q\textbackslash times n + r\$ mit \$q=\textbackslash lfloor a/n\textbackslash rfloor\$ \end{itemize*} - \item - Für den Rest \$r\$ der Division von a durch n schreiben wir + \item Für den Rest \$r\$ der Division von a durch n schreiben wir \$a\textbackslash{} MOD\textbackslash{} n\$ - \item - Wir sagen, b ist kongruent \$a\textbackslash{} mod\textbackslash{} + \item Wir sagen, b ist kongruent \$a\textbackslash{} mod\textbackslash{} n\$, wenn es bei der Division durch n den gleichen Rest wie a hat. Also teilt n \$(a-b)\$, und wir schreiben \$b\textbackslash equiv a\textbackslash{} mod\textbackslash{} n\$ - \begin{itemize*} \item Beispiele: \$4\textbackslash equiv 11\textbackslash{} mod\textbackslash{} 7\$, \$25\textbackslash equiv 11\textbackslash{} mod\textbackslash{} 7\$, \$11\textbackslash equiv 25\textbackslash{} mod\textbackslash{} 7\$, \$11\textbackslash equiv 4\textbackslash{} mod\textbackslash{} 7\$, \$-10\textbackslash equiv 4\textbackslash{} mod\textbackslash{} 7\$ \end{itemize*} - \item - Da der Rest r der Division durch n immer kleiner als n ist, stellt man + \item Da der Rest r der Division durch n immer kleiner als n ist, stellt man manchmal die Menge \$\{x\textbackslash{} MOD\textbackslash{} n - \textbar{} x\textbackslash in\textbackslash mathbb\{Z\}\}\$ durch + | x\textbackslash in\textbackslash mathbb\{Z\}\}\$ durch Elemente der Menge \$\textbackslash mathbb\{Z\}\_n=\{0, 1, ..., n-1\}\$ dar \end{itemize*} @@ -1702,27 +1117,21 @@ Größter gemeinsamer Teiler \begin{itemize*} - \item - \$c = gcd(a, b) :\textbackslash Leftrightarrow ( c \textbar{} a) - \textbackslash wedge ( c \textbar{} b) \textbackslash wedge - {[}\textbackslash forall d: ( d \textbar{} a ) \textbackslash wedge ( - d \textbar{} b) \textbackslash Rightarrow ( d \textbar{} c ){]}\$ und - \$gcd(a, 0 ) : = \textbar{} a \textbar\$ - \item - Der gcd-Rekursionssatz : - + \item \$c = gcd(a, b) :\textbackslash Leftrightarrow ( c | a) + \textbackslash wedge ( c | b) \textbackslash wedge + {[}\textbackslash forall d: ( d | a ) \textbackslash wedge ( + d | b) \textbackslash Rightarrow ( d | c ){]}\$ und + \$gcd(a, 0 ) : = | a \textbar\$ + \item Der gcd-Rekursionssatz : \begin{itemize*} \item \$\textbackslash forall a, b \textbackslash in \textbackslash mathbb\{Z\}\^{}+: gcd(a, b) = gcd(b, a\textbackslash{} MOD\textbackslash{} b)\$ \item Beweis: - \begin{itemize*} \item Da \$gcd(a, b)\$ sowohl a als auch b teilt, teilt es auch jede Linearkombination von ihnen, insbesondere \$(a- \textbackslash lfloor a / b \textbackslash rfloor \textbackslash times b) = a\textbackslash{} MOD\textbackslash{} b\$, also \$gcd(a, b) \textbar{} gcd(b, a\textbackslash{} MOD\textbackslash{} b)\$ \item Da \$gcd(b, a\textbackslash{} MOD\textbackslash{} b)\$ sowohl b als auch \$a\textbackslash{} MOD\textbackslash{} b\$ teilt, teilt es auch jede Linearkombination von beiden, insbesondere \$\textbackslash lfloor a / b \textbackslash rfloor \textbackslash times b + (a\textbackslash{} MOD\textbackslash{} b) = a\$, also \$gcd(b, a\textbackslash{} MOD\textbackslash{} b) \textbar{} gcd(a, b)\$ \end{itemize*} + \begin{itemize*} \item Da \$gcd(a, b)\$ sowohl a als auch b teilt, teilt es auch jede Linearkombination von ihnen, insbesondere \$(a- \textbackslash lfloor a / b \textbackslash rfloor \textbackslash times b) = a\textbackslash{} MOD\textbackslash{} b\$, also \$gcd(a, b) | gcd(b, a\textbackslash{} MOD\textbackslash{} b)\$ \item Da \$gcd(b, a\textbackslash{} MOD\textbackslash{} b)\$ sowohl b als auch \$a\textbackslash{} MOD\textbackslash{} b\$ teilt, teilt es auch jede Linearkombination von beiden, insbesondere \$\textbackslash lfloor a / b \textbackslash rfloor \textbackslash times b + (a\textbackslash{} MOD\textbackslash{} b) = a\$, also \$gcd(b, a\textbackslash{} MOD\textbackslash{} b) | gcd(a, b)\$ \end{itemize*} \end{itemize*} - \item - Euklidischer Algorithmus: - + \item Euklidischer Algorithmus: \begin{itemize*} \item Der euklidische Algorithmus berechnet aus a, b \$gcd(a, b)\$ \end{itemize*} - %\begin{Shaded} % \begin{Highlighting}[] % \DataTypeTok{int}\NormalTok{ Euclid(}\DataTypeTok{int}\NormalTok{ a, b)\{} @@ -1731,13 +1140,10 @@ % \NormalTok{\}} % \end{Highlighting} %\end{Shaded} - \item - Erweiterter euklidischer Algorithmus: - + \item Erweiterter euklidischer Algorithmus: \begin{itemize*} \item Der Algorithmus ExtendedEuclid berechnet für a, b d, m, n so, dass: \$d = gcd(a, b) = m \textbackslash times a + n \textbackslash times b\$ \end{itemize*} - %\begin{Shaded} % \begin{Highlighting}[] % \KeywordTok{struct}\NormalTok{\{}\DataTypeTok{int}\NormalTok{ d, m, n\} ExtendedEuclid(}\DataTypeTok{int}\NormalTok{ a, b)} @@ -1748,7 +1154,6 @@ % \ControlFlowTok{return}\NormalTok{(d, m, n); \}} % \end{Highlighting} %\end{Shaded} - \begin{itemize*} \item Beweis: (durch Induktion) \begin{itemize*} \item Grundfall \$(a,0): gcd(a, 0) = a = 1 \textbackslash times a + 0 \textbackslash times 0\$ \item Induktion von \$(b, a\textbackslash{} MOD\textbackslash{} b)\$ auf \$(a, b)\$: @@ -1757,20 +1162,16 @@ \begin{itemize*} \item Beweis: siehe {[}Cor90a{]}, Abschnitt 33. \end{itemize*} \item Lemma 1: Sei \$a,b\textbackslash in\textbackslash mathbb\{N\}\$ und \$d=gcd(a,b)\$. Dann gibt es \$m,n\textbackslash in\textbackslash mathbb\{N\}\$ so, dass: \$d=m\textbackslash times a+n \textbackslash times b\$ \end{itemize*} - \item - Theorem 1 (Euklid): Wenn eine Primzahl das Produkt zweier ganzer + \item Theorem 1 (Euklid): Wenn eine Primzahl das Produkt zweier ganzer Zahlen teilt, dann teilt sie mindestens eine der ganzen Zahlen: \$p\textbar(a\textbackslash times b)\textbackslash Rightarrow (p\textbar a)\textbackslash times(p\textbar b)\$ - \begin{itemize*} \item Der Beweis: Es sei \$p\textbar(a\textbackslash times b)\$ \begin{itemize*} \item Wenn \$p\textbar a\$ dann sind wir fertig. \item Wenn nicht, dann \$gcd(p,a) = 1 \textbackslash Rightarrow\textbackslash exists m, n\textbackslash in\textbackslash mathbb\{N\}:1=m\textbackslash times p+n\textbackslash times a \textbackslash Leftrightarrow b=m\textbackslash times p \textbackslash times b + n \textbackslash times a \textbackslash times b\$ \item Da \$p\textbar(a\textbackslash times b)\$, teilt p beide Summanden der Gleichung und somit auch die Summe, die b ist \end{itemize*} \end{itemize*} - \item - Theorem 2 (Fundamentalsatz der Arithmetik): Die Faktorisierung in + \item Theorem 2 (Fundamentalsatz der Arithmetik): Die Faktorisierung in Primzahlen ist bis zur Ordnung eindeutig. - \begin{itemize*} \item Der Beweis: \begin{itemize*} \item Wir werden zeigen, dass jede ganze Zahl mit einer nicht eindeutigen Faktorisierung einen eigenen Teiler mit einer nicht eindeutigen Faktorisierung hat, was zu einem klaren Widerspruch führt, wenn wir schließlich auf eine Primzahl reduziert haben. \item Nehmen wir an, dass n eine ganze Zahl mit einer nicht eindeutigen Faktorisierung ist: \$n=p\_1\textbackslash times p\_2\textbackslash times ...\textbackslash times p\_r=q\_1 \textbackslash times q\_2\textbackslash times ... \textbackslash times q\_s\$. Die Primzahlen sind nicht notwendigerweise verschieden, aber die zweite Faktorisierung ist nicht einfach eine Umordnung der ersten. Da \$p\_1\$ n dividiert, dividiert es auch das Produkt \$q\_1\textbackslash times q\_2\textbackslash times ... \textbackslash times q\_s\$. Durch wiederholte Anwendung von Satz 1 zeigen wir, dass es mindestens ein \$q\_i\$ gibt, das durch \$p\_1\$ teilbar ist. Gegebenenfalls ordnen wir die \$q\_i\$'s so, dass es \$q\_1\$ ist. Da sowohl \$p\_1\$ als auch \$q\_1\$ Primzahlen sind, müssen sie gleich sein. Wir können also durch \$p\_1\$ dividieren und haben, dass \$n/p\_1\$ eine nicht-eindeutige Faktorisierung hat. \end{itemize*} @@ -1779,19 +1180,15 @@ \item Bezeichne \$\textbackslash phi(n)\$ die Anzahl der positiven ganzen Zahlen, die kleiner als n und relativ zu n prim sind \begin{itemize*} \item Beispiele: \$\textbackslash phi(4) = 2\$, \textbackslash phi(6)=2\$, \$\textbackslash phi(7)=6\$, \$\textbackslash phi(15)=8\$ \item Wenn p eine Primzahl ist \$\textbackslash Rightarrow\textbackslash phi(p)=p-1\$ \end{itemize*} \end{itemize*} - \item - Theorem 3 (Euler): Seien n und b positive und relativ primäre ganze + \item Theorem 3 (Euler): Seien n und b positive und relativ primäre ganze Zahlen, d.h. \$gcd(n, b) = 1 \textbackslash Rightarrow b \textbackslash phi(n) \textbackslash equiv 1\textbackslash{} mod\textbackslash{} n\$ - \begin{itemize*} \item Beweis: \begin{itemize*} \item Sei \$t=\textbackslash phi(n)\$ und \$a\_1,...a\_t\$ seien die positiven ganzen Zahlen kleiner als \$n\$, die relativ zu \$n\$ prim sind. Definieren Sie \$r\_1,...,r\_t\$ als die Residuen von \$b\textbackslash times a\_1\textbackslash{} mod\textbackslash{} n , ..., b\textbackslash times a\_t\textbackslash{} mod\textbackslash{} n\$, d.h.: \$b\textbackslash times a\_i \textbackslash equiv r\_i\textbackslash{} mod\textbackslash{} n\$. \item Beachten Sie, dass \$i\textbackslash not= j \textbackslash Rightarrow r\_i\textbackslash not= r\_j\$. Wäre dies nicht der Fall, hätten wir \$b\textbackslash times a\_i\textbackslash equiv b\textbackslash times a\_j\textbackslash{} mod\textbackslash{} n\$ und da \$gcd(b,n)=1\$, würde Korollar 1 \$a\_i\textbackslash equiv a\_j\textbackslash{} mod\textbackslash{} n\$ implizieren, was nicht sein kann, da \$a\_i\$ und \$a\_j\$ per Definition verschiedene ganze Zahlen zwischen 0 und n sind \item Wir wissen auch, dass jedes \$r\_i\$ relativ prim zu n ist, denn jeder gemeinsame Teiler k von \$r\_i\$ und \$n\$ , d.h. \$n=k\textbackslash times m\$ und \$r\_i=p\_i\textbackslash times k\$, müsste auch \$a\_i\$ teilen, \item da \$b\textbackslash times a\_i\$gleich (p\_i\textbackslash times k)\textbackslash{} mod\textbackslash{} (k\textbackslash times m)\textbackslash Rightarrow\textbackslash exists s\textbackslash in\textbackslash mathbb\{N\}:(b\textbackslash times a\_i)-(p\_i\textbackslash times k)=s\textbackslash times k\textbackslash times m \textbackslash Leftrightarrow (b\textbackslash times a\_i)=s\textbackslash times k\textbackslash times m+(p\_i\textbackslash times k)\$ \item Da k jeden der Summanden auf der rechten Seite dividiert und k nicht durch b dividiert (n und b sind relativ prim), müsste es auch \$a\_i\$ dividieren, das relativ prim zu n sein soll \item Somit ist \$r\_1, ...,r\_t\$ eine Menge von \$\textbackslash phi(n)\$ verschiedenen ganzen Zahlen, die relativ prim zu \$n\$ sind. Das bedeutet, dass sie genau dasselbe sind wie \$a\_1,...a\_t\$, nur dass sie in einer anderen Reihenfolge stehen. Insbesondere wissen wir, dass \$r\_1\textbackslash times ...\textbackslash times r\_t=a\_1\textbackslash times ...\textbackslash times a\_t\$ \item Wir verwenden nun die Kongruenz \$r\_1\textbackslash times ...\textbackslash times r\_t\textbackslash equiv b\textbackslash times a\_1\textbackslash times ...\textbackslash times b\textbackslash times a\_t\textbackslash{} mod\textbackslash{} n\$ \$\textbackslash Leftrightarrow r\_1\textbackslash times ...\textbackslash times r\_t\textbackslash equiv b\_t\textbackslash times a\_1\textbackslash times ...\textbackslash times a\_t\textbackslash{} mod\textbackslash{} n\$ \$\textbackslash Leftrightarrow r\_1\textbackslash times ...\textbackslash times r\_t\textbackslash equiv b\_\textbackslash times r\_1\textbackslash times ...\textbackslash times r\_t\textbackslash{} mod\textbackslash{} n\$ \item Da alle \$r\_i\$ relativ prim zu \$n\$ sind, können wir Korollar 1 anwenden und durch ihr Produkt dividieren: \$1\textbackslash equiv b\_t\textbackslash{} mod\textbackslash{} n \textbackslash Leftrightarrow 1\textbackslash equiv b\textbackslash phi(n)\textbackslash{} mod n\$ \end{itemize*} \end{itemize*} - \item - Satz 4 (Chinese Remainder Theorem): - + \item Satz 4 (Chinese Remainder Theorem): \begin{itemize*} \item Seien \$m\_1,...,m\_r\$ positive ganze Zahlen, die paarweise relativ prim sind, \item d.h. \$ganz i\textbackslash not= j:gcd(m\_i, m\_j) = 1\$. Seien \$a\_1,...,a\_r\$ beliebige ganze Zahlen. @@ -1801,9 +1198,7 @@ \item Beweis: \begin{itemize*} \item Für alle \$i\textbackslash in\{1,...,r\}\$ definieren wir \$M\_i:=(M/m\_i)\textbackslash phi(m\_i)\$ \item Da \$M\_i\$ per Definition relativ prim zu \$m\_i\$ ist, können wir Theorem 3 anwenden und wissen, dass \$M\_i\textbackslash equiv 1\textbackslash{} mod\textbackslash{} m\_i\$ \item Da \$M\_i\$ durch \$m\_j\$ für jedes \$j\textbackslash not= i\$ teilbar ist, haben wir \$\textbackslash forall j\textbackslash not= i:M\_i\textbackslash equiv 0\textbackslash{} mod\textbackslash{} m\_j\$ \item Wir können nun die Lösung konstruieren, indem wir definieren: \$a:= a\_1\textbackslash times M\_1+a\_2\textbackslash times M\_2+...+a\_r\textbackslash times M\_r\$ \item Die beiden oben angeführten Argumente bezüglich der Kongruenzen der \$M\_i\$ implizieren, dass a tatsächlich alle Kongruenzen erfüllt. \item Um zu sehen, dass a eindeutig modulo \$M\$ ist, sei b eine beliebige andere ganze Zahl, die die r Kongruenzen erfüllt. Da \$a\textbackslash equiv c\textbackslash{} mod\textbackslash{} n\$ und \$b\textbackslash equiv c\textbackslash{} mod\textbackslash{} n \textbackslash Rightarrow a \textbackslash equiv b\textbackslash{} mod\textbackslash{} n\$ haben wir \$\textbackslash forall i\textbackslash in\{1,...,r\}:a\textbackslash equiv b\textbackslash{} mod\textbackslash{} m\_i\textbackslash Rightarrow\textbackslash forall i\textbackslash in\{1,. ...,r\}:m\_i\textbar(a-b) \textbackslash Rightarrow M\textbar(a-b)\$, da die \$m\_i\$ paarweise relativ prim sind \$\textbackslash Leftrightarrow a\textbackslash equiv b\textbackslash{} mod\textbackslash{} M\$ \end{itemize*} \end{itemize*} - \item - Lemma 2: - + \item Lemma 2: \begin{itemize*} \item Wenn \$gcd(m,n)=1\$, dann ist \$\textbackslash phi(m\textbackslash times n)=\textbackslash phi(m)\textbackslash times \textbackslash phi(n)\$ \item Der Beweis: @@ -1817,50 +1212,38 @@ Algorithmus} \begin{itemize*} - \item - Der RSA-Algorithmus wurde 1977 von R. Rivest, A. Shamir und L. Adleman + \item Der RSA-Algorithmus wurde 1977 von R. Rivest, A. Shamir und L. Adleman {[}RSA78{]} erfunden und basiert auf Theorem 3. - \item - Seien \$p, q\$ verschiedene große Primzahlen und + \item Seien \$p, q\$ verschiedene große Primzahlen und \$n=p\textbackslash times q\$. Nehmen wir an, wir haben auch zwei ganze Zahlen e und d, so dass: \$d\textbackslash times e \textbackslash equiv 1\textbackslash{} mod\textbackslash{} \textbackslash phi(n)\$ - \item - M sei eine ganze Zahl, die die zu verschlüsselnde Nachricht darstellt, + \item M sei eine ganze Zahl, die die zu verschlüsselnde Nachricht darstellt, wobei M positiv, kleiner als und relativ prim zu n ist. - \begin{itemize*} \item Beispiel: Verschlüsseln mit = 99, A = 10, B = 11, ..., Z = 35. Somit würde ,,HELLO'' als 1714212124 kodiert werden. Falls erforderlich, ist M in Blöcke kleinerer Nachrichten aufzuteilen: 17142 12124 \end{itemize*} - \item - Zum Verschlüsseln berechnen Sie: \$E = M\^{}e\textbackslash{} + \item Zum Verschlüsseln berechnen Sie: \$E = M\^{}e\textbackslash{} MOD\textbackslash{} n\$ - \begin{itemize*} \item Dies kann mit dem Quadrat- und Multiplikationsalgorithmus effizient durchgeführt werden \end{itemize*} - \item - Zum Entschlüsseln berechnet man: \$M'=E\^{}d\textbackslash{} + \item Zum Entschlüsseln berechnet man: \$M'=E\^{}d\textbackslash{} MOD\textbackslash{} n\$ - \begin{itemize*} \item Da \$d\textbackslash times e\textbackslash equiv 1\textbackslash{} mod\textbackslash{} \textbackslash phi(n)\textbackslash Rightarrow\textbackslash exists k\textbackslash in\textbackslash mathbb\{Z\}:(d\textbackslash times e)-1=k\textbackslash times\textbackslash phi(n)\textbackslash Leftrightarrow(d\textbackslash times e)=k\textbackslash times\textbackslash phi(n)+1\$ \item haben wir: \$M'\textbackslash equiv E\^{}d\textbackslash equiv M\^{}\{e\textbackslash times d\}\textbackslash equiv M\^{}\{k\textbackslash times\textbackslash phi(n)+1\}\textbackslash equiv 1\^{}k\textbackslash times M\textbackslash equiv M\textbackslash{} mod\textbackslash{} n\$ \end{itemize*} - \item - Da \$(d\textbackslash times e)=(e\textbackslash times d)\$ + \item Da \$(d\textbackslash times e)=(e\textbackslash times d)\$ funktioniert die Operation auch in umgekehrter Richtung, d.h. man kann mit d verschlüsseln und mit e entschlüsseln - \begin{itemize*} \item Diese Eigenschaft erlaubt es, die gleichen Schlüssel d und e zu verwenden: \item den Empfang von Nachrichten, die mit dem eigenen öffentlichen Schlüssel verschlüsselt wurden \item Senden von Nachrichten, die mit dem eigenen privaten Schlüssel signiert wurden \end{itemize*} - \item - So richten Sie ein Schlüsselpaar für RSA ein: - + \item So richten Sie ein Schlüsselpaar für RSA ein: \begin{itemize*} \item Wählen Sie zufällig zwei Primzahlen \$p\$ und \$q\$ (mit jeweils 100 bis 200 Ziffern) \item Berechne \$n=p\textbackslash times q,\textbackslash phi(n)=(p-1)\textbackslash times (q-1)\$ (Lemma 2) @@ -1869,16 +1252,13 @@ \item Der öffentliche Schlüssel ist das Paar \$(e, n)\$ \item Der private Schlüssel ist das Paar \$(d, n)\$ \end{itemize*} - \item - Die Sicherheit des Verfahrens liegt in der Schwierigkeit der + \item Die Sicherheit des Verfahrens liegt in der Schwierigkeit der Faktorisierung von \$n=p\textbackslash times q\$, da es einfach ist, \$\textbackslash phi(n)\$ und dann \$d\$ zu berechnen, wenn \$p\$ und \$q\$ bekannt sind. - \item - In diesem Kurs wird nicht gelehrt, warum es schwierig ist, große n zu + \item In diesem Kurs wird nicht gelehrt, warum es schwierig ist, große n zu faktorisieren, da dies einen tiefen Einblick in die Mathematik erfordern würde. - \begin{itemize*} \item Wenn p und q bestimmte Eigenschaften erfüllen, sind die besten bekannten Algorithmen exponentiell zur Anzahl der Ziffern von n \item Bitte beachten Sie, dass es bei einer unglücklichen Wahl von p und q Algorithmen geben könnte, die effizienter faktorisieren können, und dass Ihre RSA-Verschlüsselung dann nicht mehr sicher ist: @@ -1893,44 +1273,35 @@ Hintergründe} \begin{itemize*} - \item - Definition: endliche Gruppen - + \item Definition: endliche Gruppen \begin{itemize*} \item Eine Gruppe ( S , \textbackslash oplus) ist eine Menge S zusammen mit einer binären Operation \textbackslash oplus, für die die folgende Eigenschaften gelten: \begin{itemize*} \item Geschlossenheit: Für alle a, b \textbackslash in S , haben wir a \textbackslash oplus b \textbackslash in S \item Identität: Es gibt ein Element e \textbackslash in S , so dass e \textbackslash oplus a = a \textbackslash oplus e = a für alle a \textbackslash in S \item Assoziativität: Für alle a, b, c \textbackslash in S , gilt ( a \textbackslash oplus b ) \textbackslash oplus c = a \textbackslash oplus ( b \textbackslash oplus c ) \item Inversen: Für jedes a \textbackslash in S , gibt es ein einziges Element b \textbackslash in S , so dass dass a \textbackslash oplus b = b \textbackslash oplus a = e \end{itemize*} \item Erfüllt eine Gruppe ( S , \textbackslash oplus) das Kommutativgesetz \textbackslash forall a, b \textbackslash in S : a \textbackslash oplus b = b \textbackslash oplus a dann nennt man sie eine abelsche Gruppe - \item Wenn eine Gruppe ( S , \textbackslash oplus) nur eine endliche Menge von Elementen hat, d.h. \textbar S\textbar{} \textless{} \textbackslash infty, dann wird sie eine endliche Gruppe genannt + \item Wenn eine Gruppe ( S , \textbackslash oplus) nur eine endliche Menge von Elementen hat, d.h. \textbar S| \textless{} \textbackslash infty, dann wird sie eine endliche Gruppe genannt \end{itemize*} - \item - Beispiele: - + \item Beispiele: \begin{itemize*} \item \$(\textbackslash mathbb\{Z\}\_n , +\_n)\$ - \begin{itemize*} \item mit \$\textbackslash mathbb\{Z\}\_n:=\{{[}0{]}\_n,{[}1{]}\_n,...,{[}n-1{]}\_n\}\$ \item wobei \${[}a{]}\_n:=\{b \textbackslash in \textbackslash mathbb\{Z\} \textbar{} b \textbackslash equiv a mod n\}\$ und \item \$+\_n\$ ist so definiert, dass \${[}a{]}\_n+\_n{[}b{]}\_n={[}a+b{]}\_n\$ \item eine endliche abelsche Gruppe ist. Für den Beweis siehe die Tabelle mit den Eigenschaften der modularen Arithmetik \end{itemize*} + \begin{itemize*} \item mit \$\textbackslash mathbb\{Z\}\_n:=\{{[}0{]}\_n,{[}1{]}\_n,...,{[}n-1{]}\_n\}\$ \item wobei \${[}a{]}\_n:=\{b \textbackslash in \textbackslash mathbb\{Z\} | b \textbackslash equiv a mod n\}\$ und \item \$+\_n\$ ist so definiert, dass \${[}a{]}\_n+\_n{[}b{]}\_n={[}a+b{]}\_n\$ \item eine endliche abelsche Gruppe ist. Für den Beweis siehe die Tabelle mit den Eigenschaften der modularen Arithmetik \end{itemize*} \item \$(\textbackslash mathbb\{Z\}\^{}*\_n , \textbackslash times\_n)\$ - \begin{itemize*} \item mit \$\textbackslash mathbb\{Z\}\^{}*\_n :=\{{[}a{]}\_n\textbackslash in \textbackslash mathbb\{Z\}\_n \textbar{} gcd(a,n)=1\}\$, und \item \$\textbackslash times\_n\$ ist so definiert, dass \${[}a{]}\_n\textbackslash times\_n {[}b{]}\_n={[}a\textbackslash times b{]}\_n\$ \item eine endliche abelsche Gruppe ist. Man beachte, dass \$\textbackslash mathbb\{Z\}\^{}*\_n\$ nur die Elemente von \$\textbackslash mathbb\{Z\}\_n\$ enthält, die eine multiplikative Inverse modulo n haben. Zum Beweis siehe Eigenschaften der modularen Arithmetik \item Beispiel: \$\textbackslash mathbb\{Z\}\^{}*\emph{\{15\}=\{{[}1{]}}\{15\},{[}2{]}\emph{\{15\},{[}4{]}}\{15\},{[}7{]}\emph{\{15\},{[}8{]}}\{15\},{[}11{]}\emph{\{15\},{[}13{]}}\{15\},{[}14{]}\_\{15\}\}\$, als \$1\textbackslash times 1\textbackslash equiv 1 mod 15\$, \$2 \textbackslash times 8 \textbackslash equiv 1 mod 15\$, \$4 \textbackslash times 4 \textbackslash equiv 1 mod 15\$, \$7 \textbackslash times 13 \textbackslash equiv 1 mod 15\$, \$11 \textbackslash times 11 \textbackslash equiv 1 mod 15\$, \$14 \textbackslash times 14 \textbackslash equiv 1 mod 15\$ \end{itemize*} + \begin{itemize*} \item mit \$\textbackslash mathbb\{Z\}\^{}*\_n :=\{{[}a{]}\_n\textbackslash in \textbackslash mathbb\{Z\}\_n | gcd(a,n)=1\}\$, und \item \$\textbackslash times\_n\$ ist so definiert, dass \${[}a{]}\_n\textbackslash times\_n {[}b{]}\_n={[}a\textbackslash times b{]}\_n\$ \item eine endliche abelsche Gruppe ist. Man beachte, dass \$\textbackslash mathbb\{Z\}\^{}*\_n\$ nur die Elemente von \$\textbackslash mathbb\{Z\}\_n\$ enthält, die eine multiplikative Inverse modulo n haben. Zum Beweis siehe Eigenschaften der modularen Arithmetik \item Beispiel: \$\textbackslash mathbb\{Z\}\^{}*\emph{\{15\}=\{{[}1{]}}\{15\},{[}2{]}\emph{\{15\},{[}4{]}}\{15\},{[}7{]}\emph{\{15\},{[}8{]}}\{15\},{[}11{]}\emph{\{15\},{[}13{]}}\{15\},{[}14{]}\_\{15\}\}\$, als \$1\textbackslash times 1\textbackslash equiv 1 mod 15\$, \$2 \textbackslash times 8 \textbackslash equiv 1 mod 15\$, \$4 \textbackslash times 4 \textbackslash equiv 1 mod 15\$, \$7 \textbackslash times 13 \textbackslash equiv 1 mod 15\$, \$11 \textbackslash times 11 \textbackslash equiv 1 mod 15\$, \$14 \textbackslash times 14 \textbackslash equiv 1 mod 15\$ \end{itemize*} \end{itemize*} - \item - Wenn klar ist, dass es sich um \$(\textbackslash mathbb\{Z\}\_n, + \item Wenn klar ist, dass es sich um \$(\textbackslash mathbb\{Z\}\_n, +\_n)\$ oder \$(\textbackslash mathbb\{Z\}\^{}*\_n, \textbackslash times\_n)\$ handelt, werden Äquivalenzklassen \${[}a{]}\_n\$ oft durch ihre repräsentativen Elemente a dargestellt und \$+\_n\$ und \$\textbackslash times\_n\$ durch \$+\$ bzw. \$\textbackslash times\$ bezeichnet. - \begin{itemize*} \item Definition: endliche Felder \begin{itemize*} \item Ein Feld \$(S,\textbackslash oplus, \textbackslash otimes)\$ ist eine Menge S zusammen mit zwei Operationen \$\textbackslash oplus\$, \$\textbackslash otimes\$, so dass \begin{itemize*} \item \$(S,\textbackslash oplus)\$ und \$(S\textbackslash backslash\{e\_\{\textbackslash oplus\}\},\textbackslash otimes)\$ sind kommutative Gruppen, d.h. nur das Identitätselement bezüglich der Operation \$\textbackslash oplus\$ muss kein Inverses bezüglich der Operation \$\textbackslash otimes\$ haben \item Für alle \$a,b,c\textbackslash in S\$ haben wir ein \$\textbackslash otimes(b\textbackslash oplus c)=(a\textbackslash otimes b)\textbackslash oplus(a\textbackslash otimes c)\$ \end{itemize*} \end{itemize*} \item Wenn \$\textbar S\textbar\textless\textbackslash infty\$ dann heißt \$(S,\textbackslash oplus,\textbackslash otimes)\$ ein endliches Feld \end{itemize*} - \item - Beispiel: \$(\textbackslash mathbb\{Z\}\_p, +\_p, + \item Beispiel: \$(\textbackslash mathbb\{Z\}\_p, +\_p, \textbackslash times\_p)\$ ist ein endliches Feld für jede Primzahl p - \item - Definition: Primitive Wurzel, Generator - + \item Definition: Primitive Wurzel, Generator \begin{itemize*} \item Sei \$(S,\textbackslash circ)\$ eine Gruppe, \$g\textbackslash in S\$ und \$g\^{}a:=g\textbackslash circ g\textbackslash circ...\textbackslash circ g\$ (a mal mit \$a\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$) \item Dann heißt g eine primitive Wurzel oder ein Generator von \$(S,\textbackslash circ):\textbackslash Leftrightarrow\{g\^{}a\textbar1\textbackslash leq a\textbackslash leq \textbar S\textbar\}=S\$ @@ -1938,52 +1309,38 @@ \begin{itemize*} \item 1 ist eine primitive Wurzel von \$(\textbackslash mathbb\{Z\}\_n, +\_n)\$ \item 3 ist eine Primitivwurzel von \$(\textbackslash mathbb\{Z\}\^{}*\_7, \textbackslash times\_7)\$ \end{itemize*} \item Nicht alle Gruppen haben Primitivwurzeln, und diejenigen, die sie haben, nennt man zyklische Gruppen \end{itemize*} - \item - Theorem 5: - + \item Theorem 5: \begin{itemize*} \item \$(\textbackslash mathbb\{Z\}\^{}*\_n, \textbackslash times\_n)\$ hat eine primitive Wurzel \$\textbackslash Leftrightarrow n\textbackslash in\{2,4,p,2\textbackslash times p\^{}e\}\$, wobei p eine ungerade Primzahl ist und \$e\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ \end{itemize*} - \item - Theorem 6: - + \item Theorem 6: \begin{itemize*} \item Wenn \$(S,\textbackslash circ)\$ eine Gruppe ist und \$b\textbackslash in S\$, dann ist \$(S',\textbackslash circ)\$ mit \$S'=\{b\^{}a\textbar a\textbackslash in\textbackslash mathbb\{Z\}\^{}+\}\$ ebenfalls eine Gruppe. \item Da \$S'\textbackslash subseteq S, heißt (S',\textbackslash circ)\$ eine Untergruppe von \$(S,\textbackslash circ)\$ \item Wenn b eine Urwurzel von \$(S,\textbackslash circ)\$ ist, dann ist \$S'=S\$ \end{itemize*} - \item - Definition: Ordnung einer Gruppe und eines Elements - + \item Definition: Ordnung einer Gruppe und eines Elements \begin{itemize*} \item Sei \$(S,\textbackslash circ)\$ eine Gruppe, \$e\textbackslash in S\$ ihr Identitätselement und \$b\textbackslash in S\$ irgendein Element von \$S\$: \begin{itemize*} \item Dann heiße \$\textbar S\textbar\$ die Ordnung von \$(S,\textbackslash circ)\$ \item Sei \$c\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ das kleinste Element, so dass \$b\^{}c=e\$ ist (falls ein solches c existiert, falls nicht, setze \$c=\textbackslash infty\$). Dann wird c die Ordnung von b genannt. \end{itemize*} \end{itemize*} - \item - Theorem 7 (Lagrange): - + \item Theorem 7 (Lagrange): \begin{itemize*} \item Ist G eine endliche Gruppe und H eine Untergruppe von G , so ist \$\textbar H\textbar\$ Teiler von \$\textbar G\textbar\$. \item Wenn also \$b in G\$ ist, dann ist die Ordnung von b Teiler von \$\textbar G\textbar\$. \end{itemize*} - \item - Theorem 8: - + \item Theorem 8: \begin{itemize*} \item Ist G eine zyklische endliche Gruppe der Ordnung n und d ist Teiler von n, dann hat G genau \$\textbackslash phi(d)\$ Elemente der Ordnung \$d\$. Insbesondere hat G \$\textbackslash phi(n)\$-Elemente der Ordnung n. \end{itemize*} - \item - Die Theoreme 5, 7 und 8 sind die Grundlage des folgenden Algorithmus, + \item Die Theoreme 5, 7 und 8 sind die Grundlage des folgenden Algorithmus, der eine zyklische Gruppe \$\textbackslash mathbb\{Z\}\^{}*\_p\$ und eine Urwurzel g davon findet: - \begin{itemize*} \item Man wählt eine große Primzahl q, so dass \$p=2q+1\$ eine Primzahl ist. \begin{itemize*} \item Da \$p\$ prim ist, besagt Satz 5, dass \$\textbackslash mathbb\{Z\}\^{}*\_p\$ zyklisch ist. \item Die Ordnung von \$\textbackslash mathbb\{Z\}\^{}*\_p\$ ist \$2\textbackslash times q\$ und \$\textbackslash phi(2\textbackslash times q)=\textbackslash phi(2)\textbackslash times \textbackslash phi(q)=q-1\$, da \$q\$ prim ist. \item Die Wahrscheinlichkeit, dass eine Primitivwurzel zufällig ausgewählt wird, beträgt also \$(q-1)/2q \textbackslash approx 1/2\$. \item Um effizient zu prüfen, ob ein zufällig gewähltes g eine Urwurzel ist, müssen wir nur prüfen, ob \$g\^{}2\textbackslash equiv 1 mod p\$ oder \$g\^{}q\textbackslash equiv 1 mod p\$ ist. Wenn nicht, dann muss seine Ordnung \$\textbar\textbackslash mathbb\{Z\}\^{}\emph{\_p\textbar\$ sein, da Satz 7 besagt, dass die Ordnung von g \$\textbar\textbackslash mathbb\{Z\}\^{}}\_p\textbar\$ teilen muss \end{itemize*} \end{itemize*} - \item - Definition: diskreter Logarithmus - + \item Definition: diskreter Logarithmus \begin{itemize*} \item Sei p eine Primzahl, g eine Urwurzel von \$(\textbackslash mathbb\{Z\}\^{}\emph{\_p,\textbackslash times\_p)\$ und c ein beliebiges Element von \$\textbackslash mathbb\{Z\}\^{}}\_p\$. Dann gibt es z so, dass: \$g\^{}z\textbackslash equiv c mod p\$ \item z wird der diskrete Logarithmus von c modulo p zur Basis g genannt @@ -1996,26 +1353,21 @@ \subsection{Diffie-Hellman-Schlüsselaustausch} \begin{itemize*} - \item - Der Diffie-Hellman-Schlüsselaustausch wurde erstmals in der + \item Der Diffie-Hellman-Schlüsselaustausch wurde erstmals in der bahnbrechenden Arbeit {[}DH76{]} veröffentlicht, in der auch die Grundidee der asymmetrischen Kryptographie vorgestellt wurde - \item - Der DH-Austausch in seiner Grundform ermöglicht es zwei Parteien A und + \item Der DH-Austausch in seiner Grundform ermöglicht es zwei Parteien A und B, sich über einen öffentlichen Kanal auf ein gemeinsames Geheimnis zu einigen: - \begin{itemize*} \item Öffentlicher Kanal bedeutet, dass ein potentieller Angreifer E (E steht für Eavesdropper) alle zwischen A und B ausgetauschten Nachrichten lesen kann \item Es ist wichtig, dass A und B sicher sein können, dass der Angreifer nicht in der Lage ist, Nachrichten zu verändern, da er in diesem Fall einen Man-in-the-Middle-Angriff starten könnte \item Die mathematische Grundlage für den DH-Austausch ist das Problem, diskrete Logarithmen in endlichen Feldern zu finden. \item Der DH-Austausch ist kein asymmetrischer Verschlüsselungsalgorithmus, wird aber dennoch hier vorgestellt, da er gut zum mathematischen Charakter dieser Vorlesung passt... \end{itemize*} - \item - Wenn Alice (A) und Bob (B) sich auf ein gemeinsames Geheimnis s + \item Wenn Alice (A) und Bob (B) sich auf ein gemeinsames Geheimnis s einigen wollen und ihr einziges Kommunikationsmittel ein öffentlicher Kanal ist, können sie wie folgt vorgehen: - \begin{itemize*} \item A wählt eine Primzahl p, eine primitive Wurzel g von \$\textbackslash mathbb\{Z\}\^{}*\_p\$ und eine Zufallszahl q: \begin{itemize*} \item A und B können sich vor der Kommunikation auf die Werte p und g einigen, oder A wählt p und g und sendet sie mit seiner ersten Nachricht \item A berechnet \$v=g\^{}q\textbackslash{} MOD\textbackslash{} p\$ und sendet an \$B:\{p,g,v\}\$ \end{itemize*} @@ -2025,11 +1377,9 @@ \begin{itemize*} \item A errechnet \$s=w\^{}q\textbackslash{} MOD\textbackslash{} p\$ \item B errechnet \$s'=v\^{}r\textbackslash{} MOD\textbackslash{} p\$ \item Da \$g\^{}\{q\textbackslash times r\}\textbackslash{} MOD\textbackslash{} p = g\^{}\{r \textbackslash times q\}\textbackslash{} MOD\textbackslash{} p\$ ist, gilt: \$s=s'\$ \end{itemize*} \item Ein Angreifer Eve, der den öffentlichen Kanal abhört, kann das Geheimnis s nur berechnen, wenn er entweder q oder r berechnen kann, die die diskreten Logarithmen von v, w modulo p zur Basis g sind. \end{itemize*} - \item - Wenn der Angreifer Eve in der Lage ist, Nachrichten auf dem + \item Wenn der Angreifer Eve in der Lage ist, Nachrichten auf dem öffentlichen Kanal zu verändern, kann er einen Man-in-the-Middle-Angriff starten: - \begin{itemize*} \item Eve generiert zwei Zufallszahlen \$q'\$ und \$r'\$: Eve berechnet \$v'=g\^{}\{q'\}\textbackslash{} MOD\textbackslash{} p\$ und \$w'=g\^{}\{r'\}\textbackslash{} MOD\textbackslash{} p\$ \item Wenn A \$\{p,g,v\}\$ sendet, fängt sie die Nachricht ab und sendet an \$B:\{p,g,v'\}\$ @@ -2038,9 +1388,7 @@ \begin{itemize*} \item A berechnet \$s\_1=w'\^{}q\textbackslash{} MOD\textbackslash{} p = v\^{}\{r'\}\textbackslash{} MOD\textbackslash{} p\$, letzteres berechnet von E \item B berechnet \$s\_2=v'\^{}r\textbackslash{} MOD\textbackslash{} p = w\^{}\{q'\}\textbackslash{} MOD\textbackslash{} p\$, letzteres berechnet von E \item A und E haben sich also auf ein gemeinsames Geheimnis \$s\_1\$ geeinigt, und E und B haben sich auf ein gemeinsames Geheimnis \$s\_2\$ geeinigt. \end{itemize*} \item Wenn das ,,gemeinsame Geheimnis'' nun von A und B verwendet wird, um Nachrichten zu verschlüsseln, die über den öffentlichen Kanal ausgetauscht werden sollen, kann E alle Nachrichten abfangen und ent- bzw. wiederverschlüsseln, bevor er sie zwischen A und B weiterleitet. \end{itemize*} - \item - Zwei Gegenmaßnahmen gegen den Man-in-the-Middle-Angriff: - + \item Zwei Gegenmaßnahmen gegen den Man-in-the-Middle-Angriff: \begin{itemize*} \item Das gemeinsame Geheimnis wird ,,authentifiziert'', nachdem es vereinbart worden ist. \begin{itemize*} \item Wir werden dies im Abschnitt über die Schlüsselverwaltung behandeln \end{itemize*} @@ -2048,8 +1396,7 @@ \begin{itemize*} \item Dazu müssen sie Nachrichten austauschen, die E weiterleiten muss, bevor sie sie entschlüsseln bzw. wieder verschlüsseln kann. \item Der Inhalt dieser Nachrichten muss von A und B überprüfbar sein. \item Dies zwingt E dazu, Nachrichten zu erfinden, und sie kann entdeckt werden. \item Eine Technik, um zu verhindern, dass E die Nachrichten entschlüsselt, besteht darin, sie in zwei Teile aufzuteilen und den zweiten Teil vor dem ersten zu senden. \begin{itemize*} \item Wenn der verwendete Verschlüsselungsalgorithmus bestimmte Eigenschaften verhindert, kann E den zweiten Teil nicht verschlüsseln, bevor sie den ersten erhält. \item Da A den ersten Teil erst senden wird, nachdem er eine Antwort (den zweiten Teil) von B erhalten hat, ist E gezwungen, zwei Nachrichten zu erfinden, bevor sie die ersten Teile erhalten kann. \end{itemize*} \end{itemize*} \end{itemize*} - \item - Bemerkung: In der Praxis muss die Zahl g nicht unbedingt eine Urwurzel + \item Bemerkung: In der Praxis muss die Zahl g nicht unbedingt eine Urwurzel von p sein, es genügt, wenn sie eine große Untergruppe von \$\textbackslash mathbb\{Z\}\^{}*\_p\$ erzeugt \end{itemize*} @@ -2058,23 +1405,17 @@ \subsection{ElGamal Algorithmus} \begin{itemize*} - \item - Der ElGamal-Algorithmus kann sowohl für die Verschlüsselung als auch + \item Der ElGamal-Algorithmus kann sowohl für die Verschlüsselung als auch für digitale Signaturen verwendet werden (siehe auch {[}ElG85a{]}). - \item - Wie der DH-Austausch basiert er auf der Schwierigkeit, diskrete + \item Wie der DH-Austausch basiert er auf der Schwierigkeit, diskrete Logarithmen in endlichen Feldern zu berechnen - \item - Um ein Schlüsselpaar zu erstellen: - + \item Um ein Schlüsselpaar zu erstellen: \begin{itemize*} \item Wähle eine große Primzahl p, einen Generator g der multiplikativen Gruppe \$\textbackslash mathbb\{Z\}\^{}*\_p\$ und eine Zufallszahl v, so dass \$1\textbackslash leq v\textbackslash leq p - 2\$. Berechnen Sie: \$y=g\^{}v mod p\$ \item Der öffentliche Schlüssel ist \$( y, g, p )\$ \item Der private Schlüssel ist v \end{itemize*} - \item - So signieren Sie eine Nachricht m : - + \item So signieren Sie eine Nachricht m : \begin{itemize*} \item Wähle eine Zufallszahl k so, dass k relativ prim zu \$p-1\$ ist. \item Berechne \$r=g\^{}k mod p\$ @@ -2082,9 +1423,7 @@ \item Berechne \$s=k\^{}\{-1\} \textbackslash times ( m - v \textbackslash times r) mod ( p - 1)\$ \item Die Signatur über die Nachricht ist \$( r, s )\$ \end{itemize*} - \item - Überprüfen einer Signatur \$( r , s )\$ über eine Nachricht m: - + \item Überprüfen einer Signatur \$( r , s )\$ über eine Nachricht m: \begin{itemize*} \item Bestätige, dass \$y\^{}r \textbackslash times r\^{}s\textbackslash{} MOD\textbackslash{} p = g\^{}m\textbackslash{} MOD\textbackslash{} p\$ \item Der Beweis: Wir benötigen Folgendes @@ -2092,35 +1431,27 @@ \item Als \$s\textbackslash equiv k\^{}\{-1\}\textbackslash times(m-v\textbackslash times r) mod (p-1)\$ \begin{itemize*} \item \$\textbackslash Leftrightarrow k \textbackslash times s\textbackslash equiv m-v\textbackslash times r mod (p-1)\$ \item \$\textbackslash Leftrightarrow m \textbackslash equiv v\textbackslash times r+k\textbackslash times s mod (p-1)\$ \item \$\textbackslash Rightarrow g\^{}m \textbackslash equiv g\^{}\{(v\textbackslash times r+ k\textbackslash times s)\} mod p\$ mit Lemma 3 \item \$\textbackslash Leftrightarrow g\^{}m \textbackslash equiv g\^{}\{(v\textbackslash times r)\}\textbackslash times g\^{}\{(k\textbackslash times s)\} mod p\$ \item \$\textbackslash Leftrightarrow g\^{}m \textbackslash equiv y\^{}r\textbackslash times r\^{}s mod p\$ \end{itemize*} \end{itemize*} - \item - Sicherheit von ElGamal-Signaturen: - + \item Sicherheit von ElGamal-Signaturen: \begin{itemize*} \item Da der private Schlüssel v benötigt wird, um s berechnen zu können, müsste ein Angreifer den diskreten Logarithmus von y modulo p zur Basis g berechnen, um Signaturen zu fälschen \item Entscheidend für die Sicherheit ist, dass für jede Nachricht eine neue Zufallszahl k gewählt wird, denn ein Angreifer kann das Geheimnis v berechnen, wenn er zwei Nachrichten zusammen mit ihren Signaturen auf der Basis des gleichen k erhält (siehe {[}Men97a{]}, Anmerkung 11.66.ii) \item Um zu verhindern, dass ein Angreifer eine Nachricht M mit einer passenden Signatur erstellen kann, ist es notwendig, die Nachricht M nicht direkt zu signieren, sondern einen kryptographischen Hashwert \$m=h(M)\$ davon zu signieren (diese werden bald behandelt, siehe auch {[}Men97a{]}, Anmerkung 11.66.iii) \end{itemize*} - \item - Um eine Nachricht m mit dem öffentlichen Schlüssel \$(y,g,p)\$ zu + \item Um eine Nachricht m mit dem öffentlichen Schlüssel \$(y,g,p)\$ zu verschlüsseln: - \begin{itemize*} \item Wähle einen zufälligen \$k\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ mit \$k\textless p-1\$ \item Berechne \$r=g\^{}k\textbackslash{} MOD\textbackslash{} p\$ \item Berechne \$s=m\textbackslash times y\^{}k\textbackslash{} MOD\textbackslash{} p\$ \item Der verschlüsselte Text ist \$(r,s)\$, der doppelt so lang ist wie m \end{itemize*} - \item - Entschlüsseln der Nachricht \$(r,s)\$ mit v: - + \item Entschlüsseln der Nachricht \$(r,s)\$ mit v: \begin{itemize*} \item Verwenden Sie den privaten Schlüssel v zur Berechnung von \$r\^{}\{(p-1-v)\}\textbackslash{} MOD\textbackslash{} p=r\^{}\{(-v)\}\textbackslash{} MOD\textbackslash{} p\$ \item Wiederherstellung von m durch Berechnung von \$m=r\^{}\{(-v)\}\textbackslash times s\textbackslash{} MOD\textbackslash{} p\$ \item Beweis: \$r\^{}\{(-v)\}\textbackslash times s\textbackslash equiv r\^{}\{(-v)\} \textbackslash times m \textbackslash times y\^{}k\textbackslash equiv g\^{}\{(-vk)\}\textbackslash times m \textbackslash times y\^{}k\textbackslash equiv g\^{}\{(-v \textbackslash times k)\} \textbackslash times m\textbackslash times g\^{}\{(v \textbackslash times k)\} \textbackslash equiv m mod p\$ \end{itemize*} - \item - Sicherheit: - + \item Sicherheit: \begin{itemize*} \item Die einzige bekannte Möglichkeit für einen Angreifer, m wiederherzustellen, ist die Berechnung des diskreten Logarithmus v von y modulo p zur Basis g \item Für jede Nachricht wird ein neues zufälliges k benötigt ({[}Men97a{]}, Anmerkung 8.23.ii) @@ -2132,28 +1463,22 @@ Kryptographie} \begin{itemize*} - \item - Die bisher vorgestellten Algorithmen wurden für die multiplikative + \item Die bisher vorgestellten Algorithmen wurden für die multiplikative Gruppe \$(\textbackslash mathbb\{Z\}\^{}*\_p,\textbackslash times p)\$ bzw. das Feld \$(\textbackslash mathbb\{Z\}\_p, +\_p, \textbackslash times\_p)\$ entwickelt. - \item - In den 1980er Jahren wurde festgestellt, dass sie verallgemeinert und + \item In den 1980er Jahren wurde festgestellt, dass sie verallgemeinert und auch für andere Gruppen und Felder verwendet werden können - \item - Die Hauptmotivation für diese Verallgemeinerung ist: - + \item Die Hauptmotivation für diese Verallgemeinerung ist: \begin{itemize*} \item Zahlreiche mathematische Forschungen auf dem Gebiet der Primzahlprüfung, der Faktorisierung und der Berechnung diskreter Logarithmen haben zu Techniken geführt, mit denen diese Probleme effizienter gelöst werden können, wenn bestimmte Eigenschaften erfüllt sind: \begin{itemize*} \item Als 1977 die RSA-129-Aufgabe gestellt wurde, ging man davon aus, dass es etwa 40 Billiarden Jahre dauern würde, die 129-stellige Zahl (\$\textbackslash approx 428\$ Bit) zu faktorisieren. \item Im Jahr 1994 benötigte eine Gruppe von Computern, die über das Internet vernetzt waren, 8 Monate, um die Zahl zu faktorisieren, was etwa 5000 MIPS-Jahre entsprach. \item Fortschritte bei den Faktorisierungsalgorithmen ermöglichten 2009 die Faktorisierung einer 232-stelligen Zahl (768 Bit) in etwa 1500 AMD64-Jahren {[}KAFL10{]}. \item \$\textbackslash Rightarrow\$ die Schlüssellänge muss erhöht werden (derzeit etwa 2048 Bit) \end{itemize*} \item Einige der effizienteren Verfahren beruhen auf bestimmten Eigenschaften der algebraischen Strukturen \$(\textbackslash mathbb\{Z\}\^{}*\_p,\textbackslash times p)\$ und \$(\textbackslash mathbb\{Z\}\_p, +\_p, \textbackslash times\_p)\$ \item Verschiedene algebraische Strukturen können daher die gleiche Sicherheit mit kürzeren Schlüssellängen bieten \end{itemize*} - \item - Eine sehr vielversprechende Struktur für die Kryptographie lässt sich + \item Eine sehr vielversprechende Struktur für die Kryptographie lässt sich aus der Gruppe der Punkte auf einer elliptischen Kurve über einem endlichen Feld gewinnen - \begin{itemize*} \item Die mathematischen Operationen in diesen Gruppen können sowohl in Hardware als auch in Software effizient implementiert werden. \item Das Problem des diskreten Logarithmus gilt in der allgemeinen Klasse, die sich aus der Gruppe der Punkte auf einer elliptischen Kurve über einem endlichen Feld ergibt, als schwierig @@ -2165,7 +1490,6 @@ \begin{itemize*} \item Algebraische Gruppe bestehend aus - \begin{itemize*} \item Punkte auf der Weierstraß'schen Gleichung: \$y\^{}2 = x\^{}3 + ax + b\$ \item Zusätzlicher Punkt O im ,,Unendlichen'' @@ -2173,7 +1497,6 @@ \item Kann über \$\textbackslash mathbb\{R\}\$ berechnet werden, aber in der Kryptographie werden \$\textbackslash mathbb\{Z\}\_p\$ und \$GF(2\^{}n)\$ verwendet - \begin{itemize*} \item Schon in \$\textbackslash mathbb\{R\}\$ beeinflussen Argumente die Form erheblich: \begin{itemize*} @@ -2194,9 +1517,7 @@ \item Im Allgemeinen ist die Summe von zwei Punkten P und Q gleich \$-R\$ % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ecc-3.png} \end{itemize*} - \item - Addition (Sonderfälle) - + \item Addition (Sonderfälle) \begin{itemize*} \item Der zusätzliche Punkt O ist das neutrale Element, d.h. \$P+O=P\$ \item \$P + (-P)\$: @@ -2211,12 +1532,9 @@ Addition} \begin{itemize*} - \item - Wenn einer der Summanden O ist, ist die Summe der andere Summand - \item - Wenn die Summanden zueinander invers sind, ist die Summe O - \item - Für die allgemeineren Fälle ist die Steigung der Geraden: + \item Wenn einer der Summanden O ist, ist die Summe der andere Summand + \item Wenn die Summanden zueinander invers sind, ist die Summe O + \item Für die allgemeineren Fälle ist die Steigung der Geraden: \$\textbackslash alpha=\textbackslash begin\{cases\} \textbackslash frac\{y\_Q-y\_P\}\{x\_Q-x\_P\} \textbackslash quad\textbackslash text\{ for \} P\textbackslash not=-Q @@ -2224,8 +1542,7 @@ \textbackslash frac\{3x\^{}2\_P +a\}\{2y\_P\} \textbackslash quad\textbackslash text\{ for \} P=Q \textbackslash end\{cases\}\$ - \item - Ergebnis der Punktaddition, wobei \$(x\_r,y\_r)\$ bereits der + \item Ergebnis der Punktaddition, wobei \$(x\_r,y\_r)\$ bereits der Spiegelpunkt \$(-R)\$ ist \end{itemize*} @@ -2233,24 +1550,18 @@ \subsubsection{Multiplikation} \begin{itemize*} - \item - Multiplikation von natürlicher Zahl n und Punkt P durch mehrfache + \item Multiplikation von natürlicher Zahl n und Punkt P durch mehrfache wiederholte Additionen - \item - Zahlen werden in 2er-Potenzen gruppiert, um eine logarithmische + \item Zahlen werden in 2er-Potenzen gruppiert, um eine logarithmische Laufzeit zu erreichen, z.B. \$25P = P + 8P + 16P\$ - \item - Dies ist nur möglich, wenn das n bekannt ist! - \item - Wenn n für \$nP = Q\$ unbekannt ist, muss ein Logarithmus gelöst + \item Dies ist nur möglich, wenn das n bekannt ist! + \item Wenn n für \$nP = Q\$ unbekannt ist, muss ein Logarithmus gelöst werden, was möglich ist, wenn die Koordinatenwerte aus \$\textbackslash mathbb\{R\}\$ gewählt werden - \item - Für \$\textbackslash mathbb\{Z\}\_p\$ und \$GF(2\^{}n)\$ muss das + \item Für \$\textbackslash mathbb\{Z\}\_p\$ und \$GF(2\^{}n)\$ muss das diskrete Logarithmusproblem für elliptische Kurven gelöst werden, was nicht effizient durchgeführt werden kann! - \item - Hinweis: Es ist nicht definiert, wie zwei Punkte multipliziert werden, + \item Hinweis: Es ist nicht definiert, wie zwei Punkte multipliziert werden, sondern nur eine natürliche Zahl n und der Punkt P \end{itemize*} @@ -2259,12 +1570,9 @@ \$\textbackslash mathbb\{Z\}\_p\$} \begin{itemize*} - \item - Über \$\textbackslash mathbb\{Z\}\_p\$ zerfällt die Kurve in eine + \item Über \$\textbackslash mathbb\{Z\}\_p\$ zerfällt die Kurve in eine Menge von Punkten - \item - Für: \$y\^{}2=x\^{}3-3x+5\textbackslash{} mod\textbackslash{} 19\$ - + \item Für: \$y\^{}2=x\^{}3-3x+5\textbackslash{} mod\textbackslash{} 19\$ \begin{itemize*} % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ecc-5.png} \item Hinweis: Für einige x-Werte gibt es keinen y-Wert! @@ -2276,38 +1584,30 @@ \$\textbackslash mathbb\{Z\}\_p\$} \begin{itemize*} - \item - Im Allgemeinen etwas problematischer: Bestimmen Sie die y-Werte für + \item Im Allgemeinen etwas problematischer: Bestimmen Sie die y-Werte für ein gegebenes x (da sein quadratischer Wert berechnet wird) durch \$y\^{}2\textbackslash equiv f(x)\textbackslash{} mod\textbackslash{} p\$ - \item - Daher wird p oft s.t. gewählt \$p\textbackslash equiv + \item Daher wird p oft s.t. gewählt \$p\textbackslash equiv 3\textbackslash{} mod\textbackslash{} 4\$ - \item - Dann wird y durch \$y\_1\textbackslash equiv + \item Dann wird y durch \$y\_1\textbackslash equiv f(x)\^{}\{\textbackslash frac\{p+1\}\{4\}\}\$ und \$y\_2\textbackslash equiv -f(x)\^{}\{\textbackslash frac\{p+1\}\{4\}\}\$ berechnet, wenn und nur wenn überhaupt eine Lösung existiert - \item - Kurzer Beweis: - + \item Kurzer Beweis: \begin{itemize*} \item Aus dem Euler-Theorem 3 wissen wir, dass \$f(x)\^{}\{p-1\}\textbackslash equiv 1\textbackslash{} mod\textbackslash{} p\$ \item Die Quadratwurzel muss also 1 oder -1 sein \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv\textbackslash pm 1\textbackslash{} mod\textbackslash{} p\$ \end{itemize*} - \item - Fall 1: + \item Fall 1: \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv1\textbackslash{} mod\textbackslash{} p\$ - \begin{itemize*} \item Multiplizieren Sie beide Seiten mit f(x): \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv f(x)\textbackslash equiv y\^{}2\textbackslash{} mod\textbackslash{} p\$ \item Da \$p + 1\$ durch 4 teilbar ist, können wir die Quadratwurzel ziehen, so dass \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv y\textbackslash{} mod\textbackslash{} p\$ \end{itemize*} - \item - Fall 2: In diesem Fall existiert keine Lösung für den gegebenen x-Wert + \item Fall 2: In diesem Fall existiert keine Lösung für den gegebenen x-Wert (wie von Euler gezeigt) \end{itemize*} @@ -2316,30 +1616,22 @@ \$\textbackslash mathbb\{Z\}\_p\$} \begin{itemize*} - \item - Aufgrund des diskreten Strukturpunktes haben mathematische Operationen + \item Aufgrund des diskreten Strukturpunktes haben mathematische Operationen keine geometrische Interpretation mehr, sondern - \item - Algebraische Addition ähnlich der Addition über + \item Algebraische Addition ähnlich der Addition über \$\textbackslash mathbb\{R\}\$ - \item - Wird der inverse Punkt zu P addiert, schneiden sich Linie und + \item Wird der inverse Punkt zu P addiert, schneiden sich Linie und ,,Kurve'' immer noch im ,,Unendlichen'' - \item - Alle x- und y-Werte werden mod p berechnet - \item - Division wird durch Multiplikation mit dem inversen Element des + \item Alle x- und y-Werte werden mod p berechnet + \item Division wird durch Multiplikation mit dem inversen Element des Nenners ersetzt - \begin{itemize*} \item Verwendung des erweiterten euklidischen Algorithmus mit w und p zur Ableitung der Inversen \$-w\$ \end{itemize*} - \item - Die algebraische Multiplikation einer natürlichen Zahl n und eines + \item Die algebraische Multiplikation einer natürlichen Zahl n und eines Punktes P erfolgt ebenfalls durch wiederholte Addition von Summanden der Potenz von 2 - \item - Das Problem des diskreten Logarithmus ist die Bestimmung einer + \item Das Problem des diskreten Logarithmus ist die Bestimmung einer natürlichen Zahl n in \$nP=Q\$ für zwei bekannte Punkte P und Q \end{itemize*} @@ -2348,35 +1640,28 @@ Gruppen} \begin{itemize*} - \item - Bitte beachten Sie, dass die Ordnung einer durch einen Punkt auf einer + \item Bitte beachten Sie, dass die Ordnung einer durch einen Punkt auf einer Kurve über \$\textbackslash mathbb\{Z\}\_p\$ erzeugten Gruppe nicht \$p-1\$ ist! - \item - Die Bestimmung der exakten Ordnung ist nicht einfach, kann aber mit + \item Die Bestimmung der exakten Ordnung ist nicht einfach, kann aber mit Schoofs Algorithmus {[}Sch85{]} in logarithmischer Zeit durchgeführt werden (erfordert viel mehr mathematischen Hintergrund als hier gewünscht) - \item - Der Satz von Hasse über elliptische Kurven besagt jedoch, dass die + \item Der Satz von Hasse über elliptische Kurven besagt jedoch, dass die Gruppengröße n zwischen: \$p+1 - 2\textbackslash sqrt\{p\}\textbackslash leq n\textbackslash leq p+1+2\textbackslash sqrt\{p\}\$ liegen muss - \item - Wie bereits erwähnt: Es genügt, relativ große Gruppen zu erzeugen + \item Wie bereits erwähnt: Es genügt, relativ große Gruppen zu erzeugen \end{itemize*} \subsubsection{ECDH} \begin{itemize*} - \item - Der Diffie-Hellman-Algorithmus kann leicht an elliptische Kurven + \item Der Diffie-Hellman-Algorithmus kann leicht an elliptische Kurven angepasst werden - \item - Wenn Alice (A) und Bob (B) sich auf ein gemeinsames Geheimnis s + \item Wenn Alice (A) und Bob (B) sich auf ein gemeinsames Geheimnis s einigen wollen: - \begin{itemize*} \item A und B einigen sich auf eine kryptographisch sichere elliptische Kurve und einen Punkt P auf dieser Kurve \item A wählt eine Zufallszahl q: @@ -2386,8 +1671,7 @@ \item Beide Seiten errechnen das gemeinsame Geheimnis: \begin{itemize*} \item A errechnet \$S=qR\$ \item B errechnet \$S'=rQ\$ \item Da \$qrP=rqP\$ der geheime Punkt \$S=S'\$ \end{itemize*} \end{itemize*} - \item - Angreifer, die den öffentlichen Kanal abhören, können S nur berechnen, + \item Angreifer, die den öffentlichen Kanal abhören, können S nur berechnen, wenn sie entweder q oder r berechnen können, die die diskreten Logarithmen von Q und R für den Punkt P sind \end{itemize*} @@ -2397,20 +1681,15 @@ ElGamal-Algorithmus} \begin{itemize*} - \item - Die Anpassung von ElGamal für elliptische Kurven ist für die + \item Die Anpassung von ElGamal für elliptische Kurven ist für die Verschlüsselungsroutine recht einfach - \item - Ein Schlüsselpaar einrichten: - + \item Ein Schlüsselpaar einrichten: \begin{itemize*} \item Wählen Sie eine elliptische Kurve über einem endlichen Feld, einen Punkt G, der eine große Gruppe erzeugt, und eine Zufallszahl v, so dass \$1 \textless{} v \textless{} n\$, wobei n die Größe der induzierten Gruppe bezeichnet, Berechnen Sie: \$Y = vG\$ \item Der öffentliche Schlüssel ist \$(Y,G,Kurve)\$ \item Der private Schlüssel ist v \end{itemize*} - \item - Um eine Nachricht zu verschlüsseln: - + \item Um eine Nachricht zu verschlüsseln: \begin{itemize*} \item Wähle eine zufällige \$k\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ mit \$k\textless n-1\$, berechne \$R=kG\$ \item Berechne \$S=M+kY\$, wobei M ein von der Nachricht abgeleiteter Punkt ist @@ -2418,32 +1697,24 @@ \item Der Chiffretext sind die Punkte \$(R,S)\$ \item Doppelt so lang wie m, wenn sie in so genannter komprimierter Form gespeichert werden, d.h. nur die x-Koordinaten werden gespeichert und ein einziges Bit, das angibt, ob die größere oder kleinere entsprechende y-Koordinate verwendet werden soll \end{itemize*} - \item - Um eine Nachricht zu entschlüsseln: - + \item Um eine Nachricht zu entschlüsseln: \begin{itemize*} \item Ableitung von M durch Berechnung von \$S-vR\$ \item Beweis: \$S-vR=M+kY-vR =M+kvG-vkG= M+O= M\$ \end{itemize*} - \item - Eine Nachricht signieren: - + \item Eine Nachricht signieren: \begin{itemize*} \item Wähle ein zufälliges \$k\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ mit \$k\textless n-1\$, berechne \$R = kG\$ \item Berechne \$s=k\^{}\{-1\}(m+rv) mod\textbackslash{} n\$, wobei \$r\$ der x-Wert von R ist \item Die Signatur ist \$(r,s)\$, wiederum etwa doppelt so lang wie n \end{itemize*} - \item - Überprüfen einer signierten Nachricht: - + \item Überprüfen einer signierten Nachricht: \begin{itemize*} \item Prüfen, ob der Punkt \$P=ms\^{}\{-1\}G+rs\^{}\{-1\}Y\$ die x-Koordinate r hat \item Anmerkung: \$s\^{}\{-1\}\$ wird durch den Erweiterten Euklidischen Algorithmus mit den Eingaben s und n (der Ordnung der Gruppe) berechnet. \item Beweis: \$ms\^{}\{-1\}G+rs\^{}\{-1\}Y = ms\^{}\{-1\}G+rs\^{}\{-1\}vG = (m+rv)(s\^{}\{-1\})G = (ks)(s\^{}\{-1\})G = kG = R\$ \end{itemize*} - \item - Diskussion zur Sicherheit: - + \item Diskussion zur Sicherheit: \begin{itemize*} \item Wie in der ursprünglichen Version von ElGamal ist es entscheidend, k nicht zweimal zu verwenden \item Nachrichten sollten nicht direkt signiert werden @@ -2455,51 +1726,39 @@ \subsubsection{Sicherheit} \begin{itemize*} - \item - Die Sicherheit hängt stark von der gewählten Kurve und dem Punkt ab: - \item - Die Diskriminante der Kurve darf nicht Null sein, d.h. + \item Die Sicherheit hängt stark von der gewählten Kurve und dem Punkt ab: + \item Die Diskriminante der Kurve darf nicht Null sein, d.h. \$4a\^{}3+27b\^{}2\textbackslash not\textbackslash equiv 0\textbackslash{} mod\textbackslash{} p\$ sonst ist die Kurve degradiert (eine sogenannte ,,singuläre Kurve'' ) - \item - Menezes et. al. haben einen subexponentiellen Algorithmus für + \item Menezes et. al. haben einen subexponentiellen Algorithmus für sogenannte ,,supersinguläre elliptische Kurven'' gefunden, der aber im allgemeinen Fall nicht funktioniert {[}Men93a{]} - \item - Die konstruierten algebraischen Gruppen sollten so viele Elemente wie + \item Die konstruierten algebraischen Gruppen sollten so viele Elemente wie möglich haben. - \item - In diesem Kurs wird nicht näher auf die Kryptographie elliptischer + \item In diesem Kurs wird nicht näher auf die Kryptographie elliptischer Kurven eingegangen, da dies viel mehr Mathematik erfordert, als für diesen Kurs erwünscht ist... - \item - Für Nicht-Kryptographen ist es am besten, sich auf vordefinierte + \item Für Nicht-Kryptographen ist es am besten, sich auf vordefinierte Kurven zu verlassen, z.B. {[}LM10{]} oder {[}NIST99{]} und Standards wie ECDSA - \item - Viele Veröffentlichungen wählen die Parameter a und b so, dass sie + \item Viele Veröffentlichungen wählen die Parameter a und b so, dass sie nachweislich durch einen Zufallsprozess gewählt werden (z.B. veröffentlichen Sie x für \$h(x)=a\$ und \$y\$ für \$h(y) = b\$); so soll sichergestellt werden, dass die Kurven keine kryptographische Schwäche enthalten, die nur den Autoren bekannt ist - \item - Die Sicherheit ist abhängig von der Länge von p - + \item Die Sicherheit ist abhängig von der Länge von p \begin{itemize*} - \item Schlüssellängen mit vergleichbaren Stärken nach {[}NIST12{]}: \textbar{} Symmetrische Algorithmen \textbar{} RSA \textbar{} ECC \textbar{} \textbar{} -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{} -\/-\/-\/-\/- \textbar{} -\/-\/-\/-\/-\/-\/- \textbar{} \textbar{} 112 \textbar{} 2048 \textbar{} 224-255 \textbar{} \textbar{} 128 \textbar{} 3072 \textbar{} 256-383 \textbar{} \textbar{} 192 \textbar{} 7680 \textbar{} 384-511 \textbar{} \textbar{} 256 \textbar{} 15360 \textbar{} \textgreater{} 512 \textbar{} + \item Schlüssellängen mit vergleichbaren Stärken nach {[}NIST12{]}: | Symmetrische Algorithmen | RSA | ECC | | ------------------------ | ----- | ------- | | 112 | 2048 | 224-255 | | 128 | 3072 | 256-383 | | 192 | 7680 | 384-511 | | 256 | 15360 | \textgreater{} 512 | \end{itemize*} - \item - Die Sicherheit hängt auch stark von der Implementierung ab! - + \item Die Sicherheit hängt auch stark von der Implementierung ab! \begin{itemize*} \item Die verschiedenen Fälle (z.B. mit O) in der ECC-Berechnung können beobachtbar sein, d.h. Stromverbrauch und Zeitunterschiede \item Angreifer können Seitenkanalangriffe ableiten, wie in OpenSSL 0.9.8o {[}BT11{]} \begin{itemize*} \item Ein Angreifer kann die Bitlänge eines Wertes k in \$kP\$ ableiten, indem er die für den Quadrat- und Multiplikationsalgorithmus benötigte Zeit misst \item Der Algorithmus wurde in OpenSSL frühzeitig abgebrochen, wenn keine weiteren Bits auf ,,1'' gesetzt wurden \end{itemize*} \item Angreifer könnten versuchen, ungültige Punkte zu generieren, um Fakten über den verwendeten Schlüssel abzuleiten, wie in OpenSSL 0.9.8g, was zu einer Wiederherstellung eines vollen 256-Bit ECC-Schlüssels nach nur 633 Abfragen führte {[}BBP12{]} \end{itemize*} - \item - Lektion gelernt: Machen Sie es nicht selbst, es sei denn, Sie müssen + \item Lektion gelernt: Machen Sie es nicht selbst, es sei denn, Sie müssen es tun und wissen, was Sie tun! \end{itemize*} @@ -2507,26 +1766,21 @@ \subsubsection{Weitere Anmerkungen} \begin{itemize*} - \item - Wie bereits erwähnt, ist es möglich, kryptographische elliptische + \item Wie bereits erwähnt, ist es möglich, kryptographische elliptische Kurven über \$G(2\^{}n)\$ zu konstruieren, was in Hardware-Implementierungen schneller sein kann. - \begin{itemize*} \item Wir haben auf Details verzichtet, da dies nicht viele neue Erkenntnisse gebracht hätte! \end{itemize*} - \item - Elliptische Kurven und ähnliche algebraische Gruppen sind ein aktives + \item Elliptische Kurven und ähnliche algebraische Gruppen sind ein aktives Forschungsgebiet und ermöglichen weitere fortgeschrittene Anwendungen, z.B: - \begin{itemize*} \item Sogenannte Edwards-Kurven werden derzeit diskutiert, da sie robuster gegen Seitenkanalangriffe zu sein scheinen (z.B. {[}BLR08{]}) \item Bilineare Paarungen ermöglichen \begin{itemize*} \item Programme zu verifizieren, dass sie zur selben Gruppe gehören, ohne ihre Identität preiszugeben (Secret Handshakes, z.B. {[}SM09{]}) \item Öffentliche Schlüssel können strukturiert werden, z.B. ,,Alice'' als öffentlicher Schlüssel für Alice verwenden (Identitätsbasierte Verschlüsselung, Grundlagen in {[}BF03{]}) \end{itemize*} \end{itemize*} - \item - Bevor Sie elliptische Kurvenkryptographie in einem Produkt einsetzen, + \item Bevor Sie elliptische Kurvenkryptographie in einem Produkt einsetzen, stellen Sie sicher, dass Sie keine Patente verletzen, da es noch viele gültige Patente in diesem Bereich gibt! \end{itemize*} @@ -2535,29 +1789,22 @@ \subsection{Schlussfolgerung} \begin{itemize*} - \item - Asymmetrische Kryptographie erlaubt es, zwei verschiedene Schlüssel zu + \item Asymmetrische Kryptographie erlaubt es, zwei verschiedene Schlüssel zu verwenden: - \begin{itemize*} \item Verschlüsselung / Entschlüsselung \item Signieren / Überprüfen \end{itemize*} - \item - Die praktischsten Algorithmen, die immer noch als sicher gelten, sind: - + \item Die praktischsten Algorithmen, die immer noch als sicher gelten, sind: \begin{itemize*} \item RSA, basierend auf der Schwierigkeit, diskrete Logarithmen zu faktorisieren und zu lösen \item Diffie-Hellman (kein asymmetrischer Algorithmus, sondern ein Schlüsselvereinbarungsprotokoll) \item ElGamal, wie DH basierend auf der Schwierigkeit, diskrete Logarithmen zu berechnen \end{itemize*} - \item - Da ihre Sicherheit vollständig auf der Schwierigkeit bestimmter + \item Da ihre Sicherheit vollständig auf der Schwierigkeit bestimmter mathematischer Probleme beruht, stellt der algorithmische Fortschritt ihre größte Bedrohung dar. - \item - Praktische Überlegungen: - + \item Praktische Überlegungen: \begin{itemize*} \item Asymmetrische kryptografische Operationen sind um Größenordnungen langsamer als symmetrische Operationen. \item Daher werden sie oft nicht für die Verschlüsselung/Signierung von Massendaten verwendet. @@ -2572,30 +1819,23 @@ \subsection{Motivation} \begin{itemize*} - \item - In der Datenkommunikation ist es üblich, eine Art Fehlererkennungscode + \item In der Datenkommunikation ist es üblich, eine Art Fehlererkennungscode für Nachrichten zu berechnen, mit dem der Empfänger überprüfen kann, ob eine Nachricht während der Übertragung verändert wurde. - \begin{itemize*} \item Beispiele: Parität, Bit-Interleaved Parity, Cyclic Redundancy Check (CRC) \end{itemize*} - \item - Dies führt zu dem Wunsch, einen ähnlichen Wert zu haben, der es + \item Dies führt zu dem Wunsch, einen ähnlichen Wert zu haben, der es ermöglicht zu überprüfen, ob eine Nachricht während der Übertragung verändert wurde. - \item - Es ist jedoch ein großer Unterschied, ob man davon ausgeht, dass die + \item Es ist jedoch ein großer Unterschied, ob man davon ausgeht, dass die Nachricht durch mehr oder weniger zufällige Fehler oder absichtlich verändert wird: - \begin{itemize*} \item Wenn jemand eine Nachricht, die mit einem CRC-Wert geschützt ist, absichtlich verändern will, kann er den CRC-Wert nach der Veränderung neu berechnen oder die Nachricht so verändern, dass sie den gleichen CRC-Wert ergibt. \end{itemize*} - \item - Ein Änderungsprüfwert muss also einige zusätzliche Eigenschaften + \item Ein Änderungsprüfwert muss also einige zusätzliche Eigenschaften erfüllen, die es Angreifern unmöglich machen, ihn zu fälschen - \begin{itemize*} \item Zwei Hauptkategorien von Modifikationsprüfwerten: \begin{itemize*} \item Modifikationserkennungscode (MDC) \item Nachrichten-Authentifizierungs-Code (MAC) \end{itemize*} @@ -2607,16 +1847,12 @@ Hash-Funktionen} \begin{itemize*} - \item - Definition: Hash-Funktion - + \item Definition: Hash-Funktion \begin{itemize*} \item Eine Hash-Funktion ist eine Funktion h, die die folgenden zwei Eigenschaften hat: \begin{itemize*} \item Komprimierung: h bildet eine Eingabe x mit beliebiger endlicher Bitlänge auf eine Ausgabe \$h(x)\$ mit fester Bitlänge n ab. \item Einfachheit der Berechnung: Bei h und x ist es einfach, \$h(x)\$ zu berechnen. \end{itemize*} \end{itemize*} - \item - Definition: kryptografische Hash-Funktion - + \item Definition: kryptografische Hash-Funktion \begin{itemize*} \item Eine kryptografische Hash-Funktion h ist eine Hash-Funktion, die zusätzlich unter anderem die folgenden Eigenschaften erfüllt: \begin{itemize*} \item Pre-Image-Resistenz: für im Wesentlichen alle vorgegebenen Ausgaben y ist es rechnerisch nicht möglich, ein x zu finden, so dass \$h(x)=y\$ \item \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \setcounter{enumi}{1} \item Vorabbild-Resistenz: Bei x ist es rechnerisch nicht möglich, eine zweite Eingabe \$x'\$ mit \$x\textbackslash not= x'\$ zu finden, so dass \$h(x)=h(x')\$ \end{enumerate*} \item Kollisionssicherheit: Es ist rechnerisch nicht möglich, ein beliebiges Paar \$(x,x')\$ mit \$x\textbackslash not= x'\$ zu finden, so dass \$h(x)=h(x')\$ \end{itemize*} @@ -2629,9 +1865,7 @@ (MAC)} \begin{itemize*} - \item - Definition: Nachrichten-Authentifizierungs-Code - + \item Definition: Nachrichten-Authentifizierungs-Code \begin{itemize*} \item Ein Message-Authentication-Code-Algorithmus ist eine Familie von Funktionen \$h\_k\$, die durch einen geheimen Schlüssel k parametrisiert sind und die folgenden Eigenschaften aufweisen: \begin{itemize*} \item Komprimierung: hk bildet eine Eingabe x beliebiger endlicher Bitlänge auf eine Ausgabe \$h\_k(x)\$ fester Bitlänge ab, genannt MAC \item Einfache Berechnung: Bei k, x und einer bekannten Funktionsfamilie \$h\_k\$ ist der Wert \$h\_k(x)\$ einfach zu berechnen \item Berechnungsresistenz: für jeden festen, erlaubten, aber unbekannten Wert von k ist es bei null oder mehr Text-MAC-Paaren \$(x\_i, h\_k(x\_i))\$ rechnerisch nicht möglich, ein Text-MAC-Paar \$(x, h\_k(x))\$ für jede neue Eingabe \$x\textbackslash not= x\_i\$ zu berechnen \end{itemize*} @@ -2644,22 +1878,17 @@ MAC} \begin{itemize*} - \item - Betrachten wir zur Veranschaulichung die folgende MAC-Definition: - + \item Betrachten wir zur Veranschaulichung die folgende MAC-Definition: \begin{itemize*} \item Eingabe: Nachricht \$m=(x\_1,x\_2,...,x\_n)\$, wobei \$x\_i\$ 64-Bit-Werte sind, und Schlüssel k \item Berechne \$\textbackslash delta(m):= x\_1\textbackslash oplus x\_2\textbackslash oplus...\textbackslash oplus x\_n\$, wobei \$\textbackslash oplus\$ die bitweise Exklusiv-Oder-Verknüpfung bezeichnet \item Ausgabe: MAC \$C\_k(m):= E\_k(\textbackslash delta(m))\$ mit \$E\_k(x)\$ für die DES-Verschlüsselung \end{itemize*} - \item - Die Schlüssellänge beträgt 56 Bit und die MAC-Länge 64 Bit, so dass + \item Die Schlüssellänge beträgt 56 Bit und die MAC-Länge 64 Bit, so dass wir einen Aufwand von etwa \$2\^{}\{55\}\$ Operationen erwarten würden, um den Schlüssel k zu erhalten und den MAC zu knacken (= Nachrichten fälschen zu können). - \item - Leider ist die MAC-Definition unsicher: - + \item Leider ist die MAC-Definition unsicher: \begin{itemize*} \item Angenommen, ein Angreifer Eve, der die zwischen Alice und Bob ausgetauschten Nachrichten fälschen will, erhält eine Nachricht \$(m,C\_k(m))\$, die von Alice mit dem mit Bob geteilten geheimen Schlüssel k ,,geschützt'' wurde \item Eve kann eine Nachricht \$m'\$ konstruieren, die denselben MAC ergibt: @@ -2672,25 +1901,19 @@ MACs} \begin{itemize*} - \item - Wichtigste Anwendung, die zum ursprünglichen Entwurf führte: + \item Wichtigste Anwendung, die zum ursprünglichen Entwurf führte: Integrität von Nachrichten - \begin{itemize*} \item Ein MDC stellt einen digitalen Fingerabdruck dar, der mit einem privaten Schlüssel signiert werden kann, z. B. mit dem RSA- oder ElGamal-Algorithmus, und es ist nicht möglich, zwei Nachrichten mit demselben Fingerabdruck zu erstellen, so dass ein bestimmter signierter Fingerabdruck von einem Angreifer nicht wiederverwendet werden kann \item Ein MAC über eine Nachricht m bescheinigt direkt, dass der Absender der Nachricht im Besitz des geheimen Schlüssels k ist und die Nachricht ohne Kenntnis dieses Schlüssels nicht verändert worden sein kann. \end{itemize*} - \item - Andere Anwendungen, die eine gewisse Vorsicht erfordern: - + \item Andere Anwendungen, die eine gewisse Vorsicht erfordern: \begin{itemize*} \item Bestätigung von Wissen \item Schlüsselableitung \item Pseudo-Zufallszahlengenerierung \end{itemize*} - \item - Je nach Anwendung müssen weitere Anforderungen erfüllt werden: - + \item Je nach Anwendung müssen weitere Anforderungen erfüllt werden: \begin{itemize*} \item Partielle Vorabbild-Resistenz: auch wenn nur ein Teil der Eingabe, z.B. t Bit, unbekannt ist, sollte es im Durchschnitt \$2\^{}\{t-1\}\$ Operationen benötigen, um diese Bits zu finden \end{itemize*} @@ -2701,93 +1924,71 @@ Geburtstagsphänomen} \begin{itemize*} - \item - Das Geburtstagsphänomen: - + \item Das Geburtstagsphänomen: \begin{itemize*} \item Wie viele Personen müssen sich in einem Raum befinden, damit die Wahrscheinlichkeit, dass es mindestens zwei Personen mit demselben Geburtstag gibt, größer als 0,5 ist? \item Der Einfachheit halber lassen wir den 29. Februar beiseite und nehmen an, dass jeder Geburtstag gleich wahrscheinlich ist \end{itemize*} - \item - Definieren Sie \$P(n,k):= Pr\${[}mindestens ein Duplikat in k + \item Definieren Sie \$P(n,k):= Pr\${[}mindestens ein Duplikat in k Elementen, wobei jedes Element einen von n gleich wahrscheinlichen Werten zwischen 1 und n annehmen kann {]} - \item - Definieren Sie \$Q(n,k):= Pr\${[}kein Duplikat in k Artikeln, jeder + \item Definieren Sie \$Q(n,k):= Pr\${[}kein Duplikat in k Artikeln, jeder Artikel zwischen 1 und n {]} - \begin{itemize*} \item Wir können das erste Element aus n möglichen Werten wählen, das zweite Element aus \$n-1\$ möglichen Werten, usw. \item Die Anzahl der verschiedenen Möglichkeiten, k Elemente aus n Werten ohne Duplikate auszuwählen, ist also: \$N=n \textbackslash times (n-1)\textbackslash times ...\textbackslash times (n-k+1)= n!\textbackslash backslash(n-k)!\$ \item Die Anzahl der verschiedenen Möglichkeiten, k Elemente aus n Werten auszuwählen, mit oder ohne Duplikate, ist: \$n\^{}k\$ \item Also, \$Q(n,k)=N\textbackslash backslash n\^{}k=n!\textbackslash backslash((n-k)! \textbackslash times n\^{}k)\$ \end{itemize*} - \item - Wir haben: + \item Wir haben: \$P(n,k)=1-Q(n,k)=1-\textbackslash frac\{n!\}\{(n-k)!\textbackslash times n\^{}k\}=1-\textbackslash frac\{n\textbackslash times(n-1)\textbackslash times...\textbackslash times(n-k+1)\}\{n\^{}k\}=1-{[}(1-\textbackslash frac\{1\}\{n\})\textbackslash times(1-\textbackslash frac\{2\}\{n\})\textbackslash times...\textbackslash times(1-\textbackslash frac\{k-1\}\{n\}){]}\$ - \item - Wir werden die folgende Ungleichung verwenden: \$(1-x) + \item Wir werden die folgende Ungleichung verwenden: \$(1-x) \textbackslash leq e\^{}\{-x\}\$ für alle \$x \textbackslash geq 0\$ - \item - So: + \item So: \$P(n,k)\textgreater1-{[}(e\^{}\{-1/n\})\textbackslash times(e\^{}\{-2/n\})\textbackslash times...\textbackslash times(e\^{}\{-(k-1)/n\}){]}=1-e\^{}\{\textbackslash frac\{-k\textbackslash times(k-1)\}\{2n\}\}\$ - \item - Im letzten Schritt haben wir die Gleichheit: \$1+2+...+(k-1)=(k\^{}2 - + \item Im letzten Schritt haben wir die Gleichheit: \$1+2+...+(k-1)=(k\^{}2 - k)\textbackslash backslash 2\$ - \begin{itemize*} \item Übung: Beweisen Sie die obige Gleichheit durch Induktion \end{itemize*} - \item - Kehren wir zu unserer ursprünglichen Frage zurück: Wie viele Personen + \item Kehren wir zu unserer ursprünglichen Frage zurück: Wie viele Personen k müssen sich in einem Raum befinden, damit mindestens zwei Personen mit demselben Geburtstag (von \$n=365\$ möglichen) mit der Wahrscheinlichkeit \$\textbackslash geq 0,5\$ vorhanden sind? - \begin{itemize*} \item Wir wollen also lösen: \$\textbackslash frac\{1\}\{2\}=1-e\^{}\{\textbackslash frac\{-k\textbackslash times(k-1)\}\{2n\}\}\textbackslash Leftrightarrow 2=e\^{}\{\textbackslash frac\{k\textbackslash times(k-1)\}\{2n\}\}\textbackslash Leftrightarrow ln(2)=\textbackslash frac\{k\textbackslash times(k-1)\}\{2n\}\$ \item Für große k können wir \$k\textbackslash times(k-1)\$ durch \$k\^{}2\$ approximieren, und wir erhalten: \$k=\textbackslash sqrt\{2 ln(2)n\}\textbackslash approx 1,18\textbackslash sqrt\{n\}\$ \item Für \$n=365\$ erhalten wir \$k=22,54\$, was der richtigen Antwort recht nahe kommt 23 \end{itemize*} - \item - Was hat das mit MDCs zu tun? - \item - Wir haben gezeigt, dass bei n möglichen unterschiedlichen Werten die + \item Was hat das mit MDCs zu tun? + \item Wir haben gezeigt, dass bei n möglichen unterschiedlichen Werten die Anzahl k der Werte, die man zufällig wählen muss, um mindestens ein Paar identischer Werte zu erhalten, in der Größenordnung von \$\textbackslash sqrt\{n\}\$ liegt. - \item - Betrachten wir nun den folgenden Angriff {[}Yuv79a{]}: - + \item Betrachten wir nun den folgenden Angriff {[}Yuv79a{]}: \begin{itemize*} \item Eve möchte, dass Alice eine Nachricht m1 signiert, die Alice normalerweise nie signieren würde. Eve weiß, dass Alice die Funktion MDC1(m) verwendet, um eine MDC von m zu berechnen, die eine Länge von r Bit hat, bevor sie diese MDC mit ihrem privaten Schlüssel signiert, was ihre digitale Signatur ergibt. \item Zunächst erzeugt Eve ihre Nachricht m1. Würde sie nun MDC1(m1) berechnen und dann versuchen, eine zweite harmlose Nachricht m2 zu finden, die zu demselben MDC führt, wäre ihr Suchaufwand im durchschnittlichen Fall in der Größenordnung von \$2\^{}\{(r-1)\}\$. \item Stattdessen nimmt sie eine beliebige harmlose Nachricht m2 und beginnt, Variationen m1' und m2' der beiden Nachrichten zu produzieren, z.B. durch Hinzufügen von -Kombinationen oder Variationen mit semantisch identischen Wörtern. \end{itemize*} - \item - Wie wir aus dem Geburtstagsphänomen gelernt haben, muss sie nur etwa + \item Wie wir aus dem Geburtstagsphänomen gelernt haben, muss sie nur etwa \$\textbackslash sqrt\{2\^{}r\}=2\^{}\{r/2\}\$ Variationen von jeder der beiden Nachrichten produzieren, so dass die Wahrscheinlichkeit, dass sie zwei Nachrichten m1' und m2' mit demselben MDC erhält, mindestens 0,5 beträgt - \item - Da sie die Nachrichten zusammen mit ihren MDCs speichern muss, um eine + \item Da sie die Nachrichten zusammen mit ihren MDCs speichern muss, um eine Übereinstimmung zu finden, liegt der Speicherbedarf ihres Angriffs in der Größenordnung von \$2\^{}\{\textbackslash frac\{r\}\{2\}\}\$ und der Rechenzeitbedarf in der gleichen Größenordnung - \item - Nachdem sie m1' und m2' mit \$MDC1(m1')=MDC1(m2')\$ gefunden hat, + \item Nachdem sie m1' und m2' mit \$MDC1(m1')=MDC1(m2')\$ gefunden hat, fordert sie Alice auf, \$m2'\$ zu signieren. Eve kann dann diese Unterschrift nehmen und behaupten, dass Alice \$m1'\$ unterschrieben hat. - \item - Angriffe nach dieser Methode werden Geburtstagsangriffe genannt. - \item - Nehmen wir nun an, dass Alice RSA mit Schlüsseln der Länge 2048 Bit + \item Angriffe nach dieser Methode werden Geburtstagsangriffe genannt. + \item Nehmen wir nun an, dass Alice RSA mit Schlüsseln der Länge 2048 Bit und eine kryptographische Hashfunktion verwendet, die MDCs der Länge 96 Bit erzeugt. - \begin{itemize*} \item Eves durchschnittlicher Aufwand, zwei Nachrichten m1' und m2' wie oben beschrieben zu erzeugen, liegt in der Größenordnung von \$2\^{}\{48\}\$, was heute machbar ist. Das Knacken von RSA-Schlüsseln der Länge 2048 Bit ist mit den heutigen Algorithmen und Technologien bei weitem nicht möglich. \end{itemize*} @@ -2798,9 +1999,7 @@ MDCs} \begin{itemize*} - \item - Kryptografische Hash-Funktionen zur Erstellung von MDCs: - + \item Kryptografische Hash-Funktionen zur Erstellung von MDCs: \begin{itemize*} \item Message Digest 5 (MD5): \begin{itemize*} \item Erfunden von R. Rivest \item Nachfolger von MD \end{itemize*} @@ -2811,18 +2010,14 @@ \item Sicherer Hash-Algorithmus 3 (SHA-3, Keccak) \begin{itemize*} \item Gewinner eines offenen Wettbewerbs \item Sogenannte Sponge-Konstruktion \item Vielseitiger als frühere Hash-Funktionen \end{itemize*} \end{itemize*} - \item - Nachrichten-Authentifizierungs-Codes (MACs): - + \item Nachrichten-Authentifizierungs-Codes (MACs): \begin{itemize*} \item DES-CBC-MAC: \begin{itemize*} \item Verwendet den Data Encryption Standard im Cipher Block Chaining Modus \item Im Allgemeinen kann die CBC-MAC-Konstruktion mit jeder Blockchiffre verwendet werden. \end{itemize*} \item MACs, die aus MDCs aufgebaut sind: \begin{itemize*} \item Dieser sehr verbreitete Ansatz wirft einige kryptografische Bedenken auf, da er einige implizite, aber nicht verifizierte Annahmen über die Eigenschaften der MDCs trifft. \end{itemize*} \end{itemize*} - \item - Authentifizierte Verschlüsselung mit zugehörigen Daten (AEAD) - + \item Authentifizierte Verschlüsselung mit zugehörigen Daten (AEAD) \begin{itemize*} \item Galois-Counter-Verfahren (GCM) \begin{itemize*} \item Verwendet eine Blockchiffre zur Verschlüsselung und Authentifizierung von Daten \item Schnell in Netzwerkanwendungen \end{itemize*} @@ -2836,12 +2031,10 @@ Hash-Funktionen} \begin{itemize*} - \item - So wie viele der heutigen Blockchiffren der allgemeinen Struktur eines + \item So wie viele der heutigen Blockchiffren der allgemeinen Struktur eines Feistel-Netzwerks folgen, folgen auch viele der heute verwendeten kryptografischen Hash-Funktionen einer gemeinsamen Struktur, der sogenannten Merkle-Dåmgard-Struktur: - \begin{itemize*} \item Sei y eine beliebige Nachricht. Normalerweise wird die Länge der Nachricht an die Nachricht angehängt und auf ein Vielfaches einer Blockgröße b aufgefüllt. Bezeichnen wir \$(y\_0,y\_1,...,y\_\{L-1\})\$ die resultierende Nachricht, die aus L Blöcken der Größe b \item Die allgemeine Struktur ist wie folgt abgebildet: % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-feistel.png} @@ -2854,17 +2047,14 @@ \item \$CV\_i = f(CV\_\{i -1\}, y\_\{i-1\}) \textbackslash quad\textbackslash quad 1\textbackslash leq i \textbackslash leq L\$ \item \$H(y) = CV\_L\$ \end{itemize*} - \item - Es wurde gezeigt {[}Mer89a{]}, dass, wenn die Kompressionsfunktion f + \item Es wurde gezeigt {[}Mer89a{]}, dass, wenn die Kompressionsfunktion f kollisionssicher ist, die resultierende iterierte Hash-Funktion H ebenfalls kollisionssicher ist. - \item - Die Kryptoanalyse kryptographischer Hash-Funktionen konzentriert sich + \item Die Kryptoanalyse kryptographischer Hash-Funktionen konzentriert sich daher auf die interne Struktur der Funktion f und die Suche nach effizienten Techniken zur Erzeugung von Kollisionen bei einer einzigen Ausführung von f - \item - In erster Linie durch Geburtstagsangriffe motiviert, ist ein gängiger + \item In erster Linie durch Geburtstagsangriffe motiviert, ist ein gängiger Mindestvorschlag für n , die Bitlänge des Hashwerts, 160 Bit, da dies einen Aufwand der Größenordnung \$2\^{}\{80\}\$ für einen Angriff impliziert, der heute als undurchführbar gilt @@ -2874,10 +2064,8 @@ \subsection{Der Message Digest 5} \begin{itemize*} - \item - MD5 folgt der zuvor skizzierten allgemeinen Struktur (z. B. + \item MD5 folgt der zuvor skizzierten allgemeinen Struktur (z. B. {[}Riv92a{]}): - \begin{itemize*} \item Die Nachricht y wird mit einer ,,1'' aufgefüllt, gefolgt von 0 bis 511 ,,0'' Bits, so dass die Länge der resultierenden Nachricht kongruent 448 modulo 512 ist \item Die Länge der ursprünglichen Nachricht wird als 64-Bit-Wert hinzugefügt, so dass eine Nachricht entsteht, deren Länge ein ganzzahliges Vielfaches von 512 Bit ist. @@ -2889,19 +2077,15 @@ \begin{itemize*} \item Jede Runde ist ähnlich aufgebaut und verwendet eine Tabelle T, die 64 konstante Werte von je 32 Bit enthält, \item Jede der vier Runden verwendet eine bestimmte logische Funktion g \end{itemize*} \end{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-md5.png} - \begin{itemize*} \item Die Funktion g ist eine von vier verschiedenen logischen Funktionen \item \$y\_i{[}k{]}\$ bezeichnet das k-te\$ 32-Bit-Wort des Nachrichtenblocks i \item \$T{[}j{]}\$ ist der j-te Eintrag der Tabelle t, wobei j bei jedem Schritt modulo 64 inkrementiert wird \item CLS s bezeichnet die zyklische Linksverschiebung um s Bits, wobei s einem bestimmten Schema folgt. \end{itemize*} - \item - Der MD5-MDC über eine Nachricht ist der Inhalt des Verkettungswertes + \item Der MD5-MDC über eine Nachricht ist der Inhalt des Verkettungswertes CV nach Verarbeitung des letzten Nachrichtenblocks. - \item - Sicherheit von MD5: - + \item Sicherheit von MD5: \begin{itemize*} \item Jedes Bit des 128-Bit-Hash-Codes ist eine Funktion eines jeden Eingabebits \item 1996 veröffentlichte H. Dobbertin einen Angriff, der es erlaubt, eine Kollision für die Funktion f zu erzeugen (realisiert durch die oben beschriebenen 64 Schritte). @@ -2918,9 +2102,7 @@ SHA-1} \begin{itemize*} - \item - Auch SHA-1 folgt der gleichen Struktur wie oben beschrieben: - + \item Auch SHA-1 folgt der gleichen Struktur wie oben beschrieben: \begin{itemize*} \item SHA-1 arbeitet mit 512-Bit-Blöcken und erzeugt einen 160-Bit-Hash-Wert. \item Da sein Design auch vom MD4-Algorithmus inspiriert wurde, ist seine Initialisierung im Grunde dieselbe wie die von MD5: @@ -2930,34 +2112,26 @@ \begin{itemize*} \item Die Runden haben eine ähnliche Struktur, aber jede Runde verwendet eine andere primitive logische Funktion \$f\_1, f\_2, f\_3, f\_4\$. \item Bei jedem Schritt wird eine feste additive Konstante \$K\_t\$ verwendet, die während einer Runde unverändert bleibt \end{itemize*} \end{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-sha1.png} - \begin{itemize*} \item \$t\textbackslash in\{0,...,15\}\textbackslash Rightarrow W\_t:= y\_i{[}t{]}\$ \item \$t\textbackslash in\{16,...,79\}\textbackslash Rightarrow W\_t:=CLS\_1(W\_\{t-16\}\textbackslash oplus W\_\{t-14\}\textbackslash oplus W\_\{t-8\} \textbackslash oplus W\_\{t-3\})\$ \item Nach Schritt 79 wird jedes Register A, B, C, D, E modulo \$2\^{}\{32\}\$ mit dem Wert des entsprechenden Registers vor Schritt 0 addiert, um \$CV\_\{i+1\}\$ zu berechnen \end{itemize*} - \item - Der SHA-1-MDC über eine Nachricht ist der Inhalt des Verkettungswertes + \item Der SHA-1-MDC über eine Nachricht ist der Inhalt des Verkettungswertes CV nach Verarbeitung des letzten Nachrichtenblocks. - \item - Vergleich zwischen SHA-1 und MD5: - + \item Vergleich zwischen SHA-1 und MD5: \begin{itemize*} \item Geschwindigkeit: SHA-1 ist etwa 25\% langsamer als MD5 (CV ist etwa 25\% größer) \item Einfachheit und Kompaktheit: beide Algorithmen sind einfach zu beschreiben und zu implementieren und erfordern keine großen Programme oder Ersetzungstabellen \end{itemize*} - \item - Sicherheit von SHA-1: - + \item Sicherheit von SHA-1: \begin{itemize*} \item Da SHA-1 MDCs der Länge 160 Bit erzeugt, wird erwartet, dass es eine bessere Sicherheit gegen Brute-Force- und Geburtstagsangriffe bietet als MD5. \item Einige inhärente Schwächen von Merkle-Dåmgard-Konstruktionen, z. B. {[}KK06{]}, sind vorhanden \item Im Februar 2005 veröffentlichten X. Wang et. al. einen Angriff, der es erlaubt, eine Kollision mit einem Aufwand von \$2\^{}\{69\}\$ zu finden, der in den folgenden Monaten auf \$2\^{}\{63\}\$ verbessert und in {[}WYY05a{]} veröffentlicht wurde \item Die Forschung ging weiter (z.B. {[}Man11{]}), und im Februar 2017 wurde die erste tatsächliche Kollision gefunden (demonstriert mit einem veränderten PDF-Dokument) \end{itemize*} - \item - SHA-2-Familie - + \item SHA-2-Familie \begin{itemize*} \item Im Jahr 2001 veröffentlichte das NIST einen neuen Standard FIPS PUB 180-2, der neue Varianten mit den Bezeichnungen SHA-256, SHA-384 und SHA-512 {[}NIST02{]} mit 256, 384 und 512 Bits enthält. \begin{itemize*} \item SHA-224 wurde im Jahr 2004 hinzugefügt. \end{itemize*} @@ -2966,9 +2140,7 @@ \item Der interne Zustand ist in 8 Registern von 32 Bit (SHA-256) und 64 Bit (SHA-512) organisiert \item 64 Runden (SHA-256) oder 80 Runden (SHA-512) \end{itemize*} - \item - Ein Schritt - + \item Ein Schritt \begin{itemize*} % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-sha-2.png} \item \$t\textbackslash in\{0, ..., 15\}\textbackslash Rightarrow W\_t:=y\_i{[}t{]}\$ @@ -2977,9 +2149,7 @@ \item Die ROTR- und Funktionen XOR-verknüpfen verschiedene Verschiebungen des Eingangswertes \item Ch und Maj sind logische Kombinationen der Eingabewerte \end{itemize*} - \item - SHA-2-Familie - + \item SHA-2-Familie \begin{itemize*} \item Alles in allem sehr ähnlich zu SHA-1 \item Aufgrund der Größe und der komplizierteren Rundungsfunktionen etwa 30-50 Prozent langsamer als SHA-1 (variiert für 64-Bit- und 32-Bit-Systeme!) @@ -2993,10 +2163,8 @@ SHA-3} \begin{itemize*} - \item - Sicherheitsbedenken bezüglich SHA-1 und SHA-2 führten zu einem offenen + \item Sicherheitsbedenken bezüglich SHA-1 und SHA-2 führten zu einem offenen Wettbewerb des NIST, der 2007 begann - \begin{itemize*} \item 5 Finalisten ohne nennenswerte Schwächen \item Oktober 2012: NIST gibt bekannt, dass Keccak zu SHA-3 wird @@ -3005,23 +2173,17 @@ \item SHA-3 ist sehr schnell, besonders in der Hardware \item Sehr gut dokumentiert und analysierbar \end{itemize*} - \item - Keccak basiert auf einer so genannten Schwammkonstruktion anstelle der + \item Keccak basiert auf einer so genannten Schwammkonstruktion anstelle der früheren Merkle-Dåmgard-Konstruktionen - \begin{itemize*} \item Vielseitiges Design, um fast alle symmetrischen kryptographischen Funktionen zu implementieren (allerdings ist nur das Hashing standardisiert) \end{itemize*} - \item - Arbeitet normalerweise in 2 Phasen - + \item Arbeitet normalerweise in 2 Phasen \begin{itemize*} \item ,,Absorbieren'' von Informationen beliebiger Länge in 1600 Bit des internen Zustands \item ,,Auspressen'' (d.h. Ausgeben) von Hash-Daten beliebiger Länge (nur 224, 256, 384 und 512 Bit standardisiert) \end{itemize*} - \item - Der interne Zustand ist in 2 Registern organisiert - + \item Der interne Zustand ist in 2 Registern organisiert \begin{itemize*} \item Ein Register der Größe r ist ,,public'': Eingabedaten werden in der Absorptionsphase mit XOR verknüpft, Ausgabedaten werden in der Quetschungsphase daraus abgeleitet \item Das Register der Größe c ist ,,privat''; Ein- und Ausgabe wirken sich nicht direkt auf es aus. @@ -3029,21 +2191,16 @@ \item Die Größe von c ist doppelt so groß wie die Länge des Ausgangsblocks \item Beide Register werden mit ,,0'' initialisiert \end{itemize*} - \item - Das Hashing erfolgt durch eine Funktion f, die die Register liest und + \item Das Hashing erfolgt durch eine Funktion f, die die Register liest und einen neuen Zustand ausgibt - \item - Sponge-Konstruktion - + \item Sponge-Konstruktion \begin{itemize*} % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-sha-3.png} \item Absorptionsphase: \$k + 1\$ Eingabeblöcke der Größe r werden in den Zustand gemischt \item Quetschphase: \$l + 1\$ Ausgangsblöcke der Größe r werden erzeugt (oft nur einer) \item Der letzte Eingabe- und Ausgabeblock kann aufgefüllt oder abgeschnitten werden. \end{itemize*} - \item - Die Funktion f - + \item Die Funktion f \begin{itemize*} \item Offensichtlich hängt die Sicherheit einer Sponge-Konstruktion von der Sicherheit von f \item Keccak verwendet 24 Runden von 5 verschiedenen Unterfunktionen \$(\textbackslash Sigma, \textbackslash ro,\textbackslash pi,$\chi$,$\iota$)\$, um f zu implementieren. @@ -3052,13 +2209,10 @@ \item Jede der Unterfunktionen gewährleistet bestimmte Eigenschaften, z.B, \begin{itemize*} \item Schnelle Diffusion der geänderten Bits im gesamten Zustand (\$\textbackslash Sigma\$) \item Langfristige Diffusion (\$\textbackslash pi\$) \item Sicherstellung, dass f nichtlinear wird ($\chi$) \item Rundenspezifische Substitution ($\iota$) \end{itemize*} \end{itemize*} - \item - \$\textbackslash Sigma\$ wird zuerst ausgeführt, um sicherzustellen, + \item \$\textbackslash Sigma\$ wird zuerst ausgeführt, um sicherzustellen, dass sich der geheime und der öffentliche Zustand schnell vermischen, bevor andere Unterfunktionen angewendet werden. - \item - Sicherheit - + \item Sicherheit \begin{itemize*} \item Derzeit gibt es keine nennenswerten Schwachstellen in SHA-3 \begin{itemize*} \item Die bekanntesten Pre-Image-Angriffe funktionieren nur mit einer Funktion f mit bis zu 8 Runden \item Zum Schutz vor internen Kollisionen sollten 11 Runden ausreichen. \end{itemize*} @@ -3072,23 +2226,17 @@ Codes} \begin{itemize*} - \item - Ein CBC-MAC wird berechnet, indem eine Nachricht im CBC-Modus + \item Ein CBC-MAC wird berechnet, indem eine Nachricht im CBC-Modus verschlüsselt wird und der letzte Chiffretextblock oder ein Teil davon als MAC verwendet wird: % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-CBC-mac.png} - \item - Dieser MAC muss nicht mehr signiert werden, da er bereits mit einem + \item Dieser MAC muss nicht mehr signiert werden, da er bereits mit einem gemeinsamen Geheimnis K erzeugt wurde. - \begin{itemize*} \item Es ist jedoch nicht möglich zu sagen, wer genau einen MAC erstellt hat, da jeder (Sender, Empfänger), der den geheimen Schlüssel K kennt, dies tun kann \end{itemize*} - \item - Dieses Verfahren funktioniert mit jeder Blockchiffre (DES, IDEA, ...) - \item - Sicherheit von CBC-MAC: - + \item Dieses Verfahren funktioniert mit jeder Blockchiffre (DES, IDEA, ...) + \item Sicherheit von CBC-MAC: \begin{itemize*} \item Da ein Angreifer K nicht kennt, ist ein Geburtstagsangriff sehr viel schwieriger (wenn nicht gar unmöglich) zu starten \item Ein Angriff auf einen CBC-MAC erfordert bekannte Paare (Nachricht, MAC) @@ -3097,11 +2245,9 @@ \item Dadurch verdoppelt sich der Schlüsselraum bei nur geringem Rechenaufwand \item Die Konstruktion ist nicht sicher, wenn die Nachrichtenlängen variieren! \end{itemize*} - \item - Es gibt auch einige Vorschläge, MDCs aus symmetrischen Blockchiffren + \item Es gibt auch einige Vorschläge, MDCs aus symmetrischen Blockchiffren zu erzeugen, indem der Schlüssel auf einen festen (bekannten) Wert gesetzt wird: - \begin{itemize*} \item Wegen der relativ kleinen Blockgröße von 64 Bit der meisten gängigen Blockchiffren bieten diese Verfahren keine ausreichende Sicherheit gegen Geburtstagsangriffe. \item Da symmetrische Blockchiffren mehr Rechenaufwand erfordern als spezielle kryptografische Hash-Funktionen, sind diese Verfahren relativ langsam. @@ -3113,28 +2259,22 @@ MDC} \begin{itemize*} - \item - Grund für die Konstruktion von MACs aus MDCs Kryptografische + \item Grund für die Konstruktion von MACs aus MDCs Kryptografische Hash-Funktionen laufen im Allgemeinen schneller ab als symmetrische Blockchiffren - \item - Grundidee: ,,mix'' einen geheimen Schlüssel K mit der Eingabe und + \item Grundidee: ,,mix'' einen geheimen Schlüssel K mit der Eingabe und berechne einen MDC - \item - Die Annahme, dass ein Angreifer K kennen muss, um einen gültigen MAC + \item Die Annahme, dass ein Angreifer K kennen muss, um einen gültigen MAC zu erzeugen, wirft dennoch einige kryptografische Probleme auf (zumindest für Merkle-Dåmgard-Hash-Funktionen): - \begin{itemize*} \item Die Konstruktion \$H(K\textbar\textbar m)\$ ist nicht sicher (siehe Anmerkung 9.64 in {[}Men97a{]}) \item Die Konstruktion \$H(m\textbar\textbar K)\$ ist nicht sicher (siehe Bemerkung 9.65 in {[}Men97a{]}) \item Die Konstruktion \$H(K\textbar\textbar p\textbar\textbar m\textbar\textbar K)\$, bei der p ein zusätzliches Auffüllfeld bezeichnet, bietet keine ausreichende Sicherheit (siehe Anmerkung 9.66 in {[}Men97a{]}) \end{itemize*} - \item - Die am häufigsten verwendete Konstruktion ist: - \$H(K\textbackslash oplus p\_1\textbar\textbar{} - H(K\textbackslash oplus p\_2\textbar\textbar{} m))\$ - + \item Die am häufigsten verwendete Konstruktion ist: + \$H(K\textbackslash oplus p\_1\textbar| + H(K\textbackslash oplus p\_2\textbar| m))\$ \begin{itemize*} \item Der Schlüssel wird mit 0's aufgefüllt, um den Schlüssel zu einem Eingabeblock der kryptographischen Hashfunktion aufzufüllen \item Zwei verschiedene konstante Muster \$p\_1\$ und \$p\_2\$ werden mit dem aufgefüllten Schlüssel XOR-verknüpft @@ -3149,17 +2289,12 @@ Modi} \begin{itemize*} - \item - Normalerweise sind die Daten nicht authentifiziert oder verschlüsselt, + \item Normalerweise sind die Daten nicht authentifiziert oder verschlüsselt, sondern verschlüsselt UND authentifiziert (Blöcke \$P\_0...P\_n\$) - \item - Manchmal müssen zusätzliche Daten authentifiziert werden (z.B. + \item Manchmal müssen zusätzliche Daten authentifiziert werden (z.B. Paketköpfe), im Folgenden mit \$A\_0...A\_m\$ bezeichnet - \item - führte zur Entwicklung von AEAD-Betriebsarten - \item - Beispiele hierfür sind - + \item führte zur Entwicklung von AEAD-Betriebsarten + \item Beispiele hierfür sind \begin{itemize*} \item Galois/Zähler-Modus (GCM) \item Zähler mit CBC-MAC (CCM) @@ -3173,34 +2308,25 @@ {[}MV04{]}} \begin{itemize*} - \item - Beliebter AEAD-Modus - \item - NIST-Standard, Teil von IEEE 802.1AE, IPsec, TLS, SSH usw. - \item - Frei von Patenten - \item - Wird wegen seiner hohen Geschwindigkeit hauptsächlich in + \item Beliebter AEAD-Modus + \item NIST-Standard, Teil von IEEE 802.1AE, IPsec, TLS, SSH usw. + \item Frei von Patenten + \item Wird wegen seiner hohen Geschwindigkeit hauptsächlich in Netzwerkanwendungen eingesetzt - \begin{itemize*} \item Äußerst effizient in der Hardware \item Prozessorunterstützung auf neueren x86-CPUs \item Zeitintensive Aufgaben können vorberechnet und parallelisiert werden \item Keine Notwendigkeit für Auffüllungen \end{itemize*} - \item - Verwendet konventionelle Blockchiffre mit 128-Bit-Blockgröße (z. B. + \item Verwendet konventionelle Blockchiffre mit 128-Bit-Blockgröße (z. B. AES) - \item - Berechnet MAC durch Multiplikationen und Additionen in + \item Berechnet MAC durch Multiplikationen und Additionen in \$GF(2\^{}\{128\})\$ über das irreduzible Polynom \$x\^{}\{128\}+x\^{}\{7\}+x\^{}\{2\}+x+1\$ - \item - Erfordert nur \$n+1\$ Blockchiffre-Aufrufe pro Paket (n = Länge der + \item Erfordert nur \$n+1\$ Blockchiffre-Aufrufe pro Paket (n = Länge der verschlüsselten und authentifizierten Daten) %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-gcm.png} - \begin{itemize*} \item \$I\_0\$ wird mit dem IV und einem Padding oder einem Hash des IV initialisiert (wenn er nicht 96 Bit beträgt) \item \$\textbackslash circ H\$ ist \$GF(2\^{}\{128\})\$ Multiplikation mit \$H=E(K,0\^{}\{128\})\$ @@ -3208,9 +2334,7 @@ \item \$A\_m\$ und \$C\_n\$ werden vor der Ausgabe auf die Originalgröße gekürzt \item Die letzte Authentifizierung verwendet 64 Bit kodierte Bitlängen von A und C \end{itemize*} - \item - Sicherheit - + \item Sicherheit \begin{itemize*} \item Schneller Modus, erfordert aber einige Sorgfalt: \begin{itemize*} \item Erwiesenermaßen sicher (unter bestimmten Voraussetzungen, z. B. wenn die verwendete Blockchiffre nicht von Zufallszahlen unterscheidbar ist), aber die Konstruktion ist anfällig: \end{itemize*} @@ -3227,55 +2351,40 @@ \$GF(2\^{}n)\$} \begin{itemize*} - \item - Galoisfeld-Arithmetik definiert über Termen (z.B. + \item Galoisfeld-Arithmetik definiert über Termen (z.B. \$a\_3x\^{}3+a\_2x\^{}2+a\_1x+a\_0\$) - \item - Koeffizienten sind Elemente des Feldes + \item Koeffizienten sind Elemente des Feldes \$\textbackslash matbb\{Z\}\_2\$, d.h. entweder 0 oder 1 - \item - Oft werden nur die Koeffizienten gespeichert, so wird aus x\^{}4 + \item Oft werden nur die Koeffizienten gespeichert, so wird aus x\^{}4 +x\^{}2 +x\^{}1 0x16 - \item - Die Addition in \$GF(2\^{}n)\$ ist einfach die Addition von Termen - + \item Die Addition in \$GF(2\^{}n)\$ ist einfach die Addition von Termen \begin{itemize*} \item Da gleiche Koeffizienten auf 0 abbilden, einfach XOR der Werte! \item Extrem schnell in Hard- und Software! \end{itemize*} - \item - Multiplikation in \$GF(2\^{}n)\$ ist Polynommultiplikation und + \item Multiplikation in \$GF(2\^{}n)\$ ist Polynommultiplikation und anschließende Modulodivision durch ein irreduzibles Polynom vom Grad n - \begin{itemize*} \item Irreduzible Polynome sind nicht ohne Rest durch irgendein anderes Polynom teilbar, außer durch ,,1'', ähnlich wie Primzahlen in GF \item Kann durch eine Reihe von Verschiebe- und XOR-Operationen implementiert werden \item Sehr schnell in Hardware oder auf neueren Intel-CPUs (mit CLMUL-Operationen) \item Modulo-Operation kann wie bei einer regulären CRC-Berechnung durchgeführt werden \end{itemize*} - \item - Addition Beispiel: - + \item Addition Beispiel: \begin{itemize*} \item \$x\^{}3 +x+1 x\textbackslash oplus x\^{}2+x = x\^{}3 +x\^{}2 +1 \textbackslash leftrightarrow\$ 0x0B XOR 0x06 = 0x0D \end{itemize*} - \item - Multiplikationsbeispiel (über \$x\^{}4 +x+1\$): - + \item Multiplikationsbeispiel (über \$x\^{}4 +x+1\$): \begin{itemize*} \item \$x\^{}3 +x+1\textbackslash circ x\^{}2+x = x\^{}5+x\^{}3+x\^{}2\textbackslash oplus x\^{}4+x\^{}2+x\textbackslash{} MOD\textbackslash{} x\^{}4+x+1=x\^{}5+x\^{}4+x\^{}3+x\textbackslash{} MOD\textbackslash{} x\^{}4+x+1 = x\^{}3 +x\^{}2 +x+1\$ \end{itemize*} - \item - Elemente von \$GF(2\^{}n)\$ (mit Ausnahme von 1 und dem irreduziblen + \item Elemente von \$GF(2\^{}n)\$ (mit Ausnahme von 1 und dem irreduziblen Polynom) können ein Generator für die Gruppe sein - \item - Beispiel für x und das Polynom + \item Beispiel für x und das Polynom \$x\^{}4+x+1:x,x\^{}2,x\^{}3,x+1,x\^{}2+x,x\^{}3+x\^{}2,x\^{}3+x+1,x\^{}2 +1,x\^{}3+x,x\^{}2+x+1,x\^{}3+x\^{}2+x,x\^{}3+x\^{}2+x+1,x\^{}3+x\^{}2+1,x\^{}3+1,1,x,...\$ - \item - Andere Konzepte endlicher Gruppen gelten ebenfalls, z. B. hat jedes + \item Andere Konzepte endlicher Gruppen gelten ebenfalls, z. B. hat jedes Element ein multiplikatives inverses Element - \begin{itemize*} \item Kann durch eine angepasste Version des Erweiterten Euklidischen Algorithmus gefunden werden \end{itemize*} @@ -3285,28 +2394,20 @@ \subsection{SpongeWrap} \begin{itemize*} - \item - Durch Verwendung von SHA-3 ist es auch möglich, ein AEAD-Konstrukt zu + \item Durch Verwendung von SHA-3 ist es auch möglich, ein AEAD-Konstrukt zu implementieren {[}BDP11a{]} - \item - Die Konstruktion ist sehr einfach und vergleichsweise leicht zu + \item Die Konstruktion ist sehr einfach und vergleichsweise leicht zu verstehen - \item - Verwendet den sogenannten Duplex-Modus für Sponge-Funktionen, bei dem + \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 Erfordert kein Auffüllen der Daten auf eine bestimmte Blockgröße + \item Kann nicht parallelisiert werden + \item Sicherheit: \begin{itemize*} \item Noch nicht weit verbreitet, aber mehrere Aspekte haben sich als genauso sicher wie SHA-3 im standardisierten Modus erwiesen \item Wenn die authentifizierten Daten A keine eindeutige IV enthalten, wird derselbe Schlüsselstrom erzeugt (ermöglicht die Wiederherstellung eines Blocks XOR-verschlüsselter Daten) \end{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-sponge-wrap.png} - \begin{itemize*} \item Vereinfachte Version, bei der die Länge von Schlüssel und MAC kleiner sein muss als die Blockgröße \item Auffüllungen mit einem einzelnen ,,0''- oder ,,1''-Bit stellen sicher, dass verschiedene Datenblocktypen gut voneinander getrennt sind @@ -3321,50 +2422,36 @@ 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. \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. \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: - + \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: - + \item Vernichtung: \begin{itemize*} \item Schlüssel, die nicht mehr verwendet werden (z. B. alte Sitzungsschlüssel), sollten sicher vernichtet werden. \end{itemize*} - \item - Wiederherstellung: - + \item Wiederherstellung: \begin{itemize*} \item Wenn ein Schlüssel verloren gegangen ist (z. B. defekte Chipkarte, Diskette, versehentliches Löschen), sollte er wiederhergestellt werden können, um Datenverluste zu vermeiden. \item Die Wiederherstellung von Schlüsseln ist nicht zu verwechseln mit der Schlüsselhinterlegung \end{itemize*} - \item - Hinterlegung: - + \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*} @@ -3376,12 +2463,10 @@ Pseudo-Zufallszahlengenerierung} \begin{itemize*} - \item - Definition: ,,Ein Zufallsbitgenerator ist ein Gerät oder ein + \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 + \item Bemerkung: Ein Zufallsbitgenerator kann zur Erzeugung gleichmäßig verteilter Zufallszahlen verwendet werden, z. B. kann eine zufällige ganze Zahl im Intervall \${[}0,n{]}\$ erhalten werden, indem eine zufällige Bitfolge der Länge \$\textbackslash lfloor lg @@ -3389,59 +2474,47 @@ 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 + \item Definition: Ein Pseudo-Zufallsbitgenerator (PRBG) ist ein deterministischer Algorithmus, der bei einer wirklich zufälligen Binärfolge der Länge k eine Binärfolge der Länge \$m\textgreater\textgreater k\$ ausgibt, die ,,zufällig'' erscheint. Die Eingabe in den PRBG wird als Seed bezeichnet, die Ausgabe als pseudozufällige Bitfolge. - \item - Bemerkungen: - + \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\textbackslash times y\_\{i-1\} + b\textbackslash{} mod\textbackslash{} q\$, wobei \$a, b, q\$ Parameter sind, die den PRBG charakterisieren \item Leider ist dieser Generator auch dann vorhersehbar, wenn \$a, b\$ und \$q\$ unbekannt sind, und sollte daher nicht für kryptographische Zwecke verwendet werden \end{itemize*} - \item - Sicherheitsanforderungen an PRBGs für die Verwendung in der + \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, + \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 + \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 + \item Theorem (Universalität des Next-Bit-Tests): Wenn eine PRBG den Next-Bit-Test \$\textbackslash Leftrightarrow\$ besteht, dann besteht sie alle statistischen Polynomialzeittests - \item - Definition: Ein PRBG, der den Next-Bit-Test besteht - möglicherweise + \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) @@ -3452,10 +2525,8 @@ \subsection{Zufallszahlengenerierung} \begin{itemize*} - \item - Hardware-basierte Zufallsbit-Generatoren basieren auf physikalischen + \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, @@ -3465,14 +2536,11 @@ \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 + \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 + \item Softwarebasierte Zufallsbit-Generatoren können auf Prozessen basieren wie - \begin{itemize*} \item der Systemuhr, \item der verstrichenen Zeit zwischen Tastenanschlägen oder Mausbewegungen, @@ -3480,32 +2548,25 @@ \item Benutzereingaben und \item Werte des Betriebssystems wie Systemauslastung und Netzwerkstatistiken \end{itemize*} - \item - Idealerweise sollten mehrere Zufallsquellen ,,gemischt'' werden, z. B. + \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\textbackslash not= 0,5\$ und 0en mit der Wahrscheinlichkeit \$1-p\$, wobei p unbekannt, aber fest ist \end{itemize*} - \item - Die folgende Technik kann verwendet werden, um eine Zufallsfolge zu + \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 + \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 @@ -3516,11 +2577,9 @@ Zufallszahlen} \begin{itemize*} - \item - Mit den folgenden Tests lässt sich überprüfen, ob eine generierte + \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? @@ -3537,17 +2596,13 @@ Pseudo-Zufallszahlengenerierung} \begin{itemize*} - \item - Es gibt eine Reihe von Algorithmen, die kryptografische + \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 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\$ @@ -3555,14 +2610,11 @@ \begin{enumerate*} \def\labelenumii{\arabic{enumii}.} \item \$x\_i = E(K, (q\textbackslash oplus s)\$ \item \$s = E(K, (x\_i\textbackslash oplus q)\$ \end{enumerate*} \item \$Return(x\_1,x\_2,...x\_m)\$ \end{enumerate*} \item Diese Methode ist eine vom U.S. Federal Information Processing Standard (FIPS) zugelassene Methode zur pseudozufälligen Erzeugung von Schlüsseln und Initialisierungsvektoren zur Verwendung mit DES \end{itemize*} - \item - Das RSA-PRBG ist ein CSPRBG unter der Annahme, dass das RSA-Problem + \item Das RSA-PRBG ist ein CSPRBG unter der Annahme, dass das RSA-Problem unlösbar ist: - \begin{itemize*} \item Ausgabe: eine pseudo-zufällige Bitfolge \$z\_1,z\_2,...,z\_k\$ der Länge k \end{itemize*} - \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item Setup-Prozedur: Erzeuge zwei geheime Primzahlen \$p, q\$, die für die Verwendung mit RSA geeignet sind. Berechne \$n=p\textbackslash times q\$ und \$\textbackslash phi=(p-1)\textbackslash times(q-1)\$. Wähle eine zufällige ganze Zahl e so, dass \$1\textless e\textless\textbackslash phi\$ und \$gcd(e,\textbackslash phi)=1\$ @@ -3570,19 +2622,15 @@ \item Für i von 1 bis k tun \begin{enumerate*} \def\labelenumii{\arabic{enumii}.} \item \$y\_i=(y\_\{i-1\})\^{}e\textbackslash{} mod\textbackslash{} n\$ \item \$z\_i =\$ das niedrigstwertige Bit von \$y\_i\$ \end{enumerate*} \end{enumerate*} - \begin{itemize*} \item Die Effizienz des Generators kann leicht verbessert werden, indem man die letzten j Bits von jedem \$y\_i\$ nimmt, wobei \$j=c\textbackslash times lg(lg(n))\$ und c eine Konstante ist \item Für eine gegebene Bitlänge m von n wurde jedoch noch kein Wertebereich für die Konstante c ermittelt, in dem der Algorithmus noch einen CSPRBG ergibt \end{itemize*} - \item - Der Blum-Blum-Shub-PRBG ist ein CSPRBG unter der Annahme, dass das + \item Der Blum-Blum-Shub-PRBG ist ein CSPRBG unter der Annahme, dass das Problem der ganzzahligen Faktorisierung unlösbar ist: - \begin{itemize*} \item Ausgabe: eine pseudo-zufällige Bitfolge \$z\_1,z\_2,...,z\_k\$ der Länge k \end{itemize*} - \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item Setup-Prozedur: Erzeuge zwei große geheime und unterschiedliche Primzahlen \$p,q\$, so dass \$p,q\$ jeweils kongruent 3 modulo 4 sind, und lass \$n=p\textbackslash times q\$ @@ -3590,13 +2638,10 @@ \item Für i von 1 bis k tun \begin{enumerate*} \def\labelenumii{\arabic{enumii}.} \item \$y\_i = (y\_\{i-1\})\^{}2\textbackslash{} mod\textbackslash{} n\$ \item \$z\_i =\$ das niedrigstwertige Bit von \$y\_i\$ \end{enumerate*} \end{enumerate*} - \begin{itemize*} \item Die Effizienz des Generators kann mit der gleichen Methode wie beim RSA-Generator verbessert werden, wobei ähnliche Einschränkungen für die Konstante c gelten \end{itemize*} - \item - Dualer deterministischer Zufallsbitgenerator mit elliptischer Kurve: - + \item Dualer deterministischer Zufallsbitgenerator mit elliptischer Kurve: \begin{itemize*} \item Basierend auf der Unlösbarkeit des Problems des diskreten Logarithmus elliptischer Kurven \item Vereinfachte Version: % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-dual-elliptic-curve-deterministic-random-bit-generator.png} @@ -3613,25 +2658,19 @@ Sache!} \begin{itemize*} - \item - Im September 2006 wurde Debian versehentlich so verändert, dass nur + \item Im September 2006 wurde Debian versehentlich so verändert, dass nur die Prozess-ID verwendet wurde, um den OpenSSL CSPRNG zu füttern - \begin{itemize*} \item Nur 32.768 mögliche Werte! \item Wurde bis Mai 2008 nicht entdeckt \end{itemize*} - \item - Ein Scan von etwa 23 Millionen TLS- und SSH-Hosts zeigte, dass - + \item Ein Scan von etwa 23 Millionen TLS- und SSH-Hosts zeigte, dass \begin{itemize*} \item Mindestens 0,34\% der Hosts teilten Schlüssel aufgrund fehlerhafter RNGs \item 0,50\% der gescannten TLS-Schlüssel aufgrund einer geringen Zufälligkeit kompromittiert werden konnten \item und 1,06\% der SSH-Hosts... \end{itemize*} - \item - Überwachen Sie Ihren CSPRNG! - + \item Überwachen Sie Ihren CSPRNG! \begin{itemize*} \item Generieren Sie keine Zufallszahlen direkt nach dem Booten Ihres Systems \item Verwenden Sie blockierende RNGs, d.h. solche, die nicht fortfahren, bis sie genügend Entropie haben @@ -3643,22 +2682,17 @@ Protokolle} \begin{itemize*} - \item - Definition: Ein kryptographisches Protokoll ist definiert als eine + \item Definition: Ein kryptographisches Protokoll ist definiert als eine Reihe von Schritten und der Austausch von Nachrichten zwischen mehreren Einheiten, um ein bestimmtes Sicherheitsziel zu erreichen. - \item - Eigenschaften eines Protokolls (im Allgemeinen): - + \item Eigenschaften eines Protokolls (im Allgemeinen): \begin{itemize*} \item Jeder, der an dem Protokoll beteiligt ist, muss das Protokoll und alle zu befolgenden Schritte im Voraus kennen \item Jeder, der an dem Protokoll beteiligt ist, muss zustimmen, es zu befolgen. \item Das Protokoll muss eindeutig sein, d.h. jeder Schritt ist genau definiert, und es gibt keine Möglichkeit für Missverständnisse \item Das Protokoll muss vollständig sein, d. h. es gibt für jede mögliche Situation eine bestimmte Aktion. \end{itemize*} - \item - Zusätzliche Eigenschaft eines kryptographischen Protokolls: - + \item Zusätzliche Eigenschaft eines kryptographischen Protokolls: \begin{itemize*} \item Es sollte nicht möglich sein, mehr zu tun oder zu erfahren als das, was im Protokoll angegeben ist. \end{itemize*} @@ -3669,60 +2703,43 @@ Protokollen} \begin{itemize*} - \item - Schlüsselaustausch - \item - Authentifizierung - + \item Schlüsselaustausch + \item Authentifizierung \begin{itemize*} \item Authentifizierung der Datenherkunft \item Authentifizierung von Entitäten \end{itemize*} - \item - Kombinierte Authentifizierung und Schlüsselaustausch - \item - Aufteilung des Geheimnisses (alle Teile werden für die Rekonstruktion + \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 + \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 + \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 + \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 + \item Blindsignaturen (nützlich für die Wahrung der Privatsphäre bei Zeitstempeldiensten) - \item - Sichere Wahlen - \item - Elektronisches Geld + \item Sichere Wahlen + \item Elektronisches Geld \end{itemize*} \subsection{Schlüsselaustausch} \begin{itemize*} - \item - Das vorgestellte Diffie-Hellman-Protokoll ist unser erstes Beispiel + \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 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 + \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. @@ -3739,10 +2756,8 @@ verändert wurde. Ein Synonym für diesen Dienst ist Datenintegrität. \begin{itemize*} - \item - Die Beziehung zwischen Datenintegrität und kryptografischen + \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*} @@ -3759,13 +2774,10 @@ überprüfen. \begin{itemize*} - \item - Die Entitätsauthentifizierung ist der grundlegendste + \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 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 @@ -3773,15 +2785,12 @@ \item Ort: Es wird der Nachweis erbracht, dass sich eine Entität an einem bestimmten Ort befindet (Beispiel: Menschen überprüfen selten die Authentizität von Agenten in einer Bank) \item Delegation der Authentizität: Die überprüfende Stelle akzeptiert, dass eine vertrauenswürdige Person die Authentifizierung bereits vorgenommen hat. \end{itemize*} - \item - In Kommunikationsnetzen ist die direkte Überprüfung der oben genannten + \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 + \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*} @@ -3790,14 +2799,11 @@ \item Zwei grundsätzliche Mittel zur Sicherstellung der Aktualität in kryptographischen Protokollen: \begin{itemize*} \item Zeitstempel (erfordern mehr oder weniger synchronisierte Uhren) \item Zufallszahlen (Challenge-Response-Austausch) \end{itemize*} \end{itemize*} - \item - Die meisten Authentifizierungsprotokolle erstellen auch einen geheimen + \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 + \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: @@ -3846,16 +2852,12 @@ Needham-Schroeder-Protokoll} \begin{itemize*} - \item - Erfunden im Jahr 1978 von Roger Needham und Michael Schroeder + \item Erfunden im Jahr 1978 von Roger Needham und Michael Schroeder {[}Nee78a{]} - \item - Das Protokoll basiert auf symmetrischer Verschlüsselung und nutzt eine + \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 + \item Angenommen, TTP teilt die geheimen Schlüssel KA,TTP und KB,TTP mit Alice bzw. Bob: - \begin{itemize*} \item A erzeugt eine Zufallszahl rA und sendet die folgende Nachricht: \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$A\textbackslash rightarrow TTP: (A, B, r\_A)\$ \end{enumerate*} @@ -3865,9 +2867,7 @@ \item Alice entschlüsselt die Nachricht, errechnet \$r\_\{B\}-1\$ und antwortet mit: 5.) \$A\textbackslash rightarrow B:\{r\_B-1\}\emph{\{K}\{A,B\}\}\$ \item Bob entschlüsselt die Nachricht und prüft, ob sie \$r\_B-1\$ enthält. \end{itemize*} - \item - Diskussion: - + \item Diskussion: \begin{itemize*} \item Der Austausch von \$r\_B\$ und \$r\_\{B-1\}\$ soll sicherstellen, dass ein Angreifer, der versucht, sich als Alice auszugeben, keinen vollständigen Protokolldurchlauf mit nachgespielten Nachrichten durchführen kann \item Da jedoch alte Sitzungsschlüssel \$K\_\{A,B\}\$ gültig bleiben, kann ein Angreifer, Eve, der es schafft, einen Sitzungsschlüssel \$K\_\{A,B\}\$ in Erfahrung zu bringen, diesen später dazu verwenden, sich als Alice auszugeben: @@ -3880,12 +2880,10 @@ \subsection{Das Otway-Rees-Protokoll} \begin{itemize*} - \item - Das oben beschriebene Sicherheitsproblem sowie einige andere wurden + \item Das oben beschriebene Sicherheitsproblem sowie einige andere wurden von Needham und Schroeder behandelt. Ihre Lösung {[}Nee87a{]} ist im Wesentlichen die gleiche wie die von Otway und Rees in der gleichen Zeitschrift {[}Otw87a{]} vorgeschlagene: - \begin{itemize*} \item Alice generiert eine Nachricht, die eine Indexzahl \$i\_A\$, ihren Namen A, Bobs Namen B und die gleichen Informationen plus eine zusätzliche Zufallszahl \$r\_A\$ enthält, die mit dem Schlüssel \$K\_\{A,TTP\}\$ verschlüsselt ist, den sie mit TTP teilt, und sendet diese Nachricht an Bob: \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$A\textbackslash rightarrow B:(i\_A, A, B,\{r\_A, i\_A, A, B\}\emph{\{K}\{A,TTP\}\})\$ \end{enumerate*} @@ -3894,9 +2892,7 @@ \item Bob entschlüsselt seinen Teil der Nachricht, verifiziert rB und sendet Alices Teil der Nachricht an sie: 4. \$B\textbackslash rightarrow A:(i\_A,\{r\_A,K\_\{A,B\}\}\emph{\{K}\{A,TTP\}\})\$ \item Alice entschlüsselt die Nachricht und überprüft, ob sich \$i\_A\$ und \$r\_A\$ während des Austauschs nicht geändert haben. Wenn nicht, kann sie sicher sein, dass TTP ihr einen neuen Sitzungsschlüssel \$K\_\{A,B\}\$ für die Kommunikation mit Bob geschickt hat. Wenn sie nun diesen Schlüssel in einer verschlüsselten Kommunikation mit Bob verwendet, kann sie sich seiner Authentizität sicher sein. \end{itemize*} - \item - Diskussion: - + \item Diskussion: \begin{itemize*} \item Die Indexzahl \$i\_A\$ schützt vor Replay-Attacken. Dies erfordert jedoch, dass TTP überprüft, ob \$i\_A\$ größer ist als das letzte \$i\_A\$, das er von Alice erhalten hat. \item Da TTP nur dann zwei Nachrichten generiert, wenn beide Teile der Nachricht, die er erhält, die gleiche Indexnummer \$i\_A\$ und die Namen \$A, B,\$ enthalten, können Alice und Bob sicher sein, dass sie sich beide während des Protokolllaufs gegenüber TTP authentifiziert haben. @@ -3907,36 +2903,28 @@ \subsection{Kerberos} \begin{itemize*} - \item - Kerberos ist ein Authentifizierungs- und Zugangskontrolldienst für + \item Kerberos ist ein Authentifizierungs- und Zugangskontrolldienst für Workstation-Cluster, der in den späten 1980er Jahren am MIT entwickelt wurde. - \item - Entwurfsziele: - + \item Entwurfsziele: \begin{itemize*} \item Sicherheit: Abhörer oder aktive Angreifer sollten nicht in der Lage sein, die notwendigen Informationen zu erhalten, um sich beim Zugriff auf einen Dienst als ein Benutzer auszugeben \item Zuverlässigkeit: Da jede Nutzung eines Dienstes eine vorherige Authentifizierung erfordert, sollte Kerberos höchst zuverlässig und verfügbar sein. \item Transparenz: Der Authentifizierungsprozess sollte für den Benutzer transparent sein und nicht nur die Eingabe eines Passworts erfordern. \item Skalierbarkeit: Das System sollte in der Lage sein, eine große Anzahl von Clients und Servern zu unterstützen. \end{itemize*} - \item - Das Kerberos zugrunde liegende kryptografische Verfahren ist die + \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 + \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, + \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 + \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. @@ -3948,20 +2936,16 @@ \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Kerberos.png} - \item - Der Benutzer meldet sich an seiner Arbeitsstation an und fordert den + \item Der Benutzer meldet sich an seiner Arbeitsstation an und fordert den Zugriff auf einen Dienst an: - \begin{itemize*} \item Die Workstation repräsentiert ihn im Kerberos-Protokoll und sendet die erste Nachricht an den Authentifizierungsserver AS, die seinen Namen, den Namen eines geeigneten Ticket-Granting-Servers TGS und einen Zeitstempel \$t\_A\$ enthält: \end{itemize*} - \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$A\textbackslash rightarrow AS:(A, TGS, t\_A)\$ \end{enumerate*} - \item - Der AS prüft, ob A sich für den Zugang zu den Diensten + \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 @@ -3970,20 +2954,17 @@ t\_\{AS\}, LifetimeTicket\_\{TGS\}, Ticket\_\{TGS\}\}\emph{\{K\_A\}\$ mit \$Ticket}\{TGS\}=\{K\_\{A,TGS\},A, Addr\_A, TGS, t\_\{AS\}, LifetimeTicket\_\{TGS\}\}\emph{\{K}\{AS,TGS\}\}\$ - \item - Nach Erhalt dieser Nachricht fordert die Workstation Alice auf, ihr + \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 + \item Alice erstellt einen sogenannten Authenticator und sendet ihn zusammen mit dem Ticket und dem Namen des Servers \$S1\$ an TGS: 3. \$A\textbackslash rightarrow TGS:(S1, Ticket\_\{TGS\}, Authenticator\_\{A,TGS\})\$ mit Authenticator \$A,TGS=\{A,Addr\_A,t'\emph{A\}}\{K\_\{A,TGS\}\}\$ - \item - Nach Erhalt entschlüsselt TGS \$Ticket\_\{TGS\}\$, extrahiert daraus + \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 @@ -3993,30 +2974,25 @@ Ticket\_\{S1\}\}\emph{\{K}\{A,TGS\}\}\$ mit \$Ticket\_\{S1\}=\{K\_\{A,S1\}, A, Addr\_A, S1, t\_\{TGS\}, LifetimeTicket\_\{S1\}\}\emph{\{K}\{TGS,S\}\}\$ - \item - Alice entschlüsselt die Nachricht und verfügt nun über einen + \item Alice entschlüsselt die Nachricht und verfügt nun über einen Sitzungsschlüssel für die sichere Kommunikation mit S1. Sie sendet nun eine Nachricht an S1, um ihm ihr Ticket und einen neuen Authentifikator zu zeigen: 5. \$A\textbackslash rightarrow S1:(Ticket\_\{S1\}, Authenticator\_\{A,S1\})\$ mit \$Authenticator\_\{A,S1\}=\{A,Addr\_A, t''\emph{A\}}\{K\_\{A,S1\}\}\$ - \item - Nach Erhalt entschlüsselt S1 das Ticket mit dem Schlüssel + \item Nach Erhalt entschlüsselt S1 das Ticket mit dem Schlüssel \$K\_\{TGS,S1\}\$, den er mit TGS teilt, und erhält den Sitzungsschlüssel \$K\_\{A,S1\}\$ für die sichere Kommunikation mit A. Mit diesem Schlüssel überprüft er den Authentifikator und antwortet A: 6. \$S1\textbackslash rightarrow A:\{t'\,'\emph{A+1\}}\{K\_\{A,S\}\}\$ - \item - Durch Entschlüsselung dieser Nachricht und Überprüfung des enthaltenen + \item Durch Entschlüsselung dieser Nachricht und Überprüfung des enthaltenen Wertes kann Alice nachweisen, dass sie wirklich mit S1 kommuniziert, da nur er (neben TGS) den Schlüssel \$K\_\{TGS,S1\}\$ zur Entschlüsselung von \$Ticket\_\{S1\}\$ kennt, der den Sitzungsschlüssel \$K\_\{A,S1\}\$ enthält, und somit nur er in der Lage ist, \$Authenticator\_\{A,S1\}\$ zu entschlüsseln und mit \$t''\emph{\{A+1\}\$ verschlüsselt mit \$K}\{A,S\}\$ zu antworten - \item - Das oben beschriebene Protokoll ist der Kerberos-Dialog der Version 4. - + \item Das oben beschriebene Protokoll ist der Kerberos-Dialog der Version 4. \begin{itemize*} \item In diesem Protokoll wurden eine Reihe von Mängeln festgestellt, so dass eine neue Version 5 des Protokolls definiert wurde, auf die wir später eingehen werden... \item Wo liegt eigentlich das Problem? @@ -4028,20 +3004,16 @@ Domänen} \begin{itemize*} - \item - Stellen Sie sich eine Organisation mit Workstation-Clustern an zwei + \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 + \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. @@ -4049,10 +3021,8 @@ \item Skalierbarkeitsproblem: n Realms benötigen \$n\textbackslash 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 + \item Nachrichten, die während eines Protokolllaufs mit mehreren Domänen ausgetauscht werden: - \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$A\textbackslash rightarrow AS1:(A,TGS1, t\_A)\$ @@ -4070,89 +3040,71 @@ \subsubsection{Kerberos Version 5} \begin{itemize*} - \item - Letzter Standard von 2005 (RFC 4120) - \item - Entwickelt als Reaktion auf Schwachstellen, die bei Kerberos v4 + \item Letzter Standard von 2005 (RFC 4120) + \item Entwickelt als Reaktion auf Schwachstellen, die bei Kerberos v4 bekannt wurden - \begin{itemize*} \item Enthält explizite Prüfsummen, um zu verifizieren, dass die Nachrichten nicht verändert wurden \item Unterstützt mehrere Chiffren (andere als das unsichere DES) \end{itemize*} - \item - Einheitliches Nachrichtenformat - Nachrichten an den + \item Einheitliches Nachrichtenformat - Nachrichten an den Authentifizierungsserver und den Ticketvergabeserver sind sehr ähnlich - \item - Flexible ASN.1-Kodierung der Nachrichten, ermöglicht spätere + \item Flexible ASN.1-Kodierung der Nachrichten, ermöglicht spätere Erweiterungen - \item - Im Folgenden wird nur eine vereinfachte Version gezeigt, weit mehr + \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 + \item Der Authentifizierungsdialog in Kerberos Version 5 ist ähnlich wie in Version 4 - \item - Der Austausch des Authentifizierungsdienstes: Bei der ersten + \item Der Austausch des Authentifizierungsdienstes: Bei der ersten Kontaktaufnahme sendet der Client A nicht nur Namen und Zeitstempel, sondern auch eine Nonce n , die hilft, Wiederholungen zu vermeiden, wenn sich die Zeit geändert hat; es ist auch möglich, mehrere Adressen anzugeben - \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$A\textbackslash rightarrow AS:(A,TGS,t\_\{start\},t\_\{end\},n,Addr\_A, ...)\$ \end{enumerate*} - \item - Die Antwort enthält ein Klartext-Ticket und verschlüsselte + \item Die Antwort enthält ein Klartext-Ticket und verschlüsselte Informationen: 2. \$AS\textbackslash rightarrow A: (A,Ticket\_\{TGS\},\{K\_\{A,TGS\}, LastRequest,n,t\_\{expire\},t\_\{AS\},t\_\{start\},t\_\{end\},t\_\{renew\},TGS, Addr\_A\}\emph{\{K\_A\})\$ mit \$Ticket}\{TGS\}=(TGS, \{K\_\{A,TGS\},A,transited, t\_\{AS\}, t\_\{start\},t\_\{end\},t\_\{renew\},Addr\_A,restrictions\}\emph{\{K}\{AS,TGS\}\})\$ - \begin{itemize*} \item LastRequest gibt den letzten Login des Benutzers an transited enthält die Vertrauenskette Multidomain Kerberos Restriktionen für den Benutzer können dem TGS und den Servern übergeben werden \$t\_\{expire\}\$ und \$t\_\{end\}\$ enthalten verschiedene Zeiten, um die Erneuerung von Tickets zu ermöglichen (wobei die Start- und Endzeit einfach aktualisiert werden können) \end{itemize*} - \item - Der Dialog zum TGS ist mit dem Ausgangsdialog harmonisiert: Er enthält + \item Der Dialog zum TGS ist mit dem Ausgangsdialog harmonisiert: Er enthält zusätzlich Tickets und einen Authentifikator, der beweist, dass A \$K\_\{A,TGS\}\$ kennt 3. \$Aufrechtes TGS:(A,S1,t\_\{start\},t\_\{end\},n',Addr\_A,Authenticator\_\{A,TGS\}, Tickets,...)\$ mit \$Authenticator\_\{A,TGS\}=\{A, CheckSum, t\_\{A'\}, K\_\{A,TGS'\}, Seq\#,...\}\emph{\{K}\{A,TGS\}\}\$ Hinweis: Der Authentifikator enthält jetzt eine kryptographische Prüfsumme! - \item - Die Antwort an A ist völlig analog zu Nachricht 2: 4. + \item Die Antwort an A ist völlig analog zu Nachricht 2: 4. \$TGS\textbackslash rightarrow A:(A,Ticket\_\{S1\},\{K\_\{A,S1\},LastRequest, n',t\_\{expire\},t\_\{TGS\},t\_\{start\},t\_\{end\},t\_\{renew\},S1,Addr\_A\}\emph{\{K}\{A,TGS\}\})\$ - \item - Der Austausch mit dem Server ist ebenfalls ähnlich wie bei Version 4, + \item Der Austausch mit dem Server ist ebenfalls ähnlich wie bei Version 4, aber mit dem Authentifikator ist eine explizite Prüfsumme möglich: 5. \$A\textbackslash rightarrow S1:(Ticket\_\{S1\}, Authenticator\_\{A,S1\})\$ mit \$Authenticator\_\{A,S1\}=\{A,CheckSum,t\_\{A''\},K\_\{A,S1\}', Seq\#, ...\}\emph{\{K}\{A,S1\}\}\$ - \item - Nach Erhalt entschlüsselt S1 das Ticket mit dem Schlüssel + \item Nach Erhalt entschlüsselt S1 das Ticket mit dem Schlüssel \$K\_\{TGS,S1\}\$, den er mit TGS teilt, und erhält den Sitzungsschlüssel \$K\_\{A,S1\}\$ für die sichere Kommunikation mit A. Mit diesem Schlüssel überprüft er den Authentifikator und antwortet A: 6. \$S1\textbackslash rightarrow A:\{t\_\{S1\},K\_\{A,S1\}',Seq\#,...\}\emph{\{K}\{A,S1\}\}\$ - \item - Alles in allem behebt der Dialog mehrere potenzielle Schwachstellen, + \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 @@ -4166,27 +3118,21 @@ Passwortauthentifizierung} \begin{itemize*} - \item - Alle gezeigten Protokolle haben eine gemeinsame Schwäche: - + \item Alle gezeigten Protokolle haben eine gemeinsame Schwäche: \begin{itemize*} \item Passwörter müssen leicht zu merken und leicht einzugeben sein \$\textbackslash rightarrow\$ Geringe Entropie \item Angreifer können schnell alle möglichen Kombinationen ausprobieren \item Offline, über Grafikkarten, Cloud-Computer, spezielle Hardware... \item Asymmetrische Situation \end{itemize*} - \item - Mögliche Lösungen: - + \item Mögliche Lösungen: \begin{itemize*} \item Schlüsselableitungsfunktionen \begin{itemize*} \item Erschweren Brute-Force-Angriffe durch extrem häufiges Hashing \item Erfordert auch Aufwand durch legitime Geräte \item Nur linearer Sicherheitsgewinn \item Bessere Funktionen verbrauchen viel Speicher, um Angriffe mit Grafikkarten und spezieller Hardware undurchführbar zu machen \end{itemize*} \item Passwort-authentifizierter Schlüsselaustausch (PAKE) \end{itemize*} - \item - Passwortauthentifizierter Schlüsselaustausch (PAKE) - Grundlegende + \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 @@ -4201,40 +3147,32 @@ \subsection{PAKE-Schemata: EKE} \begin{itemize*} - \item - Ein einfaches erstes Protokoll ist Encrypted Key Exchange (EKE) + \item Ein einfaches erstes Protokoll ist Encrypted Key Exchange (EKE) {[}BM92{]} - \item - Der Dialog beginnt damit, dass A ein privates/öffentliches + \item Der Dialog beginnt damit, dass A ein privates/öffentliches Schlüsselpaar zur einmaligen Verwendung erzeugt und den öffentlichen Schlüssel \$+K\_\{ar\}\$ verschlüsselt mit dem Passwort \$K\_\{A,B\}\$ an B sendet - \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$A\textbackslash rightarrow B:A,\{+K\_\{ar\}\}\emph{\{K}\{A,B\}\}\$ \end{enumerate*} - \item - B wählt einen symmetrischen Sitzungsschlüssel \$K\_r\$ und sendet ihn + \item B wählt einen symmetrischen Sitzungsschlüssel \$K\_r\$ und sendet ihn verschlüsselt mit dem öffentlichen Schlüssel und dem Passwort zurück an A - \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$B\textbackslash rightarrow A:\{\{K\_r\}\emph{\{+K}\{ar\}\}\}\emph{\{K}\{A,B\}\}\$ \end{enumerate*} - \item - A und B teilen sich nun einen gemeinsamen Sitzungsschlüssel und + \item A und B teilen sich nun einen gemeinsamen Sitzungsschlüssel und beweisen ihr Wissen darüber durch den Austausch von Nonces - \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$A\textbackslash rightarrow B:\{r\_A\}\_\{K\_r\}\$ \item \$B\textbackslash rightarrow A:\{r\_A,r\_B\}\_\{K\_r\}\$ \item \$A\textbackslash rightarrow B:\{r\_B\}\_\{K\_r\}\$ \end{enumerate*} - \item - Nach diesem Schritt ist sichergestellt, dass beide \$K\_\{A,B\}\$ + \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*} @@ -4243,43 +3181,34 @@ \subsubsection{Sicherheitsdiskussion} \begin{itemize*} - \item - Resistenz gegen Offline-Angriffe hängt davon ab, dass \$+K\_\{ar\}\$ + \item Resistenz gegen Offline-Angriffe hängt davon ab, dass \$+K\_\{ar\}\$ nicht von Zufallszahlen zu unterscheiden ist - \begin{itemize*} \item Was bedeutet das für ECC? \item Für RSA schlagen die Autoren vor, e zu verschlüsseln und n im Klartext zu senden \begin{itemize*} \item n hat keine kleinen Primfaktoren und ist daher von Zufallszahlen unterscheidbar \item Immer noch unsicher gegen Man-in-the-Middle-Angriffe, da Angreifer n mit besonderen Eigenschaften wählen können (z.B. \$p-1\$ und \$q-1\$ teilbar durch 3) \item Antwort von B ist von Zufallszahlen unterscheidbar \item Details sind in {[}Par97{]} oder {[}SR14{]} zu finden. \end{itemize*} \end{itemize*} - \item - Bietet keine perfekte Vorwärtsverschwiegenheit... - \item - Aber es gibt ein anderes Protokoll von den Autoren namens DH-EKE + \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\}\$ - + \item DH-EKE ist im Grunde ein DH-Austausch mit cleverer Authentifizierung + \item A sendet DH-Austausch verschlüsselt mit dem Passwort \$K\_\{A,B\}\$ \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$A\textbackslash rightarrow B:\{g\^{}\{ra\}\textbackslash{} mod\textbackslash{} p\}\emph{\{K}\{A,B\}\}\$ \end{enumerate*} - \item - B antwortet mit seinem Teil des DH-Austauschs (verschlüsselt mit dem + \item B antwortet mit seinem Teil des DH-Austauschs (verschlüsselt mit dem Passwort \$K\_\{A,B\}\$) und verwendet den Sitzungsschlüssel \$K\_S=g\^{}\{ra*rb\}\textbackslash{} mod\textbackslash{} p\$, um eine verschlüsselte Nonce \$c\_b\$ zu senden 2. \$B\textbackslash rightarrow A:\{g\^{}\{rb\}\textbackslash{} mod\textbackslash{} p\}\emph{\{K}\{A,B\}\}\{c\_b\}\_\{K\_s\}\$ - \item - Beide Parteien beweisen ihre Kenntnis von \$K\_S\$ 3. + \item Beide Parteien beweisen ihre Kenntnis von \$K\_S\$ 3. \$A\textbackslash rightarrow B:\{c\_a\textbar\textbar c\_b\}\emph{\{K\_s\} 4. \$B\textbackslash rightarrow A:\{c\_a\}}\{K\_s\}\$ @@ -4289,21 +3218,16 @@ \subsubsection{Sicherheitsdiskussion 2} \begin{itemize*} - \item - Wiederum müssen verschlüsselte Daten von Zufallsdaten ununterscheidbar + \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 + \item Bietet perfektes Vorwärtsgeheimnis + \item Alles in allem ein nettes Verfahren, das jedoch patentiert werden musste - \begin{itemize*} \item Keine breite Anpassung \item Führte zur Entwicklung zahlreicher anderer Verfahren @@ -4314,17 +3238,13 @@ \subsubsection{SRP} \begin{itemize*} - \item - Das heute am weitesten verbreitete Protokoll: Sicheres Fernkennwort + \item Das heute am weitesten verbreitete Protokoll: Sicheres Fernkennwort (SRP) - \item - Mehrere Versionen: Hier SRP-6a {[}Wu02{]} - \item - Initialisierung: - + \item Mehrere Versionen: Hier SRP-6a {[}Wu02{]} + \item Initialisierung: \begin{itemize*} \item Server B wählt eine Zufallszahl \$s\_\{A,B\}\$ - \item berechnet \$x=H(s\_\{A,B\} \textbar\textbar{} Benutzername \textbar\textbar{} Passwort)\$ und \$v=g\^{}x\textbackslash{} mod\textbackslash{} p\$ + \item berechnet \$x=H(s\_\{A,B\} \textbar| Benutzername \textbar| Passwort)\$ und \$v=g\^{}x\textbackslash{} mod\textbackslash{} p\$ \item Benutzer werden durch \$(Benutzername, s\_\{A,B\}, v)\$ authentifiziert \item Der Server braucht das Passwort nicht zu speichern \$\textbackslash rightarrow\$ kann nicht leicht erlangt werden, wenn der Server kompromittiert wird! \item Server kann diese Werte auch nicht verwenden, um sich als Benutzer auf anderen Servern auszugeben @@ -4336,33 +3256,27 @@ \subsubsection{SRP - Dialog} \begin{itemize*} - \item - A initiiert die Verbindung durch Senden seines Benutzernamens - + \item A initiiert die Verbindung durch Senden seines Benutzernamens \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$A\textbackslash rightarrow B: A\$ \end{enumerate*} - \item - B antwortet mit ausgewählten kryptographischen Parametern und einem + \item B antwortet mit ausgewählten kryptographischen Parametern und einem Verifizierer v, der durch einen DH-Austausch ,,geblendet'' ist 2. \$B\textbackslash rightarrow A: p, g, s\_\{A,B\}, (H(g - \textbar\textbar{} p)*v + g\^{}\{rb\})\textbackslash{} + \textbar| p)*v + g\^{}\{rb\})\textbackslash{} mod\textbackslash{} p\$ - \item - A berechnet den gemeinsamen Sitzungsschlüssel durch \$K\_S=(Y\_B-H(g - \textbar\textbar{} p)\emph{g\^{}x)\^{}\{ra+u}x\}\textbackslash{} + \item A berechnet den gemeinsamen Sitzungsschlüssel durch \$K\_S=(Y\_B-H(g + \textbar| p)\emph{g\^{}x)\^{}\{ra+u}x\}\textbackslash{} mod\textbackslash{} p\$, mit \$u=H(Y\_A\textbar\textbar Y\_B)\$, und sendet seinen Teil des DH-Austauschs und eine Bestätigung zurück, dass er \$K\_S\$ kennt 3. \$A\textbackslash rightarrow B:g\^{}\{ra\}\textbackslash{} mod\textbackslash{} p, H(Y\_A,Y\_B,K\_S)\$ - \item - B berechnet \$K\_S'=(Y\_A v\^{}u)\^{}\{rb\}\textbackslash{} + \item B berechnet \$K\_S'=(Y\_A v\^{}u)\^{}\{rb\}\textbackslash{} mod\textbackslash{} p\$ und beweist seine Kenntnis 4. \$B\textbackslash rightarrow A:H(Y\_A, H(Y\_A,Y\_B,K\_S),K\_S')\$ - \item - \$K\_S'\$ und \$K\_S\$ stimmen überein, wenn es keinen + \item \$K\_S'\$ und \$K\_S\$ stimmen überein, wenn es keinen Man-in-the-Middle-Angriff gegeben hat \end{itemize*} @@ -4370,37 +3284,29 @@ \subsubsection{SRP - Diskussion} \begin{itemize*} - \item - Sicheres Schema - + \item Sicheres Schema \begin{itemize*} \item Gegenseitige Authentifizierung zwischen Server und Client \item Erweiterung erhöht die Sicherheit in Client/Server-Szenarien \item Keine Unterstützung für ECC, da es Feldarithmetik erfordert \end{itemize*} - \item - Patentiert, aber frei zu verwenden - \item - Unterstützung für TLS, IPsec, ... + \item Patentiert, aber frei zu verwenden + \item Unterstützung für TLS, IPsec, ... \end{itemize*} \subsection{X.509 - Einführung} \begin{itemize*} - \item - X.509 ist eine internationale Empfehlung der ITU-T und gehört zur + \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 + \item X.509 definiert einen Rahmen für die Bereitstellung von Authentifizierungsdiensten, der Folgendes umfasst: - \begin{itemize*} \item Zertifizierung von öffentlichen Schlüsseln und Handhabung von Zertifikaten: \begin{itemize*} \item Zertifikatsformat \item Zertifikats-Hierarchie \item Zertifikatswiderrufslisten \end{itemize*} @@ -4416,24 +3322,17 @@ % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-x509-certificates.png} \begin{itemize*} - \item - Ein Public-Key-Zertifikat ist eine Art Reisepass, der bescheinigt, + \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 + \item Zertifikate werden von Zertifizierungsstellen (CA) ausgestellt. + \item Wenn alle Nutzer den öffentlichen Schlüssel der CA kennen, kann jeder Nutzer jedes von dieser CA ausgestellte Zertifikat überprüfen. - \item - Zertifikate können die Online-Teilnahme eines TTP verhindern - \item - Die Sicherheit des privaten Schlüssels der CA ist entscheidend für die + \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\$ + \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*} @@ -4447,50 +3346,38 @@ Zertifikatshierarchie} \begin{itemize*} - \item - Betrachten wir nun zwei Benutzer Alice und Bob, die in verschiedenen + \item Betrachten wir nun zwei Benutzer Alice und Bob, die in verschiedenen Ländern leben und sicher kommunizieren wollen: - \begin{itemize*} \item Die Wahrscheinlichkeit ist recht hoch, dass ihre öffentlichen Schlüssel von verschiedenen CAs zertifiziert sind \item Nennen wir die Zertifizierungsstelle von Alice CA und die von Bob CB \item Wenn Alice CB nicht vertraut oder gar kennt, dann ist Bobs Zertifikat \$CB\textless{}\textgreater\$ für sie nutzlos, dasselbe gilt in der anderen Richtung \end{itemize*} - \item - Eine Lösung für dieses Problem ist die Konstruktion von + \item Eine Lösung für dieses Problem ist die Konstruktion von Zertifikatsketten: - \begin{itemize*} \item Stellen Sie sich einmal vor, dass CA und CB einander kennen und einander vertrauen. \begin{itemize*} \item Ein Beispiel aus der realen Welt für dieses Konzept ist das gegenseitige Vertrauen zwischen Ländern hinsichtlich ihrer Passausgabestellen \end{itemize*} \item Wenn CA den öffentlichen Schlüssel von CB mit einem Zertifikat \$CA\textless{}\textgreater\$ und CB den öffentlichen Schlüssel von CA mit einem Zertifikat \$CB\textless{}\textgreater\$ beglaubigt, können A und B ihre Zertifikate anhand einer Zertifikatskette überprüfen: \begin{itemize*} \item Nachdem ihr \$CB\textless{}\textgreater\$ vorgelegt wurde, versucht Alice herauszufinden, ob es ein Zertifikat \$CA\textless{}\textgreater\$ gibt. \item Sie überprüft dann die Kette: \$CA\textless{}\textgreater, CB\textless{}\textgreater\$ \end{itemize*} \end{itemize*} - \item - Zertifikatsketten müssen nicht auf eine Länge von zwei Zertifikaten + \item Zertifikatsketten müssen nicht auf eine Länge von zwei Zertifikaten beschränkt sein: - \begin{itemize*} \item \$CA\textless{}\textgreater, CC\textless{}\textgreater, CD\textless{}\textgreater, CE\textless{}\textgreater, CG\textless{}\$ würde es Alice erlauben, das von CG ausgestellte Zertifikat des Benutzers G zu überprüfen, auch wenn sie nur ihre eigene Zertifizierungsstelle CA kennt und ihr vertraut. \item Tatsächlich wird das Vertrauen von A in den Schlüssel +KG durch eine Vertrauenskette zwischen Zertifizierungsstellen hergestellt. \item Wenn Alice jedoch \$CG\textless{}\textgreater\$ vorgelegt wird, ist es nicht offensichtlich, welche Zertifikate sie zur Überprüfung benötigt \end{itemize*} - \item - X.509 schlägt daher vor, dass die Zertifizierungsstellen in einer + \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: - + \item Verbleibendes Problem: \begin{itemize*} \item Zertifizierungspfade können ziemlich lang werden \item Die Kompromittierung eines einzigen Zwischenzertifikats reicht aus, um die Sicherheit zu brechen \end{itemize*} - \item - Führt zu zwei Entwicklungen - + \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*} @@ -4504,27 +3391,21 @@ Zertifikatssperrung} \begin{itemize*} - \item - Nehmen wir nun an, dass der private Schlüssel von Alice kompromittiert + \item Nehmen wir nun an, dass der private Schlüssel von Alice kompromittiert wurde, z.B. weil Eve in ihren Computer eingebrochen ist, ihren privaten Schlüssel aus einer Datei gelesen und das Passwort geknackt hat, das sie zum Schutz des privaten Schlüssels verwendet hat: - \begin{itemize*} \item Wenn Alice feststellt, dass ihr privater Schlüssel kompromittiert wurde, möchte sie unbedingt den Widerruf des entsprechenden Zertifikats für den öffentlichen Schlüssel beantragen. \item Wenn das Zertifikat nicht widerrufen wird, könnte sich Eve bis zum Ende der Gültigkeitsdauer des Zertifikats weiterhin als Alice ausgeben. \end{itemize*} - \item - Eine noch schlimmere Situation tritt ein, wenn der private Schlüssel + \item Eine noch schlimmere Situation tritt ein, wenn der private Schlüssel einer Zertifizierungsstelle kompromittiert wird: - \begin{itemize*} \item Dies bedeutet, dass alle mit diesem Schlüssel signierten Zertifikate widerrufen werden müssen! \end{itemize*} - \item - Der Widerruf von Zertifikaten wird durch das Führen von + \item Der Widerruf von Zertifikaten wird durch das Führen von Zertifikatswiderrufslisten (CRL) realisiert: - \begin{itemize*} \item CRLs werden im X.500-Verzeichnis gespeichert, oder Erweiterungen können auf eine URL verweisen \item Bei der Überprüfung eines Zertifikats muss auch geprüft werden, ob das Zertifikat noch nicht widerrufen wurde (Suche nach dem Zertifikat in der CRL) @@ -4537,52 +3418,39 @@ 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\}\}\emph{\{+KB\}{]}, CA\textless{}\textgreater)\$, wobei \$sgnData\_A\$ optionale Daten darstellt, die von \$A signiert werden sollen, \{K}\{A,B\}\}\_\{+K\_B\}\$ ein optionaler Sitzungsschlüssel ist, der mit Bobs öffentlichem Schlüssel verschlüsselt wird, und \$CA\textless{}\textgreater\$ ebenfalls optional ist \end{enumerate*} - \begin{itemize*} \item Beim Empfang dieser Nachricht verifiziert Bob mit \$+K\_\{CA\}\$ das enthaltene Zertifikat, extrahiert Alices öffentlichen Schlüssel, überprüft Alices Signatur der Nachricht und die Aktualität der Nachricht \$(t\_A)\$ und entschlüsselt optional den enthaltenen Sitzungsschlüssel \$K\_\{A,B\}\$, den Alice vorgeschlagen hat \end{itemize*} - \item - Zwei-Wege-Authentifizierung: - + \item Zwei-Wege-Authentifizierung: \begin{itemize*} \item Wenn eine gegenseitige Authentifizierung erwünscht ist, dann erstellt Bob eine ähnliche Nachricht: \end{itemize*} - \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \setcounter{enumi}{1} \item \$(B{[}t\_B, r\_B, A, r\_A, sgnData\_B,\{K\_\{B,A\}\}\_\{+K\_A\}{]}, CA\textless{}\textgreater)\$ der enthaltene Zeitstempel \$t\_B\$ ist nicht wirklich erforderlich, da Alice überprüfen kann, ob die signierte Nachricht die Zufallszahl \$r\_A\$ enthält \end{enumerate*} - \item - Drei-Wege-Authentifizierung: - + \item Drei-Wege-Authentifizierung: \begin{itemize*} \item Wenn Alice und Bob nicht sicher sind, ob sie synchrone Uhren haben, sendet Alice die folgende Nachricht an Bob: \end{itemize*} - \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \setcounter{enumi}{2} \item \$A{[}r\_B{]}\$ \end{enumerate*} - \begin{itemize*} \item Die Rechtzeitigkeit der Teilnahme von Alice am Authentifizierungsdialog wird also durch die Unterzeichnung der ,,frischen'' Zufallszahl \$r\_B\$ nachgewiesen. \end{itemize*} - \item - Anmerkung zum Signaturalgorithmus: - + \item Anmerkung zum Signaturalgorithmus: \begin{itemize*} \item Wie aus der Verwendung von Zertifikaten ersichtlich, schlägt X.509 vor, die Authentifizierungsnachrichten mit asymmetrischer Kryptographie zu signieren. \item Das Authentifizierungsprotokoll selbst kann jedoch auch mit symmetrischer Kryptographie eingesetzt werden: @@ -4595,28 +3463,22 @@ Protokollen} \begin{itemize*} - \item - Wie wir am Beispiel des Needham-Schroeder-Protokolls gesehen haben, + \item Wie wir am Beispiel des Needham-Schroeder-Protokolls gesehen haben, ist die Sicherheit eines kryptografischen Protokolls nicht einfach zu beurteilen: - \begin{itemize*} \item Es gibt viele weitere Beispiele für Protokollfehler in kryptografischen Protokollen, die manchmal erst Jahre nach der Veröffentlichung des Protokolls entdeckt wurden \begin{itemize*} \item Eine frühe Version des X.509-Standards enthielt einen Fehler, der dem Fehler im Needham-Schroeder-Protokoll ähnlich war. \end{itemize*} \item Daraus ergibt sich der Bedarf an formalen Methoden zur Analyse der Eigenschaften von kryptographischen Protokollen \end{itemize*} - \item - Kategorien von formalen Validierungsmethoden für kryptografische + \item Kategorien von formalen Validierungsmethoden für kryptografische Protokolle: - \begin{itemize*} \item Allgemeine Ansätze zur Analyse spezifischer Protokolleigenschaften: \begin{itemize*} \item Beispiele: Finite-State-Machine-basierte Ansätze, Prädikatenkalkül erster Ordnung, Allzweck-Spezifikationssprachen \item Hauptnachteil: Sicherheit unterscheidet sich wesentlich von Korrektheit, da für letztere keine böswillige Manipulation angenommen werden muss \end{itemize*} \end{itemize*} - \item - Kategorien von formalen Validierungsmethoden für kryptographische + \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*} @@ -4638,12 +3500,10 @@ \subsection{Was ist Zugangskontrolle?} \begin{itemize*} - \item - Definition: Die Zugriffskontrolle umfasst die Mechanismen, die die + \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 + \item Ein wichtiges konzeptuelles Modell in diesem Zusammenhang ist der Referenzmonitor: %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-reference-monitor.png} \end{itemize*} @@ -4652,16 +3512,12 @@ \subsection{Sicherheitspolitik} \begin{itemize*} - \item - Um Entscheidungen über die Zugriffskontrolle treffen zu können, muss + \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 + \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 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. @@ -4674,31 +3530,23 @@ Zugriffsarten} \begin{itemize*} - \item - Definition: Ein Subjekt ist eine aktive Entität, die eine Anfrage nach + \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 + \item Definition: Ein Objekt ist ein passives Repository, das zur Speicherung von Informationen dient - \item - Die beiden obigen Definitionen stammen aus der klassischen + \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 + \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 + \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 @@ -4709,47 +3557,37 @@ \subsection{Sicherheitskennzeichen} \begin{itemize*} - \item - Definition: Eine Sicherheitsstufe wird als hierarchisches Attribut zu + \item Definition: Eine Sicherheitsstufe wird als hierarchisches Attribut zu Entitäten eines Systems definiert, um deren Sensibilitätsgrad zu kennzeichnen - \begin{itemize*} \item Beispiele: \begin{itemize*} \item Militär: unklassifiziert \textless{} vertraulich \textless{} geheim \textless{} streng geheim \item Kommerziell: öffentlich \textless{} sensibel \textless{} proprietär \textless{} eingeschränkt \end{itemize*} \end{itemize*} - \item - Definition: Eine Sicherheitskategorie ist definiert als eine + \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 + \item Definition: Eine Sicherheitskennzeichnung ist definiert als ein Attribut, das mit Systemeinheiten verbunden ist, um deren hierarchische Sensibilitätsstufe und Sicherheitskategorien zu kennzeichnen. - \begin{itemize*} \item In Form von mathematischen Mengen: \$Labels = Levels \textbackslash times Powerset(Categories)\$ \end{itemize*} - \item - Sicherheitslabels, die die Sicherheitsempfindlichkeit von: - + \item Sicherheitslabels, die die Sicherheitsempfindlichkeit von: \begin{itemize*} \item Subjekte werden Freigaben genannt \item Objekte werden Klassifizierungen genannt \end{itemize*} - \item - Ein wichtiges Konzept für die Spezifikation von Sicherheitspolitiken + \item Ein wichtiges Konzept für die Spezifikation von Sicherheitspolitiken sind binäre Relationen auf der Menge der Kennzeichnungen: - \begin{itemize*} \item Eine binäre Relation auf einer Menge S ist eine Teilmenge des Kreuzprodukts \$S\textbackslash times S\$ \item Beispiel: - \begin{itemize*} \item Dominiert: \$Labels \textbackslash times Labels\$ \item Dominiert \$=\{(b1,b2) \textbar{} b1, b2 \textbackslash in Labels \textbackslash wedge level(b1) \textbackslash geq level(b2) \textbackslash wedge categories(b2) \textbackslash subseteq categories(b1)\}\$ \item Wenn \$(b1, b2) \textbackslash in Dominates\$, schreiben wir auch b1 dominates b \end{itemize*} + \begin{itemize*} \item Dominiert: \$Labels \textbackslash times Labels\$ \item Dominiert \$=\{(b1,b2) | b1, b2 \textbackslash in Labels \textbackslash wedge level(b1) \textbackslash geq level(b2) \textbackslash wedge categories(b2) \textbackslash subseteq categories(b1)\}\$ \item Wenn \$(b1, b2) \textbackslash in Dominates\$, schreiben wir auch b1 dominates b \end{itemize*} \end{itemize*} \end{itemize*} @@ -4758,28 +3596,22 @@ Sicherheitspolitik} \begin{itemize*} - \item - Formale Ausdrücke für Regeln der Sicherheitspolitik: - \item - Betrachten Sie die folgenden Zuordnungen: - + \item Formale Ausdrücke für Regeln der Sicherheitspolitik: + \item Betrachten Sie die folgenden Zuordnungen: \begin{itemize*} \item \$allow: Subjects \textbackslash times Accesses \textbackslash times Objects \textbackslash rightarrow boolean\$ \item \$own: Subjects \textbackslash times Objects \textbackslash rightarrow boolean\$ \item \$admin: Subjects \textbackslash rightarrow boolean\$ \item \$dominates: Labels \textbackslash times Labels \textbackslash rightarrow boolean\$ \end{itemize*} - \item - Die oben genannten Zuordnungen können verwendet werden, um bekannte + \item Die oben genannten Zuordnungen können verwendet werden, um bekannte Sicherheitsrichtlinien zu spezifizieren: - \begin{itemize*} \item \$ownership: \textbackslash forall s \textbackslash in Subjects, o \textbackslash in Objects, a \textbackslash in Accesses: allow(s, o, a) \textbackslash Leftrightarrow own(s, o)\$ \item \$own\_admin: \textbackslash forall s \textbackslash in Subjects, o \textbackslash in Objects, a \textbackslash in Accesses: allow(s, o, a) \textbackslash Leftrightarrow own(s, o) \textbackslash wedge admin(s)\$ \item \$dom: \textbackslash forall s \textbackslash in Subjects, o \textbackslash in Objects, a \textbackslash in Accesses: allow(s, o, a) \textbackslash Leftrightarrow dominates(label(s), label(o))\$ \end{itemize*} - \item - Die dom-Policy erfordert ein System zur Speicherung und Verarbeitung + \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 @@ -4790,22 +3622,17 @@ Zugriffskontrollmechanismen} \begin{itemize*} - \item - Ein Zugriffskontrollmechanismus ist eine konkrete Umsetzung des + \item Ein Zugriffskontrollmechanismus ist eine konkrete Umsetzung des Referenzmonitor-Konzepts - \item - Es gibt zwei Haupttypen von Zugriffskontrollmechanismen: - + \item Es gibt zwei Haupttypen von Zugriffskontrollmechanismen: \begin{itemize*} \item Diskretionäre Zugriffskontrolle umfasst diejenigen Verfahren und Mechanismen, die die spezifizierte Vermittlung nach dem Ermessen der einzelnen Benutzer durchsetzen \begin{itemize*} \item Beispiel: Das Unix-Betriebssystem ermöglicht es den Benutzern, die Zugriffsrechte für Dateien, die ihnen gehören, zu erteilen oder zu entziehen (Lesen, Schreiben, Ausführen). \end{itemize*} \item Die obligatorische Zugriffskontrolle umfasst die Verfahren und Mechanismen, die die angegebene Vermittlung nach dem Ermessen einer zentralen Systemverwaltung durchsetzen. \end{itemize*} - \item - Beide Arten können kombiniert werden, wobei die obligatorischen + \item Beide Arten können kombiniert werden, wobei die obligatorischen Zugriffskontrollentscheidungen in den meisten Fällen Vorrang vor den diskretionären Entscheidungen haben - \begin{itemize*} \item Beispiel: \begin{itemize*} \item Verwendung einer diskretionären Zugangskontrolle auf Personalcomputern kombiniert mit einer obligatorischen Zugangskontrolle für die Kommunikation (\$\textbackslash rightarrow\$ Firewalls) \end{itemize*} @@ -4816,10 +3643,8 @@ \subsection{Zugriffsmatrizen} \begin{itemize*} - \item - Ein nützliches Konzept für die Beschreibung von + \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 @@ -4843,29 +3668,22 @@ 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 - \$\textbackslash rightarrow\$ Die Datenintegrität von + \item \$\textbackslash rightarrow\$ Die Datenintegrität von Zugriffskontrolldatenstrukturen ist entscheidend! \end{itemize*} @@ -4878,16 +3696,13 @@ tun?} \begin{itemize*} - \item - Analog zur Methodik der Sicherheitsanalyse gibt es zwei Dimensionen, + \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 + \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 + \item Dimension 2: Welcher Sicherheitsdienst sollte in welcher Schicht realisiert werden? % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Security-service-dim-2.png} \end{itemize*} @@ -4898,37 +3713,27 @@ \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Sicheres-Netz-Modell.png} - \item - Anwendung: - + \item Anwendung: \begin{itemize*} \item Ein Stück Software, das eine bestimmte Aufgabe erfüllt, z. B. elektronische E-Mail, Webdienst, Textverarbeitung, Datenspeicherung usw. \end{itemize*} - \item - Endsystem: - + \item Endsystem: \begin{itemize*} \item Ein Gerät, das vom Personal Computer über den Server bis zum Großrechner reicht. \item Für Sicherheitszwecke hat ein Endsystem in der Regel eine einzige Richtlinienautorität. \end{itemize*} - \item - Teilnetz: - + \item Teilnetz: \begin{itemize*} \item Eine Sammlung von Kommunikationseinrichtungen, die unter der Kontrolle einer Verwaltungsorganisation stehen, z. B. ein LAN, ein Campusnetz, ein WAN usw. \item Für Sicherheitszwecke hat ein Teilnetz in der Regel eine Richtlinienkompetenz. \end{itemize*} - \item - Internet: - + \item Internet: \begin{itemize*} \item Eine Sammlung von miteinander verbundenen Teilnetzen \item Im Allgemeinen haben die Teilnetze, die in einem Inter-Netzwerk verbunden sind, unterschiedliche Richtlinienautoritäten \end{itemize*} - \item - Es gibt vier Ebenen, auf denen unterschiedliche Anforderungen an + \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*} @@ -4946,11 +3751,9 @@ Anforderungsniveaus} \begin{itemize*} - \item - Die Beziehungen zwischen den Protokollschichten und den Stufen der + \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. @@ -4963,40 +3766,30 @@ Platzierung} \begin{itemize*} - \item - Verkehrsvermischung: - + \item Verkehrsvermischung: \begin{itemize*} \item Infolge des Multiplexing besteht auf niedrigeren Ebenen eine größere Tendenz, Datenelemente von verschiedenen Quell-/Ziel-Benutzern und/oder Anwendungen in einem Datenstrom zu vermischen \item Ein Sicherheitsdienst, der auf einer Schicht/Ebene realisiert wird, behandelt den Verkehr dieser Schicht/Ebene gleich, was zu einer unzureichenden Kontrolle der Sicherheitsmechanismen für Benutzer und Anwendungen führt. \item Wenn eine Sicherheitspolitik eine differenziertere Behandlung erfordert, sollte sie besser auf einer höheren Ebene realisiert werden \end{itemize*} - \item - Wissen über die Route: - + \item Wissen über die Route: \begin{itemize*} \item Auf niedrigeren Ebenen ist in der Regel mehr Wissen über die Sicherheitseigenschaften der verschiedenen Routen und Verbindungen vorhanden. \item In Umgebungen, in denen diese Merkmale stark variieren, kann die Platzierung von Sicherheit auf niedrigeren Ebenen Vorteile in Bezug auf Effektivität und Effizienz haben \item Geeignete Sicherheitsdienste können auf der Basis von Teilnetzen oder Verbindungen ausgewählt werden, so dass keine Kosten für Sicherheit anfallen, wenn der Schutz unnötig ist. \end{itemize*} - \item - Anzahl der Schutzpunkte: - + \item Anzahl der Schutzpunkte: \begin{itemize*} \item Wenn die Sicherheit auf der Anwendungsebene angesiedelt wird, muss die Sicherheit in jeder sensiblen Anwendung und jedem Endsystem implementiert werden. \item Sicherheit auf der Verbindungsebene bedeutet, dass am Ende jeder Netzverbindung, die als weniger vertrauenswürdig gilt, Sicherheit implementiert werden muss. \item Wenn die Sicherheit in der Mitte der Architektur angesiedelt wird, müssen die Sicherheitsmerkmale an weniger Stellen installiert werden. \end{itemize*} - \item - Schutz der Protokoll-Header: - + \item Schutz der Protokoll-Header: \begin{itemize*} \item Der Sicherheitsschutz auf höheren Ebenen kann die Protokollköpfe der unteren Protokollschichten nicht schützen. \item Die Netzwerkinfrastruktur muss möglicherweise ebenfalls geschützt werden. \end{itemize*} - \item - Quelle/Senke-Bindung: - + \item Quelle/Senke-Bindung: \begin{itemize*} \item Sicherheitsdienste wie die Authentifizierung der Datenherkunft und die Unleugbarkeit hängen von der Zuordnung der Daten zu ihrer Quelle oder Senke ab. \item Dies wird am effizientesten auf höheren Ebenen erreicht, insbesondere auf der Anwendungsebene. @@ -5008,33 +3801,25 @@ Ebenen} \begin{itemize*} - \item - Anwendungsebene: - + \item Anwendungsebene: \begin{itemize*} \item Diese Stufe kann die einzige geeignete Stufe sein, zum Beispiel weil: \begin{itemize*} \item Ein Sicherheitsdienst ist anwendungsspezifisch, z.B. die Zugriffskontrolle für einen vernetzten Dateispeicher \item Ein Sicherheitsdienst muss Anwendungs-Gateways durchqueren, z.B. Integrität und/oder Vertraulichkeit von elektronischer Post \item Die Semantik der Daten ist wichtig, z.B. für Nichtabstreitbarkeitsdienste - Es liegt außerhalb der Reichweite eines Benutzers/Anwendungsprogrammierers, Sicherheit auf einer niedrigeren Ebene zu integrieren \end{itemize*} \end{itemize*} - \item - Endsystem-Ebene: - + \item Endsystem-Ebene: \begin{itemize*} \item Diese Ebene ist geeignet, wenn davon ausgegangen wird, dass die Endsysteme vertrauenswürdig sind und das Kommunikationsnetz als nicht vertrauenswürdig angesehen wird. \item Weitere Vorteile der Sicherheit auf Endsystemebene: \begin{itemize*} \item Die Sicherheitsdienste sind für die Anwendungen transparent. \item Die Verwaltung von Sicherheitsdiensten kann leichter in die Hände eines Systemadministrators gelegt werden. \end{itemize*} \end{itemize*} - \item - Teilnetzebene: - + \item Teilnetzebene: \begin{itemize*} \item Auch wenn die auf dieser Ebene implementierte Sicherheit in der gleichen Protokollschicht wie auf der Endsystemebene implementiert werden kann, sollten diese nicht verwechselt werden: \begin{itemize*} \item Mit der auf der Subnetzebene implementierten Sicherheit wird in der Regel der gleiche Schutz für alle Endsysteme dieses Subnetzes realisiert \end{itemize*} \item Es ist sehr üblich, dass ein Teilnetz in der Nähe eines Endsystems als ebenso vertrauenswürdig angesehen wird, da es sich in denselben Räumlichkeiten befindet und von denselben Behörden verwaltet wird. \item In den meisten Fällen gibt es weit weniger zu sichernde Teilnetz-Gateways als Endsysteme. \end{itemize*} - \item - Verbindungsebene: - + \item Verbindungsebene: \begin{itemize*} \item Wenn es relativ wenige nicht vertrauenswürdige Verbindungen gibt, kann es ausreichend und zudem einfacher und kostengünstiger sein, das Netz auf der Verbindungsebene zu schützen. \item Darüber hinaus können auf der Verbindungsebene spezielle Schutztechniken eingesetzt werden, z. B. Spreizspektrum oder Frequenzsprungverfahren. @@ -5047,18 +3832,14 @@ Nutzern} \begin{itemize*} - \item - Einige Netzsicherheitsdienste beinhalten eine direkte Interaktion mit + \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 + \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 + \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*} @@ -5074,10 +3855,8 @@ Anwendungen} \begin{itemize*} - \item - Vorteile der Integration von Sicherheitsdiensten in niedrigere + \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*} @@ -5095,22 +3874,17 @@ Zwischensysteme} \begin{itemize*} - \item - Integration in Endsysteme: - + \item Integration in Endsysteme: \begin{itemize*} \item Kann im Allgemeinen entweder auf der Anwendungs- oder der Endsystemebene erfolgen \item In einigen speziellen Fällen kann auch ein Schutz auf Verbindungsebene angebracht sein, z. B. bei der Verwendung eines Modems zur Verbindung mit einem bestimmten Gerät \end{itemize*} - \item - Integration in Zwischensysteme - + \item Integration in Zwischensysteme \begin{itemize*} \item Kann auf allen vier Ebenen erfolgen: \begin{itemize*} \item Anwendungs-/,,Endsystem"-Ebene: zur Sicherung der Verwaltungsschnittstellen von Zwischenknoten, nicht zur Sicherung des Nutzdatenverkehrs \item Teilnetz-/Link-Ebene: zur Sicherung des Nutzdatenverkehrs \end{itemize*} \end{itemize*} - \item - Je nach den Sicherheitszielen kann eine Integration sowohl in + \item Je nach den Sicherheitszielen kann eine Integration sowohl in Endsystemen als auch in Zwischensystemen sinnvoll sein \end{itemize*} @@ -5138,28 +3912,22 @@ \subsection{Schlussfolgerung} \begin{itemize*} - \item - Die Integration von Sicherheitsdiensten in Kommunikationsarchitekturen + \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 + \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 + \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 + \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*} @@ -5169,16 +3937,11 @@ Datenübertragungsschicht} \begin{itemize*} - \item - IEEE 802.1Q, IEEE 802.1X \& IEEE 802.1AE - \item - Point-to-Point Protocol (PPP) - \item - Point-to-Point Tunneling Protocol (PPTP) - \item - Layer 2 Tunneling Protocol (L2TP) - \item - Virtual Private Networks (VPN) + \item IEEE 802.1Q, IEEE 802.1X \& IEEE 802.1AE + \item Point-to-Point Protocol (PPP) + \item Point-to-Point Tunneling Protocol (PPTP) + \item Layer 2 Tunneling Protocol (L2TP) + \item Virtual Private Networks (VPN) \end{itemize*} @@ -5186,28 +3949,21 @@ Verbindungsschicht} \begin{itemize*} - \item - Nach dem klassischen Verständnis des OSI-Modells stellt die + \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: - + \item Ihre Hauptaufgaben sind: \begin{itemize*} \item Fehlererkennung und -korrektur \item Medium Access Control (MAC, nicht zu verwechseln mit Message Authentication Code) für gemeinsam genutzte Medien, z. B. Ethernet usw. \end{itemize*} - \item - Nicht alle heutigen Netzwerktechnologien passen in dieses Modell: - + \item Nicht alle heutigen Netzwerktechnologien passen in dieses Modell: \begin{itemize*} \item Einwahlverbindungen zu einem Internetdienstanbieter \item Lösungen für virtuelle private Netzwerke (VPN) \end{itemize*} - \item - In diesem Kurs geben wir uns mit der folgenden Definition zufrieden: - + \item In diesem Kurs geben wir uns mit der folgenden Definition zufrieden: \begin{itemize*} \item Der Zweck eines Link-Layer-Sicherheitsprotokolls besteht darin, bestimmte Sicherheitseigenschaften der Link-Layer-PDUs zu gewährleisten, d. h. der PDUs der Protokollschicht, die die PDUs der Netzwerkschicht (z. B. IP) tragen. \end{itemize*} @@ -5221,21 +3977,16 @@ Ziele} \begin{itemize*} - \item - Das Institute of Electrical and Electronics Engineers (IEEE) 802 + \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: - + \item Die am weitesten verbreiteten Standards sind: \begin{itemize*} \item Ethernet-Familie (802.3, allgemein als CSMA/CD bezeichnet), \item Drahtloses LAN (802.11) \item WIMAX (802.16) \end{itemize*} - \item - Die IEEE 802.1-Standards: - + \item Die IEEE 802.1-Standards: \begin{itemize*} \item Können mit verschiedenen IEEE 802.x Technologien verwendet werden \item Definieren unter anderem verschiedene explizite Sicherheitsdienste oder Dienste, die zur Erreichung von Sicherheitszielen verwendet werden können @@ -5248,9 +3999,7 @@ Ziele und Dienste \begin{itemize*} - \item - Der Standard IEEE 802.1Q: - + \item Der Standard IEEE 802.1Q: \begin{itemize*} \item Ermöglicht die Schaffung von ,,miteinander verbundenen IEEE-802-Standard-LANs mit unterschiedlichen oder identischen Methoden der Medienzugriffskontrolle'', d. h. die Schaffung separater virtueller lokaler Netzwerke (VLANs) über eine physische Infrastruktur \item Obwohl es sich nicht um einen echten Sicherheitsstandard handelt, wird er häufig verwendet, um verschiedene Benutzer und Dienste voneinander zu trennen, z. B. nicht vertrauenswürdige Gastcomputer von Unternehmensservern, ohne eine neue Infrastruktur einzurichten @@ -5261,17 +4010,13 @@ Grundlegende Funktionsweise \begin{itemize*} - \item - Jedes Netzwerkpaket wird mit einem VLAN-Tag versehen, der eine + \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 + \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! - + \item Die VLAN-ID ist nicht kryptografisch geschützt! \begin{itemize*} \item VLAN IDs müssen auf andere Weise, d.h. physikalisch, gesichert werden! \item Normalerweise werden VLAN-IDs am ersten vertrauenswürdigen Switch eingefügt und am letzten vertrauenswürdigen Switch auf dem Weg durch das Netzwerk entfernt @@ -5281,17 +4026,12 @@ Typisches Einführungsszenario \begin{itemize*} - \item - Normalerweise wird das vertrauenswürdige innere Netzwerk durch + \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 + \item Verschiedene Ports zum vertrauenswürdigen Kern werden VLANs zugeordnet + \item VLANs sind virtuell verbunden, dürfen aber nicht auf andere VLANs zugreifen - \item - VLANs werden normalerweise gekoppelt durch - + \item VLANs werden normalerweise gekoppelt durch \begin{itemize*} \item Router, die mehrere Schnittstellen in den verschiedenen VLANs haben \item Router, die selbst zum vertrauenswürdigen Netzwerk gehören und selbst getaggte Frames empfangen und senden können (kann gefährlich sein, Wechselwirkung zwischen Routing und VLANs, siehe unten) @@ -5302,17 +4042,13 @@ Weitere Diskussion \begin{itemize*} - \item - 802.1Q ermöglicht eine einfache Trennung verschiedener + \item 802.1Q ermöglicht eine einfache Trennung verschiedener Sicherheitsdomänen innerhalb eines vertrauenswürdigen Netzwerks - \begin{itemize*} \item Ermöglicht auch die Priorisierung bestimmter VLANs (z. B. um die Verwaltung von Geräten zu ermöglichen, wenn der Rest des Netzes von einem Angreifer überflutet wird) \item VLAN-Tags können gestapelt werden, z. B. um verschiedene Kunden zu trennen, die eigene VLANs einrichten \end{itemize*} - \item - Diskussion über die Sicherheit: - + \item Diskussion über die Sicherheit: \begin{itemize*} \item Die Sicherheit hängt davon ab, dass kein einziges Gerät in der vertrauenswürdigen Domäne kompromittiert wird! \item Alle Switches müssen korrekt konfiguriert sein, d.h. kein einziger Switch darf eingehenden Verkehr aus einem nicht vertrauenswürdigen Netz zulassen, der bereits getaggt ist @@ -5329,14 +4065,11 @@ Ziele \begin{itemize*} - \item - Der Standard IEEE 802.1X: - + \item Der Standard IEEE 802.1X: \begin{itemize*} \item Ziel ist es, ,,den Zugang zu den von einem LAN angebotenen Diensten auf diejenigen Benutzer und Geräte zu beschränken, die diese Dienste nutzen dürfen'' \end{itemize*} - \item - Definiert eine portbasierte Netzwerkzugriffskontrolle, um ein Mittel + \item Definiert eine portbasierte Netzwerkzugriffskontrolle, um ein Mittel zur ,,Authentifizierung und Autorisierung von Geräten bereitzustellen, die an einen LAN-Port mit Punkt-zu-Punkt-Verbindungseigenschaften angeschlossen sind''. @@ -5345,9 +4078,7 @@ Kontrollierte und unkontrollierte Ports \begin{itemize*} - \item - IEEE 802.1X führt den Begriff der zwei logischen Ports ein: - + \item IEEE 802.1X führt den Begriff der zwei logischen Ports ein: \begin{itemize*} \item Der unkontrollierte Port ermöglicht die Authentifizierung eines Geräts \item Der kontrollierte Port ermöglicht es einem authentifizierten Gerät, auf LAN-Dienste zuzugreifen @@ -5358,17 +4089,13 @@ Rollen \begin{itemize*} - \item - Es werden drei Hauptrollen unterschieden: - + \item Es werden drei Hauptrollen unterschieden: \begin{itemize*} \item Ein Gerät, das den von einem IEEE 802.1X LAN angebotenen Dienst nutzen möchte, agiert als Supplicant, der den Zugriff auf den kontrollierten Port anfordert \item Der Anschlusspunkt an die LAN-Infrastruktur (z. B. eine MAC-Brücke) fungiert als Authentifikator, der den Supplicant auffordert, sich zu authentifizieren. \item Der Authentifikator prüft die vom Antragsteller vorgelegten Anmeldeinformationen nicht selbst, sondern leitet sie zur Überprüfung an seinen Authentifizierungsserver weiter. \end{itemize*} - \item - Zugriff auf ein LAN mit IEEE 802.1X Sicherheitsmaßnahmen: - + \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*} @@ -5380,19 +4107,15 @@ Sicherheitsprotokolle und Nachrichtenaustausch \begin{itemize*} - \item - IEEE 802.1X definiert keine eigenen Sicherheitsprotokolle, sondern + \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 + \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, ... @@ -5409,10 +4132,8 @@ Ziele \begin{itemize*} - \item - Der Standard IEEE 802.1AE wird auch als MAC-Sicherheit (MACsec) + \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 @@ -5427,19 +4148,14 @@ \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ieee802.1AE-frame.png} - \item - Quell- und Zieladressen werden im Klartext gesendet - \item - VLAN-Tag, Typfeld und Nutzdaten werden ebenfalls verschlüsselt - \item - Ein neuer 8-16 Byte langer SecTAG wird eingefügt - + \item Quell- und Zieladressen werden im Klartext gesendet + \item VLAN-Tag, Typfeld und Nutzdaten werden ebenfalls verschlüsselt + \item Ein neuer 8-16 Byte langer SecTAG wird eingefügt \begin{itemize*} \item Beginnt mit 0x88e5, um ein Protokoll für ältere Geräte zu emulieren \item Enthält einen 4-Byte-Paketzähler (wird als IV verwendet, auch um Replay-Angriffe abzuwehren) \end{itemize*} - \item - FCS wird durch einen kryptografischen MAC von 8-16 Byte ersetzt und + \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*} @@ -5447,12 +4163,9 @@ Diskussion über Sicherheit \begin{itemize*} - \item - MACsec erlaubt es, Verbindungen zu sichern, z.B. zwischen Gebäuden auf + \item MACsec erlaubt es, Verbindungen zu sichern, z.B. zwischen Gebäuden auf einem Campus - \item - Es bietet keinen Schutz gegen kompromittierte Geräte! - + \item Es bietet keinen Schutz gegen kompromittierte Geräte! \begin{itemize*} \item Wenn es in Kombination mit 802.1Q verwendet wird, kann die vertrauenswürdige Computerbasis immer noch ziemlich groß sein... \item Die Verwendung des GCM unterliegt den in Kapitel 5 beschriebenen potenziellen Problemen @@ -5466,24 +4179,18 @@ Zweck und Aufgaben \begin{itemize*} - \item - Große Teile des Internets beruhen auf Punkt-zu-Punkt-Verbindungen: - + \item Große Teile des Internets beruhen auf Punkt-zu-Punkt-Verbindungen: \begin{itemize*} \item Wide Area Network (WAN)-Verbindungen zwischen Routern \item Einwahlverbindungen von Hosts über Modems und Telefonleitungen \end{itemize*} - \item - Protokolle für diesen Zweck: - + \item Protokolle für diesen Zweck: \begin{itemize*} \item Serial Line IP (SLIP): keine Fehlererkennung, unterstützt nur IP, keine dynamische Adressvergabe, keine Authentifizierung {[}RFC 1055{]} \item Point-to-Point Protocol (PPP): Nachfolger von SLIP, unterstützt IP, IPX, ... % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Point-to-Point.png} \end{itemize*} - \item - PPP {[}RFC 1661/1662{]} - + \item PPP {[}RFC 1661/1662{]} \begin{itemize*} \item Schicht-2-Rahmenformat mit Rahmenbegrenzung und Fehlererkennung \item Kontrollprotokoll (Link Control Protocol, LCP) für Verbindungsaufbau, -test, -aushandlung und -abbau @@ -5494,33 +4201,25 @@ Packet Format \begin{itemize*} - \item - Zeichenorientierte (statt bitorientierte) + \item Zeichenorientierte (statt bitorientierte) \$\textbackslash Rightarrow\$ byteausgerichtete Rahmen - \item - Code-Transparenz wird durch Zeichenstuffing erreicht - \item - Normalerweise werden nur unnummerierte Frames übertragen, in Szenarien + \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, + \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 + \item Wenn nicht anders ausgehandelt, beträgt die maximale Nutzdatengröße 1500 Byte. - \item - Zusätzliche Aushandlung unterstützt kleinere Paketköpfe + \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'': - + \item Nutzungsszenario ,,Internetzugang eines PCs über Modem'': \begin{itemize*} \item Der Benutzer ruft den Internet Service Provider (ISP) über ein Modem an und stellt eine ,,physikalische'' Verbindung über den ,,Plain Old Telephone Service'' (POTS) her. \item Anrufer sendet mehrere LCP-Pakete in PPP-Frames, um die gewünschten PPP-Parameter auszuwählen @@ -5536,19 +4235,15 @@ Link Control Protocol \begin{itemize*} - \item - Rahmenformat des Link Control Protocol (LCP): - + \item Rahmenformat des Link Control Protocol (LCP): \begin{itemize*} \item Code: configure-request, configure-ack, configure-nack, configure-reject, terminate-request, terminate-ack, code-reject, protocol-reject, echo-request, echo-reply, discard-request \item Länge: gibt die Länge des LCP-Pakets einschließlich des Codefelds usw. an \item Daten: null oder mehr Oktette befehlsspezifischer Daten % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Point-to-Point-LCP.png} \end{itemize*} - \item - Die Konfigurationsprimitive von LCP ermöglichen die Konfiguration der + \item Die Konfigurationsprimitive von LCP ermöglichen die Konfiguration der Verbindungsschicht: - \begin{itemize*} \item Es gibt verschiedene Optionen für dieses Primitiv zur Konfiguration verschiedener Aspekte (max. Empfangseinheit, Protokollkompression, Authentifizierung, ...) \end{itemize*} @@ -5557,11 +4252,9 @@ Sicherheitsdienste \begin{itemize*} - \item - Die ursprüngliche Version von PPP {[}RFC 1661{]} schlägt die optionale + \item Die ursprüngliche Version von PPP {[}RFC 1661{]} schlägt die optionale Ausführung eines Authentifizierungsprotokolls nach der Verbindungsaufbauphase vor: - \begin{itemize*} \item Falls erforderlich, wird die Authentifizierung von einer Peer-Entität über einen LCP Configuration-Request am Ende der Verbindungsaufbauphase gefordert \item Ursprünglich sind zwei Authentifizierungsprotokolle definiert worden: @@ -5569,10 +4262,8 @@ \item Inzwischen ist ein erweiterbares Protokoll definiert worden: \begin{itemize*} \item Erweiterbares Authentifizierungsprotokoll (EAP) \item PPP EAP Transport Level Security Protocol (PPP-EAP-TLS) \end{itemize*} \end{itemize*} - \item - Außerdem kann nach der Authentifizierung eine Verschlüsselung + \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*} @@ -5582,9 +4273,7 @@ Authentifizierungsprotokolle \begin{itemize*} - \item - Passwort-Authentifizierungs-Protokoll (PAP): - + \item Passwort-Authentifizierungs-Protokoll (PAP): \begin{itemize*} \item PAP wurde 1992 in RFC 1334 definiert. \item Das Protokoll ist sehr einfach: @@ -5592,17 +4281,13 @@ \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): - + \item Challenge Handshake Authentication Protocol (CHAP): \begin{itemize*} \item CHAP ist ebenfalls in RFC 1334 und RFC 1994 definiert. \item Es verwirklicht ein einfaches Challenge-Response-Protokoll: \begin{itemize*} \item Voraussetzung: Authentifikator und Peer-Entität teilen ein Geheimnis \item Nach der Verbindungsaufbauphase sendet der Authentifikator (A) eine Challenge-Nachricht, die einen Identifikator für diese Challenge, eine Zufallszahl \$r\_A\$ und seinen Namen enthält, an die Peer-Entität (B): \$A \textbackslash rightarrow B: (1, Identifikator, r\_A, A)\$ \item Die Peer-Entität berechnet eine kryptografische Hash-Funktion über ihren Namen, das gemeinsame Geheimnis \$K\_\{A,B\}\$ und die Zufallszahl \$r\_A\$ und sendet die folgende Nachricht: \$B \textbackslash rightarrow A: (2, Kennung, H(B, K\_\{A,B\}, r\_A), B)\$ \item Beim Empfang dieser Nachricht berechnet der Authentifikator den Hashwert neu und vergleicht ihn mit dem empfangenen Wert; wenn beide Werte übereinstimmen, antwortet er mit einer Erfolgsmeldung \item RFC 1994 legt fest, dass MD5 als Hash-Funktion unterstützt werden muss, aber die Verwendung anderer Hash-Funktionen kann ausgehandelt werden \end{itemize*} \end{itemize*} - \item - CHAP-Nachrichtenformat: - + \item CHAP-Nachrichtenformat: \begin{itemize*} \item Code: 1 \textasciitilde{} Herausforderung / 2 \textasciitilde{} Antwort / 3 \textasciitilde{} Erfolg / 4 \textasciitilde{} Fehler \item Identifier: ein Oktett, das bei jeder gesendeten Challenge geändert werden muss @@ -5615,9 +4300,7 @@ \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): - + \item Erweiterbares Authentifizierungsprotokoll (EAP): \begin{itemize*} \item EAP ist ein allgemeines Protokoll für die PPP-Authentifizierung, das mehrere Authentifizierungsmethoden unterstützt {[}RFC2284{]}. \item Die Hauptidee hinter EAP ist es, ein gemeinsames Protokoll bereitzustellen, um komplexere Authentifizierungsmethoden als ,,1 Frage + 1 Antwort'' durchzuführen. @@ -5626,9 +4309,7 @@ \item Typ-Felder: \begin{itemize*} \item Identität \item Benachrichtigung \item Nak (nur Antwort, zur Beantwortung inakzeptabler Anfragetypen) \item MD5 Challenge (dies entspricht CHAP) \item One-Time Password (OTP): definiert in {[}RFC2289{]} \item Generische Token-Karte \item EAP-TLS \end{itemize*} \end{itemize*} - \item - Einmaliges Kennwort (One-Time Password, OTP): - + \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: @@ -5637,17 +4318,13 @@ \begin{itemize*} \item \$A\textbackslash rightarrow B: N - 1\$ \item \$B\textbackslash rightarrow A: PW\_\{N-1\} := H\^{}\{N-1\}(r\_A, Passwort\_B)\$ \item A prüft, ob \$H(PW\_\{N-1\}) = PW\_N\$, und speichert \$(N-1, PW\_\{N-1\})\$ als neue Authentifizierungsinformation für B \end{itemize*} \item Sicherheit: Um dieses Verfahren zu brechen, müsste ein Angreifer ein PWN abhören und \$H\^{}\{-1\}(PW\_N)\$ berechnen, was unpraktisch ist. \end{itemize*} - \item - Generische Token-Karte: - + \item Generische Token-Karte: \begin{itemize*} \item Im Grunde ein Challenge-Response-Dialog \item Eine Token-Karte wird verwendet, um eine Antwort auf eine Herausforderung zu berechnen: \begin{itemize*} \item Die Herausforderung wird dem Benutzer präsentiert, der sie in sein Token-Card-Gerät eintippen muss. \item Die Token-Karte berechnet die Antwort und zeigt sie an. \item Der Benutzer gibt die Antwort in das System ein, das sie als Antwort auf die Aufforderungsnachricht sendet. \end{itemize*} \end{itemize*} - \item - PPP-EAP-TLS: - + \item PPP-EAP-TLS: \begin{itemize*} \item TLS steht für Transport Layer Security {[}RFC 2246{]}. \item Es wird also der Authentifizierungsdialog von TLS ausgeführt @@ -5658,27 +4335,21 @@ Verschlüsselungsprotokolle \begin{itemize*} - \item - Nach dem Verbindungsaufbau und der Authentifizierungsphase kann die + \item Nach dem Verbindungsaufbau und der Authentifizierungsphase kann die Verschlüsselung für eine PPP-Verbindung ausgehandelt werden: - \begin{itemize*} \item Das Encryption Control Protocol (ECP) {[}RFC1968{]} ist für die Konfiguration und Aktivierung von Datenverschlüsselungsalgorithmen an beiden Enden der PPP-Verbindung zuständig: \begin{itemize*} \item ECP verwendet das gleiche Rahmenformat wie LCP und führt zwei neue Primitive ein: Reset-Request und Reset-Ack zur Anzeige von Entschlüsselungsfehlern unabhängig für jede Richtung (nützlich für die kryptographische Resynchronisation) \item Eine bestimmte Verschlüsselungsmethode wird mit dem configure-Primitiv ausgehandelt, das eine Option zur Angabe von DESE, 3DESE, Proprietär usw. enthält. \item Proprietäre Verschlüsselungsprotokolle werden durch einen registrierten OUI (Organizational Unit Identifier) + einen herstellerspezifischen Wert identifiziert. \item Genau ein ECP-Paket wird im PPP-Informationsfeld eines Link-Layer-Pakets transportiert \item ECP-Pakete werden durch das PPP-Protokollfeld identifiziert: \begin{itemize*} \item 0x8053 für ,,Standard'' Betrieb \item 0x8055 für die Verschlüsselung einzelner Verbindungsdaten auf mehreren Verbindungen zum selben Ziel \end{itemize*} \end{itemize*} \end{itemize*} - \item - Das PPP DES Encryption Protocol (DESE): - + \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*} \end{itemize*} - \item - PPP DESE v2 Nachrichtenformat: - + \item PPP DESE v2 Nachrichtenformat: \begin{itemize*} \item Adresse: 0x11111111 (bei HDLC-ähnlichem Framing) \item Steuerung: 0x00000011 (bei HDLC-ähnlicher Rahmung) @@ -5688,19 +4359,15 @@ \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): - + \item PPP 3DES Encryption Protocol (3DESE): \begin{itemize*} \item PPP 3DESE {[}RFC2420{]} ist dem PPP DESE sehr ähnlich \item PPP 3DESE wird mit einer Configure-Request-Nachricht ausgehandelt, wobei das Type-Feld der Option auf 2 gesetzt ist (\textasciitilde{} 3DESE) \item Die Verschlüsselung der PPP-Nutzdaten erfolgt wie bei DESE, mit dem Unterschied, dass 3DES mit 3 verschiedenen Schlüsseln verwendet wird \end{itemize*} - \item - Alle PPP-Verschlüsselungsprotokolle gehen davon aus, dass vor der + \item Alle PPP-Verschlüsselungsprotokolle gehen davon aus, dass vor der Verschlüsselungsphase ein Sitzungsschlüssel für die Verschlüsselung/Entschlüsselung von PPP-Paketen vereinbart wurde: - \begin{itemize*} \item Diese Annahme ist sinnvoll, da die Festlegung des Sitzungsschlüssels eine Aufgabe ist, die während der Authentifizierungsphase erfüllt werden sollte. \item Allerdings unterstützt nur das PPP-EAP-TLS-Authentifizierungsprotokoll den Aufbau von Sitzungsschlüsseln. @@ -5712,19 +4379,15 @@ (PPTP)} \begin{itemize*} - \item - PPP wurde ursprünglich für den Betrieb zwischen ,,direkt'' verbundenen + \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 + \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: @@ -5746,13 +4409,10 @@ Tunneling} \begin{itemize*} - \item - PPTP realisiert einen ,,Tunnel'' über das Internet, der PPP-Pakete + \item PPTP realisiert einen ,,Tunnel'' über das Internet, der PPP-Pakete überträgt. - \item - Ein solcher Tunnel kann zwischen verschiedenen Einheiten realisiert + \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*} @@ -5774,26 +4434,20 @@ ,,Geschichte''} \begin{itemize*} - \item - PPTP hat sich vor allem aufgrund der Unterstützung durch Microsoft + \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 + \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 + \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 @@ -5806,36 +4460,27 @@ L2TP} \begin{itemize*} - \item - Beide Protokolle: - + \item Beide Protokolle: \begin{itemize*} \item verwenden PPP, um eine anfängliche Umhüllung für Benutzerpakete bereitzustellen \item erweitern das PPP-Modell, indem sie erlauben, dass die Layer-2- und PPP-Endpunkte sich auf verschiedenen Geräten befinden \item unterstützen freiwilliges und obligatorisches Tunneling \end{itemize*} - \item - Zugrundeliegendes Netzwerk: - + \item Zugrundeliegendes Netzwerk: \begin{itemize*} \item PPTP benötigt ein IP-Netzwerk für den Transport seiner PDUs \item L2TP unterstützt verschiedene Technologien: IP (unter Verwendung von UDP), permanente virtuelle Schaltungen (PVCs) von Frame Relay, virtuelle Schaltungen (VCs) von X.25 oder ATM VCs \end{itemize*} - \item - PPTP kann nur einen einzigen Tunnel zwischen Endpunkten unterstützen, + \item PPTP kann nur einen einzigen Tunnel zwischen Endpunkten unterstützen, L2TP ermöglicht die Verwendung mehrerer Tunnel zwischen Endpunkten - \begin{itemize*} \item L2TP ermöglicht z. B. die Erstellung verschiedener Tunnel für unterschiedliche Dienstqualitäten \end{itemize*} - \item - Beide Protokolle bieten eine Header-Kompression: - + \item Beide Protokolle bieten eine Header-Kompression: \begin{itemize*} \item Mit Header-Kompression kommt L2TP mit 4 Byte Overhead aus, im Vergleich zu 6 Byte bei PPTP. \end{itemize*} - \item - L2TP ermöglicht eine Tunnelauthentifizierung, während PPTP dies nicht + \item L2TP ermöglicht eine Tunnelauthentifizierung, während PPTP dies nicht tut. \end{itemize*} @@ -5844,10 +4489,8 @@ Netzwerke} \begin{itemize*} - \item - Verschiedene Definitionen des Begriffs virtuelles privates Netzwerk + \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 @@ -5866,25 +4509,19 @@ Techniken zum Aufbau virtueller privater Netze \begin{itemize*} - \item - Nutzung dedizierter Verbindungen (Cut-Through-Mechanismen): - + \item Nutzung dedizierter Verbindungen (Cut-Through-Mechanismen): \begin{itemize*} \item Virtuelle Verbindungen über ATM oder Frame Relay \item Multi-Protokoll über ATM (MPOA) \item Multiprotokoll-Etiketten-Vermittlung (MPLS) \item Sicherheitsdienste für Link Layer VPNs können effizient im Link Layer Protokoll realisiert werden; ein Beispiel ist die ATM Security Specification {[}ATM99a{]} \end{itemize*} - \item - Kontrolliertes Routenleck / Routenfilterung: - + \item Kontrolliertes Routenleck / Routenfilterung: \begin{itemize*} \item Grundidee: Kontrolle der Routenausbreitung dahingehend, dass nur bestimmte Netze Routen für andere Netze erhalten \item Damit soll ,,security by obscurity'' realisiert werden (also kein wirklicher Schutz!) \end{itemize*} - \item - Tunneln: - + \item Tunneln: \begin{itemize*} \item Generische Routing-Kapselung (GRE) \item PPP / PPTP / L2TP @@ -5900,13 +4537,9 @@ \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: - + \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*} @@ -5914,33 +4547,25 @@ \item IP-Sicherheitsrichtlinien-Datenbank (SPD) \item Sicherheitsvereinigungen (SA) und die SA-Datenbank (SADB) \end{itemize*} - \item - IPsec Sicherheitsprotokolle: - + \item IPsec Sicherheitsprotokolle: \begin{itemize*} \item Authentifizierungs-Header (AH) \item Encapsulating Security Payload (ESP) \end{itemize*} - \item - Entitätsauthentifizierung und der Internet-Schlüsselaustausch (IKE) + \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 + \item IP (Internet Protocol): unzuverlässiges, verbindungsloses Netzwerkprotokoll - \item - TCP (Transmission Control Protocol): zuverlässiges, + \item TCP (Transmission Control Protocol): zuverlässiges, verbindungsorientiertes Transportprotokoll, realisiert über IP - \item - UDP (User Datagram Protocol): unzuverlässiges, verbindungsloses + \item UDP (User Datagram Protocol): unzuverlässiges, verbindungsloses Transportprotokoll, bietet eine Anwendungsschnittstelle zu IP - \item - Beispiele für Anwendungsprotokolle : - + \item Beispiele für Anwendungsprotokolle : \begin{itemize*} \item HTTP: Hypertext-Übertragungsprotokoll \item SMTP: Einfaches Mail-Übertragungsprotokoll @@ -5953,90 +4578,64 @@ \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipv4-packet-format.png} - \item - Version (Ver.): 4 bit - + \item Version (Ver.): 4 bit \begin{itemize*} \item Derzeit ist Version 4 weit verbreitet \item Version 6 ist bereits spezifiziert, aber es ist noch nicht klar, ob sie jemals zum Einsatz kommen wird \end{itemize*} - \item - IP-Header-Länge (IHL): 4 Bit - + \item IP-Header-Länge (IHL): 4 Bit \begin{itemize*} \item Länge des IP-Headers in 32-Bit-Wörtern \end{itemize*} - \item - Art des Dienstes (TOS): 8 Bit - + \item Art des Dienstes (TOS): 8 Bit \begin{itemize*} \item Dieses Feld könnte verwendet werden, um die Verkehrsanforderungen eines Pakets anzugeben. \item Jetzt: DCSP und Explicit Congestion (EC) Indication \end{itemize*} - \item - Länge: 16 Bit - + \item Länge: 16 Bit \begin{itemize*} \item Die Länge des Pakets einschließlich des Headers in Oktetten \item Dieses Feld ist, wie alle anderen Felder in der IP-Suite, in ,,big endian'' Darstellung \end{itemize*} - \item - Kennung: 16 Bit - + \item Kennung: 16 Bit \begin{itemize*} \item Dient der ,,eindeutigen'' Identifizierung eines IP-Datagramms \item Wichtig für das Wiederzusammensetzen von fragmentierten IP-Datagrammen \end{itemize*} - \item - Flaggen: 3 Bit - + \item Flaggen: 3 Bit \begin{itemize*} \item Bit 1: nicht fragmentieren \item Bit 2: Datagramm fragmentiert \item Bit 3: reserviert für zukünftige Verwendung \end{itemize*} - \item - Fragmentierungs-Offset: 13 Bit - + \item Fragmentierungs-Offset: 13 Bit \begin{itemize*} \item Die Position dieses Pakets im entsprechenden IP-Datagramm \end{itemize*} - \item - Lebenszeit (TTL): 8 Bit - + \item Lebenszeit (TTL): 8 Bit \begin{itemize*} \item An jedem verarbeitenden Netzknoten wird dieses Feld um eins dekrementiert \item Wenn die TTL 0 erreicht, wird das Paket verworfen, um Paketschleifen zu vermeiden. \end{itemize*} - \item - Protokoll: 8 Bit - + \item Protokoll: 8 Bit \begin{itemize*} \item Gibt das (Transport-)Protokoll der Nutzlast an \item Wird vom empfangenden Endsystem verwendet, um Pakete zwischen verschiedenen Transportprotokollen wie TCP, UDP, ... zu entmultiplexen. \end{itemize*} - \item - Prüfsumme: 16 Bit - + \item Prüfsumme: 16 Bit \begin{itemize*} \item Schutz vor Übertragungsfehlern \item Da es sich nicht um eine kryptografische Prüfsumme handelt, kann sie leicht gefälscht werden. \end{itemize*} - \item - Quelladresse: 32 Bit - + \item Quelladresse: 32 Bit \begin{itemize*} \item Die IP-Adresse des Absenders dieses Pakets \end{itemize*} - \item - Zieladresse: 32 Bit - + \item Zieladresse: 32 Bit \begin{itemize*} \item Die IP-Adresse des vorgesehenen Empfängers dieses Pakets \end{itemize*} - \item - IP-Optionen: variable Länge - + \item IP-Optionen: variable Länge \begin{itemize*} \item Ein IP-Header kann optional zusätzliche Informationen enthalten. \item Da sie nicht Bestandteil von IPsec sind, werden sie in diesem Kurs nicht behandelt. @@ -6048,9 +4647,7 @@ Internet-Protokolls} \begin{itemize*} - \item - Wenn eine Einheit ein IP-Paket empfängt, hat sie keine Garantie für: - + \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*} @@ -6064,19 +4661,15 @@ IPsec} \begin{itemize*} - \item - IPsec zielt darauf ab, die folgenden Sicherheitsziele zu + \item IPsec zielt darauf ab, die folgenden Sicherheitsziele zu gewährleisten: - \begin{itemize*} \item Authentifizierung der Datenherkunft / Verbindungslose Datenintegrität: \begin{itemize*} \item Es ist nicht möglich, ein IP-Datagramm mit einer maskierten IP-Quell- oder Zieladresse zu senden, ohne dass der Empfänger dies erkennen kann. \item Es ist nicht möglich, ein IP-Datagramm während der Übertragung zu verändern, ohne dass der Empfänger diese Veränderung feststellen kann. \item Wiedergabeschutz: Es ist nicht möglich, ein aufgezeichnetes IP-Paket zu einem späteren Zeitpunkt erneut abzuspielen, ohne dass der Empfänger dies erkennen kann. \end{itemize*} \item Vertraulichkeit: \begin{itemize*} \item Es ist nicht möglich, den Inhalt von IP-Datagrammen zu belauschen \item Begrenzte Vertraulichkeit des Verkehrsflusses \end{itemize*} \end{itemize*} - \item - Sicherheitspolitik: - + \item Sicherheitspolitik: \begin{itemize*} \item Sender, Empfänger und Zwischenknoten können den erforderlichen Schutz für ein IP-Paket gemäß einer lokalen Sicherheitsrichtlinie festlegen \item Zwischenknoten und der Empfänger verwerfen IP-Pakete, die diese Anforderungen nicht erfüllen @@ -6094,9 +4687,7 @@ IPsec-Architektur} \begin{itemize*} - \item - RFC 4301 definiert die grundlegende Architektur von IPsec: - + \item RFC 4301 definiert die grundlegende Architektur von IPsec: \begin{itemize*} \item Konzepte: \begin{itemize*} \item Sicherheitsvereinigung (SA), Sicherheitsvereinigungsdatenbank (SADB) \item Sicherheitsrichtlinien, Sicherheitsrichtlinien-Datenbank (SPD) \end{itemize*} @@ -6107,9 +4698,7 @@ \item Schlüsselmanagement-Verfahren: \begin{itemize*} \item IKE \& IKEv \end{itemize*} \end{itemize*} - \item - RFC 4301 definiert die grundlegende Architektur von IPsec: - + \item RFC 4301 definiert die grundlegende Architektur von IPsec: \begin{itemize*} \item Verwendung von verschiedenen kryptographischen Primitiven mit AH und ESP: \begin{itemize*} \item Verschlüsselung: 3DES-CBC, AES und andere CBC-Verschlüsselungsalgorithmen, AES-Zählermodus \item Integrität: HMAC-MD5, HMAC-SHA-1, HMAC-SHA-2, HMAC- RIPEMD-160, AES-GMAC, AES-CMAC, AES-XCBC... \item Authentifizierte Verschlüsselung: GCM und "Zähler mit CBC-MAC" (CCM), beide für AES definiert \end{itemize*} @@ -6174,10 +4763,8 @@ protection)} \begin{itemize*} - \item - Sowohl AH- als auch ESP-geschützte IP-Pakete tragen eine + \item Sowohl AH- als auch ESP-geschützte IP-Pakete tragen eine Sequenznummer, die einen Wiedergabeschutz realisiert: - \begin{itemize*} \item Beim Einrichten einer SA wird diese Sequenznummer auf Null initialisiert. \item Die Sequenznummer wird mit jedem gesendeten IP-Paket erhöht @@ -6186,19 +4773,15 @@ % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-replay-protection.png} \begin{itemize*} \item (Paket mit Sequenznummer N kann noch akzeptiert werden) \end{itemize*} \end{itemize*} - \item - Wenn ein empfangenes Paket eine Sequenznummer hat, die: - + \item Wenn ein empfangenes Paket eine Sequenznummer hat, die: \begin{itemize*} \item links vom aktuellen Fenster \$\textbackslash Rightarrow\$ liegt, lehnt der Empfänger das Paket ab \item innerhalb des aktuellen Fensters \$\textbackslash Rightarrow\$ liegt, nimmt der Empfänger das Paket an \item liegt rechts vom aktuellen Fenster \$\textbackslash Rightarrow\$ der Empfänger nimmt das Paket an und schiebt das Fenster weiter \item Natürlich werden IP-Pakete nur akzeptiert, wenn sie die Authentifizierungsprüfung bestehen und das Fenster wird niemals vor dieser Prüfung weitergeschaltet \end{itemize*} - \item - Die minimale Fenstergröße beträgt 32 Pakete (64 Pakete werden + \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 @@ -6210,28 +4793,25 @@ Host-Implementierung} \begin{itemize*} - \item - Vorteile der IPsec-Implementierung in Endsystemen: - + \item Vorteile der IPsec-Implementierung in Endsystemen: \begin{itemize*} \item Bereitstellung von End-to-End-Sicherheitsdiensten \item Bereitstellung von Sicherheitsdiensten auf einer Per-Flow-Basis \item Fähigkeit, alle IPsec-Modi zu implementieren \end{itemize*} - \item - Zwei Hauptalternativen zur Integration: \textbar{} Integriertes - Betriebssystem \textbar{} ,,Bump'' im Stack \textbar{} \textbar{} - -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- - \textbar{} - -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- - \textbar{} \textbar{} Anwendung \textbar{} Anwendung \textbar{} - \textbar{} Transport \textbar{} Transport \textbar{} \textbar{} - Netzwerk + IPsec \textbar{} Netzwerk \textbar{} \textbar{} IPsec - \textbar{} \textbar{} Data Link \textbar{} Data Link \textbar{} - \textbar{} \textbar{} \textbar{} Echte Betriebssystemintegration ist + \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 \textbar{} Wenn das Betriebssystem nicht geändert werden - kann, wird IPsec über den Datenverbindungstreiber eingefügt \textbar{} + vermeidet | Wenn das Betriebssystem nicht geändert werden + kann, wird IPsec über den Datenverbindungstreiber eingefügt | \end{itemize*} @@ -6239,17 +4819,13 @@ Router-Implementierung} \begin{itemize*} - \item - Vorteile der IPsec-Implementierung in Routern: - + \item Vorteile der IPsec-Implementierung in Routern: \begin{itemize*} \item Möglichkeit, IP-Pakete zu sichern, die zwischen zwei Netzen über ein öffentliches Netz wie das Internet fließen: \begin{itemize*} \item Ermöglicht die Einrichtung virtueller privater Netzwerke (VPNs) \item Keine Notwendigkeit, IPsec in jedes Endsystem zu integrieren \end{itemize*} \item Fähigkeit zur Authentifizierung und Autorisierung des IP-Verkehrs, der von entfernten Benutzern eingeht \end{itemize*} - \item - Zwei Hauptalternativen für die Implementierung: - + \item Zwei Hauptalternativen für die Implementierung: % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ipsec-router-implementation.png} \end{itemize*} @@ -6258,38 +4834,30 @@ werden?} \begin{itemize*} - \item - In den meisten Fällen handelt es sich bei den Kommunikationsendpunkten + \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 + \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 + \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 + \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} @@ -6321,13 +4889,10 @@ Pakete} \begin{itemize*} - \item - Nehmen wir an, die IP-Schicht eines Knotens (Host/Gateway) wird + \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 Um IPsec zu unterstützen, muss sie die folgenden Schritte durchführen: \begin{itemize*} \item Feststellen, ob und wie das ausgehende Paket gesichert werden muss: \begin{itemize*} @@ -6571,21 +5136,16 @@ Sicherheitsassoziationen} \begin{itemize*} - \item - Bevor ein Paket durch IPsec geschützt werden kann, muss eine SA + \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 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*} @@ -6598,25 +5158,19 @@ \subsection{ISAKMP - Einführung} \begin{itemize*} - \item - Die IETF hat zwei RFCs zu ISAKMP für IPsec verabschiedet: - + \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 + \item Das ISAKMP-Basisprotokoll ist ein generisches Protokoll, das für verschiedene Zwecke verwendet werden kann: - \begin{itemize*} \item Die für eine Anwendung von ISAKMP spezifischen Verfahren werden in einem DOI-Dokument detailliert beschrieben. \item Es wurden weitere DOI-Dokumente erstellt: \begin{itemize*} \item Group DOI für sichere Gruppenkommunikation {[}RFC6407{]} \item MAP DOI für die Verwendung von ISAKMP zum Aufbau von SAs zur Sicherung des Mobile Application Protocol (MAP) von GSM (Internet Draft, Nov. 2000) \end{itemize*} \end{itemize*} - \item - ISAKMP definiert zwei grundlegende Kategorien von Austauschvorgängen: - + \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 @@ -6628,38 +5182,27 @@ Nachrichtenformat} \begin{itemize*} - \item - % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-format.png} - \item - Initiator \& Responder Cookie: - + \item % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-ISAKMP-format.png} + \item Initiator \& Responder Cookie: \begin{itemize*} \item Identifizieren einen ISAKMP-Austausch bzw. eine Sicherheitsassoziation \item Dienen auch als begrenzter Schutz gegen Denial-of-Service-Angriffe (siehe unten) \end{itemize*} - \item - Nächste Nutzlast: gibt an, welcher ISAKMP-Nutzlasttyp die erste + \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: - + \item Major \& Minor Version: gibt die Version des ISAKMP-Protokolls an + \item Austausch-Typ: \begin{itemize*} \item Gibt die Art des verwendeten Austauschs an \item Es gibt fünf vordefinierte generische Austauschtypen, weitere Typen können pro DOI definiert werden \end{itemize*} - \item - Flags: - + \item Flags: \begin{itemize*} \item Encrypt: wenn auf eins gesetzt, wird die Nutzlast nach dem Header verschlüsselt \item Commit: wird für die Schlüsselsynchronisation verwendet \item Authenticate only: wenn auf eins gesetzt, wird nur der Schutz der Datenursprungsauthentifizierung auf die ISAKMP-Nutzdaten angewendet und keine Verschlüsselung durchgeführt \end{itemize*} - \item - Nachrichten-ID: - + \item Nachrichten-ID: \begin{itemize*} \item Dient zur Identifizierung von Nachrichten, die zu verschiedenen Austauschen gehören \end{itemize*} @@ -6701,10 +5244,8 @@ \subsubsection{ISAKMP - Nutzdatenarten} \begin{itemize*} - \item - RFC 2408 definiert verschiedene Nutzdaten von ISAKMP (Liste ist nicht + \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 @@ -6715,102 +5256,74 @@ \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 + \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 + \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 Auf den SA-Payload folgen ein oder mehrere Proposal-Payloads \end{itemize*} - \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 + \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 + \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 + \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 + \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 + \item Jede in einem Vorschlag aufgeführte Transformation hat eine eindeutige Transform \# - \item - Jede Transformation wird durch eine Transform-ID eindeutig + \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 + \item Die SA-Attribute geben die Attribute an, die für die im Feld Transform ID angegebene Transformation definiert sind. \end{itemize*} - \subsubsection{ISAKMP - SA-Verhandlung} - \begin{itemize*} - \item - Inhalt des Next Payload-Feldes von SA-, Proposal- und + \item Inhalt des Next Payload-Feldes von SA-, Proposal- und Transform-Payloads: - \begin{itemize*} \item Das Next-Payload-Feld einer SA-Payload gibt nicht die unmittelbar folgende Proposal-Payload an, da diese implizit ist. \item Das Gleiche gilt für Proposal- und Transform-Payloads \end{itemize*} - \item - Die Proposal-Payload gibt der initiierenden Entität die Möglichkeit, + \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 + \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 + \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 Dieses erste Beispiel zeigt eine ESP- UND AH-Schutzsuite: \begin{itemize*} \item Das erste Protokoll wird mit zwei von der vorschlagenden Stelle unterstützten Transformationen dargestellt, ESP mit: \begin{itemize*} \item Transformation 1 als 3DES \item Umwandlung 2 als AES \item Der Responder muss zwischen den beiden für ESP vorgeschlagenen Transformationen wählen. \end{itemize*} @@ -6822,10 +5335,8 @@ \begin{itemize*} \item {[}Vorschlag 1, ESP, (Transform 1, 3DES, ...), (Transform 2, AES){]} {[}Vorschlag 1, AH, (Transform 1, SHA){]} \end{itemize*} \item Bitte beachten Sie, dass dies zu zwei SAs pro Richtung führt! \end{itemize*} - \item - Dieses zweite Beispiel zeigt einen Vorschlag für zwei verschiedene + \item Dieses zweite Beispiel zeigt einen Vorschlag für zwei verschiedene Schutzsuiten: - \begin{itemize*} \item Die erste Schutzsuite wird vorgestellt mit: \begin{itemize*} \item einer Transformation (MD5) für das erste Protokoll (AH), und \item eine Umwandlung (3DES) für das zweite Protokoll (ESP) \end{itemize*} @@ -6836,38 +5347,29 @@ \begin{itemize*} \item {[}Vorschlag 1, AH, (Transform 1, MD5, ...){]} {[}Vorschlag 1, ESP, (Transform 1, 3DES, ...){]} {[}Vorschlag 2, ESP, (Transform1, 3DES, ...), (Transform 2, AES, ...){]} \end{itemize*} \item Bitte beachten Sie, dass Vorschlag 1 zu zwei SAs pro Richtung führt. \end{itemize*} - \item - Bei der Beantwortung einer Security-Association-Nutzlast muss der + \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 + \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 + \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 + \item Der Initiator muss überprüfen, ob die vom Responder empfangene SA-Nutzlast mit einem der ursprünglich gesendeten Vorschläge übereinstimmt \end{itemize*} - \subsubsection{ISAKMP - Session Key Establishment} - \begin{itemize*} - \item - ISAKMP baut 4 verschiedene Schlüssel mit einem + \item ISAKMP baut 4 verschiedene Schlüssel mit einem Authentifizierungsaustausch auf: - \begin{itemize*} \item SKEYID ist eine Zeichenkette, die aus geheimem Material abgeleitet wird, das nur den aktiven Teilnehmern des Austauschs bekannt ist und als ,,Hauptschlüssel'' dient. \begin{itemize*} \item Die Berechnung von SKEYID ist abhängig von der Authentifizierungsmethode \end{itemize*} @@ -6877,17 +5379,12 @@ \end{itemize*} \end{itemize*} - \subsection{IKE - Einführung} - \begin{itemize*} - \item - Während ISAKMP die grundlegenden Datenformate und Verfahren zur + \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 IKE definiert fünf Austauschvorgänge: \begin{itemize*} \item Phase-1-Austausch für die Einrichtung einer IKE SA : \begin{itemize*} \item Main-Mode-Austausch, der durch 6 ausgetauschte Nachrichten realisiert wird \item Aggressive mode exchange, der nur 3 Nachrichten benötigt \end{itemize*} @@ -6896,93 +5393,73 @@ \item Andere Austausche: \begin{itemize*} \item Informationsaustausch zur Übermittlung von Status- und Fehlermeldungen \item Neuer Gruppenaustausch zur Vereinbarung von privaten Diffie-Hellman-Gruppen \end{itemize*} \end{itemize*} - \item - Hinweis: Auf den folgenden Folien steht HMAC(K, x \textbar{} y - \textbar{} ...) für H(K, p 1 , H(K, p 2 , x, y, ...)), wobei p 1 und p + \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 - Berechnung von IKE-Sitzungsschlüsseln} - \begin{itemize*} - \item - IKE baut vier verschiedene Schlüssel mit einem + \item IKE baut vier verschiedene Schlüssel mit einem Authentifizierungsaustausch auf: - \begin{itemize*} \item SKEYID ist eine Zeichenkette, die aus geheimem Material abgeleitet wird, das nur den aktiven Teilnehmern des Austauschs bekannt ist, und die als ,,Hauptschlüssel'' dient. \begin{itemize*} \item Die Berechnung von SKEYID ist abhängig von der Authentifizierungsmethode \end{itemize*} \item SKEYID\_d ist das Keying-Material, das zur Ableitung von Schlüsseln für Nicht-IKE-SAs verwendet wird - \begin{itemize*} \item SKEYID\_d = \$HMAC(SKEYID, g\^{}\{xy\} \textbar{} CKY-I \textbar{} CKY-R \textbar{} 0)\$, wobei \$g\^{}\{xy\}\$ das gemeinsame Diffie-Hellman-Geheimnis bezeichnet \end{itemize*} + \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 \textbar{} g\^{}\{xy\} \textbar{} CKY-I \textbar{} CKY-R \textbar{} 1)\$ \end{itemize*} + \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 \textbar{} g\^{}\{xy\} \textbar{} CKY-I \textbar{} CKY-R \textbar{} 2)\$ \end{itemize*} + \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 + \item Falls erforderlich, werden die Schlüssel nach der folgenden Methode erweitert: - \begin{itemize*} - \item \$K=(K\_1 \textbar{} K\_2 \textbar{} ...)\$ mit \$K\_i = HMAC(SKEYID, K\_\{i-1\})\$ und \$K\_0 = 0\$ + \item \$K=(K\_1 | K\_2 | ...)\$ mit \$K\_i = HMAC(SKEYID, K\_\{i-1\})\$ und \$K\_0 = 0\$ \end{itemize*} \end{itemize*} - \subsubsection{IKE - Authentifizierungsmethoden} - \begin{itemize*} - \item - Phase 1 IKE-Austausche werden mit Hilfe von zwei Hash-Werten Hash-I + \item Phase 1 IKE-Austausche werden mit Hilfe von zwei Hash-Werten Hash-I und Hash-R authentifiziert, die vom Initiator und vom Responder erstellt werden: - \begin{itemize*} - \item Hash-I = HMAC(SKEYID, gx \textbar{} gy \textbar{} CKY-I \textbar{} CKY-R \textbar{} SA-Angebot \textbar{} ID-I) - \item Hash-R = HMAC(SKEYID, gy \textbar{} gx \textbar{} CKY-R \textbar{} CKY-I \textbar{} SA-offer \textbar{} ID-R) wobei gx, gy die ausgetauschten öffentlichen Diffie-Hellman-Werte bezeichnen ID-I, ID-R bezeichnen die Identität des Initiators und des Responders SA-offer bezeichnet die Nutzdaten bezüglich der SA-Verhandlung + \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*} - \item - IKE unterstützt vier verschiedene Methoden der Authentifizierung: - + \item IKE unterstützt vier verschiedene Methoden der Authentifizierung: \begin{itemize*} \item Pre-shared Key: - \begin{itemize*} \item SKYEID = \$HMAC(K\_\{Initiator\}, Responder , r\_\{Initiator\} \textbar{} r\_\{Responder\})\$ \end{itemize*} + \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 \textbar{} CKY-R) \end{itemize*} + \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\} \textbar{} r\_\{Responder\}), g\^{}\{xy\})\$ \item Da in diesem Fall SKEYID selbst keine Authentifizierung bietet, werden die Werte Hash-I und Hash-R vom Initiator/Responder signiert \end{itemize*} + \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*} \end{itemize*} \end{itemize*} - \subsubsection{IKE - Main Mode Austausch mit Pre-Shared Key} - \begin{itemize*} - \item - Die folgenden Beschreibungen listen die ausgetauschten ISAKMP- und + \item Die folgenden Beschreibungen listen die ausgetauschten ISAKMP- und IKE-Payloads auf, wenn verschiedene ,,Flavors'' der IKE-Authentifizierung durchgeführt werden: - \begin{itemize*} % \item \includegraphics[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 + \item Bitte beachten Sie, dass Hash-I und Hash-R nicht signiert werden müssen, da sie bereits ,,ein authentisches Geheimnis'' (Pre-Shared Key) enthalten \end{itemize*} - \subsubsection{IKE - Hauptmodus Austausch mit Signaturen} - \begin{itemize*} \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKE-exchange-payload-signature.png} \begin{itemize*} @@ -6992,10 +5469,8 @@ \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} \begin{itemize*} @@ -7012,76 +5487,57 @@ \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 + \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 + \item Ähnliche Varianten des aggressiven Modus gibt es auch für die Authentifizierung mit: - \begin{itemize*} \item Digitale Signatur \item Verschlüsselung mit öffentlichem Schlüssel \end{itemize*} \end{itemize*} - \subsubsection{IKE - Quick Mode Exchange} - \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKE-quick-mode.png} - \item - \$Hash1 = HMAC(SKEYID\_a, M-ID \textbar{} SA \textbar{} Ni \textbar{} - {[} \textbar{} KE {]} {[} \textbar{} ID\_\{ci\} \textbar{} + \item \$Hash1 = HMAC(SKEYID\_a, M-ID | SA | Ni | + {[} | KE {]} {[} | ID\_\{ci\} | ID\_\{cr\}{]} )\$ - \item - \$Hash2 = HMAC(SKEYID\_a, M-ID \textbar{} N\_i \textbar{} SA - \textbar{} N\_r \textbar{} {[} \textbar{} KE {]} {[} \textbar{} - ID\_\{ci\} \textbar{} ID\_\{cr\}{]} ) - \item - \$Hash3 = HMAC(SKEYID\_a, 0 \textbar{} M-ID \textbar{} N\_i \textbar{} + \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 + \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 + \item Die optionalen Schlüsselaustausch-Payloads KE ermöglichen die Durchführung eines neuen DH-Austauschs, wenn perfekte Forward Secrecy gewünscht ist - \item - Sitzungsschlüsselmaterial \$= HMAC(SKEYID\_d, {[} g\^{}\{xy\} - \textbar{} {]} protocol \textbar{} SPI \textbar{} N\_i \textbar{} + \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: - + \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 + \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*} @@ -7090,108 +5546,78 @@ \end{itemize*} \end{itemize*} - \subsection{Schlussfolgerung} - \begin{itemize*} - \item - IPsec ist die Sicherheitsarchitektur der IETF für das + \item IPsec ist die Sicherheitsarchitektur der IETF für das Internet-Protokoll - \item - Sie bietet die folgenden Sicherheitsdienste für IP-Pakete: - + \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 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: - + \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 + \item SA-Verhandlung und Schlüsselverwaltung werden mit folgenden Protokollen realisiert: - \begin{itemize*} \item Internet security association key management protocol (ISAKMP) \item Internet-Schlüsselaustausch (IKE) \end{itemize*} \end{itemize*} - \subsection{Neue Wege in der IPsec-Entwicklung} - \begin{itemize*} - \item - Internet-Schlüsselaustausch Version 2 - + \item Internet-Schlüsselaustausch Version 2 \begin{itemize*} \item Basierend auf den Erkenntnissen aus IKEv1 \item Wesentliche Vereinfachungen \end{itemize*} - \item - Netzwerkadressübersetzung (NAT) - + \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 Konfiguration von großen IPsec-Infrastrukturen \end{itemize*} - \subsection{Internet Key Exchange Protocol Version 2 {[}RFC5996{]}} - Zusätzliche Designziele zu IKEv1 - \begin{itemize*} - \item - Konsolidierung von mehreren IKEv1-RFCs (und mehreren Erweiterungen) - + \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 - + \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 + \item Verringerung der Latenzzeit + \item Aushandlung von Verkehrsselektoren + \item Graceful Changes, damit bestehende IKEv1-Software aufgerüstet werden kann \end{itemize*} - \subsubsection{IKEv2 - Schlüsselaustauschverfahren} - \begin{itemize*} \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-IKEv2-exchange-procedure.png} \begin{itemize*} - \item \$K\$ Schlüssel abgeleitet durch \$PRF(PRF(N\_i \textbar\textbar{} N\_r, g\^{}\{ir\}), N\_i \textbar\textbar{} N\_r \textbar\textbar{} SPI\_i \textbar\textbar{} SPI\_r)\$ + \item \$K\$ Schlüssel abgeleitet durch \$PRF(PRF(N\_i \textbar| N\_r, g\^{}\{ir\}), N\_i \textbar| N\_r \textbar| SPI\_i \textbar| SPI\_r)\$ \item \$PRF\$ ,,irgendeine'' Pseudozufallsfunktion - in der Regel eine asymmetrische HMAC SIG-Signatur oder MAC über die ersten beiden Nachrichten \item \$SAEx\$ ein Huckepack- ,,Quick-Mode-Austausch'' \end{itemize*} @@ -7199,7 +5625,6 @@ \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 @@ -7225,7 +5650,6 @@ \end{itemize*} \end{itemize*} - \subsubsection{IKEv2 - Zusätzliche Funktionen} \begin{itemize*} \item Zusätzlicher DoS-Schutz @@ -7249,7 +5673,6 @@ \end{itemize*} \end{itemize*} - \subsection{Netzwerk-Adressübersetzung (NAT)} \begin{itemize*} \item Heutzutage ein häufiges Problem: ISP stellt nur eine einzige IP-Adresse zur Verfügung, es sollen aber mehrere Geräte angeschlossen werden @@ -7270,14 +5693,12 @@ \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*} - \subsubsection{Probleme mit NAT und IPsec - NAT-Traversal} \begin{itemize*} \item Probleme: @@ -7294,25 +5715,19 @@ \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: - + \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? - + \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 - + \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 @@ -7322,17 +5737,12 @@ \end{itemize*} \end{itemize*} - \subsubsection{Probleme mit NAT und IPsec - BEET-Modus} - \begin{itemize*} - \item - Welche Adressen soll Alice verwenden, um Pakete an Bob, Charlie und + \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! - + \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 @@ -7340,9 +5750,7 @@ \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 - + \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 @@ -7350,55 +5758,40 @@ \item durch Aushandlung von Verkehrsselektoren (IKEv2) \item L2TP über IPsec ausführen \end{itemize*} - \item - IPsec-Tunnelmodus ist erforderlich - + \item IPsec-Tunnelmodus ist erforderlich \begin{itemize*} \item Externer IP-Header trägt entweder eine öffentliche IP-Adresse oder eine private NAT-Adresse \item Interner IP Header trägt virtuelle IP-Adresse \item Führt zu (mindestens!) 28 Bytes Overhead pro Paket in NAT-Situationen - \item \textbar{} IP Header \textbar{} UDP Header \textbar{} ESP Header \textbar{} IP Header \textbar{} geschützte Daten \textbar{} + \item | IP Header | UDP Header | ESP Header | IP Header | geschützte Daten | \end{itemize*} - \item - Aber eigentlich sind nur Adressfelder im inneren IP-Header + \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 + \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 + \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 + \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 + \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 + \item Der innere Header wird durch den ESP-Entkapselungsprozess wiederhergestellt. - \item - Unterscheidet zwischen der Erreichbarkeit eines Hosts (externe + \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 + \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 Kommunikationsinfrastrukturen von Unternehmen und Behörden: + \item Kann komplexe Overlay-Topologien bilden \begin{itemize*} \item Verschachtelt \item Kreisläufe @@ -7407,62 +5800,45 @@ \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 - + \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 ... + \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 + \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 - + \item Daher werden Sicherheits-Gateways in der Regel manuell konfiguriert \begin{itemize*} \item Die Anzahl der Sicherheitsrichtlinieneinträge wächst quadratisch mit der Anzahl der Sicherheitsgateways \item Problem der Skalierbarkeit \begin{itemize*} \item Der Administrationsaufwand wächst \$\textbackslash Rightarrow\$ Die Kosten steigen \item Administratoren machen potenziell mehr Konfigurationsfehler, z.B. vergessen, einen Eintrag aus einem SPD zu löschen oder einen zu großen IP-Bereich zuzulassen, usw. \$\textbackslash Rightarrow\$ Mögliche Sicherheitsprobleme \end{itemize*} \end{itemize*} - \item - Problem der Agilität - + \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 - + \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 - + \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 @@ -7471,44 +5847,27 @@ \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) + \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 + \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: - + \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 @@ -7519,16 +5878,11 @@ \end{itemize*} \end{itemize*} - \subsubsection{Tunnel Endpoint Discovery (TED)} - \begin{itemize*} - \item - Proprietärer Ansatz von Cisco {[}Fluh01{]} - \item - Sicherheitsassoziationen werden reaktiv erstellt - + \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 @@ -7537,9 +5891,7 @@ \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 - + \item Ziemlich leistungsfähiger, sicherer Ansatz, aber \begin{itemize*} \item Routing muss im Transportnetz durchgeführt werden \item Keine privaten IP-Adressbereiche @@ -7548,60 +5900,40 @@ %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-TED.png} \end{itemize*} - \subsubsection{Gruppenverschlüsseltes Transport-VPN (GET)} - \begin{itemize*} - \item - Cisco Produktbranding mehrerer IPsec-Komponenten {[}Bhai08{]} - \item - Sicherheits-Gateways kontaktieren zentralen IKE-Server - \item - IKE-Server verteilt symmetrische Schlüssel (bevorzugt über Multicast) - \item - Alle Sicherheitsgateways einer Gruppe verwenden dieselbe SA + \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) - + \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: - + \item Zusätzliche Probleme mit zentralen Policy-Servern: \begin{itemize*} \item schwacher Wiedergabeschutz \item Die Kompromittierung eines einzelnen Gateways beeinträchtigt das gesamte VPN \item Rekeying durch symmetrischen Austausch \$\textbackslash Rightarrow\$ kann nicht von kompromittierten Schlüsseln wiederhergestellt werden \item Perfektes Vorwärtsgeheimnis nicht verfügbar \end{itemize*} - \item - Einziger Vorteil: Ermöglicht Multicast-Netzwerkprivatisierung + \item Einziger Vorteil: Ermöglicht Multicast-Netzwerkprivatisierung %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-GET.png} \end{itemize*} - \subsubsection{Proaktives Multicast-basiertes IPsec-Erkennungsprotokoll} - \begin{itemize*} - \item - Ansatz wurde für militärische Anwendungen entwickelt {[}Tran06{]} - \item - Sicherheits-Gateways kündigen periodisch private Netzwerke an - \item - Erfolgt durch Transportnetzwerk-Multicast - \item - Nachrichten werden durch einen vorab geteilten symmetrischen Schlüssel + \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 + \item Vorteile: Unterstützt private Adressbereiche, Multicast innerhalb des VPN - \item - Probleme: - + \item Probleme: \begin{itemize*} \item Erfordert Transportnetz-Multicast \item Verschachtelte Topologien funktionieren nicht @@ -7612,28 +5944,19 @@ %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-proactive-multicast-discovery.png} \end{itemize*} - \subsubsection{Soziales VPN} - \begin{itemize*} - \item - Akademischer Ansatz {[}FBJW08{]} - \item - Verwendet Facebook als ,,policy'' Server zum Austausch von IKE + \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 - + \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 Probleme \begin{itemize*} \item Keine Gateway-Funktionalität (nur Ende-zu-Ende) \item Keine verschachtelten Topologien @@ -7644,44 +5967,30 @@ \end{itemize*} \end{itemize*} - \subsubsection{Dynamisches Mehrpunkt-VPN (DMVPN)} - \begin{itemize*} - \item - Ein weiterer Ansatz von Cisco {[}Bhai08{]} - \item - VPN ist aufgeteilt in - + \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 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} - \begin{itemize*} - \item - Vorteile - + \item Vorteile \begin{itemize*} \item Ansatz ermöglicht dynamischere Topologien \item Kann private Adressen verwenden \end{itemize*} - \item - Nachteilig - + \item Nachteilig \begin{itemize*} \item Erfordert immer noch erheblichen Konfigurationsaufwand \begin{itemize*} \item Kernnetz muss manuell konfiguriert werden \item Spokes müssen mit den Adressen der Hubs konfiguriert werden \item Macht z.B. einen einfachen Wechsel zu einem neuen ISP unmöglich \end{itemize*} @@ -7692,29 +6001,20 @@ \end{itemize*} \end{itemize*} - \subsubsection{Sicheres OverLay für IPsec-Erkennung (SOLID)} - \begin{itemize*} - \item - Komplexer Ansatz, verspricht einfache Implementierung {[}RSS10{]} - \item - Sicherheitsgateways bilden ein strukturiertes Overlay-Netzwerk - + \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 - + \item Erfordert nur sehr wenige proaktiv erstellte IPsec-Verbindungen \begin{itemize*} \item Minimale Konnektivität ermöglicht eine reaktive Erkennung von Sicherheitsgateways \item Sich bewegende Sicherheitsgateways müssen nicht alle anderen über die aktuelle externe IP-Adresse informieren \end{itemize*} - \item - Drei Aufgaben zu erfüllen - + \item Drei Aufgaben zu erfüllen \begin{itemize*} \item Topologie-Kontrolle \begin{itemize*} \item Proaktiver Aufbau einer VPN-Struktur zur schnellen Erkennung \end{itemize*} @@ -7725,96 +6025,68 @@ \end{itemize*} \end{itemize*} - \paragraph{SOLID - Topologie-Kontrolle} - \begin{itemize*} - \item - Mechanismen zur Topologiekontrolle - + \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 + \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, + \item Sicherheitsgateways sind nach inneren Adressen geordnet + \item Gateways, die nicht direkt im Transportnetz kommunizieren können, werden durch virtuelle Pfade verbunden \$\textbackslash Rightarrow\$ Verschachtelte Strukturen werden abgeflacht, um eine einfache Erkennung zu ermöglichen %\item \includegraphics[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 + \item Reaktive Erkennung, um ein Sicherheits-Gateway für eine bestimmte Client-IP-Adresse zu finden - \item - Suchanfragen werden an das (bereits zugeordnete) Gateway + \item Suchanfragen werden an das (bereits zugeordnete) Gateway weitergeleitet, dessen innere IP-Adresse der gesuchten IP-Adresse ,,am ähnlichsten'' ist - \begin{itemize*} \item Ein einfacher Mechanismus stellt sicher, dass das korrekte entsprechende Sicherheits-Gateway gefunden wird \item Die Pakete werden entlang der Ringstruktur gesendet \item Benötigt \$O(n)\$ Overlay Hops, um das Ziel zu erreichen (wobei n die Anzahl der Netzwerke in der VPN-Topologie ist) \end{itemize*} - \item - \$\textbackslash Rightarrow\$ Kürzere ,,Suchpfade'' erforderlich + \item \$\textbackslash Rightarrow\$ Kürzere ,,Suchpfade'' erforderlich \end{itemize*} - \paragraph{SOLID - Mehr Topologiekontrolle} - \begin{itemize*} - \item - Erweiterte Topologiekontrolle schafft zusätzliche SAs - \item - IP-Adressraum des VPN wird in Bereiche unterteilt - + \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 + \item Zu jedem Bereich wird mindestens eine SA proaktiv von jedem Gateway gehalten - \item - Anzahl der zusätzlichen SAs wächst in \$O(log\textbackslash{} n)\$ - \item - Aufgrund der Konstruktionstechnik Entdeckung in + \item Anzahl der zusätzlichen SAs wächst in \$O(log\textbackslash{} n)\$ + \item Aufgrund der Konstruktionstechnik Entdeckung in \$O(log\textbackslash{} n)\$ Overlay Hops \$\textbackslash Rightarrow\$ Ansatz skaliert gut mit Anzahl der Netzwerke %\item \includegraphics[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 + \item Nach der anfänglichen Erkennung müssen die Datenpakete weitergeleitet werden - \item - Senden von Daten entlang des Entdeckungspfades möglich - + \item Senden von Daten entlang des Entdeckungspfades möglich \begin{itemize*} \item Länge wieder \$O(log\textbackslash{} n)\$ Overlay-Hops \item Zu ineffizient, wenn viele Pakete geroutet werden müssen \item Wird nur anfangs verwendet \end{itemize*} - \item - Nachfolgend wird der Pfad optimiert - + \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 @@ -7822,117 +6094,81 @@ \end{itemize*} \end{itemize*} - \paragraph{SOLID - Eigenschaften und Ergebnisse} - \begin{itemize*} - \item - Kann komplexe Infrastrukturen innerhalb von Sekunden oder Minuten + \item Kann komplexe Infrastrukturen innerhalb von Sekunden oder Minuten konfigurieren - \item - Erfordert keine manuelle Interaktion - \item - Erfordert keine besonderen Eigenschaften des Transportnetzes - \item - Robustheit - + \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 + \item Keine Schwächung der von Standard-IPsec gebotenen Sicherheit + \item Gute Skalierbarkeit mit der Anzahl der privaten Netze, keine Engpässe + \item Wenn Sicherheitsgateways umziehen, müssen nur zwei SAs wiederhergestellt werden, um die Erreichbarkeit zu gewährleisten \end{itemize*} - \paragraph{SOLID - Simulative Bewertung} - \begin{itemize*} - \item - SOLID kann in OMNeT++ evaluiert werden - \item - Ermöglicht Tests von komplexen Szenarien + \item SOLID kann in OMNeT++ evaluiert werden + \item Ermöglicht Tests von komplexen Szenarien \end{itemize*} - \paragraph{SOLID - Sonstige Forschung} - \begin{itemize*} - \item - SOLID wird in der Gruppe Telematik/Computernetzwerke erforscht - \item - Entwicklung von Prototypen - \item - Verfügbarkeit - + \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 - + \item Zugriffskontrolle + \item Robustheit \begin{itemize*} \item Proaktive Wiederherstellung bei Netzwerkausfällen \end{itemize*} - \item - Anwendungsschicht-Multicast - + \item Anwendungsschicht-Multicast \begin{itemize*} \item Ermöglicht sicheres Multicast über reine Unicast-Netze \end{itemize*} \end{itemize*} - \section{Sicherheitsprotokolle der Transportschicht} - \subsection{Anwendungsbereich von Sicherheitsprotokollen der Transportschicht} - \begin{itemize*} - \item - Die Transportschicht sorgt für die Kommunikation zwischen + \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 + \item Sicherheitsprotokolle der Transportschicht zielen darauf ab, den Dienst der Transportschicht zu verbessern, indem sie zusätzliche Sicherheitseigenschaften gewährleisten - \begin{itemize*} \item Da sie in der Regel einen zuverlässigen Transportdienst voraussetzen und darauf aufbauen, stellen sie nach der Terminologie des OSI-Referenzmodells (Open Systems Interconnection) eigentlich Sitzungsschichtprotokolle dar. \item Da OSI jedoch nicht mehr ,,en vogue'' ist, werden sie als Sicherheitsprotokolle der Transportschicht bezeichnet \end{itemize*} \end{itemize*} - \subsection{Das Secure Socket Layer (SSL) Protokoll} - \begin{itemize*} - \item - SSL wurde ursprünglich in erster Linie zum Schutz von HTTP-Sitzungen + \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. @@ -7943,27 +6179,19 @@ \end{itemize*} \end{itemize*} - \subsection{SSL-Sicherheitsdienste} - \begin{itemize*} - \item - Peer-Entity-Authentifizierung: - + \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: - + \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: - + \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. @@ -7971,14 +6199,10 @@ \end{itemize*} \end{itemize*} - \subsection{SSL-Sitzungs- und Verbindungsstatus} - \begin{itemize*} - \item - Sitzungsstatus: - + \item Sitzungsstatus: \begin{itemize*} \item Sitzungskennzeichen: eine vom Server gewählte Bytefolge \item Peer-Zertifikat: X.509 v.3 Zertifikat der Gegenstelle (optional) @@ -7987,9 +6211,7 @@ \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: - + \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 @@ -7999,17 +6221,12 @@ \end{itemize*} \end{itemize*} - \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 + \item SSL ist als eine mehrschichtige und modulare Protokollarchitektur aufgebaut: - \begin{itemize*} \item Handshake: Authentifizierung und Aushandlung von Parametern \item Change Cipherspec: Signalisierung von Übergängen in der Verschlüsselungsstrategie @@ -8020,36 +6237,25 @@ \end{itemize*} \end{itemize*} - \subsection{SSL-Record-Protokoll} - % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-SSL-record-protocol.png} - \begin{itemize*} - \item - Inhaltstyp: - + \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 + \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: - + \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 @@ -8057,27 +6263,20 @@ \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: - + \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 + \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 + \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. @@ -8086,111 +6285,89 @@ \end{itemize*} \end{itemize*} - \subsection{SSL Handshake Protokoll: Vollständiger Handshake} - %\begin{longtable}[]{@{}lll@{}} % \toprule % Client & & Server\tabularnewline % \midrule % \endhead - % ClientHello & -\/-\/-\textgreater{} & \tabularnewline + % ClientHello & ---\textgreater{} & \tabularnewline % & & ServerHello\tabularnewline % & & {[}ServerCertificate{]}\tabularnewline % & & {[}CertificateRequest{]}\tabularnewline % & & {[}ServerKeyExchange{]}\tabularnewline - % & \textless-\/-\/- & ServerHelloDone\tabularnewline + % & \textless--- & ServerHelloDone\tabularnewline % {[}ClientCertificate{]} & & \tabularnewline % ClientKeyExchange & & \tabularnewline % {[}CertificateVerify{]} & & \tabularnewline % ChangeCipherSpec & & \tabularnewline - % Finished & -\/-\/-\textgreater{} & \tabularnewline + % Finished & ---\textgreater{} & \tabularnewline % & & ChangeCipherSpec\tabularnewline - % & \textless-\/-\/- & Finished\tabularnewline + % & \textless--- & Finished\tabularnewline % \bottomrule %\end{longtable} - {[}...{]} kennzeichnet optionale Nachrichten - \subsection{SSL Handshake Protokoll: Abgekürzter Handshake} - %\begin{longtable}[]{@{}lll@{}} % \toprule % Client & & Server\tabularnewline % \midrule % \endhead - % ClientHello(SessionID) & -\/-\/-\textgreater{} & \tabularnewline + % ClientHello(SessionID) & ---\textgreater{} & \tabularnewline % & & ServerHello(SessionID)\tabularnewline % & & ChangeCipherSpec\tabularnewline - % & \textless-\/-\/- & Finished\tabularnewline + % & \textless--- & Finished\tabularnewline % ChangeCipherSpec & & \tabularnewline - % Finished & -\/-\/-\textgreater{} & \tabularnewline + % Finished & ---\textgreater{} & \tabularnewline % \bottomrule %\end{longtable} - \begin{itemize*} - \item - Die Nachricht "Finished" enthält eine MAC, die entweder auf MD5 oder + \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 + \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: - + \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 + \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 + \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: - + \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 + \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 + \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 + \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{]} @@ -8199,9 +6376,7 @@ \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: - + \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: @@ -8210,30 +6385,23 @@ \end{itemize*} \end{itemize*} - \subsection{SSL Handshake Protokoll: Eine Sicherheitslücke} - \begin{itemize*} - \item - 1998 entdeckte D. Bleichenbacher eine Schwachstelle im + \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 + \item Wenn der Client das Pre-Master-Secret mit dem öffentlichen Schlüssel des Servers verschlüsselt, verwendet er PKCS \#1, um es vor der Verschlüsselung zu formatieren: - \begin{itemize*} - \item EM = 0x02 \textbar{} PS \textbar{} 0x00 \textbar{} M + \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{]}: - + \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 @@ -8245,9 +6413,7 @@ \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 Gegenmassnahmen: \begin{itemize*} \item Regelmäßiger Wechsel der öffentlichen Schlüsselpaare (\$\textbackslash Rightarrow\$-Overhead) \item Verringerung der Wahrscheinlichkeit, ,,gute'' Chiffriertexte zu erhalten, indem das Format der entschlüsselten Chiffriertexte gründlich überprüft und dem Client ein identisches Verhalten (Fehlermeldung, Zeitverhalten usw.) gezeigt wird @@ -8259,20 +6425,14 @@ \end{itemize*} \end{itemize*} - \subsection{SSL-Chiffre-Suiten} - \begin{itemize*} - \item - Kein Schutz (Standard-Suite): - + \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 + \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 \} @@ -8285,9 +6445,7 @@ \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 - + \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 \} @@ -8303,18 +6461,14 @@ \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 + \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 \} @@ -8322,53 +6476,40 @@ \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 Die letzte Cipher Suite ist für den Fortezza-Token: \begin{itemize*} \item SSL\_FORTEZZA\_DMS\_WITH\_NULL\_SHA = \{ 0x00,0x1C \} \item SSL\_FORTEZZA\_DMS\_WITH\_FORTEZZA\_CBC\_SHA = \{ 0x00,0x1D \} \end{itemize*} \end{itemize*} - (Diese Cipher-Suites müssen natürlich nicht auswendig gelernt werden und werden hier nur aufgeführt, um die Flexibilität des SSL-Protokolls zu verdeutlichen) - \subsection{Das Transport Layer Security-Protokoll} - \begin{itemize*} - \item - 1996 gründete die IETF eine Arbeitsgruppe zur Definition eines + \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 + \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 + \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): - + \item Ab TLS 1.2 (RFC 5246): \begin{itemize*} \item Schlüsselaustausch-Algorithmen: \begin{itemize*} \item DH oder ECDH Austausch ohne oder mit DSS / RSA / ECDSA Signaturen \item DH-Austausch mit zertifizierten öffentlichen DH-Parametern \item RSA-basierter Schlüsselaustausch \item keine \end{itemize*} @@ -8376,12 +6517,9 @@ \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 + \item Was die Protokollfunktionen betrifft, ist TLS im Wesentlichen dasselbe wie SSL - \item - Sicherheit: - + \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. @@ -8396,27 +6534,19 @@ \end{itemize*} \end{itemize*} - \subsection{Das Datagram Transport Layer Security Protokoll} - \begin{itemize*} - \item - TLS bietet sichere Kommunikation über ein zuverlässiges + \item TLS bietet sichere Kommunikation über ein zuverlässiges Transportprotokoll - \item - DTLS ist so angepasst, dass es über unzuverlässige Transportprotokolle + \item DTLS ist so angepasst, dass es über unzuverlässige Transportprotokolle wie z.B. UDP funktioniert - \item - Wird zum Schutz verwendet: - + \item Wird zum Schutz verwendet: \begin{itemize*} \item Sprach- und Videodaten in Echtzeit, insbesondere Voice-over-IP \item Getunnelte TCP-Daten (da TCP über TCP eine schlechte Idee für die Leistung ist) \end{itemize*} - \item - DTLS basiert derzeit auf TLS 1.2, enthält jedoch einige Änderungen: - + \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*} @@ -8427,43 +6557,30 @@ \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 + \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 + \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 + \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 + \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 + \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 + \item Da SSH jedoch auch ein allgemeines Sicherheitsprotokoll der Transportschicht enthält und Tunneling-Fähigkeiten bietet, wird es in diesem Kapitel als Sicherheitsprotokoll der Transportschicht behandelt \end{itemize*} - \subsection{SSH Version 2} - \begin{itemize*} - \item - SSH Version 2 ist in mehreren separaten Dokumenten spezifiziert, z.B.: - + \item SSH Version 2 ist in mehreren separaten Dokumenten spezifiziert, z.B.: \begin{itemize*} \item SSH Protocol Assigned Numbers {[}LL06{]} \item SSH-Protokollarchitektur {[}YL06a{]} @@ -8471,9 +6588,7 @@ \item SSH-Transportschichtprotokoll {[}YL06c{]} \item SSH-Verbindungsprotokoll {[}YL06d{]} \end{itemize*} - \item - SSH-Architektur: - + \item SSH-Architektur: \begin{itemize*} \item SSH verfolgt einen Client-Server-Ansatz \item Jeder SSH-Server hat mindestens einen Host-Schlüssel @@ -8483,25 +6598,18 @@ \end{itemize*} \end{itemize*} - \subsection{SSH-Transportprotokoll} - \begin{itemize*} - \item - SSH verwendet ein zuverlässiges Transportprotokoll (normalerweise + \item SSH verwendet ein zuverlässiges Transportprotokoll (normalerweise TCP). - \item - Es bietet die folgenden Dienste: - + \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: - + \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*} @@ -8513,39 +6621,28 @@ \end{itemize*} \end{itemize*} - \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: - + \item Das Paketformat ist nicht 32-Bit-wortorientiert + \item Felder des Pakets: \begin{itemize*} \item Paketlänge: die Länge des Pakets selbst, ohne dieses Längenfeld und den MAC \item Padding length: Länge des Padding-Feldes, muss zwischen vier und 255 liegen \item Payload: die eigentliche Nutzlast des Pakets, wenn Komprimierung ausgehandelt wurde, wird dieses Feld komprimiert \item Padding: dieses Feld besteht aus zufällig ausgewählten Oktetten, um die Nutzlast auf ein ganzzahliges Vielfaches von 8 oder der Blockgröße des Verschlüsselungsalgorithmus aufzufüllen, je nachdem, welcher Wert größer ist \item MAC: Wurde die Nachrichtenauthentifizierung ausgehandelt, enthält dieses Feld den MAC des gesamten Pakets ohne das MAC-Feld selbst; soll das Paket verschlüsselt werden, wird der MAC vor der Verschlüsselung wie folgt berechnet - \begin{itemize*} \item MAC = HMAC(shared\_secret, seq\_number \textbar\textbar{} unencrypted\_packet), wobei seq\_number eine 32-Bit-Sequenznummer für jedes Paket bezeichnet \end{itemize*} + \begin{itemize*} \item MAC = HMAC(shared\_secret, seq\_number \textbar| unencrypted\_packet), wobei seq\_number eine 32-Bit-Sequenznummer für jedes Paket bezeichnet \end{itemize*} \end{itemize*} - \item - Verschlüsselung: wenn Verschlüsselung ausgehandelt wird, wird das + \item Verschlüsselung: wenn Verschlüsselung ausgehandelt wird, wird das gesamte Paket ohne MAC nach der MAC-Berechnung verschlüsselt \end{itemize*} - \subsection{SSH-Aushandlung, Schlüsselaustausch und Server-Authentifizierung} - \begin{itemize*} - \item - Algorithmus-Aushandlung: - + \item Algorithmus-Aushandlung: \begin{itemize*} \item Jede Entität sendet ein Paket (bezeichnet als kexinit ) mit einer Spezifikation der von ihr unterstützten Methoden in der Reihenfolge ihrer Präferenz \item Beide Entitäten iterieren über die Liste des Clients und wählen den ersten Algorithmus, der auch vom Server unterstützt wird @@ -8554,17 +6651,13 @@ \item Ist eine Vermutung richtig, wird das entsprechende Schlüsselaustauschpaket als erstes Schlüsselaustauschpaket der anderen Entität akzeptiert \item Falsche Vermutungen werden ignoriert und neue Schlüsselaustauschpakete werden nach Aushandlung des Algorithmus gesendet \end{itemize*} - \item - Für den Schlüsselaustausch definiert {[}YL06c{]} nur eine Methode: - + \item Für den Schlüsselaustausch definiert {[}YL06c{]} nur eine Methode: \begin{itemize*} \item Diffie-Hellman mit SHA-1 und zwei vordefinierten Gruppen (1024 und 2048 Bit) \item Z.B. \$p = 2\^{}\{1024\} -2\^{}\{960\} - 1 + (2\^{}\{64\}\textbackslash times \textbackslash lfloor 2894 \textbackslash times \textbackslash pi + 129093\textbackslash rfloor); g = 2\$ \end{itemize*} - \item - Wenn der Schlüsselaustausch mit der vordefinierten DH-Gruppe + \item Wenn der Schlüsselaustausch mit der vordefinierten DH-Gruppe durchgeführt wird: - \begin{itemize*} \item Der Client wählt eine Zufallszahl \$x\$, berechnet \$e=g\^{}x\textbackslash{} mod\textbackslash{} p\$ und sendet \$e\$ an den Server \item Der Server wählt eine Zufallszahl \$y\$, errechnet \$f=g\^{}y\textbackslash{} mod\textbackslash{} p\$ @@ -8572,24 +6665,18 @@ \item Der Server signiert h mit seinem privaten Host-Schlüssel - KS und sendet dem Client eine Nachricht mit \$(+K\_S, f, s)\$. \item Beim Empfang prüft der Client den Host-Schlüssel \$+K\_S\$, berechnet \$K=f\^{}x\textbackslash{} mod\textbackslash{} p\$ sowie den Hash-Wert \$h\$ und prüft dann die Signatur \$s\$ über \$h\$ \end{itemize*} - \item - Nach diesen Prüfungen kann der Client sicher sein, dass er tatsächlich + \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 + \item Der Server-Host kann jedoch keine Rückschlüsse auf die Authentizität des Clients ziehen; zu diesem Zweck wird das SSH-Authentifizierungsprotokoll verwendet \end{itemize*} - \subsection{SSH-Sitzungsschlüssel-Ableitung} - \begin{itemize*} - \item - Die Methode des Schlüsselaustauschs ermöglicht es, ein gemeinsames + \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 @@ -8599,32 +6686,24 @@ \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 + \item Die Schlüsseldaten werden am Anfang der Hash-Ausgabe entnommen + \item Wenn mehr Schlüsselbits benötigt werden als von der Hash-Funktion erzeugt werden: - \begin{itemize*} \item K1 = Hash(K, h, x, session\_id) // x = ,,A'', ,,B'', usw. \item K2 = Hash(K, h, K1) \item K2 = Hash(K, h, K1, K2) - \item XK = K1 \textbar\textbar{} K2 \textbar\textbar{} ... + \item XK = K1 \textbar| K2 \textbar| ... \end{itemize*} \end{itemize*} - \subsection{SSH-Authentifizierungsprotokoll} - \begin{itemize*} - \item - Das SSH-Authentifizierungsprotokoll dient zur Überprüfung der + \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 + \item Das Protokoll unterstützt standardmäßig die folgenden Authentifizierungsmethoden: - \begin{itemize*} \item Öffentlicher Schlüssel: Der Benutzer erzeugt und sendet eine Signatur mit einem öffentlichen Schlüssel pro Benutzer an den Server \item \$Client\textbackslash rightarrow Server: E(-K\_\{Benutzer\}, (session\_id, 50, Name\_\{Benutzer\}, Service, ,,publickey'', True, PublicKeyAlgorithmName, +K\_\{Benutzer\}))\$ @@ -8632,40 +6711,31 @@ \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 + \item Wenn die Authentifizierungsnachricht des Clients erfolgreich geprüft wurde, antwortet der Server mit einer ssh\_msg\_userauth\_success-Nachricht \end{itemize*} - \subsection{SSH-Verbindungsprotokoll} - \begin{itemize*} - \item - Das SSH-Verbindungsprotokoll läuft auf dem SSH-Transportprotokoll und + \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 + \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: - + \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*} @@ -8674,72 +6744,56 @@ \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: - + \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: - + \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 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 + \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 + \item Beispiel 1 - Anfordern einer interaktiven Sitzung und Starten einer Shell darin: - \begin{itemize*} \item Zunächst wird ein Kanal vom Typ ,,session'' geöffnet \item Ein Pseudo-Terminal wird angefordert, indem eine ssh\_msg\_channel\_request-Nachricht gesendet wird, wobei der Anforderungstyp auf ,,pty-req'' gesetzt wird \item Falls erforderlich, können Umgebungsvariablen gesetzt werden, indem ssh\_msg\_channel\_request-Nachrichten mit dem Anforderungstyp ,,env'' gesendet werden. \item Dann wird der Start eines Shell-Prozesses über eine ssh\_msg\_channel\_request-Nachricht mit dem Request-Typ ,,shell'' gefordert (dies führt normalerweise zum Start der Standard-Shell für den Benutzer, wie sie in /etc/passwd definiert ist) - \item Anfordern einer interaktiven Sitzung und Starten einer Shell darin: \textbar{} SSH Client \textbar{} \textbar{} SSH Server \textbar{} \textbar{} -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{} -\/-\/-\/- \textbar{} -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{} \textbar{} ssh\_msg\_channel\_open (,,session'', 20, 2048, 512) \textbar{} -\/-\/-\textgreater{} \textbar{} \textbar{} \textbar{} \textless-\/-\/- \textbar{} ssh\_msg\_channel\_open\_confirmation(20, 31, 1024, 256) \textbar{} \textbar{} ssh\_msg\_channel\_request (31, ,,pty-req'', false, ...) \textbar{} -\/-\/-\textgreater{} \textbar{} \textbar{} ssh\_msg\_channel\_request (31, ,,env'', false, ,,home'', ,,/home/username'') \textbar{} -\/-\/-\textgreater{} \textbar{} \textbar{} ssh\_msg\_channel\_request (31, ,,shell'', true, ...) \textbar{} -\/-\/-\textgreater{} \textbar{} \textbar{} \textbar{} \textless-\/-\/- \textbar{} ssh\_msg\_channel\_success(20) \textbar{} + \item Anfordern einer interaktiven Sitzung und Starten einer Shell darin: | SSH Client | | SSH Server | | -------------------------------------------------------------------------- | ---- | ---------------------------------------------------- | | ssh\_msg\_channel\_open (,,session'', 20, 2048, 512) | ---\textgreater{} | | | \textless--- | ssh\_msg\_channel\_open\_confirmation(20, 31, 1024, 256) | | ssh\_msg\_channel\_request (31, ,,pty-req'', false, ...) | ---\textgreater{} | | ssh\_msg\_channel\_request (31, ,,env'', false, ,,home'', ,,/home/username'') | ---\textgreater{} | | ssh\_msg\_channel\_request (31, ,,shell'', true, ...) | ---\textgreater{} | | | \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: - + \item Beispiel 2 - Anforderung der X11-Weiterleitung: \begin{itemize*} \item Zuerst wird ein Kanal des Typs ,,session'' geöffnet \item Die X11-Weiterleitung wird durch Senden einer ssh\_msg\_channel\_request-Nachricht mit dem Anforderungstyp ,,x11-req'' angefordert \item Wenn später eine Anwendung auf dem Server gestartet wird, die auf das Terminal des Client-Rechners zugreifen muss (der X11-Server, der auf dem Client-Rechner läuft), wird ein neuer Kanal über ssh\_msg\_channel\_open geöffnet, wobei der Kanaltyp auf ,,x11'' und die IP-Adresse und Portnummer des Absenders als zusätzliche Parameter gesetzt werden \end{itemize*} - \item - Beispiel 3 - Einrichtung einer TCP/IP-Portweiterleitung: - + \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) @@ -8748,14 +6802,10 @@ \end{itemize*} \end{itemize*} - \subsection{Schlussfolgerung} - \begin{itemize*} - \item - Sowohl SSL, TLS als auch SSH eignen sich für die Sicherung der + \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 @@ -8766,23 +6816,17 @@ \end{itemize*} \end{itemize*} - \section{Sicherheitsaspekte der mobilen Kommunikation} - \begin{itemize*} - \item - Die mobile Kommunikation ist mit den gleichen Bedrohungen konfrontiert + \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 + \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*} @@ -8793,36 +6837,26 @@ \end{itemize*} \end{itemize*} - \subsection{Standortdatenschutz in Mobilfunknetzen} - \begin{itemize*} - \item - In den heutigen Mobilfunknetzen gibt es keinen angemessenen Schutz des + \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: - + \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 Das grundlegende Problem des Datenschutzes: \begin{itemize*} \item Ein mobiles Gerät sollte erreichbar sein \item Keine (einzelne) Entität im Netz sollte in der Lage sein, den Standort eines mobilen Geräts zu verfolgen \end{itemize*} - \item - Einige grundlegende Ansätze zur Lösung dieses Problems + \item Einige grundlegende Ansätze zur Lösung dieses Problems {[}Müller99a{]}: - \begin{itemize*} \item Broadcast von Nachrichten: \begin{itemize*} \item Jede Nachricht wird an jeden möglichen Empfänger gesendet \item Wenn Vertraulichkeit erforderlich ist, wird die Nachricht asymmetrisch verschlüsselt \item Dieser Ansatz ist nicht gut skalierbar für große Netzwerke / hohe Last \end{itemize*} @@ -8831,9 +6865,7 @@ \item Gemischte Netzwerke: \begin{itemize*} \item Nachrichten werden über verschiedene Entitäten (Mixes) geleitet und jede Entität kann nur einen Teil der Nachrichtenroute erfahren (siehe unten) \end{itemize*} \end{itemize*} - \item - Adressierungsschemata für standortbezogenen Datenschutz mit Broadcast: - + \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*} @@ -8895,32 +6927,25 @@ \subsection{IEEE 802.11} \begin{itemize*} - \item - IEEE 802.11 {[}IEEE12{]} standardisiert die Medienzugriffskontrolle + \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: - + \item Der Standard umfasst mehrere physikalische Schichteinheiten: \begin{itemize*} \item Derzeit zwischen 1-300 Mbit/s \item 2,4-GHz-Band und 5-GHz-Band \item Viele verschiedene Modulationsverfahren \end{itemize*} - \item - Die Übertragung im lizenzfreien 2,4-GHz-Band impliziert: - + \item Die Übertragung im lizenzfreien 2,4-GHz-Band impliziert: \begin{itemize*} \item Medium-Sharing mit unfreiwilligen 802.11-Geräten \item Überlappung von logisch getrennten Wireless LANs \item Überlappung mit Nicht-802.11-Geräten \end{itemize*} - \item - Die Medienzugriffskontrolle (MAC) unterstützt sowohl den Betrieb unter + \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 + \item In diesem Kurs werden wir uns hauptsächlich auf die (Un-)Sicherheitsaspekte des Standards konzentrieren! \end{itemize*} @@ -8928,19 +6953,14 @@ \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-802.11-network-architecture.png} - \item - Station (STA): Endgerät mit Zugriffsmechanismen auf das drahtlose + \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 + \item Basic Service Set (BSS): Gruppe von Stationen, die dieselbe Funkfrequenz verwenden - \item - Zugangspunkt: Station, die in das drahtlose LAN und das + \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 + \item Portal: Brücke zu anderen (kabelgebundenen) Netzwerken + \item Verteilungssystem: Verbindungsnetz zur Bildung eines logischen Netzes (Extended Service Set, ESS), das auf mehreren BSS basiert \end{itemize*} @@ -8948,42 +6968,32 @@ \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-802.11-ad-hoc-architecture.png} - \item - Station (STA): Endgerät mit Zugriffsmechanismen auf das drahtlose + \item Station (STA): Endgerät mit Zugriffsmechanismen auf das drahtlose Medium - \item - Basic Service Set (BSS): Gruppe von Stationen, die dieselbe + \item Basic Service Set (BSS): Gruppe von Stationen, die dieselbe Funkfrequenz verwenden - \item - Ad-Hoc-Netze ermöglichen die direkte Kommunikation zwischen + \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 + \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 + \item Die Sicherheitsdienste von IEEE 802.11 wurden ursprünglich wie folgt realisiert: - \begin{itemize*} \item Authentifizierungsdienst für Entitäten \item Wired Equivalent Privacy (WEP) Mechanismus \end{itemize*} - \item - WEP soll die folgenden Sicherheitsdienste bieten - + \item WEP soll die folgenden Sicherheitsdienste bieten \begin{itemize*} \item Vertraulichkeit \item Authentifizierung der Datenherkunft / Datenintegrität \item Zugangskontrolle in Verbindung mit Schichtenmanagement \end{itemize*} - \item - WEP verwendet die folgenden Algorithmen: - + \item WEP verwendet die folgenden Algorithmen: \begin{itemize*} \item Die RC4-Stromchiffre (siehe Kapitel 3) \item Die CRC-Prüfsumme (Cyclic Redundancy Code) zur Fehlererkennung @@ -8995,34 +7005,26 @@ Redundanzcode} \begin{itemize*} - \item - Der zyklische Redundanzcode (CRC) ist ein Fehlererkennungscode - \item - Mathematische Grundlage: - + \item Der zyklische Redundanzcode (CRC) ist ein Fehlererkennungscode + \item Mathematische Grundlage: \begin{itemize*} \item Bitstrings werden als Darstellungen von Polynomen mit den Koeffizienten 0 und 1 behandelt \$\textbackslash Rightarrow\$ Ein Bitstring, der eine Nachricht M darstellt, wird als M(x) interpretiert \item Polynomarithmetik wird modulo 2 durchgeführt \$\textbackslash Rightarrow\$ Addition und Subtraktion sind identisch mit XOR \end{itemize*} - \item - CRC-Berechnung für eine Nachricht \$M(x)\$: - + \item CRC-Berechnung für eine Nachricht \$M(x)\$: \begin{itemize*} \item A und B einigen sich auf ein Polynom \$G(x)\$; üblicherweise ist \$G(x)\$ standardisiert \item Sei \$n\$ der Grad von \$G(x)\$, d.h. die Länge von \$G(x)\$ sei \$n+1\$ \item Wenn dann \$\textbackslash frac\{M(x)\textbackslash times 2\^{}n\}\{G(x)\}=Q(x)+\textbackslash frac\{R(x)\}\{G(x)\}\$ gilt \$\textbackslash frac\{M(x)\textbackslash times 2\^{}n +R(x)\}\{G(x)\}\$ wobei \$R(x)\$ der Rest von \$M(x)\$ geteilt durch \$G(x)\$ ist \item Normalerweise wird \$R(x)\$ vor der Übertragung an \$M(x)\$ angehängt, und \$Q(x)\$ ist nicht von Interesse, da es nur geprüft wird, wenn \$\textbackslash frac\{M(x)\textbackslash times 2\^{}n+R(x)\}\{G(x)\}\$ mit Rest \$0\$ dividiert \end{itemize*} - \item - Betrachten wir nun zwei Nachrichten \$M\_1\$ und \$M\_2\$ mit CRCs + \item Betrachten wir nun zwei Nachrichten \$M\_1\$ und \$M\_2\$ mit CRCs \$R\_1\$ und \$R\_2\$: - \begin{itemize*} \item Da \$\textbackslash frac\{M\_1(x)\textbackslash times 2\^{}n+R\_1(x)\}\{G(x)\}\$ und \$\textbackslash frac\{M\_2(x)\textbackslash times 2\^{}n+R\_2(x)\}\{G(x)\}\$ mit dem Rest \$0\$ teilen, teilt sich auch \$\textbackslash frac\{M\_1(x)\textbackslash times 2\^{}n +R\_1(x)+M\_2(x)\textbackslash times 2\^{}n +R\_2(x)\}\{G(x)\} =\textbackslash frac\{(M\_1(x)+M\_2(x))\textbackslash times 2\^{}n +(R\_1(x)+R\_2(x))\}\{G(x)\}\$ teilt mit Rest \$0\$ \item \$\textbackslash Rightarrow\$ CRC ist linear, d.h. \$CRC(M\_1 + M\_2) = CRC(M\_1) + CRC(M\_2)\$ \end{itemize*} - \item - Diese Eigenschaft macht CRC schwach für kryptographische Zwecke! + \item Diese Eigenschaft macht CRC schwach für kryptographische Zwecke! \end{itemize*} @@ -9030,10 +7032,8 @@ Entity-Authentifizierung} \begin{itemize*} - \item - Ursprünglich gibt es die IEEE 802.11-Authentifizierung in zwei + \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: @@ -9044,16 +7044,12 @@ IEEE 802.11's Shared Key Authentication Dialog: \begin{itemize*} - \item - Die Authentifizierung sollte zwischen Stationen und Zugangspunkten + \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 + \item Bei der Authentifizierung fungiert eine Station als Requestor (A) und die andere als Responder (B) - \item - Der Authentifizierungsdialog: - + \item Der Authentifizierungsdialog: \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$A \textbackslash rightarrow B: (Authentifizierung, 1, ID\_A)\$ @@ -9061,11 +7057,9 @@ \item \$A \textbackslash rightarrow B: \{Authentifizierung, 3, r\_B\}\emph{\{K}\{A,B\}\}\$ \item \$B \textbackslash rightarrow A: (Authentifizierung, 4, erfolgreich)\$ \end{enumerate*} - \item - Die gegenseitige Authentifizierung erfordert zwei unabhängige + \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 + \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*} @@ -9075,21 +7069,17 @@ Privacy} \begin{itemize*} - \item - IEEE 802.11's WEP verwendet RC4 als Pseudo-Zufallsbit-Generator + \item IEEE 802.11's WEP verwendet RC4 als Pseudo-Zufallsbit-Generator (PRNG): - \begin{itemize*} \item Für jede zu schützende Nachricht M wird ein 24-Bit-Initialisierungsvektor (IV) mit dem gemeinsamen Schlüssel \$K\_\{BSS\}\$ verkettet, um den Seed des PRNG zu bilden. \item Der Integritätsprüfwert (ICV) von M wird mit CRC berechnet und an die Nachricht angehängt (,,\textbar\textbar'') - \item Die resultierende Nachricht \$(M \textbar\textbar{} ICV)\$ wird mit dem von \$RC4(IV \textbar\textbar{} K\_\{BSS\})\$ erzeugten Schlüsselstrom XOR-verknüpft (,,\$\textbackslash oplus\$'') + \item Die resultierende Nachricht \$(M \textbar| ICV)\$ wird mit dem von \$RC4(IV \textbar| K\_\{BSS\})\$ erzeugten Schlüsselstrom XOR-verknüpft (,,\$\textbackslash 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 + \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: @@ -9102,10 +7092,8 @@ 802.11} \begin{itemize*} - \item - WEP wurde entwickelt, um die folgenden Sicherheitseigenschaften zu + \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*} @@ -9114,8 +7102,7 @@ \item Zugriffskontrolle in Verbindung mit Schichtenmanagement: \begin{itemize*} \item Wenn in der Schichtenverwaltung so eingestellt, werden nur WEP-geschützte Nachrichten von Empfängern akzeptiert \item Somit können Stationen, die \$K\_\{BSS\}\$ nicht kennen, nicht an solche Empfänger senden \end{itemize*} \end{itemize*} - \item - Leider trifft keine der obigen Behauptungen zu... + \item Leider trifft keine der obigen Behauptungen zu... \end{itemize*} @@ -9123,18 +7110,14 @@ Schlüssel} \begin{itemize*} - \item - IEEE 802.11 sieht keine Schlüsselverwaltung vor: - + \item IEEE 802.11 sieht keine Schlüsselverwaltung vor: \begin{itemize*} \item Manuelle Verwaltung ist fehleranfällig und unsicher \item Die gemeinsame Verwendung eines Schlüssels für alle Stationen eines BSS führt zu zusätzlichen Sicherheitsproblemen \item Als Folge der manuellen Schlüsselverwaltung werden die Schlüssel selten geändert. \item Eine weitere Folge ist, dass die ,,Sicherheit'' oft sogar ausgeschaltet ist! \end{itemize*} - \item - Schlüssellänge: - + \item Schlüssellänge: \begin{itemize*} \item Die im ursprünglichen Standard festgelegte Schlüssellänge von 40 Bit bietet nur geringe Sicherheit \item Der Grund dafür war die Exportierbarkeit @@ -9147,11 +7130,8 @@ 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: - + \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: @@ -9159,9 +7139,7 @@ \item Wenn also ein Angreifer z.B. \$P\_1\$ und \$C\_1\$ kennt, kann er \$P\_2\$ aus \$C\_2\$ wiederherstellen, ohne den Schlüssel \$K\_\{BSS\}\$ zu kennen. \begin{itemize*} \item Kryptographen nennen dies einen Angriff mit bekanntem Klartext \end{itemize*} \end{itemize*} - \item - Wie oft kommt die Wiederverwendung des Schlüsselstroms vor? - + \item Wie oft kommt die Wiederverwendung des Schlüsselstroms vor? \begin{itemize*} \item In der Praxis recht häufig, da viele Implementierungen die IV schlecht wählen \item Selbst bei optimaler Wahl, da die IV-Länge 24 Bit beträgt, wird eine stark ausgelastete Basisstation eines 11-Mbit/s-WLAN den verfügbaren Speicherplatz in einem halben Tag erschöpfen @@ -9173,21 +7151,16 @@ unsicher} \begin{itemize*} - \item - Erinnern Sie sich, dass CRC eine lineare Funktion ist und RC4 + \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 + \item Nehmen wir an, A sendet eine verschlüsselte Nachricht an B, die von einem Angreifer E abgefangen wird: - \begin{itemize*} \item \$A \textbackslash rightarrow B: (IV, C) mit C = RC4(IV, K\_\{BSS\}) \textbackslash oplus (M, CRC(M))\$ \end{itemize*} - \item - Der Angreifer E kann einen neuen Chiffretext \$C'\$ konstruieren, der + \item Der Angreifer E kann einen neuen Chiffretext \$C'\$ konstruieren, der zu einer Nachricht \$M'\$ mit einer gültigen Prüfsumme \$CRC(M')\$ entschlüsselt wird: - \begin{itemize*} \item E wählt eine beliebige Nachricht \$\textbackslash delta\$ mit der gleichen Länge \item \$C' = C \textbackslash oplus (\textbackslash delta, CRC(\textbackslash delta)) = RC4(IV, K\_\{BSS\}) \textbackslash oplus (M, CRC(M)) \textbackslash oplus (\textbackslash delta, CRC(\textbackslash delta))\$ @@ -9205,13 +7178,10 @@ unsicher} \begin{itemize*} - \item - Erinnern Sie sich, dass die Integritätsfunktion ohne einen Schlüssel + \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 + \item Betrachten wir einen Angreifer, der ein Klartext-Chiffretext-Paar in Erfahrung bringt: - \begin{itemize*} \item Da der Angreifer \$M\$ und \$C=RC4(IV, K\_\{BSS\})\textbackslash oplus (M, CRC(M))\$ kennt, kann er den zur Erzeugung von \$C\$ verwendeten Schlüsselstrom berechnen \item Wenn \$E\$ später eine Nachricht \$M'\$ senden will, kann er \$C' = RC4(IV, K\_\{BSS\})\textbackslash oplus (M', CRC(M'))\$ berechnen und die Nachricht \$(IV, C')\$ senden. @@ -9219,8 +7189,7 @@ \item Eine ,,Anwendung'' für diesen Angriff ist die unbefugte Nutzung von Netzwerkressourcen: \begin{itemize*} \item Der Angreifer sendet IP-Pakete, die für das Internet bestimmt sind, an den Zugangspunkt, der sie entsprechend weiterleitet und dem Angreifer freien Zugang zum Internet gewährt \end{itemize*} \end{itemize*} - \item - \$\textbackslash Rightarrow\$ WEP Access Control kann mit bekanntem + \item \$\textbackslash Rightarrow\$ WEP Access Control kann mit bekanntem Klartext umgangen werden \end{itemize*} @@ -9229,9 +7198,7 @@ RC4-Schlüsselberechnung} \begin{itemize*} - \item - Anfang August 2001 wurde ein weiterer Angriff auf WEP entdeckt: - + \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: @@ -9247,9 +7214,7 @@ 802.11} \begin{itemize*} - \item - Das ursprüngliche IEEE 802.11 bietet keine ausreichende Sicherheit: - + \item Das ursprüngliche IEEE 802.11 bietet keine ausreichende Sicherheit: \begin{itemize*} \item Fehlende Schlüsselverwaltung macht die Nutzung der Sicherheitsmechanismen mühsam und führt dazu, dass die Schlüssel selten gewechselt werden oder sogar die Sicherheit ausgeschaltet ist \item Sowohl die Entity-Authentifizierung als auch die Verschlüsselung beruhen auf einem Schlüssel, der von allen Stationen eines Basisdienstes gemeinsam genutzt wird @@ -9259,12 +7224,9 @@ \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 + \item Selbst mit IEEE 802.1X und individuellen Schlüsseln bleibt das Protokoll schwach - \item - Einige vorgeschlagene Gegenmaßnahmen: - + \item Einige vorgeschlagene Gegenmaßnahmen: \begin{itemize*} \item Platzieren Sie Ihr IEEE 802.11 Netzwerk außerhalb Ihrer Internet Firewall \item Vertrauen Sie keinem Host, der über IEEE 802.11 verbunden ist. @@ -9280,13 +7242,10 @@ erwarten? \begin{itemize*} - \item - Bei den meisten Hotspots: Leider fast keine! - \item - Wenn Sie außer der Eingabe eines Benutzernamens und eines Passworts + \item Bei den meisten Hotspots: Leider fast keine! + \item Wenn Sie außer der Eingabe eines Benutzernamens und eines Passworts auf einer Webseite keine weiteren Sicherheitsparameter konfigurieren müssen, können Sie Folgendes erwarten: - \begin{itemize*} \item Der Hotspot-Betreiber prüft Ihre Authentizität bei der Anmeldung (oft mit SSL geschützt, um das Abhören Ihres Passworts zu verhindern) \item Nur authentifizierte Clients erhalten den Dienst, da die Paketfilterung den Zugriff auf die Anmeldeseite nur bei erfolgreicher Authentifizierung zulässt. @@ -9295,8 +7254,7 @@ \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 + \item Konsequenz: bessere WLAN-Sicherheit ist dringend erforderlich \end{itemize*} @@ -9304,26 +7262,19 @@ WPA} \begin{itemize*} - \item - Umfang: Definition der Interaktion zwischen 802.1X und 802.11 + \item Umfang: Definition der Interaktion zwischen 802.1X und 802.11 Standards - \item - TGi definiert zwei Klassen von Sicherheitsalgorithmen für 802.11: - + \item TGi definiert zwei Klassen von Sicherheitsalgorithmen für 802.11: \begin{itemize*} \item Pre-RSN Sicherheitsnetzwerk (\textbackslash rightarrow WEP) \item Robustes Sicherheitsnetzwerk (RSN) \end{itemize*} - \item - Die RSN-Sicherheit besteht aus zwei grundlegenden Teilsystemen: - + \item Die RSN-Sicherheit besteht aus zwei grundlegenden Teilsystemen: \begin{itemize*} \item Mechanismen zum Schutz der Daten: \begin{itemize*} \item TKIP - schnelles Re-Keying, um WEP für ein Minimum an Datenschutz zu verbessern (Marketingname WPA) \item AES-Verschlüsselung - robuster Datenschutz für lange Zeit (Marketingname WPA2) \end{itemize*} \end{itemize*} - \item - Verwaltung von Sicherheitsvereinbarungen: - + \item Verwaltung von Sicherheitsvereinbarungen: \begin{itemize*} \item Unternehmensmodus - basierend auf 802.1X \item Persönlicher Modus - basierend auf Pre-Shared Keys @@ -9336,32 +7287,24 @@ \subsection{WPA-Schlüsselverwaltung} \begin{itemize*} - \item - Im Gegensatz zum ursprünglichen 802.11: paarweise Schlüssel zwischen + \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) - + \item Das erste Geheimnis: der 256 Bit Pairwise Master Key (PMK) \begin{itemize*} \item Unternehmensmodus: Verwendet 802.1X-Authentifizierung und installiert einen neuen Schlüssel, der BS und Client bekannt ist, z. B. durch EAP-TTLS \item Persönlicher Modus: Verwendet einen Pre-Shared Key (PSK), der dem BS und vielen STAs bekannt ist. \begin{itemize*} \item Explizit durch 64 zufällige Hex-Zeichen oder implizit durch ein Passwort gegeben \item Wenn Passwort: PMK = PBKDF2(Passwort, SSID, 4096, 256) \item Wobei PBKDF2 die passwortbasierte Schlüsselableitungsfunktion 2 aus {[}RFC2898{]} mit einer Salz-SSID und einer Ausgangslänge von 256 Bit ist \item impliziert 2 * 4096 Berechnungen von HMAC-SHA1, um Brute-Force zu verlangsamen \end{itemize*} \end{itemize*} - \item - PMK ist ein Vertrauensanker für die Authentifizierung per EAPOL (EAP + \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 + \item Für aktuelle kryptographische Protokolle wird ein kurzzeitiger 512 Bit Pairwise Transient Key (PTK) wie folgt generiert - \begin{itemize*} - \item \$PTK = PRF(PMK, ,,Paarweise Schlüsselerweiterung'', min(Addr\_\{BS\}, Addr\_\{STA\}) \textbar\textbar{} max(Addr\_\{BS\}, Addr\_\{STA\}) \textbar\textbar{} min(r\_\{BS\}, r\_\{STA\}) \textbar\textbar{} max(r\_\{BS\}, r\_\{STA\}))\$ - \item Dabei ist \$PRF(K, A, B)\$ die verkettete Ausgabe von \$HMAC-SHA1(K, A \textbar\textbar{} '0' \textbar\textbar{} B \textbar\textbar{} i)\$ über einen laufenden Index i + \item \$PTK = PRF(PMK, ,,Paarweise Schlüsselerweiterung'', min(Addr\_\{BS\}, Addr\_\{STA\}) \textbar| max(Addr\_\{BS\}, Addr\_\{STA\}) \textbar| min(r\_\{BS\}, r\_\{STA\}) \textbar| max(r\_\{BS\}, r\_\{STA\}))\$ + \item Dabei ist \$PRF(K, A, B)\$ die verkettete Ausgabe von \$HMAC-SHA1(K, A \textbar| '0' \textbar| B \textbar| i)\$ über einen laufenden Index i \end{itemize*} - \item - Der PTK wird aufgeteilt in: - + \item Der PTK wird aufgeteilt in: \begin{itemize*} \item EAPOL-Schlüssel-Bestätigungsschlüssel (KCK, erste 128 Bits), \begin{itemize*} \item Wird zum Schutz der Integrität von EAPOL-Nachrichten verwendet \item Durch HMAC-MD5 (veraltet), HMAC-SHA1-128, AES-128-CMAC \end{itemize*} @@ -9369,15 +7312,13 @@ \begin{itemize*} \item Wird zur Verschlüsselung neuer Schlüssel in EAPOL-Nachrichten verwendet \item Mit RC4 (veraltet), AES im Key Wrap Mode {[}RFC3394{]} \end{itemize*} \item Ein Temporal Key (TK) zum Schutz des Datenverkehrs (ab Bit 256)! \end{itemize*} - \item - Initialer Dialog mit BS: - + \item Initialer Dialog mit BS: \begin{itemize*} \item EAPOL (EAP over LAN) 4-Wege-Handshake wird verwendet, um \begin{itemize*} \item Überprüfung der gegenseitigen Kenntnis des PMK \item Initiiert durch BS, um Schlüssel zu installieren (gruppenweise und paarweise) \end{itemize*} \item Vereinfachter Handshake funktioniert wie folgt: \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$BS\textbackslash rightarrow STA: (1, r\_\{BS\} , PMKID, install\textbackslash{} new\textbackslash{} PTK)\$ \item \$STA BS: (2, r\_\{STA\}, MAC\_\{KCK\})\$ \item \$BS STA: (3, r\_\{BS\}, MAC\_\{KCK\}, \{TK\}\_\{KEK\})\$ \item \$STA BS: (4, r\_\{STA\}, MAC\_\{KCK\})\$ \end{enumerate*} - \item Wobei PMKID den PMK identifiziert: obere 128 Bit von \$HMAC-SHA-256(PMK, "PMK Name" \textbar\textbar{} Addr\_\{BS\} \textbar\textbar{} Addr\_\{STA\} )\$ + \item Wobei PMKID den PMK identifiziert: obere 128 Bit von \$HMAC-SHA-256(PMK, "PMK Name" \textbar| Addr\_\{BS\} \textbar| Addr\_\{STA\} )\$ \end{itemize*} \end{itemize*} @@ -9386,18 +7327,14 @@ Protokoll} \begin{itemize*} - \item - Ziele des Entwurfs: - + \item Ziele des Entwurfs: \begin{itemize*} \item Schnelle Lösung für das bestehende WEP-Problem, betreibt WEP als Unterkomponente \item Kann in Software implementiert werden, nutzt vorhandene WEP-Hardware wieder \item Anforderungen an vorhandene AP-Hardware: \begin{itemize*} \item 33 oder 25 MHz ARM7 oder i486, die bereits vor TKIP mit 90\% CPU-Auslastung laufen \item Nur als Software/Firmware-Upgrade gedacht \item Keine unangemessene Beeinträchtigung der Leistung \end{itemize*} \end{itemize*} - \item - Wichtigste Konzepte: - + \item Wichtigste Konzepte: \begin{itemize*} \item Nachrichtenintegritätscode (MIC) \item Gegenmaßnahmen im Falle von MIC-Fehlern @@ -9405,8 +7342,7 @@ \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 + \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*} @@ -9414,9 +7350,7 @@ Message Integrity Code Funktion Michael \begin{itemize*} - \item - Schützt vor Fälschungen: - + \item Schützt vor Fälschungen: \begin{itemize*} \item Muss billig sein: CPU-Budget 5 Anweisungen / Byte \item Leider schwach: ein \$2\^{}\{29\}\$ Nachrichtenangriff existiert @@ -9431,17 +7365,13 @@ Wiederholungsschutz und RC4-Schlüsselplanung \begin{itemize*} - \item - Replay-Schutz: - + \item Replay-Schutz: \begin{itemize*} \item Zurücksetzen der Paket-Sequenz \# auf 0 bei Wiederholung \item Erhöhen der Sequenz \# um 1 bei jedem Paket \item Verwerfen aller Pakete, die außerhalb der Sequenz empfangen werden \end{itemize*} - \item - Umgehen Sie die Schwächen der WEP-Verschlüsselung: - + \item Umgehen Sie die Schwächen der WEP-Verschlüsselung: \begin{itemize*} \item Erstellen Sie einen besseren paketweisen Verschlüsselungsschlüssel, indem Sie Angriffe mit schwachen Schlüsseln verhindern und WEP IV und paketweisen Schlüssel dekorrelieren \item muss auf vorhandener Hardware effizient sein @@ -9460,9 +7390,7 @@ WLAN-Schutz} \begin{itemize*} - \item - Zählermodus mit CBC-MAC (CCMP): - + \item Zählermodus mit CBC-MAC (CCMP): \begin{itemize*} \item Obligatorisch zu implementieren: die langfristige Lösung \item Ein völlig neues Protokoll mit wenigen Zugeständnissen an WEP @@ -9539,20 +7467,20 @@ \end{itemize*} \end{itemize*} - Einige GSM-Abkürzungen \textbar{} \textbar{} \textbar{} \textbar{} - -\/-\/-\/-\/-\/- \textbar{} - -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- - \textbar{} \textbar{} AuC \textbar{} Authentication center \textbar{} - \textbar{} BSC \textbar{} Basisstations-Controller \textbar{} \textbar{} - BTS \textbar{} Basis-Transceiver-Station \textbar{} \textbar{} IMSI - \textbar{} Internationale mobile Teilnehmerkennung \textbar{} \textbar{} - HLR \textbar{} Heimatstandortregister \textbar{} \textbar{} LAI - \textbar{} Standortbereichskennung \textbar{} \textbar{} MS \textbar{} - Mobile Station (z. B. ein Mobiltelefon) \textbar{} \textbar{} MSC - \textbar{} Mobile Vermittlungsstelle \textbar{} \textbar{} MSISDN - \textbar{} Mobile subscriber international ISDN number \textbar{} - \textbar{} TMSI \textbar{} Temporäre mobile Teilnehmerkennung \textbar{} - \textbar{} VLR \textbar{} Register für Besucherstandorte \textbar{} + Einige GSM-Abkürzungen | | | | + ------ | + ------------------------------------------- + | | AuC | Authentication center | + | BSC | Basisstations-Controller | | + BTS | Basis-Transceiver-Station | | IMSI + | Internationale mobile Teilnehmerkennung | | + HLR | Heimatstandortregister | | LAI + | Standortbereichskennung | | MS | + Mobile Station (z. B. ein Mobiltelefon) | | MSC + | Mobile Vermittlungsstelle | | MSISDN + | Mobile subscriber international ISDN number | + | TMSI | Temporäre mobile Teilnehmerkennung | + | VLR | Register für Besucherstandorte | % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-gsm-authentication.png} @@ -9582,9 +7510,7 @@ \item \$K\_\{BSC,MS\} = A8(K\_\{AUC,MS\}, R\_\{AUC\});\$ A8 ist ein Algorithmus \item \$R\_\{AUC\}, SRES\_\{AUC\}\$ sind Arrays mit mehreren Werten \end{itemize*} - \item - Dialog zur Wiederauthentifizierung mit demselben VLR: - + \item Dialog zur Wiederauthentifizierung mit demselben VLR: \begin{enumerate*} \def\labelenumi{\arabic{enumi}.} \item \$MS \textbackslash rightarrow VLR: (LAI\_1 , TMSI\_\{MS:n\})\$ @@ -9637,16 +7563,12 @@ (GPRS)} \begin{itemize*} - \item - GPRS (General Packet Radio Service, allgemeiner Paketfunkdienst): - + \item GPRS (General Packet Radio Service, allgemeiner Paketfunkdienst): \begin{itemize*} \item Datenübertragung in GSM-Netzen auf der Basis von Paketvermittlung \item Nutzung freier Slots der Funkkanäle nur bei sendebereiten Datenpaketen (z.B. 115 kbit/s bei temporärer Nutzung von 8 Slots) \end{itemize*} - \item - GPRS-Netzelemente: - + \item GPRS-Netzelemente: \begin{itemize*} \item GGSN (Gateway GPRS Support Node): Interworking-Einheit zwischen GPRS und PDN (Packet Data Network) \item SGSN (Serving GPRS Support Node): Unterstützt die MS (Standort, Abrechnung, Sicherheit, entspricht im Grunde dem MSC) @@ -9661,26 +7583,20 @@ % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-gprs-protocol-architecture.png} \begin{itemize*} - \item - SNDCP: Subnetwork Dependent Convergence Protocol - \item - GTP: GPRS Tunnelling Protocol + \item SNDCP: Subnetwork Dependent Convergence Protocol + \item GTP: GPRS Tunnelling Protocol \end{itemize*} GPRS-Sicherheit \begin{itemize*} - \item - Sicherheitsziele: - + \item Sicherheitsziele: \begin{itemize*} \item Schutz vor unbefugter Nutzung des GPRS-Dienstes (Authentifizierung) \item Gewährleistung der Vertraulichkeit der Benutzeridentität (temporäre Identifizierung und Verschlüsselung) \item Gewährleistung der Vertraulichkeit von Benutzerdaten (Verschlüsselung) \end{itemize*} - \item - Realisierung von Sicherheitsdiensten: - + \item Realisierung von Sicherheitsdiensten: \begin{itemize*} \item Die Authentifizierung ist grundsätzlich identisch mit der GSM-Authentifizierung: \begin{itemize*} \item SGSN ist die Peer-Entität \item Zwei separate temporäre Identitäten werden für GSM/GPRS verwendet \item Nach erfolgreicher Authentifizierung wird die Verschlüsselung eingeschaltet \end{itemize*} @@ -9694,8 +7610,7 @@ % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-gprs-handover-execution.png} \begin{itemize*} - \item - GPRS unterstützt ein ,,optimiertes Handover'' einschließlich + \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*} @@ -9708,18 +7623,13 @@ \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 + \item Netzzugangssicherheit: Schutz vor Angriffen auf die Funkschnittstelle + \item Sicherheit der Netzdomäne: Schutz vor Angriffen auf das drahtgebundene Netz - \item - Sicherheit der Benutzerdomäne: sicherer Zugang zu den Mobilstationen - \item - Sicherheit der Anwendungsdomäne: sicherer Nachrichtenaustausch für + \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 + \item Sichtbarkeit und Konfigurierbarkeit der Sicherheit: Information des Benutzers über den sicheren Betrieb \end{enumerate*} @@ -9728,65 +7638,49 @@ UMTS-Sicherheitsarchitektur} \begin{itemize*} - \item - Sicherheit beim Netzzugang: Derzeit der am weitesten entwickelte Teil + \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 + \item Netzbereichssicherheit: Dieser Teil ist größtenteils noch ausbaufähig (in Spezifikationen bis Release 5) - \item - Sicherheit der Benutzerdomäne: - + \item Sicherheit der Benutzerdomäne: \begin{itemize*} \item Verlangt grundsätzlich, dass sich der Benutzer gegenüber seinem User Services Identity Module (USIM) authentifiziert, z.B. durch Eingabe einer PIN \item Optional kann ein Terminal die Authentifizierung des USIM verlangen. \end{itemize*} - \item - Anwendungsbereichssicherheit: - + \item Anwendungsbereichssicherheit: \begin{itemize*} \item Definiert ein Sicherheitsprotokoll, das zwischen den auf dem Endgerät/USIM laufenden Anwendungen und einem System im Netz verwendet wird (3GPP TS 23.048) \item Liegt etwas außerhalb des Bereichs der Mobilfunksicherheit \end{itemize*} - \item - Sichtbarkeit und Konfigurierbarkeit der Sicherheit: Definiert + \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 + \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 @@ -9825,16 +7719,15 @@ \begin{itemize*} \item Für jeden Benutzer führt die HE/AuC einen Zähler \$SQN\_\{HE\}\$ \end{itemize*} \item Ein Authentifizierungs- und Schlüsselverwaltungsfeld AMF ist im Authentifizierungs-Token jedes Authentifizierungsvektors enthalten. \item Anschließend werden die folgenden Werte berechnet: - \begin{itemize*} \item ein Nachrichtenauthentifizierungscode \$MAC = f1\_K(SQN \textbar\textbar{} RAND \textbar\textbar{} AMF)\$, wobei f1 eine Nachrichtenauthentifizierungsfunktion ist \item eine erwartete Antwort \$XRES = f2\_K(RAND)\$, wobei f2 eine (möglicherweise verkürzte) Nachrichtenauthentifizierungsfunktion ist \item ein Chiffrierschlüssel \$CK = f3\_K(RAND)\$, wobei f3 eine Schlüsselerzeugungsfunktion ist \item ein Integritätsschlüssel \$IK = f4\_K(RAND)\$, wobei f4 eine Schlüsselerzeugungsfunktion ist \item ein Anonymitätsschlüssel \$AK = f5\_K(RAND)\$, wobei f5 eine Schlüsselerzeugungsfunktion ist \end{itemize*} - \item Schließlich wird das Authentifizierungstoken \$AUTN = SQN \textbackslash oplus AK \textbar\textbar{} AMF \textbar\textbar{} MAC\$ konstruiert + \begin{itemize*} \item ein Nachrichtenauthentifizierungscode \$MAC = f1\_K(SQN \textbar| RAND \textbar| AMF)\$, wobei f1 eine Nachrichtenauthentifizierungsfunktion ist \item eine erwartete Antwort \$XRES = f2\_K(RAND)\$, wobei f2 eine (möglicherweise verkürzte) Nachrichtenauthentifizierungsfunktion ist \item ein Chiffrierschlüssel \$CK = f3\_K(RAND)\$, wobei f3 eine Schlüsselerzeugungsfunktion ist \item ein Integritätsschlüssel \$IK = f4\_K(RAND)\$, wobei f4 eine Schlüsselerzeugungsfunktion ist \item ein Anonymitätsschlüssel \$AK = f5\_K(RAND)\$, wobei f5 eine Schlüsselerzeugungsfunktion ist \end{itemize*} + \item Schließlich wird das Authentifizierungstoken \$AUTN = SQN \textbackslash oplus AK \textbar| AMF \textbar| MAC\$ konstruiert \end{itemize*} %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-umts-user-authentication-usim.png} - \begin{itemize*} \item Nach Erhalt von RAND und AUTN berechnet das USIM: \item berechnet es den Anonymitätsschlüssel \$AK = f5\_K (RAND)\$ \item ruft die Sequenznummer \$SQN = (SQN \textbackslash oplus AK) \textbackslash oplus AK\$ ab - \item errechnet \$XMAC = f1\_K (SQN \textbar\textbar{} RAND \textbar\textbar{} AMF)\$ und + \item errechnet \$XMAC = f1\_K (SQN \textbar| RAND \textbar| AMF)\$ und \item vergleicht dies mit MAC, das in AUTN enthalten ist \item Wenn sie unterschiedlich sind, sendet der Benutzer die Ablehnung der Benutzerauthentifizierung mit Angabe der Ursache an den VLR/SGSN zurück, und der Benutzer bricht das Verfahren ab. \item Wenn die MAC korrekt ist, prüft das USIM, ob die empfangene Sequenznummer SQN im richtigen Bereich liegt: @@ -9849,10 +7742,8 @@ Release'99} \begin{itemize*} - \item - Die Sicherheit von UMTS Release '99 ist der Sicherheit von GSM sehr + \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. @@ -9862,8 +7753,7 @@ \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 + \item Zusammenfassend lässt sich sagen, dass UMTS Release'99 genauso sicher sein soll wie ein unsicheres Festnetz \end{itemize*} @@ -9871,26 +7761,20 @@ \subsection{Sicherheit in LTE-Netzen} \begin{itemize*} - \item - Eine Weiterentwicklung von UMTS, so dass viele der Sicherheitskonzepte + \item Eine Weiterentwicklung von UMTS, so dass viele der Sicherheitskonzepte gleich geblieben sind - \begin{itemize*} \item Das Protokoll zur Authentifizierung und Schlüsselvereinbarung (AKA) ist im Wesentlichen dasselbe wie bei UMTS. \item Allerdings wird ein Master Key KASME abgeleitet, der dann zur Ableitung von Integritäts- und Verschlüsselungsschlüsseln verwendet wird \end{itemize*} - \item - Bemerkenswerte Unterschiede: - + \item Bemerkenswerte Unterschiede: \begin{itemize*} \item GSM-SIMs dürfen nicht mehr auf das Netz zugreifen \item KASUMI wird nicht mehr verwendet, stattdessen werden SNOW, AES oder ZUC (ein chinesischer Stream Cipher, der für LTE entwickelt wurde) eingesetzt \item Das zugehörige Festnetz (Evolved Packet Core genannt) ist vollständig paketvermittelt und normalerweise durch IPsec und IKEv2 geschützt. \item Heim-eNBs \end{itemize*} - \item - Allerdings oft neue Namen für sehr ähnliche Dinge, z.B., - + \item Allerdings oft neue Namen für sehr ähnliche Dinge, z.B., \begin{itemize*} \item Anstelle der TMSI wird eine Globally Unique Temporary Identity (GUTI) verwendet, die aus Folgendem besteht: \begin{itemize*} \item Einer PLMN-ID, MMEI und einer M-TMSI \item Damit werden das Public Land Mobile Network (PLMN), die Mobility Management Entity (MME), vergleichbar mit der MSC in GSM/UMTS, und das mobile Gerät (M-TMSI) identifiziert \end{itemize*}