Die Sprachdatenübertragung und die zugehörige Signalisierung über IP-basierte Netze erfolgt meist ungesichert und birgt daher Gefahren. Ohne eine Konfiguration von Schutzmaßnahmen liegen die Daten nämlich allen Beteiligten auf dem Transportweg im Klartext vor. Selbst im lokalen Netz können Angreifer ohne passende Schutzmaßnahmen auf der Gegenseite an die gewünschten Informationen gelangen. Bei einem entsprechenden Zugang zum Netz können potenzielle Angreifer die Sprachdaten ohne spezielle Kenntnisse und mit frei verfügbaren Tools wie Wireshark mitlesen und wiedergeben. Unberechtigte Dritte haben damit die Möglichkeit, laufende Gespräche abzuhören und mitzuschneiden. Dies hat eine hohe Relevanz für den Datenschutz wie auch bezüglich der Einhaltung des "Rechts am gesprochenen Wort".

Angreifer könnten zudem die Metadaten der Signalisierung wie beispielsweis e die Quell- und Zielrufnummern sowie gegebenenfalls auch Namen auswerten. Aus diesen Daten lassen sich bei entsprechender Aufbereitung Kommunikationsmuster der Nutzer ableiten. Aber auch ungewünschte Gesprächsbeendigungen durch Attacken oder von Angreifern provozierte Überlastungen bis hin zur Quittierung des Telefondiensts, sogenanntes Denial of Service (DoS), bergen Risiken. Die TLS-Verschlüsselung ist dabei auch sinnvoll, um die in RFC 3261 erläuterte SIP-Digest-Authentifizierung mit relativ schwachen MD5-Hashes zusätzlich abzusichern. Nicht zuletzt birgt der Missbrauch der Signalisierung die Gefahr des Gebührenbetrugs.

Das TLS-Protokoll verschlüsselt bei SIP-TLS zunächst nur die Signalisierung. SIP-TLS arbeitet grundsätzlich "Hop by Hop". Dies bedeutet, dass die Verschlüsselung zunächst nur bis zum nächsten SIP-Proxy sichergestellt ist. Dieser nächste SIP-Proxy kann die Daten entschlüsseln und eine Weiterleitungsentscheidung auf Basis der Signalisierungsinformationen im Klartext treffen. Dies wird als Call-Routing bezeichnet. Ein konkretes Beispiel für eine solche Implementierung stellt ein SIP-Trunk dar. Darunter ist eine gebündelte Verbindung mehrerer SIP-Kanäle mit SIP-TLS zu verstehen, wie bespielsweise zu einem öffentlichen Provider oder intern zwischen unterschiedlichen SIP-Servern.

Über SIP-TLS ließe sich bei einem öffentlichen SIP-Trunk sicherstellen, dass die Übertragung der Signalisierungsdaten zwischen dem internen Telekommunikationssystem (der sogenannten IP-PBX) oder einem Enterprise Session Border Controller (E-SBC) und dem Provider verschlüsselt stattfindet. Jedoch bedeutet dies nicht zwangsläufig, dass die Verbindung bis zum Ziel verschlüsselt ist. Etwas weiter bringt es SIP-TLS in Kombination mit dem sogenannten SIPS-URI-Schema. Dabei nutzt es eine Verschlüsselung bis zur Zieldomäne. Innerhalb der Domäne besteht jedoch selbst bei dieser Variante keinerlei Kontrolle darüber, ob die Weiterleitung mit oder ohne Verschlüsselung erfolgt.

SIP-TLS baut zwingend auf das Transportprotokoll TCP auf. Dies liegt daran, dass klassisches TLS selbst nur in Kombination mit dem Transportprotokoll TCP funktioniert. Dabei kommt es zu einer minimal erhöhten Latenz im Vergleich zu UDP aufgrund des initialen Verbindungsaufbaus durch den Drei-Wege-Handshake (SYN, SYN/ACK, ACK). Der TLS-Handshake findet erst danach statt, was aufgrund der sequentiellen Abarbeitung zu zusätzlicher Latenz führt.

