Ein SIP-Autokonfigurationsdienst für sicheres VoIP

Diplomarbeit von Maximilian Vinokurov

Einleitung:

Telefonie über IP-Netze gewinnt in letzter Zeit immer mehr an Bedeutung. IP-Telefonie, auch Internet-Telefonie oder Voice over Internet Protocol (VoIP) genannt, setzt nicht mehr auf dedizierte Telefonnetze, sondern verwendet die inzwischen gut ausgebauten IP-Datennetze. Durch das Wegfallen der Notwendigkeit für Betrieb einer Telefonnetz-Infrastruktur mit dazugehörigen komplizierten Standards und teuren Komponenten, versprechen sich Telefondiensteanbieter großes Einsparpotential. Die neue Fernsprechtechnologie ist auch bei Telefonkunden beliebt. IP-Telefongeräte können nun überall dort betrieben werden, wo es Internet gibt. Der kostengünstige Betrieb, der sich in niedriger Telefontarifen wiederspiegelt, und die Flexibilität der IP-Telefonie sorgen für eine rasche Verbreitung der IP-Telefonie.

Trotz guter Verbreitung und Akzeptanz der VoIP-Protokolle und -Standards gelten diese als sehr unsicher. Das für VoIP-Signalisierung definierte und von IETF veröffentlichte Session Initiation Protocol (SIP), das unter anderem für Gesprächsaufbau und -abbau sorgt, genau so wie das für Multimedia-Datenübertragung definierte Protokoll namens Real-Time Transport Protocol (RTP), sind für das Übermitteln der VoIP-Daten im ‘Klartext’ ausgelegt. Da diese Daten über öffentliche Datennetze fließen, kann man VoIP-Gespräche nicht nur theoretisch sondern auch praktisch an jedem Netzwerkknoten, der zwischen zwei miteinander kommunizierenden VoIP-Gesprächspartner liegt, abhören. Diese Annahme wird von einer großen Anzahl der Computer-Programme, die sich auf Abhören von VoIP-Telefonaten spezialisieren, bestätigt. Ferner sorgt die in VoIP-Protokollen fehlende Authentizitätsprüfung dafür, dass die Identität des Anrufers oder des Angerufenen leicht zu fälschen ist. Gelingt es den Angreifern die Identität eines Telefonkunden zu fälschen, so können sie zum Beispiel auf Kosten der Kunden telefonieren oder unerwünschte Werbeanrufe unter falscher Identität tätigen, was deren Unterbindung stark erschwert oder fast unmöglich macht.

Aus oben genannten Gründen wurden fast alle VoIP-Protokolle in den letzten Jahren so erweitert, dass sie heutigen Sicherheitsstandards entsprechen. Doch die neuen Erweiterungen setzen eine aktive Mitwirkung und Zusammenarbeit der VoIP-Provider und VoIP-Gerätehersteller voraus. Die sichere Variante des RTPs - Secure RTP (SRTP), muss beispielsweise von allen an einem Gespräch teilnehmenden VoIP-Clients unterstützt werden, dabei ist die SRTP-Unterstützung bei VoIP-Telefonen keine Selbstverständlichkeit. Ältere Geräte unterstützten SRTP nicht und in VoIP-Telefonen, die heute mit SRTP-Unterstützen produziert werden, sind SRTP-Funktionen standardmäßig deaktiviert. Die standardmäßige Deaktivierung ist damit zu erklären, dass der Einsatz von SRTP eine aktive Unterstützung seitens VoIP-Provider erfordert. SRTP ist so ausgelegt, dass es auf ein externes Schlüsselaustauschverfahren setzt, dass mit VoIP-Signalisierung integriert werden soll. Was wiederum bedeutet, dass erst wenn ein VoIP-Provider einen Sclüsselaustauschsystem in Betrieb nimmt und für die Verschlüsselung der VoIP-Signalisierung sorgt, kann der Chiffrierschlüssel für SRTP ausgetauscht werden. Da aber solche Schlüsselaustauschsysteme sehr komplex und teuer im Aufbau und Betrieb sind, verzichten VoIP-Diensteanbieter in der Regel auf diese. Die Gründe dafür liegen zum Teil auf der Hand, einerseits stehen hinter VoIP-Providern oft kleine Unternehmen, die sich ein solches Sicherheitssystem mit dazugehöriger Infrastruktur nicht leisten können. Andererseits ist die Kostengünstigkeit eines VoIP-Provider-Betriebes gerade eines der Hauptgründe für eine rasche Verbreitung der IP-Telefonie.

