next up previous contents
Next: Das Biometrische Protokoll Up: Konzept der Implementation. Previous: Konzept der Implementation.   Contents

Subsections

SSL/TLS

Die Secure Sockets Layer$ \,$(SSL) Protokoll-Familie ist ursprünglich bei Netscape entstanden. Die aktuelle Version 3 des SSL-Protokolls ist auch als Internet Draft$ \,$ veröffentlicht [SSLv3 Draft] und die IETF hat daraus den allgemeinen Standard TLS 1.0 [TLS-RFC] entworfen, auch bekannt als Transport Layer Security$ \,$(TLS). Diese erste Version von TLS kann als SSLv3.1 angesehen werden und ist sehr eng an SSLv3 angelehnt. Deswegen wird hier im Allgemeinen SSL sowohl für SSLv3, als auch synonym für TLS benutzt. Am Ende von dieses Unterkapitels, werden kurz die Unterschiede zwischen SSLv3 und TLS erläutert.

SSL Architektur

SSL ist eine Protokollschicht, welche sich direkt über die Transportschicht im TCP/IP-Protokollstapel setzt und sich somit unter der Applikationsschicht befindet. Dieses Design hat den Vorteil, dass SSL unabhängig von dem verwendeten Applikationsprotokoll eine sichere Punkt-zu-Punkt Verbindung herstellen kann. SSL besteht nicht aus einem einzelnem Protokoll, sondern besitzt zwei Protokollschichten.


Table 5: SSL Protokoll-Stack

$\displaystyle \begin{tabular}{\vert c \vert c \vert c \vert c \vert }
\hline \s...
...t}{TCP} \\
\hline
\multicolumn{4}{\vert c\vert}{IP} \\
\hline
\end{tabular}$


Zwei wichtige Konzepte von SSL sind die SSL-Session und die SSL-Connection.

SSL-Session
Eine SSL-Session ist eine Assoziation zwischen einem Client und einem Server. Sessions werden über das Handshake-Protokoll aufgebaut. Eine Session definiert eine Menge von kryptologischen Sicherheitsparametern, welche gemeinsam über mehrere Verbindungen genutzt werden können. Der Sinn hinter Session besteht darin, nicht jedesmal eine neue zeitaufwendige Verhandlung der Sicherheitsparameter auszuführen.
SSL-Connection
Eine SSL-Connection ist ein Transportkanal, welcher einrn spezifizierten Service bietet. Bei SSL handelt es sich um Peer-to-Peer Verbindung, welche nur vorübergehend aufgebaut sein kann. Jede Connection muss mit einer Session assoziert sein.

Somit können aus einer Session mehrere Connections aufgebaut werden, welche auch parallel betrieben werden können.

SSL-Sessions besitzen unterschiedliche Zustände. Ein Sessionzustand ist definiert über folgende Parameter [SSLv3 Draft]:

Auch die Connections definieren unterschiedliche Zustände

SSL Record Protokoll

Das SSL Record Protokoll stellt zwei Dienste für SSL-Verbindungen zur Verfügung

Das SSL Record Protokoll nimmt eine für die Übertragung vorgesehene Applikationsnachricht an und erstellt daraus ein SSL-Paket. Zunächst wird das Paket fragmentiert und in die notwendige Blöckgröße zerlegt/aufgefüllt. Optional wird dann dieser Block komprimiert. Anschliessend wird ein MAC angehangen. Dieser neue Block wird verschlüsselt und ein SSL-Header vorrangestellt. Anschliessend wird dieser Block dem TCP-Stack übergeben. Der Empfänger entschlüsselt, verifiziert und dekomprimiert diesen Block. Anschliessend setzt er aus den anderen Teilen wieder den ursprünglichen Block zusammen und übergibt ihn dann an die Applikationsebene.

Figure 9: SSL-Paket erstellen
\begin{figure}\centerline{\epsfig{file=bilder/SSL_Prozess.eps, width= 16cm}}\end{figure}

