Sicherheitsmechanismen und Sicherheitsstandards

Evren Eren, Kai-Oliver Detken VoIP Security Konzepte und Lösungen für sichere VoIP-Kommunikation ISBN-10: 3-446-41086-4 ISBN-13: 978-3-446-41086-2 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41086-2 sowie im Buchhandel 4 Sicherheitsmechanismen und Sicherheitsstandards Neben dem zuverlässigen Transportprotokoll TCP gibt es auch andere, zuverlässige Transportprotokolle wie z.B. SCTP8 oder RUDP9. Letzteres wird beispielsweise bei U- NIStim eingesetzt. Das SCTP-Protokoll als Transportprotokoll für SIP wird genauer spezi- fiziert in RFC-4168. Die Angabe des Transportprotokolls erfolgt bei SIP durch den Para- meter „transport“. Beispiel: sip:alice:secretword@atlanta.com;transport=tcp Bei der Spezifikation des SIP-Protokolls wird der Transport auf Punkt-zu-Punkt-Basis definiert, was partikulär für SIP via SSL/TLS essenziell ist (siehe Kapitel 4.2.2). Abbildung 4.3 zeigt die Aufteilung der Sicherheitsmechanismen in RFC 3261 auf unter- schiedlichen Protokollebenen: Sicherheitsmechanismen für SIP Sicherheitsmechanismen auf Sicherheitsmechnismen auf Sicherheitsmechnismen auf Anwendungsebene Transportebene Netzwerkebene HTTP Basic HTTP Basic S/MIME TLS IPsec Authentication Authentication Abbildung 4.3 SIP Security Architecture (Qui 2003) Die dargestellten Sicherheitsmechanismen sollen nun in den nächsten Kapiteln genauer beschrieben werden. 4.2.2 SIP über SSL/TLS (SIPS) SIP über SSL/TLS, verwendet zur Absicherung der SIP-Signalisierung das TLS- Protokoll10. TLS 1.0 und 1.1 sind Weiterentwicklungen von SSL. Obwohl TLS 1.0 zwar von SSL 3.0 abgeleitet wurde, ist es jedoch nicht rückwärtskompatibel zu SSL. TLS bietet Sicherheit auf Transportebene über ein verbindungsorientiertes, zuverlässiges Transport- protokoll und somit einen Übertragungskanal, der die übertragenen Daten verschlüsselt und deren Integrität sicherstellt. Da es oberhalb von TCP operiert, bietet es auch Security Associations (SA) zwischen zwei Anwendungen bzw. Geräten, welche die Wiederauf- nahme alter Verbindungen ermöglichen. Das TLS-Protokoll besteht aus mehreren Teilen: 8 SCTP: Stream Control Transmission Protocol [Rosenberg 2005] 9 RUDP: Reliable User Datagram Protocol (Version 1 [Velten 1984] und Version 2 [Partridge 1998]) 10 TLS 1.0 (Januar 1999) RFC-2246, TLS 1.0-Erweiterungen (Juni 2003) RFC-3546, TLS 1.1 (April 2006) RFC-4346 und TLS 1.1-Erweiterungen (August 2006) RFC-4366 138 4.2 Absicherung der SIP-Signalisierung Record Layer: Diese Schicht sichert die eigentliche Übertragung ab. Handshake-Protokoll: Hier werden Kommunikationsparameter wie Verschlüsse- lungs- oder Hash-Algorithmus und symmetrische Schlüssel ausgehandelt. Application-Data-Protokoll: In diesem werden die Nutzerdaten gekapselt. Bei einer TLS-Verbindung erfragt der Client beim Server ein gültiges Server-Zertifikat. Ein gültiges Zertifikat muss durch eine vertrauenswürdige CA (Certification Authority) ausgestellt sein und durch diese bestätigt werden. Durch ein gültiges Zertifikat kann der Client dem Server vertrauen und leitet nach der TLS-Aushandlungsphase die Absicherung des SIP-Datenverkehrs ein. Es wird empfohlen, dass Zertifikate, die im Authentifizie- rungsprozess empfangen werden, mit dem Root-Zertifikat geprüft werden, das im Client aufbewahrt wird. Schlägt diese Prüfung fehl, sollte dies auch als Misserfolg der Anfrage gewertet werden Der Einsatz von Zertifikaten setzt eine PKI voraus. [Rosenberg 2002] TLS bietet Vertraulichkeit und Integrität von SIP-Signalisierungsnachrichten. Dies ermög- licht den Schutz gegen Replay-Angriffe. TLS schützt in SIP-Nachrichten die sensitiven Inhalte wie SIP-URI und IP-Adresse mittels Zertifikaten und bietet integrierten Schlüssel- austausch durch gegenseitige Authentifizierung und sichere Schlüsselverteilung. Die Ci- pher Suite TLS_RSA_WITH_AES_128_CBC_SHA [Chown 2002] ist für Implementie- rungen die Minimalvoraussetzung, wenn TLS in einer SIP-Anwendung genutzt werden soll. Zur Rückwärtskompatibilität sollten Proxy-, Redirect- und Registrar-Server jedoch auch die Cipher Suite TLS_RSA_WITH_3DES_EDE_CBC_SHA unterstützen, und ande- re Cipher Suites können zusätzlich implementiert werden. Ein SIP-Client kann eine TLS-gesicherte Verbindung über den gesamten Signalisierungs- strom unter Verwendung eines sog. SIPS-URI anfordern. Verbindungen zwischen SIP- Clients, SIPS-URIs und Netzwerkinstanzen (SIP-Client, Proxy-Server, DNS-Server, Loca- tion-Server) werden durch TLS verschlüsselt. Für eine SIP-Verbindung über TLS wird in der Regel der Port 5061 verwendet. Zur Absicherung der SIP-Signalisierung setzt die SIP-Spezifikation die Verwendung von TLS für Proxies, Redirect-Server und Registrar-Server voraus, für SIP-Clients ist dies optional. Da SIP-Pakete bei der Anwendung von TLS komplett verschlüsselt werden, ist auf dem Signalisierungspfad nur eine Punkt-zu-Punkt-Absicherung (Hop-by-Hop) zwischen den einzelnen Netzkomponenten (zwischen SIP-Client und Proxy-Server oder zwischen Proxy- Servern) möglich. Jede Netzkomponente (engl. Hop) baut eine verbindungsorientierte, sichere Verbindung lediglich zur nächsten Netzkomponente auf. Die beteiligten Netzkom- ponenten könnten sonst die SIP-Nachrichten nicht interpretieren. Abbildung 4.4 stellt eine Punkt-zu-Punkt-Absicherung mit einer TLS-Verbindung dar. Man erkennt, wie das SIP-Paket vom Anrufer über zwei SIP-Proxies (Hop 2 und Hop 3) zum Angerufenen geroutet wird. Daten werden lediglich zwischen den Hops verschlüsselt – also Punkt-zu-Punkt. SIP-Header werden von den SIP-Proxies entschlüsselt und verar- beitet, sodass auch das Routing der SIP-Nachrichten problemlos ist. [Prochaska 2006] 139 4 Sicherheitsmechanismen und Sicherheitsstandards TLS hat den Nachteil, dass es eine zuverlässige, verbindungsorientierte Transportschicht wie TCP voraussetzt, und kann nicht auf unzuverlässigen, verbindungslosen Transportpro- tokollen wie UDP und somit nicht auf UDP-basierter SIP-Signalisierung angewandt wer- den. Der Einsatz von TCP als Transportprotokoll für TLS bedeutet jedoch auch, dass es für einen lokalen Outbound-Proxy oder Registrar schwierig ist, viele gleichzeitige, langlebige TLS-Verbindungen von zahlreichen SIP-Clients aufrechtzuhalten. Dadurch gerät man schneller an die Grenzen der Ressourcen, insbesondere dann, wenn rechenintensive Cipher Suites eingesetzt werden. SIP SIP SIP SIP -Proxy A SIP-Proxy B SIP SIP (Hop 2) (Hop 3) Gesichertes Paket SIP Paket im Klartext SIP SIP-Client SIP-Client (Anrufer) (Angerufene) Abbildung 4.4 Punkt-zu-Punkt-Absicherung mit TLS (Prochaska 2006) Nachteile und Schwächen bei SIP über SSL/TLS Die SIP-Spezifikation sieht zwar vor, dass ein SIP-Client eine TLS-geschützte Verbindung mithilfe eines SIPS-URI über den gesamten Signalisierungspfad anfordern kann, es kann jedoch nicht sichergestellt werden, dass TLS von allen Netzelementen bis zum Ziel einge- setzt wird. Die Anwendung muss dafür sorgen, dass SIP über SSL/TLS unter den einzel- nen Netzwerkkomponenten gezielt miteinander gekoppelt wird, da bei SIP der Transport auf Punkt-zu-Punkt-Basis und nicht über den gesamten Pfad spezifiziert ist. Es kann also nicht ausgeschlossen werden, dass dies von einem SIP-Proxy-Server absichtlich oder durch einen Fehler in der Implementierung missachtet und die Anfrage trotzdem unge- schützt weitergereicht wird. Für eine Integrität gibt es den Schwachpunkt, dass nicht überprüft werden kann, ob TLS über den gesamten Pfad oder mit den gleichen Parametern wie zu Anfang eingesetzt wird. Die Schwäche lässt sich zur Herabstufung (Downgrading) der Sicherheit ausnutzen und 140 4.2 Absicherung der SIP-Signalisierung stellt somit eine Verwundbarkeit durch einen Downgrade-Angriff11 dar, denn nachfolgen- de Proxy-Server sowie der Empfänger können diese Herabstufung der Sicherheit nicht erkennen. Eine Punkt-zu-Punkt-Absicherung schützt gegen externe Angriffe. Jedoch hat ein interner Angreifer über einen kompromittierten oder nicht vertrauenswürdigen Proxy problemlos Zugriff auf SIP-Pakete im Klartext. Er kann sie verändern oder zusätzliche SIP-Pakete einspeisen bzw. senden. Keine Integrität des Schlüsselmaterials Die fehlende Möglichkeit der Integritätsprüfung bedeutet, dass SIP über SSL/TLS nicht zur Absicherung des Schlüsselmaterials und somit für eine nachfolgende Absicherung der RTP-Nutzdaten geeignet ist.