Sollte ein VoIP-Provider eine Absicherung des SIP-Traffics gewährleisten und ein Schlüsselaustauschsystem in Betrieb nehmen, so bleibt es dennoch fraglich, ob das Schlüsselaustauschsystem vertrauenswürdig ist. Es bleibt nämlich unklar, wie sicher interne Server und Netze des Providers betrieben werden. Zusätzlich muss die Kommunikation zwischen den VoIP-Providern genügend abgesichert sein, da sie ebenso über öffentliche IP-Netze erfolgt und kompromittiert werden kann.

Ein weiteres großes Problemfeld der IP-Telefonie ist die Konfiguration der VoIP-Telefone. Was mit analoger Telefonie lange Zeit selbstverständlich war, dass die Telefone einfach ans Telefonnetz angeschlossen werden und man telefonieren kann, gilt für IP-Telefonie nicht, denn IP-Telefone müssen zuvor konfiguriert werden. Um ein VoIP-Telefon zu konfigurieren, wird vom Anwender etwas Fachwissen in den Bereichen Computer-Netzwerke und VoIP verlangt. Da ein IP-Telefon ein ganz normales Netzwerkgerät ist, müssen zuerst die Netzwerkschnittstellen des Gerätes korrekt konfiguriert werden. Anschließend sollen VoIP-spezifische Konfigurationsparameter, die sich nicht selten von Provider zu Provider stark unterscheiden können, eingestellt werden. Sollten VoIP-Gespräche abgesichert werden, so sind zusätzliche sicherheitsrelevante Konfigurationsparameter gefragt. All das schreckt heute immer noch zahlreiche Telefonkunden davon ab, auf IP-Telefonie umzusteigen. Das Problem wird heute gelöst, indem die IP-Telefone direkt von VoIP-Diensteanbietern verkauft und komplett vorkonfiguriert an Kunden ausgeliefert werden. Bei der Netzwerkkonfiguration der IP-Telefone wird dabei auf das DHCP-Protokoll gesetzt. Besitzt ein VoIP-Provider keinen Hardware-Verkauf, so muss er einen Kundendienst betreiben, der den Kunden bei der Konfiguration der IP-Telefone hilft.

Von einigen VoIP-Geräteherstellern gab es bereits mehrere Versuche dieses Konfigurationsproblem zu lösen, indem jeder von ihnen einen eigenen Standard zur automatischen Konfiguration von eigens produzierten Geräten veröffentlicht hat. Dies klappt auch meistens, führt aber gleichzeitig dazu, dass die Geräte, die automatisch mit einem herstellerspezifischen Auto-Konfigurationsprotokoll konfiguriert werden, alle vom gleichen Hersteller stammen sollen. Was den Lösungsansatz auf solche Unternehmen einschränkt, die bereit sind, eine große Anzahl an gleichen VoIP-Geräten zu erwerben und zu betreiben.

Seit 2006 gibt es nun ein Protokoll für eine automatische und herstellerübergreifende Verwaltung und Konfiguration von Netzwerkgeräten. Das Protokoll TR-069 wurde von einem Konsortium bestehend aus etwa 200 Telekommunikationsunternehmen namens Broadband Forum veröffentlicht. Eine später erschienene Protokollerweiterung mit der Bezeichnung TR-104 definiert zusätzlich die mit TR-069 konfigurierbare VoIP-spezifische Einstellungen für IP-Telefone und macht somit explizit eine Auto-Konfiguration von IP-Telefonen möglich.

