Verschlüsselung und Einsatz von Zertifikaten im VoIP-Umfeld

Grundlegende Maßnahme zur Absicherung: Authentisierung

Moderne Kommunikationssysteme bestehen in der Regel aus Server- und Client-Komponenten. Die Server-Komponenten stellen die Dienste bereit und bilden nicht selten eine komplexe Systemlandschaft. Die Administration und Konfiguration der zentralen Komponenten ist daher ebenso komplex und sollte nur durch entsprechend berechtigte Personen vorgenommen werden. Hierzu bedarf es eines Rollen- und Rechtekonzeptes, in dem sowohl Rollen wie „Administrator“, „Super-Administrator“ sowie „Nutzer“ als auch die zugehörigen Berechtigungen definiert werden. Die Berechtigungen sind dabei nach dem „Need-to-know“-Prinzip zuzuweisen und auf den benötigten Umfang zu beschränken. Für die Ausübung der jeweiligen Rolle sollten nur die notwendigen Rechte erteilt werden. Darüber hinaus müssen die definierten Rechte auch innerhalb der Kommunikationslösung konfigurierbar sein, sodass sich die Rechte für die Administratoren gemäß vorher festgelegtem Konzept einschränken lassen. Die Client-Komponenten können entweder dedizierte Endgeräte sein oder als Software auf Standardgeräten wie Smartphones, PCs und Laptops installiert werden. Auch hier ist das Rollen- und Berechtigungskonzept umzusetzen. Insbesondere sollten die Nutzer nur notwendige Berechtigungen zur Konfiguration von Endgeräten und Clientsoftware erhalten. Hierzu zählen beispielsweise die Konfiguration von Lautstärke, Klingelton und weitere nutzerspezifische Einstellungen. Weitergehende Konfigurationen wie Routing, Angaben zu Registrierungsservern und ähnliche Einstellungen dürfen hingegen nicht durch die Nutzer verändert werden.

Als Voraussetzung für die Umsetzung eines Berechtigungskonzeptes wird zudem eine entsprechende Authentisierung von Clients und Servern benötigt. Hierbei sind folgende Bereiche zu unterscheiden:

• Authentisierung der Nutzer am Client / Endgerät

Die Nutzer sollten sich mindestens mittels Nutzernamen und zugehöriger Passwörter am Client oder genutzten Endgerät authentisieren. Vielfach kann bei Softclients auf Smartphones und PCs auf die Nutzung von Single Sign-on zurückgegriffen werden, das heißt, dass mit der Anmeldung eines Nutzers am zugehörigen Betriebssystem auch die Anmeldung am Softclient erfolgt. Zudem kann bei Nutzung einer Multi-Faktor-Authentisierung (MFA) ein hohes Sicherheitsniveau erzielt werden. Als zweiter Faktor wird häufig ein Token verwendet, das mithilfe einer zusätzlichen App auf dem Smartphone generiert wird. Bei Endgeräten kommt oftmals nur die Authentisierung mittels einer PIN zum Einsatz.

• Authentisierung des Endgerätes am internen IP-Netzwerk

Das genutzte Endgerät, also entweder ein IP-Telefon, ein PC/Laptop oder auch ein Videokonferenzgerät, sollte sich im Rahmen der Umsetzung von Network Access Control (NAC) am IP-Netzwerk der Institution authentisieren. Hierbei werden zunehmend Zertifikate eingesetzt, die sicherstellen, dass nur berechtigte Endgeräte Zugriff auf das IP-Netzwerk haben.

• Authentisierung von Client / Endgerät am Server

Die Clients und Endgeräte sollten sich an den zentralen Servern authentisieren, um zu gewährleisten, dass ein Zugriff auf Daten und Dienste ausschließlich von berechtigten Endpunkten aus erfolgt. Darüber hinaus sorgt eine Authentisierung des Clients dafür, dass Kommunikationsflüsse zu den richtigen Endpunkten gelangen.