Bei SIP-TLS kommt in den meisten Fällen der TCP-Port 5061 zur Anwendung. Die Authentifizierung kann grundsätzlich entweder rein serverbasiert (über einen SIP-Proxy) oder gegenseitig zwischen Client und Server (Mutual TLS) erfolgen. Bei einer rein serverbasierten Authentifizierung braucht es ein valides X.509-Zertifikat auf dem Server, bei Mutual TLS auf dem Client und dem Server. Mutual TLS erhöht den Implementierungsaufwand, aber auch die Sicherheit. Server können beispielsweise SIP-Registrare, SIP-Proxies oder SBCs sein.

Konkrete Beispiele liefern öffentliche SIP-Trunks auf Basis der Empfehlung SIPconnect 2.0, an der Hersteller und Provider von VoIP-Systemen mitgeschrieben haben. Darin ist spezifiziert, dass bei einem registrierten SIP-Trunk eine serverbasierte Authentifizierung ausreicht. Bei einem statisch konfigurierten SIP-Trunk bedarf es gegenseitiger Client-/Server-Authentifizierungen, da sowohl Kunde als auch Provider die Verbindung initiieren können.

Der Einsatz von TLS für die Signalisierung mit SIP-TLS birgt jedoch auch diverse Herausforderungen. Einen zentralen Punkt stellen dabei die benötigten Zertifikate inklusive der Abhängigkeiten von Infrastrukturdiensten wie DNS und NTP dar. Zunächst müssen wir jedoch differenzieren, ob SIP-TLS am öffentlichen SIP-Trunk oder intern von IP-Telefonen zur IP-PBX (Private Branch Exchange) zum Einsatz kommen soll.

Beginnen wir mit dem öffentlichen SIP-Trunk. Damit Sie dort SIP-TLS verwenden können, benötigt der Provider gemäß SIPconnect 2.0 im Registrierungsmodus ein oder mehrere Serverauthentifizierungszertifikate für die Provider Edge SBCs, also die Gegenstellen der IP-PBX oder dem Enterprise Session Border Controller des Kunden. E-SBC oder IP-PBX benötigen – je nachdem, welche Komponente auf Kundenseite die SIP-Registrierung vornimmt – das zugehörige Stammzertifikat der Zertifizierungsstelle, mit dem Serverzertifikate des Providers signiert wurden. Dieses muss der Provider bekanntgeben.

Im weiteren Verlauf bedarf es einer Klärung der unterstützten TLS-Versionen, Cipher und Hash-Algorithmen des Providers und der Kundenkomponente in Abstimmung mit Empfehlungen des Bundesamts für Sicherheit in der Informationstechnik (BSI). Zusätzlich muss der Provider angeben, unter welchem TCP-Port er den SIP-TLS-Dienst anbietet. Erst auf dieser Basis kann der Systemintegrator die Kundenkomponente entsprechend für SIP-TLS parametrisieren.

Falls es sich um einen statischen SIP-Trunk gemäß SIPconnect 2.0 handelt, bedarf es sowohl auf Provider- als auch auf Kundenseite eines Zertifikats mit erweiterter Schlüsselverwendung für Server- und Clientauthentifizierung. Das Kundenzertifikat muss von einer Stammzertifizierungsstelle des Providers beziehungsweise einer für beide Seiten vertrauenswürdigen Certificate Authority (CA) stammen. Zudem ist ein sicherer Transportweg für die Übergabe zum Kunden erforderlich.

Damit das Zertifikat vertrauenswürdig ist, bedarf es auch passender Inhalte: Unter anderem muss das CN-Attribut und gegebenenfalls das SAN-Attribut (Subject Alternative Name) mit dem vollqualifizierten DNS-Hostnamen (FQDN) oder der IP-Adresse des Provider Edge SBC übereinstimmen. Das hängt davon ab, ob der SIP-Trunk mit oder ohne Namensauflösung arbeitet. Es müssen also auch die DNS-Server korrekt arbeiten und korrekte Antworten liefern. Das Zertifikat muss zudem gültig und darf nicht widerrufen worden sein. Dafür müssen sowohl die Provider Edge SBCs als auch die E-SBCs oder die IP-PBXen per NTP auf die valide Zeit synchronisiert sein.