Von der oben beschriebenen Situation ausgehend werden vor dieser Diplomarbeit mehrere Ziele gesetzt. Eine der Hauptziele ist es, IP-Telefonie so sicher wie möglich zu gestalten. Es soll ein Konzept erarbeitet werden, das es erlaubt, unabhängig von VoIP-Diensteanbietern Telefongespräche abzusichern. Weiterhin soll es eine Lösung sein, die möglichst unabhängig von VoIP-Clienten funktioniert, um die Probleme des SRTP-Protokolls sowie anderer VoIP-Sicherheitslösungen zu vermeiden, die sich stark vom Funktionsumfang der IP-Telefonen abhängig machen und sich dadurch selbst einschränken.

Diese Arbeit soll eine Art Transparent-Encryption-Proxy für die VoIP-Multimedia-Daten einführen, der den RTP-Traffic automatisch durch einen mit Verschlüsselung abgesicherten Tunnel umleitet und dabei unabhängig von VoIP-Providern agiert.

Ein weiteres Ziel ist den Anwendern den Konfigurationsprozess eines IP-Telefons komplett zu ersparen oder auf das Minimum zu reduzieren. Dies betrifft auch den Konfigurationsmehraufwand, der durch die zusätzlich eingeführte Absicherung der VoIP-Gespräche entstehen kann. Der Einsatz des neulich veröffentlichten Protokolls TR-069 soll für diese Zwecke geprüft werden.

All die Absicherungs- sowie Automatisierungsaktivitäten sollen von den lokal betriebenen Diensten erledigt werden. Dabei kann jeder der Dienste eine bestimmte Funktion übernehmen. Ein zentrales Dienst soll dabei wie eine Informationszentrale agieren und alle anderen Dienste konfigurieren und kontrollieren.

Die Arbeit wird folgendermaßen aufgegliedert: zuerst wird die Arbeit in Kapitel 1 vorgestellt, danach werden die grundlegenden und für die Diplomarbeit relevanten Protokolle und Standards in Kapitel 2erläutert sowie in dieser Arbeit verwendeten Begriffe erklärt. Im gleichen Kapitel werden ferner andere Arbeiten mit ähnlichen Zielsetzungen vorgestellt.

Kapitel 3 enthält einen Überblick über die aktuelle Situation und Probleme der IP-Telefonie, hier werden die Ziele der Arbeit ausführlicher beschrieben. Ein möglicher Lösungsweg mit dazugehörigen Szenarien wird skizziert.

In Kapitel 4 werden die wichtigsten Entitäten des zu erstellenden Systems vorgestellt und deren Rollen beschrieben. Die zuvor grob beschriebenen Szenarien werden präziser definiert. Anschließend wird der Auto-Konfigurationsdienst semiformal spezifiziert.

Eine prototypische Implementierung wird in Kapitel 5 präsentiert, wo deren Umfang und genauere Umsetzungsvorgehensweise beschrieben werden. Der Einsatz des Auto-Konfigurationsdienstes wird anhand der mit dem Prototyp durchgeführten Tests und Messungen im darauf folgenden Kapitel 6 evaluiert und mit den ähnlichen Ansätzen verglichen.

In Kapitel 7 werden die Ergebnisse der Arbeit zusammengefasst.

Inhaltsverzeichnis:

1.	Einleitung	1
1.1	Zielsetzung der Arbeit	3
1.2	Gliederung der Arbeit	3
2.	Grundlagen	5
2.1	IP-Telefonie Standards und Protokolle	5
2.1.1	SIP	5
2.1.2	SDP	8
2.1.3	RTP	10
2.1.4	VoIP-Trapezoid	10
2.1.5	STUN	10
2.1.6	ICE	11
2.2	Relevante Sicherheitsbegriffe	11
2.2.1	Sicherheitsterminologie	11
2.3	Angriffe auf IP-Telefonie	12
2.3.1	Denial Of Service	12
2.3.2	Replay-Angriff	12
2.3.3	Eavesdropping	12
2.3.4	Man-in-the-middle	12
2.3.5	Phishing	12
2.3.6	Phreaking	13
2.3.7	SPIT	13
2.3.8	Clipping	13
2.3.9	Voice-Bombing	13
2.3.10	Angriffe auf SIP	13
2.4	Überblick relevanter Verschlüsselungsstandards	13
2.4.1	Symmetrische Verschlüsselungsverfahren	13
2.4.2	Asymmetrische Verschlüsselungsverfahren	14
2.4.3	Digitale Signatur	14
2.5	Standards zur VoIP-Sicherheit	15
2.5.1	SIPS: SIP mit TLS	16
2.5.2	SIP mit S/MIME	16
2.5.3	SRTP	16
2.6	Schlüsselaustauschprotokolle	16
2.6.1	DH	16
2.6.2	IKE	17
2.6.3	ZRTP	17
2.6.4	SDES	18
2.6.5	MIKEY	18
2.7	Protokolle und Verfahren zur Absicherung der Kommunikation über IP-Netze	18
2.7.1	IPSec	19
2.7.2	TSL-VPN	19
2.7.3	SSH-VPN	19
2.7.4	OpenVPN	19
2.8	Protokolle zur automatischen Konfiguration von Endgeräten	20
2.8.1	TR-069	20
2.8.2	TR-104	21
2.9	Verwandte Arbeiten	21
2.9.1	VoIP-Media-Daten mit ZRTP und SRTP verschlüsseln	22
2.9.2	Skype	22
2.9.3	VoIP-Sicherheit bei Asterisk	22
2.9.4	Auto-Kon_guration von VoIP-Endgeräten	23
3.	Analyse	25
3.1	Aktuelle Situation und Probleme der IP-Telefonie	25
3.2	Sicherheit der IP-Telefonie	26
3.3	Providerunabhangige Sicherheit der IP-Telefonie	26
3.4	VoIP-geräteunabhängige Lösungsansätze für sichere IP-Telefonie	27
3.4.1	Absicherung der VoIP-Signalisierung	27
3.4.2	Absicherung der VoIP-Media-Daten	27
3.5	Absicherung der VoIP-Media-Daten durch verschlüsselte Kommunikationskanäle	28
3.5.1	Chiffrierschlüsselaustausch	28
3.6	Authentizitätsproblem bei der Einrichtung eines sicheren Kommunikationskanals	29
3.7	Szenarien für die Authentizitätsprüfung	30
3.7.1	Automatische Prüfung der digitalen Signaturen	30
3.7.2	Manuelle Prüfung der digitalen Signaturen	30
3.8	Automatische Konfiguration und Absicherung der IP-Telefonie	31
3.9	Kapitelzusammenfassung	31
4.	Entwurf	33
4.1	Annahmen und Voraussetzungen	33
4.2	Entitäten und Rollen	34
4.2.1	Steuerungsdienst	34
4.2.2	SIP-Proxy	34
4.2.3	Encryption-Proxy	34
4.2.4	Endgeräte-Konfigurationsdienst	35
4.2.5	HomeCA - lokale Authentication Authority	35
4.2.6	Gesamtbild	36
4.3	Einsatz alternativer Techniken zur Absicherung der IP-Telefonie	36
4.3.1	Absicherung durch SIPS und SRTP	37
4.3.2	Absicherung durch ZRTP	37
4.4	Szenarien für Authentifizierung der Gesprächsteilnehmer und Schlüsselaustausch	37
4.4.1	Szenario mit einem gemeinsamen geheimen Schlüssel	38
4.4.2	Szenario mit ausgetauschten Public-Key-Zertifikaten	38
4.4.3	Szenario ohne ausgetauschten Public-Key-Zertifikaten	38
4.4.4	Gesamtbild	39
4.5	Automatisierung von Absicherungsprozessen	40
4.6	Auswahl des Schlüsselaustauschprotokolls	40
4.7	Einrichtung eines sicheren Kommunikationskanals	41
4.7.1	Vorteile des OpenVPN-Protokolls	41
4.7.2	OpenVPN Parametrisierung mit Interactive Connectivity Establishment (ICE) Methoden	42
4.8	Auswahl des Verfahrens für automatische Konfiguration der VoIP-Endgeräte	42
4.9	Semiformale Spezifikation des Auto-Konfigurationsdienstes und der Subdienste	42
4.9.1	Steuerungsdienst	42
4.9.1.1	Discovery-Modus	43
4.9.1.2	Konfiguration und Aktivierung der Subdienste	43
4.9.1.3	Konfigurationsumfang der Subdienste	43
4.9.2	SIP-Proxy	44
4.9.3	Encryption-Proxy	45
4.9.4	Aushandlung von Parameter für den Aufbau eines sicheren Tunnels durch ICE Protokoll	45
4.9.4.1	Priorisierung des sicheren ICE-Kandidaten	47
4.9.5	ACS	47
4.9.5.1	Anbindung der VoIP-Geräte an den ACS	47
4.9.6	HomeCA	48
4.9.7	Schlüsselaustauschprotokoll: MIKEY-Light	49
4.9.7.1	Abkürzungen	49
4.9.7.2	Annahmen und Vereinfachungen	50
4.9.7.3	MIKEY-Light-Nachrichten bei PSK-Verfahren	50
4.9.7.4	MIKEY-Light-Nachrichten bei PK-Verfahren	51
4.9.7.5	MIKEY-Light-Nachrichten bei DH-Verfahren	51
4.9.8	Transportprotokoll für Schlüsselübertragung	51
4.9.9	Sequenzdiagramme für Schlüsselaustausch und Authentifizierungsszenarien	52
5.	Implementierung	55
5.1	Umfang der prototypischen Implementierung	55
5.1.1	Umgesetzte Szenarien	55
5.2	Aufbau der Testumgebung und prototypische Implementierung der Subdiensten	56
5.2.1	SIP-Registrar-Server	56
5.2.2	SIP-Proxy-Subdienst	56
5.2.3	Encryption-Proxy-Subdienst	58
5.2.4	VoIP-Client	60
6.	Evaluierung	63
6.1	Lauschangriff auf ein durch den Auto-Konfigurationsdienst abgesichertes VoIP-Gespräch	63
6.2	Vergleich des Auto-Konfigurationsdienstes mit alternativen Lösungsansätzen	63
6.2.1	Vergleich mit den anderen Auto-Konfigurationsansätzen	64
6.2.2	Vergleich mit SRTP Lösungen in Kombination mit abgesicherter Signalisierung	64
6.2.3	Vergleich mit ZRTP	66
6.2.4	Vergleich mit Skype	67
6.3	Diskussion und Performanz	67
6.3.1	Zeitliche Verzögerungen durch VoIP-Absicherung	67
6.3.1.1	Verzögerung beim Gesprächsaufbau	68
6.3.1.2	Verzögerung des Gesprächsdatenstroms	70
6.3.2	Technische Realisierung des Fingerprintabgleichs	70
6.3.3	Firmware-Unterstützung für TR-069	71
6.3.4	Umsetzung des MIKEY-Protokolls	71
6.4	Ausblick auf zukünftige Arbeiten und Verbesserungen	71
7.	Zusammenfassung	73
A	Installationsanleitung für die prototypische Implementierung	75
A.1	OpenSIPS-Installation	75
A.2	Installation der SIP- und Encryption-Proxys	76
A.3	Installation des SIP-Telefons	78
A.4	Testsystem starten	79
	Literaturverzeichnis	81

