Kryptographie und Zugriffskontrolle - Sicherheit in Netzwerken

Sicherheit in Netzwerken

IPSec

Das IP Security Protocol (IPSec) ist eines der beliebtesten Protokolle um VPN Verbindungen aufzubauen. IPSec wurde von der IETF entwickelt und ist in RFC 4301 standardisiert . IPSec arbeitet auf Ebene der Netzwerkschicht des OSI-Modells und hat somit den Vorteil, dass es somit transparent für höhere Schichten ist. IPSec beinhaltet einige andere Protokolle, wie

• dem IKE Protokoll für den Schlüsselaustausch,
• dem ESP Protokoll für den verschlüsselten und integren Datenverkehr, sowie
• dem AH Protokoll für den authentifizierten Datenverkehr.

IPSec kann in zwei Varianten eingesetzt werden . Erstens, den Transport Mode, bei welchem nur die Nutzdaten verschlüsselt werden. Dieser Modus kommt heutzutage praktisch kaum zur Anwendung und ist für Peer-to-Peer Kommunikation gedacht. Zweitens, den Tunnel Mode, bei welchem sämtliche Nutzdaten inklusive Verkehrsdaten verschlüsselt werden. Dies bietet ein höheres Maß an Sicherheit benötigt allerdings auch mehr Rechenleistung. Im Tunnel Mode werden die ursprünglichen IP-Header in ein neues IP Paket eingekapselt. Die neuen IP Header beinhalten die IP Adressen der Gateways welche den IPSec Tunnel aufbauen. Dies hat den Vorteil, dass die original IP Adressen während des Transports über den Tunnel verschlüsselt sind.

IPSec-Header nach

IP-Header	IPSec-Header	Data

Welches Verschlüsselungsverfahren und Schlüssel für einen IPSec Tunnel verwendet werden, wird in der sogenannten Security Association (SA) gespeichert. So beinhaltet eine SA die Parameter der IPSec Verbindung zwischen zwei oder mehreren Gateways. Jedes Gateway speichert sein SAs in einer Datenbank, der Security Association Database (SAD). IPSec Verbindungen sind unidirektional, deswegen werden für ein kommende und ausgehende Verbindungen jeweils eine eigene SAD geführt. Für die eindeutige Identifizierung einer Verbindung wird ein 32-Bit Wert, der Security Parameter Index (SPI) sowie der IP Adresse der Gegenstelle verwendend. Diese werden im IPSec Header mitgeschickt. In der Security Policy Database (SPD) werden zudem Strategien festgelegt, wie mit ein und ausgehenden IPSec Paket umgegangen werden soll. Zum Beispiel, ob IPSec angewendet werden soll, das Paket verworfen werden soll, oder ob es ohne weitere Sicherheitsüberprüfungen weitergeleitet werden soll.

Architektur von IPSec aus [17]

Internet Key Exchange Protocol

Das IKE Protokoll basiert auf dem Internet Security Association Key Management Protocol (ISAKMP) , einem Framework um SAs einzurichten, zu verhandeln und zu löschen. Die Funktionsweise von IKE ist in Abbildung 1.2 dargestellt. Die Aushandlung einer SA nach IKE erfolgt in 2 Phasen :

IKE Funktionsweise aus [1]

1. In der Phase 1 wird eine Verbindung zum Kommunikationspartner mittels der Diffie-Hellman Schlüsselaustausch Protokoll durchgeführt, siehe dazu [DH]. Diese Phase wird auch als Main Mode bezeichnet. Mit DH wird über Cookies ein secret ausverhandelt mit welchem die weitere IKE Kommunikation verschlüsselt wird. Die Authentifizierung der beiden IPSec Gegenstellen, kann über einen preshared key, einem Zertifikat oder Public Key Encryption erfolgen. Durch diesen Vorgang wird ein einzelner SA generiert und gespeichert.
2. In der Phase 2 wird verschlüsselt über die IPSec Security Parameter, wie verwendete Algorithmen, Time-Outs, etc. verhandelt. Die Phase 2 wird auch als Quick Mode bezeichnet. In dieser tauschen sich beide Gegenstellen über ihre unterstützten Verschlüsselungsverfahren, Hashalgorithmen und Authentifizierungsmethoden aus. Im sogenannten Aggressive Mode, wird direkt die Krypto-Suite ausgewählt. Falls die Verbindung fehl schlägt besteht allerdings keine Möglichkeit zu erkennen welche Verfahren die Gegenstelle überhaupt anbietet. Nach Abschluss der Phase 2 werden mindestens 2 SAs (eingehend und ausgehend) erzeugt.