Den Widerruf prüft der Client der TLS-Verbindung, also meist der E-SBC, anhand einer Zertifikatssperrliste (CRL) oder direkt online per OCSP (Online Certificate Status Protocol). Dafür muss entweder die Sperrliste gültig und gecacht oder einer der Webserver für die Sperrlisten muss für den E-SBC erreichbar sein.

Beim internen Einsatz von SIP-TLS, also der Kommunikation von IP-Telefonen zu einer IP-PBX, fällt der Aufwand für die Zertifikatsverteilung je nach Größe der Umgebung ungleich größer aus. Im einfachsten Fall authentifiziert das IP-Telefon beim TLS-Handshake für SIP-TLS lediglich die IP-PBX anhand des Zertifikatsinhalts. Dafür benötigt jedes IP-Telefon das Stammzertifikat der CA, die das SIP-TLS-Zertifikat der IP-PBX signiert hat. Dafür gibt es unterschiedliche Verfahren. Beispielsweise gibt es Hersteller, die auf eine vorbereitete Vertrauensstellung über Herstellerzertifikate zwischen IP-Telefon und IP-PBX setzen. Über diese vertrauenswürdige Verbindung kann dann auch eine signierte Übertragung der kundeneigenen Zertifikate stattfinden, wie beispielsweise die Verteilung eigener CA-Zertifikate.

Viele Hersteller implementieren inzwischen Zertifizierungsstellen in ihre Produkte oder Managementsysteme, um dies abbilden zu können. Im sichersten Fall generiert das IP-Telefon einen privaten Schlüssel lokal und einen Certificate Signing Request (CSR) mit dem öffentlichen Schlüssel. Der private Schlüssel bleibt immer lokal auf dem Telefon. Diese Anfrage sendet das Gerät über die signierte Verbindung an die IP-PBX, die den CSR ausführt und als signierten öffentlichen Schlüssel an das IP-Telefon zurücksendet, wie beispielsweise beim Simple Certificate Enrollment Protocol (SCEP).

Andere Hersteller generieren das Zertifikat komplett auf der Zertifizierungsstelle in der IP-PBX und übermitteln dieses dann über die initiale Vertrauensstellung. Der Administrator muss klären, ob die initiale Vertrauensstellung auf Basis der Herstellerzertifikate für den bestehenden Schutzbedarf ausreicht. Ansonsten muss er prüfen, welche Out-of-band-Mechanismen die IP-Telefone unterstützen. Dies können verschlüsselte Konfigurationsdateien in Kombination mit Einmalkennwörtern zur Entschlüsselung oder im Extremfall sogar Importe per Handarbeit auf Basis von Zertifikaten auf USB-Sticks sein.

Auch die Nutzdaten, also Sprache und Video über das UDP-basierte RTP, stehen Angreifern im Normalfall zunächst unverschlüsselt bereit. Somit könnten firmeninterne sowie personenbezogene Daten in den Gesprächsinhalten die jeweiligen Organisationen ungeschützt verlassen. Wenn Sprachdaten mitgeschnitten wurden, ist es mit Tools wie Wireshark sehr einfach möglich, den Gesprächsinhalt wiederzugeben. Dafür bringt es einen RTP-Player mit, der eine Vielzahl an Codecs unterstützt.