Umgekehrt ist ebenfalls eine Authentisierung der Server gegenüber Clients und Endgeräten erforderlich. Hierdurch lässt sich verhindern, dass sich Clients an kompromittierten Servern registrieren und Daten von Clients ungewollt abfließen.

Auch an diesen beiden Stellen der Authentisierung können Zertifikate eingesetzt werden, um die Identitäten von Clients, Endgeräten und Servern zu bestätigen.

• Authentisierung der Server untereinander

Durch das mitunter komplexe Zusammenspiel verschiedener Server erfolgt viel Kommunikation zwischen unterschiedlichen Server-Komponenten. Sei es eine Datenbankabfrage des Registrierungsservers, eine Suche in einem angebundenen Verzeichnisdienst oder die Weiterleitung von Signalisierungsnachrichten an einen Session Border Controller. Um sicherzustellen, dass die Kommunikationsflüsse zwischen den richtigen Komponenten ablaufen, ist auch eine gegenseitige Authentisierung der unterschiedlichen Server-Komponenten erforderlich, idealerweise mithilfe von Zertifikaten.

Darüber hinaus kann nicht nur bei der Anmeldung oder Registrierung von Clients eine Authentisierung erfolgen. Durch das Session Initiation Protocol (SIP) kann zum Austausch von SIP-Nachrichten zwischen zwei Clients schon beim Rufaufbau eine gegenseitige Authentisierung durchgeführt werden. Hierbei authentisieren sich die beiden Clients gegenüber den SIP-Proxy-Servern, die die SIP-Nachrichten zwischen den Clients austauschen. Das Vorgehen ist in Abbildung 1 dargestellt:

Die Authentisierung wird in der SIP-Referenzarchitektur basierend auf der HTTP Digest Authentication durchgeführt. Hierbei erfolgt zwar eine Authentisierung des Clients gegenüber dem bzw. den SIP-Proxys entlang des Kommunikationspfades, eine weitergehende Absicherung hinsichtlich Vertraulichkeit und Integrität findet jedoch nicht statt.

Um diese zu erreichen, werden in der Praxis Verschlüsselungsmechanismen verwendet, die im Folgenden betrachtet werden.

Grundlegende Maßnahme zur Absicherung: Verschlüsselung

Neben der Authentisierung ist die Verschlüsselung von Kommunikation eine zentrale Maßnahme zur Absicherung. Hierbei sollten folgende Bereiche abgedeckt werden:

• Verschlüsselung von Signalisierungsdaten

Die Signalisierungsdaten zwischen IP-Endgerät, Signalisierungsmanager und anderen Signalisierungsendpunkten sollten verschlüsselt werden, um das unberechtigte Ausspähen von Informationen über die Anrufziele, Anrufdauer etc. zu verhindern. Zudem werden über die Signalisierung wichtige Daten für die Verschlüsselung von Medienströmen ausgehandelt, sodass eine Verschlüsselung der Signalisierungsdaten auch dazu beiträgt, dass die Medienströme erfolgreich verschlüsselt werden. In der Regel wird hierfür TLS (Transport Layer Security) auf Basis von Advanced Encryption Standard (AES) mit einer Schlüssellänge von mindestens 128 Bit eingesetzt. Die Verschlüsselung der Signalisierung erfolgt dabei Hop-by-Hop, das heißt jeweils zwischen den Kommunikationspartnern innerhalb der Kommunikationskette zwischen den Endpunkten. Eine Ende-zu-Ende-Verschlüsselung findet nicht statt, da die auf dem Kommunikationspfad liegenden SIP-Server gegebenenfalls die Signalisierungsnachrichten anpassen können müssen.

• Verschlüsselung der Medienströme