Authentication Header Protocol

Das Authentication Header Protokoll (AH) bietet eine transparente Überprüfung des Datenursprungs sowie des Datenpakets an . Daher kann mittels AH die Authentizität des Absenders und die Integrität der Daten überprüft werden. Optional ist eine Erkennung und Unterbindung von Replays möglich. Die Verschlüsselung der Daten ist nicht Aufgabe von AH, sondern von ESP, siehe Kapitel 1.1.3. Das AH Protokoll verwendet zur Überprüfung der Datenintegrität Message Authentication Codes, siehe dazu Kapitel [MAC]. Die dafür benötigten Informationen werden in jedem einzelnen IP Paket im Authentication Header, welcher ein Attribut des IPSec Headers darstellt, übermittelt. Der AH Header ist in Tabelle 1.2 dargestellt.

AH-Header nach

Next Header	AH Length	Reserved
Security Parameter Index (SPI)
Sequence Number
Authentication Data (MAC)

Der Next Header spezifiziert das nächste Paket. So kann eine Reihenfolge sichergestellt werden. Im Feld AH Length wird die Länge des AH Headers angegeben. Das Feld Reserved ist für zukünftige Verwendung reserviert, daher muss dieses Feld eine 0 enthalten. Der Security Parameter Index dient, wie im Kapitel 1.1 beschrieben zur Identifizierung der Security Association. Die Sequence Number ist optional und dient der Erkennung von Replays. Die Sequenznummer wird monoton inkrementiert. Im Feld Authentication Data befindet sich der über das gesamte Paket berechnete MAC Wert. Der Empfänger kann den MAC ebenfalls berechnen und kann, falls dieser nicht übereinstimmt, dieses Paket verwerfen.

Encapsulating Security Payload - Protocol

Zu den Eigenschaften des AH - Protokolls bietet das Encapsulating Security Payload (ESP) - Protokoll zusätzlich eine Verschlüsselung der Daten an. Der RFC 4303 beschreibt zwei Modi, entweder die Verschlüsselung des reinen Payloads (ohne Verkehrsdaten im Transport Mode) und zweitens die gesamte Verschlüsselung des IP Pakets im Tunnel Mode.

ESP-Format nach

Security Parameter Index (SPI)
Sequence Number
ESP Payload Data
Padding	Padding Length	Next Header
ESP Authentication Data

Ein ESP - Paket ist ähnlich dem AH - Paket aufgebaut. Er enthält einen SPI für die Identifizierung der Security Association und eine Sequenznummer. Diese beiden Teile des Headers, sowie ein Teil des ESP Authentication Data (ESP-Trailer) sind unverschlüsselt um eine Zuordnung zu ermöglichen. Der ESP - Trailer enthält den MAC Wert, um eine Überprüfung der Integrität zu ermöglichen.

SSL/TLS

Secure Socket Layer (SSL) und dessen Nachfolger das Transport Layer Security (TLS) Protokoll bieten eine Ende zu Ende Verschlüsselung an und hat sich zum Standard vor allem im Bereich der sicheren HTTP - Verbindungen, dem HTTPS - Protokoll, etabliert . SSL und TLS kann natürlich auch für andere auf TCP/IP basierende Dienste verwendet werden, wie zum Beispiel Telnet oder FTP. SSL/TLS arbeitet auf Ebene der Transportschicht des OSI Modells. Die Protokoll - Familie verwendet asymmetrische Verfahren (siehe Kapitel [asymmetrischeVerfahren]), sowie Zertifikate (siehe Kapitel [certificates]), um die Authentifikation der Kommunikationsteilnehmer durchzuführen. Es wird somit über ein asymmetrisches Verfahren eine gemeinsamer Schlüssel bestimmt, der für die weitere symmetrische Verschlüsselung verwendet wird. Die Integrität der ausgetauschten Pakte werden mittels Message Authentication Codes (siehe Kapitel [MAC]) sichergestellt.