Textprobe:

Kapitel 6.3, Diskussion und Performanz:

In diesem Abschnitt wird das in dieser Diplomarbeit erarbeitete Konzept zur Absicherung der VoIP-Gespräche noch in der Hinsicht untersucht, ob die gefundene Lösung performant umgesetzt werden kann. Untersucht wird es anhand der prototypischen Implementierung. Es wird vor allem geprüft, ob mit den zusätzlichen Absicherungsmaßnahmen das VoIP-Gespräch in vernünftiger Zeit aufgebaut und mit akzeptabler Sprachqualität geführt werden kann.

Ferner werden in diesem Abschnitt Punkte erwähnt und ausdiskutiert, die in dieser Arbeit nicht genau definiert oder ausprobiert werden konnten. Bei solchen Fällen werden in den nächsten Abschnitten die Lösungsvorschläge für diese Punkte beschrieben.

6.3.1, Zeitliche Verzögerungen durch VoIP-Absicherung:

Außer als für den Machbarkeitsnachweis wurde die im Rahmen dieser Diplomarbeit erstellte prototypische Implementierung auch dafür verwendet, um zu messen, wie stark der Gesprächsaufbau und der Gesprächsdatenstrom durch die Absicherung eines VoIP-Gespräches verzögert werden. Die Verzögerung beim Gesprächsaufbau entsteht, weil während des SIP-Session-Aufbaus der Schlüsselaustausch erfolgt und ein sicherer Kommunikationskanal aufgebaut wird. Verzögerungen beim Gesprächsdatenstrom sind deswegen zu erwarten, weil dieser Strom nicht mehr Ende-zu-Ende fließt, sondern einen Umweg über die Encryption-Proxys und über den durch Verschlüsselung abgesicherten Kommunikationskanal macht.

