SSL/TLS

Next: Das Biometrische Protokoll Up: Konzept der Implementation. Previous: Konzept der Implementation. Contents

Subsections

SSL Architektur
SSL Record Protokoll
Change Cipher Spec Protocol
Alert Protocol
Handshake Protokoll
Unterschiede zwischen SSLv3 und TLS

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]:

Session Identifier: Eine zufällige Bytesequenz, vom Server erzeugt, um eine aktive oder wiederherstellbare Session zu identifizieren.
Peer certificate: Ein X509.v3 Zertifikat des Clients. Dieses Element kann Null sein.
Compression method: Der Kompressionsalgorithmus, welcher vor der Verschlüsselung benutzt wird.
Cipher spec: Spezifiziert den Verschlüsselungsalgorithmus, sowie den Hash- algorithmus für den MAC. Zusätzlich werden noch Attribute, wie z.B Hashlänge, definiert.
Master secret: 48-Byte Geheimnis, welches vom Client und Server benutzt wird.
Is resumable: Ein Flag, welches anzeigt, ob diese Session für neue Verbindungen genutzt werden kann.

Auch die Connections definieren unterschiedliche Zustände

Server and client random: Byte-Sequenzen, welche vom Server und Client erzeugt werden, für jede Verbindung.
Server write MAC secret: Der geheime Schlüssel, der bei MAC-Operationen von Daten, die zum Server gehen, benutzt wird.
Client write MAC secret: Der geheime Schlüssel, der bei MAC-Operationen von Daten, die zum Client gehen, benutzt wird.
Server write key: Der symmetrische Schlüssel, der zur Verschlüsselung vom Server und bei der Entschlüsselung vom Client benutzt wird.
Client write key: Der symmetrische Schlüssel, der zur Verschlüsselung vom Client und bei der Entschlüsselung vom Server benutzt wird.
Initialization vectors: Wenn ein Blockchiffre in CBC-Mode benutzt wird, so wird ein initialization vector (IV) $\,$ für jeden Schlüssel beibehalten. Dieses Feld wird zum ersten Mal beim SSL Handshake Protokoll initialisiert. Danach wird der letzte Ciphertextblock von jedem Record, als IV benutzt für den nächsten Record.
Sequence numbers: Beide Parteien verwalten eigene Sequenznummern für die gesendeten und empfangenen Nachrichten jeder Verbindung. Falls einer der Parteien ein Change cipher spec $\,$ verschickt oder erhält, so wird die Sequenznummer wieder auf Zero gesetzt. Sequenznummern können nicht größer als $2^{64} -1$ werden.

SSL Record Protokoll

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

Vertraulichkeit: Das Handshake Protokoll handelt einen gemeinsamen geheimen Schlüssel aus, welcher für die symmetrische Verschlüsselung der SSL Nutzdaten benutzt wird.
Nachrichten Integrität: Das Handschake Protokoll definiert zudem auch einen gemeinsamen geheimen Schlüssel, welcher für den Message Authentication Code $\,$ (MAC) benutzt wird.

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össern⁶Wenn 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:

Content Type (8 bits): Das höhere Protokoll, welches für die Verarbeitung verwendet wird. Hierbei handelt es sich nicht um das Protokoll aus der Applikationsebene sondern um eines aus change_cipher_spec, alert, hand_shake und application_data. Das Anwendungsprotokoll ist transparent für SSL.
Major Version (8 bits): Kennzeichnet die Version des verwendeten SSL Protokolls. Bei SSLv3 ist der Wert 3.
Minor Version (8 bits): Kennzeichnet die Unterversion. Bei SSLv3 ist der Wert 0
Compressed length (16 bits): Die Länge der Klartextnachricht in Bytes. Bei Komprimierung, die Länge der komprimierten Klartextnachricht. Der maximale Wert darf nicht grösser als $2^{14} + 2048$ sein.

**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

unexpected_message: Ungültige Nachricht erhalten.
bad_record_mac: Ungültige MAC erhalten.
decompression_failure: Die Kompressionsfunktion hat eine ungültige Eingabe erhalten.
handshake_failure: Der Sender konnte keine Vereinbarung über die geforderten Sicherheitsparameter eingehen.
illegal_parameter: Ein Feld in einer handshake-Nachricht ist ungültig oder inkonsistent mit anderen Feldern.