Historie der SSL / TLS Versionen nach

1994	SSL v2	Netscape entwickelt die erste Version von SSL
1995	SSL v3	Wegen schwerer Sicherheitslücken von SSL v2 wird SSL v3 veröffentlicht (siehe RFC 6101)
1999	TLS v1.0	Die IETF standardisiert TLS v1.0, welches fast ident mit SSL v3 ist (siehe RFC 2246)
2006	TLS v1.1	Eine neue Version des TLS Protokolls wird aufgrund der BEAST Attacke veröffentlicht (siehe RFC 4346)
2008	TLS v1.2	In dieser TLS Version wird die Unterstützung für Stream und Block Verschlüsselungen entfernt, welche eine große Angriffsfläche bieten (siehe RFC 5246).
2013	TLS v1.3	Die Arbeit an Version 1.3 von TLS wurde begonnen.

SSL/TLS ist ein zustandsbehaftetes Protkoll und besteht aus zwei Bestandteilen, dem Record Protocol und dem Handshake Protocol, welche in den folgenden Kapiteln beschrieben werden.

Handshake Protocol

Das Handshake Protocol ist in RFC 5246 Section 7.3 definiert . Das Handshake Protocol hat die Aufgabe nach Verbindungseröffnung zwischen Client und Server die Verschlüsselungs - Parameter auszuhandeln.

vereinfachter Vorgang des SSL/TLS Handshakes aus [15]

Funktionsweise:

1. Der Client schickt im Klartext ein ClientHello an den Server. Dieses Hello enthält die kryptographischen Möglichkeiten des Clients, daher werden die höchste vom Client unterstützte Protokoll Version, eine Session ID, eine Liste von unterstützten Cipher Suiten, eine Liste der unterstützten Kompressions Methoden und ein zufällig generierter Wert, das ClientHello.random, an den Server gesendet.
2. Der Server schickt im Fehlerfall ein Handshake Failure und ansonsten ein ServerHello an den Client zurück. Das Hello besteht aus der Protokoll Version in Form der höchst möglichen unterstützten Version von Server und Client. Der Server sendet ebenfalls eine Session ID, eine ausgewählte Cipher Suite und Kompressions Methode aus der Liste des Clients, sowie einem ebenfalls zufällig und unabhängigen Zufallswert, dem ServerHello.random.
3. Nachdem der Server sein Hello gesendet hat, schickt dieser sein Zertifikat (normalerweise ein X.509 Zertifikat, siehe Kapitel [x509]) zur Authentifizierung an den Client. Falls der Server ein Client-Zertifikat zur Authentifizierung benötigt, schickt er einen entsprechenden Request an den diesen. Danach schickt der Server eine Server Hello Done Nachricht an den Client.
4. Der Client überprüft das erhaltene Server Zertifikat und die vom Server ausgewählten Verfahren. Sind die erhaltenen Daten korrekt, sendet der Client die sogenannte ClientKeyExchange Message an den Server. Diese enthält das PreMasterSecret, welches mit dem öffentlichen Schlüssel des Servers verschlüsselt wird. Das PreMasterSecret und die beiden Zufallswerte ClientHello.random und ServerHello.random werden von Client und Server dazu verwendet das MasterSecret zu berechnen. Dieses dient in weiterer Folge als Initialisierungswert für die Schlüsselerzeugung . Wurde vom Server ein Client-Zertifikat angefragt, sendet der Client zudem das Zertifikat oder generiert eine no certificate Fehlermeldung. Ausserdem sendet der Client ein ChangeCipherSpec Nachricht an den Server. Mit dieser wird die verwendete Cipher Suite bestätigt oder der Beginn einer neuen Methode angekündigt . Zum Abschluss sendet der Client noch eine Finished Meldung an den Server, welche mit einem MAC mithilfe des Master Secrets verschlüsselt wurde.
5. Der Server sendet seinerseits eine ChangeCipherSpec Nachricht an den Client und das Handshake wird mit einer Finish Nachricht des Servers, wieder mit MAC und dem Master Secret verschlüsselt, abgeschlossen. Wenn die MACs der Finished Nachrichten auf beiden Seien übereinstimmen handelt es sich um eine akzeptierte Verbindung und der Austausch von Daten über das Record Protocol kann erfolgen.