Der Medientransport von Endpunkt zu Endpunkt beziehungsweise zwischen Endpunkt und Gateway, das den Medientransport terminiert (beispielsweise Session Border Controller) sollte verschlüsselt erfolgen, um ein Mithören und Ausspähen von Informationen zu verhindern. In der Regel kommt hierbei das Secure Real-Time Transport Protocol (SRTP) respektive das Secure Real-Time Transport Control Protocol (SRTCP) auf Basis von AES mit einer Schlüssellänge von mindestens 128 Bit zum Einsatz. Die Verschlüsselung des Medienstroms sollte zwischen den Endpunkten sowie zwischen Endpunkten und Gateways direkt – d.h. ohne Umwege – stattfinden. In der Praxis gibt es jedoch vielfach weitere Verschlüsselungsendpunkte, wie beispielsweise Multipoint Control Units (MCU) bei Videokonferenzen. Die Abbildung 2 zeigt schematisch die durchgängige Verschlüsselung des Medienstroms, wobei es Komponenten im Kommunikationspfad gibt, die eine Ent- und Verschlüsselung des Medienstroms vornehmen. Diese können SBCs, MCUs oder weitere SIP-Server sein.

Im Gegensatz dazu zeigt Abbildung 3 eine durchgängige Verschlüsselung des Medienstroms zwischen den beiden Endpunkten. Hierbei erfolgt keine Ent- und Verschlüsselung der Daten durch Komponenten auf dem Kommunikationspfad.

• Verschlüsselung von sonstiger Daten-Übertragung (Firmware, Konfigurationsdaten, Registrierungsdaten, Kommunikation zu weiteren Systemen etc.)

Neben Signalisierung und Medienstrom sollte auch Datenverkehr, der beispielsweise mittels Hypertext Transfer Protocol (HTTP) oder File Transfer Protocol (FTP) erfolgt, verschlüsselt übertragen werden. Insbesondere die Datenströme weiterer Dienste wie Chat-Funktionen oder Datei-Austausch werden in der Regel nicht über das SIP-Protokoll abgewickelt, sodass hier die Sicherheitsmechanismen nicht greifen. Daher nutzen moderne Systeme üblicherweise sichere Varianten wie HTTPS oder SFTP.

• Verschlüsselung von gespeicherten Daten

Doch auch ruhende Daten, also innerhalb von Servern oder Clients gespeicherte Informationen, sollten bei der Betrachtung nicht außen vor bleiben und mittels Verschlüsselung abgesichert werden. Vor allem bei Cloud-basierten Diensten, bei denen ein großer Teil an Daten nicht im eigenen Rechenzentrum, sondern auf Servern des Anbieters gespeichert werden, ist eine verschlüsselte Speicherung unerlässlich. Hierbei kommt der Schlüsselverwaltung eine zentrale Bedeutung zu. Einige Anbieter ermöglichen eine lokale Schlüsselverwaltung, wie Abbildung 4 am Beispiel Cisco zeigt. Die Kommunikation vom Unternehmensnetzwerk zum Netzwerk des Anbieters, hier Cisco, erfolgt dabei ausschließlich über verschlüsselte Protokolle wie HTTPS.

Kernpunkt einer sicheren Verschlüsselung von Signalisierung und Medienstrom ist der sichere Austausch des Schlüsselmaterials sowie eine möglichst gegenseitige Authentisierung, für die häufig Zertifikate eingesetzt werden. Dieser Aspekt wird im Folgenden genauer betrachtet.

Einsatz von Zertifikaten

Ein digitales Zertifikat ist wie ein digitales Ausweisdokument und dient zur eindeutigen Identifizierung von Identitäten. Der RFC 5280 (siehe [3]) enthält den X.509-Standard für digitale Zertifikate und eine zugehörige Public Key Infrastruktur (PKI). Darüber hinaus ist für viele Verschlüsselungsmechanismen die Verwendung eines Schlüsselpaares, bestehend aus einem geheimen, privaten Schlüssel und einem öffentlichen Schlüssel, von zentraler Bedeutung. Möchte Kommunikationsteilnehmer B eine verschlüsselte Nachricht an Kommunikationsteilnehmer A senden, so nutzt er für die Verschlüsselung der Nachricht den öffentlichen Schlüssel von Teilnehmer A. Dieser erhält anschließend eine verschlüsselte Nachricht, die er wiederum mit seinem privaten Schlüssel entschlüsseln kann (siehe Abbildung 5).

