Sicherheit in vernetzten Systemen - RRZ Universität Hamburg

6.3. KEYMANAGEMENT-PROTOKOLLE
Das TLS Handshake Protokoll – Authentisierung der Kommunikationspartner
Die Authentisierung in TLS findet zertifikatbasiert statt. Es werden die Authentisierungsmodi anonym,
Server-Authentisierung sowie Client-und Server-Authentisierung unterschieden. Im anonymen
Authentisierungsmodus findet keine Authentisierung der Partner statt. Bei der Server-Authentisierung
authentisiert sich nur der Server gegenüber dem Client. Client und Serverauthentisierung erfordert
einen gegenseitigen Zertifikatsaustausch und ermöglicht somit eine gegenseitige Authentisierung.
TLS Handshake – Schlüsseletablierung
Zuerst wird mit den „Hello“-Nachrichten verhandelt, wie die Verbindung aufgebaut wird. Hierbei
handelt es sich um die Einigung über Verschlüsselungs- und Kompressionsverfahren. Danach erfolgt
eine Authentisierung mit Zertifikaten. Der zur Übertragung des „Premaster Geheimnisses“ notwendige
Austausch von Schlüsselmaterial kann entweder mit RSA [Rivest, 1978] oder Diffie Hellman
erfolgen. Vom Client wird ein „Premaster Geheimnis“ gebildet und verschlüsselt zum Server übertragen.
Der Server entschlüsselt das „Premaster Geheimnis“ mit seinem privaten Schlüssel. Client und
Server errechnen mit dem „Premaster Geheimnis“ das „Master Geheimnis“. Das „Master Geheimnis“
dient der Berechnung eines Schlüsselblocks. Aus dem Schlüsselblock werden Sitzungsschlüssel
entnommen, mit denen der Datenverkehr verschlüsselt wird. Dabei unterscheidet sich der Sitzungsschlüssel
des Client von Sitzungsschlüssel des Servers. Der Datenstrom vom Client zum Server wird
also mit einem anderen Schlüssel verschlüsselt als der Datenstrom vom Server zum Client.
Letztlich erfolgt die Überprüfung des Handshake. Beide Kommunikationspartner überprüfen in der
letzten Nachricht des Handshake („Finished“-Nachricht) ihr „Master Geheimnis“, indem sie eine
Prüfsumme über das „Master Geheimnis“ und alle vorher im Handshake getauschten Nachrichten
übermitteln. Die Prüfsumme der „Server Finished“-Nachricht wird dabei auch über die „Client Finished“-Nachricht
gebildet.
Nachrichtenabfolge
Der Client leitet den Verbindungsaufbau mit einem „Client Hello“ ein. Die „Client Hello“-Nachricht
enthält einen Zeitstempel und eine Zufallszahl, die später für die Ableitung von Sitzungsschlüsseln
benutzt wird. Bestand bereits eine Verbindung, so kann der Client die Sitzungs-ID der damaligen
Sitzung angeben, um diese wieder aufzunehmen oder eine identische Sitzung zu eröffnen. Darüber
hinaus enthält die „Client Hello“-Nachricht eine sortierte Liste mit den Verfahren, die die Verbindung
schützen sollen.
Der Server antwortet mit einer „Server Hello“-Nachricht. Diese enthält eine Protokollversionsnummer,
einen Zufallswert, die Sitzungs-ID sowie die gewählten kryptographischen Verfahren (Authentisierungsmethode,
Verschlüsselungsalgorithmus) und die gewählte Komprimierungsmethode. Der Server
bestimmt dabei über die Verfahren, die verwendet werden. Die Sitzungs-ID stimmt im Fall einer
wieder aufgenommenen Sitzung mit der vom Client vorgeschlagenen überein. Andernfalls wird vom
Server eine neue Sitzungs-ID vergeben.
Abhängig von der verwendeten Authentisierungsmethode wird nun eine „Certificate“-Nachricht vom
Server zum Client übermittelt. Diese enthält eine Liste von Zertifikaten. Optional kann der Server
mit einer „Certificate Request“-Nachricht ein Zertifikat vom Client anfordern, um eine Client-
Authentisierung zu ermöglichen. Mit einer „Server Hello Done“-Nachricht zeigt der Server danach
an, daß von ihm keine weiteren Nachrichten außer der Finished Nachricht übermittelt werden.
SS 99, Seminar 18.416: Sicherheit in vernetzten Systemen 97