Cryptography Reference
In-Depth Information
Diese vier Schlüssel werden eingesetzt, um die SSL-Records abzusichern. Ein SSL-Record ist
ein relativ einfach aufgebauter Datenblock, der wie in Abb. 6-8 dargestellt, die folgenden Fel-
der besitzt:
Die Felder „Typ und Version“ zeigen die verwendete SSL-Version an.
Das „Längenfeld“ gibt die Länge der nachfolgenden, verschlüsselten Nutzlast an.
Die Nutzlast selber enthält die mit K
C
oder K
S
verschlüsselten Daten des zu sichernden
Applikationsprotokolls, z.B. eine HTTPS-Anfrage (mit K
C
verschlüsselt) oder HTTPS-
Antwort (mit K
S
verschlüsselt).
Das „MAC-Feld“ beinhaltet den HMAC (Kap. 3.4) zur Integritätssicherung des gesamten
SSL-Records. Der HMAC wird mit Hilfe von K
MAC-C
bzw. K
MAC-S
über alle anderen Felder
des SSL-Records und einen zusätzlichen Sequenzzähler berechnet. Der Sequenzzähler er-
möglicht es, Replay-Attacken zu erkennen, d.h. das Wiedereinspielen von abgefangenen
SSL-Records durch einen Angreifer.
Abb. 6-8: Aufbau eines SSL-Records
6.3.3
Secure Shell, SSH
Neben SSL/TLS ist Secure Shell (SSH) ebenfalls eine Sicherungsschicht unterhalb der An-
wendungsschicht. Das SSH-Protokoll wird zur sicheren Fernnutzung eines über ein TCP/IP-
Netz verbundenen Unix-Rechners verwendet. Die Vertraulichkeit, Integrität und Authentizität
der an das „ferngenutzte System“ übermittelten Kommandos, z.B. für einen Login-Vorgang
oder Dateizugriff, wird von SSH gewährleistet. Dabei werden die ansonsten unsicheren Proto-
kolle und Kommandos, wie
mail
,
pop
oder auch eine X11-Terminalanbindung, mit Hilfe gän-
giger symmetrischer Verschlüsselungsalgorithmen, wie 3DES, IDEA oder AES, gesichert.
Wie bei SSL/TLS unterscheidet die in RFC 4251 [RFC4251] beschriebene SSH-Architektur
auch zwischen einem Handshake zur Authentisierung und einer Transportsicherung. Der im
Handshake ausgetauschte öffentliche Schlüssel des Servers kann wie bei SSL/TLS in einem
Zertifikat bestätigt werden. Der Handshake besteht bei SSH aus einer Authentisierungsanfrage
vom Client an den Server, auf die der Server mit seinem öffentlichen Schlüssel antwortet.
Anschließend schickt der Client den temporären und zufällig gewählten Transportschlüssel mit
dem öffentlichen Schlüssel des Servers verschlüsselt zurück. Nur der Server, der im Besitz des
passenden privaten Schlüssels ist, kann jetzt den Transportschlüssel entschlüsseln und den
Empfang mit einer mit dem Transportschlüssel verschlüsselten Nachricht beim Client bestäti-
gen. Anschließend authentisiert sich der Client in der über den Transportschlüssel gesicherten
Verbindung entweder mit seinem öffentlichen RSA-Schlüssel, der auf dem Server hinterlegt
ist, oder einem Passwort.
