Sicherheit in vernetzten Systemen - RRZ Universität Hamburg
Sicherheit in vernetzten Systemen - RRZ Universität Hamburg
Sicherheit in vernetzten Systemen - RRZ Universität Hamburg
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
KAPITEL 6. KEYMANAGEMENT UND KOMMUNIKATIONSVERBINDUNGEN<br />
In itia tor<br />
Responde r<br />
HDR , SA<br />
HDR , SA<br />
HDR , KE , Ni<br />
HDR , KE , Nr<br />
HDR# , ID_ i, [Ce rt ], SIG_ i<br />
HDR# , ID_r, [Ce rt ], SIG_r<br />
# = ve rsch lüsse lt<br />
Abbildung 6.5: TLS Handshake<br />
Falls der Server e<strong>in</strong> Client-Zertifikat angefordert hat, erfolgt nun die Übermittlung des Client-Zertifikates.<br />
Unabhängig von der „Client Certificate“-Nachricht folgt vom Client nach e<strong>in</strong>er „Server Hello Done“-Nachricht<br />
immer e<strong>in</strong>e „Client Key Exchange“-Nachricht. Diese enthält e<strong>in</strong> vom Client errechnetes<br />
„Premaster Geheimnis“. Das „Premaster Geheimnis“ ist verschlüsselt. Der dafür notwendige<br />
Schlüssel wurde je nach Vere<strong>in</strong>barung und Authentisierungsmethode entweder aus dem Serverzertifikat<br />
entnommen, <strong>in</strong> e<strong>in</strong>er „Server Key Exchange“-Nachricht übertragen oder mittels Diffie Hellman<br />
Austausch zwischen den Kommunikationspartnern ausgehandelt.<br />
Wurde vorher e<strong>in</strong>e „Client Certificate“-Nachricht mit e<strong>in</strong>em Zertifikat übermittelt, mit dem signiert<br />
werden kann, so sendet der Client nun e<strong>in</strong>e „Client Verify“-Nachricht, die e<strong>in</strong>e kryptographische<br />
Prüfsumme über alle vorher im Handshake ausgetauschten Nachrichten enthält. Dadurch werden Manipulationen<br />
Dritter an den während des Handshakes ausgetauschten Nachrichten erkennbar.<br />
Beide Kommunikationspartner errechnen nun aus dem „Premaster Geheimnis“ e<strong>in</strong> „Master Geheimnis“.<br />
Der Client sendet e<strong>in</strong>e vom „Change Cipher Spec“ Protokoll <strong>in</strong>itiierte „Change Cipher Spec“-Nachricht<br />
und zeigt damit an, daß der nachfolgende Datenverkehr verschlüsselt übertragen wird.<br />
Mit dem „Master Geheimnis“ wird nun <strong>in</strong> der Record Schicht beider Kommunikationspartner e<strong>in</strong><br />
Schlüsselblock errechnet, aus dem e<strong>in</strong> Sitzungsschlüssel entnommen wird. Damit wird der Datenstrom<br />
vom Client zum Server durch die Recordschicht verschlüsselt.<br />
Die erste mit dem Sitzungsschlüssel verschlüsselte Nachricht ist die „F<strong>in</strong>ished“-Nachricht vom Client<br />
zum Server. Sie enthält e<strong>in</strong>e Prüfsumme über das „Master Geheimnis“ und allen vorher gesendeten<br />
Handshake Nachrichten. Dabei werden nur Handshake-Protokollnachrichten berücksichtigt. „F<strong>in</strong>ished“-Nachrichten<br />
enthalten ke<strong>in</strong>e „Alert“ und „Change Cipher Spec“-Nachrichten.<br />
98 SS 99, Sem<strong>in</strong>ar 18.416: <strong>Sicherheit</strong> <strong>in</strong> <strong>vernetzten</strong> <strong>Systemen</strong>