Transportebene

Für die sichere Übertragung von Daten wird im TwinCAT IoT-Treiber der weltweit gängige Standard Transport Layer Security (TLS) verwendet. Das folgende Kapitel beschreibt den TLS-Kommunikationsablauf exemplarisch am Beispiel von TLS-Version 1.2.

TLS ist ein Standard, welcher eine Kombination aus symmetrischer und asymmetrischer Kryptographie darstellt und versendete Daten vor unbefugtem Zugriff und Manipulation durch Dritte schützt. Außerdem wird die Authentifizierung der Kommunikationsteilnehmer zur gegenseitigen Identitätsprüfung von TLS unterstützt.

	Inhalt dieses Kapitels Die folgenden Informationen in diesem Kapitel beziehen sich in allgemeiner Weise auf den TLS-Kommunikationsablauf und haben keinen Bezug zu der Implementierung in TwinCAT. Sie sollen lediglich für ein grundlegendes Verständnis sorgen, um den in den folgenden Unterkapiteln erläuterten Bezug zu der TwinCAT-Implementierung besser nachvollziehen zu können.

Unterstützte Funktionen

Der TwinCAT IoT -Treiber ermöglicht die Verwendung der folgenden TLS-Funktionen.

Funktion	Beschreibung
Selbst signierte Clientzertifikate	Verwendung eines selbst-signierten Clientzertifikats zur Authentifizierung am Message Broker.
CA-signierte Clientzertifikate	Verwendung eines CA-signierten Clientzertifikats zur Authentifizierung am Message Broker. Das CA-Zertifikat kann zum Herstellen einer Vertrauensstellung ebenfalls angegeben werden.
Zertifikatssperrlisten	Verwendung von Zertifikatssperrlisten (englisch: Certificate Revocation Lists (CRL)).
Pre-Shared Key (PSK)	Verwendung eines Pre-Shared Key (PSK) zur Authentifizierung am Message Broker.

Definition Cipher-Suite

Eine Cipher Suite ist per Definition eine Zusammensetzung von Algorithmen (Schlüsselaustausch, Authentifizierung, Verschlüsselung, MAC) zur Verschlüsselung. Auf diese einigen sich Client und Server während des TLS-Verbindungsaufbaus. Weitere Informationen zu Cipher Suites entnehmen Sie bitte der Fachliteratur.

TLS-Kommunikationsablauf

Am Anfang einer Kommunikation mit TLS-Verschlüsselung steht der sogenannte TLS-Handshake zwischen Server und Client. Während des Handshakes wird asymmetrische Kryptographie verwendet, nach erfolgreichem Abschluss des Handshakes kommunizieren Server und Client mit symmetrischer Kryptographie, da diese um ein Vielfaches schneller ist als asymmetrische Kryptographie.

Es gibt drei verschiedene Arten der Authentisierung für das TLS-Protokoll:

Der Server weist sich per Zertifikat aus (siehe Server-Zertifikat)
Client und Server weisen sich per Zertifikat aus (siehe Client/Server-Zertifikat)
Pre-Shared-Keys (siehe Pre-Shared-Keys)

Über Vor- und Nachteile der verschiedenen Authentisierungsarten informieren Sie sich bitte in der Fachliteratur.

	Beispielhafte Erläuterung anhand von RSA Alle mit * gekennzeichneten Nachrichten sind optional und werden nicht zwingend benötigt. Die nachfolgenden Schritte beziehen sich auf das RSA-Verfahren und haben keine allgemeine Gültigkeit für andere Verfahren.

Die folgende Tabelle erläutert die einzelnen Schritte aus dem oben dargestellten Kommunikationsablauf.