Record Protocol

Die Aufgabe des Record Protokolls ist es Datenpakete aus dem Application Layer in sogenannte Records zu fragmentieren und wenn nötig zu komprimieren. Vom Record Protokoll werden zu den Daten werden entsprechende MAC - Hashwerte gebildet und MAC und Daten verschlüsselt. Die Generierung der MAC Schlüssel erfolgt dabei aus dem Master Secret. Dem verschlüsselten Paket wird ein Record Header vorangestellt und an den Transport Layer weitergegeben.

Operationen des Record Protocols aus [17]

Pretty Good Privacy und Web of Trust

Die Software Pretty Good Privacy (PGP) wurde 1991 von Phil Zimmerman entwickelt und stellt ein Möglichkeit bereit E-Mails und auch Dateien verschlüsselt und/oder signiert auszutauschen . PGP wurde 1998 als OpenPGP in RFC 2440 beziehungsweise RFC 4880 standardisiert und steht frei zum Download zur Verfügung. PGP verwendet für den Austausch eines symmetrischen Schlüssels das RSA beziehungsweise das DH Verfahren ein. Die Verschlüsselung des Plaintextes erfolgt dann symmetrisch mit dem ausgetauschten Schlüssel. Bei Verwendung einer digitalen Signatur wird die Integrität der Daten durch die Verwendung von HMACs sichergestellt. Für die Erstellung einer Signatur wird RSA als auch DSS unterstützt, siehe Kapitel [MAC].

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: BCPG C# v1.6.1.0

mQENBFkugDwBCADpjpRFnZndFGTE8inJ3irjh0McKaTwE8isZR2mRC3SwkbeGdek
Z3N2XCGenu5PFCnB1h0UMXs/wZK1pHeyruHT4U9fwO9Z/R1B3Il0V0x4DAsqTnGh
gO7NeRQjjjqjaZvZvALrAVHZcDcrwwDk3yfBz9ci+pnbOiYsLbsIxgf8+PuAGXcI
r7tqnV97LYyXynIpEVnLqrZ7Bya3/RPF1dBw1z2HoKzYgrYu9iluTdUJ/2kp1PEc
ykYa2Sb+jdR4+VbcpcfPmY7PE94AguvF9nCkRHIMuh3x/NStYCjut2tHrwbvZPsl
wb2q6HCh2eEHq1MWcD2rJIzBgeQu8nWot5E5ABEBAAG0E3Rob21hc0BzZWN1LnJp
dHkuYXSJARwEEAECAAYFAlkugDwACgkQSd9y7Kp+Xwm3rwgAzW9fLdYtr98rsZ4L
o3wn7LzFjJx0nc2gaCfL6LRCZHk+H/SNlHUfDEb0WIrdPTgziPIdNolszFyG1Vcm
WqNlPx7uBB9hGVzAAC7sNvm98Xr7bR217XCO1pva//bLC1zFxe43LTentLr3RhdX
Ot0ArClhsd9HpyZik9CoInlRaYr3fsLXRFAcWOt0b+2KluRpaIAEKTJ1YORmY4RE
fG3/ejtPwd8WtMu1q+Zc43O/Cma5/Z5qfVhlgaR68gcAbcznmbvVLVTeholSpPrA
/S8W5W88dzB6iyX5TI2ssv2hm25/+wfiDhRq7bnwOwBJVdvk85bKLFALlu9VfhYj
Z2LYQw==
=hEHq
-----END PGP PUBLIC KEY BLOCK-----