Einen weiteren Angriffsvektor stellt die Injektion von Sprachdaten dar. Über offensive Tools wie rtpinsertsound besteht die Möglichkeit, Sprachdaten aus einer bestehenden Audiodatei in ein VoIP-Gespräch zu injizieren. Ein Mitlesen der Signalisierung ist hierfür jedoch zunächst erforderlich. Im Anschluss identifiziert der Angreifer die IP-Adressen und Ports für die RTP-/Sprachdaten der Kommunikationsbeziehung auf Basis der SDP-Inhalte innerhalb der SIP-Signalisierung. Nun kann er zuvor aufgezeichnete Sprachdaten mit Stille oder einem "Ja" beziehungsweise "Nein" auf gewisse Fragen in einem Telefonat in den RTP-Datenstrom einspielen. Durch eingespielte Stille kann der Angreifer Gesprächsinhalte unterdrücken oder die Übertragung stören.

Um eine verschlüsselte Übertragung zu ermöglichen, kann das bereits seit 2004 existierende und in RFC 3711 beschriebene SRTP (Secure Real-Time Transport Protocol) zum Einsatz kommen. Der Standard bietet Vertraulichkeit, Integrität und Schutz vor Replay-Attacken, also der Wiederholung valider Nachrichten. Hierfür nutzt SRTP eine symmetrische Verschlüsselung. Konkret wird dabei über eine Ableitungsfunktion von einem Master Key und einem Master Salt ein eindeutiger Session Key erzeugt. SRTP bringt jedoch selbst kein Schlüsselmanagement mit und ist somit von externen Verfahren abhängig, um symmetrische Schlüssel zu erzeugen und zu verteilen. Diese stellen wir im weiteren Verlauf des Artikels vor.

Für die Verschlüsselung kommt AES im Counter Mode (AES-CM) zum Einsatz. Die Standardschlüssellänge sollte bei Aushandlung 128 Bit betragen. Gleiches gilt für das Hashing-Verfahren HMAC-SHA1 mit 80 Bit zur Sicherstellung der Integrität. Um den Master Key und den Master Salt zu verteilen, gibt es unterschiedliche Verfahren: MIKEY, ZRTP, SDES und DTLS-SRTP. Nicht jeder Hersteller unterstützt jedoch jedes Verfahren und jedes bringt eigene Vor- und Nachteile mit sich. In Unternehmen und Behörden kommen meist die Security Descriptions for Media Streams (SDES) zum Einsatz, in neueren Implementierungen zunehmend auch DTLS-SRTP (DTLS steht für Datagram Transport Layer Security). Wir beschränken uns daher auf diese.

Die im RFC 4568 definierten SDES erweitern das Session Description Protocol (SDP) um eine Übertragung im SIP-Body. Ein neues Crypto-Attribut im SDP überträgt den Master Key, den Master Salt und die unterstützten Algorithmen. Wie im klassischen unverschlüsselten SDP verwendet SDES das Offer/Answer-Prinzip, bei dem sich die Beteiligten auf die entsprechenden Parameter einigen – in diesem Fall die Kryptoalgorithmen. Den Einsatz von SDES erkennen Sie im SDP in der sogenannten m-Line anhand des "S" in RTP/SAVP anstatt RTP/AVP bei unverschlüsselten Mediendaten. SDES unterstützt gemäß RFC 6188 auch Schlüssellängen bis zu 256 Bit für SRTP.

Öffentliche Provider können meist nur mit SDES umgehen. Hierbei ist darauf zu achten, dass die SDES zum Schlüsselaustausch nur in Kombination mit einer TLS-verschlüsselten SIP- oder einer verschlüsselten IPsec-VPN-Kommunikation für die Signalisierung Sinn ergeben, da der Key Exchange für SRTP im SDP im Klartext stattfindet. Alle SIP-Proxys auf dem gesamten Transportweg können die Master Keys und Salts im Klartext lesen.

Die Datagram Transport Layer Security (DTLS) stellt das UDP-basierende Pendant zu TLS dar. Es handelt sich dabei also um eine Transportverschlüsselung, die auf X.509-Zertifikaten aufbaut, um die Schlüssel und Algorithmen für SRTP auszutauschen. Die Übertragung der Nutzdaten findet jedoch nicht über DTLS statt. Diese wurde im RFC 5764 für den Austausch der Schlüssel für SRTP erweitert, um eine Ende-zu-Ende-Aushandlung der symmetrischen SRTP-Schlüssel zu erreichen.