Warnende Alertmeldungen

close_notify: Der Sender dieser Nachricht wird keine Nachrichten mehr schicken.
no_certificate: Antwort auf ein certificate_request, falls keines vorhanden ist.
bad_certificate: Ein korruptes Zertifikat erhalten.
unsupported_certificate: Type des erfhaltenen Zertifikats wird nicht unterstützt.
certificate_revoked: Das Zertifikat wurde widerrufen von seinem Signierer.
certificate_expired: Das Zertifikat ist abgelaufen.
certificate_unkown: Sonstiger Fehler ist beim validieren des Zertifikats aufgetreten.

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.

Type: (1Byte) Zeigt eine von 10 möglichen Nachrichten an.
Length: (3 Bytes) Enthält die Länge der Nachricht in Bytes.
Content: ( $\geq$ 1 Byte) Parameter, welche assoziert sind mit dieser Nachricht.

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:

Version: Die höchste Version von SSL, die der Client versteht.
Random: Eine auf dem Client generierte Zufallsstruktur, bestehend aus einem 32-Bit Zeitstempel und 28 zufällig generierten Bytes. Diese Werte dienen zum Schlüsselaustausch und verhindern Replay-Attacken.
Session ID: Ein Sitzungsbezeichner von variabler Länge. Wenn dieser Wert nicht 0 ist, dann kennzeichnet der Client hiermit, dass er die Parameter einer bestehende Session verändern möchte, oder eine neue Verbindung in der Session starten will. Ist der Wert 0, so wird eine neue Session gewünscht.
CipherSuite: Eine Liste von vorhandenen kryptographischen Algorithmen, in absteigender favorisierter Ordnung. Jeder Eintrag definiert sowohl ein Chiffre, wie auch ein Schlüsseltauschalgorithmus. Diese werden später genauer erläutert.
Compression Method: Eine Liste von Kompressionsalgorithmen, die der Client unterstützt.

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:

RSA: Der geheime symmetrische Schlüssel wird mit dem öffentlichen RSA Schlüssel des Empfängers verschlüsselt. Zu diesem Zweck muss ein Public-Key-zertifikat verfügbar sein.
Fixed Diffie-Hellman: Hier wird das Diffie-Hellman Schlüsseltausch-Protokoll benutzt. Die Diffie-Hellman öffentlichen Parameter müssen dazu im Server Zertifikat stehen und dieses von einer certificate authority $\,$ (CA) signiert sein. Der Client stellt seine Diffie-Hellman öffentlichen Schlüssel Parameter entweder in einem Zertifikat zur Verfügung, falls Client-Authentisierung erfoderlich ist, oder in einer Schlüsselaustausch-Nachricht .
Ephemeral Diffie-Hellman: Hier werden temporäre Einmalschlüssel erzeugt. Die Diffie-Hellman öffentlichen Schlüssel werden mit dem privaten RSA oder DSS Schlüssel des Senders signiert. Zertifikate werden eingesetzt um die öffentlichen Schlüssel zu verifizieren.
Anonymous Diffie-Hellman: Der Diffie-Hellman Algorithmus wird ohne Authentikation benutzt. Dazu schickt jede Seite ihre Diffie-Hellman Parameter an die andere Seite, ohne eine Authentikation derselben. Hierbei besteht deswegen die Gefahr für ein Man-in-Middle Attacke.
Fortezza: Hier wird das Fortezza Verfahren benutzt.

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

Cipher Algorithm: Ein Algorithmus aus RC4, RC2, DES, 3DES, DES40, IDEA, Fortezza.
MAC-Algorithm: MD5 oder SHA-1.
Chipher Type: Stream oder Block Chiffre.
Is Exportable: true oder false.
Hash Size: 0, 16 (MD5) oder 20 (SHA-1).
Key Material: Eine Sequenz von Bytes, welche für die Generierung von Schreibkeys benutzt wurde.
IV Size: Die Größe des Initialisierungswertes für die Cipher Block Chaining $\,$ Verschlüsselung.

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.