Bei PGP wird eine Person über dessen Schlüssel ID und den Public Key, welche gewöhnlicherweise mit einer E-Mail Adresse verknüpft sind, identifiziert. Ein Beispiel eines Public Keys ist in Listing [lst: pgp] dargestellt. PGP speichert die eigenen Private Keys verschlüsselt in einer Datei ab, dem sogenannten Private-Key-Ring. Bei PGP ist es möglich mehrere asymmetrische Schlüsselpaare zu verwenden. Durch die Eingabe eines gesetzten Passwortes wird der Benutzer als Eigentümer des Private Keys authentifiziert. In einer weiteren Datei, dem Public-Key-Ring, werden zudem die öffentlichen Schlüssel der Empfänger und der eigene gespeichert.

Funktionsweise:

1. Alice möchte Bob eine mit PGP verschlüsselte E-Mail zukommen lassen. Sie generiert mit PGP einen symmetrischen Schlüssel ${\textstyle K}$. Dafür verwendet PGP einen Pseudozufallszahlen - Generator.
2. Alice generiert über PGP einen Hashwert von ${\textstyle M}$ und signiert diesen mit ihrem Private Key und hängt diesen an ${\textstyle M}$ an.
3. Alice verschlüsselt die Nachricht ${\textstyle M}$ (welche auch den Hashwert enthält) mittels dem ausgewählten symmetrischen Verfahren und dem generierten Schlüssel. ${\textstyle K}$ ist ein Sitzungsschlüssel und nur für diese Kommunikation gültig.
   $$C_{1}=EncSymm(M,K)$$
4. Der Schlüssel ${\textstyle K}$ wird mit dem Public Key des Empfängers, also mit dem öffentlichen Schlüssel von Bob ${\textstyle K_{E}^{B}}$, mit dem RSA Verfahren verschlüsselt.
   $$C_{2}=EncAsym(K,K_{E}^{B})$$
5. Alice schickt ${\textstyle C_{1}}$ und ${\textstyle C_{2}}$ an Bob.
6. Bob benötigt für die Entschlüsselung seinen privaten Schlüssel ${\textstyle K_{B}^{D}}$. Dieser ist in PGP verschlüsselt abgelegt und Bob muss sich vor dessen Verwendung authentifizieren.
7. Nach erfolgreicher Authentifizierung kann Bob zuerst ${\textstyle C_{1}}$ entschlüsseln und erhält den Sitzungschlüssel ${\textstyle K}$.
8. Mit dem erhaltenem Schlüssel ${\textstyle K}$ kann Bob dann ${\textstyle C_{2}}$ entschlüsseln und erhält die Nachricht ${\textstyle M}$. Bob kann nun die eigentliche Nachricht ${\textstyle M}$ vom beigefügten Hashwert trennen. Er generiert sich nun selbst den Hashwert von ${\textstyle M}$ und kann beide Hashwerte vergleichen. Sind beide ident, kann er sich sicher sein, dass er die korrekte Nachricht erhalten hat. Dadurch dass der Hashwert von Alice signiert wurde, kann Bob mittels des öffentlichen Schlüssels von Alice auch überprüfen, ob dieser auch tatsächliche von Alice geschickt wurde.

PGP verwendet im Gegensatz zu hierarchischen Zertifikats - basierten Systemen eine dezentrale Struktur, die Web of Trust genannt wird. Um Vertrauen zu einem Public Key aufbauen zu können, können öffentliche Schlüssel von anderen signiert werden. Damit wird dem Besitzer des Public Keys vertraut (Owner Trust). So können Vertrauenspfade gebildet werden - zum Beispiel A vertraut B, B vertraut C, also kann A auch C vertrauen. Um die Vertrauenswürdigkeit eines Public Keys überprüfen zu können werden der Owner Trust und die Vertrauenswürdigkeit der Signatoren (Signatory Trust) im Attribut Key Legitimation Field (KLF) addiert. Die öffentlichen Schlüssel können auf Keyservern hochgeladen und für andere hinterlegt werden. Sie sind dann über ihre Schlüssel ID auffindbar.