Schritt	Beschreibung
ClientHello	Der Client initiiert einen Verbindungsaufbau zum Server. Dabei werden unter anderem die verwendete TLS-Version, eine Zufallsfolge von Bytes (Client Random) und die vom Client unterstützten Cipher Suites übertragen.
ServerHello	Der Server sucht sich aus den vom Client offerierten Cipher Suites eine aus und legt diese für die Kommunikation fest. Besteht keine Schnittmenge zwischen den vom Client und Server unterstützten Cipher Suites, wird der TLS-Verbindungsaufbau abgebrochen. Zusätzlich kommuniziert auch der Server eine Zufallsfolge von Bytes (Server Random).
Certificate	Der Server präsentiert dem Client sein Zertifikat, damit der Client verifizieren kann, dass der Server auch der erwartete Server ist. Vertraut der Client dem Server-Zertifikat nicht, wird der TLS-Verbindungsaufbau abgebrochen. Das Server-Zertifikat enthält zusätzlich den öffentlichen Schlüssel des Servers.
ServerKeyExchange	Bei bestimmten Schlüsselaustauschalgorithmen reichen die Informationen aus dem Zertifikat nicht aus, damit der Client das sogenannte Pre-Master Secret erzeugen kann. In diesem Fall werden die fehlenden Informationen mittels Server Key Exchange übertragen.
CertificateRequest	Der Server fordert vom Client ein Zertifikat an, um die Identität des Clients verifizieren zu können.
ServerHelloDone	Der Server teilt dem Client mit, dass sein Versenden der initialen Informationen beendet ist.
Certificate	Der Client kommuniziert sein Zertifikat inklusive des öffentlichen Schlüssels an den Server. Der Ablauf ist der gleiche wie in entgegengesetzter Richtung: Vertraut der Server dem vom Client versendeten Zertifikat nicht, wird der Verbindungsaufbau abgebrochen.
ClientKeyExchange	Der Client verwendet den öffentlichen Schlüssel des Servers, um durch asymmetrische Verschlüsselung ein von ihm generiertes Pre-Master Secret verschlüsselt an den Server zu schicken. Aus diesem Pre-Master Secret, dem Server Random und dem Client Random wird dann der symmetrische Schlüssel berechnet, der nach dem Verbindungsaufbau für die Kommunikation verwendet wird.
CertificateVerify	Der Client signiert die bisherigen Nachrichten des Handshakes mit seinem privaten Schlüssel. Da der Server den öffentlichen Schlüssel des Clients durch das Versenden des Zertifikats erhalten hat, kann er verifizieren, dass das präsentierte Zertifikat auch wirklich dem Client „gehört“.
ChangeCipherSpec	Der Client teilt dem Server mit, dass er auf symmetrische Kryptographie umsteigt. Jede Nachricht vom Client an den Server ab hier ist signiert und verschlüsselt.
Finished	Der Client teilt dem Server verschlüsselt mit, dass der TLS-Verbindungsaufbau auf seiner Seite beendet ist. Die Nachricht enthält einen Hash und einen MAC über die bisherigen Nachrichten des Handshakes.
ChangeCipherSpec	Der Server entschlüsselt das Pre-Master Secret, das der Client mit seinem öffentlichen Schlüssel verschlüsselt hat. Da der Server der Einzige ist, der seinen privaten Schlüssel besitzt, kann nur der Server dieses Pre-Master Secret entschlüsseln. So wird sichergestellt, dass der symmetrische Schlüssel nur Client und Server bekannt ist. Anschließend berechnet auch der Server den symmetrischen Schlüssel aus Pre-Master Secret und den beiden Zufallsfolgen und teilt dem Client mit, dass auch er jetzt mit symmetrischer Kryptographie kommuniziert. Jede Nachricht vom Server an den Client ab hier ist signiert und verschlüsselt. Durch die Generierung des symmetrischen Schlüssels kann der Server die Finished-Nachricht des Clients entschlüsseln und sowohl Hash als auch MAC verifizieren. Sollte diese Verifizierung fehlschlagen, wird die Verbindung abgebrochen.
Finished	Der Server teilt dem Client mit, dass der TLS-Verbindungsaufbau auf seiner Seite ebenfalls beendet ist. Die Nachricht enthält so wie beim Client einen Hash und einen MAC über die bisherigen Nachrichten des Handshakes. Auf der Seite des Clients wird dann dieselbe Verifikation vollzogen wie beim Server, auch hier gilt: Wenn Hash und MAC nicht erfolgreich entschlüsselt werden, wird die Verbindung abgebrochen.
ApplicationData	Client und Server kommunizieren nach Abschluss des TLS-Verbindungsaufbaus mit symmetrischer Kryptographie.

Weiterführende Informationen