Im Vorfeld dieser Kommunikation muss der öffentliche Schlüssel von Teilnehmer A bekannt sein. Dies kann über ein Zertifikat realisiert werden, da ein digitales Zertifikat von Teilnehmer A den öffentlichen Schlüssel enthält. Unter Verwendung dieses Zertifikats ist Teilnehmer B dann in der Lage, eine verschlüsselte Nachricht an Teilnehmer A zu senden.

Nicht nur eine Verschlüsselung, sondern auch eine Verifizierung der Integrität von Nachrichten ist mithilfe eines Zertifikats möglich. Hierzu verwendet Teilnehmer A seinen privaten Schlüssel zur Signierung einer Nachricht an Teilnehmer B, indem ein Hash-Wert der übermittelten Nachricht gebildet wird, der anschließend mit dem privaten Schlüssel verschlüsselt wird. Teilnehmer B kann mit dem übermittelten öffentlichen Schlüssel von Teilnehmer A den Hash-Wert wieder entschlüsseln und so die Korrektheit der gesamten Nachricht überprüfen (siehe Abbildung 6).

Damit wird deutlich, dass mithilfe eines Zertifikats sowohl eine Verschlüsselung von Nachrichten als auch deren Verifikation möglich ist. Dies wird auch im Rahmen des TLS-Handshakes verwendet, bei dem unter Einsatz asymmetrischer Verschlüsselungsverfahren zunächst Informationen ausgetauscht werden, um einen Session Key zu generieren. Dieser Session Key wird dann für eine symmetrische Verschlüsselung der weiteren Kommunikation genutzt.

Im SIP-Kontext wird ebenfalls TLS zur Verschlüsselung der Signalisierungsnachrichten verwendet. Die Herausforderung besteht hier jedoch darin, dass die Signalisierung unter Umständen mehrere SIP-Server sowie weitere Komponenten, wie ein SBC, passieren muss, bis sie am Kommunikationsziel angelangt ist. Daher ist für eine durchgängige Nutzung von TLS auch eine durchgängige Nutzung von Zertifikaten unerlässlich: Endpunkte, Server, Gateways und Clients müssen entsprechende Zertifikate erhalten, und es sollte im Idealfall eine gemeinsame PKI bzw. Zertifikatsverwaltung geben, der alle beteiligten Kommunikationspartner vertrauen (siehe Abbildung 7).

Doch hier stellen sich gleich mehrere Fragen:

• Erfolgt die Zertifikatsverwaltung durch das Kommunikationssystem oder durch eine zentrale, unternehmenseigene CA (Certificate Authority)?
• Kann eine eigene, private CA an das genutzte Kommunikationssystem angebunden werden?
• Soll eine eigene, private CA oder eine öffentliche CA genutzt werden?
• Wie sieht das Ganze bei Cloud-basierten Kommunikationssystemen aus?