Der erste Schritt ist die Fragmentierung. Jedes Fragment hat eine Größe von $ 2^{14}$ Bytes oder kleiner. Anschliessend wird optional dieser Block komprimiert. Der verwendete Kompressionsalgorithmus muss verlustlos sein und darf die Nachricht nicht auf mehr als 1024 Bytes vergrössern6Wenn bei SSLv3 (als auch bei TLS) kein Kompressionsalgorithmus gewählt wurde, wird der Block nicht komprimiert. Der nächste Schritt ist das Berechnen des message authentication code und anschliessend das Anhängen desselben an den Datenblock. Hierzu wird ein gemeinsamer geheimer Schlüssel benötigt. Der verwendete Algorithmus ist dem des HMAC sehr ähnlich.
$ hash(MAC.write.secret \Vert pad2 \Vert \\
hash(MAC.write.secret \Vert pad1 \V...
...SLCompressed.type \Vert \\
SSLCompressed.length \Vert SSLCompressed.fragment))$
wobei
$ \Vert$ = Konkatenation
MAC.write.secret = gemeinsamer geheimer Schlüssel
hash = Hashalgorithms, entweder MD5 oder SHA-1
pad1 = Das Byte 0x36 48 mal wiederholt für MD5 oder 40 mal für SHA-1
pad2 = Das Byte 0x5c 48 mal wiederholt für MD5 oder 40 mal für SHA-1
seq.num = Die Sequenznummer für diese Nachricht
SSLCompressed.type = Das nächst höhere Protokoll,welches benutzt wurde, um dieses Fragment zu bearbeiten
SSLCompressed.length = Die Länge des Fragments
SSLCompressed.fragment = Das komprimierte Fragment, oder falls keine Kompression der Daten gewählt wurde, der Klartext.

Anschliessend wird die komprimierte Nachricht einschliesslich des MACs mit einem symmetrischen Schlüssel verschlüsselt. Wobei die verschlüsselte Nachricht nicht größer als 1024 Bytes werden darf. Somit wird die Gesamtlänge nicht größer als $ 2^{14} + 1024$ Bytes.

Folgende Verschlüsselungsalgorithmen dürfen hierfür verwendet werden:


Table: SSL Verschlüsselungsalgorithmen

$\displaystyle \begin{tabular}{\vert c \vert c \vert c \vert c \vert }
\hline & ...
...\
\hline 3DES & 168 && \\
\hline Fortezza & 80 && \\
\hline
\end{tabular}$


Zum Abschluss wird im SSL Record Protokoll noch ein Header der Nachricht vorangestellt, der folgende Felder hat:


Table 7: SSL Record Format

$\displaystyle \begin{tabular}{\vert c \vert c \vert c \vert c \vert }
\hline
\s...
...\vert c\vert}{MAC (0,16 oder 20 Bytes) verschlüsselt} \\
\hline
\end{tabular}$


Change Cipher Spec Protocol

Das Change Cipher Spec Protocol ist eines von drei SSL-spezifizierten Protokollen, welches das darunterliegende SSL Record Protokoll benutzt. Dieses Protokoll besteht nur aus einer einzigen Nachricht mit nur einem Byte. Dieses Byte hat nur den Wert 1. Der Sinn hinter diesem Protokoll ist es, einen wartenden Zustand in einen aktuellen Zustand zu kopieren. Dieses hat zur Folge, dass die Chiffre-Suite aktualisiert wird.

Alert Protocol

Das Alert Protocol dient zum Übertragen von SSL Fehlermeldungen. Wie bei Applikationen, die SSL benutzen, werden diese Nachrichten komprimiert und verschlüsselt. Jede Nachricht aus diesem Protokoll besteht aus 2 Bytes. Das erste Byte kann den Wert warning(1) oder fatal(2) haben und gibt den Grad der Fehlermeldung an. Wird der Wert fatal übertragen, beendet SSL sofort die Verbindung. Andere Verbindungen aus der Session bleiben bestehen, aber es kann keine neue Verbindung erzeugt werden. Das zweite Byte beschreibt den Fehler genauer.

Fatale Alertmeldungen

Warnende Alertmeldungen

Handshake Protokoll

Das komplexeste Protokoll bei SSL ist das Handshake Protokoll. Dieses Protokoll dient zum authentisieren des Servers und des Clients, zum Aushandeln eines Verschlüsselungs- und MAC-algorithmus, sowie zum Austauschen der kryptographischen Schlüssel, welche für die Sicherung der Daten benutzt werden. Dieses Protokoll tauscht unterschiedliche Nachrichten zwischen Client und Server aus, die alle den gleichen Aufbau besitzen.

Auf der nächsten Seite folgt eine Tabelle mit den unterschiedlichen Nachrichtentypen.

