DTLS Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN 978-3824540662 http://www.weka.at/bestellen/ protokolle-und-dienste-derinformationstechnologie Datagram Transport Layer Security Das Sicherheitsprotokoll DTLS wurde entwickelt, um die Sicherheit der Kommunikation im Internet und in anderen privaten IP 1 -Netzen beim Einsatz eines unzuverlässigen Transportprotokolls wie dem User Datagram Protocol (UDP) gewährleisten zu können. DTLS stellt eine modifizierte Version des wichtigen Sicherheitsprotokolls Transport Layer Security (TLS) dar und wird daher auch als Datagram TLS bezeichnet. Im Gegensatz zu TLS, mit dem der Transport von Daten mithilfe eines verbindungsorientierten (Connectionoriented Transport Service, COTS) und demzufolge eines zuverlässigen Transportprotokolls wie dem Transmission Control Protocol (TCP) gegen bösartige Angriffe abgesichert werden kann, ermöglicht DTLS den Transport von Daten beim Einsatz eines verbindungslosen (Connectionless Transport Service, CLTS) und somit eines unzuverlässigen Transportprotokolls abzusichern. Die erste Version von DTLS kurz als DTLS 1.0 bezeichnet wurde im Dokument RFC 4347 (2006) der Internet Engineering Task Force (IETF) veröffentlicht und basiert auf der im RFC 4346 spezifizierten Version 1.1 des Protokolls TLS. Inzwischen wurde DTLS 1.0 von der Working Group TLS bei der IETF weiterentwickelt und um neue Sicherheitsverfahren so erweitert, dass eine neue und auf dem Protokoll TLS 1.2 basierende Version von DTLS als RFC 4347bis veröffentlicht werden soll. Mit der Bezeichnung dieser neuen Version als DTLS 1.2 2 soll auf das Basisprotokoll und zwar auf TLS 1.2 direkt verwiesen werden. Bedeutung von DTLS Ebenso wie TLS wird DTLS im Schichtenmodell wie Bild 004172 dies illustriert in der Anwendungsschicht quasi als eine DTLS- Teilschicht zwischen Anwendungsprotokollen und einem verbin- 1 Internet Protocol 2 http://tools.ietf.org/id/draft-ietf-tls-rfc4347-bis-03.txt 1
dungslosen Transportprotokoll wie UDP, Datagram Congestion Control Protocol (DCCP) 3 oder Stream Control Transmission Protocol (SCTP) 4 im unzuverlässigen Modus angesiedelt. Zu den Anwendungsprotokollen, die ein verbindungsloses Transportprotokoll nutzen, gehören vor allem Protokolle für die Realisierung der Dienste zur Übermittlung von Echtzeitmedien wie Sprache, Audio und Video über IP-Netze. Derartige Dienste gewinnen immer mehr an Bedeutung. Ein Beispiel dafür ist Voice over IP (VoIP) und auf das fernsehorientierte TV over IP (TVoIP) werden wir mit Sicherheit nicht lange warten müssen. Bild 004172: DTLS im Schichtenmodell und seine Bedeutung WKP: Well Known Port???: WKP ist noch nicht festgelegt Nutzt ein Anwendungsprotokoll DTLS, so wird der Name des Anwendungsprotokolls ebenso wie bei TLS mit dem Buchstaben S beendet. SIP (s.u.) wird beispielsweise zu SIPS umbenannt. Damit wird zum Ausdruck gebracht, dass es sich um die gesicherte Version eines Anwendungsprotokolls handelt. Wie in Bild 004172 dargestellt, können mithilfe von DTLS folgende Anwendungsprotokolle vor bösartigen Angriffen geschützt werden: 3 RFC 4340 4 RFC 4960 2
SIP over DTLS Secure SIP (SIPS) Das Session Initiation Protocol (SIP) 5 wird vor allem bei VoIP als Signalisierungsprotokoll verwendet. Normalerweise nutzt SIP innerhalb einer Domain im Sinne des Verzeichnisdienstes Domain Name System (DNS) das verbindungslose Transportprotokoll UDP. Zur Übermittlung von SIP-Nachrichten zwischen sog. SIP-Proxies aus verschiedenen Domains kommt aber immer häufiger SIPS zum Einsatz, um die Übermittlung von SIP- Nachrichten vor böswilligen Angreifern zu sichern. Das Konzept von SIP over DTLS beschreibt der Internet-Draft draftjennings-sip-dtls-05. SNMP over DTLS Secure SNMP (SNMPS) Das Simple Network Management Protocol (SNMP) 6 ist ein Protokoll für den Transport von Nachrichten beim Netzwerkmanagement. SNMPS ermöglicht eine gegenseitige Authentifizierung der Kommunikationspartner und garantiert sowohl die Integrität als auch die Vertraulichkeit von Managementnachrichten. RADIUS over DTLS oft Secure RADIUS genannt und als RADSec, RadSec bzw. als RADSEC bezeichnet Der Remote Authentication Dial-in User Service (RADIUS) 7 wird als Zugriffsprotokoll auf einen AAA-Server (Authentication, Authorization and Accounting Server) eingesetzt, der demzufolge meist als RADIUS-Server bezeichnet wird. Es beschreibt die Kommunikation zwischen einem RADIUS-Client und einem RADIUS-Server. Zur Absicherung dieser Kommunikation wird RADSec eingesetzt. Dieses Konzept beschreibt der Internet- Draft draft-dekok-radext-dtls-01. Syslog over DTLS genannt Secure Syslog Als Syslog (System-Login) wird ein Protokoll siehe RFC 5424 zur Übermittlung von sog. Log-Meldungen in Form von kurzen Textnachrichten (mit weniger als 1024 Bytes) in einem IP-Netz bezeichnet. Um diese Übermittlung gegen böswillige Angriffe 5 RFC 3261 6 RFC 1157 7 RFC 2865 3
z.b. gegen das Abhören abzusichern, kann Secure Syslog verwendet werden. IPFIX over DTLS Secure IPFIX (IPFIXS) Das Protokoll Internet Protocol Flow Information Export (IPFIX) 8 wird zur Überwachung der IP-Netze verwendet. Als Flow werden dabei zusammengehörende Pakete eines Datenstroms bezeichnet, wie z.b. aus der gleichen Datenquelle, zum gleichen Ziel oder des gleichen Anwendungsprotokolls. Mit IPFIXS können sich die beiden kommunizierenden Netzeinrichtungen wie z.b. ein Netzmonitor und eine von ihm überwachte Netzkomponente gegenseitig authentifizieren und untereinander verschlüsselte Nachrichten übermitteln. RTP over DTLS Das Realtime Transport Protocol (RTP) 9 gehört zu den wichtigsten Protokollen und wird zum Transport von Echtzeitmedien z.b. von Sprache, Audio und Video verwendet. RTP nutzt das verbindungslose Transportprotokoll UDP. Mit dem Einsatz von RTP over DTLS besteht daher die Möglichkeit, die Echtzeitkommunikation in IP-Netzen gegen bösartige Angriffe abzusichern. Hervorzuheben ist aber, dass es bereits vor der TLS-Ära (seit März 2004) das Protokoll Secure RTP (SRTP) 10 gab. Es verwendet ein zusätzliches Protokoll das sog. Multimedia Internet Keying (MIKEY) 11 zur Erzeugung eines geheimen Schlüssels. Es werden auch einige Konzepte entwickelt, welche RTP over DTLS mit dem Protokoll SRTP so integrieren, dass MIKEY nicht mehr gebraucht wird. In diesem Zusammenhang spricht man bereits von SRTP over DTLS oder von DTLS-SRTP für Näheres siehe z.b. den Internet-Draft draft-ietfavt-dtls-srtp-07.txt. 8 RFC 5101 9 RFC 3550 10 RFC 3711 11 RFC 3830 4
TLS over Datagram Wo sind die Probleme? Das grundlegende Konzept von DTLS ist es zu ermöglichen, dass TLS den verbindungslosen und unzuverlässigen Transportdienst d.h. den sog. Datagrammdienst (Datagram Service), insbesondere mithilfe des UDP nutzen kann. Ein solches Konzept verlangt aber eine Anpassung von TLS an die Besonderheiten des Datagrammdienstes. Dafür gibt es mehrere Ursachen, die infolge der Datenverluste beim Datagrammdienst entstehen. Die Anpassungen von TLS lassen sich zu den folgenden zwei Punkten zusammenfassen: 1. Der Ablauf von TLS, der zum Aufbau einer sog. TLC- Verbindung 12 führt, setzt aber voraus, dass alle TLS- Nachrichten das Ziel erreichen, also unterwegs nicht verloren gehen. Bei DTLS ist dies aber nicht der Fall, sodass mit Verlusten von transportierten TLS-Nachrichten gerechnet werden muss. 1-te TLS-Anpassung: Bei DTLS müssen somit bestimmte Mechanismen u.a. die Nummerierung von Nachrichten und zusätzlich ein Timeout-basierter Mechanismus eingeführt werden, damit man zuerst feststellen kann, ob eine Nachricht vermutlich unterwegs verloren gegangen ist und wann diese erneut gesendet werden soll (Bild 004175). 2. Bei TLS werden zur Verschlüsselung von zu transportierenden Daten verschiedene symmetrische Verschlüsselungsverfahren eingesetzt, die im Verschlüsselungsmodus (Betriebsart) Cipher Block Chaining (CBC) arbeiten. Die zu transportierenden Daten werden hierbei blockweise verschlüsselt (Block Cipher). Im Modus CBC wird jedoch vorausgesetzt, dass der am Ziel empfangene, verschlüsselte Block i nur dann entschlüsselt werden kann, falls der vorherige Block i-1 auch am Ziel vorliegt (Bild 004181). Weil UDP-Pakete während der Übermittlung verloren gehen können, ist damit zu rechnen, dass der verschlüsselte Block i bereits empfangen wurde und sein Vorgänger Block i-1 aber verloren gegangen ist. In dieser Situation lässt sich der Block i nicht entschlüsseln. 2-te TLS-Anpassung: Demzufolge muss die symmetrische 12 Eine TLS-Verbindung stellt eine gesicherte TCP- Verbindung dar. 5
Verschlüsselung im Modus CBC die Besonderheiten des Datagrammdienstes berücksichtigen. Bei DTLS wird eine entsprechend veränderte Verschlüsselung CBC mit einem expliziten Initialisierungsvektor (Initialization Vector, IV) als CBC Mode with an Explicit Initialization Vector verwendet. Besonderheiten von DTLS Die wichtigsten Besonderheiten von DTLS als Datagram TLS in Anlehnung an die Besonderheiten von TLS lassen sich wie folgt zusammenfassen: DTLS ist ein Client-Server-Protokoll: Bei DTLS unterscheidet man ebenso wie bei TLS auch zwischen TLS-Client und TLS-Server. Sie werden im Weiteren kurz Client und Server genannt. Vor dem eigentlichen Datenaustausch vereinbaren Client und Server mithilfe des Handshake-Protokolls eine Sicherheits-Suite (Cipher Suite), die festlegt, wie der Datentransport zwischen ihnen abgesichert werden soll. Hierbei spricht man von einer Handshake-Phase. Durch das Festlegen einer Cipher Suite siehe hierzu Bild 004173 werden folgende Punkte bezüglich der Sicherheitsgewährleistung geklärt: - Schlüsselaustauschverfahren (Key Exchange Method) und Authentifizierungsverfahren (Authentication Method): Welches Schlüsselaustauschverfahren, nach dem der Client und der Server bestimmte Schlüsselmaterialen austauschen müssen, wird eingesetzt, damit sie sich gegenseitig in die Lage versetzen, eigenständig einen gemeinsamen und geheimen Schlüssel generieren zu können. Auf diese Art und Weise wird geklärt, welches Authentifizierungsverfahren hierbei zum Einsatz kommt also, wie sich Client und Server gegenseitig authentifizieren können. - Symmetrisches Verschlüsselungsverfahren (Symmetric Encryption): Wie werden die zu übertragenden Daten verschlüsselt? - Hashfunktion (Hash Function) zur Authentifizierung empfangener Daten: Wie soll am Ziel die Integrität von empfangenen Daten überprüft werden? - Komprimierungsverfahren (Compression Method): Wie werden die zu übertragenden Daten komprimiert? 6
Struktur einer Cipher Suite Während einer Handshake-Phase (Bild 004176), die vor der eigentlichen Übertragung von Daten eines Anwendungsprotokolls stattfindet, vereinbaren nach DTLS die beiden kommunizierenden Partner, d.h. Client und Server, die Prinzipien, nach denen die Kommunikation zwischen ihnen abgesichert werden soll. Diese Prinzipien werden zu einer Cipher Suite zusammengefasst und sie hat die in Bild 004173 dargestellte Struktur. Bild 004173: Sicherheitsangaben in einer Cipher Suite bei DTLS Beispiel: Eine Cipher Suite kann die folgende Form haben: TLS_DH_DSS_WITH_AES_256_CBC_SHA256 Diese Cipher Suite ist wie folgt zu interpretieren: Das Schlüsselaustausch- und Authentifizierungsverfahren ist hier DH_DSS d.h. das Verfahren Diffie-Hellman (DH) 13 zur Erzeugung des symmetrischen, geheimen Schlüssels in Kombination mit dem Digital Signature Standard (DSS) zur Authentifizierung. Das Verschlüsselungsverfahren ist hier AES_256_CBC d.h. der Advanced Encryption Standard (AES) mit der Schlüssellänge 256 Bit im Modus CBC (Bild 004181). Zur Überprüfung der Integrität von empfangenen Daten wird hier die Hashfunktion SHA256 (Secure Hash Algorithm) verwendet. Die Zahl 256 gibt jeweils die Länge des Hashwertes in 13 nach Bailey Whitfield Diffie und Martin E. Hellman 7
Bits an. Zur Berechnung der an die transportierten Nachrichten eines Anwendungsprotokolls angehängten Prüffolge MAC (Message Authentication Code) wird noch der Algorithmus Hashbased MAC (HMAC) auf die Hashfunktion SHA256 angewendet. Jede offizielle Cipher Suite wird bei der Internet Assigned Numbers Authority (IANA) registriert 14 und hat demzufolge eine weltweit eindeutige Identifikation. Um eine Cipher Suite auszuwählen, brauchen die beiden kommunizierenden Partner während einer Handshake-Phase nur die Identifikationen von betreffenden Cipher Suites untereinander zu tauschen. Komponenten von DTLS DTLS ist das an die Besonderheiten des Datagrammdienstes angepasste Protokoll TLS. Daher enthält DTLS die gleichen Funktionskomponenten wie TLS. Bild 004173 zeigt diese Komponenten im Schichtenmodell und bringt zum Ausdruck, welche von ihnen bei TLS geändert wurden und damit DTLS-spezifisch sind. Die einzelnen Funktionskomponenten von DTLS sind wie folgt zu charakterisieren: Handshake-Protokoll eine DTLS-spezifische Form Dieses Protokoll definiert die Prinzipien, nach denen Client und Server all ihre Sicherheitsvereinbarungen treffen können. Mithilfe des Handshake-Protokolls wird die Cipher Suite vereinbart (Bild 004173). Bei DTLS handelt es sich hier um eine an die Besonderheiten des Datagrammdienstes angepasste Form des Handshake-Protokolls von TLS. Change-Cipher-Spec-Protokoll wie bei TLS Dieses Protokoll definiert nur die Nachricht Change- CipherSpec, mit der jeder Kommunikationspartner dem anderen lediglich signalisiert, dass er seinen Status gewechselt hat (vgl. Bild 004176 und Bild 004177). 14 Eine Auflistung aller bei IANA registrierten Cipher Suites findet man unter http://www.iana.org/assignments/tlsparameters/tls-parameters 8
Alert-Protokoll wie bei TLS Dieses Protokoll wird bei DTLS zur Signalisierung von fehlerhaften Situationen in Form von Warn- und Fehlermeldungen verwendet. Bild 004174: DTLS-Komponenten im Schichtenmodell (Datagrammdienst) Die untere Schicht von DTLS sowie von TLS funktioniert nach dem Record Layer Protocol (RLP). Dieses stellt die Rahmen (Frames) zur Verfügung, in denen die Nachrichten aller Protokolle der oberen Schicht, d.h. sowohl von (D)TLS-Systemkomponenten als auch von Anwendungsprotokollen, die den DTLS-Dienst nutzen, übermittelt werden. Das Record Layer Protocol muss an die DTLS- Anforderungen angepasst werden, d.h. es ist DTLS-spezifisch. Maßnahmen gegen Datenverluste beim Handshake-Protokoll Bei DTLS kann eine transportierte Nachricht des Handshake- Protokolls verloren gehen, sodass diese erneut gesendet werden muss. Um feststellen zu können, ob eine Nachricht in Verlust geraten ist und wann diese erneut gesendet werden muss, wird bei DTLS der Timeout-Mechanismus 15 verwendet. Bild 004175 illustriert dies. 15 Der Parameter Timeout kann als maximale Wartezeit auf eine Reaktion der Gegenseite auf eine dahin abgeschickte Nachricht angesehen werden. 9
Bild 004175: Timeout-Mechanismus bei DTLS Die erste gesendete Nachricht vom Handshake-Protokoll bei TLS und ebenso bei DTLS ist ClientHello. Als Antwort auf diese Nachricht sendet der Server HelloVerifyRequest. Jede dieser beiden Nachrichten kann aber unterwegs verloren gegen. Im gezeigten Beispiel ist HelloVerifyRequest verloren gegangen. Nach dem Absenden von ClientHello stellt der Client immer den Timer als seinen Zeitmesser ein, der für ihn wie ein Wecker dient und ihm die maximale Wartezeit für das Eintreffen von HelloVerifyRequest signalisiert. Ist die Wartezeit abgelaufen, sendet der Client erneut die Nachricht ClientHello. Hervorzuheben ist hier aber, dass sowohl Client als auch Server ihre Nachrichten mithilfe der Angabe message_sequence (kurz seq) im Nachrichten-Header fortlaufend nummerieren siehe hierzu auch Bild 004179. Diese Nummerierung ermöglicht es, die Duplikate von empfangenen Nachrichten zu erkennen. Mit Duplikaten ist vor allem dann zu rechnen, wenn der Wert des Timers zu klein ist und die Transportzeiten von Nachrichten wegen der Entfernung groß sind. Allgemeiner Ablauf des Handshake-Protokolls bei DTLS Die erste Aufgabe, die ein Client und ein Server zusammen ausführen müssen, ist die Vereinbarung von Prinzipien, nach denen die Sicherheit der Kommunikation zwischen ihnen garantiert werden soll. Eine solche Vereinbarung beim TLS-Einsatz bezeichnet man als TLS-Verbindung. Weil ein verbindungsloses Transportprotokoll wie z.b. UDP oder DCCP bei DTLS zum Einsatz kommt, wird 10
keine virtuelle Verbindung aufgebaut; somit kann bei DTLS nur von einer gesicherten Session zwischen Client und Server gesprochen werden. Bild 004176 illustriert den allgemeinen Verlauf des Handshake- Protokolls bei DTLS, d.h. die Abstimmung von Prinzipien für die Gewährleistung der Sicherheit bei der Datenkommunikation zwischen Client und Server. Falls mehrere Nachrichten in eine Richtung gesendet werden müssen, können sie bei DTLS gruppiert werden. Eine Gruppe solcher Nachrichten wird als Flight bezeichnet. Bild 004176: Verlauf des Handshake-Protokolls bei DTLS *: Optionale Nachricht Alle Nachrichten aus einem Flight können, wenn ihre gesamte Länge dies zulässt, sogar zu einem DTLS-Record (Bild 004178) zusammengefasst und in einem Datagramm transportiert werden. Allgemein betrachtet, verläuft das Handshake-Protokoll bei DTLS fast identisch wie bei TLS. Der Unterschied besteht nur zu Beginn und liegt darin, dass der Server bei DTLS die Nachricht HelloVe- 11
rifyrequest als Antwort auf die Nachricht ClientHello vom Client sendet und dieser antwortet auf HelloVerifyRequest vom Server erneut mit ClientHello. Die Nachricht HelloVerifyRequest wurde bei DTLS eingeführt, um das Cookie-Prinzip als Maßnahme gegen eventuelle DoS- Angriffe (Denial of Service) einsetzen zu können. Für die Fortsetzung siehe: Fachkompendium Protokolle und Dienste der Informationstechnologie, WEKA-Verlag, ISBN-13: 978-3824540662 12