Zunächst ist festzuhalten, dass die großen Hersteller von Kommunikationssystemen für den Einsatz im Unternehmen auf diese Fragen entsprechende Antworten haben, jedoch verfolgt jeder Hersteller seine eigene Strategie in Bezug auf die CA. Einige Hersteller liefern mit ihrem Kommunikationssystem direkt eine eigene CA mit, die fest in ihre Systemlandschaft eingebunden ist. Hierüber erfolgen die Ausstellung und Verwaltung der Zertifikate. Das bedeutet, dass auf den Endgeräten des Herstellers neben vorinstallierten Zertifikaten, die bereits während der Produktion der Endgeräte aufgespielt werden, im laufenden Betrieb weitere Zertifikate durch die Hersteller-CA ausgestellt und verwaltet werden. Für IP-Telefone und die Registrierung am SIP-Server mag dieses Vorgehen noch einigermaßen praktikabel sein, aber spätestens dann, wenn es um die Nutzung von Zertifikaten für die Netzzugangskontrolle geht, erfordert dieses Vorgehen intensive Abstimmungen und spezifische Konfigurationen an verschiedenen Stellen. Zudem existieren in einigen Unternehmen Vorgaben hinsichtlich der Zertifikatsverwaltung und -ausstellung, wonach ausschließlich Zertifikate verwendet werden sollen, die über eine dedizierte CA ausgestellt und verwaltet werden.

Die Verwendung einer Unternehmens-CA sollte daher gemeinsam mit dem Hersteller des Kommunikationssystems geprüft werden. Bei den meisten Herstellern ist dies, wenn auch mit ein paar Umwegen, möglich. Entweder wird die Unternehmens-CA direkt als CA im Kommunikationssystem konfiguriert oder das Kommunikationssystem hat noch eine eigene CA, die als Intermediate-CA genutzt wird. Diese Intermediate-CA leitet dann Anfragen an die Unternehmens-CA weiter. Dies hat den Vorteil, dass die Kommunikationssysteme so konfiguriert werden können, als wäre lediglich die CA des Kommunikationssystems im Einsatz.

Neben unternehmensinternen CAs können auch öffentliche Zertifikatsstellen genutzt werden, die über das Internet erreichbar sind. Dieses Vorgehen ist beispielsweise bei kleineren Anbietern von Kommunikationssystemen oder bei Cloud-basierten Systemen (wie Microsoft Teams, Cisco Webex, Zoom etc.) vorzufinden. Die grundsätzliche Funktionalität ist hierbei ähnlich wie oben, jedoch müssen Endpunkte nun über das Internet erreichbar sein, um mit der öffentlichen CA zu kommunizieren. Möchte man dies aus Sicherheitsgründen vermeiden, kann hierfür auch ein Proxy-Server verwendet werden (siehe Abbildung 8 für das Beispiel von innovaphone mit CA „Let’s Encrypt“).

Neben der Ausstellung und Verifikation von Zertifikaten sind deren Verwaltung und insbesondere die Verteilung von entscheidender Bedeutung. Die Erneuerung eines einzelnen Zertifikats auf einem Endgerät mag noch mit überschaubarem Aufwand möglich sein, jedoch sollte besonders in großen Umgebungen mit mehreren Tausend Endgeräten die Verwaltung und Verteilung von Zertifikaten zumindest teilweise automatisiert erfolgen. Für die Verteilung der Zertifikate stehen zwar mehrere Standardverfahren zur Verfügung, jedoch wird unter Umständen nicht jedes Verfahren vom Anbieter des Kommunikationssystems unterstützt. Daher sind auch hier eine entsprechende Analyse und herstellerspezifische Detailkonfiguration notwendig.

Zusammenfassend lässt sich für den Einsatz von Zertifikaten festhalten, dass viele Hersteller von Kommunikationssystemen mittlerweile die Verwendung von Zertifikaten im Allgemeinen sowie die Verwendung von unternehmenseigenen Zertifikaten im Speziellen unterstützen.

Grenzen beim Einsatz von Zertifikaten und bei der Verschlüsselung