Bei den Messungen wurden nicht nur die Zahlen festgehalten, sondern auch subjektive Tests durchgeführt, wobei geprüft wurde, ob die Verzögerungen von Gesprächsteilnehmern wahrgenommen werden.

Die zeitlichen Verzögerungen wurden in einem lokalen Testnetzwerk gemessen. Das Testnetzwerk bestand aus fünf virtuellen Rechnern, die folgende Rollen übernahmen:

• Rechner 1: VoIP-Diensteanbieter.

• Rechner 2: SIP-Proxy-Subdienst und Encryption-Proxy-Subdienst des Anrufers.

• Rechner 3: SIP-Proxy-Subdienst und Encryption-Proxy-Subdienst des Angerufenen.

• Rechner 4: IP-Telefon des Anrufers.

• Rechner 5: IP-Telefon des Angerufenen.

Als Virtualisierungslösung wurde Xen genommen. Jeder Rechner konnte auf den ‘VIA C7 Processor 1000MHz’ Prozessor zurückgreifen und bekam 64 MB Hauptspeicher zugeteilt. Nur dem Rechner 1 standen 128 MB zur Verfügung.

Wie die prototypische Implementierung für die in diesem Abschnitt beschriebene Messungen genau eingerichtet wurde, wird im Anhang A näher erläutert.

6.3.1.1, Verzögerung beim Gesprächsaufbau:

Zuerst wurde gemessen wie lang die Verzögerung beim Aufbau einer SIP-Session (Call Setup) ist. Dafür wurde die kommandozeilenbasierte Implementierung eines IP-Telefons PJSIP-User-Agent (PJSUA) verwendet. Dieser VoIP-Client wurde so modifiziert, dass er bei einem VoIP-Gesprächsaufbau den Zeitpunkt protokollierte, wann eine SIP-INVITE-Nachricht versendet wurde und auch den Zeitpunkt, wann das Gespräch nach einem SIP-Three-Way-Handshake zustande kam. Danach beendete sich der PJSUA. Dieser Prozess wurde, von einem Shell-Skript gesteuert, 100 Mal wiederholt. Der gesamte Test wurde zwei Mal durchgeführt, wobei der Auto-Konfigurationsdienst beim ersten Versuch aktiviert und anschließend beim zweiten Versuch deaktiviert wurde. Der Schlüsselaustausch erfolgte dabei nach Pre-Shared-Key-Verfahren (PSK).

Das gemessene Resultat ist in der Tabelle 6.4 festgehalten.

Zustand des Auto-Konfigurationsdienstes / Call Setup Dauer (in Sek.):

Aktiviert / 4,732.

Deaktiviert / 0,130.

Die Dauer eines VoIP-Gesprächsaufbaus wird durch die zusätzlichen Schritte beeinflusst, die wegen der Absicherung des Gespräches durch den Auto-Konfigurationsdienst notwendig sind. In der Tabelle 6.5 werden diese Schritte aufgezählt sowie die Zeit für jede einzelne Aktion angegeben.

Aktion / Dauer (in Sekunden):

PSK für weitere VoIP-Sitzungen ableiten / –.

Session-Key von PSK ableiten, MIKEY-Light-Nachricht (MLN) erzeugen / 0,014.

MLN übertragen / 0,001.

MLN parsen / 0,015.

OpenVPN-Client und -Server starten, Routing-Regeln aktivieren und warten bis der VPN-Tunnel fertig eingerichtet ist / 4,572.