Secure MIME

Secure MIME oder S/MIME erweitert den Multipurpose Internet Mail Extension (MIME) Standard um Sicherheitsfunktionen . Durch MIME wird das Datenformat von E-Mail Anhängen definiert. S/MIME ermöglicht zudem verschlüsselte und/oder digital signierte E-Mails zu verschicken. S/MIME ist in RFC 5751 spezifiziert und bietet Authentifizierung, Nachrichten Integrität, Nicht-Abstreitbarkeit des Ursprungs und Verschlüsselung der Daten für E-Mails an. Dafür wird einerseits ein asymmetrisches Verfahren, wie RSA verwendet und anderseits ein Signaturalgorithmus wie DSA eingesetzt. S/MIME ist vom Ablauf sehr ähnlich zu PGP, allerdings setzt S/MIME im Gegensatz zu PGP auf die X.509 Public Key Infrastructure. Daher muss vor der Verwendung von S/MIME ein Zertifikat einer Zertifizierungsstelle beantragt werden. Zertifizierungsstellen wie VeriSign bieten Zertifikaten an, welche nach 3 Vertrauensstufen unterschieden werden. Bei einem Klasse 1 Zertifikat, welches online beantragt werden kann, wird nur die Eindeutigkeit der E-Mail Adresse bestätigt. Bei Klasse 2 Zertifikaten wird dann auch postalisch eine Meldung an den Antragsteller geschickt, da dessen Name mit in das Zertifikat aufgenommen wird. Bei Klasse 3 muss der Antragssteller persönlich bei der Zertifizierungsstelle seine Identität vorweisen.

Secure Shell

Secure Shell (SSH) ist ein Client - Server Protokoll welches eine sichere Fernadministration von Computern über unsichere Netzwerke erlaubt . Es bietet folgende Funktionen:

• eine sichere Shell auf einem entfernten Rechner
• Port Forwarding beziehungsweise Tunneling von TCP/IP Verbindungen, auch über mehrere Rechnersysteme hinweg (Jumphosts)
• Mittels dynamischen Port Fowarding kann ein SSH Server als SOCKS Proxy Server verwendet werden.
• sicherer Dateitransfer mittels Secure copy (SCP) oder auch SFTP.
• mittels Secure SHell FileSystem (SSHFS) kann das Filesystem eines entfernten Rechners gemountet werden.

SSH Architektur

SSH Connection Layer
SSH Authentication Layer
SSH Transport Layer

SSH arbeitet auf mehreren Layern und kann somit einerseits als Applikation als auch als Netzwerkprotokoll bezeichnet werden. Die einzelnen Schichten von unten nach oben sind:

• Das SSH Transport Protocol ist in RFC 4253 definiert. Der Transport Layer setzt direkt auf TCP/IP auf und bietet eine sichere Verbindung für die darüber liegenden Schichten. Seine Aufgaben sind, die Aushandlung der verwendeten Algorithmen und Sitzungsschlüsseln, Serverauthentifizierung, Verschlüsselung und Sicherstellung der Integrität der Daten über HMAC.
• Das SSH Authentication Protocol wird in RFC 4252 beschrieben und bietet 3 Möglichkeiten der Benutzerauthentifizierung. Die Authentifizierung kann mittels username/password, public key Verfahren (RSA, DSA) oder keyboard-interactive.
• Das SSH Connection Protocol, standardisiert in RFC 4254 , führt die einzelnen Kanäle, die von SSH aufgebaut werden, zu einer einzigen SSH Verbindung durch. Durch den Austausch von Channel Requests können zudem Steuerinformationen ausgetauscht werden.