Die Nutzung von Authentisierung sowie Verschlüsselung und der Einsatz von Zertifikaten tragen maßgeblich zur Erhöhung des Sicherheitsniveaus von Kommunikationssystemen bei. Dennoch gibt es auch hier Grenzen, die zum Teil schneller erreicht sind, als man zunächst vermuten würde, nämlich an den Grenzen des eigenen Unternehmens. Dies gilt insbesondere für die Verschlüsselung und Authentisierung mithilfe von Zertifikaten. Jedes Unternehmen und jeder Provider verfügt über eine eigene CA sowie PKI. Für eine unternehmensübergreifende Umsetzung von Verschlüsselung wäre jedoch eine gemeinsame CA notwendig. Zwar lassen sich über Föderationen sowie entsprechende Konfigurationen mit dem SIP-Provider Vertrauensstellungen zwischen den jeweils genutzten Infrastrukturen etablieren, jedoch müssten diese Vertrauensstellungen auch mit sämtlichen externen Kommunikationspartnern aufgebaut werden, um tatsächlich eine durchgängige Verschlüsselung von Kommunikationsdaten zu erreichen. Da der damit verbundene Aufwand oft in keiner Relation zum Sicherheitsgewinn steht, wird dies in der Regel nicht umgesetzt – vielmehr lebt man mit dieser Unsicherheit.

Erschwerend kommt hinzu, dass nach dem Telekommunikationsgesetz die SIP-Provider dazu verpflichtet sind, im Zweifelsfall die Medienströme entschlüsseln zu können. Daher ist eine Ende-zu-Ende-Verschlüsselung von Sprachdaten nicht erreichbar, sofern über das öffentliche Telefonnetz kommuniziert wird.

Cloud-basierte Kommunikationssysteme sind an dieser Stelle tatsächlich ein wenig im Vorteil, denn hier wird in der Regel die Verschlüsselung und die Verwaltung der Zertifikate durch den Anbieter vorgenommen. Wenn die beteiligten Kommunikationspartner beim gleichen Anbieter vorzufinden sind, kann somit eine gegenseitige Authentisierung sowie eine Ende-zu-Ende-Verschlüsselung der Mediendaten erreicht werden.

Zusammenfassung und Fazit

Die Nutzung von IP-basierten Protokollen bietet einerseits die Möglichkeit, deutlich mehr Dienste als nur Sprache bereitzustellen. Gleichzeitig steigen durch die gemeinsame Nutzung von Netzwerkinfrastrukturen die Anforderungen an eine Absicherung der Kommunikation. Als probate Mittel haben sich die Nutzung von Verschlüsselungsmechanismen sowie der Einsatz von Zertifikaten bewährt. Dabei kann sowohl die Identität der Gesprächspartner als auch die Integrität der übermittelten Informationen überprüft werden; zudem bietet die Verschlüsselung einen effektiven Schutz vor dem Abhören durch unbefugte Dritte. Allerdings sind hierfür einige Vorbereitungen erforderlich, vor allem hinsichtlich der Verwaltung und Verteilung von Zertifikaten. Gemeinsam mit dem Hersteller des Kommunikationssystems muss abgestimmt werden, welche Partei die führende Rolle in Bezug auf die eingesetzte CA übernimmt. Darüber hinaus müssen sowohl zentrale Systeme als auch die eingesetzten Clients die Verfahren zur Verschlüsselung und Zertifikatsverteilung unterstützen.

Die Sicherheitsgewinne durch Zertifikate und Verschlüsselung enden jedoch in der Regel an den Grenzen des eigenen Unternehmens. Spätestens beim Übergang zu einem SIP-Provider endet der Einflussbereich und damit auch der Wirkungsbereich der eigenen Zertifikate. Wird dies berücksichtigt, können zumindest innerhalb des eigenen Unternehmens das Kommunikationssystem sowie die darüber laufende Kommunikation adäquat abgesichert werden.

Verweise

[1] https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Netzwerke/TK-Systeme/tk-systeme.html

[2] https://help.webex.com/de-de/article/n5hs5mg/Bereitstellungsleitfaden-f%C3%BCr-Webex-Hybrid-Data-Security#concept_065E8E2B91B5882F02BDFFAFCCA3B556

[3] https://datatracker.ietf.org/doc/html/rfc5280

[4] https://wiki.innovaphone.com/index.php?title=Reference16r1:Concept_Let%27s_Encrypt