17.06.2014 Aufrufe

Sicherheit in vernetzten Systemen - RRZ Universität Hamburg

Sicherheit in vernetzten Systemen - RRZ Universität Hamburg

Sicherheit in vernetzten Systemen - RRZ Universität Hamburg

MEHR ANZEIGEN
WENIGER ANZEIGEN

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>

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!