Wie stark der Call-Setup-Prozess verzögert wird, falls der Schlüsselaustausch mit Diffie-Hellman- (DH) oder Public-Key-Verfahren (PK) erfolgt wurde nicht direkt gemessen, sondern nur errechnet, da eine komplette Implementierung der beiden Schlüsselaustausch-Methoden als komplex eingeschätzt wurde und viel Zeit in Anspruch nehmen würde.

Der Mehraufwand für einen Schlüsselaustausch mit DH- und PK-Verfahren wurde folgendermaßen ausgerechnet: es wurde angenommen, dass die Zeit für das Generieren, Übertragen und Parsen von MIKEY-Light-Nachrichten in der gleichen Größenordnung liegt wie beim Verfahren mit Pre-Shared-Key. Anschließend wurde dieser Wert um einen anderen Wert erhöht, der der Dauer entspricht, die notwendig ist, um einen Session-Key von DH-Werten oder von PK-Werten abzuleiten und einen Pre-Shared-Key für weitere VoIP-Sitzungen zu generieren.

Tabelle 6.6 bietet einen Überblick über die gemessene und errechnete Dauer der zuvor erwähnten Schlüsselaustauschverfahren.

Aktion / gemessene Dauer / errechnete Dauer:

Schlüsselaustausch mit PSK / 0,03 Sek. / –.

Schlüsselaustausch mit PK und Ableitung des PSK / – / 0,121 Sek.

Schlüsselaustausch mit DH und Ableitung des PSK / – / 0,111 Sek.

Die Ergebnisse zeigen, dass der Schlüsselaustauschverfahren mit DH- oder PK-Verfahren zwar die Dauer des Aufbauprozesses für ein VoIP-Gespräch fast verdoppelt, doch die Tatsache, dass dies zwischen zwei Gesprächspartnern nur einmal erfolgt, bevor es auf PSK-Verfahren umgestiegen wird, erlaubt es diese Verzögerung zu vernachlässigen. Für eine Vernachlässigung dieser Verzögerungen, die durch das Schlüsselaustausch-Mechanismus entstehen, spricht auch die Dauer der Verzögerungen: ein 0,2 Sekunden länger dauernder SIP-Session-Aufbau wird man subjektiv nicht wahrnehmen können.

Anders sieht es bei der Gesamtverzögerung des Gesprächsaufbaus aus, die mit etwa 4,7 Sekunden relativ hoch ausgefallen ist. Der Hauptgrund dafür liegt vor allem daran, dass die SIP-Nachrichten solange von SIP-Proxy-Subdiensten aufgehalten werden, bis ein VPN-Tunnel auf den beiden Seiten komplett aufgebaut ist und erst wenn eine Echo-ICMP-Nachricht4 mit einem Ping-Programm erfolgreich durch den VPN-Tunnel geschickt werden kann, werden die SIP-Nachrichten weitergeleitet.

Das der VPN-Tunnel so viel Zeit braucht um aufgebaut zu werden, kann zum Teil an den relativ knapp bemessenen Hardware-Ressourcen liegen: die jedem Rechner zugeteilte 64 MB des Hauptspeichers müssen von Debian-Linux-Betriebssystem, SIP-Proxy-Subdienst und Encryption-Proxy zusammen genutzt werden. Die Einrichtung eines sicheren VPN-Tunnels für die Durchleitung der Gesprächsdaten kann auf verschiedene Weise beschleunigt werden. Neben dem Einsatz von schnellerer oder dedizierter Hardware, die für VPN-Technologien optimiert sein kann, kann auch das Verbessern der Performanz der prototypischen Implementierung die entstehenden Verzögerungen verkürzen. Man kann beispielsweise den Einsatz des OpenVPN-Programms dadurch beschleunigen, indem die Software in den Hauptspeicher geladen und von dort gestartet wird, um damit die Ladezeit des Programms zu minimieren.

Bei einem Test mit den echten IP-Telefonen fiel diese Verzögerung subjektiv nicht auf. Was vor allem daran liegen könnte, dass man etwas Zeit braucht, bis der Hörer am Ohr platziert wird und man mit Sprechen anfängt.

