Ver- und Entschlüsselung in VoIP-Netzen mit SIP-TLS und SRTP

Mit den Bedrohungen durch unverschlüsselte VoIP-Telefonie befasst sich das Bundesamt für Sicherheit in der Informationstechnik (BSI) in seinem Final Draft zum Baustein NET.4.2 VoIP und in den zugehörigen Umsetzungshinweisen im Community Draft NET.4.2: Das BSI empfiehlt, alle VoIP-Pakete zu verschlüsseln, die das geschützte LAN verlassen; bei besonders hohem Schutzbedarf oder im Fall eines Betreibermodells – wenn also Dritte das Netz managen – kann eine Verschlüsselung auch im Intranet notwendig sein.

Ein Mitlesen der Signalisierungsdaten auf dem Transportweg ist bei unverschlüsseltem SIP (zu diesem und anderen Fachbegriffen siehe Glossar) im Klartext möglich (siehe Abbildung 4 für Anruf von *20 nach 25). Jedoch kann es je nach Schutzbedarf notwendig sein, dass kein Dritter Zugriff auf diese Metadaten erhält. Als Gegenmaßnahme kann eine Transportverschlüsselung dienen. Hierfür ist SIP mit Transport Layer Security (SIPS) oder eine Verschlüsselung mittels IPsec denkbar. SIP in Verbindung mit TLS funktioniert jedoch nur über TCP, das unter anderem wegen des Drei-Wege-Handshake beim Verbindungsaufbau und zusätzlicher Steuerungsdaten eine etwas höhere Latenz im Vergleich zu UDP mit sich bringt.

Anstelle der beiden genannten Verschlüsselungsmethoden könnten auch andere VPN-Varianten wie OpenVPN zum Einsatz kommen – je nachdem, welche die jeweils eingesetzten Telefone oder andere Endgeräte sowie die zentralen VoIP-Systeme beherrschen. Ob mit IPsec oder einer Alternative realisiert: Eine Transportverschlüsselung kann sinnvoll nur im eigenen Zuständigkeitsbereich (LAN/WAN) oder in enger Zusammenarbeit mit externen Partnern zum Einsatz kommen. Jede Gegenstelle erfordert zwingend eine Abstimmung aller Parameter: IKE-Version, Hashing-Algorithmus, Verschlüsselung, PSK oder Zertifikat zur Authentifizierung et cetera. Der Vorteil von IPsec oder anderen VPNs besteht darin, dass sie auch die Sprachdaten verschlüsseln. Dabei ist zwischen Tunneln einzelner Endgeräte und Systeme (Transport Mode) sowie solchen zwischen den Netzen ganzer Standorte (Tunnel Mode) zu unterscheiden. 

Langwieriger Tunnelbau

Bei einer direkten verschlüsselten Kopplung zwischen Endgeräten müsste immer erst der komplette Tunnelaufbau stattfinden, was den Verbindungsaufbau erheblich verzögern würde. Zunächst müsste der Tunnel zwischen Telefon und Signalisierungs-/SIP-Proxy existieren. Erst wenn die Ziel-IP-Adresse für den Sprachdatenstrom durch den SIP-Proxy im Session Description Protocol benannt wurde, kann ein zweiter Tunnel zwischen den beiden Endgeräten für den Sprachdatenstrom aufgebaut werden. Diese Variante kommt daher meist nicht zum Einsatz. 

Bei der Standortvernetzung auf Basis eines IPsec-VPN schützt der Tunnel lediglich einen Teil der Kommunikationsbeziehung, besteht aber normalerweise bereits, bevor die Signalisierungs- und Sprach­daten fließen – eine sinnvolle und häufig genutzte Variante in internen Netzen. Ein weiterer Vorteil von IPsec: Damit lassen sich auch andere Signalisierungsproto­kolle verwenden, etwa H.323, MGCP oder proprietäre Verfahren. Bei den großen Providern gibt es derzeit jedoch keine VoIP-Telefonanschlüsse (SIP-Trunks) auf Basis von IPsec zur Anbindung des öffentlichen Telefonnetzes.

Dieselben Herausforderungen wie bei den Signalisierungsdaten (von Datenschutzrechtlern als Metadaten bezeichnet) stellen sich bei der Sprachdatenübertragung über das UDP-basierte Real-Time Transport Protocol (RTP): Die Sprach­daten sind zunächst unverschlüsselt. Somit könnten personenbezogene oder andere vertrauliche Daten die Organisation ungeschützt verlassen und in die Hände Dritter gelangen. Für eine verschlüsselte Übertragung kann das Secure Real-Time Transport Protocol (SRTP, RFC 3711) zum Einsatz kommen. Sinnvoll ist dies bei einem Einsatz von Session Description Protocol Security Descriptions (SDES) zum Schlüsselaustausch nur in Kombination mit einer TLS-geschützten SIP-Verbindung oder einem VPN, da der Key Exchange für SRTP im Klartext im Header des Session Description Protocol (SDP) stattfindet (Abbildung 3).

Dies ist das älteste und meistverwendete Verfahren für den SRTP-Schlüssel­austausch und auch bei großen deutschen Providern im Einsatz. Eine Vertrauensstellung muss gegenüber allen SIP-Proxys auf dem gesamten Transportweg bestehen, da die Master Keys dort im Klartext lesbar sind. Der SDP-Header als Teil von SIP-Nachrichten dient zum Beispiel der Codec-Aushandlung für die Sprachdaten und dem Austausch für Verbindungsinformationen der RTP-Daten.

Als Alternative zur Klartextübertragung des Master Key für SDES könnte die in RFC 5764 beschriebene Übertragung der Schlüssel über einen UDP-basierten Tunnel gemäß Datagram Transport Layer Security (DTLS) dienen. Diese Variante ist jedoch noch nicht weit verbreitet. DTLS kommt nicht direkt für den Schutz der UDP-basierten RTP-­Pakete, sondern lediglich für den Schlüsselaustausch zum Einsatz, denn DTLS ist nicht für die Übertragung von RTP-­Daten optimiert.

Bei dieser Variante kann der Schlüssel­austausch direkt zwischen denjenigen Endgeräten und Systemen stattfinden, die Sprachdaten übertragen – etwa zwei Tele­fonen, die anschließend SRTP Ende-zu-­Ende nutzen sollen, oder einem Telefon und einem SRTP-Proxy beim Provider. In letzterem Fall kann der Kunde die verschlüsselte SRTP-Übertragung nur bis zum Provider sicherstellen. Die weitere Verschlüsselung der Sprachdaten liegt in dessen Zuständigkeitsbereich. Die Master Keys wären bei dieser Variante somit nicht mehr im SIP-Signalisierungspfad sichtbar.