IIm Gegensatz zu der vorgenannten Managementmethode erfolgt der Austausch im Medienpfad und nicht innerhalb der Signalisierung. Die Aushandlung, welcher Kommunikationspartner DTLS-Server und welcher Client ist, erfolgt über das SDP. Der Client der DTLS-Session verpackt in seinem Client-Hello eine "use_ srtp"-Erweiterung und tauscht in diesem dann die verwendeten Algorithmen wie "SRTP_AES128_CM_HMAC_ SHA1_80" und "SRTP_AES128_CM_ HMAC_ SHA1_32" für SRTP aus.

Eine sogenannte Key-Exporter-Funktion (RFC 5705) bietet dann den Export der DTLS-Schlüssel an das SRTP-Protokoll für die Verwendung in der Verschlüsselung. Die Endgeräte können selbstsignierte X.509-Zertifikate nutzen, da das Protokoll nur den Fingerprint aus dem öffentlichen Teil des Zertifikats als Vertrauensstellung benötigt. Im Feld "Subject Alternative Name" sollte für das Troubleshooting noch die jeweilige SIP-URI enthalten sein; diese Angabe ist jedoch nicht verpflichtend. Die Endpunkte übertragen den zuvor genannten Fingerprint im SDP der SIP-Signalisierung als Authentifizierung.

Falls der Fingerprint aus dem SDP und der ausgetauschte Fingerprint während des DTLS-Handshakes nicht übereinstimmen, bricht die Aushandlung ab. Die SIP-Proxys auf dem Transportweg haben jedoch bei diesem Verfahren keinerlei Informationen über die verwendeten Schlüssel, sondern verfügen nur noch über den Fingerprint zur Authentifizierung des Schlüsselmanagementverfahrens über DTLS. Aktuell ist in den Algorithmen über DTLS jedoch nur AES bis 128 Bit standardisiert.

Der Einsatz von SRTP bedarf einer Festlegung, ob SRTP obligatorisch oder optional ist. Falls eine Gegenstelle zwingend SRTP verlangt, die andere Gegenstelle dies jedoch nicht unterstützt, kommt es zu einer Fehlermeldung in der SIP-Signalisierung, konkret "488 Not acceptable here". Zudem sei erwähnt, dass die Faxübertragung über T.38 kein SRTP unterstützt. Eine größere Herausforderung ist zu klären, welche Key-Management-Verfahren und Algorithmen die Provider und IP-PBXen sowie E-SBC-Hersteller unterstützen. Grundsätzlich bleibt festzuhalten, dass dies die Komplexität das Troubleshooting zwangsläufig erhöht.

Da es sich bei SIP-TLS um eine "Hop-by-Hop"-Verschlüsselung handelt, liegen die Daten an den Signalisierungspunkten wie der IP-PBX oder dem E-SBC im Klartext vor. Stellen diese Komponenten also Analysemöglichkeiten bereit, braucht es im Normalfall keines gesonderten Paketmittschnitts im Netzwerk. Es gilt jedoch zu beachten, dass vor Erstellung eines Mitschnitts und dessen Auswertung gegebenenfalls betriebliche oder organisatorische Regelungen wie die Einbeziehung eines Betriebs- oder Personalrats greifen.

Falls keine andere Analysemöglichkeit bereitsteht, bedarf es einer Aufzeichnung der Signalisierungs- und Sprachdaten, wie beispielsweise in Form des PCAPng-Formats für Wireshark. Der initiale TLS-Handshake muss zwingend vorliegen, um die verschlüsselten Daten später entschlüsseln zu können. Dies ist durch das Leistungsmerkmal "TLS Session Resumption", also die Wiederaufnahme einer vorherigen TLS-Sitzung, häufig erschwert. In einigen Fällen bedarf es eines Neustarts von Diensten oder der gesamten Komponente, um einen neuen TLS-Handshake ohne Session Resumption zu erzwingen.

