DTLS. Datagram Transport Layer Security DTLS. Autor: Prof. Dr.-Ing. Anatol Badach

Transkript

1 Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Dipl.-Ing. Heinz Schulte DTLS 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 wurde. Mit der Bezeichnung dieser neuen Version als DTLS wird auf das Basisprotokoll und zwar auf TLS 1.2 direkt verwiesen. Bedeutung von DTLS Ebenso wie TLS wird DTLS im Schichtenmodell wie Bild dies illustriert in der Anwendungsschicht quasi als eine DTLS- Teilschicht zwischen Anwendungsprotokollen und einem verbindungslosen Transportprotokoll wie UDP, Datagram Congestion WEKA-Verlag ISBN Internet Protocol 2 RFC

2 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 TV over IP (TVoIP) werden wir mit Sicherheit nicht lange warten müssen. Bild : DTLS im Schichtenmodell und seine Bedeutung WKP: Well Known Port 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 dargestellt, können mithilfe von DTLS folgende Anwendungsprotokolle vor bösartigen Angriffen geschützt werden: SIP over DTLS Secure SIP (SIPS) Das Session Initiation Protocol (SIP) 5 wird vor allem bei VoIP als Signalisierungsprotokoll verwendet. Normalerweise nutzt 3 RFC RFC RFC

3 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 a- ber 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 draft-jennings-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-03. 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 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 6 RFC RFC

4 (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 RFC 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: 8 RFC RFC RFC RFC

5 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 ). 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 ). 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 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: 12 Eine TLS-Verbindung stellt eine gesicherte TCP-Verbindung dar. 5

6 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 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? Struktur einer Cipher Suite Während einer Handshake-Phase (Bild ), 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 dargestellte Struktur. 6

7 Bild : 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 ). 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 Bits an. Zur Berechnung der an die transportierten Nachrichten eines Anwendungsprotokolls angehängten Prüffolge MAC (Message Authentication Code) wird noch der Algorithmus Hash-based 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. 13 nach Bailey Whitfield Diffie und Martin E. Hellman 14 Eine Auflistung aller bei IANA registrierten Cipher Suites findet man unter 7

8 Komponenten von DTLS DTLS ist das an die Besonderheiten des Datagrammdienstes angepasste Protokoll TLS. Daher enthält DTLS die gleichen Funktionskomponenten wie TLS. Bild zeigt diese Komponenten im Schichtenmodell und bringt zum Ausdruck, welche von ihnen bei TLS geändert wurden und damit DTLS-spezifisch sind. Bild : DTLS-Komponenten im Schichtenmodell (Datagrammdienst) 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 ). 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 und Bild ). 8

9 Alert-Protokoll wie bei TLS Dieses Protokoll wird bei DTLS zur Signalisierung von fehlerhaften Situationen in Form von Warn- und Fehlermeldungen verwendet. 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 illustriert dies. Bild : Timeout-Mechanismus bei DTLS Die erste gesendete Nachricht vom Handshake-Protokoll bei TLS und ebenso bei DTLS ist ClientHello. Als Antwort auf diese 15 Der Parameter Timeout kann als maximale Wartezeit auf eine Reaktion der Gegenseite auf eine dahin abgeschickte Nachricht angesehen werden. 9

10 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 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 keine virtuelle Verbindung aufgebaut; somit kann bei DTLS nur von einer gesicherten Session zwischen Client und Server gesprochen werden. Bild 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. Alle Nachrichten aus einem Flight können, wenn ihre gesamte Länge dies zulässt, sogar zu einem DTLS-Record (Bild ) 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 10

11 und liegt darin, dass der Server bei DTLS die Nachricht HelloVerifyRequest als Antwort auf die Nachricht ClientHello vom Client sendet und dieser antwortet auf HelloVerifyRequest vom Server erneut mit ClientHello. Bild : Verlauf des Handshake-Protokolls bei DTLS *: Optionale Nachricht 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 vergleiche hierzu Bild Wiederaufnahme einer gesicherten Session DTLS lässt zu, dass Client und Server die Prinzipien für die Sicherheit der Kommunikation zwischen ihnen auf eine bestimmte Zeit vereinbaren können also quasi eine gesicherte und inaktive Session aufbauen können und bei Bedarf diese nur wieder aufnehmen 11

12 (reaktivieren) müssen. Wie Bild zeigt, sind in einem solchen Fall nur drei Flights zu einer gesicherten, aktiven Session nötig. Bild : Wiederaufnahme einer gesicherten Session bei DTLS Bei der Wiederaufnahme einer gesicherten Session wird davon ausgegangen, dass der Server bereits den Client authentifiziert hat also er ist dem Server bekannt. Somit kann bei dieser Annahme ein DoS-Angriff seitens des Clients ausgeschlossen werden. Demzufolge verzichtet man hier auf das Cookie-Prinzip. Somit sendet der Server in Bild keine HelloVerifyRequest an den Client mehr, um ihn aufzufordern, erneut ClientHello zu senden vergleiche hierzu die Bilder und Record Layer Frames bei DTLS Struktur und Nutzung Ebenso wie TLS stellt DTLS mit dem Record Layer Protocol (Bild ) Frames zur Verfügung, um sowohl die eigenen Nachrichten als auch die Nachrichten anderer in Bild aufgelisteter Anwendungsprotokolle zu übermitteln. Ein Frame bildet eine DTLS- Datenstruktur, die als DTLS-Record bezeichnet wird. Hervorzuheben ist aber, dass jeder DTLS-Record vollständig in einem Datagramm d.h. in einem Paket eines verbindungslosen Transportprotokolls enthalten sein muss. In einem Datagramm können aber auch mehrere DTLS-Records transportiert werden

13 Literatur Abend, Ulrich; Floroiu, John; Kuthan, Jiri; Schulzrinne, Henning; Sisalem, Dorgham: SIP Security Verlag John Wiley & Sons Badach, Anatol; Hoffmann, Erwin: Technik der IP-Netze. Internet- Kommunikation in Theorie und Einsatz Hanser Fachbuchverlag , DOI: /RG Badach, Anatol: Voice over IP - Die Technik. Grundlagen, Protokolle, Anwendungen, Migration, Sicherheit Hanser Fachbuchverlag , DOI: /RG Rescorla, Eric: SSl and TLS: Building and Designing Secure Systems. November Verlag Addison-Wesley Longman Thomas, Stephen: SSL and TLS Essentials Securing the Web. April Verlag John Wiley & Sons Schulte, Heinz (Hrsg.): Protokolle und Dienste der Informationstechnologie. WEKA Verlag, siehe auch TLS, DOI: /RG Für die vollständige Darstellung siehe: Dreibändiges Loseblattwerk (Print und CD-Version) mit Update-Dienst: "Protokolle und Dienste der Informationstechnologie" Aktualisierungszyklus: 2 Monate WEKA Media, Kissing ISBN-13: , Bestell-Nr. OL9142J 13