wieerwill/Informatik
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
8f91648e0b
Informatik/Network Security - Cheatsheet.tex
wieerwill e7f54fa9fa md to tex
2022-02-04 11:18:04 +01:00

17288 lines
769 KiB
TeX
Raw Blame History

\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}
Reference in New Issue View Git Blame Copy Permalink