Falls DHE Cipher Suites mit Perfect Forward Secrecy zur Anwendung kommen, müssen Sie auf die sogenannte Session-Key-Methode auf dem Client oder Server zur TLS-Entschlüsselung zurückgreifen. Die vorherige Variante der TLS-Entschlüsselung auf Basis des Private Keys ist dann nicht mehr möglich. Daher gehen wir in unserem Artikel darauf nicht weiter ein. Die Session-Key-Methode setzt eine sogenannte Keylog-Textdatei voraus.

Das Erzeugen und Befüllen dieser Datei übernehmen unterschiedliche Krypto-Bibliotheken wie beispielsweise OpenSSL oder NSS. Darauf aufbauende Applikationen wie Softphones oder SIP-Prozesse in E-SBC oder IP-PBX, aber auch Browser wie Mozilla Firefox oder Google Chrome generieren diese Datei, wenn die Umgebungsvariable "SSLKEYLOGFILE" gesetzt ist: unter macOS beispielsweise mittels export SSLKEYLOGFILE="/Users/<Username>/Desktop/sslkeyfile".

Die Bibliotheken schreiben den Pre-Master Key dann entsprechend in die in der Umgebungsvariable referenzierte Datei. Der Client generiert diesen in der Client Exchange Phase des TLS Handshakes. Der Export kann auf Client- oder Serverseite stattfinden. Ein Mitlesen auf dem Transportweg ist somit nicht möglich. Wireshark kann den Pre-Master Key aus dem Handshake nutzen, um den Master Key abzuleiten und folglich den Datenverkehr zu entschlüsseln.

Im Anschluss an die Konfiguration der Umgebungsvariable starten Sie den Mitschnitt in Wireshark und öffnen dann über die Konsole beispielsweise die Softphone-Applikation. Unter macOS gelingt dies über "Open / Applications / Telefon.app". Nachdem nun der Aufbau der ersten TLS-verschlüsselten Verbindung stattgefunden hat, können Sie überprüfen, ob die entsprechende Datei angelegt wurde und die Schlüssel enthalten sind. In der ersten Zeile der Datei erkennen Sie auch die Generierung über die Bibliothek NSS. Damit Wireshark die Datei mit den entsprechenden Schlüsseln zur Entschlüsselung heranzieht, müssen Sie diese als "(Pre)-Master-Secret log filename" unter "Preferences / Protocols / TLS" referenzieren. Nachdem der TLS Dissector in Wireshark die Entschlüsselung vorgenommen hat, können Sie die entschlüsselten Daten erkennen.

Nun lassen sich trotz verschlüsselter Signalisierung darin enthaltene Fehler wie beispielsweise ein Codec-Mismatch ausmachen. Dies bedeutet, dass die Gegenstelle A die Sprachdaten inkompatibel zur Gegenstelle B codiert und Gegenstelle B diese daher nicht korrekt verarbeiten kann. Aber auch falsche Verbindungsinformationen im SDP-Header wie beispielsweise in NAT-Szenarien fallen nun auf. Dies könnte dazu führen, dass ein Telefon klingelt und der Benutzer den Hörer abhebt, jedoch keine Stimme zu hören ist. Viele Anwender kennen dieses Fehlverhalten mittlerweile. Durch die Entschlüsselung bietet sich nun auch die Möglichkeit, anhand der SIP-Request-Line sowie der From- und To-Header hilfreiche Informationen wie etwa Quelle und Ziel eines Anrufs zu erkennen.

Auf Basis einer mittels SIP-TLS verschlüsselten Signalisierung kann innerhalb des SIP Message Body – konkret dem SDP – ein geschützter Austausch der SDES erfolgen. Zunächst findet hierbei eine Übertragung des Master Key und des Master Salt statt. SRTP leitet alle weiteren Schlüssel von diesem Master Key und Salt ab.