RSA: Der Client generiert ein 48-Byte pre-master secret und verschlüsselt dieses mit dem öffentlichen Schlüssel des Servers. Entweder aus dem Zertifikat oder aus dem temporären RSA-Schlüssel aus der server_key_message. Dieses wird später benutzt, um einen master secret zu berechnen.
Ephemeral oder Anonymous Diffie-Hellman: Die Client öffentlichen Diffie-Hellman Parameter werden verschickt.
Fixed Diffie-Hellman: Die öffentlichen Diffie-Hellman Parameter wurden schon im certificate_message verschickt, daher ist der Inhalt dieses Paketes null.
Fortezza: Die Fortezza Parameter werden verschickt.

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 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:

RSA: Der 48 Byte große pre_master_secret wird vom Client erzeugt, verschlüsselt mit dem öffentlichen Schlüssel des Servers und anschließend an diesen versandt. Der Server entschlüsselt die erhaltene Nachricht mit seinem privaten Schlüssel um den pre_master_secret zu erhalten.
Diffie-Hellman: Sowohl Client und Server generieren einen Diffie-Hellman öffentlichen Schlüssel. Nachdem diese Schlüssel ausgetauscht worden sind, führt jede Seite eine Diffie-Hellman Calculation durch, um den gemeinsamen pre_master_secret zu generieren.

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


master_secret := MD5(pre_master_secret  SHA('A'  pre_master_secret  


ClientHello.random  ServerHello.random))  


MD5(pre_master_secret  SHA('BB'  pre_master_secret  


ClientHello.random  ServerHello.random))  


MD5(pre_master_secret  SHA('CCC'  pre_master_secret  


ClientHello.random  ServerHello.random))

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:

Versionsnummer: Die Versionsnummer im Recordformat unterscheidet sich zu SSLv3. Aktuell ist für TLS die Major Version 3 und die Minor Version 1.
Message Authentication Code: Während beim MAC-Algorithmus in SSLv3 die Padding-Daten mit dem geheimen Schlüssel verkettet werden , wird bei TLS die Padding-Daten XORed. Ausserdem wird bei der MAC-Berechnung bei TLS noch ein zusätzlicher Parameter als bei SSLv3 benutzt, der Wert TLSCompression.version.
Pseudozufallsfunktion: TLS benutzt zusätzlich noch eine Pseudozufallsfunktion in der Generierung und Verifikation der Schlüssel. Der Sinn dabei ist, aus relativ kleinen Geheimnissen größere Byteblöcke zu generieren, welche resistenter sind bei Attacken gegen die Hashfunktionen.
Alert Codes: TLS implementiert alle Alert Codes aus SSLv3 und fügt noch zusätzliche hinzu.
Cipher Suite: TLS unterstützt alle Schlüsselaustausch-Protokolle ausser Fortezza. TLS unterstützt alle Symmetrischen Verschlüsselungsalgorithmen von SSLv3 ausser Fortezza.
Client Zertifikat Type: SSLv3 besitzt zusätzlich zu TLS rsa_ephemeral_dh, dss_ephemeral_dh und fortezza_kea als Zertifikat Typen. Ephemeral Diffie-Hellman benutzt entweder RSA oder DSS um die Diffie-Hellman Parameter zu signieren. Bei TLS werden hierfür die vorhanden rsa_sign oder dss_sign benutzt. TLS beinhaltet nicht das Fortezza-Schema.
Certificate_Verify and Finished Messages: Bei TLS wird in der certificate_verify_message der Hash nur über die handshake_messages erzeugt. Die extra Parameter aus SSLv3 master_secret und pads würden die Sicherheit nicht erhöhen. Der Hash in der finished_message wird bei TLS anders berechnet.
Master Secret: Der pre_master_secret wird wie bei SSLv3 erzeugt. Der daraus berechnete master_secret wird aber anders erzeugt. Auch die aus dem master_secret erzeugten MAC Geheimnisse, Session Schlüssel und Initialisierungs Vektoren werden anders berechnet.
Padding: Bei SSLv3 werden die Applikationsdaten auf das Minimum der benötigten Chiffreblockgröße aufgefüllt. TLS erlaubt auch das Auffüllen in ein vielfaches der benötigten Chiffreblockgröße. Dies soll die Angriffe auf die Länge der übermittelten Nachrichten erschweren.

Next: Das Biometrische Protokoll Up: Konzept der Implementation. Previous: Konzept der Implementation. Contents

willemATkoram.de