\documentclass[a4paper]{article}
\usepackage[ngerman]{babel}
\usepackage[utf8]{inputenc}
\usepackage{multicol}
\usepackage{calc}
\usepackage{ifthen}
\usepackage[landscape]{geometry}
\usepackage{amsmath,amsthm,amsfonts,amssymb}
\usepackage{color,graphicx,overpic}
\usepackage{xcolor, listings}
\usepackage[compact]{titlesec} %less space for headers
\usepackage{mdwlist} %less space for lists
\usepackage{pdflscape}
\usepackage{verbatim}
\usepackage[most]{tcolorbox}
\usepackage[hidelinks,pdfencoding=auto]{hyperref}
\usepackage{bussproofs}
\usepackage{fancyhdr}
\usepackage{lastpage}
\pagestyle{fancy}
\fancyhf{}
\fancyhead[L]{Network Security}
\fancyfoot[L]{\thepage/\pageref{LastPage}}
\renewcommand{\headrulewidth}{0pt} %obere Trennlinie
\renewcommand{\footrulewidth}{0pt} %untere Trennlinie

\pdfinfo{
 /Title (Network Security - Cheatsheet)
 /Creator (TeX)
 /Producer (pdfTeX 1.40.0)
 /Author (Robert Jeutter)
 /Subject ()
}

%%% Code Listings
\definecolor{codegreen}{rgb}{0,0.6,0}
\definecolor{codegray}{rgb}{0.5,0.5,0.5}
\definecolor{codepurple}{rgb}{0.58,0,0.82}
\definecolor{backcolour}{rgb}{0.95,0.95,0.92}
\lstdefinestyle{mystyle}{
 backgroundcolor=\color{backcolour}, 
 commentstyle=\color{codegreen},
 keywordstyle=\color{magenta},
 numberstyle=\tiny\color{codegray},
 stringstyle=\color{codepurple},
 basicstyle=\ttfamily,
 breakatwhitespace=false, 
}
\lstset{style=mystyle, upquote=true}

%textmarker style from colorbox doc
\tcbset{textmarker/.style={%
 enhanced,
 parbox=false,boxrule=0mm,boxsep=0mm,arc=0mm,
 outer arc=0mm,left=2mm,right=2mm,top=3pt,bottom=3pt,
 toptitle=1mm,bottomtitle=1mm,oversize}}

% define new colorboxes
\newtcolorbox{hintBox}{textmarker,
 borderline west={6pt}{0pt}{yellow},
 colback=yellow!10!white}
\newtcolorbox{importantBox}{textmarker,
 borderline west={6pt}{0pt}{red},
 colback=red!10!white}
\newtcolorbox{noteBox}{textmarker,
 borderline west={3pt}{0pt}{green},
 colback=green!10!white}

% define commands for easy access
\renewcommand{\note}[2]{\begin{noteBox} \textbf{#1} #2 \end{noteBox}}
\newcommand{\warning}[1]{\begin{hintBox} \textbf{Warning:} #1 \end{hintBox}}
\newcommand{\important}[1]{\begin{importantBox} \textbf{Important:} #1 \end{importantBox}}

% This sets page margins to .5 inch if using letter paper, and to 1cm
% if using A4 paper. (This probably isn't strictly necessary.)
% If using another size paper, use default 1cm margins.
\ifthenelse{\lengthtest { \paperwidth = 11in}}
 { \geometry{top=.5in,left=.5in,right=.5in,bottom=.5in} }
 {\ifthenelse{ \lengthtest{ \paperwidth = 297mm}}
 {\geometry{top=1.3cm,left=1cm,right=1cm,bottom=1.2cm} }
 {\geometry{top=1.3cm,left=1cm,right=1cm,bottom=1.2cm} }
 }

% Redefine section commands to use less space
\makeatletter
\renewcommand{\section}{\@startsection{section}{1}{0mm}%
 {-1ex plus -.5ex minus -.2ex}%
 {0.5ex plus .2ex}%x
 {\normalfont\large\bfseries}}
\renewcommand{\subsection}{\@startsection{subsection}{2}{0mm}%
 {-1explus -.5ex minus -.2ex}%
 {0.5ex plus .2ex}%
 {\normalfont\normalsize\bfseries}}
\renewcommand{\subsubsection}{\@startsection{subsubsection}{3}{0mm}%
 {-1ex plus -.5ex minus -.2ex}%
 {1ex plus .2ex}%
 {\normalfont\small\bfseries}}
\makeatother

% Don't print section numbers
\setcounter{secnumdepth}{0}

\setlength{\parindent}{0pt}
\setlength{\parskip}{0pt plus 0.5ex} 
% compress space
\setlength\abovedisplayskip{0pt}
\setlength{\parskip}{0pt}
\setlength{\parsep}{0pt}
\setlength{\topskip}{0pt}
\setlength{\topsep}{0pt}
\setlength{\partopsep}{0pt}
\linespread{0.5}
\titlespacing{\section}{0pt}{*0}{*0}
\titlespacing{\subsection}{0pt}{*0}{*0}
\titlespacing{\subsubsection}{0pt}{*0}{*0}

\begin{document}

\raggedright
\begin{multicols}{3}\scriptsize
    % multicol parameters
    % These lengths are set only within the two main columns
    %\setlength{\columnseprule}{0.25pt}
    \setlength{\premulticols}{1pt}
    \setlength{\postmulticols}{1pt}
    \setlength{\multicolsep}{1pt}
    \setlength{\columnsep}{2pt}

    \section{Einleitung}
    \subsection{Was ist eine Bedrohung in einem  Kommunikationsnetz?}

    \begin{itemize}
        \item Abstrakte Definition
              \begin{itemize}
                  \item
                        Eine Bedrohung in einem Kommunikationsnetz ist ein mögliches
                        Ereignis oder eine Folge von Aktionen, die zu einer Verletzung eines
                        oder mehrerer Sicherheitsziele führen können.
                  \item
                        Die tatsächliche Realisierung einer Bedrohung wird als Angriff
                        bezeichnet.
              \end{itemize}
        \item
              Beispiele

              \begin{itemize}
                  \item
                        Ein Hacker bricht in einen Firmencomputer ein
                  \item
                        Offenlegung von E-Mails während der Übertragung
                  \item
                        Jemand ändert Finanzbuchhaltungsdaten
                  \item
                        Ein Hacker, der eine Website vorübergehend außer Betrieb setzt
                  \item
                        Jemand, der Dienstleistungen in Anspruch nimmt oder Waren im Namen
                        anderer bestellt
              \end{itemize}
        \item
              Was sind Sicherheitsziele?

              \begin{itemize}
                  \item
                        Sicherheitsziele können definiert werden
                  \item
                        in Abhängigkeit von der Anwendungsumgebung oder
                  \item
                        auf eine allgemeinere, technische Weise
              \end{itemize}
    \end{itemize}


    \subsection{Sicherheitsziele in Abhängigkeit von der
        Anwendungsumgebung}

    \begin{itemize}
        \item
              Bankwesen

              \begin{itemize}
                  \item
                        Schutz vor betrügerischen oder versehentlichen Änderungen von
                        Transaktionen
                  \item
                        Identifizierung von Kunden bei Privatkundentransaktionen
                  \item
                        Schutz von PINs vor Offenlegung
                  \item
                        Sicherstellung der Privatsphäre der Kunden
              \end{itemize}
        \item
              Elektronischer Handel

              \begin{itemize}
                  \item
                        Sicherstellung der Herkunft und Integrität von Transaktionen
                  \item
                        Schutz der Privatsphäre von Unternehmen
                  \item
                        Rechtsverbindliche elektronische Signaturen für Transaktionen
                        bereitstellen
              \end{itemize}
        \item
              Regierung

              \begin{itemize}
                  \item
                        Schutz vor Offenlegung sensibler Informationen
                  \item
                        Bereitstellung elektronischer Signaturen für Regierungsdokumente
              \end{itemize}
        \item
              Öffentliche Telekommunikationsanbieter

              \begin{itemize}
                  \item
                        Beschränken Sie den Zugang zu Verwaltungsfunktionen auf
                        autorisiertes Personal
                  \item
                        Schutz vor Dienstunterbrechungen
                  \item
                        Schutz der Privatsphäre der Teilnehmer
              \end{itemize}
        \item
              Firmen-/Privatnetzwerke

              \begin{itemize}
                  \item
                        Schutz der Privatsphäre von Unternehmen/Personen
                  \item
                        Sicherstellung der Authentizität von Nachrichten
              \end{itemize}
        \item
              Alle Netzwerke

              \begin{itemize}
                  \item
                        Verhinderung des Eindringens von außen (wer will schon Hacker?)
              \end{itemize}
        \item
              Manchmal werden Sicherheitsziele auch als Sicherheitsvorgaben
              bezeichnet
    \end{itemize}


    \subsection{Sicherheitsziele technisch
        definiert}

    \begin{itemize}
        \item
              \textbf{Vertraulichkeit (Confidentiality)}

              \begin{itemize}
                  \item
                        Übertragene oder gespeicherte Daten sollten nur einem bestimmten
                        Personenkreis zugänglich gemacht werden.
                  \item
                        Die Vertraulichkeit von Entitäten wird auch als Anonymität
                        bezeichnet.
              \end{itemize}
        \item
              \textbf{Integrität der Daten (Data Integrity)}

              \begin{itemize}
                  \item
                        Es sollte möglich sein, jede Veränderung von Daten zu erkennen.
                  \item
                        Dies setzt voraus, dass der Ersteller bestimmter Daten identifiziert
                        werden kann.
              \end{itemize}
        \item
              \textbf{Rechenschaftspflicht (Accountability)}

              \begin{itemize}
                  \item
                        Es sollte möglich sein, die für ein Kommunikationsereignis
                        verantwortliche Stelle zu identifizieren.
              \end{itemize}
        \item
              \textbf{Verfügbarkeit (Availability)}

              \begin{itemize}
                  \item
                        Die Dienste sollten verfügbar sein und korrekt funktionieren.
              \end{itemize}
        \item
              \textbf{Kontrollierter Zugang (Controlled Access)}

              \begin{itemize}
                  \item
                        Nur autorisierte Stellen sollten auf bestimmte Dienste oder
                        Informationen zugreifen können.
              \end{itemize}
    \end{itemize}


    \subsection{Technisch definierte
        Bedrohungen}

    \begin{itemize}
        \item
              \textbf{Maskerade (oder Man-in-the-Middle-Angriff, Masquerade)}

              \begin{itemize}
                  \item
                        Eine Entität gibt sich als eine andere Entität aus
              \end{itemize}
        \item
              \textbf{Lauschangriff (Eavesdropping)}

              \begin{itemize}
                  \item
                        Eine Entität liest Informationen, die sie nicht lesen soll
              \end{itemize}
        \item
              \textbf{Verletzung der Berechtigung (Authorization Violation)}

              \begin{itemize}
                  \item
                        Eine Entität nutzt einen Dienst oder Ressourcen, für die sie nicht
                        vorgesehen ist
              \end{itemize}
        \item
              \textbf{Verlust oder Veränderung} von (übertragenen) Informationen
              (Loss or Modification of (transmitted) Information)

              \begin{itemize}
                  \item
                        Daten werden verändert oder zerstört
              \end{itemize}
        \item
              \textbf{Verweigerung von Kommunikationsakten (Denial of Communication
                  Acts, Repudiation)}

              \begin{itemize}
                  \item
                        Ein Unternehmen leugnet fälschlicherweise seine Teilnahme an einer
                        Kommunikationshandlung
              \end{itemize}
        \item
              \textbf{Fälschung von Informationen (Forgery of Information)}

              \begin{itemize}
                  \item
                        Ein Unternehmen erstellt neue Informationen im Namen eines anderen
                        Unternehmens
              \end{itemize}
        \item
              \textbf{Sabotage (oder Denial-of-Service-Angriffe)}

              \begin{itemize}
                  \item
                        Jede Aktion, die darauf abzielt, die Verfügbarkeit und/oder das
                        ordnungsgemäße Funktionieren von Diensten oder Systemen zu
                        beeinträchtigen.
              \end{itemize}
    \end{itemize}


    \subsection{Bedrohungen und technische
        Sicherheitsziele}

    Diese Bedrohungen werden oft kombiniert, um einen Angriff durchzuführen!

    %\begin{longtable}[]{@{}llllllll@{}}
    %    \toprule
    %    Technische Sicherheitsziele & Maskerade                                        & Abhören       &
    %    Autorisierungsverletzung    & Verlust oder Modifikation von (übertragenen)
    %    Informationen               & Denial of Communication-Aktionen                 & Fälschung von
    %    Informationen               & Sabotage (z.B. durch Überlastung)\tabularnewline
    %    \midrule
    %    \endhead
    %    Vertraulichkeit             & x                                                & x             & x &   &   &   & \tabularnewline
    %    Datenintegrität             & x                                                &               & x & x & x & x & \tabularnewline
    %    Rechenschaftspflicht        & x                                                &               & x &   & x & x & \tabularnewline
    %    Verfügbarkeit               & x                                                &               & x & x &   &   & x\tabularnewline
    %    Kontrollierter Zugriff      & x                                                &               & x &   &   & x & \tabularnewline
    %    \bottomrule
    %\end{longtable}


    \subsection{Analyse der
        Netzwerksicherheit}

    \begin{itemize}
        \item
              Um geeignete Gegenmaßnahmen gegen Bedrohungen ergreifen zu können,
              müssen diese für eine gegebene Netzkonfiguration angemessen bewertet
              werden.
        \item
              Daher ist eine detaillierte Netzsicherheitsanalyse erforderlich, die

              \begin{itemize}
                  \item
                        das Risikopotenzial der allgemeinen Bedrohungen für die ein Netz
                        nutzenden Einheiten bewertet und
                  \item
                        den Aufwand (Ressourcen, Zeit usw.) abschätzt, der zur Durchführung
                        bekannter Angriffe erforderlich ist.
                  \item
                        Achtung! Es ist im Allgemeinen unmöglich, unbekannte Angriffe zu
                        bewerten!
              \end{itemize}
        \item
              Eine detaillierte Sicherheitsanalyse einer bestimmten
              Netzkonfiguration / spezifischen Protokollarchitektur

              \begin{itemize}
                  \item
                        kann auch erforderlich sein, um die Finanzkontrolleure eines
                        Unternehmens davon zu überzeugen, Mittel für
                        Sicherheitsverbesserungen bereitzustellen, und
                  \item
                        kann besser nach den feinkörnigeren Angriffen auf der
                        Nachrichtenebene strukturiert werden.
              \end{itemize}
    \end{itemize}


    \subsection{Angriffe auf die Kommunikation auf der
        Nachrichtenebene}

    \begin{itemize}
        \item
              Passive Angriffe

              \begin{itemize}
                  \item
                        Lauschangriff
              \end{itemize}
        \item
              Aktive Angriffe

              \begin{itemize}
                  \item
                        Verzögerung von PDUs (Protocol Data Units)
                  \item
                        Wiederholung von PDUs
                  \item
                        Löschung von PDUs
                  \item
                        Modifikation von PDUs
                  \item
                        Einfügung von PDUs
              \end{itemize}
        \item
              Die erfolgreiche Durchführung eines der oben genannten Angriffe
              erfordert

              \begin{itemize}
                  \item
                        Es gibt keine erkennbaren Nebeneffekte auf andere Kommunikationen
                        (Verbindungen/verbindungslose Übertragungen)
                  \item
                        Es gibt keine Nebenwirkungen auf andere PDUs der gleichen
                        Verbindung/verbindungslosen Datenübertragung zwischen den gleichen
                        Entitäten
              \end{itemize}
        \item
              Eine Sicherheitsanalyse einer Protokollarchitektur muss diese Angriffe
              entsprechend den Schichten der Architektur analysieren
    \end{itemize}


    \subsection{Schutzmaßnahmen gegen Bedrohungen der
        Informationssicherheit}

    \begin{itemize}
        \item
              Physische Sicherheit

              \begin{itemize}
                  \item
                        Schlösser oder andere physische Zugangskontrollen
                  \item
                        Manipulationssicherung empfindlicher Geräte
                  \item
                        Umweltkontrollen
              \end{itemize}
        \item
              Personelle Sicherheit

              \begin{itemize}
                  \item
                        Identifizierung von sensiblen Positionen
                  \item
                        Verfahren zur Überprüfung der Mitarbeiter
                  \item
                        Sicherheitsschulung und -bewusstsein
              \end{itemize}
        \item
              Administrative Sicherheit

              \begin{itemize}
                  \item
                        Kontrolle des Imports von Fremdsoftware
                  \item
                        Verfahren zur Untersuchung von Sicherheitsverstößen
                  \item
                        Überprüfung von Prüfpfaden
                  \item
                        Überprüfung von Kontrollen der Rechenschaftspflicht
              \end{itemize}
        \item
              Strahlungssicherheit

              \begin{itemize}
                  \item
                        Kontrolle von Funkfrequenzen und anderen elektromagnetischen
                        Abstrahlungen
                  \item
                        Bezeichnet als TEMPEST-Schutz
              \end{itemize}
        \item
              Mediensicherheit

              \begin{itemize}
                  \item
                        Absicherung der Speicherung von Informationen
                  \item
                        Kontrolle der Kennzeichnung, Vervielfältigung und Vernichtung von
                        sensiblen Informationen
                  \item
                        Sicherstellen, dass Medien mit sensiblen Informationen sicher
                        vernichtet werden
                  \item
                        Scannen von Medien auf Viren
              \end{itemize}
        \item
              Lebenszyklus-Kontrollen

              \begin{itemize}
                  \item
                        Vertrauenswürdiger Systementwurf, -implementierung, -bewertung und
                        -übernahme
                  \item
                        Programmierstandards und -kontrollen
                  \item
                        Kontrollen der Dokumentation
              \end{itemize}
        \item
              Computer-Sicherheit

              \begin{itemize}
                  \item
                        Schutz von Informationen während der Speicherung/Verarbeitung in
                        einem Computersystem
                  \item
                        Schutz der Datenverarbeitungsgeräte selbst
              \end{itemize}
        \item
              Sicherheit der Kommunikation

              \begin{itemize}
                  \item
                        Schutz von Informationen während des Transports von einem System zu
                        einem anderen
                  \item
                        Schutz der Kommunikationsinfrastruktur selbst
              \end{itemize}
    \end{itemize}


    \subsection{Kommunikationssicherheit: Einige
        Terminologie}

    \begin{itemize}
        \item
              Sicherheitsdienst

              \begin{itemize}
                  \item
                        Ein abstrakter Dienst, der eine bestimmte Sicherheitseigenschaft
                        gewährleisten soll.
                  \item
                        Ein Sicherheitsdienst kann sowohl mit Hilfe von kryptografischen
                        Algorithmen und Protokollen als auch mit herkömmlichen Mitteln
                        realisiert werden

                        \begin{itemize}
                            \item
                                  Man kann ein elektronisches Dokument auf einem USB-Stick
                                  vertraulich halten, indem man es in einem verschlüsselten Format
                                  auf dem Datenträger speichert und den Datenträger in einem Tresor
                                  wegschließt.
                            \item
                                  In der Regel ist eine Kombination aus kryptografischen und anderen
                                  Mitteln am effektivsten
                        \end{itemize}
              \end{itemize}
        \item
              Kryptographischer Algorithmus

              \begin{itemize}
                  \item
                        Eine mathematische Umwandlung von Eingabedaten (z. B. Daten,
                        Schlüssel) in Ausgabedaten
                  \item
                        Kryptografische Algorithmen werden in kryptografischen Protokollen
                        verwendet.
              \end{itemize}
        \item
              Kryptografisches Protokoll

              \begin{itemize}
                  \item
                        Eine Reihe von Schritten und der Austausch von Nachrichten zwischen
                        mehreren Einheiten, um ein bestimmtes Sicherheitsziel zu erreichen
              \end{itemize}
    \end{itemize}


    \subsection{Sicherheitsdienste -
        Überblick}

    \begin{itemize}
        \item
              \textbf{Authentifizierung (Authentication)}

              \begin{itemize}
                  \item
                        Der grundlegendste Sicherheitsdienst, der sicherstellt, dass eine
                        Entität tatsächlich die Identität besitzt, die sie vorgibt zu haben
              \end{itemize}
        \item
              \textbf{Integrität (Integrity)}

              \begin{itemize}
                  \item
                        In gewisser Weise der "kleine Bruder" des
                        Authentifizierungsdienstes, da er sicherstellt, dass Daten, die von
                        bestimmten Entitäten erstellt wurden, nicht unentdeckt verändert
                        werden können
              \end{itemize}
        \item
              \textbf{Vertraulichkeit (Confidentiality)}

              \begin{itemize}
                  \item
                        Der beliebteste Sicherheitsdienst, der die Geheimhaltung der
                        geschützten Daten gewährleistet
              \end{itemize}
        \item
              \textbf{Zugriffskontrolle (Access Control)}

              \begin{itemize}
                  \item
                        Kontrolliert, dass jede Identität nur auf die Dienste und
                        Informationen zugreift, zu denen sie berechtigt ist
              \end{itemize}
        \item
              \textbf{Nicht-Abstreitbarkeit (Non Repudiation)}

              \begin{itemize}
                  \item
                        Schützt davor, dass an einem Kommunikationsaustausch beteiligte
                        Entitäten später fälschlicherweise abstreiten können, dass der
                        Austausch stattgefunden hat
              \end{itemize}
    \end{itemize}


    \subsection{Sicherheitsunterstützende
        Mechanismen}

    \begin{itemize}
        \item
              Allgemeine Mechanismen

              \begin{itemize}
                  \item
                        Schlüsselverwaltung: Alle Aspekte des Lebenszyklus von
                        kryptografischen Schlüsseln
                  \item
                        Zufallszahlengenerierung: Generierung von kryptographisch sicheren
                        Zufallszahlen
                  \item
                        Ereigniserkennung / Sicherheitsprüfpfad: Erkennung und Aufzeichnung
                        von Ereignissen, die zur Erkennung von Angriffen oder Bedingungen,
                        die von Angriffen ausgenutzt werden könnten, verwendet werden können
                  \item
                        Erkennung von Eindringlingen: Analyse der aufgezeichneten
                        Sicherheitsdaten, um erfolgreiche Einbrüche oder Angriffe zu
                        erkennen
                  \item
                        Beglaubigung: Registrierung von Daten durch eine vertrauenswürdige
                        dritte Partei, die später bestimmte Eigenschaften (Inhalt,
                        Ersteller, Erstellungszeitpunkt) der Daten bestätigen kann
              \end{itemize}
        \item
              Kommunikationsspezifische Mechanismen

              \begin{itemize}
                  \item
                        Traffic Padding \& Cover Traffic: Erzeugung von gefälschtem Verkehr,
                        um die Analyse des Verkehrsflusses zu verhindern
                  \item
                        Routing-Kontrolle: Beeinflussung des Routings von PDUs in einem
                        Netzwerk
              \end{itemize}
    \end{itemize}


    \subsection{Kryptologie - Definition und
        Terminologie}

    \begin{itemize}
        \item
              Kryptologie

              \begin{itemize}
                  \item
                        Wissenschaft, die sich mit sicherer und meist geheimer Kommunikation
                        beschäftigt
                  \item
                        Der Begriff leitet sich von den griechischen Wörtern kryptós
                        (verborgen) und lógos (Wort) ab.
                  \item
                        Kryptologie umfasst

                        \begin{itemize}
                            \item
                                  Kryptographie ( gráphein = schreiben): die Lehre von den
                                  Prinzipien und Techniken, mit denen Informationen in
                                  verschlüsseltem Text verborgen und später von legitimen Nutzern
                                  mit Hilfe eines geheimen Schlüssels offengelegt werden können
                            \item
                                  Kryptoanalyse ( analýein = lýsen, losbinden): die Wissenschaft
                                  (und Kunst) der Wiedergewinnung von Informationen aus Chiffren
                                  ohne Kenntnis des Schlýssels
                        \end{itemize}
              \end{itemize}
        \item
              Chiffre (Quelle Encyclopaedia Britannica)

              \begin{itemize}
                  \item
                        Methode zur Umwandlung einer Nachricht (Klartext), um ihre Bedeutung
                        zu verschleiern
                  \item
                        Wird auch als Synonym für den verborgenen Chiffretext verwendet.
                  \item
                        Chiffren sind eine Klasse von kryptografischen Algorithmen
                  \item
                        Die Umwandlung erfolgt in der Regel mit der Nachricht und einem
                        (geheimen) Schlüssel als Eingabe
              \end{itemize}
    \end{itemize}


    \subsection{Kryptologie - einige historische
        Anmerkungen}

    \begin{itemize}
        \item
              400 v. Chr.: Die Spartaner verwenden ein Chiffriergerät namens Scytale
              für die Kommunikation zwischen militärischen Befehlshabern.

              \begin{itemize}
                  \item
                        Die Scytale bestand aus einem spitz zulaufenden Stab, um den
                        spiralförmig ein Streifen Pergament oder Leder gewickelt war, auf
                        den die Nachricht geschrieben wurde
                  \item
                        Beim Aufwickeln wurden die Buchstaben der Reihe nach durcheinander
                        gewürfelt und bildeten die Chiffre.
                  \item
                        Wurde der Streifen um einen anderen Stab mit den gleichen
                        Proportionen wie das Original gewickelt, kam der Klartext wieder zum
                        Vorschein
              \end{itemize}
        \item
              Im 4. Jahrhundert v. Chr:

              \begin{itemize}
                  \item
                        Aeneas Tacticus (Grieche) schreibt "Über die Verteidigung von
                        Festungen", wobei ein Kapitel der Kryptographie gewidmet ist
                  \item
                        Polybius (Grieche) erfindet eine Methode zur Kodierung von
                        Buchstaben in Symbolpaaren mit Hilfe eines Geräts namens
                        Polybius-Schachbrett, das eine bi-literale Substitution ermöglicht
                        und viele Elemente späterer Kryptosysteme vorwegnimmt
              \end{itemize}
        \item
              Die Römer verwendeten eine monoalphabetische Substitution mit
              einfacher zyklischer Verschiebung des Alphabets:

              \begin{itemize}
                  \item
                        Julius Caesar verwendete eine Verschiebung von drei Buchstaben (A
                        ergibt D, ..., Z ergibt C)
                  \item
                        Augustus Caesar verwendete eine einzige Verschiebung (A ergibt B,
                        ...)
              \end{itemize}
        \item
              Die Araber waren die ersten, die die Prinzipien der Kryptographie
              verstanden und die Anfänge der Kryptoanalyse entdeckten:

              \begin{itemize}
                  \item
                        Entwurf und Verwendung von Substitutions- und
                        Transpositions-Chiffren
                  \item
                        Entdeckung der Verwendung von Buchstabenhäufigkeitsverteilungen und
                        wahrscheinlichen Klartexten in der Kryptoanalyse
                  \item
                        Bis 1412 n. Chr. enthält Al-Kalka-Shandi in seiner Enzyklopädie Subh
                        al-a'sha eine elementare und respektable Behandlung mehrerer
                        kryptographischer Systeme und ihrer Kryptoanalyse
              \end{itemize}
        \item
              Europäische Kryptographie:

              \begin{itemize}
                  \item
                        Die Entwicklung begann im Kirchenstaat und in den italienischen
                        Stadtstaaten im Mittelalter
                  \item
                        Die ersten Chiffren verwendeten nur Vokalsubstitutionen
                  \item
                        1397: Gabriele de Lavinde von Parma verfasst das erste europäische
                        Handbuch zur Kryptographie, das eine Zusammenstellung von Chiffren
                        sowie eine Reihe von Schlüsseln für 24 Korrespondenten enthält und
                        Symbole für Buchstaben, Zahlen und mehrere zweistellige
                        Codeäquivalente für Wörter und Namen umfasst
                  \item
                        Code-Vokabulare, Nomenklatoren genannt, wurden für mehrere
                        Jahrhunderte zur Hauptstütze der diplomatischen Kommunikation der
                        meisten europäischen Regierungen
                  \item
                        1470: Leon Battista Alberti veröffentlicht Trattati In Cifra, in
                        denen er die erste Chiffrierscheibe beschreibt und bereits
                        vorschreibt, die Scheibe regelmäßig neu einzustellen, wobei er den
                        Begriff der Polyalphabetizität entwickelt
                  \item
                        1563: Giambattista della Porta liefert eine abgewandelte Form einer
                        quadratischen Tabelle und das früheste Beispiel einer digraphischen
                        Chiffre (2-Buchstaben-Substitution)
                  \item
                        1586: Blaise de Vigenère veröffentlicht Traicté des chiffres, das
                        die ihm zugeschriebene quadratische Tabelle enthält
                  \item
                        Bis 1860 wurden große Codes für die diplomatische Kommunikation
                        verwendet, und Chiffren wurden nur in der militärischen
                        Kommunikation eingesetzt (außer auf hoher Kommandoebene), da es
                        schwierig war, Codebücher im Feld zu schützen.
              \end{itemize}
        \item
              Entwicklungen während der Weltkriege 1 und 2:

              \begin{itemize}
                  \item
                        Während des 1. Weltkriegs: Chiffriersysteme wurden hauptsächlich für
                        die taktische Kommunikation verwendet und die Kommunikation auf
                        hoher Ebene wurde durch Codes geschützt.
                  \item
                        1920: Die Kommunikationsbedürfnisse der Telekommunikation und die
                        Weiterentwicklung der elektromechanischen Technik führen zu einer
                        wahren Revolution bei den Verschlüsselungsgeräten - der Entwicklung
                        von Rotor-Chiffriermaschinen:

                        \begin{itemize}
                            \item
                                  Das Rotorprinzip wird unabhängig voneinander von E. E. Hebern
                                  (USA), H. A. Koch (Niederlande) und A. Scherbius (Deutschland)
                                  entdeckt
                            \item
                                  Rotor-Chiffriermaschinen kaskadieren eine Sammlung von
                                  Chiffrierscheiben, um eine polyalphabetische Substitution von
                                  hoher Komplexität zu realisieren
                            \item
                                  Die Kryptoanalyse der taktischen Kommunikation spielt während des
                                  Zweiten Weltkriegs eine sehr wichtige Rolle. Die größten Erfolge
                                  sind die britische und polnische Lösung der deutschen Enigma- und
                                  der beiden Fernschreiber-Chiffren sowie die amerikanische
                                  Kryptoanalyse der japanischen Chiffren.
                        \end{itemize}
              \end{itemize}
        \item
              Entwicklungen nach dem 2. Weltkrieg:

              \begin{itemize}
                  \item
                        Die moderne Elektronik ermöglicht noch komplexere Chiffren, die
                        zunächst den Rotorprinzipien folgen (und deren Schwächen
                        einbeziehen)
                  \item
                        Die meisten Informationen über elektronische Chiffriermaschinen, die
                        von verschiedenen nationalen Kryptodiensten verwendet wurden, sind
                        nicht öffentlich zugänglich.
                  \item
                        Ende der 1960er Jahre war die kommerziell verfügbare Kryptographie
                        kaum bekannt, und starke Kryptographie war den nationalen Behörden
                        vorbehalten
                  \item
                        1973-1977: Entwicklung des Data Encryption Standard (DES)
                  \item
                        1976-1978: Entdeckung der Public-Key-Kryptografie
                  \item
                        1976: W. Diffie und M. Hellman veröffentlichen "New Directions in
                        Cryptography" (Neue Wege in der Kryptographie), in dem sie die
                        Konzepte der Public-Key-Kryptographie einführen und ein Verfahren
                        zum Austausch von Schlüsseln über unsichere Kanäle beschreiben.
                  \item
                        R. Merkle entdeckt unabhängig das Prinzip des öffentlichen
                        Schlüssels, seine ersten Veröffentlichungen erscheinen jedoch erst
                        1978, da der Veröffentlichungsprozess langsam ist
                  \item
                        1978: R. L. Rivest, A. Shamir und A. M. Adleman veröffentlichen "A
                        Method for Obtaining Digital Signatures and Public Key
                        Cryptosystems", das den ersten funktionierenden und sicheren
                        Public-Key-Algorithmus RSA enthält
              \end{itemize}
    \end{itemize}


    \section{Grundlagen der
      Kryptographie}

    \begin{itemize}
        \item
              Überblick über kryptografische Algorithmen
        \item
              Angriffe auf die Kryptographie
        \item
              Eigenschaften von Verschlüsselungsalgorithmen
        \item
              Klassifizierung von Verschlüsselungsalgorithmen
    \end{itemize}


    \subsection{Kryptographische Algorithmen:
        Überblick}

    \begin{itemize}
        \item
              In diesem Kurs stehen zwei Hauptanwendungen kryptographischer
              Algorithmen im Mittelpunkt des Interesses

              \begin{itemize}
                  \item
                        Verschlüsselung von Daten: Umwandlung von Klartextdaten in
                        Chiffretext, um deren Bedeutung zu verbergen
                  \item
                        Signierung von Daten: Berechnung eines Prüfwerts oder einer
                        digitalen Signatur für einen gegebenen Klartext oder Geheimtext, der
                        von einigen oder allen Stellen, die auf die signierten Daten
                        zugreifen können, überprüft werden kann
              \end{itemize}
        \item
              Einige kryptografische Algorithmen können für beide Zwecke verwendet
              werden, andere sind nur für einen der beiden Zwecke sicher und/oder
              effizient.
        \item
              Hauptkategorien von kryptografischen Algorithmen

              \begin{itemize}
                  \item
                        Symmetrische Kryptografie, die 1 Schlüssel für die
                        Ver-/Entschlüsselung oder die Signierung/Prüfung verwendet
                  \item
                        Asymmetrische Kryptografie mit 2 verschiedenen Schlüsseln für die
                        Ver-/Entschlüsselung oder die Unterzeichnung/Prüfung
                  \item
                        Kryptografische Hash-Funktionen mit 0 Schlüsseln (der "Schlüssel"
                        ist keine separate Eingabe, sondern wird an die Daten "angehängt"
                        oder mit ihnen "vermischt").
              \end{itemize}
    \end{itemize}


    \subsection{Angriff auf die
        Kryptographie}


    \subsection{Kryptoanalyse}

    \begin{itemize}
        \item
              Kryptoanalyse ist der Versuch, den Klartext und/oder den Schlüssel
              herauszufinden.
        \item
              Arten der Kryptoanalyse

              \begin{itemize}
                  \item
                        Nur Chiffretext: bestimmte Muster des Klartextes können im
                        Chiffretext erhalten bleiben (Häufigkeit von Buchstaben, Digraphen
                        usw.)
                  \item
                        Bekannte Chiffretext-Klartext-Paare
                  \item
                        Gewählter Klartext oder gewählter Chiffretext
                  \item
                        Differentielle Kryptoanalyse und lineare Kryptoanalyse
                  \item
                        Neuere Entwicklung: verwandte Schlüsselanalyse
              \end{itemize}
        \item
              Kryptoanalyse der Public-Key-Kryptographie

              \begin{itemize}
                  \item
                        Die Tatsache, dass ein Schlüssel öffentlich zugänglich ist, kann
                        ausgenutzt werden
                  \item
                        Die Kryptoanalyse öffentlicher Schlüssel zielt eher darauf ab, das
                        Kryptosystem selbst zu knacken und ist näher an der reinen
                        mathematischen Forschung als an der klassischen Kryptoanalyse.
                  \item
                        Wichtige Richtungen

                        \begin{itemize}
                            \item
                                  Berechnung von diskreten Logarithmen
                            \item
                                  Faktorisierung von großen ganzen Zahlen
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsubsection{Brute-Force-Angriff}

    \begin{itemize}
        \item
              Der Brute-Force-Angriff probiert alle möglichen Schlüssel aus, bis er
              einen verständlichen Klartext findet

              \begin{itemize}
                  \item
                        Jeder kryptographische Algorithmus kann theoretisch mit Brute Force
                        angegriffen werden
                  \item
                        Im Durchschnitt muss die Hälfte aller möglichen Schlüssel
                        ausprobiert werden
              \end{itemize}
    \end{itemize}

    Durchschnittlich benötigte Zeit für erschöpfende Schlüsselsuche

    %\begin{longtable}[]{@{}llll@{}}
    %    \toprule
    %    Schlüsselgröße {[}bit{]}                                       & Anzahl der Schlüssel                                   & Benötigte Zeit bei 1
    %    \$Verschlüsselung/\textbackslash mu\$s                         & Zeitbedarf bei 10\^{}6
    %    Verschlüsselung /\$\textbackslash mu\$s\tabularnewline
    %    \midrule
    %    \endhead
    %    56                                                             & \$2\^{}\{56\} = 7,2\textbackslash times 10\^{}\{16\}\$ &
    %    \$2\^{}\{55\}\textbackslash mu s = 1142\$ Jahre                & \$10,01\$
    %    Stunden\tabularnewline
    %    128                                                            & \$2\^{}\{128\} = 3,4 x 10\^{}\{38\}\$                  &
    %    \$2\^{}\{127\}\textbackslash mu s = 5,4 x 10\^{}\{24\}\$ Jahre & \$5,4 x
    %    10\^{}\{18\}\$ Jahre\tabularnewline
    %    256                                                            & \$2\^{}\{256\} = 1.2 x 10\^{}\{77\}                    &
    %    \$2\^{}\{255\}\textbackslash mu s = 3,7 x 10\^{}\{63\}\$ Jahre & \$3,7 x
    %    10\^{}\{57\}\$ Jahre\tabularnewline
    %    \bottomrule
    %\end{longtable}


    \subsubsection{Wie groß ist groß?}

    Referenzzahlen zum Vergleich relativer Größenordnungen \textbar{}
    Referenz \textbar{} Größe \textbar{} \textbar{}
    -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
    \textbar{}
    -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
    \textbar{} \textbar{} Sekunden in einem Jahr \textbar{} ca. \$3 x
    10\^{}7\$ \textbar{} \textbar{} Sekunden seit der Entstehung des
    Sonnensystems \textbar{} ca. \$2 x 10\^{}\{17\}\$ \textbar{} \textbar{}
    Taktzyklen pro Jahr (50 MHz Computer) \textbar{} ca. \$1,6 x
    10\^{}\{15\}\$ \textbar{} \textbar{} Binäre Zeichenketten der Länge 64
    \textbar{} \$2\^{}\{64\}\$ ca. \$1,8 x 10\^{}\{19\}\$ \textbar{}
    \textbar{} Binäre Zeichenfolgen der Länge 128 \textbar{}
    \$2\^{}\{128\}\$ ca. \$3,4 x 10\^{}\{38\}\$ \textbar{} \textbar{} Binäre
    Zeichenfolgen der Länge 256 \textbar{} \$2\^{}\{256\}\$ ca. \$1,2 x
    10\^{}\{77\}\$ \textbar{} \textbar{} Anzahl der 75-stelligen Primzahlen
    \textbar{} \$5,2 x 10\^{}\{72\}\$ \textbar{} \textbar{} Elektronen im
    Universum \textbar{} \$8,37 x 10\^{}\{77\}\$ \textbar{}


    \subsubsection{Wichtige Eigenschaften von
        Verschlüsselungsalgorithmen}

    Nehmen wir an, ein Absender verschlüsselt Klartextnachrichten \$P\_1,
    P\_2, ...\$ zu Chiffretextnachrichten \$C\_1, C\_2, ...\$

    Dann sind die folgenden Eigenschaften des Verschlüsselungsalgorithmus
    von besonderem Interesse

    \begin{itemize}
        \item
              Die Fehlerfortpflanzung charakterisiert die Auswirkungen von
              Bit-Fehlern bei der Übertragung von Chiffretext zu rekonstruiertem
              Klartext \$P\_1', P\_2', ...\$

              \begin{itemize}
                  \item
                        Je nach Verschlüsselungsalgorithmus können pro fehlerhaftem
                        Chiffretext-Bit ein oder mehrere fehlerhafte Bits im rekonstruierten
                        Klartext vorhanden sein
              \end{itemize}
        \item
              Die Synchronisierung charakterisiert die Auswirkungen verlorener
              Chiffretext-Dateneinheiten auf den rekonstruierten Klartext

              \begin{itemize}
                  \item
                        Einige Verschlüsselungsalgorithmen können sich nicht von verlorenem
                        Chiffretext erholen und benötigen daher eine explizite
                        Neusynchronisierung im Falle verlorener Nachrichten
                  \item
                        Andere Algorithmen führen eine automatische Neusynchronisierung nach
                        0 bis n (n je nach Algorithmus) Chiffretextbits durch.
              \end{itemize}
    \end{itemize}


    \subsection{Klassifizierung von Verschlüsselungsalgorithmen: Drei
        Dimensionen}

    \begin{itemize}
        \item
              Die Art der Operationen, die zur Umwandlung von Klartext in
              Chiffretext verwendet werden

              \begin{itemize}
                  \item
                        Substitution, die jedes Element des Klartextes (Bit, Buchstabe,
                        Gruppe von Bits oder Buchstaben) in ein anderes Element umwandelt
                  \item
                        Transposition, die die Elemente des Klartextes neu anordnet
              \end{itemize}
        \item
              Die Anzahl der verwendeten Schlüssel

              \begin{itemize}
                  \item
                        Symmetrische Chiffren, die denselben Schlüssel für die Ver- und
                        Entschlüsselung verwenden
                  \item
                        Asymmetrische Chiffren, bei denen unterschiedliche Schlüssel für die
                        Ver- und Entschlüsselung verwendet werden
              \end{itemize}
        \item
              Die Art und Weise, in der der Klartext verarbeitet wird

              \begin{itemize}
                  \item
                        Stromchiffren arbeiten mit Bitströmen und verschlüsseln ein Bit nach
                        dem anderen

                        \begin{itemize}
                            \item
                                  Viele Stromchiffren basieren auf der Idee der linearen
                                  rückgekoppelten Schieberegister, und bei vielen Algorithmen dieser
                                  Klasse wurden Schwachstellen entdeckt, da es eine tiefgreifende
                                  mathematische Theorie zu diesem Thema gibt.
                            \item
                                  Die meisten Stromchiffren verbreiten keine Fehler, sind aber
                                  anfällig für den Verlust der Synchronisation.
                        \end{itemize}
                  \item
                        Blockchiffren arbeiten mit Blöcken der Breite b, wobei b vom
                        jeweiligen Algorithmus abhängt.
              \end{itemize}
    \end{itemize}


    \subsection{Kryptographische Algorithmen -
        Überblick}

    Kryptografische Algorithmen

    \begin{itemize}
        \item
              Überblick

              \begin{itemize}
                  \item
                        Eigenschaften
                  \item
                        Kryptoanalyse
              \end{itemize}
        \item
              Symmetrische Ver-/Entschlüsselung

              \begin{itemize}
                  \item
                        Funktionsweisen
                  \item
                        DES
                  \item
                        AES
                  \item
                        RC4
                  \item
                        KASUMI
              \end{itemize}
        \item
              Asymmetrische Ver-/Entschlüsselung

              \begin{itemize}
                  \item
                        Hintergrund
                  \item
                        RSA
                  \item
                        Diffie-Hellman
                  \item
                        ElGamal
                  \item
                        ECC
              \end{itemize}
        \item
              Kryptographische Hash-Funktionen

              \begin{itemize}
                  \item
                        MDCs/MACs
                  \item
                        MD
                  \item
                        SHA-1/2/
                  \item
                        CBC-MAC
                  \item
                        GCM-MAC
              \end{itemize}
    \end{itemize}


    \section{Symmetrische Kryptographie}

    \begin{itemize}
        \item
              Modi der Verschlüsselung
        \item
              Datenverschlüsselungsstandard (DES)
        \item
              Erweiterter Verschlüsselungsstandard (AES)
        \item
              Die Blockchiffre RC
        \item
              KASUMI
    \end{itemize}


    \subsection{Symmetrische
        Verschlüsselung}

    \begin{itemize}
        \item
              Allgemeine Beschreibung

              \begin{itemize}
                  \item
                        Derselbe Schlüssel KA,B wird für die Verschlüsselung und
                        Entschlüsselung von Nachrichten verwendet
              \end{itemize}
        \item
              Schreibweise

              \begin{itemize}
                  \item
                        Wenn P die Klartextnachricht bezeichnet, bezeichnet \$E(K\_\{A,B\},
                        P)\$ den Chiffretext und es gilt \$D(K\_\{A,B\}, E(K\_\{A,B\}, P)) =
                        P\$
                  \item
                        Alternativ schreibt man manchmal \$\{P\}\emph{\{K}\{A,B\}\}\$ oder
                        \$E\_\{K\_\{A,B\}\}(P)\$ für \$E(K\_\{A,B\}, P)\$
              \end{itemize}
        \item
              Beispiele: DES, 3DES, AES, ...
    \end{itemize}


    \subsection{Symmetrische Blockchiffren -
        Verschlüsselungsarten}

    Allgemeine Bemerkungen \& Notation

    \begin{itemize}
        \item
              Ein Klartext P wird in Blöcke \$P\_1, P\_2, ...\$ der Länge b bzw. j
              zerlegt, wobei b die Blockgröße des Verschlüsselungsalgorithmus
              bezeichnet und j \textless{} b
        \item
              Der Chiffretext C ist die Kombination von \$C\_1, C\_2, ...\$, wobei
              \$c\_i\$ das Ergebnis der Verschlüsselung des i-ten Blocks der
              Klartextnachricht bezeichnet
        \item
              Die Stellen, die eine Nachricht verschlüsseln und entschlüsseln, haben
              sich auf einen Schlüssel K geeinigt.
    \end{itemize}

    Elektronischer Codebuch-Modus (Electronic Code Book Mode: ECB)

    \begin{itemize}
        \item
              Jeder Block Pi der Länge b wird unabhängig verschlüsselt: \$C\_i =
              E(K, p\_i)\$
        \item
              Ein Bitfehler in einem Chiffretextblock \$C\_i\$ führt zu einem völlig
              falsch wiederhergestellten Klartextblock \$P\_i'\$
        \item
              Der Verlust der Synchronisation hat keine Auswirkungen, wenn
              ganzzahlige Vielfache der Blockgröße b verloren gehen. Geht eine
              andere Anzahl von Bits verloren, ist eine explizite Neusynchronisation
              erforderlich.
        \item
              Nachteil: identische Klartextblöcke werden zu identischem Chiffretext
              verschlüsselt!
        \item
              % \includegraphics{Assets/NetworkSecurity-electronic-code-book-mode.png}
    \end{itemize}

    Cipher Block Chaining Modus (Cipher Block Chaining Mode: CBC)

    \begin{itemize}
        \item
              Vor der Verschlüsselung eines Klartextblocks pi wird dieser mit dem
              vorangegangenen Chiffretextblock \$C\_\{i-1\}\$ XOR-verknüpft ()

              \begin{itemize}
                  \item
                        \$C\_i = E(K, C\_\{i-1\} \textbackslash oplus p\_i)\$
                  \item
                        \$P\_\{i'\} = C\_\{i-1\} \textbackslash oplus D(K, C\_i)\$
                  \item
                        Um \$C\_1\$ zu berechnen, einigen sich beide Parteien auf einen
                        Anfangswert (IV) für \$C\_0\$
              \end{itemize}
        \item
              Eigenschaften

              \begin{itemize}
                  \item
                        Fehlerfortpflanzung: Ein verfälschter Chiffretextblock führt zu zwei
                        verfälschten Klartextblöcken, da \$P\_i'\$ mit \$C\_\{i-1\}\$ und
                        \$C\_i\$ berechnet wird
                  \item
                        Synchronisation: Wenn die Anzahl der verlorenen Bits ein
                        ganzzahliges Vielfaches von b ist, wird ein zusätzlicher Block
                        \$P\_\{i+1\}\$ verzerrt, bevor die Synchronisation wiederhergestellt
                        wird. Wenn eine andere Anzahl von Bits verloren geht, ist eine
                        explizite Neusynchronisation erforderlich.
                  \item
                        Vorteil: identische Klartextblöcke werden zu nicht-identischem
                        Chiffretext verschlüsselt.
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-cipher-block-chaining-mode.png}
    \end{itemize}

    Chiffretext-Feedback-Modus (Ciphertext Feedback Mode: CFB)

    \begin{itemize}
        \item
              Ein Blockverschlüsselungsalgorithmus, der mit Blöcken der Größe b
              arbeitet, kann in einen Algorithmus umgewandelt werden, der mit
              Blöcken der Größe \$j (j\textless b)\$ arbeitet.

              \begin{itemize}
                  \item
                        \$S(j, x)\$ bezeichnen die \$j\$ höherwertigen Bits von \$x\$
                  \item
                        \$P\_i\$, \$C\_i\$ den \$i\$-ten Block von Klartext und Geheimtext
                        der Länge \$j\$ bezeichnen
                  \item
                        IV ist ein Anfangswert, auf den sich beide Parteien geeinigt haben
                  \item
                        \$R\_1 = IV\$
                  \item
                        \$R\_n = (R\_\{n-1\}*2\^{}j\textbackslash{} mod\textbackslash{}
                        2\^{}b)\textbackslash oplus C\_\{n-1\}\$
                  \item
                        \$C\_n = S(j,E\_K(R\_n))\textbackslash oplus P\_n\$
                  \item
                        \$S(j,E\_K(R\_n))\textbackslash oplus C\_n =
                        S(j,E\_K(R\_n))\textbackslash oplus
                        S(j,E\_K(R\_n))\textbackslash oplus P\_n\$
                  \item
                        \$S(j,E\_K(R\_n))\textbackslash oplus C\_n = P\_n\$
              \end{itemize}
        \item
              Ein gängiger Wert für j ist 8 für die Verschlüsselung von einem
              Zeichen pro Schritt
        \item
              Eigenschaften von CFB

              \begin{itemize}
                  \item
                        Fehlerfortpflanzung: Da die Chiffretextblöcke schrittweise durch das
                        Register geschoben werden, verfälscht ein fehlerhafter Block
                        \$C\_i\$ den wiederhergestellten Klartextblock \$P\_i'\$ sowie die
                        folgenden \$\textbackslash lceil b / j\textbackslash rceil\$-Blöcke
                  \item
                        Synchronisation: Wenn die Anzahl der verlorenen Bits ein
                        ganzzahliges Vielfaches von j ist, werden \$\textbackslash lceil b /
                        j\textbackslash rceil\$ zusätzliche Blöcke verfälscht, bevor die
                        Synchronisation wiederhergestellt ist. Wenn eine beliebige andere
                        Anzahl von Bits verloren geht, ist eine explizite
                        Neusynchronisierung erforderlich.
                  \item
                        Nachteil: Die Verschlüsselungsfunktion E muss häufiger berechnet
                        werden, da eine Verschlüsselung von b Bit durchgeführt werden muss,
                        um j Bit des Klartextes zu verbergen. Beispiel: Bei Verwendung von
                        DES mit Verschlüsselung von jeweils einem Zeichen
                        \$\textbackslash Rightarrow\$ muss die Verschlüsselung 8-mal
                        häufiger durchgeführt werden
              \end{itemize}
    \end{itemize}

    Output-Feedback-Modus (OFB)

    \begin{itemize}
        \item
              Der Blockverschlüsselungsalgorithmus wird zur Erzeugung einer
              Pseudozufallsfolge \$R\_i\$ verwendet, die nur von \$K\$ und \$IV\$
              abhängt.

              \begin{itemize}
                  \item
                        \$S(j, x)\$ bezeichnen die \$j\$ höherwertigen Bits von \$x\$
                  \item
                        \$P\_i\$, \$C\_i\$ bezeichnen den \$i\$-ten Block von Klartext und
                        Chiffretext der Länge \$j\$
                  \item
                        \$IV\$ sei ein Anfangswert, auf den sich beide Parteien geeinigt
                        haben
                  \item
                        \$R\_1 = IV\$
                  \item
                        \$R\_n = (R\_\{n-1\}* 2\^{}j\textbackslash{} mod\textbackslash{}
                        2\^{}b )\textbackslash oplus S(j,E\_K(R\_\{n-1\}))\$ // j-bit
                        Linksverschiebung + verschlüsselter alter Wert
                  \item
                        \$C\_n = S(j,E\_K(R\_n))\textbackslash oplus P\_n\$
                  \item
                        \$S(j,E\_K(R\_n))\textbackslash oplus C\_n =
                        S(j,E\_K(R\_n))\textbackslash oplus
                        S(j,E\_K(R\_n))\textbackslash oplus P\_n\$
                  \item
                        \$S(j,E\_K(R\_n))\textbackslash oplus C\_n = P\_n\$
              \end{itemize}
        \item
              Der Klartext wird mit der Pseudo-Zufallssequenz XOR-verknüpft, um den
              Chiffretext zu erhalten und umgekehrt
        \item
              Eigenschaften von OFB

              \begin{itemize}
                  \item
                        Fehlerfortpflanzung: Einzelbitfehler führen nur zu Einzelbitfehlern
                        \$\textbackslash rightarrow\$ keine Fehlermultiplikation
                  \item
                        Synchronisierung: Wenn einige Bits verloren gehen, ist eine
                        explizite Re-Synchronisation erforderlich.
                  \item
                        Vorteil: Die Pseudo-Zufallsfolge kann vorberechnet werden, um die
                        Auswirkungen der Verschlüsselung auf die Ende-zu-Ende-Verzögerung
                        gering zu halten
                  \item
                        Nachteile

                        \begin{itemize}
                            \item
                                  Wie bei CFB muss die Verschlüsselungsfunktion E häufiger berechnet
                                  werden, da eine Verschlüsselung von b Bit durchgeführt werden
                                  muss, um j Bit des Klartextes zu verbergen
                            \item
                                  Es ist für einen Angreifer möglich, bestimmte Bits des Klartextes
                                  zu manipulieren
                        \end{itemize}
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-output-feedback-mode.png}
    \end{itemize}

    Algorithmus-Übersicht

    \begin{itemize}
        \item
              Datenverschlüsselungsstandard (DES)

              \begin{itemize}
                  \item
                        Alter amerikanischer Standard aus den 70er Jahren
                  \item
                        Unsicher wegen der Schlüssel- und Blocklänge
                  \item
                        Grundlegender Aufbau
                  \item
                        Dreifache Verschlüsselung mit einer Blockchiffre, z.B. Triple-DES
              \end{itemize}
        \item
              Erweiterter Verschlüsselungsstandard (AES)

              \begin{itemize}
                  \item
                        Offener Standardisierungsprozess mit internationaler Beteiligung
                  \item
                        Im Oktober 2000 wurde ein Algorithmus namens Rijndael für AES
                        vorgeschlagen
                  \item
                        Ankündigung des AES-Standards im November 2001
                  \item
                        Siehe auch \href{http://www.nist.gov/aes/}{http://www.nist.gov/aes/}
              \end{itemize}
        \item
              Andere populäre Algorithmen

              \begin{itemize}
                  \item
                        RC
                  \item
                        KASUMI
              \end{itemize}
    \end{itemize}


    \subsection{Der Datenverschlüsselungsstandard
        (DES)}

    Geschichte

    \begin{itemize}
        \item
              1973 veröffentlichte das National Bureau of Standards (NBS, heute
              National Institute of Standards and Technology, NIST) eine
              Aufforderung zur Einreichung von Vorschlägen für einen nationalen
              Verschlüsselungsstandard und forderte von dem Algorithmus, dass er

              \begin{itemize}
                  \item
                        ein hohes Maß an Sicherheit bieten,
                  \item
                        vollständig spezifiziert und leicht zu verstehen sein,
                  \item
                        Sicherheit nur durch seinen Schlüssel und nicht durch seine eigene
                        Geheimhaltung bieten,
                  \item
                        für alle Benutzer verfügbar sein,
                  \item
                        für den Einsatz in verschiedenen Anwendungen anpassbar sein,
                  \item
                        wirtschaftlich in elektronischen Geräten implementierbar sein,
                  \item
                        effizient in der Anwendung sein,
                  \item
                        validiert werden können und
                  \item
                        exportierbar sein.
              \end{itemize}
        \item
              Keine der Einreichungen auf diese erste Aufforderung erfüllte diese
              Kriterien auch nur annähernd.
        \item
              Auf eine zweite Aufforderung hin reichte IBM seinen Algorithmus
              LUCIFER ein, eine symmetrische Blockchiffre, die mit Blöcken der Länge
              128 Bit unter Verwendung von Schlüsseln der Länge 128 Bit arbeitet;
              dies war der einzige vielversprechende Kandidat.
        \item
              Die NBS bat die National Security Agency (NSA) um Hilfe bei der
              Bewertung der Sicherheit des Algorithmus

              \begin{itemize}
                  \item
                        Die NSA reduzierte die Blockgröße auf 64 Bit, die Größe des
                        Schlüssels auf 56 Bit und änderte Details in den
                        Substitutionsfeldern des Algorithmus.
                  \item
                        Viele der Gründe der NSA für diese Änderungen wurden erst in den
                        frühen 1990er Jahren deutlich, lösten aber in den späten 1970er
                        Jahren große Besorgnis aus.
              \end{itemize}
        \item
              Trotz aller Kritik wurde der Algorithmus 1977 als ,,Data Encryption
              Standard'' in die Reihe der Federal Information Processing Standards
              (FIPS PUB 46) aufgenommen und für die Verwendung in der gesamten nicht
              klassifizierten Regierungskommunikation zugelassen.
        \item
              DES hat sich in den folgenden Jahren weithin durchgesetzt
    \end{itemize}

    % \includegraphics{Assets/NetworkSecurity-des-algorithm.png}

    % \includegraphics{Assets/NetworkSecurity-des-single-iteration.png}


    \subsubsection{DES - Einzelne
        Iteration}

    \begin{itemize}
        \item
              Die rechten 32 Bit der zu verschlüsselnden Daten werden mit Hilfe
              einer Expansions-/Permutationstabelle auf 48 Bit erweitert.
        \item
              Sowohl die linken als auch die rechten 28 Bit des Schlüssels (auch
              Subkeys genannt) werden zirkulär nach links verschoben und der
              resultierende Wert wird mit Hilfe einer
              Permutations-/Kontraktionstabelle auf 48 Bit verkürzt.
        \item
              Die beiden oben genannten Werte werden XOR-verknüpft und in eine
              Auswahl- und Ersetzungsbox eingegeben

              \begin{itemize}
                  \item
                        Intern wird diese Operation durch 8 so genannte s-Boxen realisiert,
                        von denen jede einen Sechs-Bit-Wert auf einen Vier-Bit-Wert gemäß
                        einer boxspezifischen Tabelle abbildet, was insgesamt zu einem
                        32-Bit-Ausgang führt
                  \item
                        Das Design dieser s-boxes wurde von der NSA verstärkt, was in den
                        1970er Jahren zu intensiven Diskussionen führte und in den 1990er
                        Jahren nach der Entdeckung der differentiellen Kryptoanalyse
                        verstanden wurde
              \end{itemize}
        \item
              Der Ausgang des obigen Schritts wird erneut permutiert und mit den
              linken 32 Bit der Daten XOR-verknüpft, was zu den neuen rechten 32 Bit
              der Daten führt
        \item
              Die neuen linken 32 Bit der Daten sind der rechte Wert der vorherigen
              Iteration
    \end{itemize}


    \subsubsection{DES - Entschlüsselung}

    \begin{itemize}
        \item
              Unter Verwendung der Abkürzung f(R, K) kann der
              Verschlüsselungsprozess wie folgt geschrieben werden

              \begin{itemize}
                  \item
                        \$L\_i = R\_\{i-1\}\$
                  \item
                        \$R\_i = L\_\{i-1\}\textbackslash oplus f(R\_\{i-1\}, K\_i)\$
                  \item
                        Dieses Konzept (Aufteilung der Daten in zwei Hälften und
                        Organisation der Verschlüsselung gemäß den obigen Gleichungen) wird
                        in vielen Blockchiffren verwendet und wird als Feistel-Netzwerk
                        bezeichnet (nach seinem Erfinder H. Feistel)
              \end{itemize}
        \item
              Der DES-Entschlüsselungsprozess ist im Wesentlichen derselbe wie die
              Verschlüsselung. Er verwendet den Chiffretext als Eingabe für den
              Verschlüsselungsalgorithmus, wendet aber die Unterschlüssel in
              umgekehrter Reihenfolge an
        \item
              Die Ausgangswerte sind also

              \begin{itemize}
                  \item
                        \$L\_0' \textbar\textbar{} R\_0' =\$ InitialPermutation
                        (Chiffretext)
                  \item
                        chiffretext = InverseInitialPermutation (\$R\_\{16\}
                        \textbar\textbar{} L\_\{16\}\$)
                  \item
                        \$L\_0' \textbar\textbar{} R\_0' =\$ InitialPermutation
                        (InverseInitialPermutation
                        (\$R\_\{16\}\textbar\textbar L\_\{16\}))=R\_\{16\}\textbar\textbar L\_\{16\}\$
              \end{itemize}
        \item
              Nach einem Schritt der Entschlüsselung

              \begin{itemize}
                  \item
                        \$L\_1' = R\_0' = L\_\{16\} = R\_\{15\}\$
                  \item
                        \$R\_1' = L\_0' \textbackslash oplus f(R\_0',
                        K\_\{16\})=R\_\{16\}\textbackslash oplus
                        f(R\_\{15\},K\_\{16\})={[}L\_\{15\}\textbackslash oplus
                        f(R\_\{15\},K\_\{16\}){]}\textbackslash oplus f(R\_\{15\},K\_\{16\})
                        =L\_\{15\}\$
              \end{itemize}
        \item
              Diese Beziehung gilt für den gesamten Prozess als

              \begin{itemize}
                  \item
                        \$R\_\{i-1\} = L\_i\$
                  \item
                        \$L\_\{i-1\} = R\_i\textbackslash oplus f(R\_\{i-1\}, K\_i) =
                        R\_i\textbackslash oplus f(L\_i, K\_i)\$
              \end{itemize}
        \item
              Der Ausgang der letzten Runde ist schließlich

              \begin{itemize}
                  \item
                        \$L\_\{16\}' \textbar\textbar{} R\_\{16\}' = R\_0 \textbar\textbar{}
                        L\_0\$
              \end{itemize}
        \item
              Nach der letzten Runde führt DES einen 32-Bit-Tausch und die inverse
              Anfangspermutation durch

              \begin{itemize}
                  \item
                        InverseInitialPermutation(\$L\_0\textbar\textbar R\_0\$) =
                        InverseInitialPermutation(InitialPermutation(Klartext)) = Klartext
              \end{itemize}
    \end{itemize}


    \subsubsection{DES - Sicherheit}

    \begin{itemize}
        \item
              Schwächen der Schlüssel

              \begin{itemize}
                  \item
                        Schwache Schlüssel: Vier Schlüssel sind schwach, da sie
                        Unterschlüssel erzeugen, die entweder alle 0 oder alle 1 enthalten.
                  \item
                        Halbschwache Schlüssel: Es gibt sechs Schlüsselpaare, die Klartext
                        zu identischem Chiffriertext verschlüsseln, da sie nur zwei
                        verschiedene Unterschlüssel erzeugen
                  \item
                        Möglicherweise schwache Schlüssel: Es gibt 48 Schlüssel, die nur
                        vier verschiedene Unterschlüssel erzeugen
                  \item
                        Insgesamt werden 64 Schlüssel von \$72057594037927936\$ als schwach
                        angesehen
              \end{itemize}
        \item
              Algebraische Struktur

              \begin{itemize}
                  \item
                        Wäre DES geschlossen, dann gäbe es für jedes \$K\_1,K\_2\$ ein
                        \$K\_3\$, so dass: \$E(K\_2,E(K\_1,M))=E(K\_3,M)\$, also wäre die
                        doppelte Verschlüsselung nutzlos
                  \item
                        Wäre DES rein, dann gäbe es für jedes \$K\_1,K\_2,K\_3\$ ein
                        \$K\_4\$, so dass \$E(K\_3,E(K\_2,E(K\_1,M)))=E(K\_4,M)\$, also wäre
                        die dreifache Verschlüsselung nutzlos
                  \item
                        DES ist weder geschlossen noch rein, daher kann ein
                        Mehrfachverschlüsselungsschema verwendet werden, um die
                        Schlüssellänge zu erhöhen
              \end{itemize}
        \item
              Differentielle Kryptoanalyse

              \begin{itemize}
                  \item
                        Im Jahr 1990 veröffentlichten E. Biham und A. Shamir diese
                        Analysemethode
                  \item
                        Sie sucht gezielt nach Unterschieden in Chiffretexten, deren
                        Klartexte bestimmte Unterschiede aufweisen, und versucht, daraus den
                        richtigen Schlüssel zu erraten
                  \item
                        Der grundlegende Ansatz benötigt einen ausgewählten Klartext
                        zusammen mit seinem Chiffretext
                  \item
                        DES mit 16 Runden ist gegen diesen Angriff immun, da der Angriff
                        \$2\^{}\{47\}\$ gewählte Klartexte oder (bei "Umwandlung" in einen
                        Angriff mit bekannten Klartexten) \$2\^{}55\$ bekannte Klartexte
                        benötigt.
                  \item
                        Die Entwickler von DES erklärten in den 1990er Jahren, dass sie in
                        den 1970er Jahren über diese Art von Angriffen Bescheid wussten und
                        dass die s-Boxen entsprechend entworfen wurden
              \end{itemize}
        \item
              Schlüssellänge

              \begin{itemize}
                  \item
                        Da ein 56-Bit-Schlüssel in \$10,01\$ Stunden durchsucht werden kann,
                        wenn man \$10\^{}6\$ Verschlüsselungen / \$\textbackslash mu s\$
                        durchführen kann (was heute möglich ist), kann DES nicht mehr als
                        ausreichend sicher angesehen werden.
              \end{itemize}
    \end{itemize}


    \subsubsection{Erweiterung der Schlüssellänge von DES durch
        Mehrfachverschlüsselung}

    \begin{itemize}
        \item
              Doppelter DES: Da DES nicht geschlossen ist, führt die doppelte
              Verschlüsselung zu einer Chiffre, die 112-Bit-Schlüssel verwendet

              \begin{itemize}
                  \item
                        Leider kann sie mit einem Aufwand von \$2\^{}\{56\}\$ angegriffen
                        werden.
                  \item
                        Da \$C=E(K\_2,E(K\_1,P))\$ haben wir \$X:=E(K\_1,P)=D(K\_2,C)\$
                  \item
                        Wenn ein Angreifer ein bekanntes Klartext/Chiffretext-Paar erhalten
                        kann, kann er zwei Tabellen erstellen (meet-in-the-middle-attack)

                        \begin{itemize}
                            \item
                                  Tabelle 1 enthält die Werte von \$X\$, wenn \$P\$ mit allen
                                  möglichen Werten von \$K\$ verschlüsselt ist
                            \item
                                  Tabelle 2 enthält die Werte von \$X\$, wenn \$C\$ mit allen
                                  möglichen Werten von \$K\$ entschlüsselt wird
                            \item
                                  Sortiere die beiden Tabellen und konstruiere Schlüssel
                                  \$K\_\{T1\}\textbar\textbar K\_\{T2\}\$ für alle Kombinationen von
                                  Einträgen, die den gleichen Wert ergeben.
                        \end{itemize}
              \end{itemize}
        \item
              Da es für jeden beliebigen Klartext \$2\^{}\{64\}\$ mögliche
              Chiffretext-Werte gibt, die mit Double-DES erzeugt werden könnten,
              gibt es beim ersten bekannten Klartext/Chiffretext-Paar
              durchschnittlich \$2\^{}\{112\}/2\^{}\{64\}=2\^{}\{48\}\$ Fehlalarme.
        \item
              Jedes weitere Klartext/Chiffretext-Paar verringert die Chance, einen
              falschen Schlüssel zu erhalten, um den Faktor \$1/2\^{}\{64\}\$, so
              dass bei zwei bekannten Blöcken die Chance \$2\^{}\{-16\}\$ beträgt.
        \item
              Der Aufwand, der erforderlich ist, um Double DES zu knacken, liegt
              also in der Größenordnung von \$2\^{}\{56\}\$, was nur geringfügig
              besser ist als der Aufwand von \$2\^{}\{55\}\$, der erforderlich ist,
              um Single DES mit einem Angriff mit bekanntem Klartext zu knacken, und
              weit entfernt von den \$2\^{}\{111\}\$, die wir von einer Chiffre mit
              einer Schlüssellänge von 112 Bit erwarten würden!
        \item
              Diese Art von Angriff kann durch die Verwendung eines dreifachen
              Verschlüsselungsschemas umgangen werden, wie es 1979 von W. Tuchman
              vorgeschlagen wurde

              \begin{itemize}
                  \item
                        \$C=E(K\_3,D(K\_2,E(K\_1,P)))\$
                  \item
                        Die Verwendung der Entschlüsselungsfunktion D in der Mitte
                        ermöglicht die Verwendung von Dreifachverschlüsselungsgeräten mit
                        Gegenstellen, die nur Einfachverschlüsselungsgeräte besitzen, indem
                        \$K\_1=K\_2=K\_3\$ gesetzt wird.
                  \item
                        Dreifachverschlüsselung kann mit zwei (Einstellung \$K\_1=K\_3\$)
                        oder drei verschiedenen Schlüsseln verwendet werden
                  \item
                        Bislang sind keine praktischen Angriffe gegen dieses Verfahren
                        bekannt
                  \item
                        Nachteil: die Leistung beträgt nur \$1/3\$ der einfachen
                        Verschlüsselung, so dass es besser sein könnte, gleich eine andere
                        Chiffre zu verwenden, die eine größere Schlüssellänge bietet
              \end{itemize}
    \end{itemize}


    \subsection{Der fortgeschrittene Verschlüsselungsstandard
        AES}

    \begin{itemize}
        \item
              Jan. 1997: Das National Institute of Standards and Technology (NIST)
              der USA kündigt die Entwicklung des AES an.

              \begin{itemize}
                  \item
                        Das übergeordnete Ziel ist die Entwicklung eines Federal Information
                        Processing Standard (FIPS), der einen Verschlüsselungsalgorithmus
                        spezifiziert, der in der Lage ist, sensible Regierungsinformationen
                        bis weit ins nächste Jahrhundert hinein zu schützen.
              \end{itemize}
        \item
              Sep. 1997: Offizieller Aufruf zur Einreichung von Algorithmen, offen
              für jeden auf der Welt

              \begin{itemize}
                  \item
                        AES würde einen nicht klassifizierten, öffentlich zugänglichen
                        Verschlüsselungsalgorithmus bzw. -algorithmen spezifizieren, der
                        weltweit lizenzgebührenfrei erhältlich ist.
              \end{itemize}
        \item
              Aug. 1998: Erste AES-Kandidatenkonferenz

              \begin{itemize}
                  \item
                        NIST gibt die Auswahl von 15 Kandidatenalgorithmen bekannt
                  \item
                        Aufforderung zu öffentlichen Kommentaren
              \end{itemize}
        \item
              April 1999:

              \begin{itemize}
                  \item
                        Anhand der eingegangenen Analysen und Kommentare wählt das NIST fünf
                        Algorithmen als Kandidaten für die Endauswahl aus: MARS, RC6,
                        Rijndael, Serpent und Twofish
              \end{itemize}
        \item
              Oktober 2000: Rijndael wird als Vorschlag des NIST für AES bekannt
              gegeben

              \begin{itemize}
                  \item
                        \begin{enumerate}
                            \def\labelenumi{\arabic{enumi}.}
                            \setcounter{enumi}{25}
                            \item
                                  November 2001: offizielle Ankündigung des AES-Standards
                        \end{enumerate}
              \end{itemize}
        \item
              Rundenbasierte symmetrische Chiffre
        \item
              Keine Feistel-Struktur (unterschiedliche Verschlüsselungs- und
              Entschlüsselungsfunktionen)
        \item
              Schlüssel- und Blocklängen

              \begin{itemize}
                  \item
                        Schlüssellänge: 128, 192, oder 256 Bit
                  \item
                        Blocklänge: 128, 192 oder 256 Bit (nur 128-Bit-Version
                        standardisiert)
                  \item
                        Anzahl der Runden: 10, 12, 14
              \end{itemize}
    \end{itemize}

    Standardisierte AES-Konfigurationen \textbar{} Schlüsselgröße {[}bit{]}
    \textbar{} Blocklänge {[}bit{]} \textbar{} \# Runden \textbar{}
    \textbar{} -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
    \textbar{} -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{}
    -\/-\/-\/-\/-\/-\/-\/- \textbar{} \textbar{} 128 \textbar{} 128
    \textbar{} 10 \textbar{} \textbar{} 192 \textbar{} 128 \textbar{} 12
    \textbar{} \textbar{} 256 \textbar{} 128 \textbar{} 14 \textbar{}

    \begin{itemize}
        \item
              Der Algorithmus arbeitet mit

              \begin{itemize}
                  \item
                        \$state{[}4, 4{]}\$: ein Byte-Array mit 4 Zeilen und 4 Spalten (für
                        128-Bit-Blockgröße)
                  \item
                        \$key{[}4, 4{]}\$: ein Array mit 4 Zeilen und 4 Spalten (für
                        128-Bit-Schlüsselgröße)
              \end{itemize}
        \item
              Verschlüsselung: (für eine Block- und Schlüsselgröße von 128 Bit) in
              den Runden \$1-9\$ werden vier verschiedene Operationen verwendet

              \begin{itemize}
                  \item
                        ByteSub: eine nicht-lineare Byte-Substitution durch eine feste
                        Tabelle (im Grunde eine s-Box)
                  \item
                        ShiftRow: die Zeilen des Zustands werden zyklisch um verschiedene
                        Offsets verschoben
                  \item
                        MixColumn: die Spalten von \$state{[}{]}\$ werden als Polynome über
                        \$GF(2\^{}8)\$ betrachtet und modulo \$x\^{}4+1\$ mit einer festen
                        Matrix multipliziert: \$\textbackslash begin\{pmatrix\}
                        02\&03\&01\&01\textbackslash01\&02\&03\&01\textbackslash\textbackslash{}
                        01\&01\&02\&03\textbackslash\textbackslash{}
                        03\&01\&01\&02\textbackslash end\{pmatrix\}\$
                  \item
                        RoundKey: ein Round-Key wird mit dem Status XORiert
              \end{itemize}
        \item
              Round 10 macht keinen Gebrauch von der Operation MixColumn
    \end{itemize}

    % \includegraphics{Assets/NetworkSecurity-rijndael-one-round.png}

    \begin{itemize}
        \item
              Entschlüsselung

              \begin{itemize}
                  \item
                        Rundenschlüssel und Operationen werden in umgekehrter Reihenfolge
                        angewendet
                  \item
                        Der MixColumn-Schritt kann nur durch Multiplikation mit der inversen
                        Matrix (auch über \$GF(2\^{}8)\$) invertiert werden
                  \item
                        \$\textbackslash begin\{pmatrix\} 0e\&0b\&0d\&09\textbackslash{}
                        09\&0e\&0b\&0d\textbackslash{} 0d\&09\&0e\&0b\textbackslash{}
                        0b\&0d\&09\&0e \textbackslash end\{pmatrix\}\$
                  \item
                        Oft werden tabellarische vorberechnete Lösungen verwendet, die aber
                        mehr Platz benötigen
              \end{itemize}
    \end{itemize}


    \subsubsection{AES - Sicherheit}

    \begin{itemize}
        \item
              Die einfache mathematische Struktur von AES ist der Hauptgrund für
              seine Geschwindigkeit, führte aber auch zu Kritik
        \item
              Nur die ByteSub-Funktion ist wirklich nichtlinear und verhindert eine
              effektive Analyse
        \item
              AES kann als eine große Matrix-Operation beschrieben werden
        \item
              Bereits während der Standardisierung wurden Angriffe für reduzierte
              Versionen entwickelt

              \begin{itemize}
                  \item
                        Ein Angriff mit \$2\^{}\{32\}\$ gewähltem Klartext gegen eine
                        7-Runden-Version von AES {[}GM00{]}
                  \item
                        Signifikante Reduktion der Komplexität auch für eine
                        9-Runden-Version von AES mit 256-Schlüsselgröße mit einem
                        zugehörigen Schlüsselangriff
              \end{itemize}
        \item
              2011 wurde der erste Angriff gegen einen vollständigen AES bekannt
              {[}BKR11{]}

              \begin{itemize}
                  \item
                        Schlüsselwiederherstellung in \$2\^{}\{126.1\}\$ für AES mit 128
                        Bit, \$2\^{}\{189.7\}\$ für AES mit 192 Bit, \$2\^{}\{254.4\}\$ für
                        AES mit 256 Bit
                  \item
                        "Praktischer" Angriff (geht nicht von verwandten Schlüsseln aus),
                        aber
                  \item
                        nur ein kleiner Kratzer in Anbetracht von 10 Jahren
                        kryptographischer Forschung
              \end{itemize}
    \end{itemize}


    \subsection{Der Stromchiffre-Algorithmus
        RC4}

    \begin{itemize}
        \item
              RC4 ist eine Stromchiffre, die 1987 von Ron Rivest erfunden wurde.
        \item
              Sie war bis 1994 urheberrechtlich geschützt, als jemand sie anonym in
              eine Mailingliste einstellte.
        \item
              RC4 wird im Output-Feedback-Modus (OFB) betrieben

              \begin{itemize}
                  \item
                        Der Verschlüsselungsalgorithmus erzeugt eine Pseudozufallsfolge
                        \$RC4(IV,K)\$, die nur vom Schlüssel K und einem
                        Initialisierungsvektor IV abhängt
                  \item
                        Der Klartext \$P\_i\$ wird dann mit der Pseudozufallssequenz
                        XOR-verknüpft, um den Chiffretext zu erhalten und umgekehrt

                        \begin{itemize}
                            \item
                                  \$C\_1 = P\_1\textbackslash oplus RC4 (IV\_1,K)\$
                            \item
                                  \$P\_1 = C\_1\textbackslash oplus RC4 (IV\_1,K)\$
                        \end{itemize}
                  \item
                        Die Pseudo-Zufallsfolge wird oft auch als Keystream bezeichnet
                  \item
                        Entscheidend für die Sicherheit ist, dass der Keystream niemals
                        wiederverwendet wird!!!

                        \begin{itemize}
                            \item
                                  Wenn der Keystream wiederverwendet wird (d.h. \$IV\_1=IV\_2\$ mit
                                  demselben \$K\$), dann kann das XOR zweier Klartexte erhalten
                                  werden: \$C\_1\textbackslash oplus C\_2= P\_1\textbackslash oplus
                                  RC4(IV, K)\textbackslash oplus P\_2\textbackslash oplus RC4(IV,K)
                                  = P\_1\textbackslash oplus P\_2\$
                        \end{itemize}
              \end{itemize}
        \item
              RC4 verwendet einen Schlüssel variabler Länge bis zu 2048 Bit

              \begin{itemize}
                  \item
                        Eigentlich dient der Schlüssel als Seed für einen
                        Pseudo-Zufallsgenerator
              \end{itemize}
        \item
              RC4 arbeitet mit zwei 256-Byte-Arrays: \$S{[}0,255{]}, K{[}0,255{]}\$

              \begin{itemize}
                  \item
                        Schritt 1: Initialisierung der Arrays

                        %\begin{Shaded}
                        %    \begin{Highlighting}[]
                        %        \ControlFlowTok{for}\NormalTok{ (i = }\DecValTok{0}\NormalTok{; i \textless{} }\DecValTok{256}\NormalTok{; i++)\{}
                        %        \NormalTok{    S[i] = i; }\CommentTok{// Array S[] mit 0 bis 255 füllen}
                        %        \NormalTok{\}}
                        %        \CommentTok{// Füllen des Arrays K[] mit dem Schlüssel und IV durch Wiederholung, bis K[] gefüllt ist}
                        %        \NormalTok{n = }\DecValTok{0}\NormalTok{;}
                        %        \ControlFlowTok{for}\NormalTok{ (i =}\DecValTok{0}\NormalTok{; i \textless{} }\DecValTok{256}\NormalTok{; i++) \{}
                        %        \NormalTok{    n = (n + S[i] + K[i]) MOD }\DecValTok{256}\NormalTok{; swap(S[i], S[n]); }
                        %        \NormalTok{\}}
                        %    \end{Highlighting}
                        %\end{Shaded}
                  \item
                        Schritt 2: Erzeugen des Schlüsselstroms (nach Initialisierung \$i =
                        0; n = 0;\$)

                        %\begin{Shaded}
                        %    \begin{Highlighting}[]
                        %        \NormalTok{i = (i + }\DecValTok{1}\NormalTok{) MOD }\DecValTok{256}\NormalTok{; n = (n + S[i]) MOD }\DecValTok{256}\NormalTok{;}
                        %        \NormalTok{swap(S[i], S[n]);}
                        %        \NormalTok{t = (S[i] + S[n]) MOD }\DecValTok{256}\NormalTok{;}
                        %        \NormalTok{Z = S[t]; }\CommentTok{// Z enthält 8 Bit des durch eine Iteration erzeugten Schlüsselstroms}
                        %    \end{Highlighting}
                        %\end{Shaded}
                  \item
                        Schritt 3: XOR-Verknüpfung des Schlüsselstroms mit dem Klartext oder
                        Chiffretext
              \end{itemize}
        \item
              Sicherheit von RC4

              \begin{itemize}
                  \item
                        Sicherheit gegen Brute-Force-Angriffe (Ausprobieren aller möglichen
                        Schlüssel)

                        \begin{itemize}
                            \item
                                  Die variable Schlüssellänge von bis zu 2048 Bit erlaubt es, sie
                                  unpraktisch zu machen (zumindest mit den in unserem Universum
                                  verfügbaren Ressourcen)
                            \item
                                  Allerdings kann RC4 durch Verringerung der Schlüssellänge auch
                                  beliebig unsicher gemacht werden!
                        \end{itemize}
                  \item
                        RSA Data Security, Inc. behauptet, RC4 sei immun gegen
                        differentielle und lineare Kryptoanalyse, und es seien keine kleinen
                        Zyklen bekannt
              \end{itemize}
        \item
              RC4 mit 40-Bit-Schlüsseln hatte einen besonderen Exportstatus, selbst
              als andere Chiffren nicht aus den USA exportiert werden durften

              \begin{itemize}
                  \item
                        Secure Socket Layer (SSL) verwendet RC4 mit 40-Bit-Schlüsseln als
                        Standardalgorithmus
                  \item
                        Die Schlüssellänge von 40 Bit ist nicht immun gegen
                        Brute-Force-Angriffe.
              \end{itemize}
        \item
              Je nach Schlüsselplanungsmethode kann RC4 jedoch stark verwundbar
              sein! {[}FMS01a, Riv01a, SIR01a{]}
        \item
              Es wird empfohlen, mindestens die ersten 3072 Bytes des
              Schlüsselstroms zu verwerfen {[}Mir02, Kle08{]}
        \item
              Sollte eigentlich nicht mehr verwendet werden, auch nicht bei längeren
              Schlüsseln
    \end{itemize}


    \subsection{KASUMI}

    \begin{itemize}
        \item
              Verwendet zur Verschlüsselung von Anrufen in GSM und UMTS,
              implementiert f(8) und f(9) (auch A5/3, UEA1, UIA1 genannt)
        \item
              Ursprünglich standardisiert durch 3GPP im Jahr 2000 {[}ETS12{]} und
              basierend auf MISTY1 von Mitsubishi
        \item
              Entwickelt für Hardware-Implementierung

              \begin{itemize}
                  \item
                        Schnelle Implementierung möglich
                  \item
                        \$\textless10k\$ Gatter
              \end{itemize}
        \item
              64-Bit-Blockgröße
        \item
              128-Bit-Schlüssellänge
        \item
              8 Runden Feistel-Netzwerk
        \item
              Sicherheitsspanne nicht sehr groß
    \end{itemize}

    % \includegraphics{Assets/NetworkSecurity-kasumi-singe-iteration.png}

    \begin{itemize}
        \item
              Die linken 32 Bit der zu verschlüsselnden Daten werden durch zwei
              nichtlineare Funktionen FO und FL verändert, die beide
              Schlüsselmaterial verwenden
        \item
              Die Reihenfolge, in der FO und FL angewendet werden, hängt von der
              Rundenzahl ab
        \item
              FL teilt die Daten in 16-Bit-Wörter auf, die mit Schlüsselmaterial
              kombiniert, permutiert und mit den Originalwerten XOR-verknüpft werden
        \item
              FO ist ein 3-Runden-Feistel-Netzwerk mit einer Modifizierungsfunktion
              FI, die selbst ein Feistel-ähnliches Netzwerk ist, das zwei s-Boxen
              verwendet.
        \item
              Der Ausgang des obigen Schritts wird mit den rechten 32 Bit der Daten
              XOR-verknüpft, was zu den neuen rechten 32 Bit der Daten führt
        \item
              Das neue linke 32-Bit der Daten ist der rechte Wert der vorherigen
              Iteration
    \end{itemize}


    \subsubsection{KASUMI -
        Sicherheitsdiskussion}

    \begin{itemize}
        \item
              Eine reduzierte Version von KASUMI (6 Runden) kann durch sogenannte
              unmögliche differentielle Kryptoanalyse angegriffen werden, bei der
              unmögliche Zustände der Chiffre aus Chiffretext/Klartext-Paaren
              abgeleitet werden

              \begin{itemize}
                  \item
                        Erste Veröffentlichung bereits ein Jahr nach der Standardisierung
                  \item
                        Zeitkomplexität von \$2\^{}\{100\}\$ {[}Kue01{]}
              \end{itemize}
        \item
              Für eine Vollversion von KASUMI sind verwandte Schlüsselangriffe
              möglich

              \begin{itemize}
                  \item
                        Ausgewählter Klartextangriff, bei dem der Angreifer dieselben Daten
                        mit mehreren "verwandten" Schlüsseln verschlüsseln kann
                  \item
                        Zeitkomplexität von \$2\^{}\{76.1\}\$ {[}BDN05{]} und
                        \$2\^{}\{32\}\$ im besten Fall {[}DKS10{]}
                  \item
                        Allerdings sind die Bedingungen, unter denen Angreifer Zugang zu
                        verwandten Schlüsseln in 3G-Netzen haben, sehr selten
                  \item
                        Interessanterweise ist MISTY von diesen Angriffen nicht betroffen!
              \end{itemize}
        \item
              ETSI hat jedoch SNOW 3G (UEA2 und UIA2) {[}ETS06{]} eingeführt, um auf
              eine vollständige Verletzung von KASUMI vorbereitet zu sein

              \begin{itemize}
                  \item
                        Stromchiffre basierend auf LFSR, kann in 7.500 ASIC-Gattern
                        implementiert werden
                  \item
                        Aber auch anfällig für verwandte Schlüsselangriffe {[}KY11{]}.
              \end{itemize}
    \end{itemize}


    \section{Asymmetrische
      Kryptographie}

    Eine vorherige Beschäftigung mit der diskreten Mathematik wird dem Leser
    jedoch helfen, die hier vorgestellten Konzepte zu verstehen.'' E.
    Amoroso in einem anderen Zusammenhang {[}Amo94{]}

    \begin{itemize}
        \item
              Allgemeine Idee:

              \begin{itemize}
                  \item
                        Verwenden Sie zwei verschiedene Schlüssel \$-K\$ und \$+K\$ für die
                        Ver- und Entschlüsselung
                  \item
                        Bei einem zufälligen Chiffretext \$c=E(+K, m)\$ und \$+K\$ sollte es
                        nicht möglich sein, \$m = D(-K, c) = D(-K, E(+K, m))\$ zu berechnen.

                        \begin{itemize}
                            \item
                                  Dies impliziert, dass die Berechnung von \$-K\$ bei \$+K\$ nicht
                                  möglich sein sollte.
                        \end{itemize}
                  \item
                        Der Schlüssel \$-K\$ ist nur einer Entität A bekannt und wird A's
                        privater Schlüssel \$-K\_A\$ genannt
                  \item
                        Der Schlüssel \$+K\$ kann öffentlich bekannt gegeben werden und wird
                        A's öffentlicher Schlüssel \$+K\_A\$ genannt
              \end{itemize}
        \item
              Anwendungen:

              \begin{itemize}
                  \item
                        Verschlüsselung:

                        \begin{itemize}
                            \item
                                  Wenn B eine Nachricht mit dem öffentlichen Schlüssel \$+K\_A\$ von
                                  A verschlüsselt, kann er sicher sein, dass nur A sie mit \$-K\_A\$
                                  entschlüsseln kann.
                        \end{itemize}
                  \item
                        Signieren:

                        \begin{itemize}
                            \item
                                  Wenn A eine Nachricht mit seinem eigenen privaten Schlüssel
                                  \$-K\_A\$ verschlüsselt, kann jeder diese Signatur verifizieren,
                                  indem er sie mit A's öffentlichem Schlüssel \$+K\_A\$
                                  entschlüsselt
                        \end{itemize}
                  \item
                        Achtung! Entscheidend ist, dass jeder nachprüfen kann, dass er
                        wirklich den öffentlichen Schlüssel von A kennt und nicht den
                        Schlüssel eines Gegners!
              \end{itemize}
        \item
              Entwurf von asymmetrischen Kryptosystemen:

              \begin{itemize}
                  \item
                        Schwierigkeit: Finde einen Algorithmus und eine Methode, zwei
                        Schlüssel \$-K\$, \$+K\$ so zu konstruieren, dass es nicht möglich
                        ist, \$E(+K, m)\$ mit der Kenntnis von \$+K\$ zu entschlüsseln
                  \item
                        Beschränkungen:

                        \begin{itemize}
                            \item
                                  Die Schlüssellänge sollte ,,überschaubar'' sein
                            \item
                                  Verschlüsselte Nachrichten sollten nicht beliebig länger sein als
                                  unverschlüsselte Nachrichten (wir würden einen kleinen konstanten
                                  Faktor tolerieren)
                            \item
                                  Ver- und Entschlüsselung sollten nicht zu viele Ressourcen
                                  verbrauchen (Zeit, Speicher)
                        \end{itemize}
                  \item
                        Grundlegende Idee: Man nehme ein Problem aus dem Bereich der
                        Mathematik/Informatik, das schwer zu lösen ist, wenn man nur \$+K\$
                        kennt, aber leicht zu lösen, wenn man \$-K\$ kennt

                        \begin{itemize}
                            \item
                                  Knapsack-Probleme: Grundlage der ersten funktionierenden
                                  Algorithmen, die sich leider fast alle als unsicher erwiesen haben
                            \item
                                  Faktorisierungsproblem: Grundlage des RSA-Algorithmus
                            \item
                                  Diskreter-Logarithmus-Problem: Grundlage von Diffie-Hellman und
                                  ElGamal
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Einige mathematische
        Hintergründe}

    \begin{itemize}
        \item
              Sei \$\textbackslash mathbb\{Z\}\$ die Menge der ganzen Zahlen, und
              \$a,b,n\textbackslash in\textbackslash mathbb\{Z\}\$
        \item
              Wir sagen, \$a\$ teilt \$b(a\textbar b)\$, wenn es eine ganze Zahl
              \$k\textbackslash in\textbackslash mathbb\{Z\}\$ gibt, so dass
              \$a\textbackslash times k=b\$
        \item
              \$a\$ ist prim, wenn es positiv ist und die einzigen Teiler von a
              \$1\$ und \$a\$ sind.
        \item
              \$r\$ ist der Rest von a geteilt durch \$n\$, wenn
              \$r=a-\textbackslash lfloor a / n
              \textbackslash rfloor\textbackslash times n\$, wobei
              \$\textbackslash lfloor x\textbackslash rfloor\$ die größte ganze Zahl
              kleiner oder gleich \$x\$ ist.

              \begin{itemize}
                  \item
                        Beispiel: 4 ist der Rest von 11 geteilt durch 7 als
                        \$4=11-\textbackslash lfloor
                        11/7\textbackslash rfloor\textbackslash times 7\$
                  \item
                        Wir können dies auch anders schreiben: \$a=q\textbackslash times n +
                        r\$ mit \$q=\textbackslash lfloor a/n\textbackslash rfloor\$
              \end{itemize}
        \item
              Für den Rest \$r\$ der Division von a durch n schreiben wir
              \$a\textbackslash{} MOD\textbackslash{} n\$
        \item
              Wir sagen, b ist kongruent \$a\textbackslash{} mod\textbackslash{}
              n\$, wenn es bei der Division durch n den gleichen Rest wie a hat.
              Also teilt n \$(a-b)\$, und wir schreiben \$b\textbackslash equiv
              a\textbackslash{} mod\textbackslash{} n\$

              \begin{itemize}
                  \item
                        Beispiele: \$4\textbackslash equiv 11\textbackslash{}
                        mod\textbackslash{} 7\$, \$25\textbackslash equiv 11\textbackslash{}
                        mod\textbackslash{} 7\$, \$11\textbackslash equiv 25\textbackslash{}
                        mod\textbackslash{} 7\$, \$11\textbackslash equiv 4\textbackslash{}
                        mod\textbackslash{} 7\$, \$-10\textbackslash equiv 4\textbackslash{}
                        mod\textbackslash{} 7\$
              \end{itemize}
        \item
              Da der Rest r der Division durch n immer kleiner als n ist, stellt man
              manchmal die Menge \$\{x\textbackslash{} MOD\textbackslash{} n
              \textbar{} x\textbackslash in\textbackslash mathbb\{Z\}\}\$ durch
              Elemente der Menge \$\textbackslash mathbb\{Z\}\_n=\{0, 1, ...,
              n-1\}\$ dar
    \end{itemize}

    %\begin{longtable}[]{@{}ll@{}}
    %    \toprule
    %    Eigenschaft       & Ausdruck\tabularnewline
    %    \midrule
    %    \endhead
    %    Kommutativgesetze & \$(a + b)\textbackslash{} MOD\textbackslash{} n = (b
    %    + a)\textbackslash{} MOD\textbackslash{} n\$\tabularnewline
    %                      & \$(a \textbackslash times b)\textbackslash{} MOD\textbackslash{} n =
    %    (b \textbackslash times a)\textbackslash{} MOD\textbackslash{}
    %    n\$\tabularnewline
    %    Assoziativgesetze & \${[}(a + b) + c{]}\textbackslash{}
    %    MOD\textbackslash{} n = {[}a + (b + c){]}\textbackslash{}
    %    MOD\textbackslash{} n\$\tabularnewline
    %                      & \${[}(a \textbackslash times b) \textbackslash times
    %    c{]}\textbackslash{} MOD\textbackslash{} n = {[}a \textbackslash times
    %    (b \textbackslash times c){]}\textbackslash{} MOD\textbackslash{}
    %    n\$\tabularnewline
    %    Distributivgesetz & \${[}a \textbackslash times (b +
    %    c){]}\textbackslash{} MOD\textbackslash{} n = {[}(a \textbackslash times
    %    b) + (a \textbackslash times c){]}\textbackslash{} MOD\textbackslash{}
    %    n\$\tabularnewline
    %    Identitäten       & \$(0 + a)\textbackslash{} MOD\textbackslash{} n =
    %    a\textbackslash{} MOD\textbackslash{} n\$\tabularnewline
    %                      & \$(1 \textbackslash times a)\textbackslash{} MOD\textbackslash{} n =
    %    a\textbackslash{} MOD\textbackslash{} n\$\tabularnewline
    %    Inverse           & \$\textbackslash forall a \textbackslash in
    %    \textbackslash mathbb\{Z\}n: \textbackslash exists (-a)
    %    \textbackslash in \textbackslash mathbb\{Z\}n : a + (-a)
    %    \textbackslash equiv 0\textbackslash{} mod\textbackslash{}
    %    n\$\tabularnewline
    %                      & p is prime \$\textbackslash Rightarrow \textbackslash forall a
    %    \textbackslash in \textbackslash mathbb\{Z\}p: \textbackslash exists
    %    (a-1) \textbackslash in \textbackslash mathbb\{Z\}p: a
    %    \textbackslash times (a-1) \textbackslash equiv 1\textbackslash{}
    %    mod\textbackslash{} p\$\tabularnewline
    %    \bottomrule
    %\end{longtable}

    Größter gemeinsamer Teiler

    \begin{itemize}
        \item
              \$c = gcd(a, b) :\textbackslash Leftrightarrow ( c \textbar{} a)
              \textbackslash wedge ( c \textbar{} b) \textbackslash wedge
              {[}\textbackslash forall d: ( d \textbar{} a ) \textbackslash wedge (
              d \textbar{} b) \textbackslash Rightarrow ( d \textbar{} c ){]}\$ und
              \$gcd(a, 0 ) : = \textbar{} a \textbar\$
        \item
              Der gcd-Rekursionssatz :

              \begin{itemize}
                  \item
                        \$\textbackslash forall a, b \textbackslash in
                        \textbackslash mathbb\{Z\}\^{}+: gcd(a, b) = gcd(b,
                        a\textbackslash{} MOD\textbackslash{} b)\$
                  \item
                        Beweis:

                        \begin{itemize}
                            \item
                                  Da \$gcd(a, b)\$ sowohl a als auch b teilt, teilt es auch jede
                                  Linearkombination von ihnen, insbesondere \$(a-
                                  \textbackslash lfloor a / b \textbackslash rfloor
                                  \textbackslash times b) = a\textbackslash{} MOD\textbackslash{}
                                  b\$, also \$gcd(a, b) \textbar{} gcd(b, a\textbackslash{}
                                  MOD\textbackslash{} b)\$
                            \item
                                  Da \$gcd(b, a\textbackslash{} MOD\textbackslash{} b)\$ sowohl b
                                  als auch \$a\textbackslash{} MOD\textbackslash{} b\$ teilt, teilt
                                  es auch jede Linearkombination von beiden, insbesondere
                                  \$\textbackslash lfloor a / b \textbackslash rfloor
                                  \textbackslash times b + (a\textbackslash{} MOD\textbackslash{} b)
                                  = a\$, also \$gcd(b, a\textbackslash{} MOD\textbackslash{} b)
                                  \textbar{} gcd(a, b)\$
                        \end{itemize}
              \end{itemize}
        \item
              Euklidischer Algorithmus:

              \begin{itemize}
                  \item
                        Der euklidische Algorithmus berechnet aus a, b \$gcd(a, b)\$
              \end{itemize}

              %\begin{Shaded}
              %    \begin{Highlighting}[]
              %        \DataTypeTok{int}\NormalTok{ Euclid(}\DataTypeTok{int}\NormalTok{ a, b)\{}
              %        \ControlFlowTok{if}\NormalTok{ (b = }\DecValTok{0}\NormalTok{) \{ }\ControlFlowTok{return}\NormalTok{(a); \}}
              %        \NormalTok{  \{}\ControlFlowTok{return}\NormalTok{(Euclid(b, a\textbackslash{} MOD\textbackslash{} b);\} }
              %        \NormalTok{\}}
              %    \end{Highlighting}
              %\end{Shaded}
        \item
              Erweiterter euklidischer Algorithmus:

              \begin{itemize}
                  \item
                        Der Algorithmus ExtendedEuclid berechnet für a, b d, m, n so, dass:
                        \$d = gcd(a, b) = m \textbackslash times a + n \textbackslash times
                        b\$
              \end{itemize}

              %\begin{Shaded}
              %    \begin{Highlighting}[]
              %        \KeywordTok{struct}\NormalTok{\{}\DataTypeTok{int}\NormalTok{ d, m, n\} ExtendedEuclid(}\DataTypeTok{int}\NormalTok{ a, b)}
              %%        \NormalTok{\{ }\DataTypeTok{int}\NormalTok{ d, d}\CharTok{\textquotesingle{},}\ErrorTok{ m, m}\CharTok{\textquotesingle{}}\NormalTok{, n, n}\CharTok{\textquotesingle{};}
              %        \ControlFlowTok{if}\NormalTok{ (b = }\DecValTok{0}\NormalTok{) \{}\ControlFlowTok{return}\NormalTok{(a, }\DecValTok{1}\NormalTok{, }\DecValTok{0}\NormalTok{); \}}
              %        \NormalTok{  (d}\CharTok{\textquotesingle{},}\ErrorTok{ m}\CharTok{\textquotesingle{}}\NormalTok{, n}\CharTok{\textquotesingle{})}\ErrorTok{ = ExtendedEuclid(b, a MOD b);}
              %        \NormalTok{  (d, m, n) = (d}\CharTok{\textquotesingle{},}\ErrorTok{ n}\CharTok{\textquotesingle{}}\NormalTok{, m}\CharTok{\textquotesingle{} }\ErrorTok{{-} \textbackslash{}lfloor a / b \textbackslash{}rfloor \textbackslash{}times n}\CharTok{\textquotesingle{}}\NormalTok{);}
              %        \ControlFlowTok{return}\NormalTok{(d, m, n); \}}
              %    \end{Highlighting}
              %\end{Shaded}

              \begin{itemize}
                  \item
                        Beweis: (durch Induktion)

                        \begin{itemize}
                            \item
                                  Grundfall \$(a,0): gcd(a, 0) = a = 1 \textbackslash times a + 0
                                  \textbackslash times 0\$
                            \item
                                  Induktion von \$(b, a\textbackslash{} MOD\textbackslash{} b)\$ auf
                                  \$(a, b)\$:

                                  \begin{itemize}
                                      \item
                                            ExtendedEuclid berechnet \$d', m', n'\$ korrekt
                                            (Induktionshypothese)
                                      \item
                                            \$d=d'=m'\textbackslash times b+n'\textbackslash times
                                            (a\textbackslash{} MOD\textbackslash{} b)=m'\textbackslash times
                                            b+n'\textbackslash times (a-\textbackslash lfloor
                                            a/b\textbackslash rfloor\textbackslash times
                                            b)=n'\textbackslash times a+(m'-\textbackslash lfloor
                                            a/b\textbackslash rfloor\textbackslash times
                                            n')\textbackslash times b\$
                                  \end{itemize}
                        \end{itemize}
                  \item
                        Die Laufzeit von \$Euclid(a, b)\$ und \$ExtendedEuclid(a, b)\$ ist
                        von \$O(log\textbackslash{} b)\$

                        \begin{itemize}
                            \item
                                  Beweis: siehe {[}Cor90a{]}, Abschnitt 33.
                        \end{itemize}
                  \item
                        Lemma 1: Sei \$a,b\textbackslash in\textbackslash mathbb\{N\}\$ und
                        \$d=gcd(a,b)\$. Dann gibt es
                        \$m,n\textbackslash in\textbackslash mathbb\{N\}\$ so, dass:
                        \$d=m\textbackslash times a+n \textbackslash times b\$
              \end{itemize}
        \item
              Theorem 1 (Euklid): Wenn eine Primzahl das Produkt zweier ganzer
              Zahlen teilt, dann teilt sie mindestens eine der ganzen Zahlen:
              \$p\textbar(a\textbackslash times b)\textbackslash Rightarrow
              (p\textbar a)\textbackslash times(p\textbar b)\$

              \begin{itemize}
                  \item
                        Der Beweis: Es sei \$p\textbar(a\textbackslash times b)\$

                        \begin{itemize}
                            \item
                                  Wenn \$p\textbar a\$ dann sind wir fertig.
                            \item
                                  Wenn nicht, dann \$gcd(p,a) = 1
                                  \textbackslash Rightarrow\textbackslash exists m,
                                  n\textbackslash in\textbackslash mathbb\{N\}:1=m\textbackslash times
                                  p+n\textbackslash times a \textbackslash Leftrightarrow
                                  b=m\textbackslash times p \textbackslash times b + n
                                  \textbackslash times a \textbackslash times b\$
                            \item
                                  Da \$p\textbar(a\textbackslash times b)\$, teilt p beide Summanden
                                  der Gleichung und somit auch die Summe, die b ist
                        \end{itemize}
              \end{itemize}
        \item
              Theorem 2 (Fundamentalsatz der Arithmetik): Die Faktorisierung in
              Primzahlen ist bis zur Ordnung eindeutig.

              \begin{itemize}
                  \item
                        Der Beweis:

                        \begin{itemize}
                            \item
                                  Wir werden zeigen, dass jede ganze Zahl mit einer nicht
                                  eindeutigen Faktorisierung einen eigenen Teiler mit einer nicht
                                  eindeutigen Faktorisierung hat, was zu einem klaren Widerspruch
                                  führt, wenn wir schließlich auf eine Primzahl reduziert haben.
                            \item
                                  Nehmen wir an, dass n eine ganze Zahl mit einer nicht eindeutigen
                                  Faktorisierung ist: \$n=p\_1\textbackslash times
                                  p\_2\textbackslash times ...\textbackslash times p\_r=q\_1
                                  \textbackslash times q\_2\textbackslash times ...
                                  \textbackslash times q\_s\$. Die Primzahlen sind nicht
                                  notwendigerweise verschieden, aber die zweite Faktorisierung ist
                                  nicht einfach eine Umordnung der ersten. Da \$p\_1\$ n dividiert,
                                  dividiert es auch das Produkt \$q\_1\textbackslash times
                                  q\_2\textbackslash times ... \textbackslash times q\_s\$. Durch
                                  wiederholte Anwendung von Satz 1 zeigen wir, dass es mindestens
                                  ein \$q\_i\$ gibt, das durch \$p\_1\$ teilbar ist. Gegebenenfalls
                                  ordnen wir die \$q\_i\$'s so, dass es \$q\_1\$ ist. Da sowohl
                                  \$p\_1\$ als auch \$q\_1\$ Primzahlen sind, müssen sie gleich
                                  sein. Wir können also durch \$p\_1\$ dividieren und haben, dass
                                  \$n/p\_1\$ eine nicht-eindeutige Faktorisierung hat.
                        \end{itemize}
                  \item
                        Wir verwenden Theorem 2, um die folgende Korollarie 1 zu beweisen

                        \begin{itemize}
                            \item
                                  Wenn \$gcd(c,m)=1\$ und \$(a\textbackslash times
                                  c)\textbackslash equiv(b\textbackslash times c)mod\textbackslash{}
                                  m\$, dann \$a\textbackslash equiv b\textbackslash{}
                                  mod\textbackslash{} m\$
                            \item
                                  Der Beweis: Da \$(a\textbackslash times
                                  c)\textbackslash equiv(b\textbackslash times c)mod\textbackslash{}
                                  m\textbackslash Rightarrow\textbackslash exists
                                  n\textbackslash in\textbackslash mathbb\{N\}:(a\textbackslash times
                                  c)-(b\textbackslash times c)=n\textbackslash times m\$
                            \item
                                  \$\textbackslash Leftrightarrow ( a - b ) \textbackslash times c =
                                  n \textbackslash times m\$
                            \item
                                  \$\textbackslash Leftrightarrow p\_1\textbackslash times
                                  ...\textbackslash times p\_i\textbackslash times
                                  q\_1\textbackslash times ...\textbackslash times
                                  q\_j=r\_1\textbackslash times ...\textbackslash times
                                  r\_k\textbackslash times s\_1\textbackslash times
                                  ...\textbackslash times s\_l\$
                            \item
                                  Man beachte, dass die \$p\$'s, \$q\$'s, \$r\$'s und \$s\$'s
                                  Primzahlen sind und nicht verschieden sein müssen, aber da
                                  \$gcd(c,m)=1\$, gibt es keine Indizes g, h, so dass \$q\_g =
                                  s\_h\$.
                            \item
                                  Wir können also die Gleichung fortlaufend durch alle q's teilen,
                                  ohne jemals ein \$s\$ zu ,,eliminieren'' und erhalten schließlich
                                  etwas wie \$\textbackslash Leftrightarrow p\_1\textbackslash times
                                  ...\textbackslash times p\_i=r\_1\textbackslash times
                                  ...\textbackslash times r\_o\textbackslash times
                                  s\_1\textbackslash times ...\textbackslash times s\_l\$ (beachten
                                  Sie, dass es weniger r's geben wird)
                            \item
                                  \$\textbackslash Leftrightarrow(a-b)=r\_1\textbackslash times
                                  ...\textbackslash times r\_o\textbackslash times
                                  m\textbackslash Rightarrow a \textbackslash equiv
                                  b\textbackslash{} mod\textbackslash{} m\$
                        \end{itemize}
                  \item
                        Bezeichne \$\textbackslash phi(n)\$ die Anzahl der positiven ganzen
                        Zahlen, die kleiner als n und relativ zu n prim sind

                        \begin{itemize}
                            \item
                                  Beispiele: \$\textbackslash phi(4) = 2\$,
                                  \textbackslash phi(6)=2\$, \$\textbackslash phi(7)=6\$,
                                  \$\textbackslash phi(15)=8\$
                            \item
                                  Wenn p eine Primzahl ist
                                  \$\textbackslash Rightarrow\textbackslash phi(p)=p-1\$
                        \end{itemize}
              \end{itemize}
        \item
              Theorem 3 (Euler): Seien n und b positive und relativ primäre ganze
              Zahlen, d.h. \$gcd(n, b) = 1 \textbackslash Rightarrow b
              \textbackslash phi(n) \textbackslash equiv 1\textbackslash{}
              mod\textbackslash{} n\$

              \begin{itemize}
                  \item
                        Beweis:

                        \begin{itemize}
                            \item
                                  Sei \$t=\textbackslash phi(n)\$ und \$a\_1,...a\_t\$ seien die
                                  positiven ganzen Zahlen kleiner als \$n\$, die relativ zu \$n\$
                                  prim sind. Definieren Sie \$r\_1,...,r\_t\$ als die Residuen von
                                  \$b\textbackslash times a\_1\textbackslash{} mod\textbackslash{} n
                                  , ..., b\textbackslash times a\_t\textbackslash{}
                                  mod\textbackslash{} n\$, d.h.: \$b\textbackslash times a\_i
                                  \textbackslash equiv r\_i\textbackslash{} mod\textbackslash{} n\$.
                            \item
                                  Beachten Sie, dass \$i\textbackslash not= j
                                  \textbackslash Rightarrow r\_i\textbackslash not= r\_j\$. Wäre
                                  dies nicht der Fall, hätten wir \$b\textbackslash times
                                  a\_i\textbackslash equiv b\textbackslash times
                                  a\_j\textbackslash{} mod\textbackslash{} n\$ und da
                                  \$gcd(b,n)=1\$, würde Korollar 1 \$a\_i\textbackslash equiv
                                  a\_j\textbackslash{} mod\textbackslash{} n\$ implizieren, was
                                  nicht sein kann, da \$a\_i\$ und \$a\_j\$ per Definition
                                  verschiedene ganze Zahlen zwischen 0 und n sind
                            \item
                                  Wir wissen auch, dass jedes \$r\_i\$ relativ prim zu n ist, denn
                                  jeder gemeinsame Teiler k von \$r\_i\$ und \$n\$ , d.h.
                                  \$n=k\textbackslash times m\$ und \$r\_i=p\_i\textbackslash times
                                  k\$, müsste auch \$a\_i\$ teilen,
                            \item
                                  da \$b\textbackslash times a\_i\$gleich (p\_i\textbackslash times
                                  k)\textbackslash{} mod\textbackslash{} (k\textbackslash times
                                  m)\textbackslash Rightarrow\textbackslash exists
                                  s\textbackslash in\textbackslash mathbb\{N\}:(b\textbackslash times
                                  a\_i)-(p\_i\textbackslash times k)=s\textbackslash times
                                  k\textbackslash times m \textbackslash Leftrightarrow
                                  (b\textbackslash times a\_i)=s\textbackslash times
                                  k\textbackslash times m+(p\_i\textbackslash times k)\$
                            \item
                                  Da k jeden der Summanden auf der rechten Seite dividiert und k
                                  nicht durch b dividiert (n und b sind relativ prim), müsste es
                                  auch \$a\_i\$ dividieren, das relativ prim zu n sein soll
                            \item
                                  Somit ist \$r\_1, ...,r\_t\$ eine Menge von
                                  \$\textbackslash phi(n)\$ verschiedenen ganzen Zahlen, die relativ
                                  prim zu \$n\$ sind. Das bedeutet, dass sie genau dasselbe sind wie
                                  \$a\_1,...a\_t\$, nur dass sie in einer anderen Reihenfolge
                                  stehen. Insbesondere wissen wir, dass \$r\_1\textbackslash times
                                  ...\textbackslash times r\_t=a\_1\textbackslash times
                                  ...\textbackslash times a\_t\$
                            \item
                                  Wir verwenden nun die Kongruenz \$r\_1\textbackslash times
                                  ...\textbackslash times r\_t\textbackslash equiv
                                  b\textbackslash times a\_1\textbackslash times
                                  ...\textbackslash times b\textbackslash times a\_t\textbackslash{}
                                  mod\textbackslash{} n\$ \$\textbackslash Leftrightarrow
                                  r\_1\textbackslash times ...\textbackslash times
                                  r\_t\textbackslash equiv b\_t\textbackslash times
                                  a\_1\textbackslash times ...\textbackslash times
                                  a\_t\textbackslash{} mod\textbackslash{} n\$
                                  \$\textbackslash Leftrightarrow r\_1\textbackslash times
                                  ...\textbackslash times r\_t\textbackslash equiv
                                  b\_\textbackslash times r\_1\textbackslash times
                                  ...\textbackslash times r\_t\textbackslash{} mod\textbackslash{}
                                  n\$
                            \item
                                  Da alle \$r\_i\$ relativ prim zu \$n\$ sind, können wir Korollar 1
                                  anwenden und durch ihr Produkt dividieren: \$1\textbackslash equiv
                                  b\_t\textbackslash{} mod\textbackslash{} n
                                  \textbackslash Leftrightarrow 1\textbackslash equiv
                                  b\textbackslash phi(n)\textbackslash{} mod n\$
                        \end{itemize}
              \end{itemize}
        \item
              Satz 4 (Chinese Remainder Theorem):

              \begin{itemize}
                  \item
                        Seien \$m\_1,...,m\_r\$ positive ganze Zahlen, die paarweise relativ
                        prim sind,
                  \item
                        d.h. \$ganz i\textbackslash not= j:gcd(m\_i, m\_j) = 1\$. Seien
                        \$a\_1,...,a\_r\$ beliebige ganze Zahlen.
                  \item
                        Dann gibt es eine ganze Zahl a derart, dass:

                        \begin{itemize}
                            \item
                                  \$a\textbackslash equiv a\_1\textbackslash{} mod\textbackslash{}
                                  m\_1\$
                            \item
                                  \$a\textbackslash equiv a\_2\textbackslash{} mod\textbackslash{}
                                  m\_2\$
                            \item
                                  ...
                            \item
                                  \$a\textbackslash equiv a\_r\textbackslash{} mod\textbackslash{}
                                  m\_r\$
                        \end{itemize}
                  \item
                        Außerdem ist a eindeutig modulo \$M := m\_1\textbackslash times
                        ...\textbackslash times m\_r\$
                  \item
                        Beweis:

                        \begin{itemize}
                            \item
                                  Für alle \$i\textbackslash in\{1,...,r\}\$ definieren wir
                                  \$M\_i:=(M/m\_i)\textbackslash phi(m\_i)\$
                            \item
                                  Da \$M\_i\$ per Definition relativ prim zu \$m\_i\$ ist, können
                                  wir Theorem 3 anwenden und wissen, dass \$M\_i\textbackslash equiv
                                  1\textbackslash{} mod\textbackslash{} m\_i\$
                            \item
                                  Da \$M\_i\$ durch \$m\_j\$ für jedes \$j\textbackslash not= i\$
                                  teilbar ist, haben wir \$\textbackslash forall
                                  j\textbackslash not= i:M\_i\textbackslash equiv 0\textbackslash{}
                                  mod\textbackslash{} m\_j\$
                            \item
                                  Wir können nun die Lösung konstruieren, indem wir definieren:
                                  \$a:= a\_1\textbackslash times M\_1+a\_2\textbackslash times
                                  M\_2+...+a\_r\textbackslash times M\_r\$
                            \item
                                  Die beiden oben angeführten Argumente bezüglich der Kongruenzen
                                  der \$M\_i\$ implizieren, dass a tatsächlich alle Kongruenzen
                                  erfüllt.
                            \item
                                  Um zu sehen, dass a eindeutig modulo \$M\$ ist, sei b eine
                                  beliebige andere ganze Zahl, die die r Kongruenzen erfüllt. Da
                                  \$a\textbackslash equiv c\textbackslash{} mod\textbackslash{} n\$
                                  und \$b\textbackslash equiv c\textbackslash{} mod\textbackslash{}
                                  n \textbackslash Rightarrow a \textbackslash equiv
                                  b\textbackslash{} mod\textbackslash{} n\$ haben wir
                                  \$\textbackslash forall
                                  i\textbackslash in\{1,...,r\}:a\textbackslash equiv
                                  b\textbackslash{} mod\textbackslash{}
                                  m\_i\textbackslash Rightarrow\textbackslash forall
                                  i\textbackslash in\{1,. ...,r\}:m\_i\textbar(a-b)
                                  \textbackslash Rightarrow M\textbar(a-b)\$, da die \$m\_i\$
                                  paarweise relativ prim sind \$\textbackslash Leftrightarrow
                                  a\textbackslash equiv b\textbackslash{} mod\textbackslash{} M\$
                        \end{itemize}
              \end{itemize}
        \item
              Lemma 2:

              \begin{itemize}
                  \item
                        Wenn \$gcd(m,n)=1\$, dann ist
                        \$\textbackslash phi(m\textbackslash times
                        n)=\textbackslash phi(m)\textbackslash times \textbackslash phi(n)\$
                  \item
                        Der Beweis:

                        \begin{itemize}
                            \item
                                  Sei a eine positive ganze Zahl, die kleiner als und relativ prim
                                  zu \$m\textbackslash times n\$ ist. Mit anderen Worten: a ist eine
                                  der ganzen Zahlen, die von
                                  \$\textbackslash phi(m\textbackslash times n)\$ gezählt werden.
                            \item
                                  Betrachten Sie die Entsprechung
                                  \$a\textbackslash rightarrow(a\textbackslash{} MOD\textbackslash{}
                                  m, a\textbackslash{} MOD\textbackslash{} n)\$. Die ganze Zahl a
                                  ist relativ prim zu m und relativ prim zu n (andernfalls würde sie
                                  \$m \textbackslash times n\$ teilen). Also ist
                                  \$(a\textbackslash{} MOD\textbackslash{} m)\$ relativ prim zu m
                                  und \$(a\textbackslash{} MOD\textbackslash{} n)\$ ist relativ prim
                                  zu n, da: \$a=\textbackslash lfloor
                                  a/m\textbackslash rfloor\textbackslash times m +
                                  (a\textbackslash{} MOD\textbackslash{} m)\$, wenn es also einen
                                  gemeinsamen Teiler von \$m\$ und \$(a\textbackslash{}
                                  MOD\textbackslash{} m)\$ gäbe, würde dieser Teiler auch a teilen.
                                  Somit entspricht jede Zahl a, die durch
                                  \$\textbackslash phi(m\textbackslash times n )\$ gezählt wird,
                                  einem Paar von zwei ganzen Zahlen \$(a\textbackslash{}
                                  MOD\textbackslash{} m,a\textbackslash{} MOD\textbackslash{} n)\$,
                                  wobei die erste durch \$\textbackslash phi(m)\$ und die zweite
                                  durch \$\textbackslash phi(n)\$ gezählt wird.
                            \item
                                  Aufgrund des zweiten Teils von Satz 4 ist die Einzigartigkeit der
                                  Lösung \$a\textbackslash{} mod\textbackslash{}
                                  (m\textbackslash times n)\$ der simultanen Kongruenzen: \$a
                                  \textbackslash equiv(a\textbackslash{} mod\textbackslash{}
                                  m)\textbackslash{} mod\textbackslash{} m\$ \$a
                                  \textbackslash equiv(a\textbackslash{} MOD\textbackslash{}
                                  n)\textbackslash{} mod\textbackslash{} n\$ können wir ableiten,
                                  dass verschiedene ganze Zahlen, die durch
                                  \$\textbackslash phi(m\textbackslash times n)\$ gezählt werden,
                                  verschiedenen Paaren entsprechen:

                                  \begin{itemize}
                                      \item
                                            Um dies zu sehen, nehmen wir an, dass \$a\textbackslash not=b\$,
                                            gezählt durch \$\textbackslash phi(m\textbackslash times n)\$,
                                            demselben Paar \$(a\textbackslash{} MOD\textbackslash{} m,
                                            a\textbackslash{} MOD\textbackslash{} n)\$ entspricht. Dies
                                            führt zu einem Widerspruch, da b auch die Kongruenzen erfüllen
                                            würde: \$b\textbackslash equiv (a\textbackslash{}
                                            MOD\textbackslash{} m)\textbackslash{} mod\textbackslash{} m\$
                                            \$b\textbackslash equiv (a\textbackslash{} MOD\textbackslash{}
                                            n)\textbackslash{} mod\textbackslash{} n\$ aber die Lösung
                                            dieser Kongruenzen ist eindeutig modulo \$(m
                                            \textbackslash times n)\$
                                      \item
                                            Daher ist \$\textbackslash phi(m \textbackslash times n)\$
                                            höchstens die Anzahl solcher Paare: \$\textbackslash phi(m
                                            \textbackslash times n)\textbackslash leq
                                            \textbackslash phi(m)\textbackslash times
                                            \textbackslash phi(n)\$
                                  \end{itemize}
                            \item
                                  Betrachten wir nun ein Paar von ganzen Zahlen \$(b,c)\$, von denen
                                  eine mit \$\textbackslash phi(m)\$ und die andere mit
                                  \$\textbackslash phi(n)\$ gezählt wird: Mit Hilfe des ersten Teils
                                  von Satz 4 können wir eine einzige positive ganze Zahl a
                                  konstruieren, die kleiner als und relativ prim zu
                                  \$m\textbackslash times n\$ ist: \$a\textbackslash equiv
                                  b\textbackslash{} mod\textbackslash{} m\$ und
                                  \$a\textbackslash equiv c\textbackslash{} mod\textbackslash{} n\$.
                                  Die Anzahl solcher Paare ist also höchstens \$\textbackslash phi(m
                                  \textbackslash times n):\textbackslash phi(m \textbackslash times
                                  n)\textbackslash leq\textbackslash phi(m)\textbackslash times\textbackslash phi(n)\$
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Der RSA Public Key
        Algorithmus}

    \begin{itemize}
        \item
              Der RSA-Algorithmus wurde 1977 von R. Rivest, A. Shamir und L. Adleman
              {[}RSA78{]} erfunden und basiert auf Theorem 3.
        \item
              Seien \$p, q\$ verschiedene große Primzahlen und
              \$n=p\textbackslash times q\$. Nehmen wir an, wir haben auch zwei
              ganze Zahlen e und d, so dass: \$d\textbackslash times e
              \textbackslash equiv 1\textbackslash{} mod\textbackslash{}
              \textbackslash phi(n)\$
        \item
              M sei eine ganze Zahl, die die zu verschlüsselnde Nachricht darstellt,
              wobei M positiv, kleiner als und relativ prim zu n ist.

              \begin{itemize}
                  \item
                        Beispiel: Verschlüsseln mit = 99, A = 10, B = 11, ..., Z = 35. Somit
                        würde ,,HELLO'' als 1714212124 kodiert werden. Falls erforderlich,
                        ist M in Blöcke kleinerer Nachrichten aufzuteilen: 17142 12124
              \end{itemize}
        \item
              Zum Verschlüsseln berechnen Sie: \$E = M\^{}e\textbackslash{}
              MOD\textbackslash{} n\$

              \begin{itemize}
                  \item
                        Dies kann mit dem Quadrat- und Multiplikationsalgorithmus effizient
                        durchgeführt werden
              \end{itemize}
        \item
              Zum Entschlüsseln berechnet man: \$M'=E\^{}d\textbackslash{}
              MOD\textbackslash{} n\$

              \begin{itemize}
                  \item
                        Da \$d\textbackslash times e\textbackslash equiv 1\textbackslash{}
                        mod\textbackslash{}
                        \textbackslash phi(n)\textbackslash Rightarrow\textbackslash exists
                        k\textbackslash in\textbackslash mathbb\{Z\}:(d\textbackslash times
                        e)-1=k\textbackslash times\textbackslash phi(n)\textbackslash Leftrightarrow(d\textbackslash times
                        e)=k\textbackslash times\textbackslash phi(n)+1\$
                  \item
                        haben wir: \$M'\textbackslash equiv E\^{}d\textbackslash equiv
                        M\^{}\{e\textbackslash times d\}\textbackslash equiv
                        M\^{}\{k\textbackslash times\textbackslash phi(n)+1\}\textbackslash equiv
                        1\^{}k\textbackslash times M\textbackslash equiv M\textbackslash{}
                        mod\textbackslash{} n\$
              \end{itemize}
        \item
              Da \$(d\textbackslash times e)=(e\textbackslash times d)\$
              funktioniert die Operation auch in umgekehrter Richtung, d.h. man kann
              mit d verschlüsseln und mit e entschlüsseln

              \begin{itemize}
                  \item
                        Diese Eigenschaft erlaubt es, die gleichen Schlüssel d und e zu
                        verwenden:
                  \item
                        den Empfang von Nachrichten, die mit dem eigenen öffentlichen
                        Schlüssel verschlüsselt wurden
                  \item
                        Senden von Nachrichten, die mit dem eigenen privaten Schlüssel
                        signiert wurden
              \end{itemize}
        \item
              So richten Sie ein Schlüsselpaar für RSA ein:

              \begin{itemize}
                  \item
                        Wählen Sie zufällig zwei Primzahlen \$p\$ und \$q\$ (mit jeweils 100
                        bis 200 Ziffern)
                  \item
                        Berechne \$n=p\textbackslash times
                        q,\textbackslash phi(n)=(p-1)\textbackslash times (q-1)\$ (Lemma 2)
                  \item
                        Wähle zufällig \$e\$, so dass \$gcd(e,\textbackslash phi(n))=1\$
                  \item
                        Berechne mit dem erweiterten euklidischen Algorithmus d und c, so
                        dass: \$e\textbackslash times
                        d+\textbackslash phi(n)\textbackslash times c = 1\$, wobei zu
                        beachten ist, dass dies impliziert, dass \$e\textbackslash times
                        d\textbackslash equiv 1\textbackslash{} mod\textbackslash{}
                        \textbackslash phi(n)\$
                  \item
                        Der öffentliche Schlüssel ist das Paar \$(e, n)\$
                  \item
                        Der private Schlüssel ist das Paar \$(d, n)\$
              \end{itemize}
        \item
              Die Sicherheit des Verfahrens liegt in der Schwierigkeit der
              Faktorisierung von \$n=p\textbackslash times q\$, da es einfach ist,
              \$\textbackslash phi(n)\$ und dann \$d\$ zu berechnen, wenn \$p\$ und
              \$q\$ bekannt sind.
        \item
              In diesem Kurs wird nicht gelehrt, warum es schwierig ist, große n zu
              faktorisieren, da dies einen tiefen Einblick in die Mathematik
              erfordern würde.

              \begin{itemize}
                  \item
                        Wenn p und q bestimmte Eigenschaften erfüllen, sind die besten
                        bekannten Algorithmen exponentiell zur Anzahl der Ziffern von n
                  \item
                        Bitte beachten Sie, dass es bei einer unglücklichen Wahl von p und q
                        Algorithmen geben könnte, die effizienter faktorisieren können, und
                        dass Ihre RSA-Verschlüsselung dann nicht mehr sicher ist:

                        \begin{itemize}
                            \item
                                  Daher sollten p und q ungefähr die gleiche Bitlänge haben und
                                  ausreichend groß sein
                            \item
                                  \$(p-q)\$ sollte nicht zu klein sein
                            \item
                                  Wenn man einen kleinen Verschlüsselungsexponenten, z.B. 3, wählen
                                  will, kann es zusätzliche Einschränkungen geben, z.B. \$gcd(p-1,
                                  3) = 1\$ und \$gcd(q-1,3)=1\$
                        \end{itemize}
                  \item
                        Die Sicherheit von RSA hängt auch davon ab, dass die erzeugten
                        Primzahlen wirklich zufällig sind (wie jede Methode zur
                        Schlüsselerzeugung bei jedem Algorithmus).
                  \item
                        Moral: Wenn Sie RSA selbst implementieren wollen, bitten Sie einen
                        Mathematiker oder besser einen Kryptographen, Ihren Entwurf zu
                        überprüfen.
              \end{itemize}
    \end{itemize}


    \subsection{Einige weitere mathematische
        Hintergründe}

    \begin{itemize}
        \item
              Definition: endliche Gruppen

              \begin{itemize}
                  \item
                        Eine Gruppe ( S , \textbackslash oplus) ist eine Menge S zusammen
                        mit einer binären Operation \textbackslash oplus, für die die
                        folgende Eigenschaften gelten:

                        \begin{itemize}
                            \item
                                  Geschlossenheit: Für alle a, b \textbackslash in S , haben wir a
                                  \textbackslash oplus b \textbackslash in S
                            \item
                                  Identität: Es gibt ein Element e \textbackslash in S , so dass e
                                  \textbackslash oplus a = a \textbackslash oplus e = a für alle a
                                  \textbackslash in S
                            \item
                                  Assoziativität: Für alle a, b, c \textbackslash in S , gilt ( a
                                  \textbackslash oplus b ) \textbackslash oplus c = a
                                  \textbackslash oplus ( b \textbackslash oplus c )
                            \item
                                  Inversen: Für jedes a \textbackslash in S , gibt es ein einziges
                                  Element b \textbackslash in S , so dass dass a
                                  \textbackslash oplus b = b \textbackslash oplus a = e
                        \end{itemize}
                  \item
                        Erfüllt eine Gruppe ( S , \textbackslash oplus) das Kommutativgesetz
                        \textbackslash forall a, b \textbackslash in S : a
                        \textbackslash oplus b = b \textbackslash oplus a dann nennt man sie
                        eine abelsche Gruppe
                  \item
                        Wenn eine Gruppe ( S , \textbackslash oplus) nur eine endliche Menge
                        von Elementen hat, d.h. \textbar S\textbar{} \textless{}
                        \textbackslash infty, dann wird sie eine endliche Gruppe genannt
              \end{itemize}
        \item
              Beispiele:

              \begin{itemize}
                  \item
                        \$(\textbackslash mathbb\{Z\}\_n , +\_n)\$

                        \begin{itemize}
                            \item
                                  mit
                                  \$\textbackslash mathbb\{Z\}\_n:=\{{[}0{]}\_n,{[}1{]}\_n,...,{[}n-1{]}\_n\}\$
                            \item
                                  wobei \${[}a{]}\_n:=\{b \textbackslash in
                                  \textbackslash mathbb\{Z\} \textbar{} b \textbackslash equiv a mod
                                  n\}\$ und
                            \item
                                  \$+\_n\$ ist so definiert, dass
                                  \${[}a{]}\_n+\_n{[}b{]}\_n={[}a+b{]}\_n\$
                            \item
                                  eine endliche abelsche Gruppe ist. Für den Beweis siehe die
                                  Tabelle mit den Eigenschaften der modularen Arithmetik
                        \end{itemize}
                  \item
                        \$(\textbackslash mathbb\{Z\}\^{}*\_n , \textbackslash times\_n)\$

                        \begin{itemize}
                            \item
                                  mit \$\textbackslash mathbb\{Z\}\^{}*\_n
                                  :=\{{[}a{]}\_n\textbackslash in \textbackslash mathbb\{Z\}\_n
                                  \textbar{} gcd(a,n)=1\}\$, und
                            \item
                                  \$\textbackslash times\_n\$ ist so definiert, dass
                                  \${[}a{]}\_n\textbackslash times\_n
                                  {[}b{]}\_n={[}a\textbackslash times b{]}\_n\$
                            \item
                                  eine endliche abelsche Gruppe ist. Man beachte, dass
                                  \$\textbackslash mathbb\{Z\}\^{}*\_n\$ nur die Elemente von
                                  \$\textbackslash mathbb\{Z\}\_n\$ enthält, die eine multiplikative
                                  Inverse modulo n haben. Zum Beweis siehe Eigenschaften der
                                  modularen Arithmetik
                            \item
                                  Beispiel:
                                  \$\textbackslash mathbb\{Z\}\^{}*\emph{\{15\}=\{{[}1{]}}\{15\},{[}2{]}\emph{\{15\},{[}4{]}}\{15\},{[}7{]}\emph{\{15\},{[}8{]}}\{15\},{[}11{]}\emph{\{15\},{[}13{]}}\{15\},{[}14{]}\_\{15\}\}\$,
                                  als \$1\textbackslash times 1\textbackslash equiv 1 mod 15\$, \$2
                                  \textbackslash times 8 \textbackslash equiv 1 mod 15\$, \$4
                                  \textbackslash times 4 \textbackslash equiv 1 mod 15\$, \$7
                                  \textbackslash times 13 \textbackslash equiv 1 mod 15\$, \$11
                                  \textbackslash times 11 \textbackslash equiv 1 mod 15\$, \$14
                                  \textbackslash times 14 \textbackslash equiv 1 mod 15\$
                        \end{itemize}
              \end{itemize}
        \item
              Wenn klar ist, dass es sich um \$(\textbackslash mathbb\{Z\}\_n,
              +\_n)\$ oder \$(\textbackslash mathbb\{Z\}\^{}*\_n,
              \textbackslash times\_n)\$ handelt, werden Äquivalenzklassen
              \${[}a{]}\_n\$ oft durch ihre repräsentativen Elemente a dargestellt
              und \$+\_n\$ und \$\textbackslash times\_n\$ durch \$+\$ bzw.
              \$\textbackslash times\$ bezeichnet.

              \begin{itemize}
                  \item
                        Definition: endliche Felder

                        \begin{itemize}
                            \item
                                  Ein Feld \$(S,\textbackslash oplus, \textbackslash otimes)\$ ist
                                  eine Menge S zusammen mit zwei Operationen
                                  \$\textbackslash oplus\$, \$\textbackslash otimes\$, so dass

                                  \begin{itemize}
                                      \item
                                            \$(S,\textbackslash oplus)\$ und
                                            \$(S\textbackslash backslash\{e\_\{\textbackslash oplus\}\},\textbackslash otimes)\$
                                            sind kommutative Gruppen, d.h. nur das Identitätselement
                                            bezüglich der Operation \$\textbackslash oplus\$ muss kein
                                            Inverses bezüglich der Operation \$\textbackslash otimes\$ haben
                                      \item
                                            Für alle \$a,b,c\textbackslash in S\$ haben wir ein
                                            \$\textbackslash otimes(b\textbackslash oplus
                                            c)=(a\textbackslash otimes
                                            b)\textbackslash oplus(a\textbackslash otimes c)\$
                                  \end{itemize}
                        \end{itemize}
                  \item
                        Wenn \$\textbar S\textbar\textless\textbackslash infty\$ dann heißt
                        \$(S,\textbackslash oplus,\textbackslash otimes)\$ ein endliches
                        Feld
              \end{itemize}
        \item
              Beispiel: \$(\textbackslash mathbb\{Z\}\_p, +\_p,
              \textbackslash times\_p)\$ ist ein endliches Feld für jede Primzahl p
        \item
              Definition: Primitive Wurzel, Generator

              \begin{itemize}
                  \item
                        Sei \$(S,\textbackslash circ)\$ eine Gruppe, \$g\textbackslash in
                        S\$ und \$g\^{}a:=g\textbackslash circ
                        g\textbackslash circ...\textbackslash circ g\$ (a mal mit
                        \$a\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$)
                  \item
                        Dann heißt g eine primitive Wurzel oder ein Generator von
                        \$(S,\textbackslash circ):\textbackslash Leftrightarrow\{g\^{}a\textbar1\textbackslash leq
                        a\textbackslash leq \textbar S\textbar\}=S\$
                  \item
                        Beispiele:

                        \begin{itemize}
                            \item
                                  1 ist eine primitive Wurzel von \$(\textbackslash mathbb\{Z\}\_n,
                                  +\_n)\$
                            \item
                                  3 ist eine Primitivwurzel von
                                  \$(\textbackslash mathbb\{Z\}\^{}*\_7, \textbackslash times\_7)\$
                        \end{itemize}
                  \item
                        Nicht alle Gruppen haben Primitivwurzeln, und diejenigen, die sie
                        haben, nennt man zyklische Gruppen
              \end{itemize}
        \item
              Theorem 5:

              \begin{itemize}
                  \item
                        \$(\textbackslash mathbb\{Z\}\^{}*\_n, \textbackslash times\_n)\$
                        hat eine primitive Wurzel \$\textbackslash Leftrightarrow
                        n\textbackslash in\{2,4,p,2\textbackslash times p\^{}e\}\$, wobei p
                        eine ungerade Primzahl ist und
                        \$e\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$
              \end{itemize}
        \item
              Theorem 6:

              \begin{itemize}
                  \item
                        Wenn \$(S,\textbackslash circ)\$ eine Gruppe ist und
                        \$b\textbackslash in S\$, dann ist \$(S',\textbackslash circ)\$ mit
                        \$S'=\{b\^{}a\textbar a\textbackslash in\textbackslash mathbb\{Z\}\^{}+\}\$
                        ebenfalls eine Gruppe.
                  \item
                        Da \$S'\textbackslash subseteq S, heißt (S',\textbackslash circ)\$
                        eine Untergruppe von \$(S,\textbackslash circ)\$
                  \item
                        Wenn b eine Urwurzel von \$(S,\textbackslash circ)\$ ist, dann ist
                        \$S'=S\$
              \end{itemize}
        \item
              Definition: Ordnung einer Gruppe und eines Elements

              \begin{itemize}
                  \item
                        Sei \$(S,\textbackslash circ)\$ eine Gruppe, \$e\textbackslash in
                        S\$ ihr Identitätselement und \$b\textbackslash in S\$ irgendein
                        Element von \$S\$:

                        \begin{itemize}
                            \item
                                  Dann heiße \$\textbar S\textbar\$ die Ordnung von
                                  \$(S,\textbackslash circ)\$
                            \item
                                  Sei \$c\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ das
                                  kleinste Element, so dass \$b\^{}c=e\$ ist (falls ein solches c
                                  existiert, falls nicht, setze \$c=\textbackslash infty\$). Dann
                                  wird c die Ordnung von b genannt.
                        \end{itemize}
              \end{itemize}
        \item
              Theorem 7 (Lagrange):

              \begin{itemize}
                  \item
                        Ist G eine endliche Gruppe und H eine Untergruppe von G , so ist
                        \$\textbar H\textbar\$ Teiler von \$\textbar G\textbar\$.
                  \item
                        Wenn also \$b in G\$ ist, dann ist die Ordnung von b Teiler von
                        \$\textbar G\textbar\$.
              \end{itemize}
        \item
              Theorem 8:

              \begin{itemize}
                  \item
                        Ist G eine zyklische endliche Gruppe der Ordnung n und d ist Teiler
                        von n, dann hat G genau \$\textbackslash phi(d)\$ Elemente der
                        Ordnung \$d\$. Insbesondere hat G \$\textbackslash phi(n)\$-Elemente
                        der Ordnung n.
              \end{itemize}
        \item
              Die Theoreme 5, 7 und 8 sind die Grundlage des folgenden Algorithmus,
              der eine zyklische Gruppe \$\textbackslash mathbb\{Z\}\^{}*\_p\$ und
              eine Urwurzel g davon findet:

              \begin{itemize}
                  \item
                        Man wählt eine große Primzahl q, so dass \$p=2q+1\$ eine Primzahl
                        ist.

                        \begin{itemize}
                            \item
                                  Da \$p\$ prim ist, besagt Satz 5, dass
                                  \$\textbackslash mathbb\{Z\}\^{}*\_p\$ zyklisch ist.
                            \item
                                  Die Ordnung von \$\textbackslash mathbb\{Z\}\^{}*\_p\$ ist
                                  \$2\textbackslash times q\$ und
                                  \$\textbackslash phi(2\textbackslash times
                                  q)=\textbackslash phi(2)\textbackslash times
                                  \textbackslash phi(q)=q-1\$, da \$q\$ prim ist.
                            \item
                                  Die Wahrscheinlichkeit, dass eine Primitivwurzel zufällig
                                  ausgewählt wird, beträgt also \$(q-1)/2q \textbackslash approx
                                  1/2\$.
                            \item
                                  Um effizient zu prüfen, ob ein zufällig gewähltes g eine Urwurzel
                                  ist, müssen wir nur prüfen, ob \$g\^{}2\textbackslash equiv 1 mod
                                  p\$ oder \$g\^{}q\textbackslash equiv 1 mod p\$ ist. Wenn nicht,
                                  dann muss seine Ordnung
                                  \$\textbar\textbackslash mathbb\{Z\}\^{}\emph{\_p\textbar\$ sein,
                                  da Satz 7 besagt, dass die Ordnung von g
                                  \$\textbar\textbackslash mathbb\{Z\}\^{}}\_p\textbar\$ teilen muss
                        \end{itemize}
              \end{itemize}
        \item
              Definition: diskreter Logarithmus

              \begin{itemize}
                  \item
                        Sei p eine Primzahl, g eine Urwurzel von
                        \$(\textbackslash mathbb\{Z\}\^{}\emph{\_p,\textbackslash times\_p)\$
                        und c ein beliebiges Element von
                        \$\textbackslash mathbb\{Z\}\^{}}\_p\$. Dann gibt es z so, dass:
                        \$g\^{}z\textbackslash equiv c mod p\$
                  \item
                        z wird der diskrete Logarithmus von c modulo p zur Basis g genannt
                  \item
                        Beispiel 6 ist der diskrete Logarithmus von 1 modulo 7 zur Basis 3
                        als \$3\^{}6\textbackslash equiv 1 mod 7\$
                  \item
                        Die Berechnung des diskreten Logarithmus z bei gegebenem g, c und p
                        ist ein rechnerisch schwieriges Problem, und die asymptotische
                        Laufzeit der besten bekannten Algorithmen für dieses Problem ist
                        exponentiell zur Bitlänge von p
              \end{itemize}
    \end{itemize}


    \subsection{Diffie-Hellman-Schlüsselaustausch}

    \begin{itemize}
        \item
              Der Diffie-Hellman-Schlüsselaustausch wurde erstmals in der
              bahnbrechenden Arbeit {[}DH76{]} veröffentlicht, in der auch die
              Grundidee der asymmetrischen Kryptographie vorgestellt wurde
        \item
              Der DH-Austausch in seiner Grundform ermöglicht es zwei Parteien A und
              B, sich über einen öffentlichen Kanal auf ein gemeinsames Geheimnis zu
              einigen:

              \begin{itemize}
                  \item
                        Öffentlicher Kanal bedeutet, dass ein potentieller Angreifer E (E
                        steht für Eavesdropper) alle zwischen A und B ausgetauschten
                        Nachrichten lesen kann
                  \item
                        Es ist wichtig, dass A und B sicher sein können, dass der Angreifer
                        nicht in der Lage ist, Nachrichten zu verändern, da er in diesem
                        Fall einen Man-in-the-Middle-Angriff starten könnte
                  \item
                        Die mathematische Grundlage für den DH-Austausch ist das Problem,
                        diskrete Logarithmen in endlichen Feldern zu finden.
                  \item
                        Der DH-Austausch ist kein asymmetrischer
                        Verschlüsselungsalgorithmus, wird aber dennoch hier vorgestellt, da
                        er gut zum mathematischen Charakter dieser Vorlesung passt...
              \end{itemize}
        \item
              Wenn Alice (A) und Bob (B) sich auf ein gemeinsames Geheimnis s
              einigen wollen und ihr einziges Kommunikationsmittel ein öffentlicher
              Kanal ist, können sie wie folgt vorgehen:

              \begin{itemize}
                  \item
                        A wählt eine Primzahl p, eine primitive Wurzel g von
                        \$\textbackslash mathbb\{Z\}\^{}*\_p\$ und eine Zufallszahl q:

                        \begin{itemize}
                            \item
                                  A und B können sich vor der Kommunikation auf die Werte p und g
                                  einigen, oder A wählt p und g und sendet sie mit seiner ersten
                                  Nachricht
                            \item
                                  A berechnet \$v=g\^{}q\textbackslash{} MOD\textbackslash{} p\$ und
                                  sendet an \$B:\{p,g,v\}\$
                        \end{itemize}
                  \item
                        B wählt eine Zufallszahl r:

                        \begin{itemize}
                            \item
                                  B berechnet \$w=g\^{}r\textbackslash{} MOD\textbackslash{} p\$ und
                                  sendet an \$A:\{p,g,w\}\$ (oder einfach \$\{w\}\$)
                        \end{itemize}
                  \item
                        Beide Seiten errechnen das gemeinsame Geheimnis:

                        \begin{itemize}
                            \item
                                  A errechnet \$s=w\^{}q\textbackslash{} MOD\textbackslash{} p\$
                            \item
                                  B errechnet \$s'=v\^{}r\textbackslash{} MOD\textbackslash{} p\$
                            \item
                                  Da \$g\^{}\{q\textbackslash times r\}\textbackslash{}
                                  MOD\textbackslash{} p = g\^{}\{r \textbackslash times
                                  q\}\textbackslash{} MOD\textbackslash{} p\$ ist, gilt: \$s=s'\$
                        \end{itemize}
                  \item
                        Ein Angreifer Eve, der den öffentlichen Kanal abhört, kann das
                        Geheimnis s nur berechnen, wenn er entweder q oder r berechnen kann,
                        die die diskreten Logarithmen von v, w modulo p zur Basis g sind.
              \end{itemize}
        \item
              Wenn der Angreifer Eve in der Lage ist, Nachrichten auf dem
              öffentlichen Kanal zu verändern, kann er einen
              Man-in-the-Middle-Angriff starten:

              \begin{itemize}
                  \item
                        Eve generiert zwei Zufallszahlen \$q'\$ und \$r'\$: Eve berechnet
                        \$v'=g\^{}\{q'\}\textbackslash{} MOD\textbackslash{} p\$ und
                        \$w'=g\^{}\{r'\}\textbackslash{} MOD\textbackslash{} p\$
                  \item
                        Wenn A \$\{p,g,v\}\$ sendet, fängt sie die Nachricht ab und sendet
                        an \$B:\{p,g,v'\}\$
                  \item
                        Wenn B \$\{p,g,w\}\$ sendet, fängt sie die Nachricht ab und sendet
                        an \$A:\{p,g,w'\}\$
                  \item
                        Wenn das angebliche ,,gemeinsame Geheimnis'' berechnet wird,
                        erhalten wir:

                        \begin{itemize}
                            \item
                                  A berechnet \$s\_1=w'\^{}q\textbackslash{} MOD\textbackslash{} p =
                                  v\^{}\{r'\}\textbackslash{} MOD\textbackslash{} p\$, letzteres
                                  berechnet von E
                            \item
                                  B berechnet \$s\_2=v'\^{}r\textbackslash{} MOD\textbackslash{} p =
                                  w\^{}\{q'\}\textbackslash{} MOD\textbackslash{} p\$, letzteres
                                  berechnet von E
                            \item
                                  A und E haben sich also auf ein gemeinsames Geheimnis \$s\_1\$
                                  geeinigt, und E und B haben sich auf ein gemeinsames Geheimnis
                                  \$s\_2\$ geeinigt.
                        \end{itemize}
                  \item
                        Wenn das ,,gemeinsame Geheimnis'' nun von A und B verwendet wird, um
                        Nachrichten zu verschlüsseln, die über den öffentlichen Kanal
                        ausgetauscht werden sollen, kann E alle Nachrichten abfangen und
                        ent- bzw. wiederverschlüsseln, bevor er sie zwischen A und B
                        weiterleitet.
              \end{itemize}
        \item
              Zwei Gegenmaßnahmen gegen den Man-in-the-Middle-Angriff:

              \begin{itemize}
                  \item
                        Das gemeinsame Geheimnis wird ,,authentifiziert'', nachdem es
                        vereinbart worden ist.

                        \begin{itemize}
                            \item
                                  Wir werden dies im Abschnitt über die Schlüsselverwaltung
                                  behandeln
                        \end{itemize}
                  \item
                        A und B verwenden ein sogenanntes Interlock-Protokoll, nachdem sie
                        sich auf ein gemeinsames Geheimnis geeinigt haben:

                        \begin{itemize}
                            \item
                                  Dazu müssen sie Nachrichten austauschen, die E weiterleiten muss,
                                  bevor sie sie entschlüsseln bzw. wieder verschlüsseln kann.
                            \item
                                  Der Inhalt dieser Nachrichten muss von A und B überprüfbar sein.
                            \item
                                  Dies zwingt E dazu, Nachrichten zu erfinden, und sie kann entdeckt
                                  werden.
                            \item
                                  Eine Technik, um zu verhindern, dass E die Nachrichten
                                  entschlüsselt, besteht darin, sie in zwei Teile aufzuteilen und
                                  den zweiten Teil vor dem ersten zu senden.

                                  \begin{itemize}
                                      \item
                                            Wenn der verwendete Verschlüsselungsalgorithmus bestimmte
                                            Eigenschaften verhindert, kann E den zweiten Teil nicht
                                            verschlüsseln, bevor sie den ersten erhält.
                                      \item
                                            Da A den ersten Teil erst senden wird, nachdem er eine Antwort
                                            (den zweiten Teil) von B erhalten hat, ist E gezwungen, zwei
                                            Nachrichten zu erfinden, bevor sie die ersten Teile erhalten
                                            kann.
                                  \end{itemize}
                        \end{itemize}
              \end{itemize}
        \item
              Bemerkung: In der Praxis muss die Zahl g nicht unbedingt eine Urwurzel
              von p sein, es genügt, wenn sie eine große Untergruppe von
              \$\textbackslash mathbb\{Z\}\^{}*\_p\$ erzeugt
    \end{itemize}


    \subsection{ElGamal Algorithmus}

    \begin{itemize}
        \item
              Der ElGamal-Algorithmus kann sowohl für die Verschlüsselung als auch
              für digitale Signaturen verwendet werden (siehe auch {[}ElG85a{]}).
        \item
              Wie der DH-Austausch basiert er auf der Schwierigkeit, diskrete
              Logarithmen in endlichen Feldern zu berechnen
        \item
              Um ein Schlüsselpaar zu erstellen:

              \begin{itemize}
                  \item
                        Wähle eine große Primzahl p, einen Generator g der multiplikativen
                        Gruppe \$\textbackslash mathbb\{Z\}\^{}*\_p\$ und eine Zufallszahl
                        v, so dass \$1\textbackslash leq v\textbackslash leq p - 2\$.
                        Berechnen Sie: \$y=g\^{}v mod p\$
                  \item
                        Der öffentliche Schlüssel ist \$( y, g, p )\$
                  \item
                        Der private Schlüssel ist v
              \end{itemize}
        \item
              So signieren Sie eine Nachricht m :

              \begin{itemize}
                  \item
                        Wähle eine Zufallszahl k so, dass k relativ prim zu \$p-1\$ ist.
                  \item
                        Berechne \$r=g\^{}k mod p\$
                  \item
                        Berechne mit dem erweiterten euklidischen Algorithmus
                        \$k\^{}\{-1\}\$, den Kehrwert von \$k mod (p - 1)\$
                  \item
                        Berechne \$s=k\^{}\{-1\} \textbackslash times ( m - v
                        \textbackslash times r) mod ( p - 1)\$
                  \item
                        Die Signatur über die Nachricht ist \$( r, s )\$
              \end{itemize}
        \item
              Überprüfen einer Signatur \$( r , s )\$ über eine Nachricht m:

              \begin{itemize}
                  \item
                        Bestätige, dass \$y\^{}r \textbackslash times r\^{}s\textbackslash{}
                        MOD\textbackslash{} p = g\^{}m\textbackslash{} MOD\textbackslash{}
                        p\$
                  \item
                        Der Beweis: Wir benötigen Folgendes

                        \begin{itemize}
                            \item
                                  Lemma 3: Sei p eine Primzahl und g ein Generator von
                                  \$\textbackslash mathbb\{Z\}\^{}*\_p\$. Dann sei \$i
                                  \textbackslash equiv j mod ( p -1) \textbackslash Rightarrow g i
                                  \textbackslash equiv g j mod p\$
                            \item
                                  Beweis: \$i \textbackslash equiv j mod (p-1)
                                  \textbackslash Rightarrow\$ es gibt \$k\textbackslash in
                                  \textbackslash mathbb\{Z\}\^{}+\$ so, dass
                                  \$(i-j)=(p-1)\textbackslash times k\$
                            \item
                                  Also \$g\^{}\{(i-j)\}=g\^{}\{(p-1)\textbackslash times k\}
                                  \textbackslash equiv 1\^{}k\textbackslash equiv 1 mod p\$, wegen
                                  Theorem 3 (Euler) \$\textbackslash Rightarrow g\^{}i
                                  \textbackslash equiv g\^{}j mod p\$
                        \end{itemize}
                  \item
                        Als \$s\textbackslash equiv
                        k\^{}\{-1\}\textbackslash times(m-v\textbackslash times r) mod
                        (p-1)\$

                        \begin{itemize}
                            \item
                                  \$\textbackslash Leftrightarrow k \textbackslash times
                                  s\textbackslash equiv m-v\textbackslash times r mod (p-1)\$
                            \item
                                  \$\textbackslash Leftrightarrow m \textbackslash equiv
                                  v\textbackslash times r+k\textbackslash times s mod (p-1)\$
                            \item
                                  \$\textbackslash Rightarrow g\^{}m \textbackslash equiv
                                  g\^{}\{(v\textbackslash times r+ k\textbackslash times s)\} mod
                                  p\$ mit Lemma 3
                            \item
                                  \$\textbackslash Leftrightarrow g\^{}m \textbackslash equiv
                                  g\^{}\{(v\textbackslash times r)\}\textbackslash times
                                  g\^{}\{(k\textbackslash times s)\} mod p\$
                            \item
                                  \$\textbackslash Leftrightarrow g\^{}m \textbackslash equiv
                                  y\^{}r\textbackslash times r\^{}s mod p\$
                        \end{itemize}
              \end{itemize}
        \item
              Sicherheit von ElGamal-Signaturen:

              \begin{itemize}
                  \item
                        Da der private Schlüssel v benötigt wird, um s berechnen zu können,
                        müsste ein Angreifer den diskreten Logarithmus von y modulo p zur
                        Basis g berechnen, um Signaturen zu fälschen
                  \item
                        Entscheidend für die Sicherheit ist, dass für jede Nachricht eine
                        neue Zufallszahl k gewählt wird, denn ein Angreifer kann das
                        Geheimnis v berechnen, wenn er zwei Nachrichten zusammen mit ihren
                        Signaturen auf der Basis des gleichen k erhält (siehe {[}Men97a{]},
                        Anmerkung 11.66.ii)
                  \item
                        Um zu verhindern, dass ein Angreifer eine Nachricht M mit einer
                        passenden Signatur erstellen kann, ist es notwendig, die Nachricht M
                        nicht direkt zu signieren, sondern einen kryptographischen Hashwert
                        \$m=h(M)\$ davon zu signieren (diese werden bald behandelt, siehe
                        auch {[}Men97a{]}, Anmerkung 11.66.iii)
              \end{itemize}
        \item
              Um eine Nachricht m mit dem öffentlichen Schlüssel \$(y,g,p)\$ zu
              verschlüsseln:

              \begin{itemize}
                  \item
                        Wähle einen zufälligen
                        \$k\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ mit
                        \$k\textless p-1\$
                  \item
                        Berechne \$r=g\^{}k\textbackslash{} MOD\textbackslash{} p\$
                  \item
                        Berechne \$s=m\textbackslash times y\^{}k\textbackslash{}
                        MOD\textbackslash{} p\$
                  \item
                        Der verschlüsselte Text ist \$(r,s)\$, der doppelt so lang ist wie m
              \end{itemize}
        \item
              Entschlüsseln der Nachricht \$(r,s)\$ mit v:

              \begin{itemize}
                  \item
                        Verwenden Sie den privaten Schlüssel v zur Berechnung von
                        \$r\^{}\{(p-1-v)\}\textbackslash{} MOD\textbackslash{}
                        p=r\^{}\{(-v)\}\textbackslash{} MOD\textbackslash{} p\$
                  \item
                        Wiederherstellung von m durch Berechnung von
                        \$m=r\^{}\{(-v)\}\textbackslash times s\textbackslash{}
                        MOD\textbackslash{} p\$
                  \item
                        Beweis: \$r\^{}\{(-v)\}\textbackslash times s\textbackslash equiv
                        r\^{}\{(-v)\} \textbackslash times m \textbackslash times
                        y\^{}k\textbackslash equiv g\^{}\{(-vk)\}\textbackslash times m
                        \textbackslash times y\^{}k\textbackslash equiv g\^{}\{(-v
                        \textbackslash times k)\} \textbackslash times m\textbackslash times
                        g\^{}\{(v \textbackslash times k)\} \textbackslash equiv m mod p\$
              \end{itemize}
        \item
              Sicherheit:

              \begin{itemize}
                  \item
                        Die einzige bekannte Möglichkeit für einen Angreifer, m
                        wiederherzustellen, ist die Berechnung des diskreten Logarithmus v
                        von y modulo p zur Basis g
                  \item
                        Für jede Nachricht wird ein neues zufälliges k benötigt
                        ({[}Men97a{]}, Anmerkung 8.23.ii)
              \end{itemize}
    \end{itemize}


    \subsection{Elliptische Kurven
        Kryptographie}

    \begin{itemize}
        \item
              Die bisher vorgestellten Algorithmen wurden für die multiplikative
              Gruppe \$(\textbackslash mathbb\{Z\}\^{}*\_p,\textbackslash times p)\$
              bzw. das Feld \$(\textbackslash mathbb\{Z\}\_p, +\_p,
              \textbackslash times\_p)\$ entwickelt.
        \item
              In den 1980er Jahren wurde festgestellt, dass sie verallgemeinert und
              auch für andere Gruppen und Felder verwendet werden können
        \item
              Die Hauptmotivation für diese Verallgemeinerung ist:

              \begin{itemize}
                  \item
                        Zahlreiche mathematische Forschungen auf dem Gebiet der
                        Primzahlprüfung, der Faktorisierung und der Berechnung diskreter
                        Logarithmen haben zu Techniken geführt, mit denen diese Probleme
                        effizienter gelöst werden können, wenn bestimmte Eigenschaften
                        erfüllt sind:

                        \begin{itemize}
                            \item
                                  Als 1977 die RSA-129-Aufgabe gestellt wurde, ging man davon aus,
                                  dass es etwa 40 Billiarden Jahre dauern würde, die 129-stellige
                                  Zahl (\$\textbackslash approx 428\$ Bit) zu faktorisieren.
                            \item
                                  Im Jahr 1994 benötigte eine Gruppe von Computern, die über das
                                  Internet vernetzt waren, 8 Monate, um die Zahl zu faktorisieren,
                                  was etwa 5000 MIPS-Jahre entsprach.
                            \item
                                  Fortschritte bei den Faktorisierungsalgorithmen ermöglichten 2009
                                  die Faktorisierung einer 232-stelligen Zahl (768 Bit) in etwa 1500
                                  AMD64-Jahren {[}KAFL10{]}.
                            \item
                                  \$\textbackslash Rightarrow\$ die Schlüssellänge muss erhöht
                                  werden (derzeit etwa 2048 Bit)
                        \end{itemize}
                  \item
                        Einige der effizienteren Verfahren beruhen auf bestimmten
                        Eigenschaften der algebraischen Strukturen
                        \$(\textbackslash mathbb\{Z\}\^{}*\_p,\textbackslash times p)\$ und
                        \$(\textbackslash mathbb\{Z\}\_p, +\_p, \textbackslash times\_p)\$
                  \item
                        Verschiedene algebraische Strukturen können daher die gleiche
                        Sicherheit mit kürzeren Schlüssellängen bieten
              \end{itemize}
        \item
              Eine sehr vielversprechende Struktur für die Kryptographie lässt sich
              aus der Gruppe der Punkte auf einer elliptischen Kurve über einem
              endlichen Feld gewinnen

              \begin{itemize}
                  \item
                        Die mathematischen Operationen in diesen Gruppen können sowohl in
                        Hardware als auch in Software effizient implementiert werden.
                  \item
                        Das Problem des diskreten Logarithmus gilt in der allgemeinen
                        Klasse, die sich aus der Gruppe der Punkte auf einer elliptischen
                        Kurve über einem endlichen Feld ergibt, als schwierig
              \end{itemize}
    \end{itemize}


    \subsubsection{Gruppenelemente}

    \begin{itemize}
        \item
              Algebraische Gruppe bestehend aus

              \begin{itemize}
                  \item
                        Punkte auf der Weierstraß'schen Gleichung: \$y\^{}2 = x\^{}3 + ax +
                        b\$
                  \item
                        Zusätzlicher Punkt O im ,,Unendlichen''
              \end{itemize}
        \item
              Kann über \$\textbackslash mathbb\{R\}\$ berechnet werden, aber in der
              Kryptographie werden \$\textbackslash mathbb\{Z\}\_p\$ und
              \$GF(2\^{}n)\$ verwendet

              \begin{itemize}
                  \item
                        Schon in \$\textbackslash mathbb\{R\}\$ beeinflussen Argumente die
                        Form erheblich:

                        \begin{itemize}
                            \item
                                  \$y\^{}2 = x\^{}3-3x+5\$
                                  % \includegraphics{Assets/NetworkSecurity-ecc-1.png}
                            \item
                                  \$y\^{}2 = x\^{}3-40x+5\$
                                  % \includegraphics{Assets/NetworkSecurity-ecc-2.png}
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsubsection{Punktaddition}

    \begin{itemize}
        \item
              Addition von Elementen = Addition von Punkten auf der Kurve
        \item
              Geometrische Interpretation:

              \begin{itemize}
                  \item
                        Jeder Punkt \$P:(x,y)\$ hat einen Kehrwert \$-P:(x,-y)\$
                  \item
                        Eine Linie durch zwei Punkte P und Q schneidet sich normalerweise
                        mit einem dritten Punkt R
                  \item
                        Im Allgemeinen ist die Summe von zwei Punkten P und Q gleich \$-R\$
                  \item
                        % \includegraphics{Assets/NetworkSecurity-ecc-3.png}
              \end{itemize}
        \item
              Addition (Sonderfälle)

              \begin{itemize}
                  \item
                        Der zusätzliche Punkt O ist das neutrale Element, d.h. \$P+O=P\$
                  \item
                        \$P + (-P)\$:

                        \begin{itemize}
                            \item
                                  Wird der inverse Punkt zu P addiert, schneiden sich Linie und
                                  Kurve im ,,Unendlichen''
                            \item
                                  Per Definition: \$P+(-P) = O\$
                        \end{itemize}
                  \item
                        \$P+P\$: Die Summe zweier identischer Punkte P ist der Kehrwert des
                        Schnittpunkts mit der Tangente durch P:

                        \begin{itemize}
                            \item
                                  % \includegraphics{Assets/NetworkSecurity-ecc-4.png}
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsubsection{Grundlagen des ECC - Algebraische
        Addition}

    \begin{itemize}
        \item
              Wenn einer der Summanden O ist, ist die Summe der andere Summand
        \item
              Wenn die Summanden zueinander invers sind, ist die Summe O
        \item
              Für die allgemeineren Fälle ist die Steigung der Geraden:
              \$\textbackslash alpha=\textbackslash begin\{cases\}
              \textbackslash frac\{y\_Q-y\_P\}\{x\_Q-x\_P\}
              \textbackslash quad\textbackslash text\{ for \} P\textbackslash not=-Q
              \textbackslash keil P\textbackslash not=Q \textbackslash{}
              \textbackslash frac\{3x\^{}2\_P +a\}\{2y\_P\}
              \textbackslash quad\textbackslash text\{ for \} P=Q
              \textbackslash end\{cases\}\$
        \item
              Ergebnis der Punktaddition, wobei \$(x\_r,y\_r)\$ bereits der
              Spiegelpunkt \$(-R)\$ ist
    \end{itemize}


    \subsubsection{Multiplikation}

    \begin{itemize}
        \item
              Multiplikation von natürlicher Zahl n und Punkt P durch mehrfache
              wiederholte Additionen
        \item
              Zahlen werden in 2er-Potenzen gruppiert, um eine logarithmische
              Laufzeit zu erreichen, z.B. \$25P = P + 8P + 16P\$
        \item
              Dies ist nur möglich, wenn das n bekannt ist!
        \item
              Wenn n für \$nP = Q\$ unbekannt ist, muss ein Logarithmus gelöst
              werden, was möglich ist, wenn die Koordinatenwerte aus
              \$\textbackslash mathbb\{R\}\$ gewählt werden
        \item
              Für \$\textbackslash mathbb\{Z\}\_p\$ und \$GF(2\^{}n)\$ muss das
              diskrete Logarithmusproblem für elliptische Kurven gelöst werden, was
              nicht effizient durchgeführt werden kann!
        \item
              Hinweis: Es ist nicht definiert, wie zwei Punkte multipliziert werden,
              sondern nur eine natürliche Zahl n und der Punkt P
    \end{itemize}


    \subsubsection{Kurven über
        \$\textbackslash mathbb\{Z\}\_p\$}

    \begin{itemize}
        \item
              Über \$\textbackslash mathbb\{Z\}\_p\$ zerfällt die Kurve in eine
              Menge von Punkten
        \item
              Für: \$y\^{}2=x\^{}3-3x+5\textbackslash{} mod\textbackslash{} 19\$

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-ecc-5.png}
                  \item
                        Hinweis: Für einige x-Werte gibt es keinen y-Wert!
              \end{itemize}
    \end{itemize}


    \subsubsection{Berechnen Sie die y-Werte in
        \$\textbackslash mathbb\{Z\}\_p\$}

    \begin{itemize}
        \item
              Im Allgemeinen etwas problematischer: Bestimmen Sie die y-Werte für
              ein gegebenes x (da sein quadratischer Wert berechnet wird) durch
              \$y\^{}2\textbackslash equiv f(x)\textbackslash{} mod\textbackslash{}
              p\$
        \item
              Daher wird p oft s.t. gewählt \$p\textbackslash equiv
              3\textbackslash{} mod\textbackslash{} 4\$
        \item
              Dann wird y durch \$y\_1\textbackslash equiv
              f(x)\^{}\{\textbackslash frac\{p+1\}\{4\}\}\$ und
              \$y\_2\textbackslash equiv
              -f(x)\^{}\{\textbackslash frac\{p+1\}\{4\}\}\$ berechnet, wenn und nur
              wenn überhaupt eine Lösung existiert
        \item
              Kurzer Beweis:

              \begin{itemize}
                  \item
                        Aus dem Euler-Theorem 3 wissen wir, dass
                        \$f(x)\^{}\{p-1\}\textbackslash equiv 1\textbackslash{}
                        mod\textbackslash{} p\$
                  \item
                        Die Quadratwurzel muss also 1 oder -1 sein
                        \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv\textbackslash pm
                        1\textbackslash{} mod\textbackslash{} p\$
              \end{itemize}
        \item
              Fall 1:
              \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv1\textbackslash{}
              mod\textbackslash{} p\$

              \begin{itemize}
                  \item
                        Multiplizieren Sie beide Seiten mit f(x):
                        \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv
                        f(x)\textbackslash equiv y\^{}2\textbackslash{} mod\textbackslash{}
                        p\$
                  \item
                        Da \$p + 1\$ durch 4 teilbar ist, können wir die Quadratwurzel
                        ziehen, so dass
                        \$f(x)\^{}\{\textbackslash frac\{p-1\}\{2\}\}\textbackslash equiv
                        y\textbackslash{} mod\textbackslash{} p\$
              \end{itemize}
        \item
              Fall 2: In diesem Fall existiert keine Lösung für den gegebenen x-Wert
              (wie von Euler gezeigt)
    \end{itemize}


    \subsubsection{Addition und Multiplikation in
        \$\textbackslash mathbb\{Z\}\_p\$}

    \begin{itemize}
        \item
              Aufgrund des diskreten Strukturpunktes haben mathematische Operationen
              keine geometrische Interpretation mehr, sondern
        \item
              Algebraische Addition ähnlich der Addition über
              \$\textbackslash mathbb\{R\}\$
        \item
              Wird der inverse Punkt zu P addiert, schneiden sich Linie und
              ,,Kurve'' immer noch im ,,Unendlichen''
        \item
              Alle x- und y-Werte werden mod p berechnet
        \item
              Division wird durch Multiplikation mit dem inversen Element des
              Nenners ersetzt

              \begin{itemize}
                  \item
                        Verwendung des erweiterten euklidischen Algorithmus mit w und p zur
                        Ableitung der Inversen \$-w\$
              \end{itemize}
        \item
              Die algebraische Multiplikation einer natürlichen Zahl n und eines
              Punktes P erfolgt ebenfalls durch wiederholte Addition von Summanden
              der Potenz von 2
        \item
              Das Problem des diskreten Logarithmus ist die Bestimmung einer
              natürlichen Zahl n in \$nP=Q\$ für zwei bekannte Punkte P und Q
    \end{itemize}


    \subsubsection{Foundations of ECC - Größe der erzeugten
        Gruppen}

    \begin{itemize}
        \item
              Bitte beachten Sie, dass die Ordnung einer durch einen Punkt auf einer
              Kurve über \$\textbackslash mathbb\{Z\}\_p\$ erzeugten Gruppe nicht
              \$p-1\$ ist!
        \item
              Die Bestimmung der exakten Ordnung ist nicht einfach, kann aber mit
              Schoofs Algorithmus {[}Sch85{]} in logarithmischer Zeit durchgeführt
              werden (erfordert viel mehr mathematischen Hintergrund als hier
              gewünscht)
        \item
              Der Satz von Hasse über elliptische Kurven besagt jedoch, dass die
              Gruppengröße n zwischen: \$p+1 -
              2\textbackslash sqrt\{p\}\textbackslash leq n\textbackslash leq
              p+1+2\textbackslash sqrt\{p\}\$ liegen muss
        \item
              Wie bereits erwähnt: Es genügt, relativ große Gruppen zu erzeugen
    \end{itemize}


    \subsubsection{ECDH}

    \begin{itemize}
        \item
              Der Diffie-Hellman-Algorithmus kann leicht an elliptische Kurven
              angepasst werden
        \item
              Wenn Alice (A) und Bob (B) sich auf ein gemeinsames Geheimnis s
              einigen wollen:

              \begin{itemize}
                  \item
                        A und B einigen sich auf eine kryptographisch sichere elliptische
                        Kurve und einen Punkt P auf dieser Kurve
                  \item
                        A wählt eine Zufallszahl q:

                        \begin{itemize}
                            \item
                                  A berechnet \$Q=qP\$ und überträgt Q an Bob
                        \end{itemize}
                  \item
                        B wählt eine Zufallszahl r:

                        \begin{itemize}
                            \item
                                  B berechnet \$R=rP\$ und überträgt P an Alice
                        \end{itemize}
                  \item
                        Beide Seiten errechnen das gemeinsame Geheimnis:

                        \begin{itemize}
                            \item
                                  A errechnet \$S=qR\$
                            \item
                                  B errechnet \$S'=rQ\$
                            \item
                                  Da \$qrP=rqP\$ der geheime Punkt \$S=S'\$
                        \end{itemize}
              \end{itemize}
        \item
              Angreifer, die den öffentlichen Kanal abhören, können S nur berechnen,
              wenn sie entweder q oder r berechnen können, die die diskreten
              Logarithmen von Q und R für den Punkt P sind
    \end{itemize}


    \subsubsection{EC-Version des
        ElGamal-Algorithmus}

    \begin{itemize}
        \item
              Die Anpassung von ElGamal für elliptische Kurven ist für die
              Verschlüsselungsroutine recht einfach
        \item
              Ein Schlüsselpaar einrichten:

              \begin{itemize}
                  \item
                        Wählen Sie eine elliptische Kurve über einem endlichen Feld, einen
                        Punkt G, der eine große Gruppe erzeugt, und eine Zufallszahl v, so
                        dass \$1 \textless{} v \textless{} n\$, wobei n die Größe der
                        induzierten Gruppe bezeichnet, Berechnen Sie: \$Y = vG\$
                  \item
                        Der öffentliche Schlüssel ist \$(Y,G,Kurve)\$
                  \item
                        Der private Schlüssel ist v
              \end{itemize}
        \item
              Um eine Nachricht zu verschlüsseln:

              \begin{itemize}
                  \item
                        Wähle eine zufällige
                        \$k\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ mit
                        \$k\textless n-1\$, berechne \$R=kG\$
                  \item
                        Berechne \$S=M+kY\$, wobei M ein von der Nachricht abgeleiteter
                        Punkt ist

                        \begin{itemize}
                            \item
                                  Problem: Die Interpretation der Nachricht m als x-Koordinate von M
                                  ist nicht ausreichend, da der y-Wert nicht existieren muss
                            \item
                                  Lösung aus {[}Ko87{]}: Wähle eine Konstante c (z.B. 100) und
                                  prüfe, ob \$cm\$ die x-Koordinate eines gültigen Punktes ist, wenn
                                  nicht, versuche \$cm+1\$, dann \$cm+2\$ usw.
                            \item
                                  Um m zu entschlüsseln: nimm den x-Wert von M und führe eine
                                  ganzzahlige Division durch c durch (der Empfänger muss c ebenfalls
                                  kennen)
                        \end{itemize}
                  \item
                        Der Chiffretext sind die Punkte \$(R,S)\$
                  \item
                        Doppelt so lang wie m, wenn sie in so genannter komprimierter Form
                        gespeichert werden, d.h. nur die x-Koordinaten werden gespeichert
                        und ein einziges Bit, das angibt, ob die größere oder kleinere
                        entsprechende y-Koordinate verwendet werden soll
              \end{itemize}
        \item
              Um eine Nachricht zu entschlüsseln:

              \begin{itemize}
                  \item
                        Ableitung von M durch Berechnung von \$S-vR\$
                  \item
                        Beweis: \$S-vR=M+kY-vR =M+kvG-vkG= M+O= M\$
              \end{itemize}
        \item
              Eine Nachricht signieren:

              \begin{itemize}
                  \item
                        Wähle ein zufälliges
                        \$k\textbackslash in\textbackslash mathbb\{Z\}\^{}+\$ mit
                        \$k\textless n-1\$, berechne \$R = kG\$
                  \item
                        Berechne \$s=k\^{}\{-1\}(m+rv) mod\textbackslash{} n\$, wobei \$r\$
                        der x-Wert von R ist
                  \item
                        Die Signatur ist \$(r,s)\$, wiederum etwa doppelt so lang wie n
              \end{itemize}
        \item
              Überprüfen einer signierten Nachricht:

              \begin{itemize}
                  \item
                        Prüfen, ob der Punkt \$P=ms\^{}\{-1\}G+rs\^{}\{-1\}Y\$ die
                        x-Koordinate r hat
                  \item
                        Anmerkung: \$s\^{}\{-1\}\$ wird durch den Erweiterten Euklidischen
                        Algorithmus mit den Eingaben s und n (der Ordnung der Gruppe)
                        berechnet.
                  \item
                        Beweis: \$ms\^{}\{-1\}G+rs\^{}\{-1\}Y = ms\^{}\{-1\}G+rs\^{}\{-1\}vG
                        = (m+rv)(s\^{}\{-1\})G = (ks)(s\^{}\{-1\})G = kG = R\$
              \end{itemize}
        \item
              Diskussion zur Sicherheit:

              \begin{itemize}
                  \item
                        Wie in der ursprünglichen Version von ElGamal ist es entscheidend, k
                        nicht zweimal zu verwenden
                  \item
                        Nachrichten sollten nicht direkt signiert werden
                  \item
                        Weitere Prüfungen können erforderlich sein, d.h. G darf nicht O
                        sein, ein gültiger Punkt auf der Kurve usw. (siehe {[}NIST09{]} für
                        weitere Details)
              \end{itemize}
    \end{itemize}


    \subsubsection{Sicherheit}

    \begin{itemize}
        \item
              Die Sicherheit hängt stark von der gewählten Kurve und dem Punkt ab:
        \item
              Die Diskriminante der Kurve darf nicht Null sein, d.h.
              \$4a\^{}3+27b\^{}2\textbackslash not\textbackslash equiv
              0\textbackslash{} mod\textbackslash{} p\$ sonst ist die Kurve
              degradiert (eine sogenannte ,,singuläre Kurve'' )
        \item
              Menezes et. al. haben einen subexponentiellen Algorithmus für
              sogenannte ,,supersinguläre elliptische Kurven'' gefunden, der aber im
              allgemeinen Fall nicht funktioniert {[}Men93a{]}
        \item
              Die konstruierten algebraischen Gruppen sollten so viele Elemente wie
              möglich haben.
        \item
              In diesem Kurs wird nicht näher auf die Kryptographie elliptischer
              Kurven eingegangen, da dies viel mehr Mathematik erfordert, als für
              diesen Kurs erwünscht ist...
        \item
              Für Nicht-Kryptographen ist es am besten, sich auf vordefinierte
              Kurven zu verlassen, z.B. {[}LM10{]} oder {[}NIST99{]} und Standards
              wie ECDSA
        \item
              Viele Veröffentlichungen wählen die Parameter a und b so, dass sie
              nachweislich durch einen Zufallsprozess gewählt werden (z.B.
              veröffentlichen Sie x für \$h(x)=a\$ und \$y\$ für \$h(y) = b\$); so
              soll sichergestellt werden, dass die Kurven keine kryptographische
              Schwäche enthalten, die nur den Autoren bekannt ist
        \item
              Die Sicherheit ist abhängig von der Länge von p

              \begin{itemize}
                  \item
                        Schlüssellängen mit vergleichbaren Stärken nach {[}NIST12{]}:
                        \textbar{} Symmetrische Algorithmen \textbar{} RSA \textbar{} ECC
                        \textbar{} \textbar{}
                        -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
                        \textbar{} -\/-\/-\/-\/- \textbar{} -\/-\/-\/-\/-\/-\/- \textbar{}
                        \textbar{} 112 \textbar{} 2048 \textbar{} 224-255 \textbar{}
                        \textbar{} 128 \textbar{} 3072 \textbar{} 256-383 \textbar{}
                        \textbar{} 192 \textbar{} 7680 \textbar{} 384-511 \textbar{}
                        \textbar{} 256 \textbar{} 15360 \textbar{} \textgreater{} 512
                        \textbar{}
              \end{itemize}
        \item
              Die Sicherheit hängt auch stark von der Implementierung ab!

              \begin{itemize}
                  \item
                        Die verschiedenen Fälle (z.B. mit O) in der ECC-Berechnung können
                        beobachtbar sein, d.h. Stromverbrauch und Zeitunterschiede
                  \item
                        Angreifer können Seitenkanalangriffe ableiten, wie in OpenSSL 0.9.8o
                        {[}BT11{]}

                        \begin{itemize}
                            \item
                                  Ein Angreifer kann die Bitlänge eines Wertes k in \$kP\$ ableiten,
                                  indem er die für den Quadrat- und Multiplikationsalgorithmus
                                  benötigte Zeit misst
                            \item
                                  Der Algorithmus wurde in OpenSSL frühzeitig abgebrochen, wenn
                                  keine weiteren Bits auf ,,1'' gesetzt wurden
                        \end{itemize}
                  \item
                        Angreifer könnten versuchen, ungültige Punkte zu generieren, um
                        Fakten über den verwendeten Schlüssel abzuleiten, wie in OpenSSL
                        0.9.8g, was zu einer Wiederherstellung eines vollen 256-Bit
                        ECC-Schlüssels nach nur 633 Abfragen führte {[}BBP12{]}
              \end{itemize}
        \item
              Lektion gelernt: Machen Sie es nicht selbst, es sei denn, Sie müssen
              es tun und wissen, was Sie tun!
    \end{itemize}


    \subsubsection{Weitere Anmerkungen}

    \begin{itemize}
        \item
              Wie bereits erwähnt, ist es möglich, kryptographische elliptische
              Kurven über \$G(2\^{}n)\$ zu konstruieren, was in
              Hardware-Implementierungen schneller sein kann.

              \begin{itemize}
                  \item
                        Wir haben auf Details verzichtet, da dies nicht viele neue
                        Erkenntnisse gebracht hätte!
              \end{itemize}
        \item
              Elliptische Kurven und ähnliche algebraische Gruppen sind ein aktives
              Forschungsgebiet und ermöglichen weitere fortgeschrittene Anwendungen,
              z.B:

              \begin{itemize}
                  \item
                        Sogenannte Edwards-Kurven werden derzeit diskutiert, da sie robuster
                        gegen Seitenkanalangriffe zu sein scheinen (z.B. {[}BLR08{]})
                  \item
                        Bilineare Paarungen ermöglichen

                        \begin{itemize}
                            \item
                                  Programme zu verifizieren, dass sie zur selben Gruppe gehören,
                                  ohne ihre Identität preiszugeben (Secret Handshakes, z.B.
                                  {[}SM09{]})
                            \item
                                  Öffentliche Schlüssel können strukturiert werden, z.B. ,,Alice''
                                  als öffentlicher Schlüssel für Alice verwenden (Identitätsbasierte
                                  Verschlüsselung, Grundlagen in {[}BF03{]})
                        \end{itemize}
              \end{itemize}
        \item
              Bevor Sie elliptische Kurvenkryptographie in einem Produkt einsetzen,
              stellen Sie sicher, dass Sie keine Patente verletzen, da es noch viele
              gültige Patente in diesem Bereich gibt!
    \end{itemize}


    \subsection{Schlussfolgerung}

    \begin{itemize}
        \item
              Asymmetrische Kryptographie erlaubt es, zwei verschiedene Schlüssel zu
              verwenden:

              \begin{itemize}
                  \item
                        Verschlüsselung / Entschlüsselung
                  \item
                        Signieren / Überprüfen
              \end{itemize}
        \item
              Die praktischsten Algorithmen, die immer noch als sicher gelten, sind:

              \begin{itemize}
                  \item
                        RSA, basierend auf der Schwierigkeit, diskrete Logarithmen zu
                        faktorisieren und zu lösen
                  \item
                        Diffie-Hellman (kein asymmetrischer Algorithmus, sondern ein
                        Schlüsselvereinbarungsprotokoll)
                  \item
                        ElGamal, wie DH basierend auf der Schwierigkeit, diskrete
                        Logarithmen zu berechnen
              \end{itemize}
        \item
              Da ihre Sicherheit vollständig auf der Schwierigkeit bestimmter
              mathematischer Probleme beruht, stellt der algorithmische Fortschritt
              ihre größte Bedrohung dar.
        \item
              Praktische Überlegungen:

              \begin{itemize}
                  \item
                        Asymmetrische kryptografische Operationen sind um Größenordnungen
                        langsamer als symmetrische Operationen.
                  \item
                        Daher werden sie oft nicht für die Verschlüsselung/Signierung von
                        Massendaten verwendet.
                  \item
                        Symmetrische Verfahren werden zur Verschlüsselung / Berechnung eines
                        kryptografischen Hashwerts verwendet, während die asymmetrische
                        Kryptografie nur zur Verschlüsselung eines Schlüssels / Hashwerts
                        eingesetzt wird.
              \end{itemize}
    \end{itemize}


    \section{Modifikationsprüfwerte}


    \subsection{Motivation}

    \begin{itemize}
        \item
              In der Datenkommunikation ist es üblich, eine Art Fehlererkennungscode
              für Nachrichten zu berechnen, mit dem der Empfänger überprüfen kann,
              ob eine Nachricht während der Übertragung verändert wurde.

              \begin{itemize}
                  \item
                        Beispiele: Parität, Bit-Interleaved Parity, Cyclic Redundancy Check
                        (CRC)
              \end{itemize}
        \item
              Dies führt zu dem Wunsch, einen ähnlichen Wert zu haben, der es
              ermöglicht zu überprüfen, ob eine Nachricht während der Übertragung
              verändert wurde.
        \item
              Es ist jedoch ein großer Unterschied, ob man davon ausgeht, dass die
              Nachricht durch mehr oder weniger zufällige Fehler oder absichtlich
              verändert wird:

              \begin{itemize}
                  \item
                        Wenn jemand eine Nachricht, die mit einem CRC-Wert geschützt ist,
                        absichtlich verändern will, kann er den CRC-Wert nach der
                        Veränderung neu berechnen oder die Nachricht so verändern, dass sie
                        den gleichen CRC-Wert ergibt.
              \end{itemize}
        \item
              Ein Änderungsprüfwert muss also einige zusätzliche Eigenschaften
              erfüllen, die es Angreifern unmöglich machen, ihn zu fälschen

              \begin{itemize}
                  \item
                        Zwei Hauptkategorien von Modifikationsprüfwerten:

                        \begin{itemize}
                            \item
                                  Modifikationserkennungscode (MDC)
                            \item
                                  Nachrichten-Authentifizierungs-Code (MAC)
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Kryptographische
        Hash-Funktionen}

    \begin{itemize}
        \item
              Definition: Hash-Funktion

              \begin{itemize}
                  \item
                        Eine Hash-Funktion ist eine Funktion h, die die folgenden zwei
                        Eigenschaften hat:

                        \begin{itemize}
                            \item
                                  Komprimierung: h bildet eine Eingabe x mit beliebiger endlicher
                                  Bitlänge auf eine Ausgabe \$h(x)\$ mit fester Bitlänge n ab.
                            \item
                                  Einfachheit der Berechnung: Bei h und x ist es einfach, \$h(x)\$
                                  zu berechnen.
                        \end{itemize}
              \end{itemize}
        \item
              Definition: kryptografische Hash-Funktion

              \begin{itemize}
                  \item
                        Eine kryptografische Hash-Funktion h ist eine Hash-Funktion, die
                        zusätzlich unter anderem die folgenden Eigenschaften erfüllt:

                        \begin{itemize}
                            \item
                                  Pre-Image-Resistenz: für im Wesentlichen alle vorgegebenen
                                  Ausgaben y ist es rechnerisch nicht möglich, ein x zu finden, so
                                  dass \$h(x)=y\$
                            \item
                                  \begin{enumerate}
                                      \def\labelenumi{\arabic{enumi}.}
                                      \setcounter{enumi}{1}
                                      \item
                                            Vorabbild-Resistenz: Bei x ist es rechnerisch nicht möglich,
                                            eine zweite Eingabe \$x'\$ mit \$x\textbackslash not= x'\$ zu
                                            finden, so dass \$h(x)=h(x')\$
                                  \end{enumerate}
                            \item
                                  Kollisionssicherheit: Es ist rechnerisch nicht möglich, ein
                                  beliebiges Paar \$(x,x')\$ mit \$x\textbackslash not= x'\$ zu
                                  finden, so dass \$h(x)=h(x')\$
                        \end{itemize}
                  \item
                        Kryptographische Hash-Funktionen werden zur Berechnung von
                        Modification Detection Codes (MDC) verwendet
              \end{itemize}
    \end{itemize}


    \subsection{Nachrichten-Authentifizierungs-Codes
        (MAC)}

    \begin{itemize}
        \item
              Definition: Nachrichten-Authentifizierungs-Code

              \begin{itemize}
                  \item
                        Ein Message-Authentication-Code-Algorithmus ist eine Familie von
                        Funktionen \$h\_k\$, die durch einen geheimen Schlüssel k
                        parametrisiert sind und die folgenden Eigenschaften aufweisen:

                        \begin{itemize}
                            \item
                                  Komprimierung: hk bildet eine Eingabe x beliebiger endlicher
                                  Bitlänge auf eine Ausgabe \$h\_k(x)\$ fester Bitlänge ab, genannt
                                  MAC
                            \item
                                  Einfache Berechnung: Bei k, x und einer bekannten Funktionsfamilie
                                  \$h\_k\$ ist der Wert \$h\_k(x)\$ einfach zu berechnen
                            \item
                                  Berechnungsresistenz: für jeden festen, erlaubten, aber
                                  unbekannten Wert von k ist es bei null oder mehr Text-MAC-Paaren
                                  \$(x\_i, h\_k(x\_i))\$ rechnerisch nicht möglich, ein
                                  Text-MAC-Paar \$(x, h\_k(x))\$ für jede neue Eingabe
                                  \$x\textbackslash not= x\_i\$ zu berechnen
                        \end{itemize}
                  \item
                        Bitte beachten Sie, dass Rechenresistenz die Eigenschaft der
                        Nicht-Wiederherstellung des Schlüssels impliziert, d.h. k kann nicht
                        aus Paaren \$(x\_i,h\_k(x\_i))\$ wiederhergestellt werden, aber
                        Rechenresistenz kann nicht aus der Nicht-Wiederherstellung des
                        Schlüssels abgeleitet werden, da der Schlüssel k nicht immer
                        wiederhergestellt werden muss, um neue MACs zu fälschen
              \end{itemize}
    \end{itemize}


    \subsection{Ein einfacher Angriff gegen einen unsicheren
        MAC}

    \begin{itemize}
        \item
              Betrachten wir zur Veranschaulichung die folgende MAC-Definition:

              \begin{itemize}
                  \item
                        Eingabe: Nachricht \$m=(x\_1,x\_2,...,x\_n)\$, wobei \$x\_i\$
                        64-Bit-Werte sind, und Schlüssel k
                  \item
                        Berechne \$\textbackslash delta(m):= x\_1\textbackslash oplus
                        x\_2\textbackslash oplus...\textbackslash oplus x\_n\$, wobei
                        \$\textbackslash oplus\$ die bitweise Exklusiv-Oder-Verknüpfung
                        bezeichnet
                  \item
                        Ausgabe: MAC \$C\_k(m):= E\_k(\textbackslash delta(m))\$ mit
                        \$E\_k(x)\$ für die DES-Verschlüsselung
              \end{itemize}
        \item
              Die Schlüssellänge beträgt 56 Bit und die MAC-Länge 64 Bit, so dass
              wir einen Aufwand von etwa \$2\^{}\{55\}\$ Operationen erwarten
              würden, um den Schlüssel k zu erhalten und den MAC zu knacken (=
              Nachrichten fälschen zu können).
        \item
              Leider ist die MAC-Definition unsicher:

              \begin{itemize}
                  \item
                        Angenommen, ein Angreifer Eve, der die zwischen Alice und Bob
                        ausgetauschten Nachrichten fälschen will, erhält eine Nachricht
                        \$(m,C\_k(m))\$, die von Alice mit dem mit Bob geteilten geheimen
                        Schlüssel k ,,geschützt'' wurde
                  \item
                        Eve kann eine Nachricht \$m'\$ konstruieren, die denselben MAC
                        ergibt:

                        \begin{itemize}
                            \item
                                  Sei \$y\_1,y\_2,...,y\_\{n-1\}\$ ein beliebiger 64-Bit-Wert
                            \item
                                  Definiere \$y\_n:= y\_1\textbackslash oplus
                                  y\_2\textbackslash oplus...\textbackslash oplus
                                  y\_\{n-1\}\textbackslash oplus \textbackslash delta(m)\$, und
                                  \$m':=(y\_1,y\_2,...,y\_n)\$
                            \item
                                  Wenn Bob \$(m',C\_k(m))\$ von Eve erhält, die vorgibt, Alice zu
                                  sein, wird er es als von Alice stammend akzeptieren, da
                                  \$C\_k(m)\$ ein gültiger MAC für \$m'\$ ist
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Anwendungen für kryptographische Hash-Funktionen und
        MACs}

    \begin{itemize}
        \item
              Wichtigste Anwendung, die zum ursprünglichen Entwurf führte:
              Integrität von Nachrichten

              \begin{itemize}
                  \item
                        Ein MDC stellt einen digitalen Fingerabdruck dar, der mit einem
                        privaten Schlüssel signiert werden kann, z. B. mit dem RSA- oder
                        ElGamal-Algorithmus, und es ist nicht möglich, zwei Nachrichten mit
                        demselben Fingerabdruck zu erstellen, so dass ein bestimmter
                        signierter Fingerabdruck von einem Angreifer nicht wiederverwendet
                        werden kann
                  \item
                        Ein MAC über eine Nachricht m bescheinigt direkt, dass der Absender
                        der Nachricht im Besitz des geheimen Schlüssels k ist und die
                        Nachricht ohne Kenntnis dieses Schlüssels nicht verändert worden
                        sein kann.
              \end{itemize}
        \item
              Andere Anwendungen, die eine gewisse Vorsicht erfordern:

              \begin{itemize}
                  \item
                        Bestätigung von Wissen
                  \item
                        Schlüsselableitung
                  \item
                        Pseudo-Zufallszahlengenerierung
              \end{itemize}
        \item
              Je nach Anwendung müssen weitere Anforderungen erfüllt werden:

              \begin{itemize}
                  \item
                        Partielle Vorabbild-Resistenz: auch wenn nur ein Teil der Eingabe,
                        z.B. t Bit, unbekannt ist, sollte es im Durchschnitt
                        \$2\^{}\{t-1\}\$ Operationen benötigen, um diese Bits zu finden
              \end{itemize}
    \end{itemize}


    \subsection{Angriffe basierend auf dem
        Geburtstagsphänomen}

    \begin{itemize}
        \item
              Das Geburtstagsphänomen:

              \begin{itemize}
                  \item
                        Wie viele Personen müssen sich in einem Raum befinden, damit die
                        Wahrscheinlichkeit, dass es mindestens zwei Personen mit demselben
                        Geburtstag gibt, größer als 0,5 ist?
                  \item
                        Der Einfachheit halber lassen wir den 29. Februar beiseite und
                        nehmen an, dass jeder Geburtstag gleich wahrscheinlich ist
              \end{itemize}
        \item
              Definieren Sie \$P(n,k):= Pr\${[}mindestens ein Duplikat in k
              Elementen, wobei jedes Element einen von n gleich wahrscheinlichen
              Werten zwischen 1 und n annehmen kann {]}
        \item
              Definieren Sie \$Q(n,k):= Pr\${[}kein Duplikat in k Artikeln, jeder
              Artikel zwischen 1 und n {]}

              \begin{itemize}
                  \item
                        Wir können das erste Element aus n möglichen Werten wählen, das
                        zweite Element aus \$n-1\$ möglichen Werten, usw.
                  \item
                        Die Anzahl der verschiedenen Möglichkeiten, k Elemente aus n Werten
                        ohne Duplikate auszuwählen, ist also: \$N=n \textbackslash times
                        (n-1)\textbackslash times ...\textbackslash times (n-k+1)=
                        n!\textbackslash backslash(n-k)!\$
                  \item
                        Die Anzahl der verschiedenen Möglichkeiten, k Elemente aus n Werten
                        auszuwählen, mit oder ohne Duplikate, ist: \$n\^{}k\$
                  \item
                        Also, \$Q(n,k)=N\textbackslash backslash
                        n\^{}k=n!\textbackslash backslash((n-k)! \textbackslash times
                        n\^{}k)\$
              \end{itemize}
        \item
              Wir haben:
              \$P(n,k)=1-Q(n,k)=1-\textbackslash frac\{n!\}\{(n-k)!\textbackslash times
              n\^{}k\}=1-\textbackslash frac\{n\textbackslash times(n-1)\textbackslash times...\textbackslash times(n-k+1)\}\{n\^{}k\}=1-{[}(1-\textbackslash frac\{1\}\{n\})\textbackslash times(1-\textbackslash frac\{2\}\{n\})\textbackslash times...\textbackslash times(1-\textbackslash frac\{k-1\}\{n\}){]}\$
        \item
              Wir werden die folgende Ungleichung verwenden: \$(1-x)
              \textbackslash leq e\^{}\{-x\}\$ für alle \$x \textbackslash geq 0\$
        \item
              So:
              \$P(n,k)\textgreater1-{[}(e\^{}\{-1/n\})\textbackslash times(e\^{}\{-2/n\})\textbackslash times...\textbackslash times(e\^{}\{-(k-1)/n\}){]}=1-e\^{}\{\textbackslash frac\{-k\textbackslash times(k-1)\}\{2n\}\}\$
        \item
              Im letzten Schritt haben wir die Gleichheit: \$1+2+...+(k-1)=(k\^{}2 -
              k)\textbackslash backslash 2\$

              \begin{itemize}
                  \item
                        Übung: Beweisen Sie die obige Gleichheit durch Induktion
              \end{itemize}
        \item
              Kehren wir zu unserer ursprünglichen Frage zurück: Wie viele Personen
              k müssen sich in einem Raum befinden, damit mindestens zwei Personen
              mit demselben Geburtstag (von \$n=365\$ möglichen) mit der
              Wahrscheinlichkeit \$\textbackslash geq 0,5\$ vorhanden sind?

              \begin{itemize}
                  \item
                        Wir wollen also lösen:
                        \$\textbackslash frac\{1\}\{2\}=1-e\^{}\{\textbackslash frac\{-k\textbackslash times(k-1)\}\{2n\}\}\textbackslash Leftrightarrow
                        2=e\^{}\{\textbackslash frac\{k\textbackslash times(k-1)\}\{2n\}\}\textbackslash Leftrightarrow
                        ln(2)=\textbackslash frac\{k\textbackslash times(k-1)\}\{2n\}\$
                  \item
                        Für große k können wir \$k\textbackslash times(k-1)\$ durch
                        \$k\^{}2\$ approximieren, und wir erhalten:
                        \$k=\textbackslash sqrt\{2 ln(2)n\}\textbackslash approx
                        1,18\textbackslash sqrt\{n\}\$
                  \item
                        Für \$n=365\$ erhalten wir \$k=22,54\$, was der richtigen Antwort
                        recht nahe kommt 23
              \end{itemize}
        \item
              Was hat das mit MDCs zu tun?
        \item
              Wir haben gezeigt, dass bei n möglichen unterschiedlichen Werten die
              Anzahl k der Werte, die man zufällig wählen muss, um mindestens ein
              Paar identischer Werte zu erhalten, in der Größenordnung von
              \$\textbackslash sqrt\{n\}\$ liegt.
        \item
              Betrachten wir nun den folgenden Angriff {[}Yuv79a{]}:

              \begin{itemize}
                  \item
                        Eve möchte, dass Alice eine Nachricht m1 signiert, die Alice
                        normalerweise nie signieren würde. Eve weiß, dass Alice die Funktion
                        MDC1(m) verwendet, um eine MDC von m zu berechnen, die eine Länge
                        von r Bit hat, bevor sie diese MDC mit ihrem privaten Schlüssel
                        signiert, was ihre digitale Signatur ergibt.
                  \item
                        Zunächst erzeugt Eve ihre Nachricht m1. Würde sie nun MDC1(m1)
                        berechnen und dann versuchen, eine zweite harmlose Nachricht m2 zu
                        finden, die zu demselben MDC führt, wäre ihr Suchaufwand im
                        durchschnittlichen Fall in der Größenordnung von \$2\^{}\{(r-1)\}\$.
                  \item
                        Stattdessen nimmt sie eine beliebige harmlose Nachricht m2 und
                        beginnt, Variationen m1' und m2' der beiden Nachrichten zu
                        produzieren, z.B. durch Hinzufügen von -Kombinationen oder
                        Variationen mit semantisch identischen Wörtern.
              \end{itemize}
        \item
              Wie wir aus dem Geburtstagsphänomen gelernt haben, muss sie nur etwa
              \$\textbackslash sqrt\{2\^{}r\}=2\^{}\{r/2\}\$ Variationen von jeder
              der beiden Nachrichten produzieren, so dass die Wahrscheinlichkeit,
              dass sie zwei Nachrichten m1' und m2' mit demselben MDC erhält,
              mindestens 0,5 beträgt
        \item
              Da sie die Nachrichten zusammen mit ihren MDCs speichern muss, um eine
              Übereinstimmung zu finden, liegt der Speicherbedarf ihres Angriffs in
              der Größenordnung von \$2\^{}\{\textbackslash frac\{r\}\{2\}\}\$ und
              der Rechenzeitbedarf in der gleichen Größenordnung
        \item
              Nachdem sie m1' und m2' mit \$MDC1(m1')=MDC1(m2')\$ gefunden hat,
              fordert sie Alice auf, \$m2'\$ zu signieren. Eve kann dann diese
              Unterschrift nehmen und behaupten, dass Alice \$m1'\$ unterschrieben
              hat.
        \item
              Angriffe nach dieser Methode werden Geburtstagsangriffe genannt.
        \item
              Nehmen wir nun an, dass Alice RSA mit Schlüsseln der Länge 2048 Bit
              und eine kryptographische Hashfunktion verwendet, die MDCs der Länge
              96 Bit erzeugt.

              \begin{itemize}
                  \item
                        Eves durchschnittlicher Aufwand, zwei Nachrichten m1' und m2' wie
                        oben beschrieben zu erzeugen, liegt in der Größenordnung von
                        \$2\^{}\{48\}\$, was heute machbar ist. Das Knacken von
                        RSA-Schlüsseln der Länge 2048 Bit ist mit den heutigen Algorithmen
                        und Technologien bei weitem nicht möglich.
              \end{itemize}
    \end{itemize}


    \subsection{Übersicht über die gebräuchlichen
        MDCs}

    \begin{itemize}
        \item
              Kryptografische Hash-Funktionen zur Erstellung von MDCs:

              \begin{itemize}
                  \item
                        Message Digest 5 (MD5):

                        \begin{itemize}
                            \item
                                  Erfunden von R. Rivest
                            \item
                                  Nachfolger von MD
                        \end{itemize}
                  \item
                        Sicherer Hash-Algorithmus 1 (SHA-1):

                        \begin{itemize}
                            \item
                                  Erfunden von der National Security Agency (NSA)
                            \item
                                  Der Entwurf wurde von MD inspiriert.
                        \end{itemize}
                  \item
                        Sicherer Hash-Algorithmus 2 (SHA-2, auch SHA-256 und SHA-512)

                        \begin{itemize}
                            \item
                                  Ebenfalls von der National Security Agency (NSA) entwickelt
                            \item
                                  Auch Merkle-Dåmgard-Verfahren
                            \item
                                  Größere Blockgröße \& komplexere Rundenfunktion
                        \end{itemize}
                  \item
                        Sicherer Hash-Algorithmus 3 (SHA-3, Keccak)

                        \begin{itemize}
                            \item
                                  Gewinner eines offenen Wettbewerbs
                            \item
                                  Sogenannte Sponge-Konstruktion
                            \item
                                  Vielseitiger als frühere Hash-Funktionen
                        \end{itemize}
              \end{itemize}
        \item
              Nachrichten-Authentifizierungs-Codes (MACs):

              \begin{itemize}
                  \item
                        DES-CBC-MAC:

                        \begin{itemize}
                            \item
                                  Verwendet den Data Encryption Standard im Cipher Block Chaining
                                  Modus
                            \item
                                  Im Allgemeinen kann die CBC-MAC-Konstruktion mit jeder
                                  Blockchiffre verwendet werden.
                        \end{itemize}
                  \item
                        MACs, die aus MDCs aufgebaut sind:

                        \begin{itemize}
                            \item
                                  Dieser sehr verbreitete Ansatz wirft einige kryptografische
                                  Bedenken auf, da er einige implizite, aber nicht verifizierte
                                  Annahmen über die Eigenschaften der MDCs trifft.
                        \end{itemize}
              \end{itemize}
        \item
              Authentifizierte Verschlüsselung mit zugehörigen Daten (AEAD)

              \begin{itemize}
                  \item
                        Galois-Counter-Verfahren (GCM)

                        \begin{itemize}
                            \item
                                  Verwendet eine Blockchiffre zur Verschlüsselung und
                                  Authentifizierung von Daten
                            \item
                                  Schnell in Netzwerkanwendungen
                        \end{itemize}
                  \item
                        Sponge Wrap

                        \begin{itemize}
                            \item
                                  Verwendet eine SHA-3 ähnliche Hash-Funktion zur Verschlüsselung
                                  und Authentifizierung von Daten
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Gemeinsame Struktur von kryptografischen
        Hash-Funktionen}

    \begin{itemize}
        \item
              So wie viele der heutigen Blockchiffren der allgemeinen Struktur eines
              Feistel-Netzwerks folgen, folgen auch viele der heute verwendeten
              kryptografischen Hash-Funktionen einer gemeinsamen Struktur, der
              sogenannten Merkle-Dåmgard-Struktur:

              \begin{itemize}
                  \item
                        Sei y eine beliebige Nachricht. Normalerweise wird die Länge der
                        Nachricht an die Nachricht angehängt und auf ein Vielfaches einer
                        Blockgröße b aufgefüllt. Bezeichnen wir
                        \$(y\_0,y\_1,...,y\_\{L-1\})\$ die resultierende Nachricht, die aus
                        L Blöcken der Größe b
                  \item
                        Die allgemeine Struktur ist wie folgt abgebildet:
                        % \includegraphics{Assets/NetworkSecurity-feistel.png}
                  \item
                        CV ist ein Verkettungswert, mit \$CV\_0:= IV\$ und \$MDC(y) :=
                        CV\_L\$
                  \item
                        f ist eine spezifische Kompressionsfunktion, die \$(n+b)\$ Bit auf n
                        Bit komprimiert
              \end{itemize}
        \item
              Die Hash-Funktion H lässt sich wie folgt zusammenfassen:

              \begin{itemize}
                  \item
                        \$CV\_0 = IV =\$ anfänglicher n-Bit-Wert
                  \item
                        \$CV\_i = f(CV\_\{i -1\}, y\_\{i-1\})
                        \textbackslash quad\textbackslash quad 1\textbackslash leq i
                        \textbackslash leq L\$
                  \item
                        \$H(y) = CV\_L\$
              \end{itemize}
        \item
              Es wurde gezeigt {[}Mer89a{]}, dass, wenn die Kompressionsfunktion f
              kollisionssicher ist, die resultierende iterierte Hash-Funktion H
              ebenfalls kollisionssicher ist.
        \item
              Die Kryptoanalyse kryptographischer Hash-Funktionen konzentriert sich
              daher auf die interne Struktur der Funktion f und die Suche nach
              effizienten Techniken zur Erzeugung von Kollisionen bei einer einzigen
              Ausführung von f
        \item
              In erster Linie durch Geburtstagsangriffe motiviert, ist ein gängiger
              Mindestvorschlag für n , die Bitlänge des Hashwerts, 160 Bit, da dies
              einen Aufwand der Größenordnung \$2\^{}\{80\}\$ für einen Angriff
              impliziert, der heute als undurchführbar gilt
    \end{itemize}


    \subsection{Der Message Digest 5}

    \begin{itemize}
        \item
              MD5 folgt der zuvor skizzierten allgemeinen Struktur (z. B.
              {[}Riv92a{]}):

              \begin{itemize}
                  \item
                        Die Nachricht y wird mit einer ,,1'' aufgefüllt, gefolgt von 0 bis
                        511 ,,0'' Bits, so dass die Länge der resultierenden Nachricht
                        kongruent 448 modulo 512 ist
                  \item
                        Die Länge der ursprünglichen Nachricht wird als 64-Bit-Wert
                        hinzugefügt, so dass eine Nachricht entsteht, deren Länge ein
                        ganzzahliges Vielfaches von 512 Bit ist.
                  \item
                        Diese neue Nachricht wird in Blöcke der Länge \$b=512\$ Bit
                        unterteilt.
                  \item
                        Die Länge des Verkettungswertes ist \$n=128\$ Bit

                        \begin{itemize}
                            \item
                                  Der Verkettungswert ist ,,strukturiert'' als vier 32-Bit-Register
                                  A, B, C, D
                            \item
                                  Initialisierung:

                                  \begin{itemize}
                                      \item
                                            A := 0x 01 23 45 67
                                      \item
                                            B := 0x 89 AB CD EF
                                      \item
                                            C := 0x FE DC BA 98
                                      \item
                                            D := 0x 76 54 32 10
                                  \end{itemize}
                        \end{itemize}
                  \item
                        Jeder Block der Nachricht \$y\_i\$ wird mit dem Verkettungswert
                        \$CV\_i\$ mit der Funktion f verarbeitet, die intern durch 4 Runden
                        zu je 16 Schritten realisiert ist

                        \begin{itemize}
                            \item
                                  Jede Runde ist ähnlich aufgebaut und verwendet eine Tabelle T, die
                                  64 konstante Werte von je 32 Bit enthält,
                            \item
                                  Jede der vier Runden verwendet eine bestimmte logische Funktion g
                        \end{itemize}
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-md5.png}

              \begin{itemize}
                  \item
                        Die Funktion g ist eine von vier verschiedenen logischen Funktionen
                  \item
                        \$y\_i{[}k{]}\$ bezeichnet das k-te\$ 32-Bit-Wort des
                        Nachrichtenblocks i
                  \item
                        \$T{[}j{]}\$ ist der j-te Eintrag der Tabelle t, wobei j bei jedem
                        Schritt modulo 64 inkrementiert wird
                  \item
                        CLS s bezeichnet die zyklische Linksverschiebung um s Bits, wobei s
                        einem bestimmten Schema folgt.
              \end{itemize}
        \item
              Der MD5-MDC über eine Nachricht ist der Inhalt des Verkettungswertes
              CV nach Verarbeitung des letzten Nachrichtenblocks.
        \item
              Sicherheit von MD5:

              \begin{itemize}
                  \item
                        Jedes Bit des 128-Bit-Hash-Codes ist eine Funktion eines jeden
                        Eingabebits
                  \item
                        1996 veröffentlichte H. Dobbertin einen Angriff, der es erlaubt,
                        eine Kollision für die Funktion f zu erzeugen (realisiert durch die
                        oben beschriebenen 64 Schritte).
                  \item
                        Es dauerte bis 2004, bis eine erste Kollision gefunden wurde
                        {[}WLYF04{]}.
                  \item
                        Inzwischen ist es möglich, Kollisionen innerhalb von Sekunden auf
                        allgemeiner Hardware zu erzeugen {[}Kl06{]}.
                  \item
                        MD5 darf nicht in Betracht gezogen werden, wenn Kollisionssicherheit
                        erforderlich ist!

                        \begin{itemize}
                            \item
                                  Dies ist oft der Fall!
                            \item
                                  Beispiele: Zwei Postskripte mit unterschiedlichen Texten, aber
                                  gleichen Hashes {[}LD05{]}, Zertifikate, eines für eine gesicherte
                                  Domain und eines für eine eigene Zertifizierungsstelle
                                  {[}LWW05{]}, Jede Nachricht, die erweiterbar ist {[}KK06{]}
                        \end{itemize}
                  \item
                        Die Resistenz gegen Preimage-Angriffe ist mit 2123.4 Berechnungen
                        noch o.k{[}SA09{]}
              \end{itemize}
    \end{itemize}


    \subsection{Der sichere Hash-Algorithmus
        SHA-1}

    \begin{itemize}
        \item
              Auch SHA-1 folgt der gleichen Struktur wie oben beschrieben:

              \begin{itemize}
                  \item
                        SHA-1 arbeitet mit 512-Bit-Blöcken und erzeugt einen
                        160-Bit-Hash-Wert.
                  \item
                        Da sein Design auch vom MD4-Algorithmus inspiriert wurde, ist seine
                        Initialisierung im Grunde dieselbe wie die von MD5:

                        \begin{itemize}
                            \item
                                  Die Daten werden aufgefüllt, ein Längenfeld wird hinzugefügt und
                                  die resultierende Nachricht wird als Blöcke der Länge 512 Bit
                                  verarbeitet.
                            \item
                                  Der Verkettungswert ist als fünf 32-Bit-Register A, B, C, D, E
                                  strukturiert
                            \item
                                  Initialisierung:

                                  \begin{itemize}
                                      \item
                                            A = 0x 67 45 23 01
                                      \item
                                            B = 0x EF CD AB 89
                                      \item
                                            C = 0x 98 BA DC FE
                                      \item
                                            D = 0x 10 32 54 76
                                      \item
                                            E = 0x C3 D2 E1 F
                                  \end{itemize}
                            \item
                                  Die Werte werden im Big-Endian-Format gespeichert.
                        \end{itemize}
                  \item
                        Jeder Block yi der Nachricht wird zusammen mit CVi in einem Modul
                        verarbeitet, das die Kompressionsfunktion f in vier Runden zu je 20
                        Schritten realisiert.

                        \begin{itemize}
                            \item
                                  Die Runden haben eine ähnliche Struktur, aber jede Runde verwendet
                                  eine andere primitive logische Funktion \$f\_1, f\_2, f\_3,
                                  f\_4\$.
                            \item
                                  Bei jedem Schritt wird eine feste additive Konstante \$K\_t\$
                                  verwendet, die während einer Runde unverändert bleibt
                        \end{itemize}
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-sha1.png}

              \begin{itemize}
                  \item
                        \$t\textbackslash in\{0,...,15\}\textbackslash Rightarrow W\_t:=
                        y\_i{[}t{]}\$
                  \item
                        \$t\textbackslash in\{16,...,79\}\textbackslash Rightarrow
                        W\_t:=CLS\_1(W\_\{t-16\}\textbackslash oplus
                        W\_\{t-14\}\textbackslash oplus W\_\{t-8\} \textbackslash oplus
                        W\_\{t-3\})\$
                  \item
                        Nach Schritt 79 wird jedes Register A, B, C, D, E modulo
                        \$2\^{}\{32\}\$ mit dem Wert des entsprechenden Registers vor
                        Schritt 0 addiert, um \$CV\_\{i+1\}\$ zu berechnen
              \end{itemize}
        \item
              Der SHA-1-MDC über eine Nachricht ist der Inhalt des Verkettungswertes
              CV nach Verarbeitung des letzten Nachrichtenblocks.
        \item
              Vergleich zwischen SHA-1 und MD5:

              \begin{itemize}
                  \item
                        Geschwindigkeit: SHA-1 ist etwa 25\% langsamer als MD5 (CV ist etwa
                        25\% größer)
                  \item
                        Einfachheit und Kompaktheit: beide Algorithmen sind einfach zu
                        beschreiben und zu implementieren und erfordern keine großen
                        Programme oder Ersetzungstabellen
              \end{itemize}
        \item
              Sicherheit von SHA-1:

              \begin{itemize}
                  \item
                        Da SHA-1 MDCs der Länge 160 Bit erzeugt, wird erwartet, dass es eine
                        bessere Sicherheit gegen Brute-Force- und Geburtstagsangriffe bietet
                        als MD5.
                  \item
                        Einige inhärente Schwächen von Merkle-Dåmgard-Konstruktionen, z. B.
                        {[}KK06{]}, sind vorhanden
                  \item
                        Im Februar 2005 veröffentlichten X. Wang et. al. einen Angriff, der
                        es erlaubt, eine Kollision mit einem Aufwand von \$2\^{}\{69\}\$ zu
                        finden, der in den folgenden Monaten auf \$2\^{}\{63\}\$ verbessert
                        und in {[}WYY05a{]} veröffentlicht wurde
                  \item
                        Die Forschung ging weiter (z.B. {[}Man11{]}), und im Februar 2017
                        wurde die erste tatsächliche Kollision gefunden (demonstriert mit
                        einem veränderten PDF-Dokument)
              \end{itemize}
        \item
              SHA-2-Familie

              \begin{itemize}
                  \item
                        Im Jahr 2001 veröffentlichte das NIST einen neuen Standard FIPS PUB
                        180-2, der neue Varianten mit den Bezeichnungen SHA-256, SHA-384 und
                        SHA-512 {[}NIST02{]} mit 256, 384 und 512 Bits enthält.

                        \begin{itemize}
                            \item
                                  SHA-224 wurde im Jahr 2004 hinzugefügt.
                        \end{itemize}
                  \item
                        SHA-224 und SHA-384 sind verkürzte Versionen von SHA-256 und SHA-512
                        mit unterschiedlichen Initialisierungswerten
                  \item
                        SHA-2 verwendet ebenfalls die Merkle-Dåmgard-Konstruktion mit einer
                        Blockgröße von 512 Bit (SHA-256) und 1024 Bit (SHA-512)
                  \item
                        Der interne Zustand ist in 8 Registern von 32 Bit (SHA-256) und 64
                        Bit (SHA-512) organisiert
                  \item
                        64 Runden (SHA-256) oder 80 Runden (SHA-512)
              \end{itemize}
        \item
              Ein Schritt

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-sha-2.png}
                  \item
                        \$t\textbackslash in\{0, ..., 15\}\textbackslash Rightarrow
                        W\_t:=y\_i{[}t{]}\$
                  \item
                        \$t\textbackslash in\{16, ..., r\}\textbackslash Rightarrow
                        W\_t:=W\_\{t-16\}\textbackslash oplus
                        \textbackslash delta\_0(W\_\{t-15\})\textbackslash oplus
                        W\_\{t-7\}\textbackslash oplus\textbackslash delta\_1(W\_\{t-2\})\$
                  \item
                        \$K\_t\$ ist der gebrochene Teil der Kubikwurzel aus der t-ten
                        Primzahl
                  \item
                        Die ROTR- und Funktionen XOR-verknüpfen verschiedene Verschiebungen
                        des Eingangswertes
                  \item
                        Ch und Maj sind logische Kombinationen der Eingabewerte
              \end{itemize}
        \item
              SHA-2-Familie

              \begin{itemize}
                  \item
                        Alles in allem sehr ähnlich zu SHA-1
                  \item
                        Aufgrund der Größe und der komplizierteren Rundungsfunktionen etwa
                        30-50 Prozent langsamer als SHA-1 (variiert für 64-Bit- und
                        32-Bit-Systeme!)
                  \item
                        Sicherheitsdiskussion:

                        \begin{itemize}
                            \item
                                  Bereits 2004 wurde entdeckt, dass eine vereinfachte Version des
                                  Algorithmus (mit XOR statt Addition und symmetrischen Konstanten)
                                  hochkorrelierte Ausgaben erzeugt {[}GH04{]}
                            \item
                                  Für rundenreduzierte Versionen von SHA-2 gibt es
                                  Pre-Image-Angriffe, die schneller sind als Brute-Force, aber sehr
                                  unpraktisch (z.B. {[}AGM09{]})
                            \item
                                  Auch wenn Größe und Komplexität derzeit keine Angriffe zulassen,
                                  ist die Situation unangenehm
                            \item
                                  Dies führte zur Notwendigkeit eines neuen SHA-3-Standards
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Der sichere Hash-Algorithmus
        SHA-3}

    \begin{itemize}
        \item
              Sicherheitsbedenken bezüglich SHA-1 und SHA-2 führten zu einem offenen
              Wettbewerb des NIST, der 2007 begann

              \begin{itemize}
                  \item
                        5 Finalisten ohne nennenswerte Schwächen
                  \item
                        Oktober 2012: NIST gibt bekannt, dass Keccak zu SHA-3 wird
                  \item
                        4 europäische Erfinder
                  \item
                        Einer davon ist Joan Daemen, der AES mitentwickelt hat
                  \item
                        SHA-3 ist sehr schnell, besonders in der Hardware
                  \item
                        Sehr gut dokumentiert und analysierbar
              \end{itemize}
        \item
              Keccak basiert auf einer so genannten Schwammkonstruktion anstelle der
              früheren Merkle-Dåmgard-Konstruktionen

              \begin{itemize}
                  \item
                        Vielseitiges Design, um fast alle symmetrischen kryptographischen
                        Funktionen zu implementieren (allerdings ist nur das Hashing
                        standardisiert)
              \end{itemize}
        \item
              Arbeitet normalerweise in 2 Phasen

              \begin{itemize}
                  \item
                        ,,Absorbieren'' von Informationen beliebiger Länge in 1600 Bit des
                        internen Zustands
                  \item
                        ,,Auspressen'' (d.h. Ausgeben) von Hash-Daten beliebiger Länge (nur
                        224, 256, 384 und 512 Bit standardisiert)
              \end{itemize}
        \item
              Der interne Zustand ist in 2 Registern organisiert

              \begin{itemize}
                  \item
                        Ein Register der Größe r ist ,,public'': Eingabedaten werden in der
                        Absorptionsphase mit XOR verknüpft, Ausgabedaten werden in der
                        Quetschungsphase daraus abgeleitet
                  \item
                        Das Register der Größe c ist ,,privat''; Ein- und Ausgabe wirken
                        sich nicht direkt auf es aus.
                  \item
                        In Keccak ist die Größe der Register 1600 Bits (d.h. \$c+r=1600\$
                        Bits)
                  \item
                        Die Größe von c ist doppelt so groß wie die Länge des Ausgangsblocks
                  \item
                        Beide Register werden mit ,,0'' initialisiert
              \end{itemize}
        \item
              Das Hashing erfolgt durch eine Funktion f, die die Register liest und
              einen neuen Zustand ausgibt
        \item
              Sponge-Konstruktion

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-sha-3.png}
                  \item
                        Absorptionsphase: \$k + 1\$ Eingabeblöcke der Größe r werden in den
                        Zustand gemischt
                  \item
                        Quetschphase: \$l + 1\$ Ausgangsblöcke der Größe r werden erzeugt
                        (oft nur einer)
                  \item
                        Der letzte Eingabe- und Ausgabeblock kann aufgefüllt oder
                        abgeschnitten werden.
              \end{itemize}
        \item
              Die Funktion f

              \begin{itemize}
                  \item
                        Offensichtlich hängt die Sicherheit einer Sponge-Konstruktion von
                        der Sicherheit von f
                  \item
                        Keccak verwendet 24 Runden von 5 verschiedenen Unterfunktionen
                        \$(\textbackslash Sigma, \textbackslash ro,\textbackslash pi,$\chi$,$\iota$)\$,
                        um f zu implementieren.
                  \item
                        Die Unterfunktionen operieren auf einem ,,dreidimensionalen''
                        Bit-Array a \${[}5{]}{[}5{]}{[}w{]}\$, wobei w entsprechend der
                        Größe r und c gewählt wird
                  \item
                        Alle Operationen werden über \$GF(2\^{}n)\$ durchgeführt.
                  \item
                        Jede der Unterfunktionen gewährleistet bestimmte Eigenschaften, z.B,

                        \begin{itemize}
                            \item
                                  Schnelle Diffusion der geänderten Bits im gesamten Zustand
                                  (\$\textbackslash Sigma\$)
                            \item
                                  Langfristige Diffusion (\$\textbackslash pi\$)
                            \item
                                  Sicherstellung, dass f nichtlinear wird ($\chi$)
                            \item
                                  Rundenspezifische Substitution ($\iota$)
                        \end{itemize}
              \end{itemize}
        \item
              \$\textbackslash Sigma\$ wird zuerst ausgeführt, um sicherzustellen,
              dass sich der geheime und der öffentliche Zustand schnell vermischen,
              bevor andere Unterfunktionen angewendet werden.
        \item
              Sicherheit

              \begin{itemize}
                  \item
                        Derzeit gibt es keine nennenswerten Schwachstellen in SHA-3

                        \begin{itemize}
                            \item
                                  Die bekanntesten Pre-Image-Angriffe funktionieren nur mit einer
                                  Funktion f mit bis zu 8 Runden
                            \item
                                  Zum Schutz vor internen Kollisionen sollten 11 Runden ausreichen.
                        \end{itemize}
                  \item
                        Im Vergleich zu SHA-1 und SHA-2 werden zusätzliche
                        Sicherheitseigenschaften garantiert, da der interne Zustand nie
                        öffentlich gemacht wird

                        \begin{itemize}
                            \item
                                  Verhindert Angriffe, bei denen beliebige Informationen zu einer
                                  gültigen geheimen Nachricht hinzugefügt werden
                            \item
                                  Bietet Chosen Target Forced Prefix (CTFP) Preimage-Resistenz
                                  {[}KK06{]}, d.h. es ist nicht möglich, eine Nachricht
                                  \$m=P\textbar\textbar S\$ zu konstruieren, wobei P fest und S
                                  beliebig gewählt ist, s.t., \$H(m)=y\$
                            \item
                                  Für Merkle-Dåmgard-Konstruktionen ist dies nur so schwer wie die
                                  Kollisionssicherheit
                            \item
                                  Keine schnelle Möglichkeit, Multikollisionen schnell zu erzeugen
                                  {[}Jou04{]}
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Cipher Block Chaining Message Authentication
        Codes}

    \begin{itemize}
        \item
              Ein CBC-MAC wird berechnet, indem eine Nachricht im CBC-Modus
              verschlüsselt wird und der letzte Chiffretextblock oder ein Teil davon
              als MAC verwendet wird:

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-CBC-mac.png}
              \end{itemize}
        \item
              Dieser MAC muss nicht mehr signiert werden, da er bereits mit einem
              gemeinsamen Geheimnis K erzeugt wurde.

              \begin{itemize}
                  \item
                        Es ist jedoch nicht möglich zu sagen, wer genau einen MAC erstellt
                        hat, da jeder (Sender, Empfänger), der den geheimen Schlüssel K
                        kennt, dies tun kann
              \end{itemize}
        \item
              Dieses Verfahren funktioniert mit jeder Blockchiffre (DES, IDEA, ...)
        \item
              Sicherheit von CBC-MAC:

              \begin{itemize}
                  \item
                        Da ein Angreifer K nicht kennt, ist ein Geburtstagsangriff sehr viel
                        schwieriger (wenn nicht gar unmöglich) zu starten
                  \item
                        Ein Angriff auf einen CBC-MAC erfordert bekannte Paare (Nachricht,
                        MAC)
                  \item
                        Dies ermöglicht kürzere MACs
                  \item
                        Ein CBC-MAC kann optional verstärkt werden, indem man sich auf einen
                        zweiten Schlüssel \$K'\textbackslash not= K\$ einigt und eine
                        dreifache Verschlüsselung des letzten Blocks durchführt:
                        \$MAC:=E(K,D(K',E(K,C\_\{n-1\})))\$
                  \item
                        Dadurch verdoppelt sich der Schlüsselraum bei nur geringem
                        Rechenaufwand
                  \item
                        Die Konstruktion ist nicht sicher, wenn die Nachrichtenlängen
                        variieren!
              \end{itemize}
        \item
              Es gibt auch einige Vorschläge, MDCs aus symmetrischen Blockchiffren
              zu erzeugen, indem der Schlüssel auf einen festen (bekannten) Wert
              gesetzt wird:

              \begin{itemize}
                  \item
                        Wegen der relativ kleinen Blockgröße von 64 Bit der meisten gängigen
                        Blockchiffren bieten diese Verfahren keine ausreichende Sicherheit
                        gegen Geburtstagsangriffe.
                  \item
                        Da symmetrische Blockchiffren mehr Rechenaufwand erfordern als
                        spezielle kryptografische Hash-Funktionen, sind diese Verfahren
                        relativ langsam.
              \end{itemize}
    \end{itemize}


    \subsection{Konstruktion eines MAC aus einem
        MDC}

    \begin{itemize}
        \item
              Grund für die Konstruktion von MACs aus MDCs Kryptografische
              Hash-Funktionen laufen im Allgemeinen schneller ab als symmetrische
              Blockchiffren
        \item
              Grundidee: ,,mix'' einen geheimen Schlüssel K mit der Eingabe und
              berechne einen MDC
        \item
              Die Annahme, dass ein Angreifer K kennen muss, um einen gültigen MAC
              zu erzeugen, wirft dennoch einige kryptografische Probleme auf
              (zumindest für Merkle-Dåmgard-Hash-Funktionen):

              \begin{itemize}
                  \item
                        Die Konstruktion \$H(K\textbar\textbar m)\$ ist nicht sicher (siehe
                        Anmerkung 9.64 in {[}Men97a{]})
                  \item
                        Die Konstruktion \$H(m\textbar\textbar K)\$ ist nicht sicher (siehe
                        Bemerkung 9.65 in {[}Men97a{]})
                  \item
                        Die Konstruktion
                        \$H(K\textbar\textbar p\textbar\textbar m\textbar\textbar K)\$, bei
                        der p ein zusätzliches Auffüllfeld bezeichnet, bietet keine
                        ausreichende Sicherheit (siehe Anmerkung 9.66 in {[}Men97a{]})
              \end{itemize}
        \item
              Die am häufigsten verwendete Konstruktion ist:
              \$H(K\textbackslash oplus p\_1\textbar\textbar{}
              H(K\textbackslash oplus p\_2\textbar\textbar{} m))\$

              \begin{itemize}
                  \item
                        Der Schlüssel wird mit 0's aufgefüllt, um den Schlüssel zu einem
                        Eingabeblock der kryptographischen Hashfunktion aufzufüllen
                  \item
                        Zwei verschiedene konstante Muster \$p\_1\$ und \$p\_2\$ werden mit
                        dem aufgefüllten Schlüssel XOR-verknüpft
                  \item
                        Dieses Schema scheint sicher zu sein (siehe Anmerkung 9.67 in
                        {[}Men97a{]})
                  \item
                        Es wurde in RFC 2104 {[}Kra97a{]} standardisiert und wird HMAC
                        genannt.
              \end{itemize}
    \end{itemize}


    \subsection{Authentifizierte Verschlüsselung mit zugehörigen Daten
        (AEAD)
        Modi}

    \begin{itemize}
        \item
              Normalerweise sind die Daten nicht authentifiziert oder verschlüsselt,
              sondern verschlüsselt UND authentifiziert (Blöcke \$P\_0...P\_n\$)
        \item
              Manchmal müssen zusätzliche Daten authentifiziert werden (z.B.
              Paketköpfe), im Folgenden mit \$A\_0...A\_m\$ bezeichnet
        \item
              führte zur Entwicklung von AEAD-Betriebsarten
        \item
              Beispiele hierfür sind

              \begin{itemize}
                  \item
                        Galois/Zähler-Modus (GCM)
                  \item
                        Zähler mit CBC-MAC (CCM)
                  \item
                        Offset-Codebuch-Modus (OCM)
                  \item
                        SpongeWrap - eine Methode zur Verwendung von Keccak für den
                        AEAD-Betrieb
              \end{itemize}
    \end{itemize}


    \subsubsection{Galois/Zähler-Modus (GCM)
    {[}MV04{]}}

    \begin{itemize}
        \item
              Beliebter AEAD-Modus
        \item
              NIST-Standard, Teil von IEEE 802.1AE, IPsec, TLS, SSH usw.
        \item
              Frei von Patenten
        \item
              Wird wegen seiner hohen Geschwindigkeit hauptsächlich in
              Netzwerkanwendungen eingesetzt

              \begin{itemize}
                  \item
                        Äußerst effizient in der Hardware
                  \item
                        Prozessorunterstützung auf neueren x86-CPUs
                  \item
                        Zeitintensive Aufgaben können vorberechnet und parallelisiert werden
                  \item
                        Keine Notwendigkeit für Auffüllungen
              \end{itemize}
        \item
              Verwendet konventionelle Blockchiffre mit 128-Bit-Blockgröße (z. B.
              AES)
        \item
              Berechnet MAC durch Multiplikationen und Additionen in
              \$GF(2\^{}\{128\})\$ über das irreduzible Polynom
              \$x\^{}\{128\}+x\^{}\{7\}+x\^{}\{2\}+x+1\$
        \item
              Erfordert nur \$n+1\$ Blockchiffre-Aufrufe pro Paket (n = Länge der
              verschlüsselten und authentifizierten Daten)
        \item
              % \includegraphics{Assets/NetworkSecurity-gcm.png}

              \begin{itemize}
                  \item
                        \$I\_0\$ wird mit dem IV und einem Padding oder einem Hash des IV
                        initialisiert (wenn er nicht 96 Bit beträgt)
                  \item
                        \$\textbackslash circ H\$ ist \$GF(2\^{}\{128\})\$ Multiplikation
                        mit \$H=E(K,0\^{}\{128\})\$
                  \item
                        Die Eingabeblöcke \$A\_m\$ und \$P\_n\$ werden auf 128 Bit
                        aufgefüllt
                  \item
                        \$A\_m\$ und \$C\_n\$ werden vor der Ausgabe auf die Originalgröße
                        gekürzt
                  \item
                        Die letzte Authentifizierung verwendet 64 Bit kodierte Bitlängen von
                        A und C
              \end{itemize}
        \item
              Sicherheit

              \begin{itemize}
                  \item
                        Schneller Modus, erfordert aber einige Sorgfalt:

                        \begin{itemize}
                            \item
                                  Erwiesenermaßen sicher (unter bestimmten Voraussetzungen, z. B.
                                  wenn die verwendete Blockchiffre nicht von Zufallszahlen
                                  unterscheidbar ist), aber die Konstruktion ist anfällig:
                        \end{itemize}
                  \item
                        IVs MÜSSEN NICHT wiederverwendet werden, da sonst Datenströme
                        XOR-verknüpft werden können und das XOR der Datenströme
                        wiederhergestellt werden kann, was zu einer sofortigen
                        Wiederherstellung des geheimen Werts ,,H'' führen kann
                  \item
                        H hat einen möglichen schwachen Wert \$0\^{}\{128\}\$, in diesem
                        Fall wird die Authentifizierung nicht funktionieren, und wenn IVs
                        mit einer anderen Länge als 96 Bits verwendet werden, wird \$C\_0\$
                        immer gleich sein!
                  \item
                        Einige andere Schlüssel erzeugen Hash-Schlüssel mit einer niedrigen
                        Ordnung, was vermieden werden muss... {[}Saa11{]}
                  \item
                        Erfolgreiche Fälschungsversuche können Informationen über H
                        durchsickern lassen, daher MÜSSEN kurze MAC-Längen vermieden oder
                        risikominimiert werden {[}Dwo07{]}
                  \item
                        Die erreichte Sicherheit ist nur \$2\^{}\{t-k\}\$ und nicht
                        \$2\^{}t\$ (für MAC-Länge t und Anzahl der Blöcke \$2\^{}k\$), da
                        Blöcke modifiziert werden können, um nur Teile des MAC zu ändern
                        {[}Fer05{]}
              \end{itemize}
    \end{itemize}


    \subsubsection{Kleiner Exkurs: Rechenoperationen in
    \$GF(2\^{}n)\$}

    \begin{itemize}
        \item
              Galoisfeld-Arithmetik definiert über Termen (z.B.
              \$a\_3x\^{}3+a\_2x\^{}2+a\_1x+a\_0\$)
        \item
              Koeffizienten sind Elemente des Feldes
              \$\textbackslash matbb\{Z\}\_2\$, d.h. entweder 0 oder 1
        \item
              Oft werden nur die Koeffizienten gespeichert, so wird aus x\^{}4
              +x\^{}2 +x\^{}1 0x16
        \item
              Die Addition in \$GF(2\^{}n)\$ ist einfach die Addition von Termen

              \begin{itemize}
                  \item
                        Da gleiche Koeffizienten auf 0 abbilden, einfach XOR der Werte!
                  \item
                        Extrem schnell in Hard- und Software!
              \end{itemize}
        \item
              Multiplikation in \$GF(2\^{}n)\$ ist Polynommultiplikation und
              anschließende Modulodivision durch ein irreduzibles Polynom vom Grad n

              \begin{itemize}
                  \item
                        Irreduzible Polynome sind nicht ohne Rest durch irgendein anderes
                        Polynom teilbar, außer durch ,,1'', ähnlich wie Primzahlen in GF
                  \item
                        Kann durch eine Reihe von Verschiebe- und XOR-Operationen
                        implementiert werden
                  \item
                        Sehr schnell in Hardware oder auf neueren Intel-CPUs (mit
                        CLMUL-Operationen)
                  \item
                        Modulo-Operation kann wie bei einer regulären CRC-Berechnung
                        durchgeführt werden
              \end{itemize}
        \item
              Addition Beispiel:

              \begin{itemize}
                  \item
                        \$x\^{}3 +x+1 x\textbackslash oplus x\^{}2+x = x\^{}3 +x\^{}2 +1
                        \textbackslash leftrightarrow\$ 0x0B XOR 0x06 = 0x0D
              \end{itemize}
        \item
              Multiplikationsbeispiel (über \$x\^{}4 +x+1\$):

              \begin{itemize}
                  \item
                        \$x\^{}3 +x+1\textbackslash circ x\^{}2+x =
                        x\^{}5+x\^{}3+x\^{}2\textbackslash oplus
                        x\^{}4+x\^{}2+x\textbackslash{} MOD\textbackslash{}
                        x\^{}4+x+1=x\^{}5+x\^{}4+x\^{}3+x\textbackslash{}
                        MOD\textbackslash{} x\^{}4+x+1 = x\^{}3 +x\^{}2 +x+1\$
              \end{itemize}
        \item
              Elemente von \$GF(2\^{}n)\$ (mit Ausnahme von 1 und dem irreduziblen
              Polynom) können ein Generator für die Gruppe sein
        \item
              Beispiel für x und das Polynom
              \$x\^{}4+x+1:x,x\^{}2,x\^{}3,x+1,x\^{}2+x,x\^{}3+x\^{}2,x\^{}3+x+1,x\^{}2
              +1,x\^{}3+x,x\^{}2+x+1,x\^{}3+x\^{}2+x,x\^{}3+x\^{}2+x+1,x\^{}3+x\^{}2+1,x\^{}3+1,1,x,...\$
        \item
              Andere Konzepte endlicher Gruppen gelten ebenfalls, z. B. hat jedes
              Element ein multiplikatives inverses Element

              \begin{itemize}
                  \item
                        Kann durch eine angepasste Version des Erweiterten Euklidischen
                        Algorithmus gefunden werden
              \end{itemize}
    \end{itemize}


    \subsection{SpongeWrap}

    \begin{itemize}
        \item
              Durch Verwendung von SHA-3 ist es auch möglich, ein AEAD-Konstrukt zu
              implementieren {[}BDP11a{]}
        \item
              Die Konstruktion ist sehr einfach und vergleichsweise leicht zu
              verstehen
        \item
              Verwendet den sogenannten Duplex-Modus für Sponge-Funktionen, bei dem
              Schreib- und Leseoperationen verschachtelt werden
        \item
              Erfordert kein Auffüllen der Daten auf eine bestimmte Blockgröße
        \item
              Kann nicht parallelisiert werden
        \item
              Sicherheit:

              \begin{itemize}
                  \item
                        Noch nicht weit verbreitet, aber mehrere Aspekte haben sich als
                        genauso sicher wie SHA-3 im standardisierten Modus erwiesen
                  \item
                        Wenn die authentifizierten Daten A keine eindeutige IV enthalten,
                        wird derselbe Schlüsselstrom erzeugt (ermöglicht die
                        Wiederherstellung eines Blocks XOR-verschlüsselter Daten)
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-sponge-wrap.png}

              \begin{itemize}
                  \item
                        Vereinfachte Version, bei der die Länge von Schlüssel und MAC
                        kleiner sein muss als die Blockgröße
                  \item
                        Auffüllungen mit einem einzelnen ,,0''- oder ,,1''-Bit stellen
                        sicher, dass verschiedene Datenblocktypen gut voneinander getrennt
                        sind
              \end{itemize}
    \end{itemize}


    \section{Zufallszahlengenerierung}


    \subsection{Aufgaben der
        Schlüsselverwaltung}

    \begin{itemize}
        \item
              Erzeugung:

              \begin{itemize}
                  \item
                        Für die Sicherheit ist es von entscheidender Bedeutung, dass die
                        Schlüssel mit einem wirklich zufälligen oder zumindest
                        pseudozufälligen Generierungsverfahren erzeugt werden (siehe unten).
                  \item
                        Andernfalls könnte ein Angreifer den Schlüsselgenerierungsprozess
                        reproduzieren und den zur Sicherung einer bestimmten Kommunikation
                        verwendeten Schlüssel leicht finden.
              \end{itemize}
        \item
              Verteilung:

              \begin{itemize}
                  \item
                        Die Verteilung einiger anfänglicher Schlüssel muss in der Regel
                        manuell / "out of band" erfolgen.
                  \item
                        Die Verteilung von Sitzungsschlüsseln wird in der Regel während
                        eines Authentifizierungsaustauschs durchgeführt.
                  \item
                        Beispiele: Diffie-Hellman, Otway-Rees, Kerberos, X.
              \end{itemize}
        \item
              Speicherung:

              \begin{itemize}
                  \item
                        Schlüssel, insbesondere Authentifizierungsschlüssel, sollten sicher
                        gespeichert werden:

                        \begin{itemize}
                            \item
                                  entweder verschlüsselt mit einer schwer zu erratenden Passphrase,
                                  oder besser
                            \item
                                  in einem sicheren Gerät wie einer Smart-Card
                        \end{itemize}
              \end{itemize}
        \item
              Entzug:

              \begin{itemize}
                  \item
                        Wenn ein Schlüssel kompromittiert wurde, sollte es möglich sein,
                        diesen Schlüssel zu widerrufen, damit er nicht mehr missbraucht
                        werden kann (vgl. X.509).
              \end{itemize}
        \item
              Vernichtung:

              \begin{itemize}
                  \item
                        Schlüssel, die nicht mehr verwendet werden (z. B. alte
                        Sitzungsschlüssel), sollten sicher vernichtet werden.
              \end{itemize}
        \item
              Wiederherstellung:

              \begin{itemize}
                  \item
                        Wenn ein Schlüssel verloren gegangen ist (z. B. defekte Chipkarte,
                        Diskette, versehentliches Löschen), sollte er wiederhergestellt
                        werden können, um Datenverluste zu vermeiden.
                  \item
                        Die Wiederherstellung von Schlüsseln ist nicht zu verwechseln mit
                        der Schlüsselhinterlegung
              \end{itemize}
        \item
              Hinterlegung:

              \begin{itemize}
                  \item
                        Mechanismen und Architekturen, die es staatlichen Stellen (und nur
                        diesen) ermöglichen sollen, Sitzungsschlüssel zu erhalten, um zu
                        Strafverfolgungszwecken die Kommunikation abzuhören / gespeicherte
                        Daten zu lesen

                        \begin{itemize}
                            \item
                                  Wenn ich meinen Schlüssel zurückbekomme, ist es
                                  Schlüsselwiederherstellung, wenn du meinen Schlüssel
                                  zurückbekommst, ist es Schlüsselhinterlegung...'')
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Zufalls- und
        Pseudo-Zufallszahlengenerierung}

    \begin{itemize}
        \item
              Definition: ,,Ein Zufallsbitgenerator ist ein Gerät oder ein
              Algorithmus, der eine Folge statistisch unabhängiger und
              unverfälschter Binärziffern ausgibt.''
        \item
              Bemerkung: Ein Zufallsbitgenerator kann zur Erzeugung gleichmäßig
              verteilter Zufallszahlen verwendet werden, z. B. kann eine zufällige
              ganze Zahl im Intervall \${[}0,n{]}\$ erhalten werden, indem eine
              zufällige Bitfolge der Länge \$\textbackslash lfloor lg
              n\textbackslash rfloor+1\$ erzeugt und in eine Zahl umgewandelt wird.
              Ist die resultierende ganze Zahl größer als n, so kann sie verworfen
              werden, und der Vorgang wird so lange wiederholt, bis eine ganze Zahl
              im gewünschten Bereich erzeugt worden ist.
        \item
              Definition: Ein Pseudo-Zufallsbitgenerator (PRBG) ist ein
              deterministischer Algorithmus, der bei einer wirklich zufälligen
              Binärfolge der Länge k eine Binärfolge der Länge
              \$m\textgreater\textgreater k\$ ausgibt, die ,,zufällig'' erscheint.
              Die Eingabe in den PRBG wird als Seed bezeichnet, die Ausgabe als
              pseudozufällige Bitfolge.
        \item
              Bemerkungen:

              \begin{itemize}
                  \item
                        Die Ausgabe eines PRBG ist nicht zufällig, tatsächlich ist die
                        Anzahl der möglichen Ausgabesequenzen der Länge m höchstens ein
                        kleiner Bruchteil \$2\^{}k/2\^{}m\$, da der PRBG immer dieselbe
                        Ausgabesequenz für einen (festen) Seed erzeugt
                  \item
                        Die Motivation für die Verwendung einer PRBG ist, dass es zu teuer
                        sein könnte, echte Zufallszahlen der Länge m zu erzeugen, z. B.
                        durch Münzwurf, so dass nur eine kleinere Menge von Zufallsbits
                        erzeugt wird und dann aus den k echten Zufallsbits eine
                        pseudozufällige Bitfolge erzeugt wird
                  \item
                        Um Vertrauen in die ,,Zufälligkeit'' einer Pseudo-Zufallsfolge zu
                        gewinnen, werden statistische Tests mit den erzeugten Folgen
                        durchgeführt
              \end{itemize}
        \item
              Beispiel:

              \begin{itemize}
                  \item
                        Ein linearer Kongruenzgenerator erzeugt eine Pseudo-Zufallsfolge von
                        Zahlen \$y\_1,y\_2, ...\$ gemäß der linearen Rekursion \$y\_i=
                        a\textbackslash times y\_\{i-1\} + b\textbackslash{}
                        mod\textbackslash{} q\$, wobei \$a, b, q\$ Parameter sind, die den
                        PRBG charakterisieren
                  \item
                        Leider ist dieser Generator auch dann vorhersehbar, wenn \$a, b\$
                        und \$q\$ unbekannt sind, und sollte daher nicht für
                        kryptographische Zwecke verwendet werden
              \end{itemize}
        \item
              Sicherheitsanforderungen an PRBGs für die Verwendung in der
              Kryptographie:

              \begin{itemize}
                  \item
                        Als Mindestsicherheitsanforderung sollte die Länge k des Seeds einer
                        PRBG so groß sein, dass eine Brute-Force-Suche über alle Seeds für
                        einen Angreifer nicht durchführbar ist
                  \item
                        Die Ausgabe einer PRBG sollte statistisch nicht von echten
                        Zufallssequenzen unterscheidbar sein.
                  \item
                        Die Ausgabebits sollten für einen Angreifer mit begrenzten
                        Ressourcen unvorhersehbar sein, wenn er den Seed nicht kennt.
              \end{itemize}
        \item
              Definition: Ein PRBG besteht alle statistischen Polynomialzeit-Tests,
              wenn kein deterministischer Polynomialzeit-Algorithmus zwischen einer
              Ausgangssequenz des Generators und einer echten Zufallssequenz
              derselben Länge mit einer Wahrscheinlichkeit deutlich größer als 0
              unterscheiden kann.

              \begin{itemize}
                  \item
                        Polynomialzeit-Algorithmus bedeutet, dass die Laufzeit des
                        Algorithmus durch ein Polynom in der Länge m der Sequenz begrenzt
                        ist
              \end{itemize}
        \item
              Definition: Ein PRBG besteht den Next-Bit-Test, wenn es keinen
              deterministischen Polynomialzeit-Algorithmus gibt, der bei Eingabe der
              ersten m Bits einer Ausgangssequenz \$s\$ das \$(m+1)\$-te Bit
              \$s\_\{m+1\}\$ der Ausgangssequenz mit einer Wahrscheinlichkeit
              deutlich größer als 0 vorhersagen kann.
        \item
              Theorem (Universalität des Next-Bit-Tests): Wenn eine PRBG den
              Next-Bit-Test \$\textbackslash Leftrightarrow\$ besteht, dann besteht
              sie alle statistischen Polynomialzeittests
        \item
              Definition: Ein PRBG, der den Next-Bit-Test besteht - möglicherweise
              unter einer plausiblen, aber unbewiesenen mathematischen Annahme wie
              der Unlösbarkeit des Faktorisierungsproblems für große ganze Zahlen -
              wird als kryptographisch sicherer Pseudo-Zufallsgenerator (CSPRBG)
              bezeichnet
    \end{itemize}


    \subsection{Zufallszahlengenerierung}

    \begin{itemize}
        \item
              Hardware-basierte Zufallsbit-Generatoren basieren auf physikalischen
              Phänomenen, wie:

              \begin{itemize}
                  \item
                        die verstrichene Zeit zwischen der Emission von Teilchen beim
                        radioaktiven Zerfall,
                  \item
                        thermisches Rauschen einer Halbleiterdiode oder eines Widerstandes,
                  \item
                        Frequenzinstabilität eines frei laufenden Oszillators,
                  \item
                        der Betrag, um den ein Metall-Isolator-Halbleiter-Kondensator
                        während eines bestimmten Zeitraums aufgeladen wird,
                  \item
                        Luftturbulenzen in einem versiegelten Festplattenlaufwerk, die
                        zufällige Schwankungen in den Sektor-Lese-Latenzen des
                        Festplattenlaufwerks verursachen, und
                  \item
                        Ton von einem Mikrofon oder Videoeingang von einer Kamera
                  \item
                        der Zustand einer ungeraden Anzahl von kreisförmig verbundenen
                        NOT-Gattern
              \end{itemize}
        \item
              Ein hardwarebasierter Zufallsbitgenerator sollte idealerweise in einer
              manipulationssicheren Vorrichtung untergebracht und so vor möglichen
              Angreifern geschützt sein.
        \item
              Softwarebasierte Zufallsbit-Generatoren können auf Prozessen basieren
              wie

              \begin{itemize}
                  \item
                        der Systemuhr,
                  \item
                        der verstrichenen Zeit zwischen Tastenanschlägen oder
                        Mausbewegungen,
                  \item
                        Inhalt von Eingabe-/Ausgabepuffern
                  \item
                        Benutzereingaben und
                  \item
                        Werte des Betriebssystems wie Systemauslastung und
                        Netzwerkstatistiken
              \end{itemize}
        \item
              Idealerweise sollten mehrere Zufallsquellen ,,gemischt'' werden, z. B.
              durch Verkettung ihrer Werte und Berechnung eines kryptografischen
              Hashwerts für den kombinierten Wert, um zu verhindern, dass ein
              Angreifer den Zufallswert erraten kann

              \begin{itemize}
                  \item
                        Wird z. B. nur die Systemuhr als Zufallsquelle verwendet, könnte ein
                        Angreifer die aus dieser Zufallsquelle gewonnenen Zufallszahlen
                        erraten, wenn er weiß, wann sie erzeugt wurden.
              \end{itemize}
        \item
              Verzerrung:

              \begin{itemize}
                  \item
                        Betrachten wir einen Zufallsgenerator, der verzerrte, aber
                        unkorrelierte Bits erzeugt, z. B. 1en mit der Wahrscheinlichkeit
                        \$p\textbackslash not= 0,5\$ und 0en mit der Wahrscheinlichkeit
                        \$1-p\$, wobei p unbekannt, aber fest ist
              \end{itemize}
        \item
              Die folgende Technik kann verwendet werden, um eine Zufallsfolge zu
              erhalten, die unkorreliert und unverzerrt ist:

              \begin{itemize}
                  \item
                        Die Ausgangssequenz des Generators wird in Bitpaare gruppiert
                  \item
                        Alle Paare 00 und 11 werden verworfen.
                  \item
                        Für jedes Paar 10 erzeugt der unvoreingenommene Generator eine 1 und
                        für jedes Paar 01 eine 0.
              \end{itemize}
        \item
              Ein weiteres praktisches (wenn auch nicht beweisbares) Verfahren zur
              Entzerrung ist die Weiterleitung von Sequenzen, deren Bits korreliert
              oder verzerrt sind, durch eine kryptografische Hash-Funktion wie MD5
              oder SHA-1
    \end{itemize}


    \subsection{Statistische Tests für
        Zufallszahlen}

    \begin{itemize}
        \item
              Mit den folgenden Tests lässt sich überprüfen, ob eine generierte
              Zufalls- oder Pseudozufallsfolge bestimmte statistische Eigenschaften
              nicht erfüllt:

              \begin{itemize}
                  \item
                        Monobit-Test: Gibt es gleich viele 1en wie 0en?
                  \item
                        Serieller Test (Zwei-Bit-Test): Gibt es gleich viele 00-, 01-, 10-,
                        11-Paare?
                  \item
                        Poker-Test: Gibt es gleich viele Sequenzen ni der Länge q, die mit
                        \$q\$ den gleichen Wert haben, so dass \$\textbackslash lfloor
                        m/q\textbackslash rfloor\textbackslash geq 5\textbackslash times
                        (2\^{}q)\$
                  \item
                        Test auf Durchläufe: Entspricht die Anzahl der Läufe (Sequenzen, die
                        nur entweder 0 oder 1 enthalten) unterschiedlicher Länge den
                        Erwartungen für Zufallszahlen?
                  \item
                        Autokorrelationstest: Gibt es Korrelationen zwischen der Sequenz und
                        (nicht-zyklischen) verschobenen Versionen davon?
                  \item
                        Maurer's Universal Test: Kann die Sequenz komprimiert werden?
                  \item
                        NIST SP 800-22: Standardisierte Testsuite, umfasst die oben
                        genannten und weitere fortgeschrittene Tests
              \end{itemize}
    \end{itemize}


    \subsection{Sichere
        Pseudo-Zufallszahlengenerierung}

    \begin{itemize}
        \item
              Es gibt eine Reihe von Algorithmen, die kryptografische
              Hash-Funktionen oder Verschlüsselungsalgorithmen zur Erzeugung von
              kryptografisch sicheren Pseudozufallszahlen verwenden.

              \begin{itemize}
                  \item
                        Obwohl diese Verfahren nicht als sicher bewiesen werden können,
                        scheinen sie für die meisten praktischen Situationen ausreichend
              \end{itemize}
        \item
              Ein solcher Ansatz ist der Generator ANSI X9.17:

              \begin{itemize}
                  \item
                        Eingabe: ein zufälliger und geheimer 64-Bit-Seed s, eine ganze Zahl
                        m und ein 3-DES-Schlüssel K
                  \item
                        Ausgabe: m pseudo-zufällige 64-Bit-Strings \$y\_1,y\_2,...Y\_m\$

                        \begin{enumerate}
                            \def\labelenumi{\arabic{enumi}.}
                            \item
                                  \$q = E(K, Date\_Time)\$
                            \item
                                  For i von 1 bis m do

                                  \begin{enumerate}
                                      \def\labelenumii{\arabic{enumii}.}
                                      \item
                                            \$x\_i = E(K, (q\textbackslash oplus s)\$
                                      \item
                                            \$s = E(K, (x\_i\textbackslash oplus q)\$
                                  \end{enumerate}
                            \item
                                  \$Return(x\_1,x\_2,...x\_m)\$
                        \end{enumerate}
                  \item
                        Diese Methode ist eine vom U.S. Federal Information Processing
                        Standard (FIPS) zugelassene Methode zur pseudozufälligen Erzeugung
                        von Schlüsseln und Initialisierungsvektoren zur Verwendung mit DES
              \end{itemize}
        \item
              Das RSA-PRBG ist ein CSPRBG unter der Annahme, dass das RSA-Problem
              unlösbar ist:

              \begin{itemize}
                  \item
                        Ausgabe: eine pseudo-zufällige Bitfolge \$z\_1,z\_2,...,z\_k\$ der
                        Länge k
              \end{itemize}

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        Setup-Prozedur: Erzeuge zwei geheime Primzahlen \$p, q\$, die für
                        die Verwendung mit RSA geeignet sind. Berechne
                        \$n=p\textbackslash times q\$ und
                        \$\textbackslash phi=(p-1)\textbackslash times(q-1)\$. Wähle eine
                        zufällige ganze Zahl e so, dass
                        \$1\textless e\textless\textbackslash phi\$ und
                        \$gcd(e,\textbackslash phi)=1\$
                  \item
                        Wähle eine zufällige ganze Zahl \$y\_0\$ (den Keim) so, dass
                        \$y\_0\textbackslash in {[}1,n{]}\$
                  \item
                        Für i von 1 bis k tun

                        \begin{enumerate}
                            \def\labelenumii{\arabic{enumii}.}
                            \item
                                  \$y\_i=(y\_\{i-1\})\^{}e\textbackslash{} mod\textbackslash{} n\$
                            \item
                                  \$z\_i =\$ das niedrigstwertige Bit von \$y\_i\$
                        \end{enumerate}
              \end{enumerate}

              \begin{itemize}
                  \item
                        Die Effizienz des Generators kann leicht verbessert werden, indem
                        man die letzten j Bits von jedem \$y\_i\$ nimmt, wobei
                        \$j=c\textbackslash times lg(lg(n))\$ und c eine Konstante ist
                  \item
                        Für eine gegebene Bitlänge m von n wurde jedoch noch kein
                        Wertebereich für die Konstante c ermittelt, in dem der Algorithmus
                        noch einen CSPRBG ergibt
              \end{itemize}
        \item
              Der Blum-Blum-Shub-PRBG ist ein CSPRBG unter der Annahme, dass das
              Problem der ganzzahligen Faktorisierung unlösbar ist:

              \begin{itemize}
                  \item
                        Ausgabe: eine pseudo-zufällige Bitfolge \$z\_1,z\_2,...,z\_k\$ der
                        Länge k
              \end{itemize}

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        Setup-Prozedur: Erzeuge zwei große geheime und unterschiedliche
                        Primzahlen \$p,q\$, so dass \$p,q\$ jeweils kongruent 3 modulo 4
                        sind, und lass \$n=p\textbackslash times q\$
                  \item
                        Wähle eine zufällige ganze Zahl s (den Keim) so, dass
                        \$s\textbackslash in {[}1, n-1{]}\$ liegt, so dass \$gcd(s,n)=1\$
                        und \$y\_0=s\^{}2\textbackslash{} mod\textbackslash{} n\$
                  \item
                        Für i von 1 bis k tun

                        \begin{enumerate}
                            \def\labelenumii{\arabic{enumii}.}
                            \item
                                  \$y\_i = (y\_\{i-1\})\^{}2\textbackslash{} mod\textbackslash{} n\$
                            \item
                                  \$z\_i =\$ das niedrigstwertige Bit von \$y\_i\$
                        \end{enumerate}
              \end{enumerate}

              \begin{itemize}
                  \item
                        Die Effizienz des Generators kann mit der gleichen Methode wie beim
                        RSA-Generator verbessert werden, wobei ähnliche Einschränkungen für
                        die Konstante c gelten
              \end{itemize}
        \item
              Dualer deterministischer Zufallsbitgenerator mit elliptischer Kurve:

              \begin{itemize}
                  \item
                        Basierend auf der Unlösbarkeit des Problems des diskreten
                        Logarithmus elliptischer Kurven
                  \item
                        Vereinfachte Version:
                        % \includegraphics{Assets/NetworkSecurity-dual-elliptic-curve-deterministic-random-bit-generator.png}
                  \item
                        Der Zustand t wird mit einem Generator P multipliziert, der x-Wert
                        des neuen Punktes wird zu t'
                  \item
                        Multiplikation mit einem anderen Punkt Q r Bits der Ausgabe können
                        erzeugt werden, die Anzahl der Bits hängt von der Kurve ab (zwischen
                        240 und 504 Bits)
                  \item
                        Teil der Norm NIST 800-90A
                  \item
                        Sicherheit:

                        \begin{itemize}
                            \item
                                  Es wurde gezeigt, dass Angreifer den Zustand t ableiten können,
                                  wenn P für eine Konstante e gleich eQ gewählt wird.
                            \item
                                  Wir wissen nicht, wie die vordefinierten Punkte P und Q in NIST
                                  800-90A abgeleitet werden, also Vorsicht
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{CSPRNG-Sicherheit ist eine große
        Sache!}

    \begin{itemize}
        \item
              Im September 2006 wurde Debian versehentlich so verändert, dass nur
              die Prozess-ID verwendet wurde, um den OpenSSL CSPRNG zu füttern

              \begin{itemize}
                  \item
                        Nur 32.768 mögliche Werte!
                  \item
                        Wurde bis Mai 2008 nicht entdeckt
              \end{itemize}
        \item
              Ein Scan von etwa 23 Millionen TLS- und SSH-Hosts zeigte, dass

              \begin{itemize}
                  \item
                        Mindestens 0,34\% der Hosts teilten Schlüssel aufgrund fehlerhafter
                        RNGs
                  \item
                        0,50\% der gescannten TLS-Schlüssel aufgrund einer geringen
                        Zufälligkeit kompromittiert werden konnten
                  \item
                        und 1,06\% der SSH-Hosts...
              \end{itemize}
        \item
              Überwachen Sie Ihren CSPRNG!

              \begin{itemize}
                  \item
                        Generieren Sie keine Zufallszahlen direkt nach dem Booten Ihres
                        Systems
                  \item
                        Verwenden Sie blockierende RNGs, d.h. solche, die nicht fortfahren,
                        bis sie genügend Entropie haben
              \end{itemize}
    \end{itemize}


    \section{Kryptographische
      Protokolle}

    \begin{itemize}
        \item
              Definition: Ein kryptographisches Protokoll ist definiert als eine
              Reihe von Schritten und der Austausch von Nachrichten zwischen
              mehreren Einheiten, um ein bestimmtes Sicherheitsziel zu erreichen.
        \item
              Eigenschaften eines Protokolls (im Allgemeinen):

              \begin{itemize}
                  \item
                        Jeder, der an dem Protokoll beteiligt ist, muss das Protokoll und
                        alle zu befolgenden Schritte im Voraus kennen
                  \item
                        Jeder, der an dem Protokoll beteiligt ist, muss zustimmen, es zu
                        befolgen.
                  \item
                        Das Protokoll muss eindeutig sein, d.h. jeder Schritt ist genau
                        definiert, und es gibt keine Möglichkeit für Missverständnisse
                  \item
                        Das Protokoll muss vollständig sein, d. h. es gibt für jede mögliche
                        Situation eine bestimmte Aktion.
              \end{itemize}
        \item
              Zusätzliche Eigenschaft eines kryptographischen Protokolls:

              \begin{itemize}
                  \item
                        Es sollte nicht möglich sein, mehr zu tun oder zu erfahren als das,
                        was im Protokoll angegeben ist.
              \end{itemize}
    \end{itemize}


    \subsection{Anwendungen von kryptographischen
        Protokollen}

    \begin{itemize}
        \item
              Schlüsselaustausch
        \item
              Authentifizierung

              \begin{itemize}
                  \item
                        Authentifizierung der Datenherkunft
                  \item
                        Authentifizierung von Entitäten
              \end{itemize}
        \item
              Kombinierte Authentifizierung und Schlüsselaustausch
        \item
              Aufteilung des Geheimnisses (alle Teile werden für die Rekonstruktion
              benötigt)
        \item
              Gemeinsame Nutzung des Geheimnisses (m von n Teilen werden für die
              Rekonstruktion benötigt)
        \item
              Zeitstempelung
        \item
              Schlüsselhinterlegung (Sicherstellung, dass nur eine befugte Stelle
              Schlüssel wiederherstellen kann)
        \item
              Zero-Knowledge-Beweise (Nachweis der Kenntnis einer Information ohne
              Offenlegung der Information)
        \item
              Blindsignaturen (nützlich für die Wahrung der Privatsphäre bei
              Zeitstempeldiensten)
        \item
              Sichere Wahlen
        \item
              Elektronisches Geld
    \end{itemize}


    \subsection{Schlüsselaustausch}

    \begin{itemize}
        \item
              Das vorgestellte Diffie-Hellman-Protokoll ist unser erstes Beispiel
              für ein kryptographisches Protokoll zum Schlüsselaustausch
        \item
              Bitte beachten Sie, dass es keine Authentifizierung realisiert:

              \begin{itemize}
                  \item
                        Weder Alice noch Bob wissen nach einem Protokolldurchlauf, mit wem
                        sie einen Schlüssel ausgetauscht haben
                  \item
                        Da dieser reine Schlüsselaustausch ohne Authentifizierung nicht
                        einmal die Vertraulichkeit der Kommunikation nach dem Austausch
                        garantieren kann, muss er mit Authentifizierung kombiniert werden
              \end{itemize}
        \item
              Diese Trennung von Schlüsselaustausch und Authentifizierung des
              Austauschs hat jedoch einen großen Vorteil, da sie es ermöglicht, die
              Eigenschaft des perfekten Vorwärtsgeheimnisses (Perfect Forward
              Secrecy, PFS) zu gewährleisten:

              \begin{itemize}
                  \item
                        Wenn ein Schlüsselaustausch PFS gewährleistet, kann die
                        Kompromittierung eines Schlüssels in der Zukunft keine Daten
                        kompromittieren, die mit anderen Schlüsseln geschützt wurden, die
                        vor dieser Kompromittierung ausgetauscht wurden.
                  \item
                        Beispiel: Stellen Sie sich vor, Alice und Bob signieren beide die
                        zur Berechnung von sk ausgetauschten Daten mit ihren privaten
                        Schlüsseln. Selbst die Kompromittierung eines privaten Schlüssels in
                        der Zukunft wird es nicht ermöglichen, aufgezeichnete Daten zu
                        entschlüsseln, die mit sk geschützt wurden.
              \end{itemize}
    \end{itemize}


    \subsection{Authentifizierung der
        Datenherkunft}

    Definition: Die Datenursprungsauthentifizierung ist der
    Sicherheitsdienst, der es Entitäten ermöglicht, zu überprüfen, ob eine
    Nachricht von einer bestimmten Entität stammt und nicht nachträglich
    verändert wurde. Ein Synonym für diesen Dienst ist Datenintegrität.

    \begin{itemize}
        \item
              Die Beziehung zwischen Datenintegrität und kryptografischen
              Protokollen ist zweifach:

              \begin{itemize}
                  \item
                        Es gibt kryptografische Protokolle zur Sicherstellung der
                        Datenintegrität. Sie umfassen in der Regel nur einen
                        Protokollschritt und sind daher nicht sehr ,,spannend'':

                        \begin{itemize}
                            \item
                                  Beispiel 1: Angenommen, jeder kennt den öffentlichen RSA-Schlüssel
                                  von Alice und kann sicher sein, dass er den Schlüssel von Alice
                                  wirklich kennt, dann kann Alice die Datenintegrität ihrer
                                  Nachrichten sicherstellen, indem sie sie mit ihrem privaten
                                  Schlüssel verschlüsselt.
                            \item
                                  Beispiel 2: Alice kann auch einen MDC über ihre Nachricht
                                  berechnen und den mit ihrem privaten Schlüssel verschlüsselten MDC
                                  an die Nachricht anhängen
                        \end{itemize}
                  \item
                        Die Datenintegrität der ausgetauschten Nachrichten ist oft eine
                        wichtige Eigenschaft in kryptografischen Protokollen, daher ist die
                        Datenintegrität ein Baustein für kryptografische Protokolle
              \end{itemize}
    \end{itemize}


    \subsection{Authentifizierung von
        Entitäten}

    Definition: Entitätsauthentifizierung ist der Sicherheitsdienst, der es
    Kommunikationspartnern ermöglicht, die Identität ihrer Peer-Entitäten zu
    überprüfen.

    \begin{itemize}
        \item
              Die Entitätsauthentifizierung ist der grundlegendste
              Sicherheitsdienst, da alle anderen Sicherheitsdienste auf ihr
              aufbauen.
        \item
              Im Allgemeinen kann sie durch verschiedene Mittel erreicht werden:

              \begin{itemize}
                  \item
                        Wissen: z. B. Passwörter
                  \item
                        Besitz: z. B. physische Schlüssel oder Karten
                  \item
                        Unveränderliches Merkmal: z. B. biometrische Eigenschaften wie
                        Fingerabdruck usw.
                  \item
                        Ort: Es wird der Nachweis erbracht, dass sich eine Entität an einem
                        bestimmten Ort befindet (Beispiel: Menschen überprüfen selten die
                        Authentizität von Agenten in einer Bank)
                  \item
                        Delegation der Authentizität: Die überprüfende Stelle akzeptiert,
                        dass eine vertrauenswürdige Person die Authentifizierung bereits
                        vorgenommen hat.
              \end{itemize}
        \item
              In Kommunikationsnetzen ist die direkte Überprüfung der oben genannten
              Mittel schwierig oder unsicher, weshalb kryptographische Protokolle
              erforderlich sind.
        \item
              Der Hauptgrund, warum die Authentifizierung von Entitäten mehr ist als
              ein Austausch von (datenherkunfts-) authentischen Nachrichten, ist die
              Aktualität:

              \begin{itemize}
                  \item
                        Selbst wenn Bob während einer Kommunikation authentische Nachrichten
                        von Alice erhält, kann er nicht sicher sein, ob:

                        \begin{itemize}
                            \item
                                  Alice zu diesem Zeitpunkt tatsächlich an der Kommunikation
                                  teilnimmt, oder ob
                            \item
                                  Eve alte Nachrichten von Alice abspielt
                        \end{itemize}
                  \item
                        Dies ist von besonderer Bedeutung, wenn die Authentifizierung nur
                        zum Zeitpunkt des Verbindungsaufbaus erfolgt:

                        \begin{itemize}
                            \item
                                  Beispiel: Übermittlung einer (möglicherweise verschlüsselten) PIN
                                  beim Einloggen
                        \end{itemize}
                  \item
                        Zwei grundsätzliche Mittel zur Sicherstellung der Aktualität in
                        kryptographischen Protokollen:

                        \begin{itemize}
                            \item
                                  Zeitstempel (erfordern mehr oder weniger synchronisierte Uhren)
                            \item
                                  Zufallszahlen (Challenge-Response-Austausch)
                        \end{itemize}
              \end{itemize}
        \item
              Die meisten Authentifizierungsprotokolle erstellen auch einen geheimen
              Sitzungsschlüssel zur Sicherung der Sitzung nach dem
              Authentifizierungsaustausch
        \item
              Zwei Hauptkategorien von Protokollen für die Authentifizierung von
              Entitäten:

              \begin{itemize}
                  \item
                        Arbitrierte Authentifizierung: ein Arbiter, auch vertrauenswürdige
                        dritte Partei (TTP) genannt, ist direkt an jedem
                        Authentifizierungsaustausch beteiligt

                        \begin{itemize}
                            \item
                                  Vorteile:

                                  \begin{itemize}
                                      \item
                                            Dies ermöglicht es zwei Parteien A und B, sich gegenseitig zu
                                            authentifizieren, ohne ein vorher festgelegtes Geheimnis zu
                                            kennen.
                                      \item
                                            Selbst wenn sich A und B nicht kennen, kann die symmetrische
                                            Kryptographie verwendet werden.
                                  \end{itemize}
                            \item
                                  Nachteilig:

                                  \begin{itemize}
                                      \item
                                            Das TTP kann zu einem Engpass werden, die Verfügbarkeit des TTP
                                            ist entscheidend
                                      \item
                                            Der TTP kann alle Authentifizierungsaktivitäten überwachen.
                                  \end{itemize}
                        \end{itemize}
                  \item
                        Direkte Authentifizierung: A und B authentifizieren sich direkt
                        gegenseitig

                        \begin{itemize}
                            \item
                                  Vorteile: keine Online-Teilnahme einer dritten Partei erforderlich
                                  und kein möglicher Leistungsengpass wird eingeführt
                            \item
                                  Nachteile: erfordert asymmetrische Kryptographie oder im Voraus
                                  festgelegte geheime Schlüssel
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Notation kryptographischer
        Protokolle}

    %\begin{longtable}[]{@{}ll@{}}
    %    \toprule
    %    Notation                           & Bedeutung\tabularnewline
    %    \midrule
    %    \endhead
    %    \$A\$                              & Name von A , analog für B, E, TTP, CA\tabularnewline
    %    \$CA\_A\$                          & Zertifizierungsstelle von A\tabularnewline
    %    \$r\_A\$                           & Zufallswert, gewählt von A\tabularnewline
    %    \$t\_A\$                           & Zeitstempel erzeugt von A\tabularnewline
    %    \$(m\_1,...,m\_m)\$                & Verkettung von Nachrichten \$m\_1,
    %    ...,m\_n\$\tabularnewline
    %    \$A\textbackslash rightarrow B:m\$ & A sendet Nachricht m an
    %    B\tabularnewline
    %    \$K\_\{A,B\}\$                     & Geheimer Schlüssel, nur A und B bekannt\tabularnewline
    %    \$+K\_A\$                          & Öffentlicher Schlüssel von A\tabularnewline
    %    \$-K\_A\$                          & Privater Schlüssel von A\tabularnewline
    %    \$\{m\}\_K\$                       & Nachricht m verschlüsselt mit Schlüssel K , Synonym für
    %    \$E(K, m)\$\tabularnewline
    %    \$H(m)\$                           & MDC über Nachricht m, berechnet mit Funktion H\tabularnewline
    %    \$A{[}m{]}\$                       & Kurzschreibweise für
    %    \$(m,\{H(m)\}\_\{-K\_A\})\$\tabularnewline
    %    \$Cert\_\{-CK\_\{CA\}\}(+K\_A)\$   & Zertifikat der CA für den
    %    öffentlichen Schlüssel \$+K\_A\$ von A, signiert mit dem privaten
    %    Zertifizierungsschlüssel \$-CK\_\{CA\}\$\tabularnewline
    %    \$CA\textless{}\textgreater\$      & Kurzschreibweise für
    %    \$Cert\_\{-CK\_\{CA\}\}(+K\_A)\$\tabularnewline
    %    \bottomrule
    %\end{longtable}


    \subsection{Das
        Needham-Schroeder-Protokoll}

    \begin{itemize}
        \item
              Erfunden im Jahr 1978 von Roger Needham und Michael Schroeder
              {[}Nee78a{]}
        \item
              Das Protokoll basiert auf symmetrischer Verschlüsselung und nutzt eine
              vertrauenswürdige dritte Partei (TTP)
        \item
              Angenommen, TTP teilt die geheimen Schlüssel KA,TTP und KB,TTP mit
              Alice bzw. Bob:

              \begin{itemize}
                  \item
                        A erzeugt eine Zufallszahl rA und sendet die folgende Nachricht:

                        \begin{enumerate}
                            \def\labelenumi{\arabic{enumi}.}
                            \item
                                  \$A\textbackslash rightarrow TTP: (A, B, r\_A)\$
                        \end{enumerate}
                  \item
                        TTP erzeugt einen Sitzungsschlüssel KA,B für die sichere
                        Kommunikation zwischen A und B und antwortet A: 2.
                        \$TTP\textbackslash rightarrow A:\{r\_A, B, K\_\{A,B\},
                        \{K\_\{A,B\}, A\}\emph{\{K}\{B,TTP\}\}\}\emph{\{K}\{A,TTP\}\}\$
                  \item
                        A entschlüsselt die Nachricht und extrahiert \$K\_\{A,B\}\$. Sie
                        bestätigt, dass \$r\_A\$ mit der von ihr im ersten Schritt
                        generierten Zahl identisch ist, so dass sie weiß, dass die Antwort
                        eine neue Antwort von TTP ist. Dann sendet sie an B: 3.)
                        \$A\textbackslash rightarrow B:\{K\_\{A,B\},
                        A\}\emph{\{K}\{B,TTP\}\}\$
                  \item
                        Bob entschlüsselt die Nachricht und erhält \$K\_\{A,B\}\$. Er
                        erzeugt dann eine Zufallszahl \$r\_B\$ und antwortet Alice: 4.)
                        \$B\textbackslash rightarrow A:\{r\_B\}\emph{\{K}\{A,B\}\}\$
                  \item
                        Alice entschlüsselt die Nachricht, errechnet \$r\_\{B\}-1\$ und
                        antwortet mit: 5.) \$A\textbackslash rightarrow
                        B:\{r\_B-1\}\emph{\{K}\{A,B\}\}\$
                  \item
                        Bob entschlüsselt die Nachricht und prüft, ob sie \$r\_B-1\$
                        enthält.
              \end{itemize}
        \item
              Diskussion:

              \begin{itemize}
                  \item
                        Der Austausch von \$r\_B\$ und \$r\_\{B-1\}\$ soll sicherstellen,
                        dass ein Angreifer, der versucht, sich als Alice auszugeben, keinen
                        vollständigen Protokolldurchlauf mit nachgespielten Nachrichten
                        durchführen kann
                  \item
                        Da jedoch alte Sitzungsschlüssel \$K\_\{A,B\}\$ gültig bleiben, kann
                        ein Angreifer, Eve, der es schafft, einen Sitzungsschlüssel
                        \$K\_\{A,B\}\$ in Erfahrung zu bringen, diesen später dazu
                        verwenden, sich als Alice auszugeben:

                        \begin{enumerate}
                            \def\labelenumi{\arabic{enumi}.}
                            \item
                                  \$E\textbackslash rightarrow B:\{K\_\{A,B\},
                                  A\}\emph{\{K}\{B,TTP\}\}\$
                            \item
                                  \$B\textbackslash rightarrow A:\{r\_B\}\emph{\{K}\{A,B\}\}\$ Eve
                                  muss diese Nachricht abfangen
                            \item
                                  \$E\textbackslash rightarrow B:\{r\_B -1\}\emph{\{K}\{A,B\}\}\$
                        \end{enumerate}

                        \begin{itemize}
                            \item
                                  Eve gibt sich also als Alice aus, obwohl sie weder
                                  \$K\_\{A,TTP\}\$ noch \$K\_\{B,TTP\}\$ kennt!
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Das Otway-Rees-Protokoll}

    \begin{itemize}
        \item
              Das oben beschriebene Sicherheitsproblem sowie einige andere wurden
              von Needham und Schroeder behandelt. Ihre Lösung {[}Nee87a{]} ist im
              Wesentlichen die gleiche wie die von Otway und Rees in der gleichen
              Zeitschrift {[}Otw87a{]} vorgeschlagene:

              \begin{itemize}
                  \item
                        Alice generiert eine Nachricht, die eine Indexzahl \$i\_A\$, ihren
                        Namen A, Bobs Namen B und die gleichen Informationen plus eine
                        zusätzliche Zufallszahl \$r\_A\$ enthält, die mit dem Schlüssel
                        \$K\_\{A,TTP\}\$ verschlüsselt ist, den sie mit TTP teilt, und
                        sendet diese Nachricht an Bob:

                        \begin{enumerate}
                            \def\labelenumi{\arabic{enumi}.}
                            \item
                                  \$A\textbackslash rightarrow B:(i\_A, A, B,\{r\_A, i\_A, A,
                                  B\}\emph{\{K}\{A,TTP\}\})\$
                        \end{enumerate}
                  \item
                        Bob erzeugt eine Zufallszahl \$r\_B\$, verschlüsselt sie zusammen
                        mit \$i\_A\$, A und B mit dem Schlüssel \$K\_\{B,TTP\}\$, den er mit
                        TTP teilt, und sendet die Nachricht an TTP: 2.
                        \$B\textbackslash rightarrow TTP:(i\_A, A,
                        B,\{r\_A,i\_A,A,B\}\emph{\{K}\{A,TTP\}\},\{r\_B,i\_A,A,B\}\emph{\{K}\{B,TTP\}\})\$
                  \item
                        TTP erzeugt einen neuen Sitzungsschlüssel KA,B und erstellt zwei
                        verschlüsselte Nachrichten, eine für Alice und eine für Bob, und
                        sendet sie an Bob: 3. \$TTP\textbackslash rightarrow
                        B:(i\_A,\{r\_A,K\_\{A,B\}\}\emph{\{K}\{A,TTP\}\},\{r\_B,
                        K\_\{A,B\}\}\emph{\{K}\{B,TTP\}\})\$
                  \item
                        Bob entschlüsselt seinen Teil der Nachricht, verifiziert rB und
                        sendet Alices Teil der Nachricht an sie: 4.
                        \$B\textbackslash rightarrow
                        A:(i\_A,\{r\_A,K\_\{A,B\}\}\emph{\{K}\{A,TTP\}\})\$
                  \item
                        Alice entschlüsselt die Nachricht und überprüft, ob sich \$i\_A\$
                        und \$r\_A\$ während des Austauschs nicht geändert haben. Wenn
                        nicht, kann sie sicher sein, dass TTP ihr einen neuen
                        Sitzungsschlüssel \$K\_\{A,B\}\$ für die Kommunikation mit Bob
                        geschickt hat. Wenn sie nun diesen Schlüssel in einer
                        verschlüsselten Kommunikation mit Bob verwendet, kann sie sich
                        seiner Authentizität sicher sein.
              \end{itemize}
        \item
              Diskussion:

              \begin{itemize}
                  \item
                        Die Indexzahl \$i\_A\$ schützt vor Replay-Attacken. Dies erfordert
                        jedoch, dass TTP überprüft, ob \$i\_A\$ größer ist als das letzte
                        \$i\_A\$, das er von Alice erhalten hat.
                  \item
                        Da TTP nur dann zwei Nachrichten generiert, wenn beide Teile der
                        Nachricht, die er erhält, die gleiche Indexnummer \$i\_A\$ und die
                        Namen \$A, B,\$ enthalten, können Alice und Bob sicher sein, dass
                        sie sich beide während des Protokolllaufs gegenüber TTP
                        authentifiziert haben.
              \end{itemize}
    \end{itemize}


    \subsection{Kerberos}

    \begin{itemize}
        \item
              Kerberos ist ein Authentifizierungs- und Zugangskontrolldienst für
              Workstation-Cluster, der in den späten 1980er Jahren am MIT entwickelt
              wurde.
        \item
              Entwurfsziele:

              \begin{itemize}
                  \item
                        Sicherheit: Abhörer oder aktive Angreifer sollten nicht in der Lage
                        sein, die notwendigen Informationen zu erhalten, um sich beim
                        Zugriff auf einen Dienst als ein Benutzer auszugeben
                  \item
                        Zuverlässigkeit: Da jede Nutzung eines Dienstes eine vorherige
                        Authentifizierung erfordert, sollte Kerberos höchst zuverlässig und
                        verfügbar sein.
                  \item
                        Transparenz: Der Authentifizierungsprozess sollte für den Benutzer
                        transparent sein und nicht nur die Eingabe eines Passworts
                        erfordern.
                  \item
                        Skalierbarkeit: Das System sollte in der Lage sein, eine große
                        Anzahl von Clients und Servern zu unterstützen.
              \end{itemize}
        \item
              Das Kerberos zugrunde liegende kryptografische Verfahren ist die
              symmetrische Verschlüsselung (Kerberos V. 4 verwendet DES, V. 5
              erlaubt andere Algorithmen).
        \item
              Eine gute Anleitung zu den Überlegungen hinter dem Kerberos-Design
              findet sich in {[}Bry88a{]}, wo das Protokoll in einer Reihe von
              fiktiven Dialogen entwickelt wird
        \item
              Das grundlegende Anwendungsszenario von Kerberos ist ein Benutzer,
              Alice, der auf einen oder mehrere verschiedene Dienste zugreifen
              möchte, die von verschiedenen Servern \$S\_1, S\_2, ...\$
              bereitgestellt werden, die über ein unsicheres Netzwerk verbunden sind
        \item
              Kerberos befasst sich mit den folgenden Sicherheitsaspekten in diesem
              Szenario:

              \begin{itemize}
                  \item
                        Authentifizierung: Alice authentifiziert sich bei einem
                        Authentifizierungsserver (AS), der eine zeitlich begrenzte
                        Genehmigung für den Zugang zu Diensten erteilt. Diese Erlaubnis wird
                        Ticket-granting ticket (TicketTGS) genannt und ist vergleichbar mit
                        einem zeitlich begrenzten Reisepass.
                  \item
                        Zugangskontrolle: Durch Vorlage ihres TicketTGS kann Alice einen
                        Ticket-gewährenden Server (TGS) anfordern, um Zugang zu einem Dienst
                        zu erhalten, der von einem bestimmten Server S1 bereitgestellt wird.
                        Der TGS entscheidet, ob der Zugang erlaubt wird und antwortet mit
                        einem TicketS1 für den Server S.
                  \item
                        Schlüsselaustausch: Der Authentifizierungsserver stellt einen
                        Sitzungsschlüssel für die Kommunikation zwischen Alice und TGS
                        bereit, und der TGS stellt einen Sitzungsschlüssel für die
                        Kommunikation zwischen Alice und S1 bereit. Die Verwendung dieser
                        Sitzungsschlüssel dient auch der Authentifizierung.
              \end{itemize}
    \end{itemize}

    Zugriff auf einen Dienst mit Kerberos - Protokollübersicht

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-Kerberos.png}
        \item
              Der Benutzer meldet sich an seiner Arbeitsstation an und fordert den
              Zugriff auf einen Dienst an:

              \begin{itemize}
                  \item
                        Die Workstation repräsentiert ihn im Kerberos-Protokoll und sendet
                        die erste Nachricht an den Authentifizierungsserver AS, die seinen
                        Namen, den Namen eines geeigneten Ticket-Granting-Servers TGS und
                        einen Zeitstempel \$t\_A\$ enthält:
              \end{itemize}

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$A\textbackslash rightarrow AS:(A, TGS, t\_A)\$
              \end{enumerate}
        \item
              Der AS prüft, ob A sich für den Zugang zu den Diensten
              authentifizieren darf, generiert aus A's Passwort (das ihm bekannt
              ist) den Schlüssel KA, extrahiert die Arbeitsplatzadresse \$Addr\_A\$
              der Anfrage, erstellt ein Ticket \$Ticket\_\{TGS\}\$ und einen
              Sitzungsschlüssel \$K\_\{A,TGS\}\$ und sendet die folgende Nachricht
              an A: 2. \$AS\textbackslash rightarrow A:\{K\_\{A,TGS\}, TGS,
              t\_\{AS\}, LifetimeTicket\_\{TGS\}, Ticket\_\{TGS\}\}\emph{\{K\_A\}\$
                  mit \$Ticket}\{TGS\}=\{K\_\{A,TGS\},A, Addr\_A, TGS, t\_\{AS\},
              LifetimeTicket\_\{TGS\}\}\emph{\{K}\{AS,TGS\}\}\$
        \item
              Nach Erhalt dieser Nachricht fordert die Workstation Alice auf, ihr
              Passwort einzugeben, berechnet daraus den Schlüssel \$K\_A\$ und
              entschlüsselt die Nachricht mit diesem Schlüssel. Wenn Alice nicht ihr
              ,,authentisches'' Passwort angibt, sind die extrahierten Werte
              ,,Müll'' und der Rest des Protokolls schlägt fehl.
        \item
              Alice erstellt einen sogenannten Authenticator und sendet ihn zusammen
              mit dem Ticket und dem Namen des Servers \$S1\$ an TGS: 3.
              \$A\textbackslash rightarrow TGS:(S1, Ticket\_\{TGS\},
              Authenticator\_\{A,TGS\})\$ mit Authenticator
              \$A,TGS=\{A,Addr\_A,t'\emph{A\}}\{K\_\{A,TGS\}\}\$
        \item
              Nach Erhalt entschlüsselt TGS \$Ticket\_\{TGS\}\$, extrahiert daraus
              den Schlüssel \$K\_\{A,TGS\}\$ und verwendet diesen Schlüssel zur
              Entschlüsselung von \$Authenticator\_\{A,TGS\}\$. Wenn Name und
              Adresse des Authentifikators und des Tickets übereinstimmen und der
              Zeitstempel \$t'\emph{A\$ noch frisch ist, wird geprüft, ob A auf den
                  Dienst S1 zugreifen darf, und die folgende Nachricht erstellt: 4.
                  \$TGS\textbackslash rightarrow A:\{K}\{A,S1\}, S1, t\_\{TGS\},
              Ticket\_\{S1\}\}\emph{\{K}\{A,TGS\}\}\$ mit
              \$Ticket\_\{S1\}=\{K\_\{A,S1\}, A, Addr\_A, S1, t\_\{TGS\},
              LifetimeTicket\_\{S1\}\}\emph{\{K}\{TGS,S\}\}\$
        \item
              Alice entschlüsselt die Nachricht und verfügt nun über einen
              Sitzungsschlüssel für die sichere Kommunikation mit S1. Sie sendet nun
              eine Nachricht an S1, um ihm ihr Ticket und einen neuen
              Authentifikator zu zeigen: 5. \$A\textbackslash rightarrow
              S1:(Ticket\_\{S1\}, Authenticator\_\{A,S1\})\$ mit
              \$Authenticator\_\{A,S1\}=\{A,Addr\_A, t''\emph{A\}}\{K\_\{A,S1\}\}\$
        \item
              Nach Erhalt entschlüsselt S1 das Ticket mit dem Schlüssel
              \$K\_\{TGS,S1\}\$, den er mit TGS teilt, und erhält den
              Sitzungsschlüssel \$K\_\{A,S1\}\$ für die sichere Kommunikation mit A.
              Mit diesem Schlüssel überprüft er den Authentifikator und antwortet A:
              6. \$S1\textbackslash rightarrow A:\{t'\,'\emph{A+1\}}\{K\_\{A,S\}\}\$
        \item
              Durch Entschlüsselung dieser Nachricht und Überprüfung des enthaltenen
              Wertes kann Alice nachweisen, dass sie wirklich mit S1 kommuniziert,
              da nur er (neben TGS) den Schlüssel \$K\_\{TGS,S1\}\$ zur
              Entschlüsselung von \$Ticket\_\{S1\}\$ kennt, der den
              Sitzungsschlüssel \$K\_\{A,S1\}\$ enthält, und somit nur er in der
              Lage ist, \$Authenticator\_\{A,S1\}\$ zu entschlüsseln und mit
              \$t''\emph{\{A+1\}\$ verschlüsselt mit \$K}\{A,S\}\$ zu antworten
        \item
              Das oben beschriebene Protokoll ist der Kerberos-Dialog der Version 4.

              \begin{itemize}
                  \item
                        In diesem Protokoll wurden eine Reihe von Mängeln festgestellt, so
                        dass eine neue Version 5 des Protokolls definiert wurde, auf die wir
                        später eingehen werden...
                  \item
                        Wo liegt eigentlich das Problem?
              \end{itemize}
    \end{itemize}


    \subsubsection{Kerberos für mehrere
        Domänen}

    \begin{itemize}
        \item
              Stellen Sie sich eine Organisation mit Workstation-Clustern an zwei
              verschiedenen Standorten vor, und stellen Sie sich vor, dass Benutzer
              A von Standort 1 einen Server von Standort 2 benutzen möchte:

              \begin{itemize}
                  \item
                        Wenn beide Standorte ihre eigenen Kerberos-Server und
                        Benutzerdatenbanken (mit Passwörtern) verwenden, gibt es in der Tat
                        zwei verschiedene Domänen, in der Kerberos-Terminologie auch Realms
                        genannt.
                  \item
                        Um zu vermeiden, dass der Benutzer A in beiden Realms registriert
                        sein muss, ermöglicht Kerberos eine Inter-Realm-Authentifizierung.
              \end{itemize}
        \item
              Die Inter-Realm-Authentifizierung erfordert, dass die
              Ticket-erteilenden Server beider Domänen einen geheimen Schlüssel
              \$K\_\{TGS1,TGS2\}\$ teilen.

              \begin{itemize}
                  \item
                        Die Grundidee ist, dass der TGS eines anderen Realms als normaler
                        Server angesehen wird, für den der TGS des lokalen Realms ein Ticket
                        ausstellen kann.
                  \item
                        Nachdem Alice das Ticket für den entfernten Realm erhalten hat,
                        fordert sie ein Ticket für den Dienst beim entfernten TGS an.
                  \item
                        Dies bedeutet jedoch, dass der entfernte Realm dem
                        Kerberos-Authentifizierungsdienst der Heimatdomäne eines
                        ,,besuchenden'' Benutzers vertrauen muss!
                  \item
                        Skalierbarkeitsproblem: n Realms benötigen
                        \$n\textbackslash times(n-1)/2\$ geheime Schlüssel!
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-multi-domain-kerberos.png}
        \item
              Nachrichten, die während eines Protokolllaufs mit mehreren Domänen
              ausgetauscht werden:

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$A\textbackslash rightarrow AS1:(A,TGS1, t\_A)\$
                  \item
                        \$AS1\textbackslash rightarrow A:\{K\_\{A,TGS1\}, TGS1, t\_\{AS\},
                        LifetimeTicket\_\{TGS1\}, Ticket\_\{TGS1\}\}\emph{\{K\_A\}\$ mit
                            \$Ticket}\{TGS1\}=\{K\_\{A,TGS1\}, A, Addr\_A, TGS1, t\_\{AS\},
                        LifetimeTicket\_\{TGS1\}\}\emph{\{K}\{AS,TGS1\}\}\$
                  \item
                        \$A\textbackslash rightarrow
                        TGS1:(TGS2,Ticket\_\{TGS1\},Authenticator\_\{A,TGS1\})\$ mit
                        \$Authenticator\_\{A,TGS1\}=\{A,Addr\_A,t'\emph{A\}}\{K\_\{A,TGS1\}\}\$
                  \item
                        \$TGS1:\{K\_\{A,TGS2\}, TGS2, t\_\{TGS1\},
                        Ticket\_\{TGS2\}\}\emph{\{K}\{A,TGS1\}\}\$ mit
                        \$Ticket\_\{TGS2\}=\{K\_\{A,TGS2\}, A, Addr\_A, TGS2, t\_\{TGS1\},
                        LifetimeTicket\_\{TGS2\}\}\emph{\{K}\{TGS1,TGS2\}\}\$
                  \item
                        \$A\textbackslash rightarrow
                        TGS2:(S2,Ticket\_\{TGS2\},Authenticator\_\{A,TGS2\})\$ mit
                        \$Authenticator\_\{A,TGS2\}=\{A,Addr\_A,t''\emph{A\}}\{K\_\{A,TGS2\}\}\$
                  \item
                        \$TGS2\textbackslash rightarrow
                        A:\{K\_\{A,S2\},S2,t\_\{TGS2\},Ticket\_\{S2\}\}\emph{\{K}\{A,TGS2\}\}\$
                        with \$Ticket\_\{S2\}=\{K\_\{A,S2\},A,Addr\_A,S2,t\_\{TGS2\},
                        LifetimeTicket\_\{S2\}\}\emph{\{K}\{TGS2,S2\}\}\$
                  \item
                        S2:(Ticket\_\{S2\}, Authentifikator\_\{A,S2\})\$ mit
                        \$Authentifikator\_\{A,S2\}=\{A,Addr\_A,t'''\emph{A\}}\{K\_\{A,S2\}\}\$
                  \item
                        \$S2\textbackslash rightarrow
                        A:\{t'\,'\,'\emph{A+1\}}\{K\_\{A,S2\}\}\$
              \end{enumerate}
    \end{itemize}


    \subsubsection{Kerberos Version 5}

    \begin{itemize}
        \item
              Letzter Standard von 2005 (RFC 4120)
        \item
              Entwickelt als Reaktion auf Schwachstellen, die bei Kerberos v4
              bekannt wurden

              \begin{itemize}
                  \item
                        Enthält explizite Prüfsummen, um zu verifizieren, dass die
                        Nachrichten nicht verändert wurden
                  \item
                        Unterstützt mehrere Chiffren (andere als das unsichere DES)
              \end{itemize}
        \item
              Einheitliches Nachrichtenformat - Nachrichten an den
              Authentifizierungsserver und den Ticketvergabeserver sind sehr ähnlich
        \item
              Flexible ASN.1-Kodierung der Nachrichten, ermöglicht spätere
              Erweiterungen
        \item
              Im Folgenden wird nur eine vereinfachte Version gezeigt, weit mehr
              Funktionen sind standardisiert, z.B:

              \begin{itemize}
                  \item
                        Client-zu-Client gegenseitige Authentifizierung
                  \item
                        Vorauthentifizierte Tickets
                  \item
                        Erneuerung von Tickets
                  \item
                        Multidomain Kerberos
              \end{itemize}
        \item
              Der Authentifizierungsdialog in Kerberos Version 5 ist ähnlich wie in
              Version 4
        \item
              Der Austausch des Authentifizierungsdienstes: Bei der ersten
              Kontaktaufnahme sendet der Client A nicht nur Namen und Zeitstempel,
              sondern auch eine Nonce n , die hilft, Wiederholungen zu vermeiden,
              wenn sich die Zeit geändert hat; es ist auch möglich, mehrere Adressen
              anzugeben

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$A\textbackslash rightarrow
                        AS:(A,TGS,t\_\{start\},t\_\{end\},n,Addr\_A, ...)\$
              \end{enumerate}
        \item
              Die Antwort enthält ein Klartext-Ticket und verschlüsselte
              Informationen: 2. \$AS\textbackslash rightarrow A:
              (A,Ticket\_\{TGS\},\{K\_\{A,TGS\},
              LastRequest,n,t\_\{expire\},t\_\{AS\},t\_\{start\},t\_\{end\},t\_\{renew\},TGS,
              Addr\_A\}\emph{\{K\_A\})\$ mit \$Ticket}\{TGS\}=(TGS,
              \{K\_\{A,TGS\},A,transited, t\_\{AS\},
              t\_\{start\},t\_\{end\},t\_\{renew\},Addr\_A,restrictions\}\emph{\{K}\{AS,TGS\}\})\$

              \begin{itemize}
                  \item
                        LastRequest gibt den letzten Login des Benutzers an transited
                        enthält die Vertrauenskette Multidomain Kerberos Restriktionen für
                        den Benutzer können dem TGS und den Servern übergeben werden
                        \$t\_\{expire\}\$ und \$t\_\{end\}\$ enthalten verschiedene Zeiten,
                        um die Erneuerung von Tickets zu ermöglichen (wobei die Start- und
                        Endzeit einfach aktualisiert werden können)
              \end{itemize}
        \item
              Der Dialog zum TGS ist mit dem Ausgangsdialog harmonisiert: Er enthält
              zusätzlich Tickets und einen Authentifikator, der beweist, dass A
              \$K\_\{A,TGS\}\$ kennt 3. \$Aufrechtes
              TGS:(A,S1,t\_\{start\},t\_\{end\},n',Addr\_A,Authenticator\_\{A,TGS\},
              Tickets,...)\$ mit \$Authenticator\_\{A,TGS\}=\{A, CheckSum,
              t\_\{A'\}, K\_\{A,TGS'\}, Seq\#,...\}\emph{\{K}\{A,TGS\}\}\$ Hinweis:
              Der Authentifikator enthält jetzt eine kryptographische Prüfsumme!
        \item
              Die Antwort an A ist völlig analog zu Nachricht 2: 4.
              \$TGS\textbackslash rightarrow
              A:(A,Ticket\_\{S1\},\{K\_\{A,S1\},LastRequest,
              n',t\_\{expire\},t\_\{TGS\},t\_\{start\},t\_\{end\},t\_\{renew\},S1,Addr\_A\}\emph{\{K}\{A,TGS\}\})\$
        \item
              Der Austausch mit dem Server ist ebenfalls ähnlich wie bei Version 4,
              aber mit dem Authentifikator ist eine explizite Prüfsumme möglich: 5.
              \$A\textbackslash rightarrow S1:(Ticket\_\{S1\},
              Authenticator\_\{A,S1\})\$ mit
              \$Authenticator\_\{A,S1\}=\{A,CheckSum,t\_\{A''\},K\_\{A,S1\}', Seq\#,
              ...\}\emph{\{K}\{A,S1\}\}\$
        \item
              Nach Erhalt entschlüsselt S1 das Ticket mit dem Schlüssel
              \$K\_\{TGS,S1\}\$, den er mit TGS teilt, und erhält den
              Sitzungsschlüssel \$K\_\{A,S1\}\$ für die sichere Kommunikation mit A.
              Mit diesem Schlüssel überprüft er den Authentifikator und antwortet A:
              6. \$S1\textbackslash rightarrow
              A:\{t\_\{S1\},K\_\{A,S1\}',Seq\#,...\}\emph{\{K}\{A,S1\}\}\$
        \item
              Alles in allem behebt der Dialog mehrere potenzielle Schwachstellen,
              während andere bestehen bleiben:

              \begin{itemize}
                  \item
                        Sequenznummern und Nonces ermöglichen eine zusätzliche
                        Replay-Prüfung, wenn sich die Zeitbasis ändert
                  \item
                        Explizite Prüfsummen verhindern die Änderung von Daten innerhalb von
                        Tickets
                  \item
                        Zentrale Server sind immer noch potentielle Single-Points-of-Failure
                  \item
                        Für den ersten Austausch ist immer noch eine gewisse
                        Zeitsynchronisierung erforderlich.
              \end{itemize}
    \end{itemize}


    \subsection{Fortgeschrittene Methoden zur
        Passwortauthentifizierung}

    \begin{itemize}
        \item
              Alle gezeigten Protokolle haben eine gemeinsame Schwäche:

              \begin{itemize}
                  \item
                        Passwörter müssen leicht zu merken und leicht einzugeben sein
                        \$\textbackslash rightarrow\$ Geringe Entropie
                  \item
                        Angreifer können schnell alle möglichen Kombinationen ausprobieren
                  \item
                        Offline, über Grafikkarten, Cloud-Computer, spezielle Hardware...
                  \item
                        Asymmetrische Situation
              \end{itemize}
        \item
              Mögliche Lösungen:

              \begin{itemize}
                  \item
                        Schlüsselableitungsfunktionen

                        \begin{itemize}
                            \item
                                  Erschweren Brute-Force-Angriffe durch extrem häufiges Hashing
                            \item
                                  Erfordert auch Aufwand durch legitime Geräte
                            \item
                                  Nur linearer Sicherheitsgewinn
                            \item
                                  Bessere Funktionen verbrauchen viel Speicher, um Angriffe mit
                                  Grafikkarten und spezieller Hardware undurchführbar zu machen
                        \end{itemize}
                  \item
                        Passwort-authentifizierter Schlüsselaustausch (PAKE)
              \end{itemize}
        \item
              Passwortauthentifizierter Schlüsselaustausch (PAKE) - Grundlegende
              Idee

              \begin{itemize}
                  \item
                        Durchführen eines Schlüsselaustauschs mit asymmetrischer
                        Kryptographie
                  \item
                        Authentifizierung von Peers mit einem Passwort unter Verwendung
                        eines Zero Knowledge Proofs
                  \item
                        Die Peers können nur feststellen, ob die Passwörter übereinstimmen
                        oder nicht
                  \item
                        Keine weiteren Informationen, um effiziente Bruteforce-Suchen
                        durchzuführen

                        \begin{itemize}
                            \item
                                  Würde das Lösen schwieriger Probleme erfordern, z. B. eine Art
                                  DH-Problem
                            \item
                                  Macht Offline-Angriffe undurchführbar
                        \end{itemize}
                  \item
                        Online-Angriffe möglich, können aber entdeckt werden
              \end{itemize}
    \end{itemize}


    \subsection{PAKE-Schemata: EKE}

    \begin{itemize}
        \item
              Ein einfaches erstes Protokoll ist Encrypted Key Exchange (EKE)
              {[}BM92{]}
        \item
              Der Dialog beginnt damit, dass A ein privates/öffentliches
              Schlüsselpaar zur einmaligen Verwendung erzeugt und den öffentlichen
              Schlüssel \$+K\_\{ar\}\$ verschlüsselt mit dem Passwort \$K\_\{A,B\}\$
              an B sendet

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$A\textbackslash rightarrow B:A,\{+K\_\{ar\}\}\emph{\{K}\{A,B\}\}\$
              \end{enumerate}
        \item
              B wählt einen symmetrischen Sitzungsschlüssel \$K\_r\$ und sendet ihn
              verschlüsselt mit dem öffentlichen Schlüssel und dem Passwort zurück
              an A

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$B\textbackslash rightarrow
                        A:\{\{K\_r\}\emph{\{+K}\{ar\}\}\}\emph{\{K}\{A,B\}\}\$
              \end{enumerate}
        \item
              A und B teilen sich nun einen gemeinsamen Sitzungsschlüssel und
              beweisen ihr Wissen darüber durch den Austausch von Nonces

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$A\textbackslash rightarrow B:\{r\_A\}\_\{K\_r\}\$
                  \item
                        \$B\textbackslash rightarrow A:\{r\_A,r\_B\}\_\{K\_r\}\$
                  \item
                        \$A\textbackslash rightarrow B:\{r\_B\}\_\{K\_r\}\$
              \end{enumerate}
        \item
              Nach diesem Schritt ist sichergestellt, dass beide \$K\_\{A,B\}\$
              gekannt haben müssen und es keinen Man-in-the-Middle-Angriff gegeben
              hat
    \end{itemize}


    \subsubsection{Sicherheitsdiskussion}

    \begin{itemize}
        \item
              Resistenz gegen Offline-Angriffe hängt davon ab, dass \$+K\_\{ar\}\$
              nicht von Zufallszahlen zu unterscheiden ist

              \begin{itemize}
                  \item
                        Was bedeutet das für ECC?
                  \item
                        Für RSA schlagen die Autoren vor, e zu verschlüsseln und n im
                        Klartext zu senden

                        \begin{itemize}
                            \item
                                  n hat keine kleinen Primfaktoren und ist daher von Zufallszahlen
                                  unterscheidbar
                            \item
                                  Immer noch unsicher gegen Man-in-the-Middle-Angriffe, da Angreifer
                                  n mit besonderen Eigenschaften wählen können (z.B. \$p-1\$ und
                                  \$q-1\$ teilbar durch 3)
                            \item
                                  Antwort von B ist von Zufallszahlen unterscheidbar
                            \item
                                  Details sind in {[}Par97{]} oder {[}SR14{]} zu finden.
                        \end{itemize}
              \end{itemize}
        \item
              Bietet keine perfekte Vorwärtsverschwiegenheit...
        \item
              Aber es gibt ein anderes Protokoll von den Autoren namens DH-EKE
    \end{itemize}


    \subsubsection{DH-EKE}

    \begin{itemize}
        \item
              DH-EKE ist im Grunde ein DH-Austausch mit cleverer Authentifizierung
        \item
              A sendet DH-Austausch verschlüsselt mit dem Passwort \$K\_\{A,B\}\$

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$A\textbackslash rightarrow B:\{g\^{}\{ra\}\textbackslash{}
                        mod\textbackslash{} p\}\emph{\{K}\{A,B\}\}\$
              \end{enumerate}
        \item
              B antwortet mit seinem Teil des DH-Austauschs (verschlüsselt mit dem
              Passwort \$K\_\{A,B\}\$) und verwendet den Sitzungsschlüssel
              \$K\_S=g\^{}\{ra*rb\}\textbackslash{} mod\textbackslash{} p\$, um eine
              verschlüsselte Nonce \$c\_b\$ zu senden 2.
              \$B\textbackslash rightarrow A:\{g\^{}\{rb\}\textbackslash{}
              mod\textbackslash{} p\}\emph{\{K}\{A,B\}\}\{c\_b\}\_\{K\_s\}\$
        \item
              Beide Parteien beweisen ihre Kenntnis von \$K\_S\$ 3.
              \$A\textbackslash rightarrow
              B:\{c\_a\textbar\textbar c\_b\}\emph{\{K\_s\} 4.
                  \$B\textbackslash rightarrow A:\{c\_a\}}\{K\_s\}\$
    \end{itemize}


    \subsubsection{Sicherheitsdiskussion 2}

    \begin{itemize}
        \item
              Wiederum müssen verschlüsselte Daten von Zufallsdaten ununterscheidbar
              sein

              \begin{itemize}
                  \item
                        Der Wert p muss klug gewählt werden, d.h. \$p-1\$ muss nahe bei
                        \$2\^{}\{8*n\}\$ für ausreichend große natürliche Zahlen n liegen
                  \item
                        Um Angriffe auf kleine Gruppen leicht zu verhindern, sollte
                        \$(p-1)/2\$ ebenfalls eine Primzahl sein.
                  \item
                        ECC ist immer noch schwierig zu realisieren
              \end{itemize}
        \item
              Bietet perfektes Vorwärtsgeheimnis
        \item
              Alles in allem ein nettes Verfahren, das jedoch patentiert werden
              musste

              \begin{itemize}
                  \item
                        Keine breite Anpassung
                  \item
                        Führte zur Entwicklung zahlreicher anderer Verfahren
              \end{itemize}
    \end{itemize}


    \subsubsection{SRP}

    \begin{itemize}
        \item
              Das heute am weitesten verbreitete Protokoll: Sicheres Fernkennwort
              (SRP)
        \item
              Mehrere Versionen: Hier SRP-6a {[}Wu02{]}
        \item
              Initialisierung:

              \begin{itemize}
                  \item
                        Server B wählt eine Zufallszahl \$s\_\{A,B\}\$
                  \item
                        berechnet \$x=H(s\_\{A,B\} \textbar\textbar{} Benutzername
                        \textbar\textbar{} Passwort)\$ und \$v=g\^{}x\textbackslash{}
                        mod\textbackslash{} p\$
                  \item
                        Benutzer werden durch \$(Benutzername, s\_\{A,B\}, v)\$
                        authentifiziert
                  \item
                        Der Server braucht das Passwort nicht zu speichern
                        \$\textbackslash rightarrow\$ kann nicht leicht erlangt werden, wenn
                        der Server kompromittiert wird!
                  \item
                        Server kann diese Werte auch nicht verwenden, um sich als Benutzer
                        auf anderen Servern auszugeben
                  \item
                        Die Eigenschaft wird als erweitertes PAKE-Schema bezeichnet
              \end{itemize}
    \end{itemize}


    \subsubsection{SRP - Dialog}

    \begin{itemize}
        \item
              A initiiert die Verbindung durch Senden seines Benutzernamens

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$A\textbackslash rightarrow B: A\$
              \end{enumerate}
        \item
              B antwortet mit ausgewählten kryptographischen Parametern und einem
              Verifizierer v, der durch einen DH-Austausch ,,geblendet'' ist 2.
              \$B\textbackslash rightarrow A: p, g, s\_\{A,B\}, (H(g
              \textbar\textbar{} p)*v + g\^{}\{rb\})\textbackslash{}
              mod\textbackslash{} p\$
        \item
              A berechnet den gemeinsamen Sitzungsschlüssel durch \$K\_S=(Y\_B-H(g
              \textbar\textbar{} p)\emph{g\^{}x)\^{}\{ra+u}x\}\textbackslash{}
              mod\textbackslash{} p\$, mit \$u=H(Y\_A\textbar\textbar Y\_B)\$, und
              sendet seinen Teil des DH-Austauschs und eine Bestätigung zurück, dass
              er \$K\_S\$ kennt 3. \$A\textbackslash rightarrow
              B:g\^{}\{ra\}\textbackslash{} mod\textbackslash{} p,
              H(Y\_A,Y\_B,K\_S)\$
        \item
              B berechnet \$K\_S'=(Y\_A v\^{}u)\^{}\{rb\}\textbackslash{}
              mod\textbackslash{} p\$ und beweist seine Kenntnis 4.
              \$B\textbackslash rightarrow A:H(Y\_A, H(Y\_A,Y\_B,K\_S),K\_S')\$
        \item
              \$K\_S'\$ und \$K\_S\$ stimmen überein, wenn es keinen
              Man-in-the-Middle-Angriff gegeben hat
    \end{itemize}


    \subsubsection{SRP - Diskussion}

    \begin{itemize}
        \item
              Sicheres Schema

              \begin{itemize}
                  \item
                        Gegenseitige Authentifizierung zwischen Server und Client
                  \item
                        Erweiterung erhöht die Sicherheit in Client/Server-Szenarien
                  \item
                        Keine Unterstützung für ECC, da es Feldarithmetik erfordert
              \end{itemize}
        \item
              Patentiert, aber frei zu verwenden
        \item
              Unterstützung für TLS, IPsec, ...
    \end{itemize}


    \subsection{X.509 - Einführung}

    \begin{itemize}
        \item
              X.509 ist eine internationale Empfehlung der ITU-T und gehört zur
              X.500-Reihe, die Verzeichnisdienste definiert:

              \begin{itemize}
                  \item
                        Die erste Version von X.509 wurde 1988 standardisiert.
                  \item
                        Eine zweite Version, die 1993 standardisiert wurde, löste einige
                        Sicherheitsbedenken
                  \item
                        Eine dritte Version von X.509 wird derzeit von der IETF in RFC 4211
                        gepflegt.
              \end{itemize}
        \item
              X.509 definiert einen Rahmen für die Bereitstellung von
              Authentifizierungsdiensten, der Folgendes umfasst:

              \begin{itemize}
                  \item
                        Zertifizierung von öffentlichen Schlüsseln und Handhabung von
                        Zertifikaten:

                        \begin{itemize}
                            \item
                                  Zertifikatsformat
                            \item
                                  Zertifikats-Hierarchie
                            \item
                                  Zertifikatswiderrufslisten
                        \end{itemize}
                  \item
                        Drei verschiedene Dialoge für die direkte Authentifizierung:

                        \begin{itemize}
                            \item
                                  Einseitige Authentifizierung, erfordert synchronisierte Uhren
                            \item
                                  Gegenseitige Zwei-Wege-Authentifizierung, erfordert immer noch
                                  synchronisierte Uhren
                            \item
                                  Gegenseitige Drei-Wege-Authentifizierung, die vollständig auf
                                  Zufallszahlen basiert
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsubsection{X.509 - Zertifikate mit öffentlichem
        Schlüssel}

    % \includegraphics{Assets/NetworkSecurity-x509-certificates.png}

    \begin{itemize}
        \item
              Ein Public-Key-Zertifikat ist eine Art Reisepass, der bescheinigt,
              dass ein öffentlicher Schlüssel zu einem bestimmten Namen gehört
        \item
              Zertifikate werden von Zertifizierungsstellen (CA) ausgestellt.
        \item
              Wenn alle Nutzer den öffentlichen Schlüssel der CA kennen, kann jeder
              Nutzer jedes von dieser CA ausgestellte Zertifikat überprüfen.
        \item
              Zertifikate können die Online-Teilnahme eines TTP verhindern
        \item
              Die Sicherheit des privaten Schlüssels der CA ist entscheidend für die
              Sicherheit aller Nutzer!
        \item
              Notation eines Zertifikats, das einen öffentlichen Schlüssel \$+K\_A\$
              an Benutzer A bindet, ausgestellt von der Zertifizierungsstelle CA
              unter Verwendung ihres privaten Schlüssels \$-CK\_\{CA\}\$:

              \begin{itemize}
                  \item
                        \$Cert\_\{-CK\_\{CA\}\}(+K\_A) = CA{[}V, SN, AI, CA, T\_\{CA\}, A,
                        +K\_A{]}\$ mit:

                        \begin{itemize}
                            \item
                                  V = Versionsnummer
                            \item
                                  SN = Seriennummer
                            \item
                                  AI = Algorithmus-Bezeichner des verwendeten Signatur-Algorithmus
                            \item
                                  CA = Name der Zertifizierungsstelle
                            \item
                                  \$T\_\{CA\}\$ = Gültigkeitsdauer dieses Zertifikats
                            \item
                                  A = Name, an den der öffentliche Schlüssel in diesem Zertifikat
                                  gebunden ist
                            \item
                                  \$+K\_A\$ = öffentlicher Schlüssel, der an einen Namen gebunden
                                  wird
                        \end{itemize}
                  \item
                        Die Kurzschreibweise \$CA{[}m{]}\$ steht für
                        \$(m,\{H(m)\}\emph{\{-CK}\{CA\}\})\$
                  \item
                        Eine andere Kurzschreibweise für \$Cert\_\{-CK\_\{CA\}\}(+K\_A)\$
                        ist \$CA\textless{}\textgreater\$
              \end{itemize}
    \end{itemize}


    \subsubsection{X.509 - Zertifikatsketten \&
        Zertifikatshierarchie}

    \begin{itemize}
        \item
              Betrachten wir nun zwei Benutzer Alice und Bob, die in verschiedenen
              Ländern leben und sicher kommunizieren wollen:

              \begin{itemize}
                  \item
                        Die Wahrscheinlichkeit ist recht hoch, dass ihre öffentlichen
                        Schlüssel von verschiedenen CAs zertifiziert sind
                  \item
                        Nennen wir die Zertifizierungsstelle von Alice CA und die von Bob CB
                  \item
                        Wenn Alice CB nicht vertraut oder gar kennt, dann ist Bobs
                        Zertifikat \$CB\textless{}\textgreater\$ für sie nutzlos, dasselbe
                        gilt in der anderen Richtung
              \end{itemize}
        \item
              Eine Lösung für dieses Problem ist die Konstruktion von
              Zertifikatsketten:

              \begin{itemize}
                  \item
                        Stellen Sie sich einmal vor, dass CA und CB einander kennen und
                        einander vertrauen.

                        \begin{itemize}
                            \item
                                  Ein Beispiel aus der realen Welt für dieses Konzept ist das
                                  gegenseitige Vertrauen zwischen Ländern hinsichtlich ihrer
                                  Passausgabestellen
                        \end{itemize}
                  \item
                        Wenn CA den öffentlichen Schlüssel von CB mit einem Zertifikat
                        \$CA\textless{}\textgreater\$ und CB den öffentlichen Schlüssel von
                        CA mit einem Zertifikat \$CB\textless{}\textgreater\$ beglaubigt,
                        können A und B ihre Zertifikate anhand einer Zertifikatskette
                        überprüfen:

                        \begin{itemize}
                            \item
                                  Nachdem ihr \$CB\textless{}\textgreater\$ vorgelegt wurde,
                                  versucht Alice herauszufinden, ob es ein Zertifikat
                                  \$CA\textless{}\textgreater\$ gibt.
                            \item
                                  Sie überprüft dann die Kette: \$CA\textless{}\textgreater,
                                  CB\textless{}\textgreater\$
                        \end{itemize}
              \end{itemize}
        \item
              Zertifikatsketten müssen nicht auf eine Länge von zwei Zertifikaten
              beschränkt sein:

              \begin{itemize}
                  \item
                        \$CA\textless{}\textgreater, CC\textless{}\textgreater,
                        CD\textless{}\textgreater, CE\textless{}\textgreater,
                        CG\textless{}\$ würde es Alice erlauben, das von CG ausgestellte
                        Zertifikat des Benutzers G zu überprüfen, auch wenn sie nur ihre
                        eigene Zertifizierungsstelle CA kennt und ihr vertraut.
                  \item
                        Tatsächlich wird das Vertrauen von A in den Schlüssel +KG durch eine
                        Vertrauenskette zwischen Zertifizierungsstellen hergestellt.
                  \item
                        Wenn Alice jedoch \$CG\textless{}\textgreater\$ vorgelegt wird, ist
                        es nicht offensichtlich, welche Zertifikate sie zur Überprüfung
                        benötigt
              \end{itemize}
        \item
              X.509 schlägt daher vor, dass die Zertifizierungsstellen in einer
              Zertifizierungshierarchie angeordnet werden, so dass die Navigation
              einfach ist:

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-x509-hierarchy.png}
              \end{itemize}
        \item
              Verbleibendes Problem:

              \begin{itemize}
                  \item
                        Zertifizierungspfade können ziemlich lang werden
                  \item
                        Die Kompromittierung eines einzigen Zwischenzertifikats reicht aus,
                        um die Sicherheit zu brechen
              \end{itemize}
        \item
              Führt zu zwei Entwicklungen

              \begin{itemize}
                  \item
                        Kreuzzertifizierung:

                        \begin{itemize}
                            \item
                                  Ermöglicht das Signieren von Stammzertifikaten untereinander
                            \item
                                  Erlaubt aber auch ,,Abkürzungen'' im Zertifikatswald
                            \item
                                  Macht die Navigation komplexer, aber potenziell mehrwegfähig
                        \end{itemize}
                  \item
                        Anheften von Zertifikaten:

                        \begin{itemize}
                            \item
                                  Ermöglicht Anwendungen, z. B. Webbrowsern, zu lernen, dass Peers
                                  nur Zertifikate von einer bestimmten CA verwenden
                            \item
                                  Wird z. B. von Google Chrome verwendet, nachdem
                                  Man-in-the-Middle-Angriffe auf google.com bekannt wurden
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsubsection{X.509 -
        Zertifikatssperrung}

    \begin{itemize}
        \item
              Nehmen wir nun an, dass der private Schlüssel von Alice kompromittiert
              wurde, z.B. weil Eve in ihren Computer eingebrochen ist, ihren
              privaten Schlüssel aus einer Datei gelesen und das Passwort geknackt
              hat, das sie zum Schutz des privaten Schlüssels verwendet hat:

              \begin{itemize}
                  \item
                        Wenn Alice feststellt, dass ihr privater Schlüssel kompromittiert
                        wurde, möchte sie unbedingt den Widerruf des entsprechenden
                        Zertifikats für den öffentlichen Schlüssel beantragen.
                  \item
                        Wenn das Zertifikat nicht widerrufen wird, könnte sich Eve bis zum
                        Ende der Gültigkeitsdauer des Zertifikats weiterhin als Alice
                        ausgeben.
              \end{itemize}
        \item
              Eine noch schlimmere Situation tritt ein, wenn der private Schlüssel
              einer Zertifizierungsstelle kompromittiert wird:

              \begin{itemize}
                  \item
                        Dies bedeutet, dass alle mit diesem Schlüssel signierten Zertifikate
                        widerrufen werden müssen!
              \end{itemize}
        \item
              Der Widerruf von Zertifikaten wird durch das Führen von
              Zertifikatswiderrufslisten (CRL) realisiert:

              \begin{itemize}
                  \item
                        CRLs werden im X.500-Verzeichnis gespeichert, oder Erweiterungen
                        können auf eine URL verweisen
                  \item
                        Bei der Überprüfung eines Zertifikats muss auch geprüft werden, ob
                        das Zertifikat noch nicht widerrufen wurde (Suche nach dem
                        Zertifikat in der CRL)
                  \item
                        Der Widerruf von Zertifikaten ist ein relativ langsamer und teurer
                        Vorgang
              \end{itemize}
    \end{itemize}


    \subsubsection{X.509 -
        Authentifizierungsprotokolle}

    \begin{itemize}
        \item
              Einweg-Authentifizierung:

              \begin{itemize}
                  \item
                        Wenn nur Alice sich gegenüber Bob authentifizieren will, sendet sie
                        folgende Nachricht an Bob:
              \end{itemize}

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$(A{[}t\_A, r\_A, B, sgnData\_A, \{K\_\{A,B\}\}\emph{\{+KB\}{]},
                        CA\textless{}\textgreater)\$, wobei \$sgnData\_A\$ optionale Daten
                        darstellt, die von \$A signiert werden sollen,
                        \{K}\{A,B\}\}\_\{+K\_B\}\$ ein optionaler Sitzungsschlüssel ist, der
                        mit Bobs öffentlichem Schlüssel verschlüsselt wird, und
                        \$CA\textless{}\textgreater\$ ebenfalls optional ist
              \end{enumerate}

              \begin{itemize}
                  \item
                        Beim Empfang dieser Nachricht verifiziert Bob mit \$+K\_\{CA\}\$ das
                        enthaltene Zertifikat, extrahiert Alices öffentlichen Schlüssel,
                        überprüft Alices Signatur der Nachricht und die Aktualität der
                        Nachricht \$(t\_A)\$ und entschlüsselt optional den enthaltenen
                        Sitzungsschlüssel \$K\_\{A,B\}\$, den Alice vorgeschlagen hat
              \end{itemize}
        \item
              Zwei-Wege-Authentifizierung:

              \begin{itemize}
                  \item
                        Wenn eine gegenseitige Authentifizierung erwünscht ist, dann
                        erstellt Bob eine ähnliche Nachricht:
              \end{itemize}

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \setcounter{enumi}{1}
                  \item
                        \$(B{[}t\_B, r\_B, A, r\_A, sgnData\_B,\{K\_\{B,A\}\}\_\{+K\_A\}{]},
                        CA\textless{}\textgreater)\$ der enthaltene Zeitstempel \$t\_B\$ ist
                        nicht wirklich erforderlich, da Alice überprüfen kann, ob die
                        signierte Nachricht die Zufallszahl \$r\_A\$ enthält
              \end{enumerate}
        \item
              Drei-Wege-Authentifizierung:

              \begin{itemize}
                  \item
                        Wenn Alice und Bob nicht sicher sind, ob sie synchrone Uhren haben,
                        sendet Alice die folgende Nachricht an Bob:
              \end{itemize}

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \setcounter{enumi}{2}
                  \item
                        \$A{[}r\_B{]}\$
              \end{enumerate}

              \begin{itemize}
                  \item
                        Die Rechtzeitigkeit der Teilnahme von Alice am
                        Authentifizierungsdialog wird also durch die Unterzeichnung der
                        ,,frischen'' Zufallszahl \$r\_B\$ nachgewiesen.
              \end{itemize}
        \item
              Anmerkung zum Signaturalgorithmus:

              \begin{itemize}
                  \item
                        Wie aus der Verwendung von Zertifikaten ersichtlich, schlägt X.509
                        vor, die Authentifizierungsnachrichten mit asymmetrischer
                        Kryptographie zu signieren.
                  \item
                        Das Authentifizierungsprotokoll selbst kann jedoch auch mit
                        symmetrischer Kryptographie eingesetzt werden:

                        \begin{itemize}
                            \item
                                  In diesem Fall müssen sich A und B vor jedem Protokolldurchlauf
                                  auf einen geheimen Authentifizierungsschlüssel \$AK\_\{A,B\}\$
                                  geeinigt haben, und
                            \item
                                  die Nachrichten werden durch Anhängen eines mit diesem Schlüssel
                                  berechneten MAC signiert.
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Formale Validierung von kryptographischen
        Protokollen}

    \begin{itemize}
        \item
              Wie wir am Beispiel des Needham-Schroeder-Protokolls gesehen haben,
              ist die Sicherheit eines kryptografischen Protokolls nicht einfach zu
              beurteilen:

              \begin{itemize}
                  \item
                        Es gibt viele weitere Beispiele für Protokollfehler in
                        kryptografischen Protokollen, die manchmal erst Jahre nach der
                        Veröffentlichung des Protokolls entdeckt wurden

                        \begin{itemize}
                            \item
                                  Eine frühe Version des X.509-Standards enthielt einen Fehler, der
                                  dem Fehler im Needham-Schroeder-Protokoll ähnlich war.
                        \end{itemize}
                  \item
                        Daraus ergibt sich der Bedarf an formalen Methoden zur Analyse der
                        Eigenschaften von kryptographischen Protokollen
              \end{itemize}
        \item
              Kategorien von formalen Validierungsmethoden für kryptografische
              Protokolle:

              \begin{itemize}
                  \item
                        Allgemeine Ansätze zur Analyse spezifischer Protokolleigenschaften:

                        \begin{itemize}
                            \item
                                  Beispiele: Finite-State-Machine-basierte Ansätze, Prädikatenkalkül
                                  erster Ordnung, Allzweck-Spezifikationssprachen
                            \item
                                  Hauptnachteil: Sicherheit unterscheidet sich wesentlich von
                                  Korrektheit, da für letztere keine böswillige Manipulation
                                  angenommen werden muss
                        \end{itemize}
              \end{itemize}
        \item
              Kategorien von formalen Validierungsmethoden für kryptographische
              Protokolle:

              \begin{itemize}
                  \item
                        Expertensystembasierte Ansätze:

                        \begin{itemize}
                            \item
                                  Das Wissen menschlicher Experten wird in deduktive Regeln
                                  formalisiert, die von einem Protokolldesigner zur Untersuchung
                                  verschiedener Szenarien verwendet werden können.
                            \item
                                  Hauptnachteil: nicht gut geeignet, um Schwachstellen in
                                  kryptografischen Protokollen zu finden, die auf unbekannten
                                  Angriffstechniken beruhen
                        \end{itemize}
                  \item
                        Algebraische Ansätze:

                        \begin{itemize}
                            \item
                                  Kryptografische Protokolle werden als algebraische Systeme
                                  spezifiziert
                            \item
                                  Die Analyse wird durchgeführt, indem algebraische
                                  Termumschreibungseigenschaften des Modells untersucht werden und
                                  geprüft wird, ob das Modell bestimmte erwünschte oder unerwünschte
                                  Zustände erreichen kann
                        \end{itemize}
                  \item
                        Spezifische logikbasierte Ansätze:

                        \begin{itemize}
                            \item
                                  Ansätze dieser Klasse definieren einen Satz von Prädikaten und
                                  eine Abbildung der während eines Protokolllaufs ausgetauschten
                                  Nachrichten auf einen Satz von Formeln
                            \item
                                  Ein generischer Satz von Regeln erlaubt es dann, das Wissen und
                                  den Glauben zu analysieren, der von den Peer-Entitäten eines
                                  kryptographischen Protokolls während eines Protokolllaufs erlangt
                                  wird (recht erfolgreicher Ansatz: GNY-Logik {[}GNY90a{]})
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \section{Sichere
      Gruppenkommunikation}


    \section{Zugriffskontrolle}


    \subsection{Was ist Zugangskontrolle?}

    \begin{itemize}
        \item
              Definition: Die Zugriffskontrolle umfasst die Mechanismen, die die
              Vermittlung von Subjektanfragen für den Zugriff auf Objekte, wie sie
              in einer bestimmten Sicherheitspolitik definiert sind, erzwingen.
        \item
              Ein wichtiges konzeptuelles Modell in diesem Zusammenhang ist der
              Referenzmonitor:
        \item
              % \includegraphics{Assets/NetworkSecurity-reference-monitor.png}
    \end{itemize}


    \subsection{Sicherheitspolitik}

    \begin{itemize}
        \item
              Um Entscheidungen über die Zugriffskontrolle treffen zu können, muss
              der Referenzmonitor die Sicherheitspolitik des Systems kennen
        \item
              Definition: Die Sicherheitspolitik eines Systems definiert die
              Bedingungen, unter denen Subjektzugriffe auf Objekte durch die
              Funktionalität des Systemreferenzmonitors vermittelt werden
        \item
              Bemerkungen:

              \begin{itemize}
                  \item
                        Die obige Definition wird gewöhnlich im Zusammenhang mit der
                        Sicherheit von Computern und Betriebssystemen gegeben.
                  \item
                        Der Referenzmonitor ist nur eine konzeptionelle Einheit, er muss
                        nicht unbedingt ein physisches oder logisches Gegenstück in einem
                        bestimmten System haben.
                  \item
                        Der Begriff Sicherheitspolitik wird oft auch in einem weiteren Sinne
                        verwendet, um eine Spezifikation aller Sicherheitsaspekte eines
                        Systems einschließlich Bedrohungen, Risiken, Sicherheitsziele,
                        Gegenmaßnahmen usw. zu beschreiben.
              \end{itemize}
    \end{itemize}


    \subsection{Klassische Computersubjekte, Objekte und
        Zugriffsarten}

    \begin{itemize}
        \item
              Definition: Ein Subjekt ist eine aktive Entität, die eine Anfrage nach
              Ressourcen initiieren und diese Ressourcen nutzen kann, um eine
              Aufgabe zu erfüllen.
        \item
              Definition: Ein Objekt ist ein passives Repository, das zur
              Speicherung von Informationen dient
        \item
              Die beiden obigen Definitionen stammen aus der klassischen
              Computerwissenschaft:

              \begin{itemize}
                  \item
                        Subjekte sind Prozesse, und Dateien, Verzeichnisse usw. sind
                        Objekte.
              \end{itemize}
        \item
              Es ist jedoch nicht immer offensichtlich, Subjekte und Objekte im
              Zusammenhang mit der Kommunikation zu identifizieren:

              \begin{itemize}
                  \item
                        Stellen Sie sich vor, eine Einheit sendet eine Nachricht an eine
                        andere Einheit: Ist die empfangende Einheit als Objekt zu
                        betrachten?
              \end{itemize}
        \item
              Außerdem müssen wir wissen, was ein Zugriff ist und welche Arten von
              Zugriffen es gibt:

              \begin{itemize}
                  \item
                        Beispiele aus der klassischen Informatik für Zugriffsarten: Lesen,
                        Schreiben, Ausführen
                  \item
                        Objektorientierte Sichtweise: Jede Methode eines Objekts definiert
                        eine Art des Zugriffs
              \end{itemize}
    \end{itemize}


    \subsection{Sicherheitskennzeichen}

    \begin{itemize}
        \item
              Definition: Eine Sicherheitsstufe wird als hierarchisches Attribut zu
              Entitäten eines Systems definiert, um deren Sensibilitätsgrad zu
              kennzeichnen

              \begin{itemize}
                  \item
                        Beispiele:

                        \begin{itemize}
                            \item
                                  Militär: unklassifiziert \textless{} vertraulich \textless{}
                                  geheim \textless{} streng geheim
                            \item
                                  Kommerziell: öffentlich \textless{} sensibel \textless{}
                                  proprietär \textless{} eingeschränkt
                        \end{itemize}
              \end{itemize}
        \item
              Definition: Eine Sicherheitskategorie ist definiert als eine
              nicht-hierarchische Gruppierung von Entitäten, um den Grad ihrer
              Sensibilität zu kennzeichnen.

              \begin{itemize}
                  \item
                        Beispiel (Wirtschaft): Abteilung A, Abteilung B, Verwaltung usw.
              \end{itemize}
        \item
              Definition: Eine Sicherheitskennzeichnung ist definiert als ein
              Attribut, das mit Systemeinheiten verbunden ist, um deren
              hierarchische Sensibilitätsstufe und Sicherheitskategorien zu
              kennzeichnen.

              \begin{itemize}
                  \item
                        In Form von mathematischen Mengen: \$Labels = Levels
                        \textbackslash times Powerset(Categories)\$
              \end{itemize}
        \item
              Sicherheitslabels, die die Sicherheitsempfindlichkeit von:

              \begin{itemize}
                  \item
                        Subjekte werden Freigaben genannt
                  \item
                        Objekte werden Klassifizierungen genannt
              \end{itemize}
        \item
              Ein wichtiges Konzept für die Spezifikation von Sicherheitspolitiken
              sind binäre Relationen auf der Menge der Kennzeichnungen:

              \begin{itemize}
                  \item
                        Eine binäre Relation auf einer Menge S ist eine Teilmenge des
                        Kreuzprodukts \$S\textbackslash times S\$
                  \item
                        Beispiel:

                        \begin{itemize}
                            \item
                                  Dominiert: \$Labels \textbackslash times Labels\$
                            \item
                                  Dominiert \$=\{(b1,b2) \textbar{} b1, b2 \textbackslash in Labels
                                  \textbackslash wedge level(b1) \textbackslash geq level(b2)
                                  \textbackslash wedge categories(b2) \textbackslash subseteq
                                  categories(b1)\}\$
                            \item
                                  Wenn \$(b1, b2) \textbackslash in Dominates\$, schreiben wir auch
                                  b1 dominates b
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Spezifikation der
        Sicherheitspolitik}

    \begin{itemize}
        \item
              Formale Ausdrücke für Regeln der Sicherheitspolitik:
        \item
              Betrachten Sie die folgenden Zuordnungen:

              \begin{itemize}
                  \item
                        \$allow: Subjects \textbackslash times Accesses \textbackslash times
                        Objects \textbackslash rightarrow boolean\$
                  \item
                        \$own: Subjects \textbackslash times Objects
                        \textbackslash rightarrow boolean\$
                  \item
                        \$admin: Subjects \textbackslash rightarrow boolean\$
                  \item
                        \$dominates: Labels \textbackslash times Labels
                        \textbackslash rightarrow boolean\$
              \end{itemize}
        \item
              Die oben genannten Zuordnungen können verwendet werden, um bekannte
              Sicherheitsrichtlinien zu spezifizieren:

              \begin{itemize}
                  \item
                        \$ownership: \textbackslash forall s \textbackslash in Subjects, o
                        \textbackslash in Objects, a \textbackslash in Accesses: allow(s, o,
                        a) \textbackslash Leftrightarrow own(s, o)\$
                  \item
                        \$own\_admin: \textbackslash forall s \textbackslash in Subjects, o
                        \textbackslash in Objects, a \textbackslash in Accesses: allow(s, o,
                        a) \textbackslash Leftrightarrow own(s, o) \textbackslash wedge
                        admin(s)\$
                  \item
                        \$dom: \textbackslash forall s \textbackslash in Subjects, o
                        \textbackslash in Objects, a \textbackslash in Accesses: allow(s, o,
                        a) \textbackslash Leftrightarrow dominates(label(s), label(o))\$
              \end{itemize}
        \item
              Die dom-Policy erfordert ein System zur Speicherung und Verarbeitung
              von Sicherheitskennzeichnungen für jede Entität, erlaubt aber
              komplexere Zugriffskontrollschemata als die ownership- und
              own\_admin-Policy
    \end{itemize}


    \subsection{Arten von
        Zugriffskontrollmechanismen}

    \begin{itemize}
        \item
              Ein Zugriffskontrollmechanismus ist eine konkrete Umsetzung des
              Referenzmonitor-Konzepts
        \item
              Es gibt zwei Haupttypen von Zugriffskontrollmechanismen:

              \begin{itemize}
                  \item
                        Diskretionäre Zugriffskontrolle umfasst diejenigen Verfahren und
                        Mechanismen, die die spezifizierte Vermittlung nach dem Ermessen der
                        einzelnen Benutzer durchsetzen

                        \begin{itemize}
                            \item
                                  Beispiel: Das Unix-Betriebssystem ermöglicht es den Benutzern, die
                                  Zugriffsrechte für Dateien, die ihnen gehören, zu erteilen oder zu
                                  entziehen (Lesen, Schreiben, Ausführen).
                        \end{itemize}
                  \item
                        Die obligatorische Zugriffskontrolle umfasst die Verfahren und
                        Mechanismen, die die angegebene Vermittlung nach dem Ermessen einer
                        zentralen Systemverwaltung durchsetzen.
              \end{itemize}
        \item
              Beide Arten können kombiniert werden, wobei die obligatorischen
              Zugriffskontrollentscheidungen in den meisten Fällen Vorrang vor den
              diskretionären Entscheidungen haben

              \begin{itemize}
                  \item
                        Beispiel:

                        \begin{itemize}
                            \item
                                  Verwendung einer diskretionären Zugangskontrolle auf
                                  Personalcomputern kombiniert mit einer obligatorischen
                                  Zugangskontrolle für die Kommunikation
                                  (\$\textbackslash rightarrow\$ Firewalls)
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Zugriffsmatrizen}

    \begin{itemize}
        \item
              Ein nützliches Konzept für die Beschreibung von
              Zugangskontrollmechanismen ist die Zugangsmatrix:

              \begin{itemize}
                  \item
                        In einer Zugriffsmatrix für zwei Mengen von Subjekten und Objekten
                        entspricht jede Zeile einem Subjekt und jede Spalte einem Objekt
                  \item
                        Jede Zelle der Matrix definiert die Zugriffsrechte des
                        entsprechenden Subjekts auf das entsprechende Objekt
              \end{itemize}
    \end{itemize}

    %\begin{longtable}[]{@{}lllll@{}}
    %    \toprule
    %              & Object 1 & Object 2 & ...             & Object M\tabularnewline
    %    \midrule
    %    \endhead
    %    Subject 1 &          &          & ...             & \tabularnewline
    %    Subject 2 &          &          & ...             & \tabularnewline
    %    ...       & ...      & ...      & (Access Rights) & \tabularnewline
    %    Subject N &          &          &                 & \tabularnewline
    %    \bottomrule
    %\end{longtable}


    \subsection{Gemeinsame
        Zugriffskontrollschemata}

    \begin{itemize}
        \item
              Zugriffskontroll-Listen (ACL):

              \begin{itemize}
                  \item
                        ACLs sind die Grundlage für ein Zugriffskontrollschema, bei dem für
                        jedes Objekt eine Liste gültiger Subjekte gespeichert wird, die
                        Zugriff auf dieses Objekt haben könnten (möglicherweise zusammen mit
                        der Art des erlaubten Zugriffs).
                  \item
                        ACLs werden in der Regel bei der diskretionären Zugriffskontrolle
                        verwendet, da es zu viele ACLs gibt, als dass sie von einer
                        zentralen Verwaltungseinrichtung verwaltet werden könnten.
              \end{itemize}
        \item
              Fähigkeiten:

              \begin{itemize}
                  \item
                        Capabilities sind gewissermaßen das Gegenkonzept zu ACLs, da bei
                        Capabilities jedes Subjekt eine Liste von Zugriffsrechten auf
                        Objekte besitzt
                  \item
                        Der Vorteil (und die Gefahr) von Capabilities ist, dass ein Subjekt
                        einige seiner Capabilities an andere Subjekte weitergeben kann
              \end{itemize}
        \item
              Label-basierte Zugriffskontrolle:

              \begin{itemize}
                  \item
                        Wenn Sicherheitslabels mit den Entitäten eines Systems gespeichert
                        und verarbeitet werden, können sie zur Durchführung einer
                        label-basierten Zugriffskontrolle verwendet werden
                  \item
                        Dieses Verfahren wird in der Regel als obligatorischer
                        Zugriffskontrollmechanismus verwendet.
              \end{itemize}
        \item
              \$\textbackslash rightarrow\$ Die Datenintegrität von
              Zugriffskontrolldatenstrukturen ist entscheidend!
    \end{itemize}


    \section{Integration von Sicherheitsdiensten in
      Kommunikationsarchitekturen}


    \subsection{Motivation: Was ist wo zu
        tun?}

    \begin{itemize}
        \item
              Analog zur Methodik der Sicherheitsanalyse gibt es zwei Dimensionen,
              die bei der Integration von Sicherheitsdiensten in
              Kommunikationsarchitekturen zu beachten sind:
        \item
              Dimension 1: Welcher Sicherheitsdienst soll in welchem Knoten
              realisiert werden?

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-Security-service-dim-1.png}
              \end{itemize}
        \item
              Dimension 2: Welcher Sicherheitsdienst sollte in welcher Schicht
              realisiert werden?

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-Security-service-dim-2.png}
              \end{itemize}
    \end{itemize}


    \subsection{Ein pragmatisches Modell für sicheres und vernetztes
        Rechnen}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-Sicheres-Netz-Modell.png}
        \item
              Anwendung:

              \begin{itemize}
                  \item
                        Ein Stück Software, das eine bestimmte Aufgabe erfüllt, z. B.
                        elektronische E-Mail, Webdienst, Textverarbeitung, Datenspeicherung
                        usw.
              \end{itemize}
        \item
              Endsystem:

              \begin{itemize}
                  \item
                        Ein Gerät, das vom Personal Computer über den Server bis zum
                        Großrechner reicht.
                  \item
                        Für Sicherheitszwecke hat ein Endsystem in der Regel eine einzige
                        Richtlinienautorität.
              \end{itemize}
        \item
              Teilnetz:

              \begin{itemize}
                  \item
                        Eine Sammlung von Kommunikationseinrichtungen, die unter der
                        Kontrolle einer Verwaltungsorganisation stehen, z. B. ein LAN, ein
                        Campusnetz, ein WAN usw.
                  \item
                        Für Sicherheitszwecke hat ein Teilnetz in der Regel eine
                        Richtlinienkompetenz.
              \end{itemize}
        \item
              Internet:

              \begin{itemize}
                  \item
                        Eine Sammlung von miteinander verbundenen Teilnetzen
                  \item
                        Im Allgemeinen haben die Teilnetze, die in einem Inter-Netzwerk
                        verbunden sind, unterschiedliche Richtlinienautoritäten
              \end{itemize}
        \item
              Es gibt vier Ebenen, auf denen unterschiedliche Anforderungen an
              Sicherheitsprotokollelemente gestellt werden:

              \begin{itemize}
                  \item
                        Anwendungsebene:

                        \begin{itemize}
                            \item
                                  Sicherheitsprotokollelemente, die anwendungsabhängig sind
                        \end{itemize}
                  \item
                        Endsystem-Ebene:

                        \begin{itemize}
                            \item
                                  Bereitstellung von Schutz auf einer Endsystem-zu-Endsystem-Basis
                        \end{itemize}
                  \item
                        Teilnetzebene:

                        \begin{itemize}
                            \item
                                  Bereitstellung von Schutz über ein Teilnetz oder ein Zwischennetz,
                                  das als weniger sicher gilt als andere Teile der Netzumgebung
                        \end{itemize}
                  \item
                        Verbindungsebene:

                        \begin{itemize}
                            \item
                                  Bereitstellung von Schutz innerhalb eines Teilnetzes, z. B. über
                                  eine Verbindung, die als weniger vertrauenswürdig gilt als andere
                                  Teile der Teilnetzumgebung
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Beziehungen zwischen Schichten und
        Anforderungsniveaus}

    \begin{itemize}
        \item
              Die Beziehungen zwischen den Protokollschichten und den Stufen der
              Sicherheitsanforderungen für die Protokollelemente sind nicht
              eins-zu-eins:

              \begin{itemize}
                  \item
                        Sicherheitsmechanismen, die sowohl die Anforderungen der Endsystem-
                        als auch der Teilnetzebene erfüllen, können entweder in der
                        Transport- und/oder in der Netzwerkschicht realisiert werden.
                  \item
                        Die Anforderungen der Verbindungsebene können durch die Integration
                        von Sicherheitsmechanismen oder durch die Verwendung von
                        ,,speziellen Funktionen'' der Verbindungsschicht und/oder der
                        physikalischen Schicht erfüllt werden.
                  \item
                        % \includegraphics{Assets/NetworkSecurity-Layer-relationship.png}
              \end{itemize}
    \end{itemize}


    \subsection{Allgemeine Überlegungen zur architektonischen
        Platzierung}

    \begin{itemize}
        \item
              Verkehrsvermischung:

              \begin{itemize}
                  \item
                        Infolge des Multiplexing besteht auf niedrigeren Ebenen eine größere
                        Tendenz, Datenelemente von verschiedenen Quell-/Ziel-Benutzern
                        und/oder Anwendungen in einem Datenstrom zu vermischen
                  \item
                        Ein Sicherheitsdienst, der auf einer Schicht/Ebene realisiert wird,
                        behandelt den Verkehr dieser Schicht/Ebene gleich, was zu einer
                        unzureichenden Kontrolle der Sicherheitsmechanismen für Benutzer und
                        Anwendungen führt.
                  \item
                        Wenn eine Sicherheitspolitik eine differenziertere Behandlung
                        erfordert, sollte sie besser auf einer höheren Ebene realisiert
                        werden
              \end{itemize}
        \item
              Wissen über die Route:

              \begin{itemize}
                  \item
                        Auf niedrigeren Ebenen ist in der Regel mehr Wissen über die
                        Sicherheitseigenschaften der verschiedenen Routen und Verbindungen
                        vorhanden.
                  \item
                        In Umgebungen, in denen diese Merkmale stark variieren, kann die
                        Platzierung von Sicherheit auf niedrigeren Ebenen Vorteile in Bezug
                        auf Effektivität und Effizienz haben
                  \item
                        Geeignete Sicherheitsdienste können auf der Basis von Teilnetzen
                        oder Verbindungen ausgewählt werden, so dass keine Kosten für
                        Sicherheit anfallen, wenn der Schutz unnötig ist.
              \end{itemize}
        \item
              Anzahl der Schutzpunkte:

              \begin{itemize}
                  \item
                        Wenn die Sicherheit auf der Anwendungsebene angesiedelt wird, muss
                        die Sicherheit in jeder sensiblen Anwendung und jedem Endsystem
                        implementiert werden.
                  \item
                        Sicherheit auf der Verbindungsebene bedeutet, dass am Ende jeder
                        Netzverbindung, die als weniger vertrauenswürdig gilt, Sicherheit
                        implementiert werden muss.
                  \item
                        Wenn die Sicherheit in der Mitte der Architektur angesiedelt wird,
                        müssen die Sicherheitsmerkmale an weniger Stellen installiert
                        werden.
              \end{itemize}
        \item
              Schutz der Protokoll-Header:

              \begin{itemize}
                  \item
                        Der Sicherheitsschutz auf höheren Ebenen kann die Protokollköpfe der
                        unteren Protokollschichten nicht schützen.
                  \item
                        Die Netzwerkinfrastruktur muss möglicherweise ebenfalls geschützt
                        werden.
              \end{itemize}
        \item
              Quelle/Senke-Bindung:

              \begin{itemize}
                  \item
                        Sicherheitsdienste wie die Authentifizierung der Datenherkunft und
                        die Unleugbarkeit hängen von der Zuordnung der Daten zu ihrer Quelle
                        oder Senke ab.
                  \item
                        Dies wird am effizientesten auf höheren Ebenen erreicht,
                        insbesondere auf der Anwendungsebene.
              \end{itemize}
    \end{itemize}


    \subsection{Überlegungen zu bestimmten
        Ebenen}

    \begin{itemize}
        \item
              Anwendungsebene:

              \begin{itemize}
                  \item
                        Diese Stufe kann die einzige geeignete Stufe sein, zum Beispiel
                        weil:

                        \begin{itemize}
                            \item
                                  Ein Sicherheitsdienst ist anwendungsspezifisch, z.B. die
                                  Zugriffskontrolle für einen vernetzten Dateispeicher
                            \item
                                  Ein Sicherheitsdienst muss Anwendungs-Gateways durchqueren, z.B.
                                  Integrität und/oder Vertraulichkeit von elektronischer Post
                            \item
                                  Die Semantik der Daten ist wichtig, z.B. für
                                  Nichtabstreitbarkeitsdienste - Es liegt außerhalb der Reichweite
                                  eines Benutzers/Anwendungsprogrammierers, Sicherheit auf einer
                                  niedrigeren Ebene zu integrieren
                        \end{itemize}
              \end{itemize}
        \item
              Endsystem-Ebene:

              \begin{itemize}
                  \item
                        Diese Ebene ist geeignet, wenn davon ausgegangen wird, dass die
                        Endsysteme vertrauenswürdig sind und das Kommunikationsnetz als
                        nicht vertrauenswürdig angesehen wird.
                  \item
                        Weitere Vorteile der Sicherheit auf Endsystemebene:

                        \begin{itemize}
                            \item
                                  Die Sicherheitsdienste sind für die Anwendungen transparent.
                            \item
                                  Die Verwaltung von Sicherheitsdiensten kann leichter in die Hände
                                  eines Systemadministrators gelegt werden.
                        \end{itemize}
              \end{itemize}
        \item
              Teilnetzebene:

              \begin{itemize}
                  \item
                        Auch wenn die auf dieser Ebene implementierte Sicherheit in der
                        gleichen Protokollschicht wie auf der Endsystemebene implementiert
                        werden kann, sollten diese nicht verwechselt werden:

                        \begin{itemize}
                            \item
                                  Mit der auf der Subnetzebene implementierten Sicherheit wird in
                                  der Regel der gleiche Schutz für alle Endsysteme dieses Subnetzes
                                  realisiert
                        \end{itemize}
                  \item
                        Es ist sehr üblich, dass ein Teilnetz in der Nähe eines Endsystems
                        als ebenso vertrauenswürdig angesehen wird, da es sich in denselben
                        Räumlichkeiten befindet und von denselben Behörden verwaltet wird.
                  \item
                        In den meisten Fällen gibt es weit weniger zu sichernde
                        Teilnetz-Gateways als Endsysteme.
              \end{itemize}
        \item
              Verbindungsebene:

              \begin{itemize}
                  \item
                        Wenn es relativ wenige nicht vertrauenswürdige Verbindungen gibt,
                        kann es ausreichend und zudem einfacher und kostengünstiger sein,
                        das Netz auf der Verbindungsebene zu schützen.
                  \item
                        Darüber hinaus können auf der Verbindungsebene spezielle
                        Schutztechniken eingesetzt werden, z. B. Spreizspektrum oder
                        Frequenzsprungverfahren.
                  \item
                        Die Vertraulichkeit des Verkehrsflusses erfordert in der Regel einen
                        Schutz auf Verbindungsebene.
              \end{itemize}
    \end{itemize}


    \subsection{Interaktionen zwischen menschlichen
        Nutzern}

    \begin{itemize}
        \item
              Einige Netzsicherheitsdienste beinhalten eine direkte Interaktion mit
              einem menschlichen Benutzer, der wichtigste davon ist die
              Authentifizierung.
        \item
              Solche Interaktionen passen in keine der bisher vorgestellten
              Architekturoptionen, da der Benutzer außerhalb der
              Kommunikationseinrichtungen steht.
        \item
              Die Kommunikation zur Unterstützung der Authentifizierung kann auf
              eine der folgenden Weisen erfolgen:

              \begin{itemize}
                  \item
                        Örtlich:

                        \begin{itemize}
                            \item
                                  Der menschliche Benutzer authentifiziert sich gegenüber dem
                                  lokalen Endsystem
                            \item
                                  Das Endsystem authentifiziert sich gegenüber dem entfernten
                                  Endsystem und teilt die Identität des Benutzers mit
                            \item
                                  Das entfernte System muss dem lokalen Endsystem vertrauen
                        \end{itemize}
                  \item
                        Unter Einbeziehung von Protokollelementen auf der Anwendungsschicht:

                        \begin{itemize}
                            \item
                                  Der Benutzer gibt einige Authentifizierungsinformationen an das
                                  lokale System weiter, die sicher an das entfernte System
                                  weitergeleitet werden
                        \end{itemize}
                  \item
                        Kombination der oben genannten Mittel:

                        \begin{itemize}
                            \item
                                  Beispiel: Kerberos
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Integration in untere Protokollschichten vs.
        Anwendungen}

    \begin{itemize}
        \item
              Vorteile der Integration von Sicherheitsdiensten in niedrigere
              Netzwerkschichten:

              \begin{itemize}
                  \item
                        Sicherheit:

                        \begin{itemize}
                            \item
                                  Auch das Netz selbst muss geschützt werden
                            \item
                                  Sicherheitsmechanismen, die in den Netzelementen (insbesondere in
                                  der Hardware) realisiert sind, sind für die Netznutzer oft
                                  schwerer angreifbar
                        \end{itemize}
                  \item
                        Anwendungsunabhängigkeit:

                        \begin{itemize}
                            \item
                                  Grundlegende Netzsicherheitsdienste müssen nicht in jede einzelne
                                  Anwendung integriert werden
                        \end{itemize}
                  \item
                        Dienstgüte (QoS):

                        \begin{itemize}
                            \item
                                  Die QoS-erhaltende Planung des Kommunikationssubsystems kann auch
                                  die Verschlüsselung nebeneinander bestehender Datenströme planen.
                            \item
                                  Beispiel: gleichzeitiger Sprachanruf und FTP-Übertragung
                        \end{itemize}
                  \item
                        Effizienz:

                        \begin{itemize}
                            \item
                                  Hardware-Unterstützung für rechenintensive Ver-/Entschlüsselung
                                  kann leichter in die Protokollverarbeitung integriert werden
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Integration in Endsysteme vs.
        Zwischensysteme}

    \begin{itemize}
        \item
              Integration in Endsysteme:

              \begin{itemize}
                  \item
                        Kann im Allgemeinen entweder auf der Anwendungs- oder der
                        Endsystemebene erfolgen
                  \item
                        In einigen speziellen Fällen kann auch ein Schutz auf
                        Verbindungsebene angebracht sein, z. B. bei der Verwendung eines
                        Modems zur Verbindung mit einem bestimmten Gerät
              \end{itemize}
        \item
              Integration in Zwischensysteme

              \begin{itemize}
                  \item
                        Kann auf allen vier Ebenen erfolgen:

                        \begin{itemize}
                            \item
                                  Anwendungs-/,,Endsystem"-Ebene: zur Sicherung der
                                  Verwaltungsschnittstellen von Zwischenknoten, nicht zur Sicherung
                                  des Nutzdatenverkehrs
                            \item
                                  Teilnetz-/Link-Ebene: zur Sicherung des Nutzdatenverkehrs
                        \end{itemize}
              \end{itemize}
        \item
              Je nach den Sicherheitszielen kann eine Integration sowohl in
              Endsystemen als auch in Zwischensystemen sinnvoll sein
    \end{itemize}


    \subsection{Beispiel: Authentifizierungsbeziehungen in
        Inter-Netzwerken}

    % \includegraphics{Assets/NetworkSecurity-Authentication-relation-in-inter-networks.png}

    %\begin{longtable}[]{@{}ll@{}}
    %    \toprule
    %    Authentication Relation                                            & Application for securing\tabularnewline
    %    \midrule
    %    \endhead
    %    Endsystem \$\textbackslash leftrightarrow\$ Endsystem              & User
    %    Channels\tabularnewline
    %    Endsystem \$\textbackslash leftrightarrow\$ Intermediate System    &
    %    Management Interfaces, Accounting\tabularnewline
    %    Intermediate \$\textbackslash leftrightarrow\$ Intermediate System &
    %    Network Operation: Signaling, Routing, Accounting, ...\tabularnewline
    %    \bottomrule
    %\end{longtable}


    \subsection{Schlussfolgerung}

    \begin{itemize}
        \item
              Die Integration von Sicherheitsdiensten in Kommunikationsarchitekturen
              wird von zwei Hauptfragen geleitet:

              \begin{itemize}
                  \item
                        Welcher Sicherheitsdienst in welchem Knoten?
                  \item
                        Welcher Sicherheitsdienst in welcher Schicht?
              \end{itemize}
        \item
              Diese Design-Entscheidungen können auch durch einen Blick auf ein
              pragmatisches Modell der vernetzten Datenverarbeitung geleitet werden,
              das vier verschiedene Ebenen unterscheidet, auf denen
              Sicherheitsdienste realisiert werden können:

              \begin{itemize}
                  \item
                        Anwendungs-/Endsystem-/Subnetz-/Link-Ebene
              \end{itemize}
        \item
              Da es verschiedene Gründe für und gegen jede Option gibt, gibt es
              keine einheitliche Lösung für dieses Designproblem.
        \item
              In diesem Kurs werden wir daher einige Beispiele für die Integration
              von Sicherheitsdiensten in Netzarchitekturen untersuchen, um die
              Auswirkungen der getroffenen Designentscheidungen besser zu verstehen
    \end{itemize}


    \section{Sicherheitsprotokolle der
      Datenübertragungsschicht}

    \begin{itemize}
        \item
              IEEE 802.1Q, IEEE 802.1X \& IEEE 802.1AE
        \item
              Point-to-Point Protocol (PPP)
        \item
              Point-to-Point Tunneling Protocol (PPTP)
        \item
              Layer 2 Tunneling Protocol (L2TP)
        \item
              Virtual Private Networks (VPN)
    \end{itemize}


    \subsection{Anwendungsbereich von Sicherheitsprotokollen der
        Verbindungsschicht}

    \begin{itemize}
        \item
              Nach dem klassischen Verständnis des OSI-Modells stellt die
              Verbindungsschicht einen gesicherten Datenübertragungsdienst zwischen
              zwei gleichrangigen Einheiten bereit, die direkt über ein
              Kommunikationsmedium miteinander verbunden sind.
        \item
              Ihre Hauptaufgaben sind:

              \begin{itemize}
                  \item
                        Fehlererkennung und -korrektur
                  \item
                        Medium Access Control (MAC, nicht zu verwechseln mit Message
                        Authentication Code) für gemeinsam genutzte Medien, z. B. Ethernet
                        usw.
              \end{itemize}
        \item
              Nicht alle heutigen Netzwerktechnologien passen in dieses Modell:

              \begin{itemize}
                  \item
                        Einwahlverbindungen zu einem Internetdienstanbieter
                  \item
                        Lösungen für virtuelle private Netzwerke (VPN)
              \end{itemize}
        \item
              In diesem Kurs geben wir uns mit der folgenden Definition zufrieden:

              \begin{itemize}
                  \item
                        Der Zweck eines Link-Layer-Sicherheitsprotokolls besteht darin,
                        bestimmte Sicherheitseigenschaften der Link-Layer-PDUs zu
                        gewährleisten, d. h. der PDUs der Protokollschicht, die die PDUs der
                        Netzwerkschicht (z. B. IP) tragen.
              \end{itemize}
    \end{itemize}


    \subsection{IEEE 802.1}


    \subsubsection{Die IEEE 802.1 Standardfamilie: Hintergrund und
        Ziele}

    \begin{itemize}
        \item
              Das Institute of Electrical and Electronics Engineers (IEEE) 802
              LAN/MAN Standards Committee entwickelt Standards für lokale Netzwerke
              und Metropolitan Area Networks.
        \item
              Die am weitesten verbreiteten Standards sind:

              \begin{itemize}
                  \item
                        Ethernet-Familie (802.3, allgemein als CSMA/CD bezeichnet),
                  \item
                        Drahtloses LAN (802.11)
                  \item
                        WIMAX (802.16)
              \end{itemize}
        \item
              Die IEEE 802.1-Standards:

              \begin{itemize}
                  \item
                        Können mit verschiedenen IEEE 802.x Technologien verwendet werden
                  \item
                        Definieren unter anderem verschiedene explizite Sicherheitsdienste
                        oder Dienste, die zur Erreichung von Sicherheitszielen verwendet
                        werden können
              \end{itemize}
    \end{itemize}


    \subsubsection{IEEE 802.1Q}

    Ziele und Dienste

    \begin{itemize}
        \item
              Der Standard IEEE 802.1Q:

              \begin{itemize}
                  \item
                        Ermöglicht die Schaffung von ,,miteinander verbundenen
                        IEEE-802-Standard-LANs mit unterschiedlichen oder identischen
                        Methoden der Medienzugriffskontrolle'', d. h. die Schaffung
                        separater virtueller lokaler Netzwerke (VLANs) über eine physische
                        Infrastruktur
                  \item
                        Obwohl es sich nicht um einen echten Sicherheitsstandard handelt,
                        wird er häufig verwendet, um verschiedene Benutzer und Dienste
                        voneinander zu trennen, z. B. nicht vertrauenswürdige Gastcomputer
                        von Unternehmensservern, ohne eine neue Infrastruktur einzurichten
                  \item
                        Wird verwendet, um Zugangskontrolle auf Verbindungsebene zu
                        realisieren
              \end{itemize}
    \end{itemize}

    Grundlegende Funktionsweise

    \begin{itemize}
        \item
              Jedes Netzwerkpaket wird mit einem VLAN-Tag versehen, der eine
              12-Bit-VLAN-ID enthält, die ein virtuelles Netzwerk identifiziert
        \item
              Switches stellen sicher, dass Pakete mit bestimmten VLAN-IDs nur an
              bestimmte Netzwerk-Ports zugestellt werden, z.B. wird ein VLAN mit
              internen Firmeninformationen nicht an einen öffentlich zugänglichen
              Port zugestellt
        \item
              Die VLAN-ID ist nicht kryptografisch geschützt!

              \begin{itemize}
                  \item
                        VLAN IDs müssen auf andere Weise, d.h. physikalisch, gesichert
                        werden!
                  \item
                        Normalerweise werden VLAN-IDs am ersten vertrauenswürdigen Switch
                        eingefügt und am letzten vertrauenswürdigen Switch auf dem Weg durch
                        das Netzwerk entfernt
              \end{itemize}
    \end{itemize}

    Typisches Einführungsszenario

    \begin{itemize}
        \item
              Normalerweise wird das vertrauenswürdige innere Netzwerk durch
              physische Mittel geschützt
        \item
              Verschiedene Ports zum vertrauenswürdigen Kern werden VLANs zugeordnet
        \item
              VLANs sind virtuell verbunden, dürfen aber nicht auf andere VLANs
              zugreifen
        \item
              VLANs werden normalerweise gekoppelt durch

              \begin{itemize}
                  \item
                        Router, die mehrere Schnittstellen in den verschiedenen VLANs haben
                  \item
                        Router, die selbst zum vertrauenswürdigen Netzwerk gehören und
                        selbst getaggte Frames empfangen und senden können (kann gefährlich
                        sein, Wechselwirkung zwischen Routing und VLANs, siehe unten)
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-ieee802.1q-scenario.png}
    \end{itemize}

    Weitere Diskussion

    \begin{itemize}
        \item
              802.1Q ermöglicht eine einfache Trennung verschiedener
              Sicherheitsdomänen innerhalb eines vertrauenswürdigen Netzwerks

              \begin{itemize}
                  \item
                        Ermöglicht auch die Priorisierung bestimmter VLANs (z. B. um die
                        Verwaltung von Geräten zu ermöglichen, wenn der Rest des Netzes von
                        einem Angreifer überflutet wird)
                  \item
                        VLAN-Tags können gestapelt werden, z. B. um verschiedene Kunden zu
                        trennen, die eigene VLANs einrichten
              \end{itemize}
        \item
              Diskussion über die Sicherheit:

              \begin{itemize}
                  \item
                        Die Sicherheit hängt davon ab, dass kein einziges Gerät in der
                        vertrauenswürdigen Domäne kompromittiert wird!
                  \item
                        Alle Switches müssen korrekt konfiguriert sein, d.h. kein einziger
                        Switch darf eingehenden Verkehr aus einem nicht vertrauenswürdigen
                        Netz zulassen, der bereits getaggt ist
                  \item
                        Paketfluten in einem VLAN können sich auch auf andere VLANs
                        auswirken
                  \item
                        Router, die an mehreren VLANs teilnehmen, können auf einer
                        Schnittstelle Pakete aus verschiedenen VLANs empfangen, aber
                  \item
                        Anstatt ein striktes Routing zu einer anderen Schnittstelle (z. B.
                        dem Internet) durchzuführen, könnte ein Angreifer diesen Router
                        nutzen, um über dieselbe Schnittstelle zurück in ein anderes VLAN zu
                        routen (sogenannter Layer-2-Proxy-Angriff)
                  \item
                        Kann sogar funktionieren, wenn VLAN 1 und VLAN 2 das gleiche
                        IP-Subnetz nutzen!
              \end{itemize}
    \end{itemize}


    \subsubsection{IEEE 802.1X}

    Ziele

    \begin{itemize}
        \item
              Der Standard IEEE 802.1X:

              \begin{itemize}
                  \item
                        Ziel ist es, ,,den Zugang zu den von einem LAN angebotenen Diensten
                        auf diejenigen Benutzer und Geräte zu beschränken, die diese Dienste
                        nutzen dürfen''
              \end{itemize}
        \item
              Definiert eine portbasierte Netzwerkzugriffskontrolle, um ein Mittel
              zur ,,Authentifizierung und Autorisierung von Geräten bereitzustellen,
              die an einen LAN-Port mit Punkt-zu-Punkt-Verbindungseigenschaften
              angeschlossen sind''.
    \end{itemize}

    Kontrollierte und unkontrollierte Ports

    \begin{itemize}
        \item
              IEEE 802.1X führt den Begriff der zwei logischen Ports ein:

              \begin{itemize}
                  \item
                        Der unkontrollierte Port ermöglicht die Authentifizierung eines
                        Geräts
                  \item
                        Der kontrollierte Port ermöglicht es einem authentifizierten Gerät,
                        auf LAN-Dienste zuzugreifen
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-ieee802.1X-ports.png}
    \end{itemize}

    Rollen

    \begin{itemize}
        \item
              Es werden drei Hauptrollen unterschieden:

              \begin{itemize}
                  \item
                        Ein Gerät, das den von einem IEEE 802.1X LAN angebotenen Dienst
                        nutzen möchte, agiert als Supplicant, der den Zugriff auf den
                        kontrollierten Port anfordert
                  \item
                        Der Anschlusspunkt an die LAN-Infrastruktur (z. B. eine MAC-Brücke)
                        fungiert als Authentifikator, der den Supplicant auffordert, sich zu
                        authentifizieren.
                  \item
                        Der Authentifikator prüft die vom Antragsteller vorgelegten
                        Anmeldeinformationen nicht selbst, sondern leitet sie zur
                        Überprüfung an seinen Authentifizierungsserver weiter.
              \end{itemize}
        \item
              Zugriff auf ein LAN mit IEEE 802.1X Sicherheitsmaßnahmen:

              \begin{itemize}
                  \item
                        Vor einer erfolgreichen Authentifizierung kann der Antragsteller auf
                        den unkontrollierten Port zugreifen:

                        \begin{itemize}
                            \item
                                  Der Port ist unkontrolliert in dem Sinne, dass er den Zugriff vor
                                  der Authentifizierung erlaubt.
                            \item
                                  Dieser Port erlaubt jedoch nur einen eingeschränkten Zugriff
                        \end{itemize}
                  \item
                        Die Authentifizierung kann durch den Supplicant oder den
                        Authenticator initiiert werden.
                  \item
                        Nach erfolgreicher Authentifizierung wird der kontrollierte Port
                        geöffnet.
              \end{itemize}
    \end{itemize}

    Sicherheitsprotokolle und Nachrichtenaustausch

    \begin{itemize}
        \item
              IEEE 802.1X definiert keine eigenen Sicherheitsprotokolle, sondern
              befürwortet die Verwendung bestehender Protokolle:

              \begin{itemize}
                  \item
                        Das Extensible Authentication Protocol (EAP) kann eine grundlegende
                        Geräteauthentifizierung realisieren {[}RFC 3748{]}.
                  \item
                        Wenn die Aushandlung eines Sitzungsschlüssels während der
                        Authentifizierung erforderlich ist, wird die Verwendung des EAP TLS
                        Authentication Protocol empfohlen {[}RFC 5216{]}.
                  \item
                        Außerdem wird empfohlen, den Authentifizierungsserver mit dem Remote
                        Authentication Dial In User Service (RADIUS) {[}RFC 2865{]} zu
                        realisieren.
              \end{itemize}
        \item
              Der Austausch von EAP Nachrichten zwischen Supplicant und
              Authenticator wird mit dem EAP over LANs (EAPOL) Protokoll realisiert:

              \begin{itemize}
                  \item
                        EAPOL definiert die Verkapselungstechniken, die verwendet werden
                        sollen, um EAP-Pakete zwischen Supplicant Port Access Entities (PAE)
                        und Authenticator PAEs in einer LAN-Umgebung zu übertragen.
                  \item
                        EAPOL-Rahmenformate wurden für verschiedene Mitglieder der
                        802.x-Protokollfamilie definiert, z. B. EAPOL für Ethernet, ...
                  \item
                        Zwischen Supplicant und Authenticator können RADIUS-Nachrichten
                        verwendet werden
              \end{itemize}
    \end{itemize}

    Beispiel für eine
    802.1X-Authentifizierung{]}(Assets/NetworkSecurity-ieee802.1X-example.png)


    \subsubsection{IEEE 802.1AE}

    Ziele

    \begin{itemize}
        \item
              Der Standard IEEE 802.1AE wird auch als MAC-Sicherheit (MACsec)
              bezeichnet:

              \begin{itemize}
                  \item
                        Ermöglicht autorisierten Systemen, die sich an LANs in einem
                        Netzwerk anschließen und diese miteinander verbinden, die
                        Vertraulichkeit der übertragenen Daten zu wahren und Maßnahmen gegen
                        Frames zu ergreifen, die von nicht autorisierten Geräten übertragen
                        oder verändert werden. ''
                  \item
                        Schützt Pakete durch kryptografische Mittel zwischen Geräten, z. B.
                        zwischen Switches oder einem Computer und einem Switch
                  \item
                        Setzt eine gültige Authentifizierung voraus und ist somit eine
                        Erweiterung von 802.1X
                  \item
                        Kryptografische Schlüssel werden auch während der
                        802.1X-Authentifizierungsphase abgeleitet
                  \item
                        Kann Datenursprungsauthentifizierung und optional Vertraulichkeit
                        durchführen
                  \item
                        Unterstützt AES-128 und AES-256 in GCM, wobei die Unterstützung von
                        AES-128-GCM obligatorisch ist!
              \end{itemize}
    \end{itemize}

    Frame-Format

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-ieee802.1AE-frame.png}
        \item
              Quell- und Zieladressen werden im Klartext gesendet
        \item
              VLAN-Tag, Typfeld und Nutzdaten werden ebenfalls verschlüsselt
        \item
              Ein neuer 8-16 Byte langer SecTAG wird eingefügt

              \begin{itemize}
                  \item
                        Beginnt mit 0x88e5, um ein Protokoll für ältere Geräte zu emulieren
                  \item
                        Enthält einen 4-Byte-Paketzähler (wird als IV verwendet, auch um
                        Replay-Angriffe abzuwehren)
              \end{itemize}
        \item
              FCS wird durch einen kryptografischen MAC von 8-16 Byte ersetzt und
              von MACsec berechnet, optional kann ein zusätzlicher CRC-FCS für
              ältere Geräte hinzugefügt werden
    \end{itemize}

    Diskussion über Sicherheit

    \begin{itemize}
        \item
              MACsec erlaubt es, Verbindungen zu sichern, z.B. zwischen Gebäuden auf
              einem Campus
        \item
              Es bietet keinen Schutz gegen kompromittierte Geräte!

              \begin{itemize}
                  \item
                        Wenn es in Kombination mit 802.1Q verwendet wird, kann die
                        vertrauenswürdige Computerbasis immer noch ziemlich groß sein...
                  \item
                        Die Verwendung des GCM unterliegt den in Kapitel 5 beschriebenen
                        potenziellen Problemen
                  \item
                        Derzeit unterstützen nur hochwertige Switches MACsec!
              \end{itemize}
    \end{itemize}


    \subsection{Punkt-zu-Punkt-Protokoll}

    Zweck und Aufgaben

    \begin{itemize}
        \item
              Große Teile des Internets beruhen auf Punkt-zu-Punkt-Verbindungen:

              \begin{itemize}
                  \item
                        Wide Area Network (WAN)-Verbindungen zwischen Routern
                  \item
                        Einwahlverbindungen von Hosts über Modems und Telefonleitungen
              \end{itemize}
        \item
              Protokolle für diesen Zweck:

              \begin{itemize}
                  \item
                        Serial Line IP (SLIP): keine Fehlererkennung, unterstützt nur IP,
                        keine dynamische Adressvergabe, keine Authentifizierung {[}RFC
                        1055{]}
                  \item
                        Point-to-Point Protocol (PPP): Nachfolger von SLIP, unterstützt IP,
                        IPX, ...
                  \item
                        % \includegraphics{Assets/NetworkSecurity-Point-to-Point.png}
              \end{itemize}
        \item
              PPP {[}RFC 1661/1662{]}

              \begin{itemize}
                  \item
                        Schicht-2-Rahmenformat mit Rahmenbegrenzung und Fehlererkennung
                  \item
                        Kontrollprotokoll (Link Control Protocol, LCP) für
                        Verbindungsaufbau, -test, -aushandlung und -abbau
                  \item
                        Separate Netzwerkkontrollprotokolle (NCP) für unterstützte
                        Schicht-3-Protokolle
              \end{itemize}
    \end{itemize}

    Packet Format

    \begin{itemize}
        \item
              Zeichenorientierte (statt bitorientierte)
              \$\textbackslash Rightarrow\$ byteausgerichtete Rahmen
        \item
              Code-Transparenz wird durch Zeichenstuffing erreicht
        \item
              Normalerweise werden nur unnummerierte Frames übertragen, in Szenarien
              mit hoher Fehlerwahrscheinlichkeit (drahtlose Kommunikation) kann
              jedoch ein zuverlässigerer Modus mit Sequenznummern und erneuten
              Übertragungen ausgehandelt werden
        \item
              Unterstützte Protokolle für das Nutzdatenfeld sind u.a.: IP, IPX,
              Appletalk
        \item
              Wenn nicht anders ausgehandelt, beträgt die maximale Nutzdatengröße
              1500 Byte.
        \item
              Zusätzliche Aushandlung unterstützt kleinere Paketköpfe
        \item
              % \includegraphics{Assets/NetworkSecurity-Punkt-zu-Punkt-Format.png}
    \end{itemize}

    Eine typische PPP-Verbindung

    \begin{itemize}
        \item
              Nutzungsszenario ,,Internetzugang eines PCs über Modem'':

              \begin{itemize}
                  \item
                        Der Benutzer ruft den Internet Service Provider (ISP) über ein Modem
                        an und stellt eine ,,physikalische'' Verbindung über den ,,Plain Old
                        Telephone Service'' (POTS) her.
                  \item
                        Anrufer sendet mehrere LCP-Pakete in PPP-Frames, um die gewünschten
                        PPP-Parameter auszuwählen
                  \item
                        Sicherheitsspezifische Aushandlung (siehe unten)
                  \item
                        Austausch von NCP-Paketen zur Konfiguration der Netzwerkschicht:

                        \begin{itemize}
                            \item
                                  z.B. Konfiguration von IP einschließlich dynamischer Zuweisung
                                  einer IP-Adresse über Dynamic Host Configuration Protocol (DHCP)
                        \end{itemize}
                  \item
                        Der Anrufer kann wie jeder andere Host mit einer festen Verbindung
                        zum Internet beliebige Internetdienste nutzen
                  \item
                        Beim Verbindungsabbau werden die zugewiesene IP-Adresse und die
                        Netzschichtverbindung freigegeben
                  \item
                        Die Schicht-2-Verbindung wird über LCP freigegeben und das Modem
                        baut die ,,physikalische'' Verbindung ab
              \end{itemize}
    \end{itemize}

    Link Control Protocol

    \begin{itemize}
        \item
              Rahmenformat des Link Control Protocol (LCP):

              \begin{itemize}
                  \item
                        Code: configure-request, configure-ack, configure-nack,
                        configure-reject, terminate-request, terminate-ack, code-reject,
                        protocol-reject, echo-request, echo-reply, discard-request
                  \item
                        Länge: gibt die Länge des LCP-Pakets einschließlich des Codefelds
                        usw. an
                  \item
                        Daten: null oder mehr Oktette befehlsspezifischer Daten
                  \item
                        % \includegraphics{Assets/NetworkSecurity-Point-to-Point-LCP.png}
              \end{itemize}
        \item
              Die Konfigurationsprimitive von LCP ermöglichen die Konfiguration der
              Verbindungsschicht:

              \begin{itemize}
                  \item
                        Es gibt verschiedene Optionen für dieses Primitiv zur Konfiguration
                        verschiedener Aspekte (max. Empfangseinheit, Protokollkompression,
                        Authentifizierung, ...)
              \end{itemize}
    \end{itemize}

    Sicherheitsdienste

    \begin{itemize}
        \item
              Die ursprüngliche Version von PPP {[}RFC 1661{]} schlägt die optionale
              Ausführung eines Authentifizierungsprotokolls nach der
              Verbindungsaufbauphase vor:

              \begin{itemize}
                  \item
                        Falls erforderlich, wird die Authentifizierung von einer
                        Peer-Entität über einen LCP Configuration-Request am Ende der
                        Verbindungsaufbauphase gefordert
                  \item
                        Ursprünglich sind zwei Authentifizierungsprotokolle definiert
                        worden:

                        \begin{itemize}
                            \item
                                  Passwort-Authentifizierungsprotokoll (PAP)
                            \item
                                  Challenge-Handshake-Authentifizierungsprotokoll (CHAP)
                        \end{itemize}
                  \item
                        Inzwischen ist ein erweiterbares Protokoll definiert worden:

                        \begin{itemize}
                            \item
                                  Erweiterbares Authentifizierungsprotokoll (EAP)
                            \item
                                  PPP EAP Transport Level Security Protocol (PPP-EAP-TLS)
                        \end{itemize}
              \end{itemize}
        \item
              Außerdem kann nach der Authentifizierung eine Verschlüsselung
              ausgehandelt werden:

              \begin{itemize}
                  \item
                        Protokolle:

                        \begin{itemize}
                            \item
                                  Encryption Control Protocol (ECP) zur Aushandlung
                            \item
                                  PPP DES-Verschlüsselungsprotokoll (DESE)
                            \item
                                  PPP-Dreifach-DES-Verschlüsselungsprotokoll (3DESE)
                        \end{itemize}
              \end{itemize}
    \end{itemize}

    Authentifizierungsprotokolle

    \begin{itemize}
        \item
              Passwort-Authentifizierungs-Protokoll (PAP):

              \begin{itemize}
                  \item
                        PAP wurde 1992 in RFC 1334 definiert.
                  \item
                        Das Protokoll ist sehr einfach:

                        \begin{itemize}
                            \item
                                  Voraussetzung: der Authentifikator kennt das Passwort der
                                  Peer-Entität
                            \item
                                  Am Ende der Verbindungsaufbauphase fordert eine Entität,
                                  Authenticator genannt, die Peer-Entität auf, sich mit PAP zu
                                  authentifizieren
                            \item
                                  Die Peer-Entität sendet eine Authenticate-Request-Nachricht mit
                                  ihrer Peer-ID und ihrem Passwort
                            \item
                                  Der Authentifikator prüft, ob die bereitgestellten Informationen
                                  korrekt sind und antwortet entweder mit einem Authenticate-ack
                                  oder einem Authenticate-nack
                        \end{itemize}
                  \item
                        Da das Protokoll keinen kryptographischen Schutz bietet, ist es
                        unsicher.
                  \item
                        PAP wird in den aktualisierten RFCs für die PPP-Authentifizierung
                        nicht erwähnt {[}RFC1994{]}.
              \end{itemize}
        \item
              Challenge Handshake Authentication Protocol (CHAP):

              \begin{itemize}
                  \item
                        CHAP ist ebenfalls in RFC 1334 und RFC 1994 definiert.
                  \item
                        Es verwirklicht ein einfaches Challenge-Response-Protokoll:

                        \begin{itemize}
                            \item
                                  Voraussetzung: Authentifikator und Peer-Entität teilen ein
                                  Geheimnis
                            \item
                                  Nach der Verbindungsaufbauphase sendet der Authentifikator (A)
                                  eine Challenge-Nachricht, die einen Identifikator für diese
                                  Challenge, eine Zufallszahl \$r\_A\$ und seinen Namen enthält, an
                                  die Peer-Entität (B): \$A \textbackslash rightarrow B: (1,
                                  Identifikator, r\_A, A)\$
                            \item
                                  Die Peer-Entität berechnet eine kryptografische Hash-Funktion über
                                  ihren Namen, das gemeinsame Geheimnis \$K\_\{A,B\}\$ und die
                                  Zufallszahl \$r\_A\$ und sendet die folgende Nachricht: \$B
                                  \textbackslash rightarrow A: (2, Kennung, H(B, K\_\{A,B\}, r\_A),
                                  B)\$
                            \item
                                  Beim Empfang dieser Nachricht berechnet der Authentifikator den
                                  Hashwert neu und vergleicht ihn mit dem empfangenen Wert; wenn
                                  beide Werte übereinstimmen, antwortet er mit einer Erfolgsmeldung
                            \item
                                  RFC 1994 legt fest, dass MD5 als Hash-Funktion unterstützt werden
                                  muss, aber die Verwendung anderer Hash-Funktionen kann
                                  ausgehandelt werden
                        \end{itemize}
              \end{itemize}
        \item
              CHAP-Nachrichtenformat:

              \begin{itemize}
                  \item
                        Code: 1 \textasciitilde{} Herausforderung / 2 \textasciitilde{}
                        Antwort / 3 \textasciitilde{} Erfolg / 4 \textasciitilde{} Fehler
                  \item
                        Identifier: ein Oktett, das bei jeder gesendeten Challenge geändert
                        werden muss
                  \item
                        Länge: die Gesamtlänge der CHAP-Nachricht in Oktetten
                  \item
                        Value Size: ein Oktett, das die Länge des Wertes angibt
                  \item
                        Wert: enthält die zufällige Herausforderung / die Antwort auf die
                        Herausforderung
                  \item
                        Name: ein oder mehrere Oktette, die das System identifizieren, das
                        das Paket erstellt hat; die Größe des Namens wird anhand des
                        Längenfeldes berechnet
                  \item
                        % \includegraphics{Assets/NetworkSecurity-Point-to-Point-CHAP1.png}
                  \item
                        Nachricht:

                        \begin{itemize}
                            \item
                                  Null oder mehr Oktette mit implementierungsabhängigem Inhalt
                            \item
                                  Der Inhalt soll für den Menschen lesbar sein und hat keinen
                                  Einfluss auf die Funktionsweise des Protokolls
                        \end{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-Point-to-Point-CHAP2.png}
              \end{itemize}
        \item
              Erweiterbares Authentifizierungsprotokoll (EAP):

              \begin{itemize}
                  \item
                        EAP ist ein allgemeines Protokoll für die PPP-Authentifizierung, das
                        mehrere Authentifizierungsmethoden unterstützt {[}RFC2284{]}.
                  \item
                        Die Hauptidee hinter EAP ist es, ein gemeinsames Protokoll
                        bereitzustellen, um komplexere Authentifizierungsmethoden als ,,1
                        Frage + 1 Antwort'' durchzuführen.
                  \item
                        Das Protokoll bietet grundlegende Primitive:

                        \begin{itemize}
                            \item
                                  Anfrage, Antwort: weiter verfeinert durch Typfeld + typspezifische
                                  Daten
                            \item
                                  Success, Failure: zur Angabe des Ergebnisses eines
                                  Authentifizierungsaustauschs
                        \end{itemize}
                  \item
                        Typ-Felder:

                        \begin{itemize}
                            \item
                                  Identität
                            \item
                                  Benachrichtigung
                            \item
                                  Nak (nur Antwort, zur Beantwortung inakzeptabler Anfragetypen)
                            \item
                                  MD5 Challenge (dies entspricht CHAP)
                            \item
                                  One-Time Password (OTP): definiert in {[}RFC2289{]}
                            \item
                                  Generische Token-Karte
                            \item
                                  EAP-TLS
                        \end{itemize}
              \end{itemize}
        \item
              Einmaliges Kennwort (One-Time Password, OTP):

              \begin{itemize}
                  \item
                        Die Grundidee von OTP besteht darin, ein ,,Passwort'' zu
                        übermitteln, das nur für einen Durchlauf eines
                        Authentifizierungsdialogs verwendet werden kann
                  \item
                        Erstmalige Einrichtung:

                        \begin{itemize}
                            \item
                                  Der Authentifikator A sendet einen Seed-Wert rA und die
                                  Peer-Entität B verkettet diesen mit seinem Passwort und berechnet
                                  einen Hash-Wert: \$PW\_N = H\^{}N(r\_A, password\_B)\$
                            \item
                                  Das Paar \$(N, PW\_N)\$ wird ,,sicher'' an den Authentifikator
                                  übertragen und beim Authentifikator gespeichert.
                        \end{itemize}
                  \item
                        Dialog zur Authentifizierung:

                        \begin{itemize}
                            \item
                                  \$A\textbackslash rightarrow B: N - 1\$
                            \item
                                  \$B\textbackslash rightarrow A: PW\_\{N-1\} := H\^{}\{N-1\}(r\_A,
                                  Passwort\_B)\$
                            \item
                                  A prüft, ob \$H(PW\_\{N-1\}) = PW\_N\$, und speichert \$(N-1,
                                  PW\_\{N-1\})\$ als neue Authentifizierungsinformation für B
                        \end{itemize}
                  \item
                        Sicherheit: Um dieses Verfahren zu brechen, müsste ein Angreifer ein
                        PWN abhören und \$H\^{}\{-1\}(PW\_N)\$ berechnen, was unpraktisch
                        ist.
              \end{itemize}
        \item
              Generische Token-Karte:

              \begin{itemize}
                  \item
                        Im Grunde ein Challenge-Response-Dialog
                  \item
                        Eine Token-Karte wird verwendet, um eine Antwort auf eine
                        Herausforderung zu berechnen:

                        \begin{itemize}
                            \item
                                  Die Herausforderung wird dem Benutzer präsentiert, der sie in sein
                                  Token-Card-Gerät eintippen muss.
                            \item
                                  Die Token-Karte berechnet die Antwort und zeigt sie an.
                            \item
                                  Der Benutzer gibt die Antwort in das System ein, das sie als
                                  Antwort auf die Aufforderungsnachricht sendet.
                        \end{itemize}
              \end{itemize}
        \item
              PPP-EAP-TLS:

              \begin{itemize}
                  \item
                        TLS steht für Transport Layer Security {[}RFC 2246{]}.
                  \item
                        Es wird also der Authentifizierungsdialog von TLS ausgeführt
                  \item
                        Dieser Dialog wird in Kapitel 12 über die Sicherheit der
                        Transportschicht im Detail erläutert.
              \end{itemize}
    \end{itemize}

    Verschlüsselungsprotokolle

    \begin{itemize}
        \item
              Nach dem Verbindungsaufbau und der Authentifizierungsphase kann die
              Verschlüsselung für eine PPP-Verbindung ausgehandelt werden:

              \begin{itemize}
                  \item
                        Das Encryption Control Protocol (ECP) {[}RFC1968{]} ist für die
                        Konfiguration und Aktivierung von Datenverschlüsselungsalgorithmen
                        an beiden Enden der PPP-Verbindung zuständig:

                        \begin{itemize}
                            \item
                                  ECP verwendet das gleiche Rahmenformat wie LCP und führt zwei neue
                                  Primitive ein: Reset-Request und Reset-Ack zur Anzeige von
                                  Entschlüsselungsfehlern unabhängig für jede Richtung (nützlich für
                                  die kryptographische Resynchronisation)
                            \item
                                  Eine bestimmte Verschlüsselungsmethode wird mit dem
                                  configure-Primitiv ausgehandelt, das eine Option zur Angabe von
                                  DESE, 3DESE, Proprietär usw. enthält.
                            \item
                                  Proprietäre Verschlüsselungsprotokolle werden durch einen
                                  registrierten OUI (Organizational Unit Identifier) + einen
                                  herstellerspezifischen Wert identifiziert.
                            \item
                                  Genau ein ECP-Paket wird im PPP-Informationsfeld eines
                                  Link-Layer-Pakets transportiert
                            \item
                                  ECP-Pakete werden durch das PPP-Protokollfeld identifiziert:

                                  \begin{itemize}
                                      \item
                                            0x8053 für ,,Standard'' Betrieb
                                      \item
                                            0x8055 für die Verschlüsselung einzelner Verbindungsdaten auf
                                            mehreren Verbindungen zum selben Ziel
                                  \end{itemize}
                        \end{itemize}
              \end{itemize}
        \item
              Das PPP DES Encryption Protocol (DESE):

              \begin{itemize}
                  \item
                        In diesem Kurs wird nur die aktualisierte Version DESEv2
                        {[}RFC2419{]} behandelt
                  \item
                        % \includegraphics{Assets/NetworkSecurity-Point-to-Point-DESE.png}
                  \item
                        DESEv2 wird mit einer ECP-Konfigurationsanforderungsnachricht
                        ausgehandelt:

                        \begin{itemize}
                            \item
                                  Code: 1 \textasciitilde{} configure request
                            \item
                                  Identifier: ändert sich mit jeder neuen Anfrage
                            \item
                                  Länge: Gesamtlänge der Configure-Request-Nachricht
                            \item
                                  Type: 3 \textasciitilde{} DESEv2
                            \item
                                  Länge': 10 (die Länge dieser Konfigurationsoption)
                            \item
                                  Initial Nonce: ein Initialisierungsvektor für DES im CBC-Modus (8
                                  Oktette)
                        \end{itemize}
              \end{itemize}
        \item
              PPP DESE v2 Nachrichtenformat:

              \begin{itemize}
                  \item
                        Adresse: 0x11111111 (bei HDLC-ähnlichem Framing)
                  \item
                        Steuerung: 0x00000011 (bei HDLC-ähnlicher Rahmung)
                  \item
                        Protokoll-ID: 0x0053 \textasciitilde{} DESE (Standard) / 0x0055
                        \textasciitilde{} DESE (individuelle Verbindung)
                  \item
                        Sequenznummer: anfänglich 0, diese Nummer wird von der
                        verschlüsselnden Stelle bei jedem gesendeten Paket erhöht
                  \item
                        Chiffriertext: die verschlüsselten Protokoll- und Informationsfelder
                        eines PPP-Pakets

                        \begin{itemize}
                            \item
                                  Nachrichten werden vor der Verschlüsselung auf ein Vielfaches von
                                  8 Oktetten aufgefüllt
                            \item
                                  die Verschlüsselung erfolgt mit DES im CBC-Modus
                        \end{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-Point-to-Point-DESE2.png}
              \end{itemize}
        \item
              PPP 3DES Encryption Protocol (3DESE):

              \begin{itemize}
                  \item
                        PPP 3DESE {[}RFC2420{]} ist dem PPP DESE sehr ähnlich
                  \item
                        PPP 3DESE wird mit einer Configure-Request-Nachricht ausgehandelt,
                        wobei das Type-Feld der Option auf 2 gesetzt ist (\textasciitilde{}
                        3DESE)
                  \item
                        Die Verschlüsselung der PPP-Nutzdaten erfolgt wie bei DESE, mit dem
                        Unterschied, dass 3DES mit 3 verschiedenen Schlüsseln verwendet wird
              \end{itemize}
        \item
              Alle PPP-Verschlüsselungsprotokolle gehen davon aus, dass vor der
              Verschlüsselungsphase ein Sitzungsschlüssel für die
              Verschlüsselung/Entschlüsselung von PPP-Paketen vereinbart wurde:

              \begin{itemize}
                  \item
                        Diese Annahme ist sinnvoll, da die Festlegung des Sitzungsschlüssels
                        eine Aufgabe ist, die während der Authentifizierungsphase erfüllt
                        werden sollte.
                  \item
                        Allerdings unterstützt nur das
                        PPP-EAP-TLS-Authentifizierungsprotokoll den Aufbau von
                        Sitzungsschlüsseln.
              \end{itemize}
    \end{itemize}


    \subsubsection{Punkt-zu-Punkt-Tunneling-Protokoll
        (PPTP)}

    \begin{itemize}
        \item
              PPP wurde ursprünglich für den Betrieb zwischen ,,direkt'' verbundenen
              Einheiten entwickelt, d.h. Einheiten, die eine gemeinsame
              Schicht-2-Verbindung haben

              \begin{itemize}
                  \item
                        Beispiel: ein PC und ein Einwahlrouter eines Internetanbieters, die
                        über das Telefonnetz mittels Modem verbunden sind
              \end{itemize}
        \item
              Die Grundidee von PPTP besteht darin, die Reichweite des Protokolls
              auf das gesamte Internet auszudehnen, indem der Transport von PPP-PDUs
              in IP-Paketen definiert wird

              \begin{itemize}
                  \item
                        Die Nutzlast von PPTP-PDUs sind also PPP-Pakete (ohne
                        schicht-2-spezifische Felder wie HDLC-Flags, Bit-Einfügungen,
                        Steuerzeichen, CRC-Fehlerprüfwerte usw.)
                  \item
                        PPP-Pakete werden in GRE-Pakete (generische Routing-Kapselung)
                        eingekapselt, die wiederum in IP-Pakete eingekapselt werden:
              \end{itemize}
    \end{itemize}

    %\begin{longtable}[]{@{}l@{}}
    %    \toprule
    %    \endhead
    %    Media Header (e.g. Ethernet MAC header)\tabularnewline
    %    IP Header\tabularnewline
    %    GRE V.2 Header\tabularnewline
    %    PPP Packet\tabularnewline
    %    \bottomrule
    %\end{longtable}


    \subsubsection{PPTP: Freiwilliges vs. obligatorisches
        Tunneling}

    \begin{itemize}
        \item
              PPTP realisiert einen ,,Tunnel'' über das Internet, der PPP-Pakete
              überträgt.
        \item
              Ein solcher Tunnel kann zwischen verschiedenen Einheiten realisiert
              werden:

              \begin{itemize}
                  \item
                        Einem Client-PC und einem PPTP Remote Access Server (RAS):

                        \begin{itemize}
                            \item
                                  Dies wird auch als freiwilliges Tunneling bezeichnet, da der
                                  Client-PC aktiv an der PPTP-Verarbeitung beteiligt ist.
                            \item
                                  Diese Variante ermöglicht die sichere Kommunikation zwischen einem
                                  Client-PC und einem bestimmten Subnetz unter Verwendung beliebiger
                                  Zugangs- und Zwischennetze
                        \end{itemize}
                  \item
                        Ein Point of Presence (POP) eines ISP und ein
                        PPTP-Fernzugangsserver:

                        \begin{itemize}
                            \item
                                  Dies wird auch als obligatorisches Tunneling bezeichnet, da der
                                  Client-PC nicht an der Entscheidung beteiligt ist, ob PPTP
                                  verwendet wird oder nicht.
                            \item
                                  Auf diese Weise lässt sich Sicherheit auf Subnetzebene
                                  realisieren, aber keine echte End-to-End-Sicherheit zwischen dem
                                  Client-PC und dem RAS
                            \item
                                  Beim obligatorischen Tunneling fungiert der ISP POP als
                                  Proxy-Client für den RAS
                        \end{itemize}
              \end{itemize}
    \end{itemize}

    Obligatorische Tunneling-Protokollschichten

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-PPTP-Tunneling-Protocol.png}
        \item
              % \includegraphics{Assets/NetworkSecurity-PPTP-Tunneling-Protocol2.png}
        \item
              % \includegraphics{Assets/NetworkSecurity-PPTP-Packet-Construction-at-Client.png}
    \end{itemize}


    \subsubsection{PPTP / PPP Proprietäre Erweiterungen und einige
        ,,Geschichte''}

    \begin{itemize}
        \item
              PPTP hat sich vor allem aufgrund der Unterstützung durch Microsoft
              durchgesetzt:

              \begin{itemize}
                  \item
                        Es wurde unter aktiver Beteiligung von Microsoft entwickelt und ist
                        in {[}RFC2637{]} dokumentiert.
                  \item
                        Microsoft implementierte es als Teil seines Remote Access Service
                        (RAS)
              \end{itemize}
        \item
              Microsoft hat weitere ,,proprietäre'' Erweiterungen für PPP
              spezifiziert:

              \begin{itemize}
                  \item
                        Microsoft PPP CHAP-Erweiterungen {[}RFC2433{]}
                  \item
                        Microsoft Point to Point Encryption Protocol {[}RFC3078{]}
              \end{itemize}
        \item
              Allerdings wurde eine Reihe von Schwachstellen in PPTP Version 1 und
              auch in einer verbesserten Version 2 entdeckt {[}SM98a, SMW99a{]}:

              \begin{itemize}
                  \item
                        Ein allgemeiner Konsens, PPTP als Standardprotokoll zu übernehmen,
                        konnte in den in den IETF-Arbeitsgruppen nicht erreicht werden.
                  \item
                        Außerdem wurde ein ähnliches Protokoll (Layer 2 Forwarding, L2F) von
                        Cisco als konkurrierender Ansatz vorgeschlagen
                  \item
                        Infolgedessen wurde ein Kompromiss gefunden, der die Vorteile beider
                        Vorschläge in einem einzigen Protokoll zusammenfasst: Layer 2
                        Tunneling Protocol (L2TP)
              \end{itemize}
    \end{itemize}


    \subsubsection{Vergleich von PPTP und
        L2TP}

    \begin{itemize}
        \item
              Beide Protokolle:

              \begin{itemize}
                  \item
                        verwenden PPP, um eine anfängliche Umhüllung für Benutzerpakete
                        bereitzustellen
                  \item
                        erweitern das PPP-Modell, indem sie erlauben, dass die Layer-2- und
                        PPP-Endpunkte sich auf verschiedenen Geräten befinden
                  \item
                        unterstützen freiwilliges und obligatorisches Tunneling
              \end{itemize}
        \item
              Zugrundeliegendes Netzwerk:

              \begin{itemize}
                  \item
                        PPTP benötigt ein IP-Netzwerk für den Transport seiner PDUs
                  \item
                        L2TP unterstützt verschiedene Technologien: IP (unter Verwendung von
                        UDP), permanente virtuelle Schaltungen (PVCs) von Frame Relay,
                        virtuelle Schaltungen (VCs) von X.25 oder ATM VCs
              \end{itemize}
        \item
              PPTP kann nur einen einzigen Tunnel zwischen Endpunkten unterstützen,
              L2TP ermöglicht die Verwendung mehrerer Tunnel zwischen Endpunkten

              \begin{itemize}
                  \item
                        L2TP ermöglicht z. B. die Erstellung verschiedener Tunnel für
                        unterschiedliche Dienstqualitäten
              \end{itemize}
        \item
              Beide Protokolle bieten eine Header-Kompression:

              \begin{itemize}
                  \item
                        Mit Header-Kompression kommt L2TP mit 4 Byte Overhead aus, im
                        Vergleich zu 6 Byte bei PPTP.
              \end{itemize}
        \item
              L2TP ermöglicht eine Tunnelauthentifizierung, während PPTP dies nicht
              tut.
    \end{itemize}


    \subsection{Virtuelle private
        Netzwerke}

    \begin{itemize}
        \item
              Verschiedene Definitionen des Begriffs virtuelles privates Netzwerk
              (VPN):

              \begin{itemize}
                  \item
                        Ein privates Netz, das innerhalb einer öffentlichen
                        Netzinfrastruktur, wie dem globalen Internet, aufgebaut ist.
                  \item
                        Eine Kommunikationsumgebung, in der der Zugang kontrolliert wird, um
                        Peer-Verbindungen nur innerhalb einer definierten
                        Interessengemeinschaft zuzulassen, und die durch eine Form der
                        Partitionierung eines gemeinsamen zugrundeliegenden
                        Kommunikationsmediums aufgebaut ist, wobei dieses zugrundeliegende
                        Kommunikationsmedium dem Netz Dienste auf nicht-exklusiver Basis
                        bereitstellt
                  \item
                        Ein logisches Computernetzwerk mit eingeschränkter Nutzung, das aus
                        den Systemressourcen eines relativ öffentlichen, physischen
                        Netzwerks (z. B. dem Internet) aufgebaut ist, oft unter Verwendung
                        von Verschlüsselung und oft durch Tunneln von Verbindungen des
                        virtuellen Netzwerks über das reale Netzwerk {[}RFC2828{]}.
                  \item
                        Anmerkung: Die beiden letzteren Definitionen beinhalten explizit
                        Sicherheitseigenschaften (kontrollierter Zugriff, Verschlüsselung),
                        die erste hingegen nicht.
              \end{itemize}
    \end{itemize}

    \begin{quote}
        ,,Sicher, es ist viel billiger als eigene Frame-Relay-Verbindungen, aber
        es funktioniert ungefähr so gut, wie wenn man sich auf dem Times Square
        Watte in die Ohren steckt und so tut, als wäre sonst niemand da.''
        (Wired Magazine Feb. 1998)
    \end{quote}

    Techniken zum Aufbau virtueller privater Netze

    \begin{itemize}
        \item
              Nutzung dedizierter Verbindungen (Cut-Through-Mechanismen):

              \begin{itemize}
                  \item
                        Virtuelle Verbindungen über ATM oder Frame Relay
                  \item
                        Multi-Protokoll über ATM (MPOA)
                  \item
                        Multiprotokoll-Etiketten-Vermittlung (MPLS)
                  \item
                        Sicherheitsdienste für Link Layer VPNs können effizient im Link
                        Layer Protokoll realisiert werden; ein Beispiel ist die ATM Security
                        Specification {[}ATM99a{]}
              \end{itemize}
        \item
              Kontrolliertes Routenleck / Routenfilterung:

              \begin{itemize}
                  \item
                        Grundidee: Kontrolle der Routenausbreitung dahingehend, dass nur
                        bestimmte Netze Routen für andere Netze erhalten
                  \item
                        Damit soll ,,security by obscurity'' realisiert werden (also kein
                        wirklicher Schutz!)
              \end{itemize}
        \item
              Tunneln:

              \begin{itemize}
                  \item
                        Generische Routing-Kapselung (GRE)
                  \item
                        PPP / PPTP / L2TP
                  \item
                        IPSec-Sicherheitsarchitektur für das Internet-Protokoll
              \end{itemize}
    \end{itemize}


    \section{Die IPsec-Architektur für das
      Internet-Protokoll}


    \subsection{Überblick}

    \begin{itemize}
        \item
              Kurze Einführung in das Internet-Protokoll (IP)
        \item
              Sicherheitsprobleme von IP und Ziele von IPsec
        \item
              Die IPsec-Architektur:

              \begin{itemize}
                  \item
                        Modi des IPsec-Sicherheitsprotokolls:

                        \begin{itemize}
                            \item
                                  Transportmodus
                            \item
                                  Tunnel-Modus
                        \end{itemize}
                  \item
                        Alternativen zur Implementierung
                  \item
                        IP-Sicherheitsrichtlinien-Datenbank (SPD)
                  \item
                        Sicherheitsvereinigungen (SA) und die SA-Datenbank (SADB)
              \end{itemize}
        \item
              IPsec Sicherheitsprotokolle:

              \begin{itemize}
                  \item
                        Authentifizierungs-Header (AH)
                  \item
                        Encapsulating Security Payload (ESP)
              \end{itemize}
        \item
              Entitätsauthentifizierung und der Internet-Schlüsselaustausch (IKE)
    \end{itemize}


    \subsection{Die TCP/IP-Protokollsuite}

    \begin{itemize}
        \item
              IP (Internet Protocol): unzuverlässiges, verbindungsloses
              Netzwerkprotokoll
        \item
              TCP (Transmission Control Protocol): zuverlässiges,
              verbindungsorientiertes Transportprotokoll, realisiert über IP
        \item
              UDP (User Datagram Protocol): unzuverlässiges, verbindungsloses
              Transportprotokoll, bietet eine Anwendungsschnittstelle zu IP
        \item
              Beispiele für Anwendungsprotokolle :

              \begin{itemize}
                  \item
                        HTTP: Hypertext-Übertragungsprotokoll
                  \item
                        SMTP: Einfaches Mail-Übertragungsprotokoll
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-tcp-ip-suite.png}
    \end{itemize}


    \subsection{Das IPv4-Paketformat}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-ipv4-packet-format.png}
        \item
              Version (Ver.): 4 bit

              \begin{itemize}
                  \item
                        Derzeit ist Version 4 weit verbreitet
                  \item
                        Version 6 ist bereits spezifiziert, aber es ist noch nicht klar, ob
                        sie jemals zum Einsatz kommen wird
              \end{itemize}
        \item
              IP-Header-Länge (IHL): 4 Bit

              \begin{itemize}
                  \item
                        Länge des IP-Headers in 32-Bit-Wörtern
              \end{itemize}
        \item
              Art des Dienstes (TOS): 8 Bit

              \begin{itemize}
                  \item
                        Dieses Feld könnte verwendet werden, um die Verkehrsanforderungen
                        eines Pakets anzugeben.
                  \item
                        Jetzt: DCSP und Explicit Congestion (EC) Indication
              \end{itemize}
        \item
              Länge: 16 Bit

              \begin{itemize}
                  \item
                        Die Länge des Pakets einschließlich des Headers in Oktetten
                  \item
                        Dieses Feld ist, wie alle anderen Felder in der IP-Suite, in ,,big
                        endian'' Darstellung
              \end{itemize}
        \item
              Kennung: 16 Bit

              \begin{itemize}
                  \item
                        Dient der ,,eindeutigen'' Identifizierung eines IP-Datagramms
                  \item
                        Wichtig für das Wiederzusammensetzen von fragmentierten
                        IP-Datagrammen
              \end{itemize}
        \item
              Flaggen: 3 Bit

              \begin{itemize}
                  \item
                        Bit 1: nicht fragmentieren
                  \item
                        Bit 2: Datagramm fragmentiert
                  \item
                        Bit 3: reserviert für zukünftige Verwendung
              \end{itemize}
        \item
              Fragmentierungs-Offset: 13 Bit

              \begin{itemize}
                  \item
                        Die Position dieses Pakets im entsprechenden IP-Datagramm
              \end{itemize}
        \item
              Lebenszeit (TTL): 8 Bit

              \begin{itemize}
                  \item
                        An jedem verarbeitenden Netzknoten wird dieses Feld um eins
                        dekrementiert
                  \item
                        Wenn die TTL 0 erreicht, wird das Paket verworfen, um Paketschleifen
                        zu vermeiden.
              \end{itemize}
        \item
              Protokoll: 8 Bit

              \begin{itemize}
                  \item
                        Gibt das (Transport-)Protokoll der Nutzlast an
                  \item
                        Wird vom empfangenden Endsystem verwendet, um Pakete zwischen
                        verschiedenen Transportprotokollen wie TCP, UDP, ... zu
                        entmultiplexen.
              \end{itemize}
        \item
              Prüfsumme: 16 Bit

              \begin{itemize}
                  \item
                        Schutz vor Übertragungsfehlern
                  \item
                        Da es sich nicht um eine kryptografische Prüfsumme handelt, kann sie
                        leicht gefälscht werden.
              \end{itemize}
        \item
              Quelladresse: 32 Bit

              \begin{itemize}
                  \item
                        Die IP-Adresse des Absenders dieses Pakets
              \end{itemize}
        \item
              Zieladresse: 32 Bit

              \begin{itemize}
                  \item
                        Die IP-Adresse des vorgesehenen Empfängers dieses Pakets
              \end{itemize}
        \item
              IP-Optionen: variable Länge

              \begin{itemize}
                  \item
                        Ein IP-Header kann optional zusätzliche Informationen enthalten.
                  \item
                        Da sie nicht Bestandteil von IPsec sind, werden sie in diesem Kurs
                        nicht behandelt.
              \end{itemize}
    \end{itemize}


    \subsection{Sicherheitsprobleme des
        Internet-Protokolls}

    \begin{itemize}
        \item
              Wenn eine Einheit ein IP-Paket empfängt, hat sie keine Garantie für:

              \begin{itemize}
                  \item
                        Authentifizierung der Datenherkunft / Datenintegrität:

                        \begin{itemize}
                            \item
                                  Das Paket wurde tatsächlich von der Einrichtung gesendet, auf die
                                  die Quelladresse des Pakets verweist.
                            \item
                                  Das Paket enthält den ursprünglichen Inhalt des Absenders, so dass
                                  es während des Transports nicht verändert worden ist.
                            \item
                                  Die empfangende Einrichtung ist tatsächlich die Einrichtung, an
                                  die der Absender das Paket senden wollte.
                        \end{itemize}
                  \item
                        Vertraulichkeit:

                        \begin{itemize}
                            \item
                                  Die ursprünglichen Daten wurden auf dem Weg vom Absender zum
                                  Empfänger nicht von Dritten eingesehen.
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Sicherheitsziele von
        IPsec}

    \begin{itemize}
        \item
              IPsec zielt darauf ab, die folgenden Sicherheitsziele zu
              gewährleisten:

              \begin{itemize}
                  \item
                        Authentifizierung der Datenherkunft / Verbindungslose
                        Datenintegrität:

                        \begin{itemize}
                            \item
                                  Es ist nicht möglich, ein IP-Datagramm mit einer maskierten
                                  IP-Quell- oder Zieladresse zu senden, ohne dass der Empfänger dies
                                  erkennen kann.
                            \item
                                  Es ist nicht möglich, ein IP-Datagramm während der Übertragung zu
                                  verändern, ohne dass der Empfänger diese Veränderung feststellen
                                  kann.
                            \item
                                  Wiedergabeschutz: Es ist nicht möglich, ein aufgezeichnetes
                                  IP-Paket zu einem späteren Zeitpunkt erneut abzuspielen, ohne dass
                                  der Empfänger dies erkennen kann.
                        \end{itemize}
                  \item
                        Vertraulichkeit:

                        \begin{itemize}
                            \item
                                  Es ist nicht möglich, den Inhalt von IP-Datagrammen zu belauschen
                            \item
                                  Begrenzte Vertraulichkeit des Verkehrsflusses
                        \end{itemize}
              \end{itemize}
        \item
              Sicherheitspolitik:

              \begin{itemize}
                  \item
                        Sender, Empfänger und Zwischenknoten können den erforderlichen
                        Schutz für ein IP-Paket gemäß einer lokalen Sicherheitsrichtlinie
                        festlegen
                  \item
                        Zwischenknoten und der Empfänger verwerfen IP-Pakete, die diese
                        Anforderungen nicht erfüllen
              \end{itemize}
    \end{itemize}


    \subsection{Überblick über die
        IPsec-Standardisierung}

    % \includegraphics{Assets/NetworkSecurity-IPsec-standardization.png}


    \subsection{Überblick über die
        IPsec-Architektur}

    \begin{itemize}
        \item
              RFC 4301 definiert die grundlegende Architektur von IPsec:

              \begin{itemize}
                  \item
                        Konzepte:

                        \begin{itemize}
                            \item
                                  Sicherheitsvereinigung (SA), Sicherheitsvereinigungsdatenbank
                                  (SADB)
                            \item
                                  Sicherheitsrichtlinien, Sicherheitsrichtlinien-Datenbank (SPD)
                        \end{itemize}
                  \item
                        Grundlegende IPsec-Protokolle:

                        \begin{itemize}
                            \item
                                  Authentifizierungs-Header (AH)
                            \item
                                  Encapsulating Security Payload (ESP)
                        \end{itemize}
                  \item
                        Protokoll-Modi:

                        \begin{itemize}
                            \item
                                  Transport-Modus
                            \item
                                  Tunnel-Modus
                        \end{itemize}
                  \item
                        Schlüsselmanagement-Verfahren:

                        \begin{itemize}
                            \item
                                  IKE \& IKEv
                        \end{itemize}
              \end{itemize}
        \item
              RFC 4301 definiert die grundlegende Architektur von IPsec:

              \begin{itemize}
                  \item
                        Verwendung von verschiedenen kryptographischen Primitiven mit AH und
                        ESP:

                        \begin{itemize}
                            \item
                                  Verschlüsselung: 3DES-CBC, AES und andere
                                  CBC-Verschlüsselungsalgorithmen, AES-Zählermodus
                            \item
                                  Integrität: HMAC-MD5, HMAC-SHA-1, HMAC-SHA-2, HMAC- RIPEMD-160,
                                  AES-GMAC, AES-CMAC, AES-XCBC...
                            \item
                                  Authentifizierte Verschlüsselung: GCM und "Zähler mit CBC-MAC"
                                  (CCM), beide für AES definiert
                        \end{itemize}
              \end{itemize}
        \item
              Eine Sicherheitsassoziation (SA) ist eine Simplex- ,,Verbindung'', die
              Sicherheitsdienste für den von ihr beförderten Verkehr bereitstellt.

              \begin{itemize}
                  \item
                        Sicherheitsdienste werden für eine SA entweder mit AH oder ESP
                        bereitgestellt, jedoch nicht mit beiden.
                  \item
                        Für bidirektionale Kommunikation sind zwei Sicherheitsverbindungen
                        erforderlich.
                  \item
                        Eine SA wird eindeutig durch ein Tripel identifiziert, das aus einem
                        Sicherheitsparameterindex (SPI), einer IP-Zieladresse und einer
                        Sicherheitsprotokollkennung (AH / ESP) besteht.
                  \item
                        Eine SA kann zwischen den folgenden Gegenstellen eingerichtet
                        werden:

                        \begin{itemize}
                            \item
                                  Host \$\textbackslash leftrightarrow\$ Host
                            \item
                                  Host \$\textbackslash leftrightarrow\$ Gateway (oder andersherum)
                            \item
                                  Gateway \$\textbackslash leftrightarrow\$ Gateway
                        \end{itemize}
                  \item
                        Es gibt zwei konzeptionelle Datenbanken, die mit SAs verbunden sind:

                        \begin{itemize}
                            \item
                                  Die Sicherheitsrichtliniendatenbank (SPD) legt fest, welche
                                  Sicherheitsdienste für welche IP-Pakete auf welche Weise
                                  bereitgestellt werden sollen.
                            \item
                                  Die Sicherheitsassoziationsdatenbank (SADB)
                        \end{itemize}
              \end{itemize}
        \item
              Protokollmodi - Eine SA ist immer von einem der folgenden Typen:

              \begin{itemize}
                  \item
                        Der Transportmodus kann nur zwischen den Endpunkten einer
                        Kommunikation verwendet werden:

                        \begin{itemize}
                            \item
                                  host \$\textbackslash leftrightarrow\$ host, oder
                            \item
                                  Host \$\textbackslash leftrightarrow\$-Gateway, wenn das Gateway
                                  ein Kommunikationsendpunkt ist (z. B. für die Netzverwaltung)
                        \end{itemize}
                  \item
                        Der Tunnelmodus kann für beliebige Peers verwendet werden.
              \end{itemize}
        \item
              Der Unterschied zwischen den beiden Modi ist, dass:

              \begin{itemize}
                  \item
                        Im Transportmodus wird lediglich ein sicherheitsspezifischer Header
                        (+ eventueller Trailer) hinzugefügt:

                        \begin{itemize}
                            \item
                                  % \includegraphics{Assets/NetworkSecurity-ipsec-transport-mode.png}
                        \end{itemize}
                  \item
                        Der Tunnelmodus kapselt IP-Pakete ein: Die Verkapselung von
                        IP-Paketen ermöglicht es einem Gateway, den Verkehr im Namen anderer
                        Entitäten zu schützen (z. B. Hosts eines Subnetzes usw.)

                        \begin{itemize}
                            \item
                                  % \includegraphics{Assets/NetworkSecurity-ipsec-tunnel-mode.png}
                        \end{itemize}
              \end{itemize}
        \item
              Der Authentifizierungs-Header (AH):

              \begin{itemize}
                  \item
                        Bietet Authentifizierung der Datenherkunft und Schutz vor
                        Wiederholung
                  \item
                        Wird als Header realisiert, der zwischen dem IP-Header und den zu
                        schützenden Daten eingefügt wird
                  \item
                        % \includegraphics{Assets/NetworkSecurity-ipsec-AH.png}
              \end{itemize}
        \item
              Die einkapselnde Sicherheitsnutzlast (ESP):

              \begin{itemize}
                  \item
                        Bietet Authentifizierung der Datenherkunft, Vertraulichkeit und
                        Schutz vor Wiederholung
                  \item
                        Wird mit einem Header und einem Trailer realisiert, der die zu
                        schützenden Daten einkapselt
                  \item
                        % \includegraphics{Assets/NetworkSecurity-ipsec-ESP.png}
              \end{itemize}
        \item
              Die Einrichtung von Sicherheitsvereinigungen wird mit:

              \begin{itemize}
                  \item
                        Internet Security Association Key Management Protocol (ISAKMP):

                        \begin{itemize}
                            \item
                                  Definiert einen generischen Rahmen für die
                                  Schlüsselauthentifizierung, den Schlüsselaustausch und die
                                  Aushandlung von Sicherheitsassoziationsparametern {[}RFC2408{]}.
                            \item
                                  Definiert kein spezifisches Authentifizierungsprotokoll, aber
                                  spezifiziert:

                                  \begin{itemize}
                                      \item
                                            Paketformate
                                      \item
                                            Zeitgeber für die Weiterleitung
                                      \item
                                            Anforderungen an den Nachrichtenaufbau
                                  \end{itemize}
                            \item
                                  Die Verwendung von ISAKMP für IPsec wird in {[}RFC2407{]} näher
                                  beschrieben.
                        \end{itemize}
                  \item
                        Internet-Schlüsselaustausch (IKE):

                        \begin{itemize}
                            \item
                                  Definiert ein Authentifizierungs- und Schlüsselaustauschprotokoll
                                  {[}RFC2409{]}.
                            \item
                                  Ist konform zu ISAKMP und kann für verschiedene Anwendungen
                                  verwendet werden
                            \item
                                  Der Aufbau von IPsec SAs zwischen zwei Entitäten wird in zwei
                                  Phasen realisiert:

                                  \begin{itemize}
                                      \item
                                            Einrichtung einer IKE SA (definiert, wie man IPsec SAs
                                            einrichtet)
                                      \item
                                            Einrichtung von IPsec SAs
                                  \end{itemize}
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{IPsec-Wiedergabeschutz (Replay
        protection)}

    \begin{itemize}
        \item
              Sowohl AH- als auch ESP-geschützte IP-Pakete tragen eine
              Sequenznummer, die einen Wiedergabeschutz realisiert:

              \begin{itemize}
                  \item
                        Beim Einrichten einer SA wird diese Sequenznummer auf Null
                        initialisiert.
                  \item
                        Die Sequenznummer wird mit jedem gesendeten IP-Paket erhöht
                  \item
                        Die Sequenznummer ist 32 Bit lang, es wird ein neuer
                        Sitzungsschlüssel benötigt, bevor ein Wrap-around erfolgt
                  \item
                        Der Empfänger eines IP-Pakets prüft, ob die Sequenznummer in einem
                        Fenster zulässiger Nummern enthalten ist
                  \item
                        % \includegraphics{Assets/NetworkSecurity-ipsec-replay-protection.png}

                        \begin{itemize}
                            \item
                                  (Paket mit Sequenznummer N kann noch akzeptiert werden)
                        \end{itemize}
              \end{itemize}
        \item
              Wenn ein empfangenes Paket eine Sequenznummer hat, die:

              \begin{itemize}
                  \item
                        links vom aktuellen Fenster \$\textbackslash Rightarrow\$ liegt,
                        lehnt der Empfänger das Paket ab
                  \item
                        innerhalb des aktuellen Fensters \$\textbackslash Rightarrow\$
                        liegt, nimmt der Empfänger das Paket an
                  \item
                        liegt rechts vom aktuellen Fenster \$\textbackslash Rightarrow\$ der
                        Empfänger nimmt das Paket an und schiebt das Fenster weiter
                  \item
                        Natürlich werden IP-Pakete nur akzeptiert, wenn sie die
                        Authentifizierungsprüfung bestehen und das Fenster wird niemals vor
                        dieser Prüfung weitergeschaltet
              \end{itemize}
        \item
              Die minimale Fenstergröße beträgt 32 Pakete (64 Pakete werden
              empfohlen)

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-ipsec-replay-protection2.png}

                        \begin{itemize}
                            \item
                                  Paket mit Sequenznummer N kann nicht mehr akzeptiert werden
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{IPsec-Implementierungsalternativen:
        Host-Implementierung}

    \begin{itemize}
        \item
              Vorteile der IPsec-Implementierung in Endsystemen:

              \begin{itemize}
                  \item
                        Bereitstellung von End-to-End-Sicherheitsdiensten
                  \item
                        Bereitstellung von Sicherheitsdiensten auf einer Per-Flow-Basis
                  \item
                        Fähigkeit, alle IPsec-Modi zu implementieren
              \end{itemize}
        \item
              Zwei Hauptalternativen zur Integration: \textbar{} Integriertes
              Betriebssystem \textbar{} ,,Bump'' im Stack \textbar{} \textbar{}
              -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
              \textbar{}
              -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
              \textbar{} \textbar{} Anwendung \textbar{} Anwendung \textbar{}
              \textbar{} Transport \textbar{} Transport \textbar{} \textbar{}
              Netzwerk + IPsec \textbar{} Netzwerk \textbar{} \textbar{} IPsec
              \textbar{} \textbar{} Data Link \textbar{} Data Link \textbar{}
              \textbar{} \textbar{} \textbar{} Echte Betriebssystemintegration ist
              die Methode der Wahl, da sie die Duplizierung von Funktionalität
              vermeidet \textbar{} Wenn das Betriebssystem nicht geändert werden
              kann, wird IPsec über den Datenverbindungstreiber eingefügt \textbar{}
    \end{itemize}


    \subsection{IPsec-Implementierungsalternativen:
        Router-Implementierung}

    \begin{itemize}
        \item
              Vorteile der IPsec-Implementierung in Routern:

              \begin{itemize}
                  \item
                        Möglichkeit, IP-Pakete zu sichern, die zwischen zwei Netzen über ein
                        öffentliches Netz wie das Internet fließen:

                        \begin{itemize}
                            \item
                                  Ermöglicht die Einrichtung virtueller privater Netzwerke (VPNs)
                            \item
                                  Keine Notwendigkeit, IPsec in jedes Endsystem zu integrieren
                        \end{itemize}
                  \item
                        Fähigkeit zur Authentifizierung und Autorisierung des IP-Verkehrs,
                        der von entfernten Benutzern eingeht
              \end{itemize}
        \item
              Zwei Hauptalternativen für die Implementierung:

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-ipsec-router-implementation.png}
              \end{itemize}
    \end{itemize}


    \subsection{Wann sollte welcher IPsec-Modus verwendet
        werden?}

    \begin{itemize}
        \item
              In den meisten Fällen handelt es sich bei den Kommunikationsendpunkten
              um Hosts (Workstations, Server), aber das ist nicht unbedingt der
              Fall:

              \begin{itemize}
                  \item
                        Beispiel: ein Gateway wird über SNMP von einer Workstation verwaltet
              \end{itemize}
        \item
              Der Transportmodus wird verwendet, wenn die ,,kryptografischen
              Endpunkte'' auch die ,,Kommunikationsendpunkte'' der gesicherten
              IP-Pakete sind

              \begin{itemize}
                  \item
                        Kryptografische Endpunkte: die Entitäten, die einen IPsec-Header (AH
                        oder ESP) erzeugen/verarbeiten
                  \item
                        Kommunikationsendpunkte: Quelle und Ziel eines IP-Pakets

                        \begin{itemize}
                            \item
                                  % \includegraphics{Assets/NetworkSecurity-communication-endpoints.png}
                        \end{itemize}
              \end{itemize}
        \item
              Der Tunnelmodus wird verwendet, wenn mindestens ein
              ,,kryptographischer Endpunkt'' nicht ein ,,Kommunikationsendpunkt''
              der gesicherten IP-Pakete ist

              \begin{itemize}
                  \item
                        Dies ermöglicht Gateways, die den IP-Verkehr im Namen anderer
                        Stellen sichern
                  \item
                        % \includegraphics{Assets/NetworkSecurity-communication-tunneling.png}
              \end{itemize}
        \item
              Die obige Beschreibung der Anwendungsszenarien für den Tunnelmodus
              umfasst auch den Fall, dass nur ein kryptografischer Endpunkt kein
              Kommunikationsendpunkt ist:

              \begin{itemize}
                  \item
                        Beispiel: ein Sicherheitsgateway, das die Authentifizierung und/oder
                        die Vertraulichkeit des IP-Verkehrs zwischen einem lokalen Teilnetz
                        und einem über das Internet verbundenen Host sicherstellt (,,Road
                        Warrior Szenario'')
                  \item
                        % \includegraphics{Assets/NetworkSecurity-communication-tunnelung-2.png}
              \end{itemize}
    \end{itemize}


    \subsection{Verschachtelung von
        Sicherheitsassoziationen}

    \begin{itemize}
        \item
              Sicherheitsassoziationen können verschachtelt werden:

              \begin{itemize}
                  \item
                        Beispiel: Host A und Gateway RB führen eine Authentifizierung der
                        Datenherkunft durch und die Gateways RA und RB führen eine
                        Vertraulichkeit von Subnetz zu Subnetz durch
                  \item
                        % \includegraphics{Assets/NetworkSecurity-communication-nesting.png}
              \end{itemize}
        \item
              Bei der Verschachtelung von SAs muss jedoch darauf geachtet werden,
              dass keine ,,falsche Klammerung'' von SAs erfolgt, wie z. B.
              ,,{[}({]})''

              \begin{itemize}
                  \item
                        Ein Beispiel für eine gültige SA-Schachtelung:

                        \begin{itemize}
                            \item
                                  % \includegraphics{Assets/NetworkSecurity-communication-nesting-2.png}
                        \end{itemize}
                  \item
                        Ein Beispiel für ungültige SA-Schachtelungen:

                        \begin{itemize}
                            \item
                                  % \includegraphics{Assets/NetworkSecurity-communication-nesting-3.png}
                            \item
                                  Da das Paket von RB nach RD getunnelt wird, kann das Gateway RC
                                  den inneren IPsec-Header nicht verarbeiten
                            \item
                                  Ein mögliches Ergebnis dieser fehlerhaften Konfiguration könnte
                                  sein, dass das Paket zurück nach RC geroutet wird
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Grundschema der IPsec-Verarbeitung: Ausgehende
        Pakete}

    \begin{itemize}
        \item
              Nehmen wir an, die IP-Schicht eines Knotens (Host/Gateway) wird
              angewiesen, ein IP-Paket an einen anderen Knoten (Host/Gateway) zu
              senden
        \item
              Um IPsec zu unterstützen, muss sie die folgenden Schritte durchführen:

              \begin{itemize}
                  \item
                        Feststellen, ob und wie das ausgehende Paket gesichert werden muss:

                        \begin{itemize}
                            \item
                                  Dies wird durch einen Lookup im SPD realisiert
                            \item
                                  Wenn die Richtlinie ,,verwerfen'' vorschreibt, wird das Paket
                                  verworfen \$\textbackslash Rightarrow\$ done
                            \item
                                  Wenn das Paket nicht gesichert werden muss, dann sende es
                                  \$\textbackslash Rightarrow\$ done
                        \end{itemize}
                  \item
                        Ermitteln, welche SA auf das Paket angewendet werden soll:

                        \begin{itemize}
                            \item
                                  Wenn es noch keine passende SA mit dem entsprechenden Knoten gibt,
                                  dann fordere den Key Management Demon auf, einen IKE durchzuführen
                        \end{itemize}
                  \item
                        Die ermittelte (und eventuell neu erstellte) SA in der SADB
                        nachschlagen
                  \item
                        Führen Sie die von der SA festgelegte Sicherheitstransformation
                        durch, indem Sie den Algorithmus, seine Parameter und den Schlüssel,
                        wie in der SA angegeben, verwenden.

                        \begin{itemize}
                            \item
                                  Dies resultiert in der Konstruktion eines AH- oder ESP-Headers
                            \item
                                  Eventuell wird auch ein neuer (äußerer) IP-Header erstellt
                                  (Tunnelmodus)
                        \end{itemize}
                  \item
                        Senden Sie das resultierende IP-Paket \$\textbackslash Rightarrow\$
                        done
              \end{itemize}
    \end{itemize}


    \subsection{Grundschema der IPsec-Verarbeitung: Eingehende
        Pakete}

    \begin{itemize}
        \item
              Nehmen wir an, die IP-Schicht eines Knotens (Host/Gateway) empfängt
              ein IP-Paket von einem anderen Knoten (Host/Gateway)
        \item
              Um IPsec zu unterstützen, muss sie die folgenden Schritte durchführen:

              \begin{itemize}
                  \item
                        Feststellen, ob das Paket einen IPsec-Header enthält, den diese
                        Einheit verarbeiten soll:

                        \begin{itemize}
                            \item
                                  Wenn es einen solchen IPsec-Header gibt, dann suchen Sie die SA in
                                  der SADB, die durch den SPI des IPsec-Headers spezifiziert ist,
                                  und führen Sie die entsprechende IPsec-Verarbeitung durch
                            \item
                                  Wenn die SA, auf die der SPI verweist, (noch) nicht existiert,
                                  verwerfen Sie das Paket
                        \end{itemize}
                  \item
                        Ermitteln, ob und wie das Paket hätte geschützt werden sollen:

                        \begin{itemize}
                            \item
                                  Dies wird wiederum durch einen Lookup im SPD realisiert, wobei der
                                  Lookup im Falle von getunnelten Paketen durch Auswertung des
                                  inneren IP-Headers durchgeführt wird
                            \item
                                  Wenn die Richtlinie ,,Verwerfen'' vorschreibt, wird das Paket
                                  verworfen.
                            \item
                                  Wenn der Schutz des Pakets nicht mit der Richtlinie übereinstimmt,
                                  wird das Paket verworfen.
                            \item
                                  Wenn das Paket ordnungsgemäß gesichert wurde, dann übergebe es an
                                  die entsprechende Protokollinstanz (Netzwerk-/Transportschicht)
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Auswahl der
        IPsec-Sicherheitspolitik}

    Die folgenden Selektoren, die aus den Headern der Netzwerk- und
    Transportschicht extrahiert werden, ermöglichen die Auswahl einer
    bestimmten Richtlinie im SPD:

    \begin{itemize}
        \item
              IP-Quelladresse:

              \begin{itemize}
                  \item
                        Bestimmter Host, Netzwerkpräfix, Adressbereich oder Platzhalter
              \end{itemize}
        \item
              IP-Zieladresse:

              \begin{itemize}
                  \item
                        Bestimmter Host, Netzwerk-Präfix, Adressbereich oder Platzhalter
                  \item
                        Im Falle eingehender getunnelter Pakete wird der innere Header
                        ausgewertet
              \end{itemize}
        \item
              Protokoll:

              \begin{itemize}
                  \item
                        Der Protokoll-Identifikator des Transportprotokolls für dieses Paket
                  \item
                        Dies ist möglicherweise nicht zugänglich, wenn ein Paket mit ESP
                        gesichert ist.
              \end{itemize}
        \item
              Ports der oberen Schicht:

              \begin{itemize}
                  \item
                        Falls zugänglich, die Ports der oberen Schicht für die
                        sitzungsorientierte Policy-Auswahl
              \end{itemize}
    \end{itemize}


    \subsection{IPsec Security Policy
        Definition}

    \begin{itemize}
        \item
              Policy Selectors werden verwendet, um spezifische Policy-Definitionen
              auszuwählen, spezifiziert:

              \begin{itemize}
                  \item
                        Wie die Einrichtung einer IKE SA zwischen zwei Knoten durchgeführt
                        werden soll:

                        \begin{itemize}
                            \item
                                  Identifizierung: DNS-Name oder andere Namenstypen, wie in der
                                  IPsec-Domäne der Interpretation eines Protokolls zur Einrichtung
                                  von SAs definiert
                            \item
                                  Phase I-Modus: Hauptmodus oder aggressiver Modus (siehe unten)
                            \item
                                  Schutzsuite(n): Angabe, wie die IKE-Authentifizierung durchgeführt
                                  wird
                        \end{itemize}
                  \item
                        Welche und wie Sicherheitsdienste für IP-Pakete bereitgestellt
                        werden sollen:

                        \begin{itemize}
                            \item
                                  Selektoren, die bestimmte Flüsse identifizieren
                            \item
                                  Sicherheitsattribute für jeden Fluss:

                                  \begin{itemize}
                                      \item
                                            Sicherheitsprotokoll: AH oder ESP
                                      \item
                                            Protokollmodus: Transport- oder Tunnelmodus
                                      \item
                                            Sicherheitstransformationen: kryptografische Algorithmen und
                                            Parameter
                                      \item
                                            Andere Parameter: SA-Lebensdauer, Replay-Fenster
                                  \end{itemize}
                            \item
                                  Aktion: Verwerfen, Sichern, Umgehen
                        \end{itemize}
              \end{itemize}
        \item
              Wenn bereits eine SA mit einem entsprechenden Sicherheitsendpunkt
              eingerichtet ist, wird im SPD auf diese verwiesen.
    \end{itemize}


    \subsection{Die Encapsulating Security
        Payload}

    \begin{itemize}
        \item
              ESP ist ein allgemeines Sicherheitsprotokoll, das IP-Paketen einen
              Wiederholungsschutz und einen oder beide der folgenden
              Sicherheitsdienste bietet:

              \begin{itemize}
                  \item
                        Vertraulichkeit durch Verschlüsselung der eingekapselten Pakete oder
                        nur ihrer Nutzlast
                  \item
                        Authentifizierung der Datenherkunft durch Erstellung und Hinzufügung
                        von MACs zu Paketen
              \end{itemize}
        \item
              Die ESP-Definition gliedert sich in zwei Teile:

              \begin{itemize}
                  \item
                        Die Definition des Basisprotokolls {[}RFC4303{]}:

                        \begin{itemize}
                            \item
                                  Definition des Header- und Trailer-Formats
                            \item
                                  Verarbeitung des Basisprotokolls
                            \item
                                  Tunnel- und Transportmodusbetrieb
                        \end{itemize}
                  \item
                        Die Verwendung spezifischer kryptographischer Algorithmen mit ESP:

                        \begin{itemize}
                            \item
                                  Verschlüsselung: 3DES-CBC, AES-CBC, AES-Zählmodus, Verwendung
                                  anderer Chiffren im CBC-Modus
                            \item
                                  Authentifizierung: HMAC-MD5-96, HMAC-SHA-96,...
                        \end{itemize}
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-ESP.png}

              \begin{itemize}
                  \item
                        Der ESP-Header folgt unmittelbar auf einen IP-Header oder einen
                        AH-Header
                  \item
                        Das Next-Header-Feld des vorangehenden Headers zeigt ,,50'' für ESP
                        an
                  \item
                        Das SPI-Feld gibt die SA an, die für dieses Paket verwendet werden
                        soll:

                        \begin{itemize}
                            \item
                                  Der SPI-Wert wird immer von der empfangenden Seite während der
                                  SA-Aushandlung bestimmt, da der Empfänger das Paket verarbeiten
                                  muss.
                        \end{itemize}
                  \item
                        Die Sequenznummer bietet, wie bereits erläutert, Schutz vor
                        Wiederholung.
                  \item
                        Wenn der verwendete kryptographische Algorithmus einen
                        Initialisierungsvektor benötigt, wird dieser in jedem Paket am
                        Anfang der Nutzlast im Klartext übertragen
                  \item
                        Das Pad-Feld dient der Sicherstellung:

                        \begin{itemize}
                            \item
                                  Auffüllen der Nutzlast bis zur erforderlichen Blocklänge der
                                  verwendeten Chiffre
                            \item
                                  Auffüllen der Nutzlast, um die Felder pad-length und next-header
                                  rechtsbündig in die höherwertigen 16 Bit eines 32-Bit-Wortes
                                  einzupassen
                        \end{itemize}
                  \item
                        Die Auffülllänge gibt die Anzahl der hinzugefügten Auffüllbytes an.
                  \item
                        Das next-header-Feld des ESP-Headers gibt die eingekapselte Nutzlast
                        an:

                        \begin{itemize}
                            \item
                                  Im Falle des Tunnelmodus: IP
                            \item
                                  Im Falle des Transportmodus: ein beliebiges Protokoll der höheren
                                  Schicht wie TCP, UDP, ...
                        \end{itemize}
                  \item
                        Das optionale Feld authentication-data enthält eine MAC, falls
                        vorhanden
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-ESP-processing.png}
        \item
              % \includegraphics{Assets/NetworkSecurity-ESP-prepare-header.png}
        \item
              % \includegraphics{Assets/NetworkSecurity-ESP-inbound-processing.png}
        \item
              % \includegraphics{Assets/NetworkSecurity-ESP-inbound-processing-2.png}
        \item
              Beachten Sie, dass das entkapselte IP-Paket ein fragmentiertes Paket
              sein kann:

              \begin{itemize}
                  \item
                        Dies kann vorkommen, wenn ESP von einem Router im Tunnelmodus
                        angewendet wurde.
                  \item
                        Um die Konformität mit der SA-Policy korrekt zu prüfen, müssen alle
                        zu diesem Paket gehörenden Fragmente vom Router empfangen werden,
                        bevor die Prüfung durchgeführt werden kann
                  \item
                        Beispiel: In einer SA sind nur Pakete an einen bestimmten Port
                        erlaubt

                        \begin{itemize}
                            \item
                                  Die erforderliche Port-Information ist nur im ersten Fragment des
                                  IP-Pakets vorhanden
                        \end{itemize}
              \end{itemize}
        \item
              Paketzustellung bedeutet Zustellung an die entsprechende
              Verarbeitungseinheit:

              \begin{itemize}
                  \item
                        Wenn ein anderer IPsec-Header für diese Entität vorhanden ist
                        \$\textbackslash Rightarrow\$ IPsec-Verarbeitung
                  \item
                        Im Tunnelmodus \$\textbackslash Rightarrow\$ Übermittlung des Pakets
                  \item
                        Im Transportmodus \$\textbackslash Rightarrow\$ Aufruf des
                        entsprechenden Protokoll-Headers (TCP, UDP, etc.)
              \end{itemize}
        \item
              Wenn ESP sowohl Vertraulichkeit als auch Authentifizierung bietet,
              können für beide Dienste unterschiedliche Schlüssel verwendet werden.

              \begin{itemize}
                  \item
                        Dies muss während der Einrichtung der ESP-SA ausgehandelt werden.
              \end{itemize}
        \item
              Beachten Sie, dass die Verwendung von ESP ohne Authentifizierung
              unsicher ist...

              \begin{itemize}
                  \item
                        Kein zuverlässiger Schutz vor Wiederholungen
                  \item
                        Zumindest, wenn im CBC-Modus verwendet:

                        \begin{itemize}
                            \item
                                  Aktive Angriffe ermöglichen die Wiederherstellung von Nachrichten
                            \item
                                  Beispiel: Bits umdrehen und prüfen, ob Fehlermeldungen erzeugt
                                  werden
                            \item
                                  Vollständige Wiederherstellung von Klartextblöcken
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Der
        Authentifizierungs-Header}

    \begin{itemize}
        \item
              AH ist ein allgemeines Sicherheitsprotokoll, das IP-Paketen Schutz
              bietet:

              \begin{itemize}
                  \item
                        Wiedergabeschutz
                  \item
                        Authentifizierung der Datenherkunft durch Erstellung und Hinzufügung
                        von MACs zu den Paketen
              \end{itemize}
        \item
              Wie bei ESP ist die AH-Definition in zwei Teile aufgeteilt:

              \begin{itemize}
                  \item
                        Die Definition des Basisprotokolls {[}RFC4302{]}:

                        \begin{itemize}
                            \item
                                  Definition des Header-Formats
                            \item
                                  Verarbeitung des Basisprotokolls
                            \item
                                  Tunnel- und Transportmodusbetrieb
                        \end{itemize}
                  \item
                        Die Verwendung spezifischer kryptographischer Algorithmen bei AH:

                        \begin{itemize}
                            \item
                                  Authentifizierung: HMAC-MD5-96, HMAC-SHA1-96, HMAC-SHA2, ...
                            \item
                                  Wenn sowohl ESP als auch AH von einer Stelle angewendet werden
                                  sollen, wird immer zuerst ESP angewendet:
                        \end{itemize}
                  \item
                        Dies führt dazu, dass AH der äußere Header ist.
                  \item
                        ,,Vorteil'': der IP-Header kann auch durch AH geschützt werden
                  \item
                        Anmerkung: Für jede Richtung werden zwei SAs (je eine für AH, ESP)
                        benötigt.
              \end{itemize}
        \item
              Im Tunnelmodus stellt die Nutzlast ein vollständiges IP-Paket dar

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-authentication-header.png}
              \end{itemize}
        \item
              Obwohl AH auch den äußeren IP-Header schützt, dürfen einige seiner
              Felder nicht geschützt werden, da sie sich während der Übertragung
              ändern können:

              \begin{itemize}
                  \item
                        Dies gilt auch für veränderliche IPv4-Optionen oder
                        IPv6-Erweiterungen.
                  \item
                        Solche Felder werden bei der Berechnung des MAC als Null angenommen
                  \item
                        % \includegraphics{Assets/NetworkSecurity-authentication-header-2.png}
              \end{itemize}
        \item
              Alle unveränderlichen Felder, Optionen und Erweiterungen (grau) sind
              geschützt
        \item
              % \includegraphics{Assets/NetworkSecurity-AH-Ausgangsbearbeitung.png}
        \item
              % \includegraphics{Assets/NetworkSecurity-AH-prepare-header.png}
        \item
              % \includegraphics{Assets/NetworkSecurity-AH-inbound-processing-1.png}
        \item
              % \includegraphics{Assets/NetworkSecurity-AH-inbound-processing-2.png}
    \end{itemize}


    \subsection{IPsec's Verwendung von kryptographischen
        Algorithmen}

    \begin{itemize}
        \item
              Vertraulichkeit (nur ESP):

              \begin{itemize}
                  \item
                        Die Verwendung von DES mit ESP {[}RFC4303{]} wird nicht mehr
                        empfohlen
                  \item
                        AES-CBC, definiert in RFC 3602, ist vielleicht "der"
                        Standardalgorithmus
                  \item
                        Der Initialisierungsvektor (IV) ist immer im Klartext enthalten, um
                        Synchronisationsprobleme zu vermeiden.
                  \item
                        Der gesamte IV soll zufällig sein
                  \item
                        Nehmen Sie KEINE weiteren IVs aus früheren Chiffretexten!

                        \begin{itemize}
                            \item
                                  Sicherheitsprobleme
                            \item
                                  Synchronisationsprobleme
                        \end{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-ipsec-protect-payload.png}
              \end{itemize}
        \item
              Authentifizierung der Datenherkunft (AH und ESP):

              \begin{itemize}
                  \item
                        Einige der Algorithmen zur Authentifizierung sind bereits definiert:

                        \begin{itemize}
                            \item
                                  HMAC-MD5-96 mit Schlüssellänge 128 Bit
                            \item
                                  HMAC-SHA1-96 mit Schlüssellänge 160 Bit
                            \item
                                  HMAC-RIPEMD160-96 mit einer Schlüssellänge von 160 Bit
                            \item
                                  HMAC-SHA2 mit Schlüssellängen von 256, 384 und 512 Bit
                        \end{itemize}
                  \item
                        Alle diese Algorithmen verwenden die in {[}RFC2104{]} definierte
                        HMAC-Konstruktion:

                        \begin{itemize}
                            \item
                                  ipad = 0x36 wiederholt B mal (B = 64 für die oben genannten
                                  Algorithmen)
                            \item
                                  opad = 0x5C, B-mal wiederholt
                            \item
                                  HMAC = H(Key XOR opad, H(Key XOR ipad, data)), wobei H die
                                  verwendete kryptografische Hash-Funktion angibt
                        \end{itemize}
                  \item
                        Das ,,-96'' in den oben genannten Algorithmen bedeutet, dass die
                        Ausgabe der Hash-Funktion auf die 96 ganz linken Bits gekürzt wird
                  \item
                        SHA2 abgeschnitten auf die Hälfte der Schlüssellänge
                  \item
                        Dieser Wert erfüllt die meisten Sicherheitsanforderungen gut
              \end{itemize}
    \end{itemize}


    \subsection{Aufbau von
        Sicherheitsassoziationen}

    \begin{itemize}
        \item
              Bevor ein Paket durch IPsec geschützt werden kann, muss eine SA
              zwischen den beiden ,,kryptographischen Endpunkten'', die den Schutz
              bieten, eingerichtet werden
        \item
              Der Aufbau einer SA kann realisiert werden:

              \begin{itemize}
                  \item
                        Manuell, durch proprietäre Methoden der Systemverwaltung
                  \item
                        Dynamisch, durch ein standardisiertes Authentifizierungs- und
                        Schlüsselverwaltungsprotokoll
                  \item
                        Die manuelle Einrichtung sollte nur in sehr eingeschränkten
                        Konfigurationen (z.B. zwischen zwei verschlüsselnden Firewalls eines
                        VPN) und während einer Übergangsphase verwendet werden
              \end{itemize}
        \item
              IPsec definiert eine standardisierte Methode für den SA-Aufbau:

              \begin{itemize}
                  \item
                        Internet Security Association and Key Management Protocol (ISAKMP)

                        \begin{itemize}
                            \item
                                  Definiert Protokollformate und Verfahren für die
                                  Sicherheitsaushandlung
                        \end{itemize}
                  \item
                        Internet-Schlüsselaustausch (IKE)

                        \begin{itemize}
                            \item
                                  Definiert das Standard-Authentifizierungs- und
                                  Schlüsselaustauschprotokoll von IPsec
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{ISAKMP - Einführung}

    \begin{itemize}
        \item
              Die IETF hat zwei RFCs zu ISAKMP für IPsec verabschiedet:

              \begin{itemize}
                  \item
                        RFC 2408, der das ISAKMP-Basisprotokoll definiert
                  \item
                        RFC 2407, der die ,,domain of interpretation'' (DOI) von IPsec für
                        ISAKMP definiert und die für IPsec spezifischen Nachrichtenformate
                        näher beschreibt
              \end{itemize}
        \item
              Das ISAKMP-Basisprotokoll ist ein generisches Protokoll, das für
              verschiedene Zwecke verwendet werden kann:

              \begin{itemize}
                  \item
                        Die für eine Anwendung von ISAKMP spezifischen Verfahren werden in
                        einem DOI-Dokument detailliert beschrieben.
                  \item
                        Es wurden weitere DOI-Dokumente erstellt:

                        \begin{itemize}
                            \item
                                  Group DOI für sichere Gruppenkommunikation {[}RFC6407{]}
                            \item
                                  MAP DOI für die Verwendung von ISAKMP zum Aufbau von SAs zur
                                  Sicherung des Mobile Application Protocol (MAP) von GSM (Internet
                                  Draft, Nov. 2000)
                        \end{itemize}
              \end{itemize}
        \item
              ISAKMP definiert zwei grundlegende Kategorien von Austauschvorgängen:

              \begin{itemize}
                  \item
                        Phase 1 Austausch, bei dem eine Art von ,,Master SA'' ausgehandelt
                        wird
                  \item
                        Phase 2 Austausch, der die ,,Master SA'' verwendet, um andere SAs zu
                        etablieren
              \end{itemize}
    \end{itemize}


    \subsubsection{ISAKMP - Grundlegendes
        Nachrichtenformat}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-ISAKMP-format.png}
        \item
              Initiator \& Responder Cookie:

              \begin{itemize}
                  \item
                        Identifizieren einen ISAKMP-Austausch bzw. eine
                        Sicherheitsassoziation
                  \item
                        Dienen auch als begrenzter Schutz gegen Denial-of-Service-Angriffe
                        (siehe unten)
              \end{itemize}
        \item
              Nächste Nutzlast: gibt an, welcher ISAKMP-Nutzlasttyp die erste
              Nutzlast der Nachricht ist
        \item
              Major \& Minor Version: gibt die Version des ISAKMP-Protokolls an
        \item
              Austausch-Typ:

              \begin{itemize}
                  \item
                        Gibt die Art des verwendeten Austauschs an
                  \item
                        Es gibt fünf vordefinierte generische Austauschtypen, weitere Typen
                        können pro DOI definiert werden
              \end{itemize}
        \item
              Flags:

              \begin{itemize}
                  \item
                        Encrypt: wenn auf eins gesetzt, wird die Nutzlast nach dem Header
                        verschlüsselt
                  \item
                        Commit: wird für die Schlüsselsynchronisation verwendet
                  \item
                        Authenticate only: wenn auf eins gesetzt, wird nur der Schutz der
                        Datenursprungsauthentifizierung auf die ISAKMP-Nutzdaten angewendet
                        und keine Verschlüsselung durchgeführt
              \end{itemize}
        \item
              Nachrichten-ID:

              \begin{itemize}
                  \item
                        Dient zur Identifizierung von Nachrichten, die zu verschiedenen
                        Austauschen gehören
              \end{itemize}
        \item
              Nachrichtenlänge:

              \begin{itemize}
                  \item
                        Gesamtlänge der Nachricht (Header + Payload)
              \end{itemize}
        \item
              Nutzlast:

              \begin{itemize}
                  \item
                        Die Nutzlast einer ISAKMP-Nachricht kann tatsächlich mehrere
                        ,,verkettete'' Nutzlasten enthalten
                  \item
                        Der Nutzlasttyp der ersten Nutzlast in der Nachricht wird im
                        nächsten Nutzlastfeld des ISAKMP-Headers angegeben
                  \item
                        Alle ISAKMP-Nutzdaten haben einen gemeinsamen Nutzdaten-Header:

                        \begin{itemize}
                            \item
                                  % \includegraphics{Assets/NetworkSecurity-ISAKMP-payload.png}
                            \item
                                  Next Header: der Payload-Typ des nächsten Payloads in der
                                  Nachricht
                            \item
                                  Payload Length: Gesamtlänge der aktuellen Payload (einschließlich
                                  dieses Headers)
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsubsection{ISAKMP - Begrenzter Schutz vor Denial of
        Service}

    \begin{itemize}
        \item
              Die Initiator- und Responder-Cookies dienen auch als Schutz gegen
              einfache Denial-of-Service-Angriffe:

              \begin{itemize}
                  \item
                        Authentifizierung und Schlüsselaustausch erfordern oft ,,teure''
                        Berechnungen, z.B. Potenzierung (für Diffie-Hellman
                        Schlüsselaustausch)
                  \item
                        Um zu verhindern, dass ein Angreifer eine ISAKMP-Einheit mit
                        gefälschten Nachrichten von gefälschten Quelladressen überschwemmen
                        und diese teuren Operationen verursachen kann, wird das folgende
                        Schema verwendet:

                        \begin{itemize}
                            \item
                                  Die initiierende ISAKMP-Entität erzeugt einen Initiator-Cookie:
                                  \$CKY-I = H(Secret\_\{Initiator\}, Address\_\{Responder\},
                                  t\_\{Initiator\})\$
                            \item
                                  Der Responder generiert sein eigenes Cookie: \$CKY-R =
                                  H(Secret\_\{Responder\}, Address\_\{Initiator\},
                                  t\_\{Responder\})\$
                            \item
                                  Beide Entitäten schließen immer beide Cookies ein und überprüfen
                                  immer ihr eigenes Cookie, bevor sie eine teure Operation
                                  durchführen
                            \item
                                  Der oben erwähnte Angriff wird daher nicht erfolgreich sein, da
                                  der Angreifer eine Antwort von dem angegriffenen System erhalten
                                  muss, um ein Cookie von ihm zu erhalten
                        \end{itemize}
                  \item
                        ISAKMP spezifiziert die genaue Cookie-Erzeugungsmethode nicht
              \end{itemize}
    \end{itemize}


    \subsubsection{ISAKMP - Nutzdatenarten}

    \begin{itemize}
        \item
              RFC 2408 definiert verschiedene Nutzdaten von ISAKMP (Liste ist nicht
              vollständig):

              \begin{itemize}
                  \item
                        Generische Payloads: Hash, Signatur, Nonce, Vendor ID,
                        Schlüsselaustausch
                  \item
                        Spezifische Payloads: SA, Zertifikat, Zertifikatsanforderung,
                        Identifikation
                  \item
                        Abhängige und gekapselte Nutzdaten:

                        \begin{itemize}
                            \item
                                  Proposal-Payload: beschreibt einen Vorschlag für die
                                  SA-Verhandlung
                            \item
                                  Transform-Payload: beschreibt eine Transformation eines Proposals
                        \end{itemize}
                  \item
                        Außerdem gibt es eine generische Attribut-Nutzlast:

                        \begin{itemize}
                            \item
                                  Dies ist eigentlich kein ISAKMP-Payload, sondern ein Payload, der
                                  innerhalb der ISAKMP-Payloads erscheint.
                            \item
                                  Alle Attribut-Payloads haben eine gemeinsame Struktur:
                            \item
                                  % \includegraphics{Assets/NetworkSecurity-ISAKMP-payload-types.png}
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsubsection{ISAKMP - Die
        Sicherheits-Assoziations-Nutzdaten}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-ISAKMP-security-payload.png}
        \item
              Domain of Interpretation definiert die Anwendungsdomäne für die
              auszuhandelnde SA, z.B. IPsec
        \item
              Situation ist ein DOI-spezifisches Feld, das die Situation angibt, in
              der die aktuelle Verhandlung stattfindet (z. B. Notruf vs. normaler
              Anruf)
        \item
              Auf den SA-Payload folgen ein oder mehrere Proposal-Payloads
    \end{itemize}


    \subsubsection{ISAKMP - Die
        Vorschlagsnutzdaten}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-ISAKMP-proposal-payload.png}
        \item
              Proposal \# wird verwendet, um Richtlinien auszudrücken und Vorschläge
              auszuhandeln:

              \begin{itemize}
                  \item
                        Wenn zwei oder mehr Vorschläge die gleiche Nummer tragen, wird ein
                        logisches UND realisiert.
                  \item
                        Unterschiedliche Werte für Proposal \# realisieren logisches OR mit
                        absteigender Priorität
              \end{itemize}
        \item
              Protocol ID gibt den Protokoll-Identifikator der aktuellen Verhandlung
              an, z. B. AH oder ESP (für IPsec)
        \item
              SPI Size gibt die Länge des enthaltenen SPI-Wertes an
        \item
              Number of Transforms (Anzahl der Transformationen) gibt an, wie viele
              Transformationen zu diesem Vorschlag gehören (diese folgen unmittelbar
              auf die Nutzlast des Vorschlags)
    \end{itemize}


    \subsubsection{ISAKMP - Die
        Transformations-Nutzdaten}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-ISAKMP-transform-payload.png}
        \item
              Eine Transform-Payload spezifiziert einen bestimmten
              Sicherheitsmechanismus, auch Transform genannt, der zur Sicherung des
              Kommunikationskanals verwendet werden soll.
        \item
              Jede in einem Vorschlag aufgeführte Transformation hat eine eindeutige
              Transform \#
        \item
              Jede Transformation wird durch eine Transform-ID eindeutig
              identifiziert, z.B. 3DES, AES, MD5, SHA-1, etc.

              \begin{itemize}
                  \item
                        Die Transformations-IDs werden in einem DOI-Dokument angegeben.
              \end{itemize}
        \item
              Die SA-Attribute geben die Attribute an, die für die im Feld Transform
              ID angegebene Transformation definiert sind.
    \end{itemize}


    \subsubsection{ISAKMP - SA-Verhandlung}

    \begin{itemize}
        \item
              Inhalt des Next Payload-Feldes von SA-, Proposal- und
              Transform-Payloads:

              \begin{itemize}
                  \item
                        Das Next-Payload-Feld einer SA-Payload gibt nicht die unmittelbar
                        folgende Proposal-Payload an, da diese implizit ist.
                  \item
                        Das Gleiche gilt für Proposal- und Transform-Payloads
              \end{itemize}
        \item
              Die Proposal-Payload gibt der initiierenden Entität die Möglichkeit,
              der antwortenden Entität die Sicherheitsprotokolle und zugehörigen
              Sicherheitsmechanismen zur Verwendung mit der auszuhandelnden
              Sicherheitsassoziation zu präsentieren.
        \item
              Wenn die SA-Etablierung für eine kombinierte Schutzsuite ausgehandelt
              wird, die aus mehreren Protokollen besteht, muss es mehrere
              Proposal-Payloads geben, die jeweils die gleiche Proposal-Nummer
              haben.
        \item
              Diese Vorschläge müssen als eine Einheit betrachtet werden und dürfen
              nicht durch einen Vorschlag mit einer anderen Vorschlagsnummer
              getrennt werden.
        \item
              Dieses erste Beispiel zeigt eine ESP- UND AH-Schutzsuite:

              \begin{itemize}
                  \item
                        Das erste Protokoll wird mit zwei von der vorschlagenden Stelle
                        unterstützten Transformationen dargestellt, ESP mit:

                        \begin{itemize}
                            \item
                                  Transformation 1 als 3DES
                            \item
                                  Umwandlung 2 als AES
                            \item
                                  Der Responder muss zwischen den beiden für ESP vorgeschlagenen
                                  Transformationen wählen.
                        \end{itemize}
                  \item
                        Das zweite Protokoll ist AH und wird mit einer einzigen
                        Transformation angeboten:

                        \begin{itemize}
                            \item
                                  Umwandlung 1 als SHA
                        \end{itemize}
                  \item
                        Die resultierende Schutzsuite ist entweder

                        \begin{itemize}
                            \item
                                  3DES und SHA, oder
                            \item
                                  AES und SHA, je nachdem, welche ESP-Transformation vom Responder
                                  gewählt wurde
                        \end{itemize}
                  \item
                        In diesem Fall folgen auf die SA-Nutzdaten die folgenden Nutzdaten:

                        \begin{itemize}
                            \item
                                  {[}Vorschlag 1, ESP, (Transform 1, 3DES, ...), (Transform 2,
                                  AES){]} {[}Vorschlag 1, AH, (Transform 1, SHA){]}
                        \end{itemize}
                  \item
                        Bitte beachten Sie, dass dies zu zwei SAs pro Richtung führt!
              \end{itemize}
        \item
              Dieses zweite Beispiel zeigt einen Vorschlag für zwei verschiedene
              Schutzsuiten:

              \begin{itemize}
                  \item
                        Die erste Schutzsuite wird vorgestellt mit:

                        \begin{itemize}
                            \item
                                  einer Transformation (MD5) für das erste Protokoll (AH), und
                            \item
                                  eine Umwandlung (3DES) für das zweite Protokoll (ESP)
                        \end{itemize}
                  \item
                        Die zweite Schutzsuite wird mit zwei Transformationen für ein
                        einziges Protokoll (ESP) vorgestellt:

                        \begin{itemize}
                            \item
                                  3DES, oder
                            \item
                                  AES
                        \end{itemize}
                  \item
                        Bitte beachten Sie, dass es nicht möglich ist, festzulegen, dass
                        Transformation 1 und Transformation 2 für eine Instanz einer
                        Protokollspezifikation verwendet werden müssen.
                  \item
                        In diesem Fall folgen auf den SA-Payload die folgenden Payloads:

                        \begin{itemize}
                            \item
                                  {[}Vorschlag 1, AH, (Transform 1, MD5, ...){]} {[}Vorschlag 1,
                                  ESP, (Transform 1, 3DES, ...){]} {[}Vorschlag 2, ESP, (Transform1,
                                  3DES, ...), (Transform 2, AES, ...){]}
                        \end{itemize}
                  \item
                        Bitte beachten Sie, dass Vorschlag 1 zu zwei SAs pro Richtung führt.
              \end{itemize}
        \item
              Bei der Beantwortung einer Security-Association-Nutzlast muss der
              Antwortende eine Security-Association-Nutzlast mit dem ausgewählten
              Vorschlag senden, der aus mehreren Proposal-Nutzlasten und den
              zugehörigen Transform-Nutzlasten bestehen kann
        \item
              Jede der Proposal-Payloads muss eine einzelne Transform-Payload
              enthalten, die dem Protokoll zugeordnet ist.
        \item
              Der Antwortende sollte das Feld Proposal \# in der Proposal-Payload
              und das Feld Transform \# in jeder Transform-Payload des ausgewählten
              Vorschlags beibehalten.

              \begin{itemize}
                  \item
                        Die Beibehaltung der Vorschlags- und Transformationsnummern sollte
                        die Protokollverarbeitung des Initiators beschleunigen, da die
                        Auswahl des Antwortenden nicht mit jeder angebotenen Option
                        verglichen werden muss.
                  \item
                        Diese Werte ermöglichen es dem Initiator, den Vergleich direkt und
                        schnell durchzuführen.
              \end{itemize}
        \item
              Der Initiator muss überprüfen, ob die vom Responder empfangene
              SA-Nutzlast mit einem der ursprünglich gesendeten Vorschläge
              übereinstimmt
    \end{itemize}


    \subsubsection{ISAKMP - Session Key
        Establishment}

    \begin{itemize}
        \item
              ISAKMP baut 4 verschiedene Schlüssel mit einem
              Authentifizierungsaustausch auf:

              \begin{itemize}
                  \item
                        SKEYID ist eine Zeichenkette, die aus geheimem Material abgeleitet
                        wird, das nur den aktiven Teilnehmern des Austauschs bekannt ist und
                        als ,,Hauptschlüssel'' dient.

                        \begin{itemize}
                            \item
                                  Die Berechnung von SKEYID ist abhängig von der
                                  Authentifizierungsmethode
                        \end{itemize}
                  \item
                        SKEYID\_e ist das Schlüsselmaterial, das von der ISAKMP SA zum
                        Schutz der Vertraulichkeit ihrer Nachrichten verwendet wird
                  \item
                        SKEYID\_a ist das Schlüsselmaterial, das von der ISAKMP SA zur
                        Authentifizierung ihrer Nachrichten verwendet wird
                  \item
                        SKEYID\_d ist das Verschlüsselungsmaterial, das zur Ableitung von
                        Schlüsseln für Nicht-ISAKMP-Sicherheitsassoziationen verwendet wird.
              \end{itemize}
    \end{itemize}


    \subsection{IKE - Einführung}

    \begin{itemize}
        \item
              Während ISAKMP die grundlegenden Datenformate und Verfahren zur
              Aushandlung beliebiger SAs definiert, spezifiziert der Internet Key
              Exchange das standardisierte Protokoll zur Aushandlung von IPsec SAs
        \item
              IKE definiert fünf Austauschvorgänge:

              \begin{itemize}
                  \item
                        Phase-1-Austausch für die Einrichtung einer IKE SA :

                        \begin{itemize}
                            \item
                                  Main-Mode-Austausch, der durch 6 ausgetauschte Nachrichten
                                  realisiert wird
                            \item
                                  Aggressive mode exchange, der nur 3 Nachrichten benötigt
                        \end{itemize}
                  \item
                        Phase 2 Austausch für die Einrichtung von IPsec SAs:

                        \begin{itemize}
                            \item
                                  Quick-Mode-Austausch, der mit 3 Nachrichten realisiert wird
                        \end{itemize}
                  \item
                        Andere Austausche:

                        \begin{itemize}
                            \item
                                  Informationsaustausch zur Übermittlung von Status- und
                                  Fehlermeldungen
                            \item
                                  Neuer Gruppenaustausch zur Vereinbarung von privaten
                                  Diffie-Hellman-Gruppen
                        \end{itemize}
              \end{itemize}
        \item
              Hinweis: Auf den folgenden Folien steht HMAC(K, x \textbar{} y
              \textbar{} ...) für H(K, p 1 , H(K, p 2 , x, y, ...)), wobei p 1 und p
              2 Auffüllmuster bezeichnen
    \end{itemize}


    \subsubsection{IKE - Berechnung von
        IKE-Sitzungsschlüsseln}

    \begin{itemize}
        \item
              IKE baut vier verschiedene Schlüssel mit einem
              Authentifizierungsaustausch auf:

              \begin{itemize}
                  \item
                        SKEYID ist eine Zeichenkette, die aus geheimem Material abgeleitet
                        wird, das nur den aktiven Teilnehmern des Austauschs bekannt ist,
                        und die als ,,Hauptschlüssel'' dient.

                        \begin{itemize}
                            \item
                                  Die Berechnung von SKEYID ist abhängig von der
                                  Authentifizierungsmethode
                        \end{itemize}
                  \item
                        SKEYID\_d ist das Keying-Material, das zur Ableitung von Schlüsseln
                        für Nicht-IKE-SAs verwendet wird

                        \begin{itemize}
                            \item
                                  SKEYID\_d = \$HMAC(SKEYID, g\^{}\{xy\} \textbar{} CKY-I \textbar{}
                                  CKY-R \textbar{} 0)\$, wobei \$g\^{}\{xy\}\$ das gemeinsame
                                  Diffie-Hellman-Geheimnis bezeichnet
                        \end{itemize}
                  \item
                        SKEYID\_a ist das Schlüsselmaterial, das von der IKE SA zur
                        Authentifizierung ihrer Nachrichten verwendet wird

                        \begin{itemize}
                            \item
                                  SKEYID\_a = \$HMAC(SKEYID, SKEYID\_d \textbar{} g\^{}\{xy\}
                                  \textbar{} CKY-I \textbar{} CKY-R \textbar{} 1)\$
                        \end{itemize}
                  \item
                        SKEYID\_e ist das Schlüsselmaterial, das von der IKE SA zum Schutz
                        der Vertraulichkeit ihrer Nachrichten verwendet wird

                        \begin{itemize}
                            \item
                                  SKEYID\_e = \$HMAC(SKEYID, SKEYID\_a \textbar{} g\^{}\{xy\}
                                  \textbar{} CKY-I \textbar{} CKY-R \textbar{} 2)\$
                        \end{itemize}
              \end{itemize}
        \item
              Falls erforderlich, werden die Schlüssel nach der folgenden Methode
              erweitert:

              \begin{itemize}
                  \item
                        \$K=(K\_1 \textbar{} K\_2 \textbar{} ...)\$ mit \$K\_i =
                        HMAC(SKEYID, K\_\{i-1\})\$ und \$K\_0 = 0\$
              \end{itemize}
    \end{itemize}


    \subsubsection{IKE -
        Authentifizierungsmethoden}

    \begin{itemize}
        \item
              Phase 1 IKE-Austausche werden mit Hilfe von zwei Hash-Werten Hash-I
              und Hash-R authentifiziert, die vom Initiator und vom Responder
              erstellt werden:

              \begin{itemize}
                  \item
                        Hash-I = HMAC(SKEYID, gx \textbar{} gy \textbar{} CKY-I \textbar{}
                        CKY-R \textbar{} SA-Angebot \textbar{} ID-I)
                  \item
                        Hash-R = HMAC(SKEYID, gy \textbar{} gx \textbar{} CKY-R \textbar{}
                        CKY-I \textbar{} SA-offer \textbar{} ID-R) wobei gx, gy die
                        ausgetauschten öffentlichen Diffie-Hellman-Werte bezeichnen ID-I,
                        ID-R bezeichnen die Identität des Initiators und des Responders
                        SA-offer bezeichnet die Nutzdaten bezüglich der SA-Verhandlung
              \end{itemize}
        \item
              IKE unterstützt vier verschiedene Methoden der Authentifizierung:

              \begin{itemize}
                  \item
                        Pre-shared Key:

                        \begin{itemize}
                            \item
                                  SKYEID = \$HMAC(K\_\{Initiator\}, Responder , r\_\{Initiator\}
                                  \textbar{} r\_\{Responder\})\$
                        \end{itemize}
                  \item
                        Zwei verschiedene Formen der Authentifizierung mit
                        Public-Key-Verschlüsselung:

                        \begin{itemize}
                            \item
                                  SKEYID = \$HMAC(H(r\_\{Initiator\}, r\_\{Responder\}), CKY-I
                                  \textbar{} CKY-R)
                        \end{itemize}
                  \item
                        Digitale Unterschrift:

                        \begin{itemize}
                            \item
                                  SKEYID = \$HMAC((r\_\{Initiator\} \textbar{} r\_\{Responder\}),
                                  g\^{}\{xy\})\$
                            \item
                                  Da in diesem Fall SKEYID selbst keine Authentifizierung bietet,
                                  werden die Werte Hash-I und Hash-R vom Initiator/Responder
                                  signiert
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsubsection{IKE - Main Mode Austausch mit Pre-Shared
        Key}

    \begin{itemize}
        \item
              Die folgenden Beschreibungen listen die ausgetauschten ISAKMP- und
              IKE-Payloads auf, wenn verschiedene ,,Flavors'' der
              IKE-Authentifizierung durchgeführt werden:

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-IKE-exchange-payloads.png}
                  \item
                        \$N\_i, N\_r\$ bezeichnen \$r\_\{Initiiator\}, r\_\{Responder\}\$
                        (IKE-Notation)
                  \item
                        \$ID\_i, ID\_r\$ bezeichnen die Identität des Initiators und des
                        Responders
                  \item
                        \$KE\$ bezeichnet die öffentlichen Werte eines DH-Austausches
              \end{itemize}
        \item
              Bitte beachten Sie, dass Hash-I und Hash-R nicht signiert werden
              müssen, da sie bereits ,,ein authentisches Geheimnis'' (Pre-Shared
              Key) enthalten
    \end{itemize}


    \subsubsection{IKE - Hauptmodus Austausch mit
        Signaturen}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-IKE-exchange-payload-signature.png}

              \begin{itemize}
                  \item
                        \$(m)\$ gibt an, dass m optional ist
                  \item
                        \$I{[}m{]}\$ bedeutet, dass I m signiert
              \end{itemize}
        \item
              Bitte beachten Sie, dass Hash-I und Hash-R signiert werden müssen, da
              sie nichts enthalten, von dem bekannt ist, dass es authentisch ist
    \end{itemize}


    \subsubsection{IKE - Main Mode Exchange mit Public Key
        Encryption}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-IKE-exchange-public-key.png}

              \begin{itemize}
                  \item
                        wobei: \$\{m\}\_\{+KI\}\$ bedeutet, dass m mit dem öffentlichen
                        Schlüssel \$+K\_I\$ verschlüsselt ist
                  \item
                        Bitte beachten Sie, dass Hash-I und Hash-R nicht signiert werden
                        müssen, da sie die ausgetauschten Zufallszahlen Ni bzw. Nr
                        ,,enthalten''.

                        \begin{itemize}
                            \item
                                  Jede Entität beweist also ihre Authentizität, indem sie die
                                  empfangene Zufallszahl ( Ni oder Nr ) mit ihrem privaten Schlüssel
                                  entschlüsselt
                        \end{itemize}
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-IKE-exchange-public-key-2.png}

              \begin{itemize}
                  \item
                        wobei: \$\{m\}\_\{+KI\}\$ bedeutet, dass m mit dem öffentlichen
                        Schlüssel \$+K\_I\$ verschlüsselt ist
                  \item
                        \$\{m\}\_\{K\_i\}\$ bedeutet, dass m mit dem symmetrischen Schlüssel
                        \$K\_i\$ mit \$K\_i=H(N\_i, CKY-I)\$ und \$K\_r=H(N\_r,CKY-R)\$
                        verschlüsselt ist
                  \item
                        Bitte beachten Sie, dass alle bisher beschriebenen Schemata einen
                        Schutz der Identität vor Abhörern im Internet bieten, da die IDs und
                        Zertifikate nicht im Klartext gesendet werden:
                  \item
                        Die IP-Adressen der ausgetauschten Pakete sind jedoch immer
                        lesbar...
              \end{itemize}
    \end{itemize}


    \subsubsection{IKE - Aggressiver Modus Austausch mit Pre-Shared
        Key}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-IKE-aggressive-mode.png}
        \item
              Da die Identität des Initiators und des Responders gesendet werden
              muss, bevor ein Sitzungsschlüssel erstellt werden kann, kann der
              Austausch im aggressiven Modus keinen Identitätsschutz vor Abhörern
              bieten
        \item
              Ähnliche Varianten des aggressiven Modus gibt es auch für die
              Authentifizierung mit:

              \begin{itemize}
                  \item
                        Digitale Signatur
                  \item
                        Verschlüsselung mit öffentlichem Schlüssel
              \end{itemize}
    \end{itemize}


    \subsubsection{IKE - Quick Mode
        Exchange}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-IKE-quick-mode.png}
        \item
              \$Hash1 = HMAC(SKEYID\_a, M-ID \textbar{} SA \textbar{} Ni \textbar{}
              {[} \textbar{} KE {]} {[} \textbar{} ID\_\{ci\} \textbar{}
              ID\_\{cr\}{]} )\$
        \item
              \$Hash2 = HMAC(SKEYID\_a, M-ID \textbar{} N\_i \textbar{} SA
              \textbar{} N\_r \textbar{} {[} \textbar{} KE {]} {[} \textbar{}
              ID\_\{ci\} \textbar{} ID\_\{cr\}{]} )
        \item
              \$Hash3 = HMAC(SKEYID\_a, 0 \textbar{} M-ID \textbar{} N\_i \textbar{}
              N\_r)\$
        \item
              Die optionale Einbeziehung der Identitäten \$ID\_\{ci\}\$ und
              \$ID\_\{cr\}\$ ermöglicht es ISAKMP-Entitäten, eine SA im Namen
              anderer Clients einzurichten (Gateway-Szenario)
        \item
              Die optionalen Schlüsselaustausch-Payloads KE ermöglichen die
              Durchführung eines neuen DH-Austauschs, wenn perfekte Forward Secrecy
              gewünscht ist
        \item
              Sitzungsschlüsselmaterial \$= HMAC(SKEYID\_d, {[} g\^{}\{xy\}
              \textbar{} {]} protocol \textbar{} SPI \textbar{} N\_i \textbar{}
              N\_r)\$
    \end{itemize}


    \subsection{Weitere Probleme mit
        IPsec}

    \begin{itemize}
        \item
              Komprimierung:

              \begin{itemize}
                  \item
                        Wenn Verschlüsselung verwendet wird, dann können die resultierenden
                        IP-Pakete nicht in der Verbindungsschicht komprimiert werden, z.B.
                        bei einer Verbindung zu einem ISP über Modem
                  \item
                        Daher wurde das IP Payload Compression Protocol (PCP) definiert
                  \item
                        PCP kann mit IPsec verwendet werden:

                        \begin{itemize}
                            \item
                                  In der IPsec-Policy-Definition kann PCP festgelegt werden.
                            \item
                                  Die IKE SA-Verhandlung ermöglicht die Aufnahme von PCP in die
                                  Vorschläge
                        \end{itemize}
              \end{itemize}
        \item
              Interoperabilitätsprobleme bei End-to-End-Sicherheit mit
              Header-Verarbeitung in Zwischenknoten:

              \begin{itemize}
                  \item
                        Interoperabilität mit Firewalls:

                        \begin{itemize}
                            \item
                                  Die Ende-zu-Ende-Verschlüsselung kollidiert mit der Notwendigkeit
                                  von Firewalls, die Protokoll-Header der oberen Schichten in
                                  IP-Paketen zu prüfen.
                        \end{itemize}
                  \item
                        Interoperabilität mit Network Address Translation (NAT):

                        \begin{itemize}
                            \item
                                  Verschlüsselte Pakete lassen weder eine Analyse noch eine Änderung
                                  der Adressen zu.
                            \item
                                  Authentifizierte Pakete werden verworfen, wenn die Quell- oder
                                  Zieladresse geändert wird.
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Schlussfolgerung}

    \begin{itemize}
        \item
              IPsec ist die Sicherheitsarchitektur der IETF für das
              Internet-Protokoll
        \item
              Sie bietet die folgenden Sicherheitsdienste für IP-Pakete:

              \begin{itemize}
                  \item
                        Authentifizierung der Datenherkunft
                  \item
                        Schutz vor Wiederholung
                  \item
                        Vertraulichkeit
              \end{itemize}
        \item
              Es kann in Endsystemen oder Zwischensystemen realisiert werden:

              \begin{itemize}
                  \item
                        Implementierung im Endsystem: Integriertes Betriebssystem oder
                        ,,bump in the stack''
                  \item
                        Gateway-Implementierung: Integrierter Router oder ,,bump in the
                        wire''
              \end{itemize}
        \item
              Es wurden zwei grundlegende Sicherheitsprotokolle definiert:

              \begin{itemize}
                  \item
                        Authentifizierungs-Header (AH)
                  \item
                        Encapsulating security payload (ESP)
              \end{itemize}
        \item
              SA-Verhandlung und Schlüsselverwaltung werden mit folgenden
              Protokollen realisiert:

              \begin{itemize}
                  \item
                        Internet security association key management protocol (ISAKMP)
                  \item
                        Internet-Schlüsselaustausch (IKE)
              \end{itemize}
    \end{itemize}


    \subsection{Neue Wege in der
        IPsec-Entwicklung}

    \begin{itemize}
        \item
              Internet-Schlüsselaustausch Version 2

              \begin{itemize}
                  \item
                        Basierend auf den Erkenntnissen aus IKEv1
                  \item
                        Wesentliche Vereinfachungen
              \end{itemize}
        \item
              Netzwerkadressübersetzung (NAT)

              \begin{itemize}
                  \item
                        Beispiel für Probleme mit NAT und IPsec
                  \item
                        NAT-Überwindung
                  \item
                        Bound-End-to-End Tunnel Mode (BEET)
              \end{itemize}
        \item
              Konfiguration von großen IPsec-Infrastrukturen
    \end{itemize}


    \subsection{Internet Key Exchange Protocol Version 2
    {[}RFC5996{]}}

    Zusätzliche Designziele zu IKEv1

    \begin{itemize}
        \item
              Konsolidierung von mehreren IKEv1-RFCs (und mehreren Erweiterungen)

              \begin{itemize}
                  \item
                        Erleichterung für Entwickler und Prüfer
                  \item
                        Klärung mehrerer unspezifischer Punkte
              \end{itemize}
        \item
              Vereinfachungen

              \begin{itemize}
                  \item
                        Anzahl der verschiedenen Schlüsselaustauschverfahren auf eines
                        reduziert
                  \item
                        Verschlüsselung wie in ESP
                  \item
                        Einfacher Anfrage/Antwort-Mechanismus
              \end{itemize}
        \item
              Verringerung der Latenzzeit
        \item
              Aushandlung von Verkehrsselektoren
        \item
              Graceful Changes, damit bestehende IKEv1-Software aufgerüstet werden
              kann
    \end{itemize}


    \subsubsection{IKEv2 -
        Schlüsselaustauschverfahren}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-IKEv2-exchange-procedure.png}

              \begin{itemize}
                  \item
                        \$K\$ Schlüssel abgeleitet durch \$PRF(PRF(N\_i \textbar\textbar{}
                        N\_r, g\^{}\{ir\}), N\_i \textbar\textbar{} N\_r \textbar\textbar{}
                        SPI\_i \textbar\textbar{} SPI\_r)\$
                  \item
                        \$PRF\$ ,,irgendeine'' Pseudozufallsfunktion - in der Regel eine
                        asymmetrische HMAC SIG-Signatur oder MAC über die ersten beiden
                        Nachrichten
                  \item
                        \$SAEx\$ ein Huckepack- ,,Quick-Mode-Austausch''
              \end{itemize}
        \item
              Nur ein einziger Austauschtyp
        \item
              Vier Nachrichten werden ausgetauscht \$(= 2 * RTT)\$
        \item
              Initiator löst alle erneuten Übertragungen aus
    \end{itemize}


    \subsubsection{IKEv2 - Eigenschaften des
        Schlüsselaustauschverfahrens}

    \begin{itemize}
        \item
              Der erste SA-Austausch erfolgt huckepack

              \begin{itemize}
                  \item
                        Geringere Latenz, da eine RTT eingespart wird
              \end{itemize}
        \item
              Nachricht 4 sollte huckepack mit Nachricht 2 ausgetauscht werden, aber

              \begin{itemize}
                  \item
                        Nachricht 3 verifiziert, dass Initiator Nachricht 2 erhalten hat
                        (SPI \textasciitilde{} Cookie)

                        \begin{itemize}
                            \item
                                  Dient als DoS-Schutz, wenn anschließend rechenintensive Aufgaben
                                  durchgeführt werden
                        \end{itemize}
                  \item
                        Identität des Responders wird erst nach Verifizierung des Initiators
                        offengelegt

                        \begin{itemize}
                            \item
                                  Schützt vor dem Scannen nach einer Partei mit einer bestimmten ID
                        \end{itemize}
                  \item
                        Initiator weiß nicht, wann es sicher ist, Daten zu senden

                        \begin{itemize}
                            \item
                                  (Pakete können in falscher Reihenfolge empfangen werden)
                        \end{itemize}
                  \item
                        Würde eine kompliziertere Strategie zur erneuten Übertragung
                        erfordern
                  \item
                        Responder kann nicht über eine Policy für die Child SA entscheiden
              \end{itemize}
    \end{itemize}


    \subsubsection{IKEv2 - Zusätzliche
        Funktionen}

    \begin{itemize}
        \item
              Zusätzlicher DoS-Schutz

              \begin{itemize}
                  \item
                        Im Falle eines DoS-Angriffs kann der Responder den Initiator
                        auffordern, ein zustandsloses Cookie zu senden
                  \item
                        Fügt dem Austausch 2 zusätzliche Nachrichten hinzu
              \end{itemize}
        \item
              Dead Peer Detection

              \begin{itemize}
                  \item
                        Regelmäßige IKE-Anfragen, um festzustellen, ob die SA gelöscht
                        werden kann
              \end{itemize}
        \item
              Flexiblere Verhandlungstechniken

              \begin{itemize}
                  \item
                        Möglichkeit der Angabe: ,,Verwenden Sie eine dieser Chiffren mit
                        einem dieser Authentifizierungsalgorithmen'' (es müssen nicht mehr
                        alle Kombinationen aufgezählt werden)
                  \item
                        Verkehrsselektoren können eingegrenzt werden

                        \begin{itemize}
                            \item
                                  Initiator: ,,Ich möchte 192.168.0.0/16 für meinen Tunnelmodus
                                  verwenden''
                            \item
                                  Antwortgeber: ,,OK, aber Sie dürfen nur 192.168.78.0/24
                                  verwenden''
                            \item
                                  Kann verwendet werden, um den Responder dem Initiator einen
                                  Adressbereich zuweisen zu lassen (in einfachen Situationen ohne /
                                  mit Hilfe von DHCP; siehe auch unten)
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Netzwerk-Adressübersetzung
        (NAT)}

    \begin{itemize}
        \item
              Heutzutage ein häufiges Problem: ISP stellt nur eine einzige
              IP-Adresse zur Verfügung, es sollen aber mehrere Geräte angeschlossen
              werden
        \item
              Lösung: Ein Router wird verwendet, um mehrere interne (private)
              Adressen auf eine einzige externe (öffentliche) Adresse abzubilden
        \item
              Häufigster Ansatz (vereinfacht):

              \begin{itemize}
                  \item
                        Für Pakete, die von der privaten Seite kommen:

                        \begin{itemize}
                            \item
                                  Der Router schreibt die TCP/UDP-Quellports auf einen eindeutigen
                                  Wert pro IP-Flow um
                            \item
                                  Speichert den neuen Quellport in einer Tabelle mit der
                                  Quelladresse und dem alten Quellport
                            \item
                                  Ersetzt die Quell-IP-Adresse durch die externe Adresse
                        \end{itemize}
                  \item
                        Für Pakete, die von der öffentlichen Seite kommen:

                        \begin{itemize}
                            \item
                                  Der Router sucht den IP-Fluss nach dem TCP/UDP-Zielport ab
                            \item
                                  Ersetzt die Zieladresse und den Port durch die alten Werte
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsubsection{NAT - Ein Beispiel}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-NAT-example.png}
        \item
              NAT ändert die Quelladresse eines jeden Pakets in eine öffentliche
              IP-Adresse mit anderen ("umgeschriebenen") Quellports
    \end{itemize}


    \subsubsection{Probleme mit NAT und IPsec -
        NAT-Traversal}

    \begin{itemize}
        \item
              Probleme:

              \begin{itemize}
                  \item
                        AH kann per Definition nicht mit NAT verwendet werden
                  \item
                        ESP bietet kein ,,wiederbeschreibbares Feld'' (wie Portnummer)
                  \item
                        TCP/UDP-Portnummern werden verschlüsselt oder authentifiziert (oder
                        beides)
              \end{itemize}
        \item
              Lösung für ESP: ESP-Pakete in normale UDP-Pakete einkapseln
              {[}RFC3948{]}

              \begin{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-NAT-encap-ESP.png}
              \end{itemize}
        \item
              UDP-Header enthält nur Portnummern und leere Prüfsumme

              \begin{itemize}
                  \item
                        Fügt 8 Byte Overhead hinzu
                  \item
                        Einziger Zweck: dem NAT-Gerät etwas zum ,,Umschreiben'' geben (um
                        die Empfänger der Pakete in der Antwort unterscheiden zu können)
                  \item
                        Port 4500 reserviert für NAT-T (NAT-Traversal)
              \end{itemize}
        \item
              Im Transport-Modus:

              \begin{itemize}
                  \item
                        Innere UDP/TCP-Prüfsumme hängt von der ursprünglichen Quelladresse
                        ab (Layering-Verletzung in der ursprünglichen TCP/IP-Suite)
                  \item
                        Muss wiederhergestellt werden
              \end{itemize}
        \item
              Wann ist NAT-T zu verwenden?

              \begin{itemize}
                  \item
                        NAT-Situation muss von IKE erkannt werden
                  \item
                        Erfolgt durch IKEv1-Erweiterung {[}RFC3947{]} und IKEv2
                  \item
                        IKE verwendet NAT-T, wenn der IKE-Quellport nicht 500 ist
                  \item
                        Funktioniert nicht immer, dann ist eine manuelle Konfiguration
                        erforderlich
              \end{itemize}
        \item
              Timeout-Probleme und Keep-Alives

              \begin{itemize}
                  \item
                        ESP-Pakete werden nicht periodisch ausgetauscht
                  \item
                        NAT-T-Ströme können im Router eine Zeitüberschreitung verursachen
                  \item
                        Eingehende Pakete können dann nicht zugestellt werden
                  \item
                        Regelmäßige Keep-Alive-Pakete stellen sicher, dass der Router seinen
                        Status beibehält
                  \item
                        Einfaches UDP-Paket an Port 4500 mit einem einzigen 0xFF-Oktett
              \end{itemize}
    \end{itemize}


    \subsubsection{Probleme mit NAT und IPsec -
        BEET-Modus}

    \begin{itemize}
        \item
              Welche Adressen soll Alice verwenden, um Pakete an Bob, Charlie und
              Dave zu senden?
        \item
              Weder die externen noch die internen Adressen dürfen eindeutig sein!

              \begin{itemize}
                  \item
                        Bobs und Charlies Pakete haben beide die gleiche externe Adresse
                  \item
                        Bobs und Daves Pakete haben beide dieselbe interne Adresse
                  \item
                        % \includegraphics{Assets/NetworkSecurity-NAT-BEET-mode.png}
                  \item
                        Die Verwendung interner oder externer Adressen ist unsicher (Warum?)
                  \item
                        Die Unterscheidung erfordert virtuelle Adressen...
              \end{itemize}
        \item
              Virtuelle IP-Adressen zuweisen oder aushandeln

              \begin{itemize}
                  \item
                        Alice muss jedem ihrer Peers eindeutige virtuelle Adressen zuweisen
                  \item
                        Dies kann manuell geschehen, oder
                  \item
                        durch DHCP über IKE, oder
                  \item
                        durch Aushandlung von Verkehrsselektoren (IKEv2)
                  \item
                        L2TP über IPsec ausführen
              \end{itemize}
        \item
              IPsec-Tunnelmodus ist erforderlich

              \begin{itemize}
                  \item
                        Externer IP-Header trägt entweder eine öffentliche IP-Adresse oder
                        eine private NAT-Adresse
                  \item
                        Interner IP Header trägt virtuelle IP-Adresse
                  \item
                        Führt zu (mindestens!) 28 Bytes Overhead pro Paket in
                        NAT-Situationen
                  \item
                        \textbar{} IP Header \textbar{} UDP Header \textbar{} ESP Header
                        \textbar{} IP Header \textbar{} geschützte Daten \textbar{}
              \end{itemize}
        \item
              Aber eigentlich sind nur Adressfelder im inneren IP-Header
              erforderlich (alle anderen Felder können vom externen Header
              abgeleitet werden)
        \item
              Beide virtuellen Adressfelder verwenden immer dieselben Adressen (kein
              Multiplexing wie in üblichen Tunnelmodusszenarien)
        \item
              Die Beschränkung auf zwei Adressen im Tunnel ermöglicht eine statische
              Bindung während der IKE-Aushandlung
        \item
              Der Bound-End-to-End-Tunnel (BEET)-Modus {[}NiMe08{]} verhält sich
              semantisch wie eine Tunnelmodus-Assoziation mit einem Verkehrsselektor
              für einen einzelnen Host (/32)
        \item
              Die übertragenen ESP-Pakete sind äquivalent zu Transport
              (!)-Modus-Paketen (virtuelle Adressen werden nie in Paketen
              übertragen)
        \item
              Der innere Header wird durch den ESP-Entkapselungsprozess
              wiederhergestellt.
        \item
              Unterscheidet zwischen der Erreichbarkeit eines Hosts (externe
              IP-Adresse) und seiner Identität (virtuelle IP-Adresse)
        \item
              Hosts können nun zwischen verschiedenen Standorten hin- und herwandern
              und ihre virtuelle IP-Adresse beibehalten (dies ermöglicht zusätzlich
              eine bessere Unterstützung der Mobilität)
    \end{itemize}


    \subsection{Konfiguration großer
        IPsec-Infrastrukturen}

    \begin{itemize}
        \item
              Kommunikationsinfrastrukturen von Unternehmen und Behörden:
        \item
              Kann komplexe Overlay-Topologien bilden

              \begin{itemize}
                  \item
                        Verschachtelt
                  \item
                        Kreisläufe
                  \item
                        Mehrere Sicherheitsgateways pro privatem Netzwerk
                  \item
                        Mehrere private Netze pro Gateway
                  \item
                        Private Adressbereiche in privaten Netzen
                  \item
                        QoS und sicheres IP-Multicast können erforderlich sein
              \end{itemize}
        \item
              Kann bis zu Tausende von Sicherheits-Gateways haben
        \item
              Kann sich dynamisch ändern

              \begin{itemize}
                  \item
                        Hinzufügen und Entfernen von Sicherheitsgateways
                  \item
                        Ausfälle von Verbindungen und Knoten
                  \item
                        Denial-of-Service-Angriffe
                  \item
                        Mobile Sicherheitsgateways (z. B. für die Kommunikation im
                        Katastrophenfall)
              \end{itemize}
        \item
              Muss natürlich sicher sein ...
    \end{itemize}


    \subsection{Probleme bei der manuellen Konfiguration der
        IPsec-Infrastruktur}

    \begin{itemize}
        \item
              Die IETF hat keine Methode zur automatischen Konfiguration und zum
              Einsatz von IPsec in großen Szenarien definiert
        \item
              Daher werden Sicherheits-Gateways in der Regel manuell konfiguriert

              \begin{itemize}
                  \item
                        Die Anzahl der Sicherheitsrichtlinieneinträge wächst quadratisch mit
                        der Anzahl der Sicherheitsgateways
                  \item
                        Problem der Skalierbarkeit

                        \begin{itemize}
                            \item
                                  Der Administrationsaufwand wächst \$\textbackslash Rightarrow\$
                                  Die Kosten steigen
                            \item
                                  Administratoren machen potenziell mehr Konfigurationsfehler, z.B.
                                  vergessen, einen Eintrag aus einem SPD zu löschen oder einen zu
                                  großen IP-Bereich zuzulassen, usw. \$\textbackslash Rightarrow\$
                                  Mögliche Sicherheitsprobleme
                        \end{itemize}
              \end{itemize}
        \item
              Problem der Agilität

              \begin{itemize}
                  \item
                        Keine dynamische Anpassung der VPN-Topologie
                  \item
                        Begrenzte Unterstützung mobiler Sicherheits-Gateways
              \end{itemize}
    \end{itemize}


    \subsection{Automatische IPsec-Konfiguration - einige
        Anforderungen}

    \begin{itemize}
        \item
              Funktionelle Anforderungen

              \begin{itemize}
                  \item
                        Muss manuelle Eingriffe minimieren
                  \item
                        Muss auch komplexe Infrastrukturen unterstützen (verschachtelte
                        Topologien mit privaten Adressbereichen usw.)
                  \item
                        Muss nur Unicast verwenden (da Multicast usw. nicht weit verbreitet
                        ist)
              \end{itemize}
        \item
              Nicht-funktionale Anforderungen

              \begin{itemize}
                  \item
                        Muss robust sein, d. h. stabil auf schwierige Netzbedingungen
                        reagieren
                  \item
                        Sie muss sicher sein, insbesondere darf sie nicht schwächer sein als
                        eine manuell konfigurierte IPsec-Infrastruktur
                  \item
                        Sie muss in Bezug auf die Anzahl der Sicherheits-Gateways skalierbar
                        sein
                  \item
                        Es muss sich schnell an neue Topologien anpassen können.
              \end{itemize}
    \end{itemize}


    \subsection{Verschiedene Ansätze für die automatische
        IPsec-Konfiguration}

    \begin{itemize}
        \item
              IPsec-Richtlinienverteilung über zentrale Server
        \item
              Gruppenverschlüsseltes Transport-VPN (GET)
        \item
              Tunnel-Endpunkt-Erkennung (TED)
        \item
              Dynamisches Mehrpunkt-VPN (DMVPN)
        \item
              Proaktives Multicast-basiertes IPsec-Erkennungsprotokoll
        \item
              Soziales VPN
        \item
              Sicheres OverLay für IPsec-Erkennung (SOLID)
    \end{itemize}


    \subsubsection{IPsec-Richtlinienverteilung durch zentrale
        Server}

    \begin{itemize}
        \item
              Einfacher, gemeinsamer Ansatz zur Konfiguration einer großen Anzahl
              von Sicherheits-Gateways
        \item
              Zentraler Policy Server statisch in jedem Gateway konfiguriert
        \item
              Jedes Gateway kontaktiert den Policy Server, um SPD zu aktualisieren
        \item
              Beispiel: Microsoft Active Directory, verschiedene Militärprodukte
        \item
              Einige offensichtliche Probleme:

              \begin{itemize}
                  \item
                        Administratoren müssen die zentrale Datenbank manuell bearbeiten
                  \item
                        Verschachtelte Topologien sind schwer zu realisieren
                  \item
                        Skalierbarkeitsprobleme aufgrund von Engpässen
                  \item
                        Verfügbarkeit ist schwer zu garantieren (Single Point of Failure)
                  \item
                        Dynamische Topologien erfordern, dass neue Richtlinien proaktiv an
                        die Sicherheitsgateways übermittelt werden (auch wenn sie derzeit
                        vielleicht nicht verwendet werden)
                  \item
                        Viele Richtlinieneinträge werden höchstwahrscheinlich nie verwendet
                        (kein Verkehr)
              \end{itemize}
    \end{itemize}


    \subsubsection{Tunnel Endpoint Discovery
        (TED)}

    \begin{itemize}
        \item
              Proprietärer Ansatz von Cisco {[}Fluh01{]}
        \item
              Sicherheitsassoziationen werden reaktiv erstellt

              \begin{itemize}
                  \item
                        Alice sendet Paket an Bob
                  \item
                        Gateway A erkennt, dass keine gültige SA vorhanden ist
                  \item
                        Verwerfen des Pakets und Senden des IKE-Pakets an Bob
                  \item
                        Gateway B fängt IKE-Paket ab
                  \item
                        Richtet SA zu Gateway A ein
                  \item
                        Nachfolgende Pakete zwischen Alice und Bob können übertragen werden
              \end{itemize}
        \item
              Ziemlich leistungsfähiger, sicherer Ansatz, aber

              \begin{itemize}
                  \item
                        Routing muss im Transportnetz durchgeführt werden
                  \item
                        Keine privaten IP-Adressbereiche
                  \item
                        Keine verschachtelten Topologien
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-TED.png}
    \end{itemize}


    \subsubsection{Gruppenverschlüsseltes Transport-VPN
        (GET)}

    \begin{itemize}
        \item
              Cisco Produktbranding mehrerer IPsec-Komponenten {[}Bhai08{]}
        \item
              Sicherheits-Gateways kontaktieren zentralen IKE-Server
        \item
              IKE-Server verteilt symmetrische Schlüssel (bevorzugt über Multicast)
        \item
              Alle Sicherheitsgateways einer Gruppe verwenden dieselbe SA
              (einschließlich SPI, Schlüssel)
        \item
              Wiederholungsschutz durch Zeitfenster (1-100 Sekunden)

              \begin{itemize}
                  \item
                        Sliding-Window-Mechanismus funktioniert nicht, da mehrere Absender
                        denselben SPI verwenden
              \end{itemize}
        \item
              Zusätzliche Probleme mit zentralen Policy-Servern:

              \begin{itemize}
                  \item
                        schwacher Wiedergabeschutz
                  \item
                        Die Kompromittierung eines einzelnen Gateways beeinträchtigt das
                        gesamte VPN
                  \item
                        Rekeying durch symmetrischen Austausch \$\textbackslash Rightarrow\$
                        kann nicht von kompromittierten Schlüsseln wiederhergestellt werden
                  \item
                        Perfektes Vorwärtsgeheimnis nicht verfügbar
              \end{itemize}
        \item
              Einziger Vorteil: Ermöglicht Multicast-Netzwerkprivatisierung
        \item
              % \includegraphics{Assets/NetworkSecurity-GET.png}
    \end{itemize}


    \subsubsection{Proaktives Multicast-basiertes
        IPsec-Erkennungsprotokoll}

    \begin{itemize}
        \item
              Ansatz wurde für militärische Anwendungen entwickelt {[}Tran06{]}
        \item
              Sicherheits-Gateways kündigen periodisch private Netzwerke an
        \item
              Erfolgt durch Transportnetzwerk-Multicast
        \item
              Nachrichten werden durch einen vorab geteilten symmetrischen Schlüssel
              geschützt
        \item
              Vorteile: Unterstützt private Adressbereiche, Multicast innerhalb des
              VPN
        \item
              Probleme:

              \begin{itemize}
                  \item
                        Erfordert Transportnetz-Multicast
                  \item
                        Verschachtelte Topologien funktionieren nicht
                  \item
                        Anzahl der empfangenen Nachrichten kann ziemlich groß sein
                  \item
                        Ein kompromittiertes Gateway führt zu einer nicht
                        wiederherstellbaren Kompromittierung des VPN
                  \item
                        Replay-Schutz nicht berücksichtigt
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-proactive-multicast-discovery.png}
    \end{itemize}


    \subsubsection{Soziales VPN}

    \begin{itemize}
        \item
              Akademischer Ansatz {[}FBJW08{]}
        \item
              Verwendet Facebook als ,,policy'' Server zum Austausch von IKE
              Zertifikaten

              \begin{itemize}
                  \item
                        Man kann mit Freunden kommunizieren
              \end{itemize}
        \item
              Agilität durch Peer-to-Peer-Netzwerk

              \begin{itemize}
                  \item
                        Schaut in einer verteilten Hash-Tabelle nach der externen IP-Adresse
                        des Ziels
              \end{itemize}
        \item
              Probleme

              \begin{itemize}
                  \item
                        Keine Gateway-Funktionalität (nur Ende-zu-Ende)
                  \item
                        Keine verschachtelten Topologien
                  \item
                        Ziemlich großer Paket-Overhead
                  \item
                        Schlechte Skalierbarkeit im Falle vieler potentieller
                        Kommunikationspartner
                  \item
                        Sicherheit

                        \begin{itemize}
                            \item
                                  Vertrauen Sie Facebook?
                            \item
                                  Wissen Sie, ob die Person in Facebook wirklich die ist, die sie
                                  behauptet?
                            \item
                                  Überhaupt keine Verifizierung möglich
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsubsection{Dynamisches Mehrpunkt-VPN
        (DMVPN)}

    \begin{itemize}
        \item
              Ein weiterer Ansatz von Cisco {[}Bhai08{]}
        \item
              VPN ist aufgeteilt in

              \begin{itemize}
                  \item
                        Statische Kern-Gateways (,,Hubs'')
                  \item
                        Dynamische periphere Gateways (,,Spokes'')
              \end{itemize}
        \item
              Hubs können OSPF-Routing zwischen den anderen nutzen
        \item
              Spokes kontaktieren vorkonfigurierte Hubs für den Zugang zum VPN
        \item
              Dynamische ,,Spoke-to-Spoke''-Verbindungen optimieren den Datenfluss
        \item
              % \includegraphics{Assets/NetworkSecurity-DMVPN.png}
    \end{itemize}


    \paragraph{Dynamisches Mehrpunkt-VPN (DMVPN) -
        Diskussion}

    \begin{itemize}
        \item
              Vorteile

              \begin{itemize}
                  \item
                        Ansatz ermöglicht dynamischere Topologien
                  \item
                        Kann private Adressen verwenden
              \end{itemize}
        \item
              Nachteilig

              \begin{itemize}
                  \item
                        Erfordert immer noch erheblichen Konfigurationsaufwand

                        \begin{itemize}
                            \item
                                  Kernnetz muss manuell konfiguriert werden
                            \item
                                  Spokes müssen mit den Adressen der Hubs konfiguriert werden
                            \item
                                  Macht z.B. einen einfachen Wechsel zu einem neuen ISP unmöglich
                        \end{itemize}
                  \item
                        Spokes können nicht verschachtelt werden
                  \item
                        Spokes können sich nicht zwischen ,,Hubs'' bewegen

                        \begin{itemize}
                            \item
                                  Hub verhält sich wie MobileIP Home Agent für Spoke
                        \end{itemize}
                  \item
                        Ausfall von ,,Hubs'' kritisch für deren ,,Spokes''
              \end{itemize}
    \end{itemize}


    \subsubsection{Sicheres OverLay für IPsec-Erkennung
        (SOLID)}

    \begin{itemize}
        \item
              Komplexer Ansatz, verspricht einfache Implementierung {[}RSS10{]}
        \item
              Sicherheitsgateways bilden ein strukturiertes Overlay-Netzwerk

              \begin{itemize}
                  \item
                        Verbindet Sicherheitsgateways so, dass das VPN effizient nach einer
                        Zieladresse durchsucht werden kann
              \end{itemize}
        \item
              Erfordert nur sehr wenige proaktiv erstellte IPsec-Verbindungen

              \begin{itemize}
                  \item
                        Minimale Konnektivität ermöglicht eine reaktive Erkennung von
                        Sicherheitsgateways
                  \item
                        Sich bewegende Sicherheitsgateways müssen nicht alle anderen über
                        die aktuelle externe IP-Adresse informieren
              \end{itemize}
        \item
              Drei Aufgaben zu erfüllen

              \begin{itemize}
                  \item
                        Topologie-Kontrolle

                        \begin{itemize}
                            \item
                                  Proaktiver Aufbau einer VPN-Struktur zur schnellen Erkennung
                        \end{itemize}
                  \item
                        Erkennung von Sicherheitsgateways

                        \begin{itemize}
                            \item
                                  Jedes Mal, wenn ein Client-Computer ein Paket sendet und keine
                                  gültige SA gefunden wird
                            \item
                                  Muss das entsprechende Sicherheits-Gateway finden, um reaktiv eine
                                  SA zu erstellen
                        \end{itemize}
                  \item
                        Weiterleitung von Datenpaketen

                        \begin{itemize}
                            \item
                                  Suche nach einem effizienten Weg zur Weiterleitung von Paketen
                                  durch das Overlay
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \paragraph{SOLID -
        Topologie-Kontrolle}

    \begin{itemize}
        \item
              Mechanismen zur Topologiekontrolle

              \begin{itemize}
                  \item
                        Kontinuierliche Aktualisierung der VPN-Struktur zur Anpassung an
                        Veränderungen
              \end{itemize}
        \item
              In SOLID werden proaktiv SAs erstellt, um eine künstliche Ringstruktur
              zu bilden
        \item
              Sicherheitsgateways sind nach inneren Adressen geordnet
        \item
              Gateways, die nicht direkt im Transportnetz kommunizieren können,
              werden durch virtuelle Pfade verbunden \$\textbackslash Rightarrow\$
              Verschachtelte Strukturen werden abgeflacht, um eine einfache
              Erkennung zu ermöglichen
        \item
              % \includegraphics{Assets/NetworkSecurity-SOLID-topology.png}
    \end{itemize}


    \paragraph{SOLID - Erkennung}

    \begin{itemize}
        \item
              Reaktive Erkennung, um ein Sicherheits-Gateway für eine bestimmte
              Client-IP-Adresse zu finden
        \item
              Suchanfragen werden an das (bereits zugeordnete) Gateway
              weitergeleitet, dessen innere IP-Adresse der gesuchten IP-Adresse ,,am
              ähnlichsten'' ist

              \begin{itemize}
                  \item
                        Ein einfacher Mechanismus stellt sicher, dass das korrekte
                        entsprechende Sicherheits-Gateway gefunden wird
                  \item
                        Die Pakete werden entlang der Ringstruktur gesendet
                  \item
                        Benötigt \$O(n)\$ Overlay Hops, um das Ziel zu erreichen (wobei n
                        die Anzahl der Netzwerke in der VPN-Topologie ist)
              \end{itemize}
        \item
              \$\textbackslash Rightarrow\$ Kürzere ,,Suchpfade'' erforderlich
    \end{itemize}


    \paragraph{SOLID - Mehr
        Topologiekontrolle}

    \begin{itemize}
        \item
              Erweiterte Topologiekontrolle schafft zusätzliche SAs
        \item
              IP-Adressraum des VPN wird in Bereiche unterteilt

              \begin{itemize}
                  \item
                        Exponentiell wachsende Größe der Bereiche
              \end{itemize}
        \item
              Zu jedem Bereich wird mindestens eine SA proaktiv von jedem Gateway
              gehalten
        \item
              Anzahl der zusätzlichen SAs wächst in \$O(log\textbackslash{} n)\$
        \item
              Aufgrund der Konstruktionstechnik Entdeckung in
              \$O(log\textbackslash{} n)\$ Overlay Hops
              \$\textbackslash Rightarrow\$ Ansatz skaliert gut mit Anzahl der
              Netzwerke
        \item
              % \includegraphics{Assets/NetworkSecurity-SOLID-topology-control.png}
    \end{itemize}


    \paragraph{SOLID - Weiterleitung von
        Datenpaketen}

    \begin{itemize}
        \item
              Nach der anfänglichen Erkennung müssen die Datenpakete weitergeleitet
              werden
        \item
              Senden von Daten entlang des Entdeckungspfades möglich

              \begin{itemize}
                  \item
                        Länge wieder \$O(log\textbackslash{} n)\$ Overlay-Hops
                  \item
                        Zu ineffizient, wenn viele Pakete geroutet werden müssen
                  \item
                        Wird nur anfangs verwendet
              \end{itemize}
        \item
              Nachfolgend wird der Pfad optimiert

              \begin{itemize}
                  \item
                        Optimierung erfolgt, wenn Gateway feststellt, dass es Pakete für
                        zwei Gateways weiterleitet, die sich im gleichen Netz befinden
                  \item
                        Führt in zyklusfreien VPNs zu optimalen Routen in Bezug auf die
                        Anzahl der Overlay-Sprünge
                  \item
                        Kleine Zyklen können lokal umgangen werden
              \end{itemize}
    \end{itemize}


    \paragraph{SOLID - Eigenschaften und
        Ergebnisse}

    \begin{itemize}
        \item
              Kann komplexe Infrastrukturen innerhalb von Sekunden oder Minuten
              konfigurieren
        \item
              Erfordert keine manuelle Interaktion
        \item
              Erfordert keine besonderen Eigenschaften des Transportnetzes
        \item
              Robustheit

              \begin{itemize}
                  \item
                        Kein einzelner Ausfallpunkt
                  \item
                        Wenn das Netzwerk aufgeteilt wird, können die Teile unabhängig
                        voneinander arbeiten
              \end{itemize}
        \item
              Keine Schwächung der von Standard-IPsec gebotenen Sicherheit
        \item
              Gute Skalierbarkeit mit der Anzahl der privaten Netze, keine Engpässe
        \item
              Wenn Sicherheitsgateways umziehen, müssen nur zwei SAs
              wiederhergestellt werden, um die Erreichbarkeit zu gewährleisten
    \end{itemize}


    \paragraph{SOLID - Simulative
        Bewertung}

    \begin{itemize}
        \item
              SOLID kann in OMNeT++ evaluiert werden
        \item
              Ermöglicht Tests von komplexen Szenarien
    \end{itemize}


    \paragraph{SOLID - Sonstige
        Forschung}

    \begin{itemize}
        \item
              SOLID wird in der Gruppe Telematik/Computernetzwerke erforscht
        \item
              Entwicklung von Prototypen
        \item
              Verfügbarkeit

              \begin{itemize}
                  \item
                        Schutz des wichtigeren Kernnetzes vor DoS-Angriffen
                  \item
                        Schaffung eines mehrschichtigen VPN, das bestimmte Verkehrsflüsse
                        zwischen Sicherheits-Gateways verhindert
              \end{itemize}
        \item
              Zugriffskontrolle
        \item
              Robustheit

              \begin{itemize}
                  \item
                        Proaktive Wiederherstellung bei Netzwerkausfällen
              \end{itemize}
        \item
              Anwendungsschicht-Multicast

              \begin{itemize}
                  \item
                        Ermöglicht sicheres Multicast über reine Unicast-Netze
              \end{itemize}
    \end{itemize}


    \section{Sicherheitsprotokolle der
      Transportschicht}


    \subsection{Anwendungsbereich von Sicherheitsprotokollen der
        Transportschicht}

    \begin{itemize}
        \item
              Die Transportschicht sorgt für die Kommunikation zwischen
              Anwendungsprozessen (anstelle der Kommunikation zwischen Endsystemen)
              und ihre Hauptaufgaben sind:

              \begin{itemize}
                  \item
                        Isolierung höherer Protokollschichten von der Technologie, der
                        Struktur und den Unzulänglichkeiten der eingesetzten
                        Kommunikationstechnik
                  \item
                        Transparente Übertragung von Nutzdaten
                  \item
                        Globale Adressierung von Anwendungsprozessen, unabhängig von
                        Adressen der unteren Schichten (Ethernet-Adressen, Telefonnummern
                        usw.)
                  \item
                        Gesamtziel: Bereitstellung eines effizienten und zuverlässigen
                        Dienstes
              \end{itemize}
        \item
              Sicherheitsprotokolle der Transportschicht zielen darauf ab, den
              Dienst der Transportschicht zu verbessern, indem sie zusätzliche
              Sicherheitseigenschaften gewährleisten

              \begin{itemize}
                  \item
                        Da sie in der Regel einen zuverlässigen Transportdienst voraussetzen
                        und darauf aufbauen, stellen sie nach der Terminologie des
                        OSI-Referenzmodells (Open Systems Interconnection) eigentlich
                        Sitzungsschichtprotokolle dar.
                  \item
                        Da OSI jedoch nicht mehr ,,en vogue'' ist, werden sie als
                        Sicherheitsprotokolle der Transportschicht bezeichnet
              \end{itemize}
    \end{itemize}


    \subsection{Das Secure Socket Layer (SSL)
        Protokoll}

    \begin{itemize}
        \item
              SSL wurde ursprünglich in erster Linie zum Schutz von HTTP-Sitzungen
              entwickelt:

              \begin{itemize}
                  \item
                        In den frühen 1990er Jahren gab es ein ähnliches Protokoll namens
                        S-HTTP
                  \item
                        Da jedoch S-HTTP-fähige Browser nicht kostenlos waren und SSL
                        Version 2.0 in den Browsern von Netscape Communications enthalten
                        war, setzte es sich schnell durch.
                  \item
                        SSL v.2 enthielt einige Schwachstellen, weshalb die Microsoft
                        Corporation ein konkurrierendes Protokoll namens Private
                        Communication Technology (PCT) entwickelte.
                  \item
                        Netscape verbesserte das Protokoll und SSL v.3 wurde zum
                        De-facto-Standardprotokoll für die Sicherung des HTTP-Verkehrs.
                  \item
                        Dennoch kann SSL eingesetzt werden, um beliebige Anwendungen zu
                        sichern, die über TCP laufen.
                  \item
                        1996 beschloss die IETF, ein allgemeines Transport Layer Security
                        (TLS) Protokoll zu spezifizieren, das auf SSL basiert
              \end{itemize}
    \end{itemize}


    \subsection{SSL-Sicherheitsdienste}

    \begin{itemize}
        \item
              Peer-Entity-Authentifizierung:

              \begin{itemize}
                  \item
                        Vor jeder Kommunikation zwischen einem Client und einem Server wird
                        ein Authentifizierungsprotokoll ausgeführt, um die Peer-Entitäten zu
                        authentifizieren.
                  \item
                        Nach erfolgreichem Abschluss des Authentifizierungsdialogs wird eine
                        SSL-Sitzung zwischen den Peer-Entities aufgebaut.
              \end{itemize}
        \item
              Vertraulichkeit der Benutzerdaten:

              \begin{itemize}
                  \item
                        Falls beim Aufbau der Sitzung vereinbart, werden die Benutzerdaten
                        verschlüsselt.
                  \item
                        Es können verschiedene Verschlüsselungsalgorithmen ausgehandelt
                        werden: RC4, DES, 3DES, IDEA
              \end{itemize}
        \item
              Integrität der Benutzerdaten:

              \begin{itemize}
                  \item
                        Ein MAC, der auf einer kryptografischen Hash-Funktion basiert, wird
                        an die Benutzerdaten angehängt.
                  \item
                        Der MAC wird mit einem ausgehandelten Geheimnis im
                        Präfix-Suffix-Modus errechnet.
                  \item
                        Für die MAC-Berechnung kann entweder MD5 oder SHA ausgehandelt
                        werden.
              \end{itemize}
    \end{itemize}


    \subsection{SSL-Sitzungs- und
        Verbindungsstatus}

    \begin{itemize}
        \item
              Sitzungsstatus:

              \begin{itemize}
                  \item
                        Sitzungskennzeichen: eine vom Server gewählte Bytefolge
                  \item
                        Peer-Zertifikat: X.509 v.3 Zertifikat der Gegenstelle (optional)
                  \item
                        Komprimierungsmethode: Algorithmus zur Komprimierung der Daten vor
                        der Verschlüsselung
                  \item
                        Cipher spec: spezifiziert kryptographische Algorithmen und Parameter
                  \item
                        Hauptgeheimnis: ein ausgehandeltes gemeinsames Geheimnis mit einer
                        Länge von 48 Byte
                  \item
                        Ist wiederaufnehmbar: ein Kennzeichen, das angibt, ob die Sitzung
                        neue Verbindungen unterstützt
              \end{itemize}
        \item
              Verbindungsstatus:

              \begin{itemize}
                  \item
                        Server und Client random: von Server und Client gewählte Bytefolgen
                  \item
                        Server write MAC secret: wird in MAC-Berechnungen des Servers
                        verwendet
                  \item
                        Client write MAC secret: wird bei MAC-Berechnungen durch den Client
                        verwendet
                  \item
                        Server-Schreibschlüssel: wird für die Verschlüsselung durch den
                        Server und die Entschlüsselung durch den Client verwendet
                  \item
                        Client write key: wird für die Verschlüsselung durch den Client und
                        die Entschlüsselung durch den Server verwendet
              \end{itemize}
    \end{itemize}


    \subsection{Architektur des
        SSL-Protokolls}

    % \includegraphics{Assets/NetworkSecurity-ssl-protocol-architecture.png}

    \begin{itemize}
        \item
              SSL ist als eine mehrschichtige und modulare Protokollarchitektur
              aufgebaut:

              \begin{itemize}
                  \item
                        Handshake: Authentifizierung und Aushandlung von Parametern
                  \item
                        Change Cipherspec: Signalisierung von Übergängen in der
                        Verschlüsselungsstrategie
                  \item
                        Alert: Signalisierung von Fehlerzuständen
                  \item
                        Application Data: Schnittstelle für den transparenten Zugriff auf
                        das Record-Protokoll
                  \item
                        Aufzeichnung:

                        \begin{itemize}
                            \item
                                  Fragmentierung der Nutzdaten in Klartextsätze der Länge
                                  \$\textless{} 2\^{}\{14\}\$
                            \item
                                  Komprimierung (optional) von Klartextsätzen
                            \item
                                  Verschlüsselung und Integritätsschutz (beides optional)
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{SSL-Record-Protokoll}

    % \includegraphics{Assets/NetworkSecurity-SSL-record-protocol.png}

    \begin{itemize}
        \item
              Inhaltstyp:

              \begin{itemize}
                  \item
                        Ändern Cipherspec. (20)
                  \item
                        Warnung (21)
                  \item
                        Handshake (22)
                  \item
                        Anwendungsdaten (23)
              \end{itemize}
        \item
              Version: die Protokollversion von SSL (major = 3, minor = 0)
        \item
              Länge: die Länge der Daten in Bytes, darf nicht größer sein als
              \$2\^{}\{14\} + 2\^{}\{10\}\$
    \end{itemize}


    \subsection{Verarbeitung des
        SSL-Datensatzprotokolls}

    \begin{itemize}
        \item
              Absendende Seite:

              \begin{itemize}
                  \item
                        Die Datensatzschicht fragmentiert zunächst die Nutzdaten in
                        Datensätze mit einer maximalen Länge von \$2\^{}\{14\}\$ Oktetten,
                        wobei mehrere Nachrichten desselben Inhaltstyps zu einem Datensatz
                        zusammengefasst werden können
                  \item
                        Nach der Fragmentierung werden die Daten des Datensatzes
                        komprimiert, der Standardalgorithmus hierfür ist null
                        (\textasciitilde{} keine Komprimierung), und er darf die Länge des
                        Datensatzes nicht um mehr als \$2\^{}\{10\}\$ Oktette erhöhen
                  \item
                        Ein Nachrichtenauthentifizierungscode wird an die Datensatzdaten
                        angehängt:

                        \begin{itemize}
                            \item
                                  \$MAC = H(MAC\_write\_secret + pad\_2 + H(MAC\_write\_secret +
                                  pad\_1 + seqnum + length + data))\$
                            \item
                                  Man beachte, dass seqnum nicht übertragen wird, da es implizit
                                  bekannt ist und das zugrundeliegende TCP einen gesicherten Dienst
                                  bietet
                        \end{itemize}
                  \item
                        Die Daten des Datensatzes und der MAC werden mit dem in der
                        aktuellen Chiffriervorschrift definierten
                        Verschlüsselungsalgorithmus verschlüsselt (dies kann ein vorheriges
                        Auffüllen erfordern)
              \end{itemize}
        \item
              Empfängerseite:

              \begin{itemize}
                  \item
                        Der Datensatz wird entschlüsselt, auf Integrität geprüft,
                        dekomprimiert, de-fragmentiert und an die Anwendung oder das
                        SSL-Protokoll der höheren Schicht übergeben
              \end{itemize}
    \end{itemize}


    \subsection{SSL Handshake Protokoll:
        Einführung}

    \begin{itemize}
        \item
              Das SSL-Handshake-Protokoll wird verwendet, um die
              Peer-Authentifizierung und die kryptographischen Parameter für eine
              SSL-Sitzung festzulegen.
        \item
              Eine SSL-Sitzung kann so ausgehandelt werden, dass sie wieder
              aufgenommen werden kann:

              \begin{itemize}
                  \item
                        Die Wiederaufnahme und Duplizierung von SSL-Sitzungen ermöglicht die
                        Wiederverwendung des etablierten Sicherheitskontextes.
                  \item
                        Dies ist für die Absicherung des HTTP-Verkehrs sehr wichtig, da in
                        der Regel für jedes Element einer Webseite eine eigene
                        TCP-Verbindung aufgebaut wird.

                        \begin{itemize}
                            \item
                                  Seit HTTP 1.1 werden persistente TCP-Verbindungen verwendet.
                            \item
                                  Dennoch ist die Wiederaufnahme von SSL-Sitzungen sehr sinnvoll, da
                                  persistente TCP-Verbindungen nach dem Herunterladen aller
                                  Elemente, die zu einer Seite gehören, und einer gewissen Zeit der
                                  Inaktivität des Benutzers geschlossen werden können.
                        \end{itemize}
                  \item
                        Bei der Wiederaufnahme / Duplizierung einer bestehenden Sitzung wird
                        ein abgekürzter Handshake durchgeführt
              \end{itemize}
    \end{itemize}


    \subsection{SSL Handshake Protokoll: Vollständiger
    Handshake}

    %\begin{longtable}[]{@{}lll@{}}
    %    \toprule
    %    Client                  &                       & Server\tabularnewline
    %    \midrule
    %    \endhead
    %    ClientHello             & -\/-\/-\textgreater{} & \tabularnewline
    %                            &                       & ServerHello\tabularnewline
    %                            &                       & {[}ServerCertificate{]}\tabularnewline
    %                            &                       & {[}CertificateRequest{]}\tabularnewline
    %                            &                       & {[}ServerKeyExchange{]}\tabularnewline
    %                            & \textless-\/-\/-      & ServerHelloDone\tabularnewline
    %    {[}ClientCertificate{]} &                       & \tabularnewline
    %    ClientKeyExchange       &                       & \tabularnewline
    %    {[}CertificateVerify{]} &                       & \tabularnewline
    %    ChangeCipherSpec        &                       & \tabularnewline
    %    Finished                & -\/-\/-\textgreater{} & \tabularnewline
    %                            &                       & ChangeCipherSpec\tabularnewline
    %                            & \textless-\/-\/-      & Finished\tabularnewline
    %    \bottomrule
    %\end{longtable}

    {[}...{]} kennzeichnet optionale Nachrichten


    \subsection{SSL Handshake Protokoll: Abgekürzter
        Handshake}

    %\begin{longtable}[]{@{}lll@{}}
    %    \toprule
    %    Client                 &                       & Server\tabularnewline
    %    \midrule
    %    \endhead
    %    ClientHello(SessionID) & -\/-\/-\textgreater{} & \tabularnewline
    %                           &                       & ServerHello(SessionID)\tabularnewline
    %                           &                       & ChangeCipherSpec\tabularnewline
    %                           & \textless-\/-\/-      & Finished\tabularnewline
    %    ChangeCipherSpec       &                       & \tabularnewline
    %    Finished               & -\/-\/-\textgreater{} & \tabularnewline
    %    \bottomrule
    %\end{longtable}

    \begin{itemize}
        \item
              Die Nachricht "Finished" enthält eine MAC, die entweder auf MD5 oder
              SHA basiert und das Master-Secret enthält, das zuvor zwischen Client
              und Server festgelegt wurde.
        \item
              Wenn der Server die Sitzung nicht fortsetzen kann / beschließt, sie
              nicht fortzusetzen, antwortet er mit den Nachrichten des vollständigen
              Handshake
    \end{itemize}


    \subsection{SSL-Handshake-Protokoll: Kryptografische
        Aspekte}

    \begin{itemize}
        \item
              SSL unterstützt drei Methoden zur Erstellung von Sitzungsschlüsseln:

              \begin{itemize}
                  \item
                        RSA: ein Pre-Master-Geheimnis wird vom Client zufällig generiert und
                        mit dem öffentlichen Schlüssel des Servers verschlüsselt an den
                        Server gesendet
                  \item
                        Diffie-Hellman: Es wird ein Standard-Diffie-Hellman-Austausch
                        durchgeführt, und das ermittelte gemeinsame Geheimnis wird als
                        Pre-Master-Secret verwendet.
                  \item
                        Fortezza: eine unveröffentlichte, von der NSA entwickelte
                        Sicherheitstechnologie, die eine Schlüsselhinterlegung unterstützt
                        und in diesem Kurs nicht behandelt wird
              \end{itemize}
        \item
              Da SSL in erster Linie für die Sicherung des HTTP-Verkehrs entwickelt
              wurde, ist das ,,Standardanwendungsszenario'' ein Client, der auf
              einen authentischen Webserver zugreifen möchte:

              \begin{itemize}
                  \item
                        In diesem Fall sendet der Webserver sein Zertifikat mit dem
                        öffentlichen Schlüssel nach der ServerHello-Nachricht
                  \item
                        Das Server-Zertifikat kann die öffentlichen DH-Werte des Servers
                        enthalten oder der Server kann sie in der optionalen
                        ServerKeyExchange-Nachricht senden
                  \item
                        Der Client verwendet das Zertifikat des Servers / die empfangenen
                        DH-Werte / seine Fortezza-Karte, um einen RSA- / DH- /
                        Fortezza-basierten Schlüsselaustausch durchzuführen.
              \end{itemize}
        \item
              Das Pre-Master-Secret und die Zufallszahlen, die der Client und der
              Server in ihren Hallo-Nachrichten angeben, werden verwendet, um das
              Master-Secret der Länge 48 Byte zu generieren.
        \item
              Berechnung des Master-Geheimnisses:

              \begin{itemize}
                  \item
                        Master-Geheimnis = MD5(vor-Master-Geheimnis + SHA('A' +
                        vor-Master-Geheimnis + ClientHello.random + ServerHello.random)) +
                        MD5(Vor-Hauptgeheimnis + SHA('BB' + Vor-Hauptgeheimnis +
                        ClientHello.random + ServerHello.random)) + MD5(pre-master-secret +
                        SHA('CCC' + pre-master-secret + ClientHello.random +
                        ServerHello.random))
              \end{itemize}
        \item
              Die Verwendung von MD5 und SHA zur Generierung des Master-Geheimnisses
              wird als sicher angesehen, selbst wenn eine der kryptografischen
              Hash-Funktionen ,,defekt'' ist.
        \item
              Um die Sitzungsschlüssel aus dem Master-Secret zu berechnen, wird in
              einem ersten Schritt eine ausreichende Menge an Schlüsselmaterial aus
              dem Master-Secret und den Zufallszahlen von Client und Server erzeugt:

              \begin{itemize}
                  \item
                        key\_block = MD5(master-secret + SHA('A' + master-secret +
                        ClientHello.random + ServerHello.random)) + MD5(master-secret +
                        SHA('BB' + master-secret + ClientHello.random + ServerHello.random))
                        + {[}...{]}
              \end{itemize}
        \item
              Anschließend wird das Material des Sitzungsschlüssels fortlaufend aus
              dem key\_block entnommen:

              \begin{itemize}
                  \item
                        client\_write\_MAC\_secret = key\_block{[}1,
                        CipherSpec.hash\_size{]}
                  \item
                        server\_write\_MAC\_secret = key\_block{[}i 1 , i 1 +
                        CipherSpec.hash\_size - 1{]}
                  \item
                        client\_write\_key = key\_block{[}i 2 , i 2 +
                        CipherSpec.key\_material - 1{]}
                  \item
                        server\_write\_key = key\_block{[}i 3 , i 3 +
                        CipherSpec.key\_material - 1{]}
                  \item
                        client\_write\_IV = key\_block{[}i 4 , i 4 + CipherSpec.IV\_size -
                        1{]}
                  \item
                        server\_write\_IV = key\_block{[}i 5 , i 5 + CipherSpec.IV\_size -
                        1{]}
              \end{itemize}
        \item
              Authentifizierung von und mit dem Pre-Master-Secret:

              \begin{itemize}
                  \item
                        SSL unterstützt Schlüsselerstellung ohne Authentifizierung (anonym),
                        in diesem Fall können Man-in-the-Middle-Angriffe nicht abgewehrt
                        werden
                  \item
                        Bei Verwendung des RSA-basierten Schlüsselaustauschs:

                        \begin{itemize}
                            \item
                                  Der Client verschlüsselt das Pre-Master-Secret mit dem
                                  öffentlichen Schlüssel des Servers, der durch eine
                                  Zertifikatskette überprüft werden kann.
                            \item
                                  Der Client weiß, dass nur der Server das Pre-Master-Secret
                                  entschlüsseln kann. Wenn der Server also die fertige Nachricht mit
                                  dem Master-Secret sendet, kann der Client die Server-Authentizität
                                  ableiten.
                            \item
                                  Der Server kann aus dem empfangenen Pre-Master-Secret keine
                                  Client-Authentizität ableiten.
                            \item
                                  Wenn Client-Authentizität erforderlich ist, sendet der Client
                                  zusätzlich sein Zertifikat und eine CertificateVerify-Nachricht,
                                  die eine Signatur über einen Hash (MD5 oder SHA) des
                                  Master-Geheimnisses und aller vor der CertificateVerify-Nachricht
                                  ausgetauschten Handshake-Nachrichten enthält
                        \end{itemize}
                  \item
                        Beim DH-Key-Austausch wird die Authentizität aus den DH-Werten
                        abgeleitet, die im Zertifikat des Servers (und des Clients)
                        enthalten und signiert sind
              \end{itemize}
    \end{itemize}


    \subsection{SSL Handshake Protokoll: Eine
        Sicherheitslücke}

    \begin{itemize}
        \item
              1998 entdeckte D. Bleichenbacher eine Schwachstelle im
              Verschlüsselungsstandard PKCS \#1 (v.1.5), der im
              SSL-Handshake-Verfahren verwendet wird
        \item
              Wenn der Client das Pre-Master-Secret mit dem öffentlichen Schlüssel
              des Servers verschlüsselt, verwendet er PKCS \#1, um es vor der
              Verschlüsselung zu formatieren:

              \begin{itemize}
                  \item
                        EM = 0x02 \textbar{} PS \textbar{} 0x00 \textbar{} M

                        \begin{itemize}
                            \item
                                  wobei PS eine Auffüllzeichenfolge von mindestens 8 pseudozufällig
                                  erzeugten Nicht-Null-Oktetts und M die zu verschlüsselnde
                                  Nachricht (= Pre-Master-Secret) bezeichnet
                            \item
                                  (PS wird verwendet, um eine Zufallskomponente hinzuzufügen und M
                                  auf die Modulusgröße des verwendeten Schlüssels aufzufüllen)
                        \end{itemize}
                  \item
                        Dann wird EM verschlüsselt: \$C = E(+K\_\{Server\}, EM)\$
                  \item
                        Nachdem der Server C entschlüsselt hat, prüft er, ob das erste
                        Oktett gleich 0x ist und ob es ein 0x00-Oktett gibt; wenn diese
                        Prüfung fehlschlägt, antwortet er mit einer Fehlermeldung
                  \item
                        Diese Fehlermeldung kann von einem Angreifer genutzt werden, um
                        einen ,,Orakel-Angriff'' zu starten.
              \end{itemize}
        \item
              Ein Orakel-Angriff gegen das SSL-Handshake-Protokoll {[}BKS98a{]}:

              \begin{itemize}
                  \item
                        Betrachten wir einen Angreifer (Eve), der einen SSL-Handshake-Dialog
                        belauscht hat und das Pre-Master-Secret (und damit alle anderen
                        abgeleiteten Geheimnisse), das zwischen Alice (Client) und Bob
                        (Server) ausgetauscht wurde, wiederherstellen möchte
                  \item
                        Eve hat die verschlüsselte Nachricht C, die das Pre-Master-Secret
                        enthält, erfolgreich abgehört und möchte nun den Klartext
                        wiederherstellen
                  \item
                        Eve generiert eine Reihe zusammenhängender Chiffretexte \$C\_1 ,
                        C\_2 , ...\$:

                        \begin{itemize}
                            \item
                                  \$C\_i = C\textbackslash times R\_i\^{}e\textbackslash{}
                                  mod\textbackslash{} n\$, wobei \$(e, n)\$ der öffentliche
                                  Schlüssel von Bob ist
                            \item
                                  Die \$R\_i\$ werden adaptiv ausgewählt, abhängig von älteren
                                  ,,guten'' \$R\_i\$, die von Bob verarbeitet wurden, ohne
                                  Fehlermeldungen zu erzeugen (was anzeigt, dass sie zu einer
                                  gültigen PKCS-1-Nachricht entschlüsselt wurden)
                            \item
                                  Die \$C\_i\$ werden an Bob übermittelt, und es werden entsprechend
                                  neue \$C\_i\$ erzeugt
                            \item
                                  Aus dem ,,guten'' \$R\_i\$ leitet Eve bestimmte Bits der
                                  entsprechenden Nachricht \$M\_i= C\_i\^{}d = M\textbackslash times
                                  R\_i\textbackslash{} mod\textbackslash{} n\$ ab, basierend auf der
                                  PKCS \#1 Verschlüsselungsmethode
                        \end{itemize}
                  \item
                        Aus den abgeleiteten Bits von \$M\textbackslash times
                        R\_i\textbackslash{} mod\textbackslash{} n\$ für hinreichend viele
                        \$R\_i\$ kann Eve die Größe des Intervalls reduzieren, das die
                        unbekannte Nachricht M enthalten muss
                  \item
                        Im Wesentlichen halbiert jeder ,,gute'' Chiffretext das betreffende
                        Intervall, so dass Eve mit genügend ,,guten'' Chiffretexten in der
                        Lage ist, M
                  \item
                        Mit PKCS \#1 Version 1.5 (wie ursprünglich in SSL V.3.0 verwendet)
                        wird ungefähr einer von \$2\^{}\{16\}\$ bis \$2\^{}\{18\}\$ zufällig
                        ausgewählten Chiffretexten ,,gut'' sein.
                  \item
                        Typischerweise beträgt die Gesamtzahl der erforderlichen
                        Chiffretexte bei einem \$1024\$-Bit-Modul etwa \$2\^{}\{20\}\$, und
                        dies ist auch die Anzahl der Abfragen an Bob
                  \item
                        Nach der Durchführung von etwa 1 Million gefälschter
                        SSL-Handshake-Dialoge (die alle entweder von Bob oder Eve
                        unterbrochen werden) ist Eve also in der Lage, das Pre-Master-Secret
                        und alle abgeleiteten Schlüssel einer zuvor eingerichteten
                        SSL-Sitzung zwischen Alice und Bob wiederherzustellen. Subtile
                        Protokollinteraktionen (hier: SSL und PKCS \#1) können zum Versagen
                        eines Sicherheitsprotokolls führen, selbst wenn der grundlegende
                        kryptographische Algorithmus (hier: RSA) selbst nicht gebrochen ist!
              \end{itemize}
        \item
              Gegenmassnahmen:

              \begin{itemize}
                  \item
                        Regelmäßiger Wechsel der öffentlichen Schlüsselpaare
                        (\$\textbackslash Rightarrow\$-Overhead)
                  \item
                        Verringerung der Wahrscheinlichkeit, ,,gute'' Chiffriertexte zu
                        erhalten, indem das Format der entschlüsselten Chiffriertexte
                        gründlich überprüft und dem Client ein identisches Verhalten
                        (Fehlermeldung, Zeitverhalten usw.) gezeigt wird
                  \item
                        Der Kunde muss den Klartext kennen, bevor er antwortet, ob die
                        Nachricht erfolgreich entschlüsselt werden konnte.
                  \item
                        Hinzufügen einer Struktur zum Klartext, z. B. durch Hinzufügen eines
                        Hashwerts zum Klartext:

                        \begin{itemize}
                            \item
                                  Achtung: Es ist eine gewisse Vorsicht geboten, um Anfälligkeiten
                                  für eine andere Klasse von Angriffen zu vermeiden {[}Cop96a{]}.
                        \end{itemize}
                  \item
                        Änderung des Verschlüsselungsprotokolls für öffentliche Schlüssel,
                        d.h. Überarbeitung von PKCS \#1:

                        \begin{itemize}
                            \item
                                  PKCS \#1 Version 2.1 bereitet den Klartext vor der Verschlüsselung
                                  mit einer Methode vor, die als optimales asymmetrisches
                                  Verschlüsselungs-Padding (OAEP) bezeichnet wird, um die PKCS \#1
                                  Entschlüsselungsprozedur ,,plaintext aware'' zu machen, was
                                  bedeutet, dass es nicht möglich ist, einen gültigen Chiffretext zu
                                  konstruieren, ohne den entsprechenden Klartext zu kennen
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{SSL-Chiffre-Suiten}

    \begin{itemize}
        \item
              Kein Schutz (Standard-Suite):

              \begin{itemize}
                  \item
                        CipherSuite SSL\_NULL\_WITH\_NULL\_NULL = \{ 0x00,0x00 \}
              \end{itemize}
        \item
              Der Server stellt einen für die Verschlüsselung geeigneten
              RSA-Schlüssel bereit:

              \begin{itemize}
                  \item
                        SSL\_RSA\_WITH\_NULL\_MD5 = \{ 0x00,0x01 \}
                  \item
                        SSL\_RSA\_WITH\_NULL\_SHA = \{ 0x00,0x02 \}
                  \item
                        SSL\_RSA\_EXPORT\_WITH\_RC4\_40\_MD5 = \{ 0x00,0x03 \}
                  \item
                        SSL\_RSA\_WITH\_RC4\_128\_MD5 = \{ 0x00,0x04 \}
                  \item
                        SSL\_RSA\_WITH\_RC4\_128\_SHA = \{ 0x00,0x05 \}
                  \item
                        SSL\_RSA\_EXPORT\_WITH\_RC2\_CBC\_40\_MD5 = \{ 0x00,0x06 \}
                  \item
                        SSL\_RSA\_WITH\_IDEA\_CBC\_SHA = \{ 0x00,0x07 \}
                  \item
                        SSL\_RSA\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x08 \}
                  \item
                        SSL\_RSA\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x09 \}
                  \item
                        SSL\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x0A \}
              \end{itemize}
        \item
              Cipher-Suites mit authentifiziertem DH-Schlüssel-Austausch

              \begin{itemize}
                  \item
                        SSL\_DH\_DSS\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x0B \}
                  \item
                        SSL\_DH\_DSS\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x0C \}
                  \item
                        SSL\_DH\_DSS\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x0D \}
                  \item
                        SSL\_DH\_RSA\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x0E \}
                  \item
                        SSL\_DH\_RSA\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x0F \}
                  \item
                        SSL\_DH\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x10 \}
                  \item
                        SSL\_DHE\_DSS\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x11 \}
                  \item
                        SSL\_DHE\_DSS\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x12 \}
                  \item
                        SSL\_DHE\_DSS\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x13 \}
                  \item
                        SSL\_DHE\_RSA\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x14 \}
                  \item
                        SSL\_DHE\_RSA\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x15 \}
                  \item
                        SSL\_DHE\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x16 \}
              \end{itemize}
    \end{itemize}

    (DH steht für Suites, bei denen die öffentlichen DH-Werte in einem von
    einer CA signierten Zertifikat enthalten sind, DHE für Suites, bei denen
    sie mit einem öffentlichen Schlüssel signiert sind, der von einer CA
    zertifiziert ist)

    \begin{itemize}
        \item
              Von der Verwendung der folgenden Chiffriersuiten ohne jegliche
              Authentifizierung der Entität wird dringend abgeraten, da sie anfällig
              für Man-in-the-Middle-Angriffe sind:

              \begin{itemize}
                  \item
                        SSL\_DH\_anon\_EXPORT\_WITH\_RC4\_40\_MD5 = \{ 0x00,0x17 \}
                  \item
                        SSL\_DH\_anon\_WITH\_RC4\_128\_MD5 = \{ 0x00,0x18 \}
                  \item
                        SSL\_DH\_anon\_EXPORT\_WITH\_DES40\_CBC\_SHA = \{ 0x00,0x19 \}
                  \item
                        SSL\_DH\_anon\_WITH\_DES\_CBC\_SHA = \{ 0x00,0x1A \}
                  \item
                        SSL\_DH\_anon\_WITH\_3DES\_EDE\_CBC\_SHA = \{ 0x00,0x1B \}
              \end{itemize}
        \item
              Die letzte Cipher Suite ist für den Fortezza-Token:

              \begin{itemize}
                  \item
                        SSL\_FORTEZZA\_DMS\_WITH\_NULL\_SHA = \{ 0x00,0x1C \}
                  \item
                        SSL\_FORTEZZA\_DMS\_WITH\_FORTEZZA\_CBC\_SHA = \{ 0x00,0x1D \}
              \end{itemize}
    \end{itemize}

    (Diese Cipher-Suites müssen natürlich nicht auswendig gelernt werden und
    werden hier nur aufgeführt, um die Flexibilität des SSL-Protokolls zu
    verdeutlichen)


    \subsection{Das Transport Layer
        Security-Protokoll}

    \begin{itemize}
        \item
              1996 gründete die IETF eine Arbeitsgruppe zur Definition eines
              Transport Layer Security (TLS) Protokolls:

              \begin{itemize}
                  \item
                        Offiziell wurde angekündigt, die Protokolle SSL, SSH und PCT als
                        Input zu nehmen.
                  \item
                        Der im Dezember 1996 veröffentlichte Entwurf der TLS
                        V.1.0-Spezifikation war jedoch im Wesentlichen identisch mit der SSL
                        V.3.0-Spezifikation
              \end{itemize}
        \item
              Eigentlich war es von Anfang an die Absicht der Arbeitsgruppe, TLS auf
              SSL V.3.0 mit den folgenden Änderungen aufzubauen:

              \begin{itemize}
                  \item
                        Die HMAC-Konstruktion zur Berechnung kryptographischer Hash-Werte
                        sollte anstelle von Hashing im Präfix- und Suffix-Modus übernommen
                        werden.
                  \item
                        Die auf Fortezza basierenden Chiffrier-Suiten von SSL sollten
                        entfernt werden, da sie eine unveröffentlichte Technologie enthalten
                  \item
                        Ein auf dem DSS (Digital Signature Standard) basierender Dialog zur
                        Authentifizierung und zum Schlüsselaustausch sollte aufgenommen
                        werden.
                  \item
                        Das TLS-Record-Protokoll und das Handshake-Protokoll sollten
                        getrennt und in separaten Dokumenten klarer spezifiziert werden, was
                        bisher nicht geschehen ist.
              \end{itemize}
        \item
              Um die Exportfähigkeit von TLS-konformen Produkten zu erreichen, wurde
              in einigen Chiffriersuiten die Verwendung von Schlüsseln mit einer auf
              40 Bit reduzierten Entropie vorgeschrieben.

              \begin{itemize}
                  \item
                        Von der Verwendung dieser Cipher-Suites wird dringend abgeraten, da
                        sie praktisch keinen Schutz der Vertraulichkeit von Daten bieten.
              \end{itemize}
        \item
              Ab TLS 1.2 (RFC 5246):

              \begin{itemize}
                  \item
                        Schlüsselaustausch-Algorithmen:

                        \begin{itemize}
                            \item
                                  DH oder ECDH Austausch ohne oder mit DSS / RSA / ECDSA Signaturen
                            \item
                                  DH-Austausch mit zertifizierten öffentlichen DH-Parametern
                            \item
                                  RSA-basierter Schlüsselaustausch
                            \item
                                  keine
                        \end{itemize}
                  \item
                        Verschlüsselungsalgorithmen: AES / 3DES in CBC / CCM /GCM, RC4, null
                  \item
                        Hash-Algorithmen: MD5, SHA-1, SHA-256, SHA-384, SHA-512, null
                  \item
                        Premaster Secret: Keine MD5/SHA-1 Kombination, sondern nur SHA-256!
              \end{itemize}
        \item
              Was die Protokollfunktionen betrifft, ist TLS im Wesentlichen dasselbe
              wie SSL
        \item
              Sicherheit:

              \begin{itemize}
                  \item
                        In SSL 3.0 und TLS 1.0 ist der Initialisierungsvektor eines im
                        CBC-Modus verschlüsselten Datensatzes der letzte Block des
                        vorherigen Datensatzes
                  \item
                        Wenn ein Angreifer den Inhalt des vorherigen Datensatzes
                        kontrolliert, kann er einen adaptiven Klartextangriff durchführen,
                        um den Inhalt des nächsten Datensatzes herauszufinden.
                  \item
                        Durchführbar für Webverkehr, d. h. Erzeugen von Verkehr mit
                        JavaScript und Beobachten von außen, führt zum sogenannten
                        BEAST-Angriff (Browser Exploit Against SSL/TLS) {[}RD10{]}.
                  \item
                        Auch für VPN-Verkehr machbar
                  \item
                        Abgeschwächt durch TLS 1.1, wo explizite IVs verwendet werden
                  \item
                        2009 wurde eine sogenannte TLS-Neuverhandlungsschwachstelle
                        identifiziert

                        \begin{itemize}
                            \item
                                  Angreifer können sie nutzen, um einer legitimen Sitzung durch
                                  einen Man-in-the-Middle-Angriff Daten voranzustellen (Details in
                                  {[}Zo11{]})
                            \item
                                  Die Auswirkungen hängen stark von dem verwendeten
                                  Anwendungsprotokoll ab
                        \end{itemize}
                  \item
                        Bei HTTPS führt dies zu mehreren Ausnutzungsmöglichkeiten, z. B,

                        \begin{itemize}
                            \item
                                  Angreifer injeziert:
                                  \texttt{GET\ /ebanking/transfer?what=LotsOfMoney\&to=eve\ HTTP/1.1\ \textless{}crlf\textgreater{}\ X-Ignore:\ \textless{}no\ crlf\textgreater{}}
                            \item
                                  Alice sendet: \texttt{GET\ /ebanking/start.html\ HTTP/1.1}
                            \item
                                  Die Anfrage wird in eine valide HTTP Anfrage umgewandelt:
                                  \texttt{GET\ /ebanking/transfer?what=LotsOfMoney\&to=eve\ HTTP/1.1\ \textless{}crlf\textgreater{}\ X-Ignore:\ GET\ /ebanking/start.html\ HTTP/1.1}
                        \end{itemize}
                  \item
                        Abgeschwächt durch Identifizierung neu ausgehandelter Sitzungen mit
                        einer anderen ID {[}RRDO10{]}
              \end{itemize}
    \end{itemize}


    \subsection{Das Datagram Transport Layer Security
        Protokoll}

    \begin{itemize}
        \item
              TLS bietet sichere Kommunikation über ein zuverlässiges
              Transportprotokoll
        \item
              DTLS ist so angepasst, dass es über unzuverlässige Transportprotokolle
              wie z.B. UDP funktioniert
        \item
              Wird zum Schutz verwendet:

              \begin{itemize}
                  \item
                        Sprach- und Videodaten in Echtzeit, insbesondere Voice-over-IP
                  \item
                        Getunnelte TCP-Daten (da TCP über TCP eine schlechte Idee für die
                        Leistung ist)
              \end{itemize}
        \item
              DTLS basiert derzeit auf TLS 1.2, enthält jedoch einige Änderungen:

              \begin{itemize}
                  \item
                        Bietet

                        \begin{itemize}
                            \item
                                  Nachrichtenwiederholungen, um verlorenen Handshake-Paketen
                                  entgegenzuwirken
                            \item
                                  Eigener Fragmentierungsmechanismus, um große Handshake-Pakete zu
                                  ermöglichen
                        \end{itemize}
                  \item
                        Hinzufügen von Sequenznummern, um neu geordnete Datenpakete zu
                        ermöglichen (und Verbot von Stromchiffren, z. B. RC4)
                  \item
                        Fügt einen Mechanismus hinzu, um zu erkennen, dass ein Client die
                        ,,Verbindung'' mit denselben Ports neu gestartet hat (z. B. nach
                        einem Anwendungsabsturz)
                  \item
                        Fügt einen Wiedergabeschutz durch ein gleitendes Fenster hinzu (wie
                        bei IPsec)
                  \item
                        Fügt eine Cookie-basierte DoS-Abwehr hinzu (wie bei IKEv2)
              \end{itemize}
    \end{itemize}


    \subsection{Das Secure
        Shell-Protokoll}

    \begin{itemize}
        \item
              Secure Shell (SSH) Version 1 wurde ursprünglich von Tatu Ylönen an der
              Universität Helsinki in Finnland entwickelt.
        \item
              Da der Autor auch eine kostenlose Implementierung mit Quellcode zur
              Verfügung stellte, fand das Protokoll weite Verbreitung im Internet
        \item
              Später wurde die Entwicklung von SSH durch den Autor kommerzialisiert.
        \item
              Nichtsdestotrotz sind immer noch kostenlose Versionen verfügbar, wobei
              die am weitesten verbreitete Version OpenSSH ist
        \item
              1997 wurde eine Spezifikation der Version 2.0 von SSH bei der IETF
              eingereicht und seitdem in einer Reihe von Internet-Entwürfen
              verfeinert
        \item
              SSH wurde ursprünglich entwickelt, um einen sicheren Ersatz für die
              Unix r-Tools (rlogin, rsh, rcp und rdist) zu bieten, und stellt somit
              ein Protokoll der Anwendungs- oder Sitzungsschicht dar.
        \item
              Da SSH jedoch auch ein allgemeines Sicherheitsprotokoll der
              Transportschicht enthält und Tunneling-Fähigkeiten bietet, wird es in
              diesem Kapitel als Sicherheitsprotokoll der Transportschicht behandelt
    \end{itemize}


    \subsection{SSH Version 2}

    \begin{itemize}
        \item
              SSH Version 2 ist in mehreren separaten Dokumenten spezifiziert, z.B.:

              \begin{itemize}
                  \item
                        SSH Protocol Assigned Numbers {[}LL06{]}
                  \item
                        SSH-Protokollarchitektur {[}YL06a{]}
                  \item
                        SSH-Authentifizierungsprotokoll {[}YL06b{]}
                  \item
                        SSH-Transportschichtprotokoll {[}YL06c{]}
                  \item
                        SSH-Verbindungsprotokoll {[}YL06d{]}
              \end{itemize}
        \item
              SSH-Architektur:

              \begin{itemize}
                  \item
                        SSH verfolgt einen Client-Server-Ansatz
                  \item
                        Jeder SSH-Server hat mindestens einen Host-Schlüssel
                  \item
                        SSH Version 2 bietet zwei verschiedene Vertrauensmodelle:

                        \begin{itemize}
                            \item
                                  Jeder Client hat eine lokale Datenbank, die jeden Hostnamen mit
                                  dem entsprechenden öffentlichen Hostschlüssel verknüpft
                            \item
                                  Die Zuordnung von Hostname zu öffentlichem Schlüssel wird von
                                  einer Zertifizierungsstelle zertifiziert, und jeder Client kennt
                                  den öffentlichen Schlüssel der Zertifizierungsstelle
                        \end{itemize}
                  \item
                        Das Protokoll ermöglicht die vollständige Aushandlung von
                        Algorithmen und Formaten für Verschlüsselung, Integrität,
                        Schlüsselaustausch, Komprimierung und öffentliche Schlüssel
              \end{itemize}
    \end{itemize}


    \subsection{SSH-Transportprotokoll}

    \begin{itemize}
        \item
              SSH verwendet ein zuverlässiges Transportprotokoll (normalerweise
              TCP).
        \item
              Es bietet die folgenden Dienste:

              \begin{itemize}
                  \item
                        Verschlüsselung von Benutzerdaten
                  \item
                        Authentifizierung der Datenherkunft (Integrität)
                  \item
                        Server-Authentifizierung (nur Host-Authentifizierung)
                  \item
                        Komprimierung der Benutzerdaten vor der Verschlüsselung
              \end{itemize}
        \item
              Unterstützte Algorithmen:

              \begin{itemize}
                  \item
                        Verschlüsselung:

                        \begin{itemize}
                            \item
                                  AES, 3DES, Blowfish, Twofish, Serpent, IDEA und CAST in CBC
                            \item
                                  AES in GCM {[}IS09{]}
                            \item
                                  Arcfour (,,vermutlich'' kompatibel mit dem ,,unveröffentlichten''
                                  RC4)
                            \item
                                  keine (nicht empfohlen)
                        \end{itemize}
                  \item
                        Integrität:

                        \begin{itemize}
                            \item
                                  HMAC mit MD5, SHA-1, SHA-256 oder SHA-512
                            \item
                                  keine (nicht empfohlen)
                        \end{itemize}
                  \item
                        Schlüsselaustausch:

                        \begin{itemize}
                            \item
                                  Diffie-Hellman mit SHA-1 und zwei vordefinierten Gruppen
                            \item
                                  ECDH mit mehreren vordefinierten NIST-Gruppen {[}SG09{]}
                                  (obligatorisch drei Kurven über $\mathbb{Z}_p$)
                            \item
                                  Öffentlicher Schlüssel: RSA, DSS, ECC (in mehreren Varianten
                                  {[}SG09{]})
                        \end{itemize}
                  \item
                        Komprimierung: keine, zlib (siehe RFCs 1950, 1951)
              \end{itemize}
    \end{itemize}


    \subsection{SSH-Transportprotokoll
        Paketformat}

    % \includegraphics{Assets/NetworkSecurity-ssh-transport-protocol-packet.png}

    \begin{itemize}
        \item
              Das Paketformat ist nicht 32-Bit-wortorientiert
        \item
              Felder des Pakets:

              \begin{itemize}
                  \item
                        Paketlänge: die Länge des Pakets selbst, ohne dieses Längenfeld und
                        den MAC
                  \item
                        Padding length: Länge des Padding-Feldes, muss zwischen vier und 255
                        liegen
                  \item
                        Payload: die eigentliche Nutzlast des Pakets, wenn Komprimierung
                        ausgehandelt wurde, wird dieses Feld komprimiert
                  \item
                        Padding: dieses Feld besteht aus zufällig ausgewählten Oktetten, um
                        die Nutzlast auf ein ganzzahliges Vielfaches von 8 oder der
                        Blockgröße des Verschlüsselungsalgorithmus aufzufüllen, je nachdem,
                        welcher Wert größer ist
                  \item
                        MAC: Wurde die Nachrichtenauthentifizierung ausgehandelt, enthält
                        dieses Feld den MAC des gesamten Pakets ohne das MAC-Feld selbst;
                        soll das Paket verschlüsselt werden, wird der MAC vor der
                        Verschlüsselung wie folgt berechnet

                        \begin{itemize}
                            \item
                                  MAC = HMAC(shared\_secret, seq\_number \textbar\textbar{}
                                  unencrypted\_packet), wobei seq\_number eine 32-Bit-Sequenznummer
                                  für jedes Paket bezeichnet
                        \end{itemize}
              \end{itemize}
        \item
              Verschlüsselung: wenn Verschlüsselung ausgehandelt wird, wird das
              gesamte Paket ohne MAC nach der MAC-Berechnung verschlüsselt
    \end{itemize}


    \subsection{SSH-Aushandlung, Schlüsselaustausch und
        Server-Authentifizierung}

    \begin{itemize}
        \item
              Algorithmus-Aushandlung:

              \begin{itemize}
                  \item
                        Jede Entität sendet ein Paket (bezeichnet als kexinit ) mit einer
                        Spezifikation der von ihr unterstützten Methoden in der Reihenfolge
                        ihrer Präferenz
                  \item
                        Beide Entitäten iterieren über die Liste des Clients und wählen den
                        ersten Algorithmus, der auch vom Server unterstützt wird
                  \item
                        Diese Methode wird verwendet, um Folgendes auszuhandeln:
                        Server-Host-Schlüssel-Algorithmus (\textasciitilde{}
                        Server-Authentifizierung) sowie Verschlüsselungs-, MAC- und
                        Kompressionsalgorithmus
                  \item
                        Zusätzlich kann jede Entität ein Schlüsselaustauschpaket
                        entsprechend einer Vermutung über den bevorzugten
                        Schlüsselaustauschalgorithmus der anderen Entität anhängen
                  \item
                        Ist eine Vermutung richtig, wird das entsprechende
                        Schlüsselaustauschpaket als erstes Schlüsselaustauschpaket der
                        anderen Entität akzeptiert
                  \item
                        Falsche Vermutungen werden ignoriert und neue
                        Schlüsselaustauschpakete werden nach Aushandlung des Algorithmus
                        gesendet
              \end{itemize}
        \item
              Für den Schlüsselaustausch definiert {[}YL06c{]} nur eine Methode:

              \begin{itemize}
                  \item
                        Diffie-Hellman mit SHA-1 und zwei vordefinierten Gruppen (1024 und
                        2048 Bit)
                  \item
                        Z.B. \$p = 2\^{}\{1024\} -2\^{}\{960\} - 1 +
                        (2\^{}\{64\}\textbackslash times \textbackslash lfloor 2894
                        \textbackslash times \textbackslash pi +
                        129093\textbackslash rfloor); g = 2\$
              \end{itemize}
        \item
              Wenn der Schlüsselaustausch mit der vordefinierten DH-Gruppe
              durchgeführt wird:

              \begin{itemize}
                  \item
                        Der Client wählt eine Zufallszahl \$x\$, berechnet
                        \$e=g\^{}x\textbackslash{} mod\textbackslash{} p\$ und sendet \$e\$
                        an den Server
                  \item
                        Der Server wählt eine Zufallszahl \$y\$, errechnet
                        \$f=g\^{}y\textbackslash{} mod\textbackslash{} p\$
                  \item
                        Nach dem Empfang von \$e\$ berechnet der Server ferner
                        \$K=e\^{}y\textbackslash{} mod\textbackslash{} p\$ und einen
                        Hash-Wert \$h = Hash(version\_C, version\_S, kexinit\_C, kexinit\_S,
                        +K\_S, e, f, K)\$, wobei version und kexinit die
                        Versionsinformationen des Clients und des Servers sowie die
                        anfänglichen Algorithmus-Aushandlungsmeldungen bezeichnen
                  \item
                        Der Server signiert h mit seinem privaten Host-Schlüssel - KS und
                        sendet dem Client eine Nachricht mit \$(+K\_S, f, s)\$.
                  \item
                        Beim Empfang prüft der Client den Host-Schlüssel \$+K\_S\$,
                        berechnet \$K=f\^{}x\textbackslash{} mod\textbackslash{} p\$ sowie
                        den Hash-Wert \$h\$ und prüft dann die Signatur \$s\$ über \$h\$
              \end{itemize}
        \item
              Nach diesen Prüfungen kann der Client sicher sein, dass er tatsächlich
              ein geheimes K mit dem Host ausgehandelt hat, der \$-K\_S\$ kennt.
        \item
              Der Server-Host kann jedoch keine Rückschlüsse auf die Authentizität
              des Clients ziehen; zu diesem Zweck wird das
              SSH-Authentifizierungsprotokoll verwendet
    \end{itemize}


    \subsection{SSH-Sitzungsschlüssel-Ableitung}

    \begin{itemize}
        \item
              Die Methode des Schlüsselaustauschs ermöglicht es, ein gemeinsames
              Geheimnis K und den Hash-Wert h zu ermitteln, die zur Ableitung der
              SSH-Sitzungsschlüssel verwendet werden:

              \begin{itemize}
                  \item
                        Der Hashwert h des anfänglichen Schlüsselaustauschs wird auch als
                        session\_id verwendet
                  \item
                        \$IV\_\{Client2Server\}\$ = Hash(K, h, ,,A'', session\_id) //
                        Initialisierungsvektor
                  \item
                        \$IV\_\{Server2Client\}\$ = Hash(K, h, ,,B'', session\_id) //
                        Initialisierungsvektor
                  \item
                        \$EK\_\{Client2Server\}\$ = Hash(K, h, ,,C'', session\_id) //
                        Verschlüsselungsschlüssel
                  \item
                        \$EK\_\{Server2Client\}\$ = Hash(K, h, ,,D'', session\_id) //
                        Chiffrierschlüssel
                  \item
                        \$IK\_\{Client2Server\}\$ = Hash(K, h, ,,E'', session\_id) //
                        Integritätsschlüssel
                  \item
                        \$IK\_\{Server2Client\}\$ = Hash(K, h, ,,F'', session\_id) //
                        Integritätsschlüssel
              \end{itemize}
        \item
              Die Schlüsseldaten werden am Anfang der Hash-Ausgabe entnommen
        \item
              Wenn mehr Schlüsselbits benötigt werden als von der Hash-Funktion
              erzeugt werden:

              \begin{itemize}
                  \item
                        K1 = Hash(K, h, x, session\_id) // x = ,,A'', ,,B'', usw.
                  \item
                        K2 = Hash(K, h, K1)
                  \item
                        K2 = Hash(K, h, K1, K2)
                  \item
                        XK = K1 \textbar\textbar{} K2 \textbar\textbar{} ...
              \end{itemize}
    \end{itemize}


    \subsection{SSH-Authentifizierungsprotokoll}

    \begin{itemize}
        \item
              Das SSH-Authentifizierungsprotokoll dient zur Überprüfung der
              Identität des Clients und ist für die Ausführung über das
              SSH-Transportprotokoll vorgesehen
        \item
              Das Protokoll unterstützt standardmäßig die folgenden
              Authentifizierungsmethoden:

              \begin{itemize}
                  \item
                        Öffentlicher Schlüssel: Der Benutzer erzeugt und sendet eine
                        Signatur mit einem öffentlichen Schlüssel pro Benutzer an den Server
                  \item
                        \$Client\textbackslash rightarrow Server: E(-K\_\{Benutzer\},
                        (session\_id, 50, Name\_\{Benutzer\}, Service, ,,publickey'', True,
                        PublicKeyAlgorithmName, +K\_\{Benutzer\}))\$
                  \item
                        Kennwort: Übertragung eines Kennworts pro Benutzer in der
                        verschlüsselten SSH-Sitzung (das Kennwort wird dem Server im
                        Klartext präsentiert, aber mit Verschlüsselung des
                        SSH-Transportprotokolls übertragen)
                  \item
                        Host-basiert: analog zum öffentlichen Schlüssel, aber mit einem
                        öffentlichen Schlüssel pro Host
                  \item
                        Keine: wird verwendet, um den Server nach unterstützten Methoden zu
                        fragen und wenn keine Authentifizierung erforderlich ist (der Server
                        antwortet direkt mit einer Erfolgsmeldung)
              \end{itemize}
        \item
              Wenn die Authentifizierungsnachricht des Clients erfolgreich geprüft
              wurde, antwortet der Server mit einer
              ssh\_msg\_userauth\_success-Nachricht
    \end{itemize}


    \subsection{SSH-Verbindungsprotokoll}

    \begin{itemize}
        \item
              Das SSH-Verbindungsprotokoll läuft auf dem SSH-Transportprotokoll und
              bietet folgende Dienste:

              \begin{itemize}
                  \item
                        Interaktive Anmeldesitzungen
                  \item
                        Fernausführung von Befehlen
                  \item
                        Weitergeleitete TCP/IP-Verbindungen
                  \item
                        Weitergeleitete X11-Verbindungen
              \end{itemize}
        \item
              Für jeden der oben genannten Dienste werden ein oder mehrere
              ,,Kanäle'' eingerichtet, und alle Kanäle werden in eine einzige
              verschlüsselte und integritätsgeschützte
              SSH-Transportprotokollverbindung gemultiplext:

              \begin{itemize}
                  \item
                        Beide Seiten können die Eröffnung eines Kanals beantragen, und die
                        Kanäle werden durch Nummern beim Sender und beim Empfänger
                        gekennzeichnet.
                  \item
                        Kanäle sind typisiert, z. B. ,,session'', ,,x11'',
                        ,,forwarded-tcpip'', ,,direct-tcpip'' ...
                  \item
                        Kanäle werden durch einen Fenstermechanismus kontrolliert, und es
                        dürfen keine Daten über einen Kanal gesendet werden, bevor ,,window
                        space'' verfügbar ist
              \end{itemize}
        \item
              Öffnen eines Kanals:

              \begin{itemize}
                  \item
                        Beide Seiten können die Nachricht ssh\_msg\_channel\_open senden,
                        die mit dem Nachrichtencode 90 und den folgenden Parametern
                        signalisiert wird:

                        \begin{itemize}
                            \item
                                  Kanaltyp: ist vom Datentyp String, z.B. ,,session'', ,,x11'', etc.
                            \item
                                  Absenderkanal: ist ein lokaler Bezeichner vom Typ uint32 und wird
                                  vom Anforderer dieses Kanals gewählt
                            \item
                                  initial window size: ist vom Typ uint32 und gibt an, wie viele
                                  Bytes an den Initiator gesendet werden dürfen, bevor das Fenster
                                  vergrößert werden muss
                            \item
                                  maximale Paketgröße: ist vom Typ uint32 und legt die maximale
                                  Paketgröße fest, die der Initiator für diesen Kanal zu akzeptieren
                                  bereit ist
                            \item
                                  weitere Parameter, die vom Typ des Kanals abhängen, können folgen
                        \end{itemize}
                  \item
                        Wenn der Empfänger dieser Nachricht die Kanalanfrage nicht annehmen
                        will, antwortet er mit der Nachricht
                        ssh\_msg\_channel\_open\_failure (Code 92):

                        \begin{itemize}
                            \item
                                  Empfängerkanal: die vom Absender in der Öffnungsanfrage angegebene
                                  ID
                            \item
                                  reason code: ist vom Typ uint32 und gibt den Grund für die
                                  Ablehnung an
                            \item
                                  additional textual information: ist vom Typ string
                            \item
                                  language tag: ist vom Typ string und entspricht dem RFC 1766
                        \end{itemize}
                  \item
                        Wenn der Empfänger dieser Nachricht die Kanalanfrage annehmen will,
                        antwortet er mit der Nachricht ssh\_msg\_channel\_open\_confirmation
                        (Code 91) und den folgenden Parametern

                        \begin{itemize}
                            \item
                                  Empfänger-Kanal: die vom Absender in der Öffnungsanforderung
                                  angegebene ID
                            \item
                                  Absenderkanal: die dem Kanal vom Antwortenden gegebene Kennung
                            \item
                                  initial window size: ist vom Typ uint32 und gibt an, wie viele
                                  Bytes an den Responder gesendet werden können, bevor das Fenster
                                  vergrößert werden muss
                            \item
                                  maximum packet size: ist vom Typ uint32 und legt die maximale
                                  Paketgröße fest, die der Responder für diesen Kanal zu akzeptieren
                                  bereit ist
                            \item
                                  weitere Parameter, die vom Kanaltyp abhängen, können folgen
                        \end{itemize}
              \end{itemize}
        \item
              Sobald ein Kanal geöffnet ist, sind die folgenden Aktionen möglich:

              \begin{itemize}
                  \item
                        Datenübertragung (allerdings sollte die empfangende Seite wissen,
                        ,,was mit den Daten zu tun ist'', was eine weitere vorherige
                        Aushandlung erfordern kann)
                  \item
                        Kanaltypspezifische Anfragen
                  \item
                        Schließung des Kanals
              \end{itemize}
        \item
              Für die Datenübertragung sind die folgenden Nachrichten definiert:

              \begin{itemize}
                  \item
                        ssh\_msg\_channel\_data: mit den beiden Parametern Empfängerkanal,
                        Daten
                  \item
                        ssh\_msg\_channel\_extended\_data: erlaubt die zusätzliche Angabe
                        eines Datentypcodes und ist nützlich, um Fehler zu signalisieren,
                        z.B. bei interaktiven Shells
                  \item
                        ssh\_msg\_channel\_window\_adjust: erlaubt es, das
                        Flusskontrollfenster des Empfängerkanals um die angegebene Anzahl
                        von Bytes zu erweitern
              \end{itemize}
        \item
              Schließen von Kanälen:

              \begin{itemize}
                  \item
                        Wenn eine Peer-Entität keine Daten mehr an einen Kanal senden will,
                        sollte sie dies der anderen Seite mit der Nachricht
                        ssh\_msg\_channel\_eof signalisieren
                  \item
                        Wenn eine der beiden Seiten einen Kanal beenden möchte, sendet sie
                        die Nachricht ssh\_msg\_channel\_close mit dem Parameter recipient
                        channel
                  \item
                        Beim Empfang der Nachricht ssh\_msg\_channel\_close muss eine
                        Peer-Entität mit einer ähnlichen Nachricht antworten, es sei denn,
                        sie hat bereits die Schließung dieses Kanals beantragt.
                  \item
                        Sowohl nach dem Empfang als auch nach dem Senden der Nachricht
                        ssh\_msg\_channel\_close für einen bestimmten Kanal kann die ID
                        dieses Kanals wiederverwendet werden.
              \end{itemize}
        \item
              Kanaltypspezifische Anfragen erlauben es, bestimmte Eigenschaften
              eines Kanals anzufordern, z. B. dass die empfangende Seite weiß, wie
              sie die über diesen Kanal gesendeten Daten verarbeiten soll, und
              werden mit signalisiert:

              \begin{itemize}
                  \item
                        ssh\_msg\_channel\_request: mit den Parametern recipient channel,
                        request type (string), want reply (bool) und weiteren
                        anfragespezifischen Parametern
                  \item
                        ssh\_msg\_channel\_success: mit dem Parameter recipient channel
                  \item
                        ssh\_msg\_channel\_failure: mit dem Parameter recipient channel
              \end{itemize}
        \item
              Beispiel 1 - Anfordern einer interaktiven Sitzung und Starten einer
              Shell darin:

              \begin{itemize}
                  \item
                        Zunächst wird ein Kanal vom Typ ,,session'' geöffnet
                  \item
                        Ein Pseudo-Terminal wird angefordert, indem eine
                        ssh\_msg\_channel\_request-Nachricht gesendet wird, wobei der
                        Anforderungstyp auf ,,pty-req'' gesetzt wird
                  \item
                        Falls erforderlich, können Umgebungsvariablen gesetzt werden, indem
                        ssh\_msg\_channel\_request-Nachrichten mit dem Anforderungstyp
                        ,,env'' gesendet werden.
                  \item
                        Dann wird der Start eines Shell-Prozesses über eine
                        ssh\_msg\_channel\_request-Nachricht mit dem Request-Typ ,,shell''
                        gefordert (dies führt normalerweise zum Start der Standard-Shell für
                        den Benutzer, wie sie in /etc/passwd definiert ist)
                  \item
                        Anfordern einer interaktiven Sitzung und Starten einer Shell darin:
                        \textbar{} SSH Client \textbar{} \textbar{} SSH Server \textbar{}
                        \textbar{}
                        -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
                        \textbar{} -\/-\/-\/- \textbar{}
                        -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
                        \textbar{} \textbar{} ssh\_msg\_channel\_open (,,session'', 20,
                        2048, 512) \textbar{} -\/-\/-\textgreater{} \textbar{} \textbar{}
                        \textbar{} \textless-\/-\/- \textbar{}
                        ssh\_msg\_channel\_open\_confirmation(20, 31, 1024, 256) \textbar{}
                        \textbar{} ssh\_msg\_channel\_request (31, ,,pty-req'', false, ...)
                        \textbar{} -\/-\/-\textgreater{} \textbar{} \textbar{}
                        ssh\_msg\_channel\_request (31, ,,env'', false, ,,home'',
                        ,,/home/username'') \textbar{} -\/-\/-\textgreater{} \textbar{}
                        \textbar{} ssh\_msg\_channel\_request (31, ,,shell'', true, ...)
                        \textbar{} -\/-\/-\textgreater{} \textbar{} \textbar{} \textbar{}
                        \textless-\/-\/- \textbar{} ssh\_msg\_channel\_success(20)
                        \textbar{}

                        {[}Nutzdatenaustausch findet ab jetzt statt...{]}
              \end{itemize}
    \end{itemize}


    \subsection{SSH-Verbindungsprotokoll
        II}

    \begin{itemize}
        \item
              Beispiel 2 - Anforderung der X11-Weiterleitung:

              \begin{itemize}
                  \item
                        Zuerst wird ein Kanal des Typs ,,session'' geöffnet
                  \item
                        Die X11-Weiterleitung wird durch Senden einer
                        ssh\_msg\_channel\_request-Nachricht mit dem Anforderungstyp
                        ,,x11-req'' angefordert
                  \item
                        Wenn später eine Anwendung auf dem Server gestartet wird, die auf
                        das Terminal des Client-Rechners zugreifen muss (der X11-Server, der
                        auf dem Client-Rechner läuft), wird ein neuer Kanal über
                        ssh\_msg\_channel\_open geöffnet, wobei der Kanaltyp auf ,,x11'' und
                        die IP-Adresse und Portnummer des Absenders als zusätzliche
                        Parameter gesetzt werden
              \end{itemize}
        \item
              Beispiel 3 - Einrichtung einer TCP/IP-Portweiterleitung:

              \begin{itemize}
                  \item
                        Eine Partei muss die Portweiterleitung von ihrem eigenen Ende in die
                        andere Richtung nicht explizit anfordern. Wenn sie jedoch
                        Verbindungen zu einem Port auf der anderen Seite an ihre eigene
                        Seite weiterleiten lassen möchte, muss sie dies explizit über eine
                        ssh\_msg\_global\_request-Nachricht mit den Parametern
                        ,,tcpip-forward'', want-reply, zu bindende Adresse (,,0.0.0.0'' für
                        jede Quelladresse) und zu bindende Portnummer anfordern (diese
                        Anforderung wird normalerweise vom Client gesendet)
                  \item
                        Wenn eine Verbindung zu einem Port kommt, für den eine Weiterleitung
                        angefordert wurde, wird ein neuer Kanal über ssh\_msg\_channel\_open
                        mit dem Typ ,,forwarded-tcpip'' und den Adressen des Ports, der
                        verbunden wurde, sowie des ursprünglichen Quellports als Parameter
                        geöffnet (diese Nachricht wird normalerweise vom Server gesendet)
                  \item
                        Wenn eine Verbindung zu einem (Client-)Port kommt, der lokal als
                        weitergeleitet eingestellt ist, wird ein neuer Kanal angefordert,
                        wobei der Typ auf ,,direct-tcpip'' gesetzt wird und die folgenden
                        Adressinformationen in zusätzlichen Parametern angegeben werden:

                        \begin{itemize}
                            \item
                                  host to connect, port to connect: Adresse, mit der der Empfänger
                                  diesen Kanal verbinden soll
                            \item
                                  Absender-IP-Adresse, Absender-Port: Quelladresse der Verbindung
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Schlussfolgerung}

    \begin{itemize}
        \item
              Sowohl SSL, TLS als auch SSH eignen sich für die Sicherung der
              Internet-Kommunikation in der (oberen) Transportschicht:

              \begin{itemize}
                  \item
                        Alle drei Sicherheitsprotokolle arbeiten mit einem zuverlässigen
                        Transportdienst, z. B. TCP, und benötigen diesen.
                  \item
                        Es gibt eine datagrammorientierte Variante von TLS, genannt DTLS
                  \item
                        Obwohl SSH in / oberhalb der Transportschicht arbeitet, ist die
                        Server-Authentifizierung hostbasiert und nicht anwendungsbasiert.
                  \item
                        Sicherheitsprotokolle der Transportschicht bieten echten
                        End-to-End-Schutz für Benutzerdaten, die zwischen
                        Anwendungsprozessen ausgetauscht werden.
                  \item
                        Außerdem können sie mit der Paketfilterung der heutigen Firewalls
                        zusammenarbeiten.
                  \item
                        Die Protokoll-Header-Felder von Protokollen der unteren Schicht
                        können jedoch nicht auf diese Weise geschützt werden, so dass sie
                        keine Gegenmaßnahmen für Bedrohungen der Netzinfrastruktur selbst
                        bieten.
              \end{itemize}
    \end{itemize}


    \section{Sicherheitsaspekte der mobilen
      Kommunikation}

    \begin{itemize}
        \item
              Die mobile Kommunikation ist mit den gleichen Bedrohungen konfrontiert
              wie ihr stationäres Pendant:

              \begin{itemize}
                  \item
                        Maskerade, Abhören, Verletzung von Berechtigungen, Verlust oder
                        Veränderung von übertragenen Informationen, Ablehnung von
                        Kommunikationsakten, Fälschung von Informationen, Sabotage
                  \item
                        Es müssen also ähnliche Maßnahmen wie in Festnetzen ergriffen
                        werden.
              \end{itemize}
        \item
              Es gibt jedoch einige spezifische Probleme, die sich aus der Mobilität
              von Benutzern und/oder Geräten ergeben:

              \begin{itemize}
                  \item
                        Einige bereits bestehende Bedrohungen werden noch gefährlicher:

                        \begin{itemize}
                            \item
                                  Die drahtlose Kommunikation ist für Abhörmaßnahmen leichter
                                  zugänglich.
                            \item
                                  Das Fehlen einer physischen Verbindung macht den Zugang zu
                                  Diensten einfacher
                        \end{itemize}
                  \item
                        Einige neue Schwierigkeiten bei der Realisierung von
                        Sicherheitsdiensten:

                        \begin{itemize}
                            \item
                                  Die Authentifizierung muss neu eingerichtet werden, wenn das
                                  mobile Gerät umzieht.
                            \item
                                  Die Schlüsselverwaltung wird schwieriger, da die Identitäten der
                                  Peers nicht im Voraus festgelegt werden können.
                        \end{itemize}
                  \item
                        Eine völlig neue Bedrohung:

                        \begin{itemize}
                            \item
                                  Der Standort eines Geräts/Nutzers wird zu einer wichtigeren
                                  Information, die abzuhören und damit zu schützen sich lohnt
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsection{Standortdatenschutz in
        Mobilfunknetzen}

    \begin{itemize}
        \item
              In den heutigen Mobilfunknetzen gibt es keinen angemessenen Schutz des
              Standortes:

              \begin{itemize}
                  \item
                        GSM / UMTS / LTE:

                        \begin{itemize}
                            \item
                                  Aktive Angreifer können IMSIs auf der Luftschnittstelle sammeln
                            \item
                                  Die Betreiber des besuchten Netzes können den Standort der Nutzer
                                  teilweise verfolgen.
                            \item
                                  Die Betreiber des Heimatnetzes können den Standort des Nutzers
                                  vollständig verfolgen.
                            \item
                                  Zumindest kommunizierende Endsysteme können den Standort eines
                                  mobilen Geräts jedoch nicht in Erfahrung bringen
                        \end{itemize}
              \end{itemize}
        \item
              Drahtloses LAN:

              \begin{itemize}
                  \item
                        Kein Datenschutz für den Standort, da die (weltweit eindeutige)
                        MAC-Adresse in jedem MAC-Frame immer im Klartext enthalten ist
              \end{itemize}
        \item
              Das grundlegende Problem des Datenschutzes:

              \begin{itemize}
                  \item
                        Ein mobiles Gerät sollte erreichbar sein
                  \item
                        Keine (einzelne) Entität im Netz sollte in der Lage sein, den
                        Standort eines mobilen Geräts zu verfolgen
              \end{itemize}
        \item
              Einige grundlegende Ansätze zur Lösung dieses Problems
              {[}Müller99a{]}:

              \begin{itemize}
                  \item
                        Broadcast von Nachrichten:

                        \begin{itemize}
                            \item
                                  Jede Nachricht wird an jeden möglichen Empfänger gesendet
                            \item
                                  Wenn Vertraulichkeit erforderlich ist, wird die Nachricht
                                  asymmetrisch verschlüsselt
                            \item
                                  Dieser Ansatz ist nicht gut skalierbar für große Netzwerke / hohe
                                  Last
                        \end{itemize}
                  \item
                        Temporäre Pseudonyme:

                        \begin{itemize}
                            \item
                                  Mobile Geräte verwenden Pseudonyme, die regelmäßig gewechselt
                                  werden
                            \item
                                  Um das mobile Gerät zu erreichen, ist jedoch eine
                                  Abbildungsinstanz erforderlich, die die Geschichte der Pseudonyme
                                  des Mobiltelefons verfolgen kann.
                        \end{itemize}
                  \item
                        Gemischte Netzwerke:

                        \begin{itemize}
                            \item
                                  Nachrichten werden über verschiedene Entitäten (Mixes) geleitet
                                  und jede Entität kann nur einen Teil der Nachrichtenroute erfahren
                                  (siehe unten)
                        \end{itemize}
              \end{itemize}
        \item
              Adressierungsschemata für standortbezogenen Datenschutz mit Broadcast:

              \begin{itemize}
                  \item
                        Explizite Adressen:

                        \begin{itemize}
                            \item
                                  Jede Entität, die eine explizite Adresse "sieht", kann die
                                  adressierte Entität bestimmen
                        \end{itemize}
                  \item
                        Implizite Adressen:

                        \begin{itemize}
                            \item
                                  Eine implizite Adresse identifiziert kein bestimmtes Gerät oder
                                  einen bestimmten Ort, sondern benennt lediglich eine Einheit, ohne
                                  dass dem Namen eine weitere Bedeutung beigemessen wird.
                            \item
                                  Sichtbare implizite Adressen:

                                  \begin{itemize}
                                      \item
                                            Entitäten, die mehrere Vorkommen einer Adresse sehen, können auf
                                            Gleichheit prüfen
                                  \end{itemize}
                            \item
                                  Unsichtbare implizite Adressen:

                                  \begin{itemize}
                                      \item
                                            Nur die adressierte Einheit kann die Gleichheit der Adresse
                                            überprüfen.
                                      \item
                                            Dies erfordert Operationen mit öffentlichen Schlüsseln:
                                            \$ImplAddr\_A =\{r\_B, r\_A\}\_\{+K\_A\}\$ wobei \$r\_A\$ von
                                            der adressierten Entität gewählt wird und \$r\_B\$ ein
                                            Zufallswert ist, der von einer Entität \$B\$ erzeugt wird, die
                                            unsichtbar auf die Entität \$A\$ verweisen will
                                  \end{itemize}
                        \end{itemize}
              \end{itemize}
        \item
              Vorübergehende Pseudonyme:

              \begin{itemize}
                  \item
                        Der Standort eines Gerätes A wird nicht mehr mit seiner Kennung
                        \$ID\_A\$, sondern mit einem wechselnden Pseudonym \$P\_A(t)\$
                        gespeichert.

                        \begin{itemize}
                            \item
                                  Beispiel: VLRs in GSM kennen und speichern möglicherweise nur die
                                  TMSI (die eine Art temporäres Pseudonym ist)
                        \end{itemize}
                  \item
                        Die Zuordnung einer IDA zum aktuellen Pseudonym \$P\_A(t)\$ wird in
                        einem vertrauenswürdigen Gerät gespeichert

                        \begin{itemize}
                            \item
                                  Beispiel: GSM HLRs könnten als vertrauenswürdige Geräte realisiert
                                  werden
                        \end{itemize}
                  \item
                        Wenn ein eingehender Anruf an den aktuellen Standort von Gerät A
                        weitergeleitet werden muss:

                        \begin{itemize}
                            \item
                                  Der Netzbetreiber von Gerät A fragt das vertrauenswürdige Gerät
                                  nach dem aktuellen Pseudonym \$P\_A(t)\$
                            \item
                                  Das Netz leitet den Anruf dann an den aktuellen Standort von A
                                  weiter, indem es das temporäre Pseudonym in einer
                                  Standortdatenbank nachschlägt.
                            \item
                                  Es ist wichtig, dass die Einrichtungen, die einen Anruf
                                  weiterleiten, nichts über die ursprüngliche Adresse der
                                  Rufaufbau-Nachricht erfahren können (\$\textbackslash rightarrow\$
                                  implizite Adressen)
                            \item
                                  Die Verwendung von Mischungen (siehe unten) kann einen
                                  zusätzlichen Schutz gegen Angriffe von kolludierenden
                                  Netzeinheiten bieten
                        \end{itemize}
              \end{itemize}
        \item
              Kommunikations-Mixe:

              \begin{itemize}
                  \item
                        Das Konzept wurde 1981 von D. Chaum für nicht zurückverfolgbare
                        E-Mail-Kommunikation erfunden
                  \item
                        Ein Mix verbirgt die Kommunikationsbeziehungen zwischen Absendern
                        und Empfängern:

                        \begin{itemize}
                            \item
                                  Er puffert eingehende Nachrichten, die asymmetrisch verschlüsselt
                                  sind, so dass nur der Mix sie entschlüsseln kann.
                            \item
                                  Er verändert das "Aussehen" von Nachrichten, indem er sie
                                  entschlüsselt
                            \item
                                  Er ändert die Reihenfolge der Nachrichten und leitet sie in
                                  Stapeln weiter.
                            \item
                                  Wenn jedoch der Mix kompromittiert wird, kann ein Angreifer
                                  "alles" erfahren.
                        \end{itemize}
                  \item
                        Die Sicherheit kann durch kaskadierende Mixe erhöht werden.
                  \item
                        Beispiel: A sendet eine Nachricht m an B über zwei Mixe M1 und M2

                        \begin{itemize}
                            \item
                                  \$A\textbackslash rightarrow M1: \{r\_1 ,\{r\_2 ,\{r\_3 ,
                                  m\}\emph{\{+K\_B\}\}}\{+K\_\{M2\}\}\}\emph{\{+K}\{M1\}\}\$
                            \item
                                  \$M1\textbackslash rightarrow M2:\{r\_2 ,\{r\_3 ,
                                  m\}\emph{\{+K\_B\}\}}\{+K\{M2\}\}\$
                            \item
                                  \$M2\textbackslash rightarrow B: \{r\_3 , m\}\_\{+K\_B\}\$
                            \item
                                  Es ist wichtig, dass die Mischungen "genug" Nachrichten
                                  verarbeiten
                        \end{itemize}
                  \item
                        Dieses Konzept lässt sich auf die mobile Kommunikation übertragen
                        {[}Müller99a{]}
              \end{itemize}
    \end{itemize}


    \section{Sicherheit von drahtlosen lokalen
      Netzen}


    \subsection{IEEE 802.11}

    \begin{itemize}
        \item
              IEEE 802.11 {[}IEEE12{]} standardisiert die Medienzugriffskontrolle
              (MAC) und die physikalischen Eigenschaften eines drahtlosen lokalen
              Netzwerks (LAN).
        \item
              Der Standard umfasst mehrere physikalische Schichteinheiten:

              \begin{itemize}
                  \item
                        Derzeit zwischen 1-300 Mbit/s
                  \item
                        2,4-GHz-Band und 5-GHz-Band
                  \item
                        Viele verschiedene Modulationsverfahren
              \end{itemize}
        \item
              Die Übertragung im lizenzfreien 2,4-GHz-Band impliziert:

              \begin{itemize}
                  \item
                        Medium-Sharing mit unfreiwilligen 802.11-Geräten
                  \item
                        Überlappung von logisch getrennten Wireless LANs
                  \item
                        Überlappung mit Nicht-802.11-Geräten
              \end{itemize}
        \item
              Die Medienzugriffskontrolle (MAC) unterstützt sowohl den Betrieb unter
              Kontrolle eines Access Points als auch zwischen unabhängigen
              Stationen.
        \item
              In diesem Kurs werden wir uns hauptsächlich auf die
              (Un-)Sicherheitsaspekte des Standards konzentrieren!
    \end{itemize}

    802.11 - Architektur eines Infrastrukturnetzes

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-802.11-network-architecture.png}
        \item
              Station (STA): Endgerät mit Zugriffsmechanismen auf das drahtlose
              Medium und Funkkontakt zum Access Point
        \item
              Basic Service Set (BSS): Gruppe von Stationen, die dieselbe
              Funkfrequenz verwenden
        \item
              Zugangspunkt: Station, die in das drahtlose LAN und das
              Verteilungssystem integriert ist
        \item
              Portal: Brücke zu anderen (kabelgebundenen) Netzwerken
        \item
              Verteilungssystem: Verbindungsnetz zur Bildung eines logischen Netzes
              (Extended Service Set, ESS), das auf mehreren BSS basiert
    \end{itemize}

    802.11 - Architektur eines Ad-Hoc-Netzes

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-802.11-ad-hoc-architecture.png}
        \item
              Station (STA): Endgerät mit Zugriffsmechanismen auf das drahtlose
              Medium
        \item
              Basic Service Set (BSS): Gruppe von Stationen, die dieselbe
              Funkfrequenz verwenden
        \item
              Ad-Hoc-Netze ermöglichen die direkte Kommunikation zwischen
              Endsystemen innerhalb einer begrenzten Reichweite
        \item
              Da es keine Infrastruktur gibt, ist keine Kommunikation zwischen
              verschiedenen BSSs möglich
    \end{itemize}

    Sicherheitsdienste von IEEE 802.11

    \begin{itemize}
        \item
              Die Sicherheitsdienste von IEEE 802.11 wurden ursprünglich wie folgt
              realisiert:

              \begin{itemize}
                  \item
                        Authentifizierungsdienst für Entitäten
                  \item
                        Wired Equivalent Privacy (WEP) Mechanismus
              \end{itemize}
        \item
              WEP soll die folgenden Sicherheitsdienste bieten

              \begin{itemize}
                  \item
                        Vertraulichkeit
                  \item
                        Authentifizierung der Datenherkunft / Datenintegrität
                  \item
                        Zugangskontrolle in Verbindung mit Schichtenmanagement
              \end{itemize}
        \item
              WEP verwendet die folgenden Algorithmen:

              \begin{itemize}
                  \item
                        Die RC4-Stromchiffre (siehe Kapitel 3)
                  \item
                        Die CRC-Prüfsumme (Cyclic Redundancy Code) zur Fehlererkennung
              \end{itemize}
    \end{itemize}


    \subsection{Der zyklische
        Redundanzcode}

    \begin{itemize}
        \item
              Der zyklische Redundanzcode (CRC) ist ein Fehlererkennungscode
        \item
              Mathematische Grundlage:

              \begin{itemize}
                  \item
                        Bitstrings werden als Darstellungen von Polynomen mit den
                        Koeffizienten 0 und 1 behandelt \$\textbackslash Rightarrow\$ Ein
                        Bitstring, der eine Nachricht M darstellt, wird als M(x)
                        interpretiert
                  \item
                        Polynomarithmetik wird modulo 2 durchgeführt
                        \$\textbackslash Rightarrow\$ Addition und Subtraktion sind
                        identisch mit XOR
              \end{itemize}
        \item
              CRC-Berechnung für eine Nachricht \$M(x)\$:

              \begin{itemize}
                  \item
                        A und B einigen sich auf ein Polynom \$G(x)\$; üblicherweise ist
                        \$G(x)\$ standardisiert
                  \item
                        Sei \$n\$ der Grad von \$G(x)\$, d.h. die Länge von \$G(x)\$ sei
                        \$n+1\$
                  \item
                        Wenn dann \$\textbackslash frac\{M(x)\textbackslash times
                        2\^{}n\}\{G(x)\}=Q(x)+\textbackslash frac\{R(x)\}\{G(x)\}\$ gilt
                        \$\textbackslash frac\{M(x)\textbackslash times 2\^{}n
                        +R(x)\}\{G(x)\}\$ wobei \$R(x)\$ der Rest von \$M(x)\$ geteilt durch
                        \$G(x)\$ ist
                  \item
                        Normalerweise wird \$R(x)\$ vor der Übertragung an \$M(x)\$
                        angehängt, und \$Q(x)\$ ist nicht von Interesse, da es nur geprüft
                        wird, wenn \$\textbackslash frac\{M(x)\textbackslash times
                        2\^{}n+R(x)\}\{G(x)\}\$ mit Rest \$0\$ dividiert
              \end{itemize}
        \item
              Betrachten wir nun zwei Nachrichten \$M\_1\$ und \$M\_2\$ mit CRCs
              \$R\_1\$ und \$R\_2\$:

              \begin{itemize}
                  \item
                        Da \$\textbackslash frac\{M\_1(x)\textbackslash times
                        2\^{}n+R\_1(x)\}\{G(x)\}\$ und
                        \$\textbackslash frac\{M\_2(x)\textbackslash times
                        2\^{}n+R\_2(x)\}\{G(x)\}\$ mit dem Rest \$0\$ teilen, teilt sich
                        auch \$\textbackslash frac\{M\_1(x)\textbackslash times 2\^{}n
                        +R\_1(x)+M\_2(x)\textbackslash times 2\^{}n +R\_2(x)\}\{G(x)\}
                        =\textbackslash frac\{(M\_1(x)+M\_2(x))\textbackslash times 2\^{}n
                        +(R\_1(x)+R\_2(x))\}\{G(x)\}\$ teilt mit Rest \$0\$
                  \item
                        \$\textbackslash Rightarrow\$ CRC ist linear, d.h. \$CRC(M\_1 +
                        M\_2) = CRC(M\_1) + CRC(M\_2)\$
              \end{itemize}
        \item
              Diese Eigenschaft macht CRC schwach für kryptographische Zwecke!
    \end{itemize}


    \subsection{IEEE 802.11
        Entity-Authentifizierung}

    \begin{itemize}
        \item
              Ursprünglich gibt es die IEEE 802.11-Authentifizierung in zwei
              ,,Geschmacksrichtungen'':

              \begin{itemize}
                  \item
                        Offene System-Authentifizierung: ,,Im Wesentlichen handelt es sich
                        um einen Null-Authentifizierungsalgorithmus.'' (IEEE 802.11)
                  \item
                        Shared-Key-Authentifizierung:

                        \begin{itemize}
                            \item
                                  Die ,,Shared-Key-Authentifizierung unterstützt die
                                  Authentifizierung von STAs entweder als Mitglied derer, die einen
                                  gemeinsamen geheimen Schlüssel kennen, oder als Mitglied derer,
                                  die ihn nicht kennen.'' (IEEE 802.11, Abschnitt 8.1.2)
                            \item
                                  Es wird davon ausgegangen, dass der erforderliche geheime,
                                  gemeinsam genutzte Schlüssel den teilnehmenden STAs über einen
                                  sicheren, von IEEE 802.11 unabhängigen Kanal übermittelt wurde.
                        \end{itemize}
              \end{itemize}
    \end{itemize}

    IEEE 802.11's Shared Key Authentication Dialog:

    \begin{itemize}
        \item
              Die Authentifizierung sollte zwischen Stationen und Zugangspunkten
              erfolgen und könnte auch zwischen beliebigen Stationen durchgeführt
              werden.
        \item
              Bei der Authentifizierung fungiert eine Station als Requestor (A) und
              die andere als Responder (B)
        \item
              Der Authentifizierungsdialog:

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$A \textbackslash rightarrow B: (Authentifizierung, 1, ID\_A)\$
                  \item
                        \$B \textbackslash rightarrow A: (Authentifizierung, 2, r\_B)\$
                  \item
                        \$A \textbackslash rightarrow B: \{Authentifizierung, 3,
                        r\_B\}\emph{\{K}\{A,B\}\}\$
                  \item
                        \$B \textbackslash rightarrow A: (Authentifizierung, 4,
                        erfolgreich)\$
              \end{enumerate}
        \item
              Die gegenseitige Authentifizierung erfordert zwei unabhängige
              Protokolldurchläufe, einen in jeder Richtung
        \item
              Aber: ein Angreifer kann sich nach dem Abhören eines
              Protokolldurchlaufs ausgeben, da er einen gültigen Schlüsselstrom aus
              den Nachrichten 2 und 3 erhalten kann!
    \end{itemize}


    \subsection{IEEE 802.11's Wired Equivalence
        Privacy}

    \begin{itemize}
        \item
              IEEE 802.11's WEP verwendet RC4 als Pseudo-Zufallsbit-Generator
              (PRNG):

              \begin{itemize}
                  \item
                        Für jede zu schützende Nachricht M wird ein
                        24-Bit-Initialisierungsvektor (IV) mit dem gemeinsamen Schlüssel
                        \$K\_\{BSS\}\$ verkettet, um den Seed des PRNG zu bilden.
                  \item
                        Der Integritätsprüfwert (ICV) von M wird mit CRC berechnet und an
                        die Nachricht angehängt (,,\textbar\textbar'')
                  \item
                        Die resultierende Nachricht \$(M \textbar\textbar{} ICV)\$ wird mit
                        dem von \$RC4(IV \textbar\textbar{} K\_\{BSS\})\$ erzeugten
                        Schlüsselstrom XOR-verknüpft (,,\$\textbackslash oplus\$'')
                  \item
                        % \includegraphics{Assets/NetworkSecurity-802.11-wep-encryption.png}
              \end{itemize}
        \item
              Da die IV mit jeder Nachricht im Klartext gesendet wird, kann jeder
              Empfänger, der \$K\_\{BSS\}\$ kennt, den entsprechenden Schlüsselstrom
              zur Entschlüsselung einer Nachricht erzeugen.

              \begin{itemize}
                  \item
                        Dadurch wird die wichtige Eigenschaft der Selbstsynchronisation von
                        WEP gewährleistet
                  \item
                        Der Entschlüsselungsprozess ist im Grunde die Umkehrung der
                        Verschlüsselung:
                  \item
                        % \includegraphics{Assets/NetworkSecurity-802.11-wep-decryption.png}
              \end{itemize}
    \end{itemize}


    \subsection{Die Sicherheitsansprüche von IEEE
        802.11}

    \begin{itemize}
        \item
              WEP wurde entwickelt, um die folgenden Sicherheitseigenschaften zu
              gewährleisten:

              \begin{itemize}
                  \item
                        Vertraulichkeit:

                        \begin{itemize}
                            \item
                                  Nur Stationen, die über \$K\_\{BSS\}\$ verfügen, können mit WEP
                                  geschützte Nachrichten lesen
                        \end{itemize}
                  \item
                        Authentifizierung der Datenherkunft / Datenintegrität:

                        \begin{itemize}
                            \item
                                  Böswillige Veränderungen von WEP-geschützten Nachrichten können
                                  erkannt werden
                        \end{itemize}
                  \item
                        Zugriffskontrolle in Verbindung mit Schichtenmanagement:

                        \begin{itemize}
                            \item
                                  Wenn in der Schichtenverwaltung so eingestellt, werden nur
                                  WEP-geschützte Nachrichten von Empfängern akzeptiert
                            \item
                                  Somit können Stationen, die \$K\_\{BSS\}\$ nicht kennen, nicht an
                                  solche Empfänger senden
                        \end{itemize}
              \end{itemize}
        \item
              Leider trifft keine der obigen Behauptungen zu...
    \end{itemize}


    \subsubsection{Schwachstelle \#1: Die
        Schlüssel}

    \begin{itemize}
        \item
              IEEE 802.11 sieht keine Schlüsselverwaltung vor:

              \begin{itemize}
                  \item
                        Manuelle Verwaltung ist fehleranfällig und unsicher
                  \item
                        Die gemeinsame Verwendung eines Schlüssels für alle Stationen eines
                        BSS führt zu zusätzlichen Sicherheitsproblemen
                  \item
                        Als Folge der manuellen Schlüsselverwaltung werden die Schlüssel
                        selten geändert.
                  \item
                        Eine weitere Folge ist, dass die ,,Sicherheit'' oft sogar
                        ausgeschaltet ist!
              \end{itemize}
        \item
              Schlüssellänge:

              \begin{itemize}
                  \item
                        Die im ursprünglichen Standard festgelegte Schlüssellänge von 40 Bit
                        bietet nur geringe Sicherheit
                  \item
                        Der Grund dafür war die Exportierbarkeit
                  \item
                        Wireless LAN-Karten erlauben oft auch Schlüssel der Länge 104 Bit,
                        aber das macht die Situation nicht besser, wie wir später sehen
                        werden
              \end{itemize}
    \end{itemize}


    \subsubsection{Schwachstelle \#2: WEP-Vertraulichkeit ist
        unsicher}

    \begin{itemize}
        \item
              Selbst mit gut verteilten und langen Schlüsseln ist WEP unsicher
        \item
              Der Grund dafür ist die Wiederverwendung des Schlüsselstroms:

              \begin{itemize}
                  \item
                        Erinnern Sie sich, dass die Verschlüsselung mit jeder Nachricht neu
                        synchronisiert wird, indem eine IV der Länge 24 Bit an
                        \$K\_\{BSS\}\$ angehängt und der PRNG neu initialisiert wird
                  \item
                        Betrachten wir zwei Klartexte M 1 und M 2, die mit demselben IV 1
                        verschlüsselt wurden:

                        \begin{itemize}
                            \item
                                  \$C\_1 = P\_1 \textbackslash oplus RC4 (IV\_1 , K\_\{BSS\})\$
                            \item
                                  \$C\_2 = P\_2 \textbackslash oplus RC4 (IV\_1 , K\_\{BSS\})\$
                                  dann:
                            \item
                                  \$C\_1 \textbackslash oplus C\_2 = (P\_1 \textbackslash oplus RC4
                                  (IV\_1, K\_\{BSS\})) \textbackslash oplus
                                  (P\_2\textbackslash oplus RC4 (IV\_1 , K\_\{BSS\})) = P\_1
                                  \textbackslash oplus P\_2\$
                        \end{itemize}
                  \item
                        Wenn also ein Angreifer z.B. \$P\_1\$ und \$C\_1\$ kennt, kann er
                        \$P\_2\$ aus \$C\_2\$ wiederherstellen, ohne den Schlüssel
                        \$K\_\{BSS\}\$ zu kennen.

                        \begin{itemize}
                            \item
                                  Kryptographen nennen dies einen Angriff mit bekanntem Klartext
                        \end{itemize}
              \end{itemize}
        \item
              Wie oft kommt die Wiederverwendung des Schlüsselstroms vor?

              \begin{itemize}
                  \item
                        In der Praxis recht häufig, da viele Implementierungen die IV
                        schlecht wählen
                  \item
                        Selbst bei optimaler Wahl, da die IV-Länge 24 Bit beträgt, wird eine
                        stark ausgelastete Basisstation eines 11-Mbit/s-WLAN den verfügbaren
                        Speicherplatz in einem halben Tag erschöpfen
              \end{itemize}
    \end{itemize}


    \subsubsection{Schwachstelle \#3: WEP-Datenintegrität ist
        unsicher}

    \begin{itemize}
        \item
              Erinnern Sie sich, dass CRC eine lineare Funktion ist und RC4
              ebenfalls linear ist
        \item
              Nehmen wir an, A sendet eine verschlüsselte Nachricht an B, die von
              einem Angreifer E abgefangen wird:

              \begin{itemize}
                  \item
                        \$A \textbackslash rightarrow B: (IV, C) mit C = RC4(IV, K\_\{BSS\})
                        \textbackslash oplus (M, CRC(M))\$
              \end{itemize}
        \item
              Der Angreifer E kann einen neuen Chiffretext \$C'\$ konstruieren, der
              zu einer Nachricht \$M'\$ mit einer gültigen Prüfsumme \$CRC(M')\$
              entschlüsselt wird:

              \begin{itemize}
                  \item
                        E wählt eine beliebige Nachricht \$\textbackslash delta\$ mit der
                        gleichen Länge
                  \item
                        \$C' = C \textbackslash oplus (\textbackslash delta,
                        CRC(\textbackslash delta)) = RC4(IV, K\_\{BSS\})
                        \textbackslash oplus (M, CRC(M)) \textbackslash oplus
                        (\textbackslash delta, CRC(\textbackslash delta))\$
                  \item
                        \$= RC4(IV, K\_\{BSS\}) \textbackslash oplus (M \textbackslash oplus
                        \textbackslash delta, CRC(M) \textbackslash oplus
                        CRC(\textbackslash delta))\$
                  \item
                        \$= RC4(IV, K\_\{BSS\}) \textbackslash oplus (M \textbackslash oplus
                        \textbackslash delta, CRC(M \textbackslash oplus
                        \textbackslash delta))\$
                  \item
                        \$= RC4(IV, K\_\{BSS\}) \textbackslash oplus (M', CRC(M'))\$
                  \item
                        Man beachte, dass \$E\$ \$M'\$ nicht kennt, da es \$M\$ nicht kennt.
                  \item
                        Dennoch führt ein ,,1'' an Position \$n\$ in
                        \$\textbackslash delta\$ zu einem umgedrehten Bit an Position n in
                        \$M'\$, so dass E kontrollierte Änderungen an \$M\$ vornehmen kann
                  \item
                        \$\textbackslash Rightarrow\$ Datenherkunftsauthentifizierung /
                        Datenintegrität von WEP ist unsicher!
              \end{itemize}
    \end{itemize}


    \subsubsection{Schwachstelle \#4: WEP-Zugangskontrolle ist
        unsicher}

    \begin{itemize}
        \item
              Erinnern Sie sich, dass die Integritätsfunktion ohne einen Schlüssel
              berechnet wird
        \item
              Betrachten wir einen Angreifer, der ein Klartext-Chiffretext-Paar in
              Erfahrung bringt:

              \begin{itemize}
                  \item
                        Da der Angreifer \$M\$ und \$C=RC4(IV,
                        K\_\{BSS\})\textbackslash oplus (M, CRC(M))\$ kennt, kann er den zur
                        Erzeugung von \$C\$ verwendeten Schlüsselstrom berechnen
                  \item
                        Wenn \$E\$ später eine Nachricht \$M'\$ senden will, kann er \$C' =
                        RC4(IV, K\_\{BSS\})\textbackslash oplus (M', CRC(M'))\$ berechnen
                        und die Nachricht \$(IV, C')\$ senden.
                  \item
                        Da die Wiederverwendung alter IV-Werte möglich ist, ohne beim
                        Empfänger einen Alarm auszulösen, handelt es sich um eine gültige
                        Nachricht
                  \item
                        Eine ,,Anwendung'' für diesen Angriff ist die unbefugte Nutzung von
                        Netzwerkressourcen:

                        \begin{itemize}
                            \item
                                  Der Angreifer sendet IP-Pakete, die für das Internet bestimmt
                                  sind, an den Zugangspunkt, der sie entsprechend weiterleitet und
                                  dem Angreifer freien Zugang zum Internet gewährt
                        \end{itemize}
              \end{itemize}
        \item
              \$\textbackslash Rightarrow\$ WEP Access Control kann mit bekanntem
              Klartext umgangen werden
    \end{itemize}


    \subsubsection{Schwachstelle Nr. 5: Schwachstelle in der
        RC4-Schlüsselberechnung}

    \begin{itemize}
        \item
              Anfang August 2001 wurde ein weiterer Angriff auf WEP entdeckt:

              \begin{itemize}
                  \item
                        Der gemeinsame Schlüssel kann in weniger als 15 Minuten
                        wiederhergestellt werden, vorausgesetzt, dass etwa 4 bis 6 Millionen
                        Pakete wiederhergestellt wurden.
                  \item
                        Bei dem Angriff handelt es sich um einen Angriff mit verwandten
                        Schlüsseln, bei dem die Verwendung von RC4 durch WEP ausgenutzt
                        wird:

                        \begin{itemize}
                            \item
                                  RC4 ist anfällig für die Ableitung von Bits eines Schlüssels,
                                  wenn:

                                  \begin{itemize}
                                      \item
                                            viele Nachrichten mit einem Schlüsselstrom verschlüsselt werden,
                                            der aus einem variablen Initialisierungsvektor und einem festen
                                            Schlüssel erzeugt wird, und
                                      \item
                                            die Initialisierungsvektoren und der Klartext der ersten beiden
                                            Oktette für die verschlüsselten Nachrichten bekannt sind
                                  \end{itemize}
                            \item
                                  Die IV für den Schlüsselstrom wird mit jedem Paket im Klartext
                                  übertragen.
                            \item
                                  Die ersten beiden Oktette eines verschlüsselten Datenpakets können
                                  erraten werden
                        \end{itemize}
                  \item
                        Der Angriff ist in {[}SMF01a{]} und {[}SIR01a{]} beschrieben und
                        wurde später so verfeinert, dass er noch schneller funktioniert
                        {[}TWP07{]}.
                  \item
                        R. Rivest kommentiert dies {[}Riv01a{]}: ,,Diejenigen, die die
                        RC4-basierten WEP- oder WEP2-Protokolle verwenden, um die
                        Vertraulichkeit ihrer 802.11-Kommunikation zu gewährleisten, sollten
                        diese Protokolle als gebrochen betrachten {[}...{]}''
              \end{itemize}
    \end{itemize}


    \subsection{Schlussfolgerungen zu den Unzulänglichkeiten von IEEE
        802.11}

    \begin{itemize}
        \item
              Das ursprüngliche IEEE 802.11 bietet keine ausreichende Sicherheit:

              \begin{itemize}
                  \item
                        Fehlende Schlüsselverwaltung macht die Nutzung der
                        Sicherheitsmechanismen mühsam und führt dazu, dass die Schlüssel
                        selten gewechselt werden oder sogar die Sicherheit ausgeschaltet ist
                  \item
                        Sowohl die Entity-Authentifizierung als auch die Verschlüsselung
                        beruhen auf einem Schlüssel, der von allen Stationen eines
                        Basisdienstes gemeinsam genutzt wird
                  \item
                        Unsicheres Protokoll zur Entitätsauthentifizierung
                  \item
                        Wiederverwendung des Schlüsselstroms ermöglicht Angriffe mit
                        bekanntem Klartext
                  \item
                        Lineare Integritätsfunktion ermöglicht die Fälschung von ICVs
                  \item
                        Unverschlüsselte Integritätsfunktion ermöglicht die Umgehung der
                        Zugangskontrolle durch Erstellung gültiger Nachrichten aus einem
                        bekannten Klartext-Chiffretext-Paar
                  \item
                        Schwachstelle in der RC4-Schlüsselplanung ermöglicht die
                        Kryptoanalyse von Schlüsseln
              \end{itemize}
        \item
              Selbst mit IEEE 802.1X und individuellen Schlüsseln bleibt das
              Protokoll schwach
        \item
              Einige vorgeschlagene Gegenmaßnahmen:

              \begin{itemize}
                  \item
                        Platzieren Sie Ihr IEEE 802.11 Netzwerk außerhalb Ihrer Internet
                        Firewall
                  \item
                        Vertrauen Sie keinem Host, der über IEEE 802.11 verbunden ist.
                  \item
                        Verwenden Sie zusätzlich andere Sicherheitsprotokolle, z. B. PPTP,
                        L2TP, IPSec, SSH, ...
              \end{itemize}
    \end{itemize}


    \subsection{Interlude: Sicherheit in öffentlichen
        WLAN-Hotspots}

    Welche Sicherheit können Sie in einem öffentlichen WLAN-Hotspot
    erwarten?

    \begin{itemize}
        \item
              Bei den meisten Hotspots: Leider fast keine!
        \item
              Wenn Sie außer der Eingabe eines Benutzernamens und eines Passworts
              auf einer Webseite keine weiteren Sicherheitsparameter konfigurieren
              müssen, können Sie Folgendes erwarten:

              \begin{itemize}
                  \item
                        Der Hotspot-Betreiber prüft Ihre Authentizität bei der Anmeldung
                        (oft mit SSL geschützt, um das Abhören Ihres Passworts zu
                        verhindern)
                  \item
                        Nur authentifizierte Clients erhalten den Dienst, da die
                        Paketfilterung den Zugriff auf die Anmeldeseite nur bei
                        erfolgreicher Authentifizierung zulässt.
                  \item
                        Nach Überprüfung der Anmeldeauthentifizierung: keine weiteren
                        Sicherheitsmaßnahmen
                  \item
                        Kein Schutz für Ihre Benutzerdaten:

                        \begin{itemize}
                            \item
                                  Alles kann abgefangen und manipuliert werden
                            \item
                                  Sie können zwar eigene Maßnahmen ergreifen, z.B. VPN oder SSL,
                                  aber die Konfiguration ist oft mühsam oder wird vom
                                  Kommunikationspartner gar nicht unterstützt und die Leistung wird
                                  durch zusätzlichen (pro-Paket-) Overhead beeinträchtigt
                        \end{itemize}
                  \item
                        Plus: Ihre Sitzung kann durch die Verwendung Ihrer MAC- und
                        IP-Adressen gestohlen werden!
              \end{itemize}
        \item
              Konsequenz: bessere WLAN-Sicherheit ist dringend erforderlich
    \end{itemize}


    \subsection{Fixing WLAN Security: IEEE 802.11i, WPA und
        WPA}

    \begin{itemize}
        \item
              Umfang: Definition der Interaktion zwischen 802.1X und 802.11
              Standards
        \item
              TGi definiert zwei Klassen von Sicherheitsalgorithmen für 802.11:

              \begin{itemize}
                  \item
                        Pre-RSN Sicherheitsnetzwerk (\textbackslash rightarrow WEP)
                  \item
                        Robustes Sicherheitsnetzwerk (RSN)
              \end{itemize}
        \item
              Die RSN-Sicherheit besteht aus zwei grundlegenden Teilsystemen:

              \begin{itemize}
                  \item
                        Mechanismen zum Schutz der Daten:

                        \begin{itemize}
                            \item
                                  TKIP - schnelles Re-Keying, um WEP für ein Minimum an Datenschutz
                                  zu verbessern (Marketingname WPA)
                            \item
                                  AES-Verschlüsselung - robuster Datenschutz für lange Zeit
                                  (Marketingname WPA2)
                        \end{itemize}
              \end{itemize}
        \item
              Verwaltung von Sicherheitsvereinbarungen:

              \begin{itemize}
                  \item
                        Unternehmensmodus - basierend auf 802.1X
                  \item
                        Persönlicher Modus - basierend auf Pre-Shared Keys
              \end{itemize}
    \end{itemize}

    (das meiste Material über 802.11i ist aus {[}WM02a{]} entnommen)


    \subsection{WPA-Schlüsselverwaltung}

    \begin{itemize}
        \item
              Im Gegensatz zum ursprünglichen 802.11: paarweise Schlüssel zwischen
              STA und BS, zusätzliche Gruppenschlüssel für Multi- und
              Broadcast-Pakete sowie Station-to-Station-Link (STSL)-Schlüssel
        \item
              Das erste Geheimnis: der 256 Bit Pairwise Master Key (PMK)

              \begin{itemize}
                  \item
                        Unternehmensmodus: Verwendet 802.1X-Authentifizierung und
                        installiert einen neuen Schlüssel, der BS und Client bekannt ist, z.
                        B. durch EAP-TTLS
                  \item
                        Persönlicher Modus: Verwendet einen Pre-Shared Key (PSK), der dem BS
                        und vielen STAs bekannt ist.

                        \begin{itemize}
                            \item
                                  Explizit durch 64 zufällige Hex-Zeichen oder implizit durch ein
                                  Passwort gegeben
                            \item
                                  Wenn Passwort: PMK = PBKDF2(Passwort, SSID, 4096, 256)
                            \item
                                  Wobei PBKDF2 die passwortbasierte Schlüsselableitungsfunktion 2
                                  aus {[}RFC2898{]} mit einer Salz-SSID und einer Ausgangslänge von
                                  256 Bit ist
                            \item
                                  impliziert 2 * 4096 Berechnungen von HMAC-SHA1, um Brute-Force zu
                                  verlangsamen
                        \end{itemize}
              \end{itemize}
        \item
              PMK ist ein Vertrauensanker für die Authentifizierung per EAPOL (EAP
              over LAN) Handshake, wird aber nie direkt verwendet...
        \item
              Für aktuelle kryptographische Protokolle wird ein kurzzeitiger 512 Bit
              Pairwise Transient Key (PTK) wie folgt generiert

              \begin{itemize}
                  \item
                        \$PTK = PRF(PMK, ,,Paarweise Schlüsselerweiterung'',
                        min(Addr\_\{BS\}, Addr\_\{STA\}) \textbar\textbar{}
                        max(Addr\_\{BS\}, Addr\_\{STA\}) \textbar\textbar{} min(r\_\{BS\},
                        r\_\{STA\}) \textbar\textbar{} max(r\_\{BS\}, r\_\{STA\}))\$
                  \item
                        Dabei ist \$PRF(K, A, B)\$ die verkettete Ausgabe von \$HMAC-SHA1(K,
                        A \textbar\textbar{} '0' \textbar\textbar{} B \textbar\textbar{}
                        i)\$ über einen laufenden Index i
              \end{itemize}
        \item
              Der PTK wird aufgeteilt in:

              \begin{itemize}
                  \item
                        EAPOL-Schlüssel-Bestätigungsschlüssel (KCK, erste 128 Bits),

                        \begin{itemize}
                            \item
                                  Wird zum Schutz der Integrität von EAPOL-Nachrichten verwendet
                            \item
                                  Durch HMAC-MD5 (veraltet), HMAC-SHA1-128, AES-128-CMAC
                        \end{itemize}
                  \item
                        EAPOL Key Encryption Key (KEK, zweite 128 Bits),

                        \begin{itemize}
                            \item
                                  Wird zur Verschlüsselung neuer Schlüssel in EAPOL-Nachrichten
                                  verwendet
                            \item
                                  Mit RC4 (veraltet), AES im Key Wrap Mode {[}RFC3394{]}
                        \end{itemize}
                  \item
                        Ein Temporal Key (TK) zum Schutz des Datenverkehrs (ab Bit 256)!
              \end{itemize}
        \item
              Initialer Dialog mit BS:

              \begin{itemize}
                  \item
                        EAPOL (EAP over LAN) 4-Wege-Handshake wird verwendet, um

                        \begin{itemize}
                            \item
                                  Überprüfung der gegenseitigen Kenntnis des PMK
                            \item
                                  Initiiert durch BS, um Schlüssel zu installieren (gruppenweise und
                                  paarweise)
                        \end{itemize}
                  \item
                        Vereinfachter Handshake funktioniert wie folgt:

                        \begin{enumerate}
                            \def\labelenumi{\arabic{enumi}.}
                            \item
                                  \$BS\textbackslash rightarrow STA: (1, r\_\{BS\} , PMKID,
                                  install\textbackslash{} new\textbackslash{} PTK)\$
                            \item
                                  \$STA BS: (2, r\_\{STA\}, MAC\_\{KCK\})\$
                            \item
                                  \$BS STA: (3, r\_\{BS\}, MAC\_\{KCK\}, \{TK\}\_\{KEK\})\$
                            \item
                                  \$STA BS: (4, r\_\{STA\}, MAC\_\{KCK\})\$
                        \end{enumerate}
                  \item
                        Wobei PMKID den PMK identifiziert: obere 128 Bit von
                        \$HMAC-SHA-256(PMK, "PMK Name" \textbar\textbar{} Addr\_\{BS\}
                        \textbar\textbar{} Addr\_\{STA\} )\$
              \end{itemize}
    \end{itemize}


    \subsection{Eine Zwischenlösung: Temporal Key Integrity
        Protokoll}

    \begin{itemize}
        \item
              Ziele des Entwurfs:

              \begin{itemize}
                  \item
                        Schnelle Lösung für das bestehende WEP-Problem, betreibt WEP als
                        Unterkomponente
                  \item
                        Kann in Software implementiert werden, nutzt vorhandene WEP-Hardware
                        wieder
                  \item
                        Anforderungen an vorhandene AP-Hardware:

                        \begin{itemize}
                            \item
                                  33 oder 25 MHz ARM7 oder i486, die bereits vor TKIP mit 90\%
                                  CPU-Auslastung laufen
                            \item
                                  Nur als Software/Firmware-Upgrade gedacht
                            \item
                                  Keine unangemessene Beeinträchtigung der Leistung
                        \end{itemize}
              \end{itemize}
        \item
              Wichtigste Konzepte:

              \begin{itemize}
                  \item
                        Nachrichtenintegritätscode (MIC)
                  \item
                        Gegenmaßnahmen im Falle von MIC-Fehlern
                  \item
                        Sequenzzähler
                  \item
                        Dynamische Schlüsselverwaltung (Re-Keying)
                  \item
                        Schlüsselmischung
              \end{itemize}
        \item
              TKIP erfüllt die Kriterien für einen guten Standard: alle sind damit
              unzufrieden...
        \item
              % \includegraphics{Assets/NetworkSecurity-tkip-mpdu-data-format.png}
    \end{itemize}

    Message Integrity Code Funktion Michael

    \begin{itemize}
        \item
              Schützt vor Fälschungen:

              \begin{itemize}
                  \item
                        Muss billig sein: CPU-Budget 5 Anweisungen / Byte
                  \item
                        Leider schwach: ein \$2\^{}\{29\}\$ Nachrichtenangriff existiert
                  \item
                        Wird über MSDUs berechnet, während WEP über MPDUs läuft
                  \item
                        Verwendet zwei 64-Bit-Schlüssel, einen in jeder Verbindungsrichtung
                  \item
                        Erfordert Gegenmaßnahmen:

                        \begin{itemize}
                            \item
                                  Rekey on active attack (nur wenige Fehlalarme, da CRC zuerst
                                  geprüft wird)
                            \item
                                  Ratenbegrenzung auf eine Neuverschlüsselung pro Minute
                        \end{itemize}
                  \item
                        % \includegraphics{Assets/NetworkSecurity-tkip-rekey.png}
              \end{itemize}
    \end{itemize}

    Wiederholungsschutz und RC4-Schlüsselplanung

    \begin{itemize}
        \item
              Replay-Schutz:

              \begin{itemize}
                  \item
                        Zurücksetzen der Paket-Sequenz \# auf 0 bei Wiederholung
                  \item
                        Erhöhen der Sequenz \# um 1 bei jedem Paket
                  \item
                        Verwerfen aller Pakete, die außerhalb der Sequenz empfangen werden
              \end{itemize}
        \item
              Umgehen Sie die Schwächen der WEP-Verschlüsselung:

              \begin{itemize}
                  \item
                        Erstellen Sie einen besseren paketweisen Verschlüsselungsschlüssel,
                        indem Sie Angriffe mit schwachen Schlüsseln verhindern und WEP IV
                        und paketweisen Schlüssel dekorrelieren
                  \item
                        muss auf vorhandener Hardware effizient sein
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-tkip-replay-protection.png}
    \end{itemize}

    TKIP-Verarbeitung beim Sender

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-tkip-processing.png}
    \end{itemize}

    TKIP-Verarbeitung auf der Empfängerseite

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-tkip-receiver.png}
    \end{itemize}


    \subsection{Die langfristige Lösung: AES-basierter
        WLAN-Schutz}

    \begin{itemize}
        \item
              Zählermodus mit CBC-MAC (CCMP):

              \begin{itemize}
                  \item
                        Obligatorisch zu implementieren: die langfristige Lösung
                  \item
                        Ein völlig neues Protokoll mit wenigen Zugeständnissen an WEP
                  \item
                        Bietet: Datenvertraulichkeit, Authentifizierung der Datenherkunft,
                        Schutz vor Wiederholungen
                  \item
                        Basiert auf AES in Counter Mode Encryption mit CBC-MAC (CCM)

                        \begin{itemize}
                            \item
                                  Verwendung von CBC-MAC zur Berechnung einer MIC für den
                                  Klartext-Header, die Länge des Klartext-Headers und die Nutzdaten
                            \item
                                  Verwenden Sie den CTR-Modus, um die Payload mit den Zählerwerten
                                  1, 2, 3, ... zu verschlüsseln.
                            \item
                                  Verwenden Sie den CTR-Modus, um die MIC mit dem Zählerwert 0 zu
                                  verschlüsseln.
                        \end{itemize}
                  \item
                        AES-Overhead erfordert neue AP-Hardware
                  \item
                        Der AES-Overhead erfordert möglicherweise neue STA-Hardware für
                        Handheld-Geräte, aber theoretisch nicht für PCs (dies erhöht jedoch
                        die CPU-Last und den Energieverbrauch), praktisch aufgrund fehlender
                        Treiber für beide
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-aes-ccmp-frame-format.png}
    \end{itemize}


    \subsection{Vergleich WEP, TKIP und
        CCMP}

    %\begin{longtable}[]{@{}llll@{}}
    %    \toprule
    %               & WEP             & TKIP        & CCMP\tabularnewline
    %    \midrule
    %    \endhead
    %    Cipher     & RC4             & RC4         & AES\tabularnewline
    %    Key Size   & 40 or 104 bits  & 104 bits    & 128 bits encrypt, 64 bit
    %    auth.\tabularnewline
    %    Key Life   & 24-bit IV, wrap & 48-bit IV   & 48-bit IV\tabularnewline
    %    Packet Key & Concat.         & Mixing Fnc. & Not Needed\tabularnewline
    %    Integrity  &                 &             & \tabularnewline
    %    Data       & CRC-32          & Michael     & CCM\tabularnewline
    %    Header     & None            & Michael     & CCM\tabularnewline
    %    Replay     & None            & Use IV      & Use IV\tabularnewline
    %    Key Mgmt.  & None            & EAP-based   & EAP-based\tabularnewline
    %    \bottomrule
    %\end{longtable}

    TKIP ist derzeit veraltet, AES wird empfohlen.


    \section{Sicherheit von GSM- und
      UMTS-Netzen}


    \subsection{GSM-Übersicht}

    \begin{itemize}
        \item
              Die GSM-Normen:

              \begin{itemize}
                  \item
                        Akronym:

                        \begin{itemize}
                            \item
                                  früher: Groupe Spéciale Mobile (gegründet 1982)
                            \item
                                  jetzt: Globales System für mobile Kommunikation
                        \end{itemize}
                  \item
                        Gesamteuropäische Norm (ETSI)
                  \item
                        Gleichzeitige Einführung wesentlicher Dienste in drei Phasen (1991,
                        1994, 1996) durch die europäischen Telekommunikationsverwaltungen
                        (Deutschland: D1 und D2) \$\textbackslash rightarrow\$ nahtloses
                        Roaming innerhalb Europas möglich
                  \item
                        Heute nutzen viele Anbieter in der ganzen Welt GSM (mehr als 130
                        Länder in Asien, Afrika, Europa, Australien, Amerika)
              \end{itemize}
        \item
              Merkmale:

              \begin{itemize}
                  \item
                        Echte mobile, drahtlose Kommunikation mit Unterstützung für Sprache
                        und Daten
                  \item
                        Weltweite Konnektivität und internationale Mobilität mit eindeutigen
                        Adressen
                  \item
                        Sicherheitsfunktionen:

                        \begin{itemize}
                            \item
                                  Vertraulichkeit auf der Luftschnittstelle
                            \item
                                  Zugangskontrolle und Benutzerauthentifizierung
                        \end{itemize}
              \end{itemize}
        \item
              GSM bietet die folgenden Sicherheitsfunktionen {[}ETSI93a, ETSI94a{]}:

              \begin{itemize}
                  \item
                        Vertraulichkeit der Identität des Teilnehmers:

                        \begin{itemize}
                            \item
                                  Schutz vor einem Eindringling, der versucht zu identifizieren,
                                  welcher Teilnehmer eine bestimmte Ressource auf dem Funkpfad
                                  benutzt (z.B. Verkehrskanal oder Signalisierungsressourcen), indem
                                  er den Signalisierungsaustausch auf dem Funkpfad abhört
                            \item
                                  Vertraulichkeit für Signalisierungs- und Benutzerdaten
                            \item
                                  Schutz gegen die Rückverfolgung des Standorts eines Teilnehmers
                        \end{itemize}
                  \item
                        Authentifizierung der Identität des Teilnehmers: Schutz des Netzes
                        vor unbefugter Nutzung
                  \item
                        Vertraulichkeit des Signalisierungsinformations-Elements:
                        Geheimhaltung von Signalisierungsdaten auf der Funkstrecke
                  \item
                        Vertraulichkeit der Benutzerdaten: Geheimhaltung von Nutzdaten auf
                        der Funkstrecke
                  \item
                        Es werden jedoch nur Lauschangriffe auf die Funkverbindung zwischen
                        dem Mobiltelefon und den Basisstationen berücksichtigt!
              \end{itemize}
    \end{itemize}

    Einige GSM-Abkürzungen \textbar{} \textbar{} \textbar{} \textbar{}
    -\/-\/-\/-\/-\/- \textbar{}
    -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
    \textbar{} \textbar{} AuC \textbar{} Authentication center \textbar{}
    \textbar{} BSC \textbar{} Basisstations-Controller \textbar{} \textbar{}
    BTS \textbar{} Basis-Transceiver-Station \textbar{} \textbar{} IMSI
    \textbar{} Internationale mobile Teilnehmerkennung \textbar{} \textbar{}
    HLR \textbar{} Heimatstandortregister \textbar{} \textbar{} LAI
    \textbar{} Standortbereichskennung \textbar{} \textbar{} MS \textbar{}
    Mobile Station (z. B. ein Mobiltelefon) \textbar{} \textbar{} MSC
    \textbar{} Mobile Vermittlungsstelle \textbar{} \textbar{} MSISDN
    \textbar{} Mobile subscriber international ISDN number \textbar{}
    \textbar{} TMSI \textbar{} Temporäre mobile Teilnehmerkennung \textbar{}
    \textbar{} VLR \textbar{} Register für Besucherstandorte \textbar{}

    % \includegraphics{Assets/NetworkSecurity-gsm-authentication.png}

    % \includegraphics{Assets/NetworkSecurity-gsm-authentication-2.png}

    \begin{itemize}
        \item
              \$K\_i\$: Authentifizierungsschlüssel des einzelnen Teilnehmers
        \item
              \$SRES\$: Signierte Antwort
    \end{itemize}

    Der grundlegende (anfängliche) Authentifizierungsdialog:

    \begin{enumerate}
        \def\labelenumi{\arabic{enumi}.}
        \item
              \$MS \textbackslash rightarrow VLR: (IMSI\_\{MS\})\$
        \item
              \$VLR \textbackslash rightarrow AuC: (IMSI\_\{MS\})\$
        \item
              \$AuC \textbackslash rightarrow VLR: (IMSI\_\{MS\}, K\_\{BSC,MS\},
              R\_\{AUC\}, SRES\_\{AUC\})\$
        \item
              \$VLR \textbackslash rightarrow MS: (R\_\{AUC:1\})\$
        \item
              \$MS \textbackslash rightarrow VLR: (SRES\_\{AUC:1\})\$
        \item
              \$VLR \textbackslash rightarrow MS: (LAI\_1 , TMSI\_\{MS:1\})\$
    \end{enumerate}

    \begin{itemize}
        \item
              Bemerkungen:

              \begin{itemize}
                  \item
                        \$SRES\_\{AUC\} = A3(K\_\{AUC,MS\}, R\_\{AUC\});\$ A3 ist ein
                        Algorithmus
                  \item
                        \$K\_\{BSC,MS\} = A8(K\_\{AUC,MS\}, R\_\{AUC\});\$ A8 ist ein
                        Algorithmus
                  \item
                        \$R\_\{AUC\}, SRES\_\{AUC\}\$ sind Arrays mit mehreren Werten
              \end{itemize}
        \item
              Dialog zur Wiederauthentifizierung mit demselben VLR:

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$MS \textbackslash rightarrow VLR: (LAI\_1 , TMSI\_\{MS:n\})\$
                  \item
                        \$VLR \textbackslash rightarrow MS: (R\_\{AUC:i\})\$
                  \item
                        \$MS \textbackslash rightarrow VLR: (SRES\_\{AUC:i\})\$
                  \item
                        \$VLR \textbackslash rightarrow MS: (LAI\_1, TMSI\_\{MS:n+1\})\$
              \end{enumerate}
        \item
              Bemerkungen:

              \begin{itemize}
                  \item
                        Die Standortbereichskennung \$LAI\_1\$ ermöglicht die Erkennung
                        eines MS ,,coming in'' aus einem anderen Bereich
                  \item
                        Nach erfolgreicher Authentifizierung wird eine neue temporäre mobile
                        Teilnehmeridentität \$TMSI\_\{MS:n+1\}\$ zugewiesen
              \end{itemize}
        \item
              Re-Authentifizierungsdialog mit Übergabe an das neue \$VLR\_2\$:

              \begin{enumerate}
                  \def\labelenumi{\arabic{enumi}.}
                  \item
                        \$MS \textbackslash rightarrow VLR\_2: (LAI\_1, TMSI\_\{MS:n\})\$
                  \item
                        \$VLR\_2\$Rechtspfeil VLR\_1: (LAI\_1, TMSI\_\{MS:n\})\$
                  \item
                        \$VLR\_1 \textbackslash rightarrow VLR\_2: (TMSI\_\{MS:n\},
                        IMSI\_\{MS\}, K\_\{BSC,MS\}, R\_\{AUC\}, SRES\_\{AUC\})\$
                  \item
                        \$VLR\_2 \textbackslash rightarrow MS: (R\_\{AUC:i\})\$
                  \item
                        \$MS \textbackslash rightarrow VLR\_2: (SRES\_\{AUC:i\})\$
                  \item
                        \$VLR\_2 \textbackslash rightarrow MS: (LAI\_2, TMSI\_\{MS:n+1\})\$
              \end{enumerate}
        \item
              Bemerkungen:

              \begin{itemize}
                  \item
                        Nur unbenutzte \$R\_\{AUC\}, ...\$ werden an \$VLR\_2\$ übertragen
                  \item
                        Dieses Schema kann nicht verwendet werden, und es ist ein
                        Anfangsdialog erforderlich:

                        \begin{itemize}
                            \item
                                  Wenn \$TMSI\_\{MS:n\}\$ bei \$VLR\_1\$ nicht verfügbar ist, oder
                            \item
                                  wenn \$VLR\_2\$ nicht in der Lage ist, \$VLR\_1\$ zu kontaktieren
                        \end{itemize}
                  \item
                        Wenn \$VLR\_1\$ und \$VLR\_2\$ zu verschiedenen Netzbetreibern
                        gehören, kann der Handover nicht durchgeführt werden und die
                        Verbindung wird unterbrochen
              \end{itemize}
        \item
              Nur das Mobiltelefon authentifiziert sich gegenüber dem Netz
        \item
              Die Authentifizierung basiert auf einem Challenge-Response-Verfahren:

              \begin{itemize}
                  \item
                        Das AuC im Heimatnetz erzeugt Challenge-Response-Paare
                  \item
                        Der MSC/VLR im besuchten Netz prüft diese
                  \item
                        Challenge-Response-Vektoren werden ungeschützt im
                        Signalisierungsnetz übertragen
              \end{itemize}
        \item
              Die permanente Identifikation des Mobiltelefons (IMSI) wird nur dann
              über die Funkverbindung gesendet, wenn dies unvermeidlich ist:

              \begin{itemize}
                  \item
                        Dies ermöglicht einen teilweisen Schutz des Standorts.
                  \item
                        Da die IMSI manchmal im Klartext gesendet wird, ist es dennoch
                        möglich, den Standort einiger Einheiten zu erfahren
                  \item
                        Ein Angreifer könnte sich als Basisstation ausgeben und die Handys
                        ausdrücklich auffordern, ihre IMSI zu senden!
              \end{itemize}
        \item
              Grundsätzlich besteht Vertrauen zwischen allen Betreibern!
    \end{itemize}


    \subsection{General Packet Radio Service
        (GPRS)}

    \begin{itemize}
        \item
              GPRS (General Packet Radio Service, allgemeiner Paketfunkdienst):

              \begin{itemize}
                  \item
                        Datenübertragung in GSM-Netzen auf der Basis von Paketvermittlung
                  \item
                        Nutzung freier Slots der Funkkanäle nur bei sendebereiten
                        Datenpaketen (z.B. 115 kbit/s bei temporärer Nutzung von 8 Slots)
              \end{itemize}
        \item
              GPRS-Netzelemente:

              \begin{itemize}
                  \item
                        GGSN (Gateway GPRS Support Node): Interworking-Einheit zwischen GPRS
                        und PDN (Packet Data Network)
                  \item
                        SGSN (Serving GPRS Support Node): Unterstützt die MS (Standort,
                        Abrechnung, Sicherheit, entspricht im Grunde dem MSC)
                  \item
                        GR (GPRS Register): Verwaltet Benutzeradressen (entspricht HLR)
              \end{itemize}
    \end{itemize}

    (allgemeine GPRS-Beschreibung entnommen aus {[}Sch03a{]})

    % \includegraphics{Assets/NetworkSecurity-gprs-logical-architecture.png}

    % \includegraphics{Assets/NetworkSecurity-gprs-protocol-architecture.png}

    \begin{itemize}
        \item
              SNDCP: Subnetwork Dependent Convergence Protocol
        \item
              GTP: GPRS Tunnelling Protocol
    \end{itemize}

    GPRS-Sicherheit

    \begin{itemize}
        \item
              Sicherheitsziele:

              \begin{itemize}
                  \item
                        Schutz vor unbefugter Nutzung des GPRS-Dienstes (Authentifizierung)
                  \item
                        Gewährleistung der Vertraulichkeit der Benutzeridentität (temporäre
                        Identifizierung und Verschlüsselung)
                  \item
                        Gewährleistung der Vertraulichkeit von Benutzerdaten
                        (Verschlüsselung)
              \end{itemize}
        \item
              Realisierung von Sicherheitsdiensten:

              \begin{itemize}
                  \item
                        Die Authentifizierung ist grundsätzlich identisch mit der
                        GSM-Authentifizierung:

                        \begin{itemize}
                            \item
                                  SGSN ist die Peer-Entität
                            \item
                                  Zwei separate temporäre Identitäten werden für GSM/GPRS verwendet
                            \item
                                  Nach erfolgreicher Authentifizierung wird die Verschlüsselung
                                  eingeschaltet
                        \end{itemize}
                  \item
                        Die Vertraulichkeit der Benutzeridentität ist ähnlich wie bei GSM:

                        \begin{itemize}
                            \item
                                  Die meiste Zeit wird nur die Paket-TMSI (P-TMSI) über die Luft
                                  gesendet.
                            \item
                                  Optional können P-TMSI ,,Signaturen'' zwischen MS und SGSN
                                  verwendet werden, um die Re-Authentifizierung zu beschleunigen
                        \end{itemize}
                  \item
                        Die Vertraulichkeit der Benutzerdaten wird zwischen MS und SGSN
                        realisiert:

                        \begin{itemize}
                            \item
                                  Unterschied zu GSM, wo nur zwischen MS und BTS verschlüsselt wird
                            \item
                                  Die Verschlüsselung wird in der LLC-Protokollschicht realisiert
                        \end{itemize}
              \end{itemize}
    \end{itemize}

    % \includegraphics{Assets/NetworkSecurity-gprs-handover-execution.png}

    \begin{itemize}
        \item
              GPRS unterstützt ein ,,optimiertes Handover'' einschließlich
              Re-Authentifizierung (dies könnte jedoch eine Schwäche der P-TMSI
              ,,Signatur'' verhindern)
    \end{itemize}


    \subsection{UMTS Sicherheits
        Architektur}

    % \includegraphics{Assets/NetworkSecurity-umts-security-architecture.png}

    \begin{enumerate}
        \def\labelenumi{\arabic{enumi}.}
        \item
              Netzzugangssicherheit: Schutz vor Angriffen auf die Funkschnittstelle
        \item
              Sicherheit der Netzdomäne: Schutz vor Angriffen auf das drahtgebundene
              Netz
        \item
              Sicherheit der Benutzerdomäne: sicherer Zugang zu den Mobilstationen
        \item
              Sicherheit der Anwendungsdomäne: sicherer Nachrichtenaustausch für
              Anwendungen
        \item
              Sichtbarkeit und Konfigurierbarkeit der Sicherheit: Information des
              Benutzers über den sicheren Betrieb
    \end{enumerate}


    \subsubsection{Aktueller Stand der
        UMTS-Sicherheitsarchitektur}

    \begin{itemize}
        \item
              Sicherheit beim Netzzugang: Derzeit der am weitesten entwickelte Teil
              der UMTS-Sicherheit (siehe unten)
        \item
              Netzbereichssicherheit: Dieser Teil ist größtenteils noch ausbaufähig
              (in Spezifikationen bis Release 5)
        \item
              Sicherheit der Benutzerdomäne:

              \begin{itemize}
                  \item
                        Verlangt grundsätzlich, dass sich der Benutzer gegenüber seinem User
                        Services Identity Module (USIM) authentifiziert, z.B. durch Eingabe
                        einer PIN
                  \item
                        Optional kann ein Terminal die Authentifizierung des USIM verlangen.
              \end{itemize}
        \item
              Anwendungsbereichssicherheit:

              \begin{itemize}
                  \item
                        Definiert ein Sicherheitsprotokoll, das zwischen den auf dem
                        Endgerät/USIM laufenden Anwendungen und einem System im Netz
                        verwendet wird (3GPP TS 23.048)
                  \item
                        Liegt etwas außerhalb des Bereichs der Mobilfunksicherheit
              \end{itemize}
        \item
              Sichtbarkeit und Konfigurierbarkeit der Sicherheit: Definiert
              Anforderungen, damit der Benutzer die Kontrolle über die
              Sicherheitsmerkmale hat
        \item
              Im Folgenden konzentrieren wir uns auf die Netzzugangssicherheit
    \end{itemize}


    \subsubsection{UMTS-Netzzugangssicherheitsdienste}

    \begin{itemize}
        \item
              Vertraulichkeit der Benutzeridentität:

              \begin{itemize}
                  \item
                        Vertraulichkeit der Benutzeridentität: die Eigenschaft, dass die
                        permanente Benutzeridentität (IMSI) eines Benutzers, dem ein Dienst
                        bereitgestellt wird, auf der Funkzugangsverbindung nicht abgehört
                        werden kann
                  \item
                        Vertraulichkeit des Benutzerstandorts: die Eigenschaft, dass die
                        Anwesenheit oder die Ankunft eines Benutzers in einem bestimmten
                        Gebiet nicht durch Abhören der Funkzugangsverbindung ermittelt
                        werden kann
                  \item
                        Unverfolgbarkeit des Benutzers: die Eigenschaft, dass ein
                        Eindringling durch Abhören der Funkzugangsverbindung nicht ableiten
                        kann, ob verschiedene Dienste an denselben Benutzer geliefert werden
              \end{itemize}
        \item
              Authentifizierung der Entität:

              \begin{itemize}
                  \item
                        Benutzerauthentifizierung: die Eigenschaft, dass das dienende Netz
                        die Identität des Benutzers bestätigt
                  \item
                        Netzauthentifizierung: die Eigenschaft, dass der Benutzer bestätigt,
                        dass er mit einem dienenden Netz verbunden ist, das von dem HE des
                        Benutzers autorisiert ist, ihm Dienste zu liefern; dies schließt die
                        Garantie ein, dass diese Autorisierung aktuell ist.
              \end{itemize}
        \item
              Vertraulichkeit:

              \begin{itemize}
                  \item
                        Vereinbarung über den Chiffrieralgorithmus: die Eigenschaft, dass
                        der MS und der SN den Algorithmus, den sie später verwenden sollen,
                        sicher aushandeln können
                  \item
                        Chiffrierschlüssel-Vereinbarung: die Eigenschaft, dass der MS und
                        der SN sich auf einen Chiffrierschlüssel einigen, den sie später
                        verwenden können
                  \item
                        Vertraulichkeit der Nutzdaten: die Eigenschaft, dass Nutzdaten an
                        der Funkzugangsschnittstelle nicht abgehört werden können
                  \item
                        Vertraulichkeit der Signalisierungsdaten: die Eigenschaft, dass
                        Signalisierungsdaten auf der Funkzugangsschnittstelle nicht abgehört
                        werden können
              \end{itemize}
        \item
              Integrität der Daten:

              \begin{itemize}
                  \item
                        Vereinbarung eines Integritätsalgorithmus
                  \item
                        Integritätsschlüssel-Vereinbarung
                  \item
                        Datenintegrität und Ursprungsauthentifizierung von
                        Signalisierungsdaten: die Eigenschaft, dass die empfangende Einheit
                        (MS oder SN) in der Lage ist, zu überprüfen, dass
                        Signalisierungsdaten seit dem Versand durch die sendende Einheit (SN
                        oder MS) nicht auf unautorisierte Weise verändert wurden und dass
                        der Datenursprung der empfangenen Signalisierungsdaten tatsächlich
                        der behauptete ist
              \end{itemize}
    \end{itemize}

    Einige UMTS-Authentifizierungsabkürzungen

    %\begin{longtable}[]{@{}ll@{}}
    %    \toprule
    %    \endhead
    %    AK   & Anonymitätsschlüssel\tabularnewline
    %    AMF  & Authentifizierungs-Management-Feld\tabularnewline
    %    AUTN & Authentifizierungs-Token\tabularnewline
    %    AV   & Authentifizierungsvektor\tabularnewline
    %    CK   & Cipher Key\tabularnewline
    %    HE   & Heimatumgebung\tabularnewline
    %    IK   & Integritätsschlüssel\tabularnewline
    %    RAND & Zufällige Herausforderung\tabularnewline
    %%    SQN  & Sequenznummer\tabularnewline
    %    SN   & Dienendes Netzwerk\tabularnewline
    %    USIM & Benutzerdienste-Identitätsmodul\tabularnewline
    %    XRES & Erwartete Antwort\tabularnewline
    %    \bottomrule
    %\end{longtable}


    \subsubsection{Überblick über den
        UMTS-Authentifizierungsmechanismus}

    \begin{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-umts-authentication-mechanism.png}
        \item
              % \includegraphics{Assets/NetworkSecurity-umts-authentication-vectors.png}

              \begin{itemize}
                  \item
                        Der HE/AuC beginnt mit der Erzeugung einer neuen Sequenznummer SQN
                        und einer unvorhersehbaren Herausforderung RAND

                        \begin{itemize}
                            \item
                                  Für jeden Benutzer führt die HE/AuC einen Zähler \$SQN\_\{HE\}\$
                        \end{itemize}
                  \item
                        Ein Authentifizierungs- und Schlüsselverwaltungsfeld AMF ist im
                        Authentifizierungs-Token jedes Authentifizierungsvektors enthalten.
                  \item
                        Anschließend werden die folgenden Werte berechnet:

                        \begin{itemize}
                            \item
                                  ein Nachrichtenauthentifizierungscode \$MAC = f1\_K(SQN
                                  \textbar\textbar{} RAND \textbar\textbar{} AMF)\$, wobei f1 eine
                                  Nachrichtenauthentifizierungsfunktion ist
                            \item
                                  eine erwartete Antwort \$XRES = f2\_K(RAND)\$, wobei f2 eine
                                  (möglicherweise verkürzte) Nachrichtenauthentifizierungsfunktion
                                  ist
                            \item
                                  ein Chiffrierschlüssel \$CK = f3\_K(RAND)\$, wobei f3 eine
                                  Schlüsselerzeugungsfunktion ist
                            \item
                                  ein Integritätsschlüssel \$IK = f4\_K(RAND)\$, wobei f4 eine
                                  Schlüsselerzeugungsfunktion ist
                            \item
                                  ein Anonymitätsschlüssel \$AK = f5\_K(RAND)\$, wobei f5 eine
                                  Schlüsselerzeugungsfunktion ist
                        \end{itemize}
                  \item
                        Schließlich wird das Authentifizierungstoken \$AUTN = SQN
                        \textbackslash oplus AK \textbar\textbar{} AMF \textbar\textbar{}
                        MAC\$ konstruiert
              \end{itemize}
        \item
              % \includegraphics{Assets/NetworkSecurity-umts-user-authentication-usim.png}

              \begin{itemize}
                  \item
                        Nach Erhalt von RAND und AUTN berechnet das USIM:
                  \item
                        berechnet es den Anonymitätsschlüssel \$AK = f5\_K (RAND)\$
                  \item
                        ruft die Sequenznummer \$SQN = (SQN \textbackslash oplus AK)
                        \textbackslash oplus AK\$ ab
                  \item
                        errechnet \$XMAC = f1\_K (SQN \textbar\textbar{} RAND
                        \textbar\textbar{} AMF)\$ und
                  \item
                        vergleicht dies mit MAC, das in AUTN enthalten ist
                  \item
                        Wenn sie unterschiedlich sind, sendet der Benutzer die Ablehnung der
                        Benutzerauthentifizierung mit Angabe der Ursache an den VLR/SGSN
                        zurück, und der Benutzer bricht das Verfahren ab.
                  \item
                        Wenn die MAC korrekt ist, prüft das USIM, ob die empfangene
                        Sequenznummer SQN im richtigen Bereich liegt:

                        \begin{itemize}
                            \item
                                  Liegt die Sequenznummer nicht im korrekten Bereich, sendet das
                                  USIM einen Synchronisationsfehler an den VLR/SGSN zurück,
                                  einschließlich eines entsprechenden Parameters, und bricht das
                                  Verfahren ab.
                        \end{itemize}
                  \item
                        Wenn die Sequenznummer im korrekten Bereich liegt, berechnet das
                        USIM:

                        \begin{itemize}
                            \item
                                  die Authentifizierungsantwort \$RES = f2\_K(RAND)\$
                            \item
                                  den Chiffrierschlüssel \$CK = f3\_K(RAND)\$ und den
                                  Integritätsschlüssel \$IK = f4\_K(RAND)\$
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \subsubsection{Schlussfolgerungen zur Sicherheit in UMTS
        Release'99}

    \begin{itemize}
        \item
              Die Sicherheit von UMTS Release '99 ist der Sicherheit von GSM sehr
              ähnlich:

              \begin{itemize}
                  \item
                        Der Heimat-AUC generiert Challenge-Response-Vektoren
                  \item
                        Die Challenge-Response-Vektoren werden ungeschützt über das
                        Signalisierungsnetz an ein besuchtes Netz übertragen, das die
                        Authentizität eines Handys überprüfen muss.
                  \item
                        Anders als bei GSM authentifiziert sich das Netz auch gegenüber dem
                        Mobiltelefon
                  \item
                        Die IMSI, die einen Benutzer eindeutig identifiziert:

                        \begin{itemize}
                            \item
                                  wird immer noch dem besuchten Netz offenbart
                            \item
                                  kann immer noch von einem Angreifer, der sich als Basisstation
                                  ausgibt, abgefragt werden, da es in diesem Fall keine
                                  Netzauthentifizierung gibt!
                        \end{itemize}
                  \item
                        Das Sicherheitsmodell setzt weiterhin Vertrauen zwischen allen
                        Netzbetreibern voraus
                  \item
                        Vertraulichkeit ist nur auf der Funkstrecke gegeben
              \end{itemize}
        \item
              Zusammenfassend lässt sich sagen, dass UMTS Release'99 genauso sicher
              sein soll wie ein unsicheres Festnetz
    \end{itemize}


    \subsection{Sicherheit in LTE-Netzen}

    \begin{itemize}
        \item
              Eine Weiterentwicklung von UMTS, so dass viele der Sicherheitskonzepte
              gleich geblieben sind

              \begin{itemize}
                  \item
                        Das Protokoll zur Authentifizierung und Schlüsselvereinbarung (AKA)
                        ist im Wesentlichen dasselbe wie bei UMTS.
                  \item
                        Allerdings wird ein Master Key KASME abgeleitet, der dann zur
                        Ableitung von Integritäts- und Verschlüsselungsschlüsseln verwendet
                        wird
              \end{itemize}
        \item
              Bemerkenswerte Unterschiede:

              \begin{itemize}
                  \item
                        GSM-SIMs dürfen nicht mehr auf das Netz zugreifen
                  \item
                        KASUMI wird nicht mehr verwendet, stattdessen werden SNOW, AES oder
                        ZUC (ein chinesischer Stream Cipher, der für LTE entwickelt wurde)
                        eingesetzt
                  \item
                        Das zugehörige Festnetz (Evolved Packet Core genannt) ist
                        vollständig paketvermittelt und normalerweise durch IPsec und IKEv2
                        geschützt.
                  \item
                        Heim-eNBs
              \end{itemize}
        \item
              Allerdings oft neue Namen für sehr ähnliche Dinge, z.B.,

              \begin{itemize}
                  \item
                        Anstelle der TMSI wird eine Globally Unique Temporary Identity
                        (GUTI) verwendet, die aus Folgendem besteht:

                        \begin{itemize}
                            \item
                                  Einer PLMN-ID, MMEI und einer M-TMSI
                            \item
                                  Damit werden das Public Land Mobile Network (PLMN), die Mobility
                                  Management Entity (MME), vergleichbar mit der MSC in GSM/UMTS, und
                                  das mobile Gerät (M-TMSI) identifiziert
                        \end{itemize}
              \end{itemize}
    \end{itemize}


    \section{Referenzen}

    \begin{itemize}
        \item
              {[}AES01a{]} National Institute of Standards and Technology -
              Specification for the Advanced Encryption Standard (AES)
        \item
              {[}DR97a{]} J. Daemen, V. Rijmen - AES Proposal: Rijndael
              \href{http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf}{http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf}
        \item
              {[}FMS01a{]} S. Fluhrer, I. Mantin, A. Shamir - Weaknesses in the Key
              Scheduling Algorithm of RC4. Eighth Annual Workshop on Selected Areas
              in Cryptography
        \item
              {[}Riv01a{]} R. Rivest. - RSA Security Response to Weaknesses in Key
              Scheduling Algorithm of RC4.
              \href{http://www.rsa.com/rsalabs/node.asp}{http://www.rsa.com/rsalabs/node.asp}
        \item
              {[}SIR01a{]} A. Stubblefield, J. Ioannidis, A. D. Rubin. - Using the
              Fluhrer, Mantin, and Shamir Attack to Break WEP. AT\&T Labs Technical
              Report TD-4ZCPZZ
        \item
              {[}FKLS00{]} N. Ferguson, J. Kelsey, S. Lucks, B. Schneier, M. Stay,
              D.Wagner, D. Whiting - Improved cryptanalysis of Rijndael. In FSE'00,
              volume 1978 of Lecture Notes in Computer Science. Springer, 2000.
        \item
              {[}GM00{]} H. Gilbert and M. Minier - A Collision Attack on 7 Rounds
              of Rijndael. In AES Candidate Conference, 2000.
        \item
              {[}BKR11{]} A. Bogdanov, D. Khovratovich, C. Rechberger - Biclique
              cryptanalysis of the full AES. In ASIACRYPT'11, 2001.
        \item
              {[}Mir02{]} I. Mironov - (Not so) random shuffles of RC4. In Advances
              in Cryptology - CRYPTO 2002
        \item
              {[}Kle08{]} A.Klein. - Attacks on the RC4 stream cipher. In Designs,
              Codes and Cryptography
        \item
              {[}ETS12{]} ETSI/SAGE - Specification of the 3GPP confidentiality and
              integrity algorithms; Document 2: Kasumi specification
        \item
              {[}Kue01{]} U. Kühn. - Cryptanalysis of Reduced-Round MISTY. In
              Advances in Cryptology - EUROCRYPT 2001
        \item
              {[}BDN05{]} E. Biham, O. Dunkelman, N. Keller - A Related-Key
              Rectangle Attack on the Full KASUMI , In ASIACRYPT 2005
        \item
              {[}DKS10{]} O. Dunkelman, N. Keller, A. Shamir - A practical-time
              related-key attack on the KASUMI cryptosystem used in GSM and 3G
              telephony. In CRYPTO'10
        \item
              {[}ETS06{]} ETSI/SAGE - Specification of the 3GPP Confidentiality and
              Integrity Algorithms UEA2 \& UIA2. Document 2: SNOW 3G Specification
        \item
              {[}KY11{]} A. Kircanski A.M. Youssef. - On the Sliding Property of
              SNOW 3G and SNOW 2.0 IET Inf. Secur.
        \item
              {[}Amo94{]} E. G. Amorosi. - Fundamentals of Computer Security
              Technology
        \item
              {[}Cha95{]} Brent Chapman and Elizabeth Zwicky - Building Internet
              Firewalls
        \item
              {[}For94b{]} Warwick Ford. - Computer Communications Security -
              Principles, Standard Protocols and Techniques.
        \item
              {[}Gar96{]} Simson Garfinkel and Gene Spafford - Practical Internet \&
              Unix Security
        \item
              {[}Men97a{]} A. J. Menezes, P. C. Van Oorschot, S. A. Vanstone -
              Handbook of Applied Cryptography. CRC Press Series on Discrete
              Mathematics and Its Applications
        \item
              {[}SR14{]} G. Schäfer, M. Rossberg - Netzsicherheit
        \item
              {[}Sch96{]} B. Schneier - Applied Cryptography Second Edition:
              Protocols, Algorithms and Source Code in C
        \item
              {[}Sta13{]} W. Stallings - Cryptography and Network Security:
              Principles and Practice
        \item
              {[}Sti05{]} D. R. Stinson - Cryptography: Theory and Practice
              (Discrete Mathematics and Its Applications)
        \item
              {[}Bre88a{]} D. M. Bressoud. - Factorization and Primality Testing
        \item
              {[}Cor90a{]} T. H. Cormen, C. E. Leiserson, R. L. Rivest. Introduction
              to Algorithms.
        \item
              {[}DH76{]} W. Diffie, M. E. Hellman - New Directions in Cryptography
        \item
              {[}ElG85a{]} T. ElGamal - A Public Key Cryptosystem and a Signature
              Scheme based on Discrete Logarithms.
        \item
              {[}Kob87a{]} N. Koblitz - A Course in Number Theory and Cryptography
        \item
              {[}Men93a{]} A. J. Menezes - Elliptic Curve Public Key Cryptosystems.
        \item
              {[}Niv80a{]} I. Niven, H. Zuckerman - An Introduction to the Theory of
              Numbers
        \item
              {[}RSA78{]} R. Rivest, A. Shamir und L. Adleman - A Method for
              Obtaining Digital Signatures and Public Key Cryptosystems
        \item
              {[}KAFL10{]} T. Kleinjung, K. Aoki, J. Franke, A. Lenstra, E. Thomé,
              J. Bos, P. Gaudry, A. Kruppa, P. Montgomery, D. Osvik, H. Te Riele,
              A.Timofeev, P. Zimmermann - Factorization of a 768-bit RSA modulus
        \item
              {[}LM10{]} M. Lochter, J. Merkle - Elliptic Curve Cryptography (ECC)
              Brainpool Standard Curves and Curve Generation
        \item
              {[}NIST99{]} NIST - Recommended Elliptic Curves for Federal Government
              Use
        \item
              {[}NIST12{]} NIST - Recommendation for Key Management: Part 1: General
              (Revision 3)
        \item
              {[}Ko87{]} N. Koblitz - Elliptic Curve Cryptosystems
        \item
              {[}BBP12{]} B.B. Brumley, M. Barbosa, D. Page, F. Vercauteren -
              Practical realisation and elimination of an ECC-related software bug
              attack
        \item
              {[}BT11{]} B.B. Brumley, N. Tuveri - Remote timing attacks are still
              practical
        \item
              {[}BLR08{]} D. Bernstein, T. Lange, R. Rezaeian Farashahi - Binary
              Edwards Curves
        \item
              {[}NIST09{]} NIST - Digital Signature Standard (DSS)
        \item
              {[}SM09{]} A. Sorniotti, R. Molva - A provably secure secret handshake
              with dynamic controlled matching
        \item
              {[}BF03{]} D. Boneh, M. Franklin - Identity-Based Encryption from the
              Weil Pairing
        \item
              {[}Sch85{]} R. Schoof - Elliptic Curves over Finite Fields and the
              Computation of Square Roots mod p
        \item
              {[}Kra97a{]} H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing
              for Message Authentication. Internet RFC 2104, February 1997.
        \item
              {[}Mer89a{]} R. Merkle. One Way Hash Functions and DES. Proceedings of
              Crypto `89, Springer, 1989
        \item
              {[}Men97a{]} A. J. Menezes, P. C. Van Oorschot, S. A. Vanstone.
              Handbook of Applied Cryptography, CRC Press Series on Discrete
              Mathematics and Its Applications, Hardcover, 816 pages, CRC Press,
              1997
        \item
              {[}NIST02{]} National Institute of Standards and Technology (NIST).
              Secure Hash Standard. Federal Information Processing Standards
              Publication (FIPS PUB), 180-2, 2002
        \item
              {[}Riv92a{]} R. L. Rivest. The MD5 Message Digest Algorithm. Internet
              RFC 1321, April 1992
        \item
              {[}Rob96a{]} M. Robshaw. On Recent Results for MD2, MD4 and MD5. RSA
              Laboratories' Bulletin, No. 4, November 1996
        \item
              {[}WYY05a{]} X. Wang, Y. L. Yin, H. Yu. Finding collisions in the full
              SHA-1. In Advances in Cryptology - CRYPTO'05, pages 18-36, 2005
        \item
              {[}Yuv79a{]} G. Yuval. How to Swindle Rabin. Cryptologia, July 1979.
        \item
              {[}WLYF04{]} X. Wang, D. Feng, X. Lai, H. Yu. Collisions for Hash
              Functions MD4, MD5, HAVAL-128 and RIPEMD. IACR Eprint archive, 2004.
        \item
              {[}LWW05{]} A. Lenstra, X. Wang, B. de Weger. Colliding X.509
              Certificates. Cryptology ePrint Archive: Report 2005/067. 2005
        \item
              {[}LD05{]} S. Lucks, M. Daum. The Story of Alice and her Boss. In Rump
              session of Eurocrypt'05. 2005.
        \item
              {[}Kl06{]} V. Klima. Tunnels in Hash Functions: MD5 Collisions Within
              a Minute (extended abstract), Cryptology ePrint Archive: Report
              2006/105, 2006
        \item
              {[}SA09{]} Y. Sasaki, K. Aoki. Finding Preimages in Full MD5 Faster
              Than Exhaustive Search. Advances in Cryptology - EUROCRYPT'09. 2009
        \item
              {[}Man11{]} M. Manuel. Classification and Generation of Disturbance
              Vectors for Collision Attacks against SHA-1. Journal Designs, Codes
              and Cryptography. Volume 59, Issue 1-3, pages 247-263, 2011
        \item
              {[}GH04{]} H. Gilbert, H. Handschuh. Security Analysis of SHA-256 and
              Sisters. Lecture Notes in Computer Science, 2004, Volume 3006/2004,
              pages 175-193. 2004
        \item
              {[}AGM09{]} K. Aoki, J. Guo, K. Matusiewicz, V. Sasaki, L. Wang.
              Preimages for Step-Reduced SHA-2. Advances in Cryptology - ASIACRYPT
              2009. pages 578-597, 2009
        \item
              {[}KK06{]} J. Kelsey, T. Kohno. Herding Hash Functions and the
              Nostradamus Attack. Advances in Cryptology - EUROCRYPT'06. 2006
        \item
              {[}Jou04{]} A. Joux: Multicollisions in Iterated Hash Functions.
              Application to Cascaded Constructions. CRYPTO 2004: pages 306-316.
              2004
        \item
              {[}MV04{]} D. McGrew, J. Viega. The Security and Performance of the
              Galois/Counter Mode (GCM) of Operation (Full Version).
              \href{http://eprint.iacr.org/2004/193.}{http://eprint.iacr.org/2004/193.}
        \item
              {[}Fer05{]} N. Ferguson. Authentication weaknesses in GCM. 2005
        \item
              {[}Dwo07{]} M. Dworkin. Recommendation for Block Cipher Modes of
              Operation: Galois/Counter Mode (GCM) and GMAC. NIST Special
              Publication 800-38D. 2007
        \item
              {[}Saa11{]} M. Saarinen. GCM, GHASH and Weak Keys. Cryptology ePrint
              Archive, Report 2011/202,
              \href{http://eprint.iacr.org/2011/202,}{http://eprint.iacr.org/2011/202,}
              2011
        \item
              {[}BDP07{]} G. Bertoni, J. Daemen, M. Peeters, G. Van Assche. Sponge
              Functions. Ecrypt Hash Workshop 2007
        \item
              {[}BDP11a{]} G. Bertoni, J. Daemen, M. Peeters, G. Van Assche.
              Cryptographic sponge functions. Research report. Version 0.1. 2011
        \item
              {[}BDP11b{]} G. Bertoni, J. Daemen, M. Peeters, G. Van Assche. The
              Keccak reference. Research report. Version 3.0. 2011
        \item
              {[}BM92{]} BELLOVIN, S.; MERRITT, M.: Encrypted Key Exchange:
              Password-Based Protocols Secure Against Dictionary Attacks. In: IEEE
              Computer Society Symposium on Research in Security and Privacy, 1992
        \item
              {[}Bry88{]} BRYANT, R.: Designing an Authentication System: A Dialogue
              in Four Scenes. 1988. Project Athena, Massachusetts Institute of
              Technology, Cambridge, USA
        \item
              {[}GNY90{]} GONG, L.; NEEDHAM, R. M.; YAHALOM, R.: Reasoning About
              Belief in Cryptographic Protocols. In: Symposium on Research in
              Security and Privacy IEEE Computer Society, IEEE Computer Society
              Press, May 1990
        \item
              {[}KNT94{]} KOHL, J.; NEUMAN, B.; TS'O, T.: The Evolution of the
              Kerberos Authentication Service. In: BRAZIER, F.; JOHANSEN, D. (Eds):
              Distributed Open Systems, IEEE Computer Society Press, 1994
        \item
              {[}NS78{]} NEEDHAM, R. M.; SCHROEDER, M. D.: Using Encryption for
              Authentication in Large Networks of Computers. In: Communications of
              the ACM, 1978
        \item
              {[}NS87{]} NEEDHAM, R.; SCHROEDER, M.: Authentication Revisited. In:
              Operating Systems Review, 1987
        \item
              {[}NYH+05{]} NEUMAN, C.; YU, T.; HARTMAN, S. ; RAEBURN, K.: The
              Kerberos Network Authentication Service (V5)\_. 2005. - RFC 4120,
              IETF, Status: Standard,
              \href{https://tools.ietf.org/html/rfc4120}{https://tools.ietf.org/html/rfc4120}
        \item
              {[}OR87{]} OTWAY, D.; REES, O.: Efficient and Timely Mutual
              Authentication. In: Operating Systems Review, 1987
        \item
              {[}Pat97{]} PATEL, S.: Number Theoretic Attacks On Secure Password
              Schemes. In: IEEE Symposium on Security and Privacy, 1997
        \item
              {[}Sch05{]} SCHAAD, J.: Internet X.509 Public Key Infrastructure
              Certificate Request Message Format (CRMF). September 2005. - RFC 4211,
              IETF, Status: Proposed Standard,
              \href{https://tools.ietf.org/html/rfc4211}{https://tools.ietf.org/html/rfc4211}
        \item
              {[}RFC1661{]} W. Simpson. \emph{The Point-to-Point Protocol (PPP).}
              RFC 1661, 1994.
        \item
              {[}RFC1968{]} G. Meyer. \emph{The PPP Encryption Control Protocol
                  (ECP).} RFC 1968, 1996.
        \item
              {[}RFC1994{]} W. Simpson. \emph{PPP Challenge Handshake Authentication
                  Protocol (CHAP).} RFC 1994 (obsoletes RFC 1334), 1996.
        \item
              {[}RFC2284{]} L. Blunk, J. Vollbrecht. \emph{PPP Extensible
                  Authentication Protocol (EAP).} RFC 2284, 1998.
        \item
              {[}RFC2289{]} N. Haller, C. Metz, P. Nesser, M. Straw. \emph{A
                  One-Time Password System.} RFC 2289, 1998.
        \item
              {[}RFC2341{]} A. Valencia, M. Littlewood, T. Kolar. \emph{Cisco Layer
                  Two Forwarding Protocol (L2F).} RFC 2341, 1998.
        \item
              {[}RFC2419{]} K. Sklower, G. Meyer. \emph{The PPP DES Encryption
                  Protocol, Version 2 (DESE-bis).} RFC 2419 (obsoletes RFC 1969), 1998.
        \item
              {[}RFC2420{]} H. Kummert. \emph{The PPP Triple-DES Encryption Protocol
                  (3DESE).} RFC 2420, 1998.
        \item
              {[}RFC2433{]} G. Zorn, S. Cobb. \emph{Microsoft PPP CHAP Extensions.}
              RFC 2433, 1998.
        \item
              {[}RFC2637{]} K. Hamzeh, G. Pall , W. Verthein, J. Taarud, W. Little,
              G. Zorn. \emph{Point-to-Point Tunneling Protocol (PPTP).} RFC 2637,
              1999.
        \item
              {[}RFC2661{]} W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
              B. Palter. \emph{Layer Two Tunneling Protocol (L2TP).} RFC 2661, 1999.
        \item
              {[}RFC2828{]} R. Shirey. \emph{Internet Security Glossary.} RFC 2828,
              2000.
        \item
              {[}RFC3078{]} G. Pall, G. Zorn. \emph{Microsoft Point to Point
                  Encryption Protocol (MPPE).} RFC 3078, 2001.
        \item
              {[}SM98a{]} B. Schneier, Mudge. \emph{Cryptanalysis of Microsoft's
                  Point-to-Point Tunneling Protocol (PPTP).} Proceedings of the 5th ACM
              Conference on Communications and Computer Security, ACM Press, 1998.
        \item
              {[}SMW99a{]} B. Schneier, Mudge, D. Wagner. \emph{Cryptanalysis of
                  Microsoft's PPTP Authentication Extensions (MSCHAPv2).} Counterpane
              Systems, 1999.
        \item
              {[}FH98a{]} P. Ferguson, G. Huston. \emph{What is a VPN?} The Internet
              Protocol Journal, Cisco Systems. 1998.
        \item
              {[}ATM99a{]} ATM Forum. \emph{ATM Security Specification Version 1.0.}
              AF-SEC-0100.000,
        \item
              {[}RFC2401{]} R. Atkinson, S. Kent. Security Architecture for the
              Internet Protocol. RFC 2401, Internet Engineering Taskforce (IETF),
              1998.
        \item
              {[}RFC2402{]} R. Atkinson, S. Kent. IP Authentication Header (AH). RFC
              2402, IETF, 1998. {[}RFC2403{]} C. Madson, R. Glenn. The Use of
              HMAC-MD5-96 within ESP and AH. RFC 2403, IETF, 1998.
        \item
              {[}RFC2404{]} C. Madson, R. Glenn. The Use of HMAC-SHA-1-96 within ESP
              and AH. RFC 2404, IETF, 1998.
        \item
              {[}RFC2405{]} C. Madson, N. Doraswami. The ESP DES-CBC Cipher
              Algorithm With Explicit IV. RFC 2405, IETF, 1998.
        \item
              {[}RFC2406{]} R. Atkinson, S. Kent. IP Encapsulating Security Payload
              (ESP). RFC 2406, IETF, 1998.
        \item
              {[}RFC2407{]} D. Piper. The Internet IP Security Domain of
              Interpretation for ISAKMP. RFC 2407, IETF, 1998.
        \item
              {[}RFC2408{]} D. Maughan, M. Schertler, M. Schneider, J. Turner.
              Internet Security Association and Key Management Protocol (ISAKMP).
              RFC 2408, - IETF, 1998.
        \item
              {[}RFC2409{]} D. Harkins, D. Carrel. The Internet Key Exchange (IKE).
              RFC 2409, IETF, 1998.
        \item
              {[}RFC2857{]} A. Keromytis, N. Provos. The Use of HMAC-RIPEMD-160-96
              within ESP and AH. RFC 2857, IETF, 2000.
        \item
              {[}RFC3947{]} T. Kivinen, B. Swander, A. Huttunen, V. Volpe:
              \emph{Negotiation of NAT-Traversal in the IKE.} RFC 3947, IETF, 2005.
        \item
              {[}RFC3948{]} A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M.
              Stenberg: \emph{UDP Encapsulation of IPsec ESP Packets.} RFC 3948,
              IETF, 2005.
        \item
              {[}RFC4306{]} C. Kaufman: \emph{Internet Key Exchange (IKEv2)
                  Protocol.} RFC 4306, Internet Engineering Taskforce (IETF), 2005.
        \item
              {[}NiMe08{]} P. Nikander, J. Melen: \emph{A Bound End-to-End Tunnel
                  (BEET) mode for ESP.} Internet-Draft, IETF Network Working Group,
              2008.
        \item
              {[}Bhai08{]} Y. Bhaiji: \emph{Network Security Technologies and
                  Solutions} , Cisco Press, 2008.
        \item
              {[}Fluh01{]} S. Fluhrer: \emph{Tunnel Endpoint Discovery.} Expired
              Internet-Draft, IETF IPSP Working Group, 2001.
        \item
              {[}Tran06{]} T.H. Tran: \emph{Proactive Multicast-Based IPSEC
                  Discovery Protocol and Multicast Extension.} Military Communications
              Conference, 2006.
        \item
              {[}FBJW08{]} R. Figueiredo, P. O. Boykin, P. St. Juste, D. Wolinsky:
              \emph{Social VPNs: Integrating Overlay and Social Networks for
                  Seamless P2P Networking'.} IEEE WETICE/COPS, 2008.
        \item
              {[}RSS10{]} M. Rossberg, T. Strufe, G. Schaefer: \emph{Distributed
                  Automatic Configuration of Complex IPsec-Infrastructures.} Journal of
              Network and Systems Management, Volume 18, Issue 3, 2010.
        \item
              {[}RSSM09{]} M. Rossberg, W. Steudel, G.Schaefer, M. Martius:
              \emph{Eine Software-Architektur zur Konstruktion flexibler
                  IPsec-Infrastrukturen.} BSI 11. Deutscher IT-Sicherheitskongress,
              2009.
        \item
              {[}BKS98a{]} D. Bleichenbacher, B. Kaliski, J. Staddon. \emph{Recent
                  Results on PKCS \#1: RSA Encryption Standard.} RSA Laboratories'
              Bulletin 7, 1998
        \item
              {[}Cop96a{]} D. Coppersmith, M. K. Franklin, J. Patarin, M. K. Reiter.
              \emph{Low Exponent RSA with Related Messages.} In Advance in
              Cryptology -\/- Eurocrypt'96, U. Maurer, Ed., vol. 1070 of Lectures
              Notes in Computer Science, Springer-Verlag, 1996
        \item
              {[}FKK96a{]} A. O. Freier, P. Karlton, P. C. Kocher. \emph{The SSL
                  Protocol Version 3.0.} Netscape Communications Corporation, 1996
        \item
              {[}DA99{]} T. Dierks, C. Allen. \emph{The TLS Protocol Version 1.0.}
              RFC 2246, 1999
        \item
              {[}DR08{]} T. Dierks, E. Rescorla. \emph{The Transport Layer Security
                  (TLS) Protocol Version 1.2.} RFC 5246, 2008
        \item
              {[}RD10{]} J. Rizzo, T. Duong, Practical Padding Oracle Attacks, 4th
              USENIX conference on Offensive technologies (WOOT), 2010
        \item
              {[}RRDO10{]} E. Rescorla, M. Ray, S. Dispensa, N. Oskov.
              \emph{Transport Layer Security (TLS) Renegotiation Indication
                  Extension} , RFC 5746. 2010
        \item
              {[}Zo11{]} T. Zoller. \emph{TLS \& SSLv3 renegotiation vulnerability.}
              Technical report, G-SEC. 2011
        \item
              {[}RM12{]} E. Rescorla, N. Modadugu. \emph{Datagram Transport Layer
                  Security Version 1.2.} RFC 6347, 2012
        \item
              {[}LL06{]} S. Lehtinen, C. Lonvick. \emph{The Secure Shell (SSH)
                  Protocol Assigned Numbers.} RFC 4250, 2006
        \item
              {[}YL06a{]} T. Ylonen, C. Lonvick. \emph{The Secure Shell (SSH)
                  Protocol Architecture.} RFC 4251, 2006
        \item
              {[}YL06b{]} T. Ylonen, C. Lonvick. \emph{The Secure Shell (SSH)
                  Authentication Protocol.} RFC 4252, 2006 -{[}YL06c{]} T. Ylonen, C.
              Lonvick. \emph{The Secure Shell (SSH) Transport Layer Protocol} , RFC
              4253, 2006 -{[}YL06d{]} T. Ylonen, C. Lonvick. \emph{The Secure Shell
                  (SSH) Connection Protocol.} RFC 4254, 2006 -{[}SG09{]} D. Stebila, J.
              Green. \emph{Elliptic Curve Algorithm Integration in the Secure Shell
                  Transport Layer} , RFC 5656. 2009 -{[}IS09{]} K. Igoe, J. Solinas.
              \emph{AES Galois Counter Mode for the Secure Shell Transport Layer
                  Protocol.} RFC 5647. 2009
        \item
              {[}Müller99a{]} G. Müller, K. Rannenberg (Ed.). \emph{Multilateral
                  Security in Communications.} Addison-Wesley-Longman, 1999
        \item
              {[}BGW01a{]} N. Borisov, I. Goldberg, D. Wagner. Intercepting Mobile
              Communications: The Insecurity of 802.11. 7th ACM SIGMOBILE Annual
              International Conference on Mobile Computing and Networking (MOBICOM),
              Rome, Italy, July 2001
        \item
              {[}FMS01a{]} S. Fluhrer, I. Mantin, A. Shamir. Weaknesses in the Key
              Scheduling Algorithm of RC4. Eighth Annual Workshop on Selected Areas
              in Cryptography, August 2001 {[}IEEE12{]} IEEE. Wireless LAN Medium
              Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE Std
              802.11-2012, The Institute of Electrical and Electronics Engineers
              (IEEE), 2012
        \item
              {[}Riv01a{]} R. Rivest. RSA Security Response to Weaknesses in Key
              Scheduling Algorithm of RC4.
              \href{http://www.rsa.com/rsalabs/technotes/wep.html}{http://www.rsa.com/rsalabs/technotes/wep.html},
              2001
        \item
              {[}SIR01a{]} A. Stubblefield, J. Ioannidis, A. D. Rubin. Using the
              Fluhrer, Mantin, and Shamir Attack to Break WEP. AT\&T Labs Technical
              Report TD-4ZCPZZ, August 2001
        \item
              {[}TWP07{]} E. Tews, R. P. Weinmann, A. Pyshkin. Breaking 104 bit WEP
              in less than 60 seconds. Information Security Applications, 188-202,
              2007
        \item
              {[}WM02a{]} N. C. Winget, T. Moore, D. Stanley, J. Walker. IEEE
              802.11i Overview. NIST 802.11 Wireless LAN Security Workshop, Falls
              Church, Virginia, December 4-5, 2002
        \item
              {[}RFC2898{]}B. Kaliski. PKCS \#5: Password-Based Cryptography
              Specification Version 2.0. IETF Request for Comments 2898, 2000
        \item
              {[}RFC3394{]}J. Schaad, R. Housley. Advanced Encryption Standard (AES)
              Key Wrap Algorithm. IETF Request for Comments 3394, 2002
        \item
              {[}3GPP00a{]} 3GPP. 3G Security: Security Architecture (Release 1999).
              3rd Generation Partnership Project, Technical Specification Group
              Services and System Aspects, 2000
        \item
              {[}3GPP02a{]} 3GPP. 3G Security: Security Architecture (Release 5),
              2002
        \item
              {[}3GPP02b{]} 3GPP. Security Mechanisms for the (U)SIM application
              toolkit, December 2002
        \item
              {[}ETSI93a{]} ETSI TC-GSM. GSM Security Aspects (GSM 02.09).
              Recommendation GSM, European Telecommunications Standards Institute
              (ETSI), 1993
        \item
              {[}ETSI94a{]} ETSI TC-SMG. European Digital Cellular
              Telecommunications System (Phase 2): Security Related Network
              Functions (GSM 03.20). ETS 300 534, European Telecommunications
              Standards Institute (ETSI), 1994
        \item
              {[}Les02a{]} Lescuyer, P. UMTS -- Grundlagen, Architektur und
              Standard. dpunkt.verlag, 2002
        \item
              {[}Sch03a{]} J. Schiller. Mobile Communications - The Course.
              \href{http://www.inf.fu-berlin.de/inst/ag-tech/resources/mobilecommunications.htm}{http://www.inf.fu-berlin.de/inst/ag-tech/resources/mobilecommunications.htm}
        \item
              {[}Sch03b{]} J. Schiller. Mobile Communications. second edition,
              Addison-Wesley, 2003
    \end{itemize}

\end{multicols}
\end{document}