Table 8: SSL Handshake Protokoll Nachrichten Typen

$\displaystyle \begin{tabular}{\vert c \vert c \vert }
\hline \textbf{Nachrichte...
...rameters, signature \\
\hline finished & hash value \\
\hline
\end{tabular}$


Das Handshake Protokoll kann in 4 Phasen aufgeteilt werden.

Phase 1: Erstellung der Sicherheitsfähigkeiten
Diese Phase dient zum Initiieren einer logischen Verbindung und zum Aufbau der Sicherheitmöglichkeiten, die mit der Verbindung assoziert werden sollen. Dieser Austausch wird vom Client gestartet, indem dieser eine client_hello Nachricht an den Server schickt mit folgenden Parametern:

Nachdem der Client ein client_hello verschickt hat, wartet er auf die server_hello Nachricht. Diese vom Server verschickte Nachricht hat dieselben Felder wie die client_hello Nachricht. Das Version Feld enthält die höchste SSL Version, die der Server unterstützt und die auch vom Client verarbeitet werden kann. Der Inhalt des Random Feldes wird vom Server generiert und ist unabhängig vom Inhalt des Random Feldes aus der Client Nachricht. Wenn das Session ID Feld vom Client nicht 0 war, wird vom Server derselbe Wert benutzt. Ansonsten enthält dieses Feld den Wert der neuen Session. Das CipherSuite Feld enthält in der Serverantwort nur einen einzigen Algorithmus mit zugehörigem Schlüsselaustauschalgorithmus. Der Server hat diese aus den angebotenen Möglichkeiten vom Client ausgewählt. Das Compression Method Feld enthält wiederrum nur einen Kompressionalgorithmus aus den Vorschlägen des Clients.
Das erste Element im CipherSuite Feld ist der Schlüsselaustauschalgorithmus. Folgende Schlüsselaustauschalgorithmen werden unterstützt:

Nach dem Schlüsselaustauschalgorithmus folgen die Chiffre-Parameter, welche aus folgenden Feldern besteht:

Phase 2: Serverauthentisierung und Schlüsseltausch
Der Server beginnt die Phase mit dem Senden seines Zertifikates in einer certificate message , falls er authentisiert werden soll. Dies ist nicht notwendig, falls Anonymous Diffie-Hellman benutzt wird. Diese Nachricht enthält ein X.509 Zertifikat oder eine Kette von X.509 Zertifikaten. Falls Fixed Diffie-Hellman benutzt wird, steht in diesem Zertifikat die öffentlichen Diffie-Hellman Parameter. Anschließend kann, falls notwendig, eine server_key_exchange_message vom Server gesendet werden. Es wird nicht verlangt, falls der Server Fixed Diffie-Hellman benutzt oder RSA zum Schlüsseltausch angewendet wird. Nun kann der Server ein Client Zertifikat anfordern, dazu schickt er eine certificate_request_message Nachricht. Diese enthält zwei Parameter: certificate_type und certificate_authorities. Der certificate_type bezeichnet den Publickey-Algorithmus des Zertifikates und certificate_authorities enthält eine Liste von ausgezeichneten Namen und akzeptierten CAs. Abschliessend für die 2. Phase wird die server_done_message Nachricht geschickt. Diese ist immer erforderlich. Nach dem Senden dieser Nachricht wartet der Server auf die Antwort vom Client. Diese Nachricht besitzt keine Parameter.

Phase 3: Clientauthentisierung und Schlüsseltausch
Nachdem der Client die server_done_message empfangen hat, prüft dieser , falls notwendig, ob er ein validiertes Zertifikat erhalten hat und checkt ob die server_hello Parameter akzeptabel sind. Wenn alles zufriedenstellend ist, schickt der Client folgende Nachrichten an den Server. Falls der Server ein Client- Zertifikat erfordert, so schickt der Client zunächst eine certificate_message zum Server. Anschließend muss ein client_key_exchange_message zum Server geschickt werden. Der Inhalt dieser Nachricht hängt von dem verwendeten Schlüsseltausch-Protokoll ab.

Zuletzt in dieser Phase kann der Client eine certificate_verify_message verschicken. Diese dient zum expliziten verifizieren des Clients Zertifikates. Diese Nachricht wird nur verschickt, wenn das Client Zertifikat Signierfunktionalität besitzt (alle ausser Fixed Diffie-Hellman). Diese Nachricht enthält den signierten Hashcode aller vorherigen Nachrichten. Wenn jemand das Client-Zertifikat entwendet hat, aber nicht den privaten Schlüssel für dieses Zertifikat besitzt, kann er diese Nachricht nicht erstellen.

Phase 4: Finish
Diese Phase beendet den Aufbau einer gesicherten Verbindung. Der Client sendet eine change_cipher_spec_message Nachricht und kopiert die ausgehandelten ChipherSpec in die aktuellen CipherSpec. Diese Nachricht ist nicht mehr Teil des Handshake Protokolls, sondern nutzt das Change Cipher Spec Protokoll. Anschliessend schickt der Client eine finished_message Nachricht. Diese Nachricht wird mit dem neuen Algorithmus, Schlüssel und Geheimnis erstellt. Diese Nachricht verifiziert, dass der Schlüsseltausch und Authentisierungsprozess erfolgreich waren. Der Inhalt dieses Paketes besteht aus zwei Hashwerten:
$ MD5(master\_secret \Vert pad\_2 \Vert \\ MD5(handshake\_messages \Vert Sender ...
...rt \\ SHA(handshake\_messages \Vert Sender \Vert master\_secret \Vert pad\_1))
$
Wobei $ Sender$ ein Code ist, der den Client identifiziert und $ handshake\_messages$ alle Nachrichten bis zu dieser enthält.
Der Server antwortet auf diese empfangene Nachricht mit seiner change_Cipher_Spec_message und transferiert die ausgehandelte CipherSpec in seinen aktuellen CipherSpec. Anschliessend schickt auch der Server eine finished_message.
Nun ist der Verbindungsaufbau vollständig und der Client und Server können die Daten aus dem Applikations-Layer austauschen.

Figure 10: SSL Handshake Protokoll
\begin{figure}\centerline{\epsfig{file=bilder/SSL_Handshake_Protokoll.eps, width= 16cm}}\end{figure}

Generierung des Master-Keys
Der gemeinsam benutzte Master-Key besteht aus 48 Byte und und gilt nur für eine Session. Der Schlüssel wird in 2 Stufen generiert. Zuerst wird im Handshake-Protokoll ein pre_master_secret ausgetauscht. Dabei exisitieren zwei Fälle für den Austausch des pre_master_secret:

In der zweiten Stufe berechnen dann beide Parteien aus diesem pre_master_secret den Master-Key:


master_secret := MD5(pre_master_secret $ \Vert$ SHA('A' $ \Vert$ pre_master_secret $ \Vert$ 

ClientHello.random $ \Vert$ ServerHello.random)) $ \Vert$
MD5(pre_master_secret $ \Vert$ SHA('BB' $ \Vert$ pre_master_secret $ \Vert$
ClientHello.random $ \Vert$ ServerHello.random)) $ \Vert$
MD5(pre_master_secret $ \Vert$ SHA('CCC' $ \Vert$ pre_master_secret $ \Vert$
ClientHello.random $ \Vert$ ServerHello.random)) $ \Vert$
wobei ClientHello.random und ServerHello.random die beiden Werte aus der ausgetauschten anfänglichen hello_message sind.

Erzeugung der CipherSpecs
Die benutzten CipherSpecs benötigen ein Client MAC-Geheimnis, einen Server MAC-Geheimnis, einen Client Schlüssel, ein Server Schlüssel, ein Client Initialisierungsvektor und einen Server Initialisierungsvektor. Diese werden aus dem Master-Key erzeugt. Dazu werden mehrere Hashes des Master-Key für die notwendige Anzahl von Bytes für die einzelnen Paramter errechnet. Man kann somit den Master-Key als Seed-Wert für eine pseudozufällige Berechnung ansehen und die ClientHello.random und ServerHello.random als zusätzliche Verschleierung für eine Kryptoanalyse.

Unterschiede zwischen SSLv3 und TLS

TLS, welches aufbauend von SSLv3 bei der IETF entstanden ist, liegt zur Zeit als Draft Version vor. Hier werden kurz die Unterschiede zu SSLv3 vorgestellt:


next up previous contents
Next: Das Biometrische Protokoll Up: Konzept der Implementation. Previous: Konzept der Implementation.   Contents
willemATkoram.de