SRTP ist gegenüber RTP im SDP-Inhalt in der m-Line an einem zusätzlichen "S", also RTP/SAVP anstatt RTP/AVP, in der Media Description erkennbar. Zusätzlich sehen Sie die Crypto-Attribute. Um den SRTP-Stream gemäß SDES zu entschlüsseln, müssen Sie in Wireshark zunächst den SRTP-Stream einer Kommunikationsrichtung filtern und exportieren. Dies ist je nach aufgezeichneten Daten entweder über den Displayfilter "rtp && ip.src_host == <Quell-IP-Adresse>" oder bei mehreren aufgezeichneten Gesprächen der Quell-IP-Adresse durch den eindeutigen Synchronisation Source Identifier des SRTP-Streams möglich. Dieser dient der eindeutigen Identifizierung des SRTP-Streams. Hierfür ist es möglich, den Display-Filter "rtp.ssrc == <SSRC> && ip.src_host == <Quell-IP-Adresse> zu nutzen.

Nachdem der Displayfilter aktiviert ist, kann ein Export des SRTP-Streams über das Menü "File/Export Specified Packets" erfolgen. Hierbei ist darauf zu achten, dass Sie die PCAP-Dateierweiterung und nicht PCAPNG verwenden, da einige SRTP-Decrypter mit letzterem Format Probleme haben. Da das nun vorliegende PCAP-File nur noch SRTP-Daten enthält, kann Wireshark diese aufgrund der dynamischen UDP-Port-Zuweisung nicht mehr als solche erkennen. Die korrekte Darstellung ist über einen Rechtsklick auf ein SRTP-Datagramm, anschließend "Decode as" und dann über die Auswahl von RTP als Zielprotokoll möglich.

Im Anschluss ist es mit einem SRTP-Entschlüsselungstool, dem Master Key/Salt und der PCAP-Datei mit den SRTP-Daten möglich, die Sprachdaten zu entschlüsseln. Hierfür kopieren Sie den Master Key und Salt für eine Base64-Formatierung des Schlüssels per Rechtsklick auf Master Key und Salt sowie "Copy as Printable Text", damit er für die folgende Entschlüsselung bereitsteht. Zum Entschlüsseln können beispielsweise das CLI-Tool "cisco/libsrtp" und das Skript "rtp_ decoder" zum Einsatz kommen.

Je nach Verschlüsselungsvariante variieren die Optionen zur Entschlüsselung, die Dokumentation steht ebenfalls auf GitHub bereit. Das CLI-Tool kopiert einen Dump der entschlüsselten Daten in die Zieldatei, die Sie als "Hex Dump" in Wireshark importieren können. Damit Wireshark diese dann wieder als RTP erkennt, bedarf es, wie bereits zuvor benannt, erneut der "Decode_as"-Funktion. Im Anschluss lassen sich sowohl RTP Statistiken als auch Gesprächsinhalte und Pegel über den RTP-Player auswerten.

Da SRTP nur die Nutzdaten verschlüsselt, stehen Headerdaten wie SSRC und Sequenznummern auch in verschlüsselten SRTP-Paketen im Klartext zur Verfügung. Somit besteht bereits ohne Entschlüsselung die Möglichkeit einer statistischen Auswertung und Erkennung von Verzögerungen, Jitter oder Paketverlusten. Dazu bedarf es ebenfalls der "Decode_as"-Funktion in Wireshark.

Obwohl die Standards für die Verschlüsselung von SIP und RTP bereits einige Jahre existieren, wächst erst in den letzten Jahren die Nachfrage nach einer chiffrierten Übertragung. In öffentlichen Netzen findet die Verschlüsselung von SIP über SIP-TLS und RTP über SRTP nur bis zum ersten Hop, also dem Provider, statt. Ob darüber hinaus eine Verschlüsselung erfolgt, entzieht sich der Kenntnis des Endnutzers. Zudem bedarf es hierfür einiger Abstimmungen mit den Providern. Allerdings löst die Verschlüsselung auch mehrere Herausforderungen. So verringert sie auch das Risiko von Spoofing und Man-in-the-Middle-Angriffen sowie das Risiko einer Denial-of-Service-Attacke.