6.3.1.2, Verzögerung des Gesprächsdatenstroms:

Da die Verlangsamung des Gesprächsdatenstroms negativ auf die Sprachqualität auswirken kann, indem es z.B. zu Echos kommen kann, wurde mit Echo-ICMP-Nachrichten die Verzögerung gemessen, die durch den Umweg über VPN-Tunnel entsteht. Innerhalb des Testnetzwerkes überschritt der Wert jedoch nicht die Grenze von einer Millisekunde: die Latenzzeit ist dabei von 0,8 Millisekunden (ms) auf 1,7ms angestiegen.

Die gleiche Auswirkung wurde auch zwischen zwei Testrechnern im Internet gemessen. Die Latenzzeit ist dabei etwas mehr angestiegen: von 18ms auf 20ms.

Wenn man die im ITU G.114 ausgesprochene Empfehlung berücksichtigt, wonach die Verzögerung für Sprachdienste erst ab 400ms in eine Richtung ein Ferngespräch unmöglich macht, kann die wegen der Verschlüsselung des Traffics entstehende Verlangsamung vernachlässigt werden.

6.3.2, Technische Realisierung des Fingerprintabgleichs:

Bei einem Schlüsselaustausch nach Diffie-Hellman- oder Public-Key-Verfahren, für den Fall dass die Daten nicht automatisch authentifiziert werden können, soll zur Abwehr einer möglichen Man-in-the-middle-Attacke eine Prüfsumme über die Schlüsselaustausch-Parameter gebildet und während des Telefongespräches, wie im Abschnitt Ein anderes Problem ist, dass es kein Standardprotokoll gibt, das es ermöglicht die Bildschirme der VoIP-Geräte zu steuern. Zwar gibt es einige von IETF veröffentlichte Protokolle sowie Protokollerweiterungen zum Thema Erweiterung des SIP-Protokolls um informative Nachrichten, doch es existiert keins, das breit eingesetzt und verwendet wird und auf irgendeine Weise das Steuern von Anzeigen von VoIP-Telefonen beschreibt. Als ein Beispiel dafür kann das von IETF im Jahr 2000 als RFC 2976 veröffentlichte Erweiterung des SIP-Protokolls ‘The SIP INFO Method’ angeführt werden, das das SIP-Protokoll um eine INFO-Nachricht erweitert, die die SIP-Session-relevanten Informationen während eine SIP-Session übertragen kann. Es existieren VoIP-Hardware-Telefone, die die Protokollerweiterung laut Geräte-Dokumentation unterstützen, es ist jedoch unbekannt, wie die INFO-Nachrichten das Verhalten von den VoIP-Endgeräten beeinflussen und welche INFO-Nachrichten überhaupt akzeptiert werden.

Zwei weitere Beispiele sind von IETF als RFC 3428 und RFC 3265 veröffentlichte Protokolle ‘Session Initiation Protocol (SIP) Extension for Instant Messaging’ und ‘Session Initiation Protocol (SIP)-Specific Event Notification’. RFC 3428 erweitert das SIP-Protokoll um die Chat-Funktionalität. RFC 3265 definiert sehr allgemein einen Framework, der für diverse Benachrichtigungsdienste benutzt werden kann. Bei diesen zwei Protokollen kann man die gleichen Argumente wie vorher einbringen: fehlende Unterstützung durch VoIP-Clients sowie eine kaum vorhandene Verbreitung erschwert die Nutzung dieser Instrumente für eine allgemein funktionierende Lösung des vorhandenen Problems.

Wie das Problem letztendlich zu lösen ist, wird in dieser Arbeit nicht beschrieben, sondern nur ein Lösungsweg vorgeschlagen. Die alternative Lösung kann dadurch ermöglicht werden, dass der SIP-Proxy-Subdienst die zu vergleichende Zeichenfolge mit einer Text-To-Speech-Software dem lokalen Gesprächspartner vorgelesen wird. Text-To-Speech-Funktionalität wird heutzutage durch zahlreichen freien und kommerziellen Implementierungen in Form von fertiger Software oder wiederverwendbaren Software-Modulen angeboten, sodass eine Integration durchaus machbar ist.