Voice over IP security
Studienarbeit: Studienarbeit Voice over IP Security Hochschule Rapperswil SS 05, 21.03.2005 –04.07.2005 Betreuer: Prof. Dr. Andreas Steffen Projektteam: Christian Höhn Silvan Geser Dokumentname: Voice Over IP Security.Doc Druckdatum: 16.01.2007
Studienarbeit Voice over IP Security Abstract 2 / 68 Voice over IP security
I Abstract
Im Rahmen dieser Studienarbeit galt es, den populären Voice over IP Client „KPhone“ für Linux „sicher“ zu machen. Konkret musste KPhone so erweitert werden, dass die Voice Daten, effi- zient verschlüsselt über das Netzwerk übertragen werden können.
Um dies zu realisieren, wurde auf ein bereits vorhandenes Softwarekonstrukt, die Verschlüsse- lungs-Bibliothek ’libsrtp’, zurückgegriffen. KPhone wurde so erweitert, dass die von der Library zur Verfügung gestellten Funktionen zur Verschlüsselung verwendet werden können.
KPhone ist nun mit dieser Erweiterung in der Lage, alle versendeten Voice Pakete symmetrisch, mit dem modernen AES Algorithmus zu verschlüsseln. Zusätzlich wird mittels einer verschlüssel- ten Prüfsumme für jedes einzelne Paket sichergestellt, dass es nicht verändert worden ist und der Sender tatsächlich im Besitzt des richtigen Schlüssel ist.
Die beiden Kommunikationspartner müssen sich vorgängig auf anderem Wege (Telefon, Email etc.) auf einen gemeinsamen Schlüssel einigen. Dieser Schlüssel kann nun vom Benutzer in der grafischen Oberfläche von KPhone eingegeben werden. Dort kann die Verschlüsselung zudem an- und abgestellt werden. Dank der übersichtlichen grafischen Oberfläche ist die Bedienung von KPhone einfach und für Jedermann gut verständlich.
Die Benutzung von KPhone ist auf allen gängigen Linux Distributionen möglich. Die verwendete Verschlüsselungs-Bibliothek, sowie der Voice over IP Client, sind beide im Internet kostenlos erhältlich.
Nach dem Abschluss dieser Studienarbeit, wird diese SRTP Erweiterung höchstwahrscheinlich in das KPhone Projekt aufgenommen werden.
Das Projekt wird als Diplomarbeit weitergeführt. Dort soll ein Key Management Protokoll einge- führt werden. Mittels eines Schlüssel Austausch Verfahrens (nach Diffie-Hellman) oder sogar mit elektronischen Zertifikaten, sollen so die schwachen Pre-Shared Schlüssel und die dadurch not- wendige Absprache abgelöst werden. Dies wird die Sicherheit massgeblich verbessern.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Inhaltsverzeichnis 3 / 68 Voice over IP security
II Inhaltsverzeichnis I Abstract...... 2 II Inhaltsverzeichnis...... 3 III Aufgabenstellung...... 6 IV Management Summary...... 7 1 Ausgangslage ...... 7 2 Vorgehen ...... 7 3 Ergebnisse...... 7 3.1 Evaluation ...... 7 3.2 Design...... 8 3.3 Sicherheit...... 8 3.4 Integration in KPhone...... 8 3.5 Features ...... 9 4 Ausblick...... 9 V SRTP...... 10 1 Allgemein...... 10 1.1 Einleitung ...... 10 2 Funktionsweise...... 10 2.1 Integration in RTP...... 10 2.2 SRTP Paketaufbau ...... 10 2.3 Cryptographic Context ...... 11 2.4 SRTP Keymanagement...... 13 2.5 Verschlüsselungsalgorithmus...... 14 2.6 Integritätssicherung ...... 14 2.7 Ablauf ...... 14 3 Secure RTCP ...... 15 4 Pre-Defined Cryptographic Transforms ...... 15 4.1 Encryption...... 15 4.2 Message Authentication...... 16 4.3 Vertraulichkeit des RTP Inhalts...... 17 4.4 Vertraulichkeit des RTP Headers ...... 18 5 Key Management...... 18 5.1 Allgemein...... 18 5.2 SRTP Policy...... 18 5.3 Re-Keying...... 19 5.4 SSRC Collision/Two Time Pad ...... 20 6 SRTP Erweiterungen ...... 20 VI Anforderungsspezifikation ...... 21 1 Einleitung ...... 21 1.1 Projekt Beschreibung...... 21 2 Funktionale Anforderungen...... 21 3 Nichtfunktionale Anforderungen...... 21 3.1 Usability...... 21 3.2 Reliability ...... 21 3.3 Performance...... 21 3.4 Security ...... 21 3.5 Supportability ...... 22 3.6 Implementation ...... 22 4 Use-Cases...... 23 4.1 Use-Cases Priorität 1 ...... 23 VII Vergleich SIP Clients ...... 24
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Inhaltsverzeichnis 4 / 68 Voice over IP security
1 Übersicht ...... 24 2 Minisip ...... 24 3 KPhone...... 25 4 Weitere Tools...... 26 5 Fazit der Evaluation ...... 26 VIII Analyse...... 27 1 SRTP Integration ...... 27 1.1 Allgemein...... 27 1.2 Domain Model...... 28 1.3 Verschlüsseltes Paket senden...... 29 1.4 Paket empfangen...... 30 IX Design ...... 31 1 Einleitung ...... 31 1.1 Allgemein...... 31 2 Klassendiagramm...... 31 2.1 Klasse SRTPWrapper ...... 32 2.2 Klasse DspOutRtp...... 33 2.3 SRTP Stack (Library) libsrtp ...... 33 3 Systemarchitektur...... 35 3.1 Systemoperationen ...... 35 4 KPhone Erweiterung ...... 37 4.1 Allgemein...... 37 4.2 Klasse DspOutRtp...... 37 4.3 User Interface...... 37 5 Fehlerbehandlung ...... 38 5.1 Allgemein...... 38 5.2 Fehlerbehandlung im SRTP-Wrapper ...... 38 X Softwaredokumentation...... 39 1 Einleitung ...... 39 2 Business Logik...... 39 2.1 Schnittstelle zur SRTP Library ...... 39 2.2 Sicherheit...... 39 2.3 QT Multithreading ...... 41 3 GUI...... 42 XI User Manual ...... 43 1 Installation ...... 43 1.1 Allgemein...... 43 1.2 Voraussetzungen ...... 43 1.3 Schrittweise...... 43 1.4 Konfiguration...... 43 2 Grundsätzliches...... 44 3 Betroffene Dateien...... 44 3.1 Konfigurations Skript und Makefiles...... 44 3.2 Sourcecode...... 46 XII Glossar ...... 49 1 Stichwortverzeichnis...... 49 2 Quellen ...... 51 XIII Anhang: Projektplan...... 52 1 Einleitung ...... 52 1.1 Ziel und Zweck ...... 52 2 Über das Projekt...... 52 2.1 Beschreibung...... 52 2.2 Vision ...... 52 Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Inhaltsverzeichnis 5 / 68 Voice over IP security
2.3 Teamstruktur...... 53 3 Dokumente ...... 54 3.1 Übersicht...... 54 3.2 Abstract...... 54 3.3 Anforderungsspezifikation ...... 54 3.4 Analyse...... 56 3.5 Design...... 56 3.6 Software Dokumentation ...... 56 3.7 Kphone Anpassungen ...... 56 3.8 SRTP Dokumentation...... 56 3.9 User Manual ...... 56 3.10 Programmierrichtlinien ...... 56 3.11 Evaluation SIP Clients...... 57 3.12 MIKEY Analyse ...... 57 3.13 Persönliche Berichte...... 57 3.14 Voice over IP security...... 57 XIV Anhang: Risk Management...... 58 XV Anhang: Zeiterfassung...... 59 1 Zeitkontrolle...... 59 1.1 Arbeitsstunden pro Woche...... 59 1.2 Kumulierte Zeit Übersicht ...... 59 1.3 Zeitaufteilung nach Bereichen ...... 60 1.4 Bereiche: soll/ist...... 61 XVI Anhang: Persönliche Berichte...... 62 1 Bericht, Christian Höhn...... 62 2 Bericht, Silvan Geser...... 63 XVII Anhang: MIKEY Analyse...... 65 1 Überblick ...... 65 1.1 Einleitung ...... 65 1.2 Szenarios...... 65 1.3 Design Ziele...... 65 1.4 Funktionsübersicht...... 65 2 Methoden zum Schlüsselaustausch/Vereinbarung...... 66 3 MIKEY Begriffe...... 66 XVIII Anhang: Programmierrichtlinien ...... 67 1 C++ Headerdatei...... 67 2 C++ Sourcedatei...... 68
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Aufgabenstellung 6 / 68 Voice over IP security
III Aufgabenstellung
2. Studienarbeit SS 2005
Voice-over-IP Sicherheit
Betreuer: Prof. Dr. Andreas Steffen Ausgabe: Montag, 21. März 2005 Abgabe: Montag, 4. Juli 2005
Einführung Voice-over-IP Applikationen auf der Basis des HTTP-basierten Session Initiation Protokolls (SIP) sind sehr populär geworden und werden auf breiter Front eingesetzt. Meist werden aber bei Te- lefongesprächen über das Internet die fundamentalsten Sicherheitsaspekte sträflich vernachläs- sigt. So werden weder beim Gesprächsaufbau die Kommunikationspartner authentisiert, noch sind die Multimedia-Ströme verschlüsselt und vor mutwilligen Veränderungen geschützt. Und dies obwohl entsprechende SIPv2 Security Standards (RFC 3261) vorhanden wären und die Mul- timedia Pakete mittels Secure RTP (RFC 3711) kryptografisch sicher übertragen werden könn- ten. In dieser Studienarbeit soll von einem Linux OpenSource SIPv2 Client ausgegangen werden und in einem ersten Schritt die Multimedia-Kanäle mittels Secure RTP gesichert werden. Die zu diesem Zweck benötigten SRTP Master Keys sollen in den SIP Endpunkten statisch konfiguriert werden.
Aufgabenstellung Wahl eines geeigneten Linux OpenSource SIPv2 Clients als Ausgangspunkt der Studienarbeit. Verschlüsselung und Authentisierung der Multimedia-Ströme (Audio, eventuell Video) mittels des Secure RTP Protokolls. Dazu kann die libsrtp Library verwendet werden. Hauptziel der Studienarbeit ist ein funktionierender Demonstrator, mit dem eine kryptografisch gesicherte Multimedia-Verbindung zwischen zwei SIP Clients betrieben werden kann, wobei der SRTP Master Key statisch vorkonfiguriert wird.
Links Overview SIP Security: http://security.zhwin.ch/DFN_SIP.pdf Session Initiation Protocol (SIPv2): http://www.ietf.org/rfc/rfc3261.txt Secure RTP (SRTP): http://www.ietf.org/rfc/rfc3711.txt libsrtp Implementierung: http://srtp.sourceforge.net/srtp.html ZHW Diplomarbeit “SIP Security”: http://home.zhwin.ch/~sna/DA/Sna2_2003.pdf minisip – Secure SIP Client: http://www.minisip.org kphone – SIP Client: http://www.wirlab.net/kphone/ Rapperswil, 21. März 2005
Prof. Dr. Andreas Steffen
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Management Summary 7 / 68 Voice over IP security
IV Management Summary
1 Ausgangslage Durch die zunehmende Verbreitung des Internets, die hohe Leistungsfähigkeit der Netzwerke und die immer günstigeren Ressourcen, wird das Telefonieren über das Internet für Private und Firmen zunehmend attraktiver. Die herkömmlichen Telefonleitungen bieten seit jeher ein gewis- ses Mass an Sicherheit, da zum Abhören von Gesprächen physikalischer Zugriff auf die Tele- kommunikationsinfrastruktur nötig ist. Da man bei Computer Netzwerken immer davon ausge- hen muss, dass ein Angreifer den Verkehr irgendwo abgreifen kann, fehlt diese Sicherheit bei VoIP Kommunikation. Vielen Benutzern ist jedoch gar nicht bewusst, wie einfach so ein Angriff mit den richtigen Tools sein kann. Zur Übertragung von Telefongesprächen übers Internet wird häufig das standardisierte RTP Pro- tokoll im Zusammenspiel mit SIP verwendet. Für die Vermittlung und den Gesprächsaufbau ist SIP verantwortlich, die eigentliche Übertragung der Audio- oder Video-Daten wird von RTP über- nommen. Beide Protokolle haben gemeinsam, dass die Daten nicht verschlüsselt werden und diese Gespräche so relativ leicht mitgeschnitten werden können. Die Daten des Verbindungs- aufbaus sind weniger schützenswert, da ein Angreifer nur beschränkt Informationen daraus beziehen kann. Die RTP Daten sind dagegen durch privaten oder geschäftlichen Inhalt sensibler und daher schützenswert. SRTP wurde Hauptsächlich entwickelt, um die Vertraulichkeit und die Integrität von Voice over IP Daten zu gewährleisten. Es handelt sich um einen ausgeklügelten Standard, der mit vielfach bewährten und bewiesenermassen sicheren kryptografischen Verfah- ren arbeitet.
2 Vorgehen Um das Rad nicht neu erfinden zu müssen, wird in diesem Projekt auf einem bestehenden Client aufgebaut. Es soll ein Client gewählt werden der komplett mit gültigen Standards arbeitet und der frei erhältlich ist. Am wahrscheinlichsten empfiehlt sich dafür eine Open Source Lösung. Da besonders die Implementation des SRTP Protokolls (der sog. SRTP-Stack) aufwendig und in Punkto Sicherheit sehr heikel ist, soll auch hier eine bestehende Implementation verwendet werden. Es muss ein Modul gefunden werden, dass lizenztechnisch unproblematisch ist und in der gleichen Umgebung läuft wie der Client. Der SRTP-Stack muss dann effizient mit dem Client verbunden werden. Um die Akzeptanz bei den Entwicklern und den Anwendern des verwendeten Open Source Clients zu erhöhen, sollen in dessen Code möglichst wenige Änderungen vorgenommen werden. Dies erfordert eine flexible und leichtgewichtige Lösung. In einem ersten Schritt wird der Client so erweitert, dass verschlüsseltes Telefonieren mit einem sog. Pre-Shared Key (einen beiden Parteien bekannten Schlüssel) möglich ist. In einer zweiten Phase kann der Client mit einem Schlüsselaustausch-System, einem so genannten Key Mana- gement, erweitert werden. Dies ist jedoch nicht teil dieser Studienarbeit.
3 Ergebnisse
3.1 Evaluation Relativ schnell hat sich als Client der beliebte und weiterverbreitete Open Source Client KPhone heraus kristallisiert. Wie bei einer Open Source Software üblich, ist der Code etwas unübersicht- lich aber solide. Als SRTP-Stack hat sich die, ursprünglich von Cisco Systems entwickelte, SRTP- Library libsrtp angeboten. Da libsrtp in C geschrieben ist und KPhone in C++, liess sich dieses relativ gut in den Client integrieren.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Management Summary 8 / 68 Voice over IP security
3.2 Design Um KPhone nicht mehr zu verändern als unbedingt nötig, wurde die Erweiterung mit Hilfe eines Wrappers implementiert, der den SRTP-Stack kapselt und die Steuerungslogik für eine ver- schlüsselte Kommunikation enthält. Da ausschliesslich mit einem manuell gewählten Schlüssel gearbeitet wird, muss der Wrapper zudem ein quasi statisches Key Management betreiben. Die Library arbeitet im Grunde erinnerungsfrei, d.h. sie weiss nichts über vorgängig verschlüsselte Pakete. Das heisst der Wrapper muss der Library zu jedem Paket den jeweiligen Verschlüsse- lungskontext mitliefern. Dieser enthält Information über die Art der Verschlüsselung, die Schlüs- sellängen und den Master Key (Hauptschlüssel), der verwendet werden soll. Trotz einiger Unzulänglichkeiten im Code des Open-Source Clients ist es uns gelungen den Stack erfolgreich zu integrieren. Die Lösung mit der Wrapper Variante bringt neben Vorteilen aber auch gewisse Nachteile mit sich. So können Ereignisse und Abläufe in KPhone zwar Aktionen im Wrapper auslösen, jedoch nicht umgekehrt. So ist es nicht möglich, eine Verbindung aufgrund eines Fehlers während der Verschlüsselung zu beenden. Es kann zwar eine Fehlermeldung ausgegeben werden, die Verbin- dung läuft aber weiter, auch wenn unter Umständen keine verständliche Kommunikation mehr möglich ist.
3.3 Sicherheit Der Pre-Shared Key kann einfach über das Einstellungsmenu von KPhone eingetragen und die Verschlüsselung aktiviert werden. Die Bedienung der Verschlüsselung gestaltet sich so relativ einfach. Die Erweiterung arbeitet mit einer 128Bit starken, symmetrischen AES Verschlüsselung. Vom statischen Hauptschlüssel werden für jede Übertragung drei sog. Session-Schlüssel für SRTP abgeleitet. Ein 128 Bit Session Verschlüsselungs-Key, ein 160Bit Authentifizierungs-Key und ein 112Bit Session Salt. Bewiesener Massen ist so eine sehr sichere Übertragung der Multimedia Daten möglich. Um höchste Sicherheit zu garantieren, muss der Benutzer allerdings einen min- destens 16-stelligen, möglichst zufälligen Schlüssel wählen. SRTP verfügt zudem über eine Integritätssicherung und Paketauthentifizierung mittels des stan- dardisierten HMAC-SAH1 Verfahren. Dafür wird jedem Paket ein 10 Bit Authentication Tag mit- geben. So kann schon vor der Entschlüsselung bestimmt werden, ob der Sender des Pakets tatsächlich im Besitz des nötigen Schlüssels ist und ob das Paket unterwegs nicht verändert wurde. Eine klare Bestimmung der Identität des Absenders, das sog. DOA (Data Origin Authenti- cation), ist indes auf dieser Ebene nicht möglich. Grundsätzlich definiert der SRTP Standart auch eine Sicherung des Kontroll-Streams (RTCP) mittels SRTCP. Da KPhone ganz ohne einen RTCP Stream auskommt, haben wir darauf verzich- tet diese Funktionalität im Wrapper zu integrieren. Wegen des noch fehlenden Key Managements konnten zudem nicht alle Sicherheitsfeatures von SRTP ausgereizt werden. Zum Beispiel kann das Master Salt vor der Kommunikation nicht ausgetauscht werden und fehlt faktisch beim Ableiten der Session-Schlüssel. Dennoch bietet die VoIP Verschlüsselung mit dieser Erweiterung für viele gängige Anwendungen ausreichend Si- cherheit.
3.4 Integration in KPhone Die SRTP Erweiterung ist bisher leider nur als Patch für die Aktuelle KPhone Version verfügbar. Das Ursprüngliche Ziel, sie in die eigentliche KPhone Distribution zu integrieren konnte bisher noch nicht verwirklicht werden. Die Verhandlungen mit den zuständigen Finnischen Entwicklern laufen aber und wir sind zuversichtlich, dass es innert nützlicher Frist doch noch klappen wird.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Management Summary 9 / 68 Voice over IP security
3.5 Features • Einfache Bedienung über des herkömmliche KPhone Interface • Starke 128 Bit symmetrische AES-CTR Verschlüsselung • Manuelles Key Management mit Pre-Shared Key’s • Audio-/Video Codec unabhängige Verschlüsselung • Integritätssicherung mittels HMAC-SAH1 Verfahren • Schutz vor Replay Angriffen • Läuft auf allen Linux Distributionen • Open-Source und absolut kostenlos
4 Ausblick Diese erste Arbeit legt den Grundstein für eine wesentliche Erweiterung. Wie gesagt wird hier mit einem manuellen Key Mangement mittels Pre-Shared Keys gearbeitet. Dieses System ist in der Praxis jedoch nur begrenzt tauglich und soll in erster Linie als experimentelles Stadium be- trachtet werden. Der sichere Austausch des Schlüssels ist aufwendig und skaliert sehr schlecht für grössere Gruppen. Der SRTP Standart wurde von Anfang an mit dem Hintergedanken an eine Zusammenarbeit mit einem Key Management Protokoll entwickelt. Auch hier soll ein bereits standardisiertes Proto- koll verwendet werden. Als Favorit kann das MIKEY (Multimedia Internet Keying) Protokoll gese- hen werden. Damit wäre ein Master Key Exchange mittels des Diffie-Hellman Algorithmus oder auch per X.509 Zertifikaten in einer PKI Umgebung möglich. Zudem könnte bei Letzterer auch die Identität des Kommunikationspartners sichergestellt werden. Die Sicherheit könnte wesentlich verbessert werden, in dem für jede Verbindung neue Master Key’s zum Einsatz kommen könnten. Das SRTP Protokoll sieht zudem vor, dass die Session- Schlüssel während der laufenden Kommunikation ausgewechselt werden können. Diese Erweiterung um ein solides Key Management ist im Grunde der nächste logische Schritt. So ist es geplant eine solche Erweiterung im Rahmen einer Diplomarbeit noch dieses Jahr zu implementieren. Im Erfolgsfall entspricht das Produkt dann allen, in der SRTP standardisierten, Sicherheitsempfehlungen und kann auch hohen Anforderungen Punkto Sicherheit und Datenin- tegrität gerecht werden.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security SRTP 10 / 68 Voice over IP security
V SRTP
1 Allgemein
1.1 Einleitung Zur Übertragung von Telefongesprächen übers Internet wird häufig das standardisierte RTP Pro- tokoll (Real-time Transfer Protocol [RTP]) im Zusammenspiel mit SIP (Session Initiation Protocol [SIP] verwendet. Für die Vermittlung und den Gesprächsaufbau ist SIP verantwortlich, die eigent- liche Übertragung der Audio- oder auch Video-Daten wird von RTP übernommen. Beide Protokol- le haben gemeinsam, dass die Daten nicht verschlüsselt werden und diese Gespräche so relativ leicht von einer Drittperson mitgeschnitten werden können. Die Daten des Verbindungsaufbaus sind weniger schützenswert da ein Angreifer nur beschränkt Informationen daraus beziehen kann. Die RTP Daten sind dagegen dadurch, dass sie privaten oder geschäftlichen Inhalt enthal- ten können, sensibler und daher schützenswert. SRTP (Secure Real-time Transport Protocol [SRTP]) wurde Hauptsächlich entwickelt um die Ver- traulichkeit und die Integrität von RTP und RTCP (Real-time Transport Control Protocol [RTCP]) Paketen zu gewährleisten und Replay Attacken zu verhindern. Es wird dabei mit einem flexiblen Krypto-Framwork gearbeitet, das auch Erweiterungen mit neuen Transformationen ermöglicht. Durch die Verschlüsselung wird nur sehr wenig Overhead erzeugt und die Unterstützung für RTP Header Kompression wird beibehalten. Zudem wird durch die symmetrische Verschlüsselung nur wenig Rechenleistung für das Verschlüsseln der Pakete benötigt, was besonders bei der Anwendung auf mobilen Geräten wie PDA’s oder Mobiltelefonen wichtig ist. SRTP ist unabhängig von den durch RTP verwendeten unteren Netzwerk Schichten und zudem sehr Tolerant gegenüber Paketverlusten.
Durch die in SRTP integrierte Key Derivation (Schlüssel Ableitung) reicht ein einziger Master Key aus, um für jede Session die benötigten Schlüssel abzuleiten. Während der Session kann zudem der Master Key in periodischen Abständen erneuert werden. Salting Keys werden zur zusätzli- chen Erhöhung der Sicherheit eingesetzt (pre-computaion, time-memory tradeoff attacks).
2 Funktionsweise
2.1 Integration in RTP SRTP ist im Grunde eine Erweiterung des RTP Stacks und wird quasi zwischen dem RTP-Stack und dem darunter liegenden Layer platziert. Die RTP Pakete werden vor dem Senden abgefangen und in ein SRTP Paket trans- formiert. Dieses wird beim Empfänger durch SRTP ent- schlüsselt und an den RTP Stack weitergegeben. SRTCP (Secure Real-time Transport Control Protocol [SRTCP]) bietet den gleichen Service für die Verschlüsse- lung der Kontrollpakete RTCP.
2.2 SRTP Paketaufbau Der Aufbau des Pakets bleibt im Grunde gleich wie der eines RTP Pakets. Zusätzlich können am Ende zwei Felder, MKI (Master Key Identifier [MKI]) und Abbildung 1: SRTP Integration
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security SRTP 11 / 68 Voice over IP security
Authentication Tag vorkommen. Da jeder Stream mit einem anderen Master Key verschlüsselt werden kann muss SRTP, falls diese Funktionalität genutzt wird, den jeweiligen Key identifizieren können. Das 32Bit Feld MKI identifiziert den Master Key von dem die Schlüssel für dieses Paket abgeleitet wurden. Dieses Feld kann auch zur Steuerung des Re-Keying während der Session verwendet werden. Diese Funktionalität ist optional und dieses Feld fehlt, wenn sie nicht aktiv ist. Die Authentifizierung ist im Grunde optional, wird jedoch dringend empfohlen. Das ganze Paket inklusive RTP Header und Payload, aber ohne die zusätzlichen zwei SRTP Felder (MKI, Authenti- cation Tag), fliessen in diese Authentifizierung ein. Dies Geschieht beim Sender erst nach der Verschlüsselung, was die Integrität der verschlüsselten Daten sicherstellt. Da die Sequenznum- mer bzw. der Paketindex auch authentifiziert wird, können mittels Ueberprüfung des Authentica- tion Tag Replay Attacken erkannt werden. Der RTP Header wird unverändert ins SRTP Paket übernommen. Die RTP-Header-Extensions, der Daten Teil (Payload), sowie dessen padding werden komplett von SRTP verschlüsselt.
012345678910111213141516171819202122232425262728293031 VPX CC M PT Sequence Number Timestamp SSRC CSRC [0..15] RTP-Header extension (Optional) Authentifiziert
Payload…
Verschlüsselt RTP Padding RTP Pad Count SRTP MKI (Optional) Authentication Tag Abbildung 2: SRTP Paketaufbau
2.3 Cryptographic Context Für jeden Stream müssen der Sender sowie der Empfänger einen sog. Cryptographic Context unterhalten. Die Attribute dieses Kontexts sind unabhängig vom verwendeten Verschlüsselungs- Algorithmus. Der Kontext enthält statische, sowie dynamische Informationen über den Stream, die wichtigsten sind: • Rollover Counter ([ROC]): zählt die Durchgänge durch den 16Bit-SRTP Sequenz Nummer Zähler Der Index eines SRTP Paketes wird berechnet aus: [i=2^16 * ROC + Sequenznummer] • Encryption Algorithm Identifier (Art und Modus der Verschlüsselung) • Replay list (indexiert kürzlich empfangene Pakete) • MKI Indicator (MKI verwendet Ja/Nein) • Wert und Länge des Feldes des verwendeten MKI • Master Key (geheim) • Sesion Key Length : länge der generierten Session Schlüssel • MK Packet Counter (summiert die Anzahl SRTP-Pakete die mit einem Master Key ver- schlüsselt wurden)
Optionale Erweiterung zu jedem Master Key: • Master Salt: Zufälliger Schlüssel der den Master Key nach der Ableitung zusätzlich ver- schleiert, wird dringend empfohlen. Beide Seiten müssen den gleichen Salt verwenden, kann öffentlich sein. • Key Derivation Rate: Sagt aus nach wie vielen Paketen ein neuer Master Key gewählt werden muss und damit die aktuellen Session Schlüssel neu abgeleitet werden sollen. (1 - 2^24) •
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security SRTP 12 / 68 Voice over IP security
SRTCP teilt normalerweise den Crypto Conetxt mit SRTP mit Ausnahme von: • SRTCP Index Counter • Eigene Replay list (schützt vor Replay Attacken) • Eigener MK Packet Counter: Summiert die Anzahl SRTCP-Pakete die mit einem Master Key verschlüsselt wurden, (max. 2^31)
Werden in der gleichen Session mehrere Streams (unterschiedliche SSRC’s (Synchronisation Source Identifier [SSRC])) mit dem gleichen Kontext verschlüsselt, muss für jeden Stream eine eigene Replay Liste und ein eigener Paket-Zähler geführt werden.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security SRTP 13 / 68 Voice over IP security
2.4 SRTP Keymanagement
2.4.1 Parameter Übersicht Eine Implementation von SRTP muss mindestens die Folgenden Schlüssel Parameter unterstüt- zen: Parameter Unterstützung Obliga- Standart torisch SRTP/SRTCP Transport Encryption AES_CM, NULL AES_CM Transport Authentication HMAC-SHA1 HMAC-SHA1 Auth. Prefix Length 80 Bit 80 Bit Key Derivation AES_CM AES_CM Key Material: Master Key 128 Bit 128 Bit Session Encryption Key 128 Bit 128 Bit Session Authentication Key 160 Bit 160 Bit Master Salt 112Bit 112Bit Session Salt 112 Bit 112 Bit Key Derivation Rate 0 0 Key lifetime SRTP-Pakete max. 2^48 2^48 SRTCP- Pakete max. 2^31 2^31 MKI Indicator 0 0 length of MKI 0 0 Tabelle 1: SRTP Parameter
2.4.2 Master Key SRTP benötigt um korrekt arbeiten zu können im Grunde nur einen Schlüssel, der vom Key- Management nach Angabe der Stream Identifikation
2.4.3 Key Derivation Für die eigentliche Verschlüsselung der Daten wird nicht der Master Key selber verwendet, son- dern sechs Schlüssel die über ein spezielles Derivation-Verfahren, unter Verwendung des Master Salt, von diesem abgeleitet werden. Die Trennung von Session- und Master Key hat im Grunde den Sinn, den Schaden den ein kompromittierter Session Key anrichtet zu Beschränken. So kön- nen vom Angreifer nur die Pakete gelesen werden die mit genau diesem Session Key verschlüs- selt wurden. Der Master Key und damit alle anderen von Ihm abgeleiteten Session Keys bleiben sicher.
Von diesem Master Key werden zusammen mit dem Paketindex und dem Master Salt die fol- genden sechs Schlüssel abgeleitet: 1. SRTP Session Encryption Key: Verschlüsselt die eigentlichen Daten des Streams synchron. 2. SRTP Session Authentication Key: Verschlüsselt den Hash Code der Nachricht. 3. SRTP Session Salt Key: Schützt vor Angriffen basierend auf statistischem Wissen der unverschlüsselten Nach- richt.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security SRTP 14 / 68 Voice over IP security
Zusätzlich 3 Schlüssel für das Kontroll-Protokoll [SRTCP]: 4. SRTCP Session Encryption Key 5. SRTCP Session Authentication Key 6. SRTCP Session Salt Key
Das Master Salt trägt insbesondere dazu bei, offline Key-Collision Angriffe zu verunmöglichen, welche sonst die effektive Schlüssellänge verringern würden. [MF00]
2.4.4 Effektive Schlüssellänge Obschon beispielsweise der Session Authentication Key 160 Bit beträgt kann die Effektive Schlüssellänge dennoch nie grösser sein, als die des Master Keys (default 128Bit). In diesem Fall wurden für den Auth. Key 160 Bit gewählt um bestehende HMAC [HMAC] Implementationen einfach integrieren zu können. Sollte trotzdem höhere Sicherheit erforderlich sein, so sieht der Standart [SRTP] vor, für den Master Key auch 192 bzw. 256 Bit zu wählen.
2.4.5 Replay Protection Für jeden Stream wird eine Liste der bereits empfangenen und authentisierten damit Pakete geführt. Die Implementation wird meist mit einem „Sliding Window“ bewerkstelligt, so dass diese Liste einen begrenzten Umfang aufweisst. Das heisst alle Pakete deren SRTP Sequenz- nummern sich unter den in der Liste vorhandenen befinden, können als bereits empfangen be- trachtet werden und werden verworfen. Pakete deren Nummern innerhalb der Liste liegen oder höher sind, werden akzeptiert.
2.5 Verschlüsselungsalgorithmus Die Daten werden standardmässig symmetrisch mit 128 Bit AES-CM [AES] verschlüsselt. Dazu wird der Session Encryption Key verwendet. AES hat einen sehr hohen Datendurchsatz und ist somit sehr schnell auch bei grossen Daten- mengen.
2.6 Integritätssicherung Um Veränderungen der Daten eines Paketes während der Übertragung festzustellen, bietet SRTP (auch SRTCP) die Möglichkeit ein Paket zu signieren. Dies wird mit dem HMAC-SHA1 [SHA1] realisiert. Mittels SHA1 wird also ein Hash über das gesamte Paket erzeugt. Dieser Hash wird dann mit dem HMAC Verfahren gesichert, als Schlüssel wird der Session Authentication Key verwendet. Die Authentifizierung ist optional, es wird jedoch vom Standart [SRTP] dringend empfohlen diese zu aktivieren.
2.7 Ablauf
2.7.1 Paket verschlüsseln Eingang RTP Paket->Paket verschlüsseln: 1. Passender Crypto Kontext auf Grund der SSRC, des Zielnetzwerks und des Zielports bestimmen 2. Paket Index aus ROC bestimmen, höchste Sequenznummer im Crypto Context und RTP Sequenznummer 3. Bestimmen des Master Keys/Salt über den Paket Index (5.3.2 Master Key Bestimmung über Lifetime). Falls MKI Indicator auf 1 gesetzt ist, ist der Master Key entsprechend der MKI zu wählen (5.3.1 Master Key Bestimmung über den MKI). 4. Session Key, Authentication Key und Session Salt bestimmen, wenn nötig (noch nicht erzeugt oder neue Erzeugung durch Key-Derivation-Rate erzwungen) ableiten aus Master Key, Master Salt und Session Key-Length aus dem Kontext.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security SRTP 15 / 68 Voice over IP security
5. RTP Paket mit dem im Kontext definierten Algorithmus, dem Index und dem aktuellen Session Key/Salt verschlüsseln. 6. MKI (falls benutzt) anfügen 7. Authentication Tag aus Auth. Key (Schritt 4) und dem jeweiligen Algorithmus aus dem Kontext berechnen und dem Paket anfügen. 8. Falls nötig ROC erhöhen.
2.7.2 Paket Entschlüsseln Eingang SRTP Paket->Paket entschlüsseln: 1. Passender Crypto Kontext auf Grund der SSRC, des Zielnetzwerks und des Zielports bestimmen 2. Paket Index Bestimmen aus ROC, höchste Sequenznummer im Crypto Context und RTP Sequenznummer 3. Bestimmen des Master Keys/Salt über den Paket Index (5.3.2 Master Key Bestimmung über Lifetime). Falls MKI Indicator auf 1 gesetzt ist, ist der Master Key entsprechend der MKI zu wählen (5.3.1 Master Key Bestimmung über den MKI). 4. Session Key, Authentication Key und Session Salt bestimmen, wenn nötig (noch nicht erzeugt oder neue Erzeugung durch Key-Derivation-Rate erzwungen) ableiten aus Master Key, Master Salt und Session Key-Length aus dem Kontext. 5. Bei aktiviertem Authentication und Replay Schutz wird zuerst die Replay Liste nach dem aktuellen Index durchsucht. Mit Hilfe des ROC und dem gewählten Authentication Algo- rithmus wird der Authentication Tag überprüft. Schlägt eine dieser Prüfungen fehl, wird das Paket zerstört. 6. Der verschlüsselte Teil des SRTP Pakets wird mit dem im Kontext definierten Algorith- mus, dem Index und dem aktuellen Session Key/Salt entschlüsselt. 7. Sequenz Nummer und falls nötig ROC erhöhen. Index in Replay Liste einfügen. 8. MKI und Authentication Tag aus dem Paket entfernen.
3 Secure RTCP SRTCP funktioniert im Grunde gleich wie SRTP. Einem RTCP-Paket sind aber zwingend drei zu- sätzliche Felder anzubringen um daraus ein SRTCP Paket zu machen: • SRTCP Index • Verschlüsselungs–Flag (encryption Flag) • Authentication Tag.
Optional kann auch hier ein MKI eingetragen sein. Für jeden Schlüssel, auch wenn er mit einem SRTP Stream geteilt wird, muss ein eigener 2^31 Bit grosser Zähler geführt werden, um die Schlüssel Laufzeit zu berechnen.
Der Empfänger muss den Index in diesem Fall nicht mehr berechnen, sondern kann diesen ein- fach aus dem Paket herauslesen.
4 Pre-Defined Cryptographic Transforms
4.1 Encryption
Der Paket Index, die SSRC und er Session Key werden zu einen Keystream Segment mit dem Datenteil (Payload) des RTP Pakets Bit-Weise verarbeitet (exklusiv-Or). Dazu wird von Anfang bis Ende jeweils eine gleich grosse Anzahl Bits aus der Payload verschlüsselt. Ist die Grösse des Keystreams kein ganzzahliger Teiler der Grösse der Payload (Anzahl Bits) wird der überschüssi- ge Teil des Streams beim letzten Block ignoriert.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security SRTP 16 / 68 Voice over IP security
Index SSRC SEK
Kestream Generator
KeyStreamSegment
block n+1 block n+2 block n+3 block n+4 block n+4
RTP Payload/Extensions
Encrypted Payload
Abbildung 3: Symmetrische Verschlüsselung
Es gibt verschiedene Mechanismen und Algorithmen um einen solchen Keystream zu erzeugen.
4.1.1 AES in Counter Mode (AES-CTR, oder AES-CM) AES Counter Mode ist eine 128Bit Block Cypher der einen 128 Bit Ctr (Counter) String mit dem Key verarbeitet. Dieser Ctr String wird aus dem Index des SRTP Pakets und aus dem aktuellen Counter (Zähler) Stand gebildet. Der Zähler (2^64) hat einen zufälligen Anfangsstand und wird bei jeder Verschlüsselung um 1 erhöht. Der Pseudo Zufalls Algorithmus AES CTR wurde bereits 1975 durch Diffie und Hellman einge- führt. Er gilt nachweislich als sicher und äusserst performant. Der verschlüsselte Text entspricht in der Grösse zudem exakt dem unverschlüsselten Original. [AES-CM]
4.1.2 AES in f8-mode Der AES-f8 Modus wurde für das 3G Telekommunikationssystem UMTS entworfen. Im Grunde handelt es sich um eine Variante des OFB Modus (Output Feedback Mode) mit einer verbesser- ten Initialisierung und erweitertem Feedback. Es werden dieselben Schlüssellängen wie beim AES CTR verwendet. Die Implementierung von AES-f8 ist laut Standard [SRTP] optional.
4.1.3 NULL Cypher Im Null Cypher Mode werden die Daten unverschlüsselt ins SRTP Paket geschrieben. Der Keystream beträgt in diesem Fall: „000…0“. Der NULL-Cypher muss in jeder SRTP Implementa- tion berücksichtigt werden.
4.2 Message Authentication Die Message Authentizität wird vom Sender über den ganzen verschlüsselten Teil des SRTP Pa- kets mit Hilfe von HMAC-SHA1 berechnet und diesem angefügt. Dazu wird der Session Authenti- cation Key verwendet, der durch die Key Derivation vom Master Key erzeugt wurde. Für die Verifizierung wird mit Hilfe des Schlüssels ebenfalls ein Hash über den verschlüsselten Teil des ankommenden Pakets berechnet. Stimmt dieser überein, gilt das Paket als authentifi- ziert, falls nicht wird es verworfen. In SRTP ist per Default für den Session Authentication Key eine Länge von 160 Bit vorgesehen. Der Authentication Tag hat eine Grösse von 80 Bit. Bedingt durch diesen Tag ist ein SRTP Paket im Normalfall genau 10Byte (80Bit) grösser als das korrespondierende RTP Paket.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security SRTP 17 / 68 Voice over IP security
4.2.1 HMAC-SHA1 HMAC-SHA1 [HMAC] ist eine bewährte Kombination zur sicheren Prüfung der Integrität und Au- thentizität von Daten. Von den Daten wird vom Sender mit SHA1 ein Hash berechnet und dieser dann mit HMAC und einem gemeinsamen Schlüssel verschlüsselt. Der Sender kann mit seinem Schlüssel und dem HMAC Algorithmus den Hash berechnen und diesen mit dem selber berechneten Hash der Da- ten vergleichen. Stimmen diese überein, kann davon ausgegangen werden, dass diese Daten nicht verändert wurden und nur von Absender stammen können, der im Besitzt des geheimen Schlüssels ist.
4.2.2 Data Origin Authentication (DOA) Auch wenn das obige Verfahren ein Paket als authentisch bestimmt, wäre es immer noch mög- lich, dass (vor allem in Gruppenszenarios wo mehrere Teilnehmer dieselben Schlüssel verwen- den) ein Stream aus einer anderen Quelle kommt als vom Empfänger angenommen. D.h. der Sender versteckt sich hinter einer falschen Identität. Dieses Problem kann von SRTP momentan nicht zuverlässig bewältigt werden. Ein Möglicher Ansatz wäre, das Problem auf der Key Management Ebene mit Zertifikaten zu regeln und für jede Verbindung einen eigenen Master Key auszuhandeln, von dem die jeweiligen Session Schlüssel abgeleitet werden. Dazu muss jedoch im Einsatzgebiet für die jeweilige Software mit DOA Eigenschaften (z. B. VoIP Client) ein robustes PKI Web of Trust eingeführt sein.
4.2.3 Kurze und Null Längen Authentifizierung Wie bereits erwähnt ist die Aktivierung der Authentifizierung in SRTP dringend empfohlen. Den- noch sind Szenarien denkbar, in welchen kurze oder gar keine Authentifizierung akzeptiert wer- den kann: • Drahtlose Kommunikations Systeme, bei denen der Overhead der Transportierten Daten möglichst gering gehalten werden muss. Eine typische Voice Anwendung produziert 20 Byte grosse Sprachsamples. Die RTP, UDP und IP Header werden dabei auf wenige Bytes komprimiert (1-2) [RFC3095]. Ein normaler SRTP Authentication Tag würde mit 10 Byte fast 50 Prozent vom ganzen Paket ausfüllen und ist daher wenig geeignet. • Applikationen mit fixen Daten-Feld-Grössen, bei denen diese Grössen vom Protokoll her nicht verändert werden können. • Wenn es sehr unwahrscheinlich ist, dass ein Angreifer ein gefälschtes Paket so zusam- menstellen kann, so dass nach dem Entschlüsseln sinnvolle Werte entstehen.
Schwache oder keine Authentifizierung darf nicht verwendet werden wenn: • Aufgrund von RTP Daten über Weiterleitungs- und Zugangsberechtigungen entschieden wird. • Wenn eine grössere Menge von abgefangenen und nochmals gesendeten Paketen einen nicht unerheblichen Einfluss auf das Verhalten des Empfängers haben könnten. Denn, ein effektiver Replay-Schutz ist nur möglich wenn eine Authentifzierung aktiv ist.
Bekannterweise ist der Authentication Tag in SRTP 80Bit gross, es gibt jedoch viele Anwendun- gen, welche nur 32Bit von diesen 80 verwenden. Im Grunde bietet denn schon ein 32 Bit Au- thentication Tag ausreichend Sicherheit.
4.3 Vertraulichkeit des RTP Inhalts Bei SRTP handelt es sich um einen sog. „Seekable Stream Cipher“, d.h. die Entschlüsselung bzw. Verschlüsselung eines Pakets hängt nicht von den vorher oder nachher verarbeiteten Pake- ten ab. Dies macht das Protokoll resistent gegen DOS (Denial of Service) Angriffe, welche die Schwä- chen einer zusammenhängenden Verschlüsselung ausnützen. Ein Potentieller Angreifer könnte dennoch aus dem Paket die Grösse der effektiven Payload (ohne Padding) ablesen. Dies wird ihm aber im Regelfall nicht viel nützen Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security SRTP 18 / 68 Voice over IP security
4.4 Vertraulichkeit des RTP Headers Da SRTP auf minimalen Overhead setzt wird der RTP Header unverschlüsselt mitgegeben was dessen Komprimierung ermöglicht. So sind Daten wie Payload Typ, SSRC, Timestamp und alle zusätzlichen Erweiterungen die zukünftig in den Header aufgenommen werden für potentielle Angreifer sichtbar. Soll dies verhindert werden muss diese Ebene zusätzlich von einem anderen Layer, z.B. durch IPsec geschützt werden.
5 Key Management Das Key Management ist für den sicheren Schlüsselaustausch verantwortlich. Momentan wer- den dafür Standards wie MIKEY (Multimedia Internet Keying [MIKEY]), KEYMGT (Key Manage- ment Extension [KEYMGT]) und SDMS (Security Description for Mediy Streams [SDMS]) prädes- tiniert. In diesem Kapitel wird eine mögliche Integration mit MIKEY betrachtet.
5.1 Allgemein SRTP verfügt selber über kein Key Management im eigentlichen Sinn. Es stellt aber Parame- ter/Attribute zur Verfügung, die von einem höher gelagerten Key Management genutzt werden können. Eine SRTP Implementation ohne zusätzliches Key Management, kann nur mit Pre-Shared Keys und zwar nur mit Einem pro Session arbeiten. Dagegen ist Grundsätzlich nichts einzuwenden denn es ist von der Spezifikation her erlaubt. Doch Pre-Shared Keys sind unflexibel, skalieren schlecht und sind für viele Anwendungsgebiete schlicht nicht geeignet. Zudem werden bei manuellem Key Management die Vorgaben für die maximale Verwendungsanzahl meist nicht erfüllt. Mögliche, aus anderen Gebieten erprobte Erweiterungen für den Schlüsselaustausch, könnten auch hier eingesetzt werden. Konkret ist das der Schlüsselaustausch mit Diffie-Hellman [DH] oder die Verwendung einer PKI (Public Key Infrastructure [PKI]) mit Zertifikaten. Auf die Funktionsweise dieser Methoden wird hier nicht näher eingegangen, sondern auf deren Einfluss auf SRTP.
5.2 SRTP Policy Folgende SRTP Parameter werden neben dem Key Exchange vor dem Beginn der Kommunika- tion vom Key Management ausgehandelt.
0 Encryption algorithm 1 Session Encr. key length 2 Authentication algorithm 3 Session Auth. key length 4 Session Salt key length 5 SRTP Pseudo Random Function 6 Key derivation rate 7 SRTP encryption off/on 8 SRTCP encryption off/on 9 sender's FEC order 10 SRTP authentication off/on 11 Authentication tag length 12 SRTP prefix length
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security SRTP 19 / 68 Voice over IP security
5.3 Re-Keying Jeder Master Key, bei MIKEY auch TEK (Transport Encryption Key) genannt, darf eine bestimmte Anzahl Pakete verschlüsseln ohne die Sicherheit zu gefährden. Mit dem gleichen Session Key dürfen 2^48 SRTP Pakete bzw. 2^31 SRTCP Pakete verschlüsselt werden, danach muss spätes- tens ein Re-Keying (neuer Session Key vom Master Key ableiten) durchgeführt werden. Wird ein TEK von SRTP für die Verschlüsselung von mehreren Streams benutzt, wird das Re-Keying vom Index des Streams getriggert, der als erster das obere Limit erreicht. Um auf der Empfängerseite ein solides Re-Keying zu gewährleisten, sollte die Authentifizierung verwendet. Sonst kann bei hohen Paketverlusten das implizite Verfahren zur Erkennung des Zeitpunkts zum Re-Keying, fehlschlagen.
5.3.1 Master Key Bestimmung über den MKI Es können mehrere solcher Master Keys zum Einsatz kommen, welche dann über den MKI iden- tifiziert werden können. Dies ist aber optional und muss von der SRTP Implementation unter- stützt werden. Der Nachteil ist, der zusätzliche Overhead der den Paketen durch den MKI aufge- laden wird. Gerade bei bandbreitenkritischen Applikationen kann dies zu Problemen führen. Dennoch wird das Re-Keying mit Hilfe des MKI für die meisten Applikationen empfohlen.
5.3.2 Master Key Bestimmung über Lifetime Alternativ definiert SRTP noch eine weitere Möglichkeit zur Bestimmung des richtigen Master Keys ohne zusätzlichen Overhead auf den Paketen. Dazu wird für jeden Master Key ein
5.3.3 Key Derivation Rate Während der Übertragung kann durch die vordefinierte Key-Derivation-Rate das Ändern des Master Keys und eine erneute Ableitung der Session Schlüssel erzwungen werden. Dies verrin- gert die Menge an verschlüsseltem Material, das mit dem gleichen Schlüssel erzeugt wurde und bringt zusätzliche Sicherheit. Die Derivation Rate entspricht der Anzahl Pakete nach der ein Re- Keying ausgelöst wird, d.h. wenn der Modulo aus Paketindex und Derivation-Rate Null ergibt [index.mod(dr)==0]. Gültige Werte für die Key Derivation Rate liegt zwischen 0-2^24.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security SRTP 20 / 68 Voice over IP security
5.4 SSRC Collision/Two Time Pad Jeder Keystream darf genau einmal verwendet werden, um ein Paket zu verschlüsseln. Sollten trotzdem zwei Pakete mit dem gleichen Keystream verschlüsselt werden, kann die Sicherheit der Übertragung ernsthaft gefährdet sein [NSA Venona Project]. Die Wahrscheinlichkeit, dass dieses Szenario auftritt, ist weitaus kleiner, wenn das Key Material von einem automatischen Key Management bereitgestellt wird, als wenn dies manuell geschieht. Wenn gewisse Regeln befolgt werden, wird dieses Problem bereits durch SRTP gelöst. • Jeder Stream in einer Session muss eine eindeutige SSRC aufweisen. • Ein Master Key kann von mehreren Streams in der gleichen Session verwendet werden. • Ein Master Key darf nicht von verschiedenen Sessions benutzt werden. • Ein Master Key darf auch für das Verschlüsseln des korrespondierenden SRTCP Streams benutzt werden.
Obschon es erlaubt ist den Master Key durch mehrere SSRC’s zu verwenden, wird die Sicherheit wesentlich verbessert, wenn jeder Stream mit einem eigenen Master Key arbeitet der ihm vom Key Management zur Verfügung gestellt wird. Denn trotz einmaliger SSRC, steigt das Risiko einer Kollision bei starker Verwendung des gleichen Schlüssels.
6 SRTP Erweiterungen Wie bereits erwähnt ist SRTP mit einem offenen Framework entwickelt worden, dass die Erwei- terung des Protokolls mit neuen Transformations-Algorithmen vorsieht. Dazu muss aber zwin- gend ein RFC verfasst werden, dass die Einbindung dieses Algorithmus in SRTP dokumentiert. Evtl. muss dazu auch der Crypto Kontext erweitert werden.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anforderungsspezifikation 21 / 68 Voice over IP security
VI Anforderungsspezifikation
1 Einleitung
1.1 Projekt Beschreibung Ziel ist es, den bereits bestehenden, populären, SIPv2-VoIP-Client „KPhone“ (für Linux), „sicher“ zu machen. Es soll dem Benutzer ermöglicht werden, mittels eines Pre-Shared Keys, eine gesi- cherte Voice-over-IP Verbindung über SRTP zu betreiben. Es gilt also den SRTP Stack in „KPho- ne“ zu integrieren.
2 Funktionale Anforderungen ID Name Beschreibung 1 Pre-Shared Key festlegen Es muss in „KPhone“ ein Key gespeichert werden können z. B. als String. 1.1 On/Off Die Verschlüsselung muss in der fertigen Version an- und ausschaltbar sein. 2 Kommunikation über SRTP Die Voice Daten müssen schlussendlich über SRTP verschlüsselt übertragen werden können. 3 SIPv2 Verbindungsaufbau mit Au- Evtl. mit MIKey HMAC thentifizierung Tabelle 2: Funktionale Anforderungen
3 Nichtfunktionale Anforderungen
3.1 Usability Das bereits vorhandene GUI soll so erweitert werden, dass es möglich wird den Pre-Shared Key, über das GUI einzutragen. Es soll auch ermöglicht werden über das GUI, zwischen RTP (ungesi- cherte Kommunikation) und SRTP (gesicherte Kommunikation) zu wählen.
3.2 Reliability Das Tool soll zuverlässig funktionieren, auch für längere Gespräche soll es ohne Probleme ver- wendet werden können. Es soll mit gut verständlichen Fehlermeldungen auf eventuelle Vorfälle hinweisen, wie z. B. ein Verbindungsunterbruch.
3.3 Performance Das SRTP Protokoll ist grundsätzlich so konzipiert, dass es auch auf wenig performanten Gerä- ten, wie zum Beispiel Embedded Systemen, benutzt werden kann. Diese Eigenschaft soll in die- ser Implementation erhalten bleiben.
3.4 Security In keinem Fall wird der Pre-Shared Key, Klartext über das Netzwerk übertragen. Das Key Management, insbesondere der Austausch des Pre-Shared Keys, ist nicht Inhalt dieses Projekts.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anforderungsspezifikation 22 / 68 Voice over IP security
3.5 Supportability Der Code soll so dokumentiert werden, dass er von Dritten verstanden, und falls gewünscht, erweitert werden kann. Es soll eine allgemeine, offene Struktur gewählt werden die einfach um weitere Funktionen erweitert werden kann.
3.6 Implementation Das Tool ist vollständig in C++ geschrieben und Open-Source verfügbar. Es kann für alle gängi- gen Linux Distributionen kompiliert werden. Das Endprodukt soll anfänglich als Patch für die aktuelle „KPhone“ Version zur Verfügung ste- hen. Wenn möglich, soll es schlussendlich in weiteren „KPhone“ Versionen integriert werden. Bei der Kompilation soll mittels Parameter die Einbindung der SRTP Erweiterung an- und abge- schaltet werden können.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anforderungsspezifikation 23 / 68 Voice over IP security
4 Use-Cases
4.1 Use-Cases Priorität 1
ID: UC01 Name: Pre-shared Key eintragen und speichern Actor: Benutzer Stakeholders and Inte- Der Benutzer will den Pre-Shared Key festlegen und speichern rest: Precondition: „KPhone“ ist installiert Postcondition: Der Pre-Shared Key ist gespeichert und steht für die Verbindung zur Verfügung Ablauf: Der Benutzer gibt eine beliebige Zahlenfolge ein. Der neue Key wird von KPhone übernommen Extensions:
ID: UC02 Name: Gesicherte Verbindung aktivieren Actor: Benutzer Stakeholders and Inte- Der Benutzer möchte „KPhone“ auf gesicherte Verbindung (SRTP) rest: einstellen Precondition: „KPhone“ ist installiert und UC01 wurde erfolgreich durchgeführt Postcondition: „KPhone“ verwendet für weitere Anrufe eine sichere Verbindung Ablauf: Benutzer aktiviert SRTP in KPhone KPhone speichert die Einstellung Extensions:
ID: UC03 Name: Gesicherte Verbindung aufbauen über SRTP Actor: Benutzer Stakeholders and Inte- Der Benutzer will ein gesichertes Gespräch durchführen rest: Precondition: UC02 wurde erfolgreich durchgeführt Postcondition: Gesicherte Verbindung über SRTP steht Ablauf: Benutzer verbindet sich mit einer SIP URI. Gesicherte Verbindung ist bereit Extensions: 2a) Key stimmt nicht überein 2b) Keine Kommunikation möglich
ID: UC04 Name: Gesicherte Verbindung beenden Actor: Benutzer Stakeholders and Inte- Der Benutzer will ein gesichertes Gespräch beenden rest: Precondition: UC03 wurde erfolgreich durchgeführt Postcondition: Gesicherte Verbindung wurde beendet Ablauf: Benutzer initiiert Verbindungsabbruch KPhone beendet Verbindung Extensions:
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Vergleich SIP Clients 24 / 68 Voice over IP security
VII Vergleich SIP Clients
1 Übersicht Als Grundlage für diese Studienarbeit müssen geeignete SIPv2 Clients evaluiert und ausgewer- tet werden. Dazu werden die Clients auf Zuverlässigkeit, Übertragungsqualität, Ergonomie und vor allem auf Sicherheit getestet. Die Sicherheit wird aufgeteilt in Authentisierung, Sicherung der Datenintegrität und Sicherung der Vertraulichkeit der Daten (Verschlüsselung). Die Voice over IP Kommunikation teilt sich Grundsätzlich in zwei Teile auf. Zuerst geschieht die Sessions-Initialisierung mit SIPv2. In dieser Phase werden neben anderen Parametern auch die symmetrischen Schlüssel für die sichere Datenübertragung ausgehandelt. Ein wichtiger Aspekt dieser Evaluation ist, ob und wie diese erste Phase nach obigen Kriterien gesichert wird. In der zweiten Phase, der eigentlichen Datenübertragungsphase werden die Pakete mit Hilfe des RTP Protokolls übertragen und können mit SRTP gesichert werden. Da wir momentan über kein geeignetes Tool zu Analyse von SRTP Paketen verfügen ist es schwierig ein solches zuverlässig zu erkennen. Meist weisen jedoch herkömmliche RTP Pakete eine gewisse Regelmässigkeit in Ihrer Payload auf. Z.B.: „..FFFFFEEE222555AAAAAA“. Das zu- gehörige verschlüsselte Paket hingegen kommt völlig zufällig daher „..3BA57AF8C2..“. Zudem lässt sich über die Paket Grösse erkennen, ob ein Paket einen Authentication Tag trägt oder nicht. Verschlüsselte Pakete sind ca. (4 oder 10 Byte) grösser als eine unverschlüsselte. Es kann aber auch verschlüsselte Pakete geben die gleich gross sind wie normale (ohne Authentication-Tag) jedoch nicht umgekehrt.
2 Minisip Minisip ist ein kleines Tool das viele Interessante Features aufweisst. Entwickelt: Royal Institute of Technology (KTH) Stockholm, Sweden Lizenz: GPL Link: www.minisip.org
Technik: • SIPv2 Session Initiation Protocol • SIP Protokoll wird nicht verschlüsselt • SIP Proxy Unterstützung (Authentication möglich) • Komplett unverschlüsselte Übertragung möglich • Pre-Shared Secret und Diffie-Hellmann (PKI Certificates) • SRTP Symmetric Key Exchange über Mikey (Multimedia Internet Keying) • SRTP Verschlüsselung und Authentizität (4Byte Auth-Tag) der Datenübertragung ist ge- währleistet. • TCP/TLS wird zwar angeboten, ist aber nicht implementiert • SIP, RTP und SRTP Übertragung ausschliesslich über UDP • NAT Traversal über STUN Server wird unterstützt (von uns nicht getestet)
Ergonomie: • Das UI ist übersichtlich, weisst jedoch einige kleinere Fehler auf • Tonqualität ist ausreichend und die Sprache ist gut verständlich • Es gibt praktisch keine Verzögerung • Es ist ein Telefonbuch vorhanden in dem beliebig viele Kontakte gespeichert werden können • Das Speichern mehrerer SIP Accounts ist möglich
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Vergleich SIP Clients 25 / 68 Voice over IP security
• Call List mit allen bisher getätigten Anrufen
Fazit: Minisip ist etwas aufwendig zum Installieren, da es verschiedenste Libraries benötigt, welche vorgängig installiert werden müssen. Einmal installiert läuft es jedoch tadellos. Die versproche- ne SRTP Verschlüsselung kann auf Wunsch zugeschaltet werden und erfüllt die Erwartungen. Der SRTP-Stack ist aber sehr stark mit der Programmlogik verwoben. Laut Aussage eines Ent- wicklers, lässt sich dieser gar nicht oder nur schwer abkoppeln. Leider hatten wir zudem kein Tool um SRTP genauer analysieren zu können.
Mögliche Erweiterungen: • S/MIME integrieren • TCP Support (eher unwichtig) • UI überarbeiten
3 KPhone KPhone ist ein Tool, das schon länger verfügbar ist und mittlerweile in der Version 4 vorliegt. Entwickelt: von Billy Biggs. Wird nun von Wirlab vertrieben. Lizenz: GPL Link: http://www.wirlab.net/kphone/index.html
Technik: • SIPv2 Session Initiation Protocol • SIP Protokoll wird nicht verschlüsselt • SIP Proxy Unterstützung (Authentication möglich) • Komplett unverschlüsselte Übertragung • Keinerlei Verschlüsselung wird angeboten • TCP wird zwar angeboten, ist aber schlecht implementiert. D.h. für jedes Packet wird ei- gene Verbindung geöffnet und gleich wieder geschlossen (UPD Konzept mit TCP) (siehe Abbildung 4: Schlechte Verwendung von TCP) • SIP und RTP Übertragung ausschliesslich über UDP • NAT Traversal über STUN Server wird unterstützt (von uns nicht getestet)
Abbildung 4: Schlechte Verwendung von TCP
Fazit: Kphone ist ein einfaches Tool, ohne jegliche Übertragungssicherheit, aber es funktioniert ein- fach. Es bietet Video-Telefonie an, diese Funktionalität haben wir jedoch nicht getestet. Das Tool arbeitet nach den gängigen Standards und würde sich gut für eine allfällige Erweiterung eignen.
Mögliche Erweiterungen: • TCP verbessern (eher unwichtig) • Security integrieren (SRTP)
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Vergleich SIP Clients 26 / 68 Voice over IP security
• Evtl. SIP Verschlüsselung mit S/MIME
4 Weitere Tools Im Rahmen dieser Evaluation haben wir auch weitere OpenSource Clients angeschaut (Liste auf http://www.uninett.no/voip/voipclients.html). Diese bieten jedoch gar keine Security und wir- ken vielfach nicht sehr viel versprechend oder sind nicht für Linux erhältlich.
5 Fazit der Evaluation Minisip hat die SRTP Sicherheit schon relativ souverän umgesetzt. Es ist jedoch bis jetzt das einzige Open Source SIPv2 Tool das diese Funktionalität mitbringt. Die Implementation lässt sich nur schwer auskoppeln und ist fast schon proprietär. Zudem ist der Client praktisch nicht verbreitet. KPhone hingegen erfreut sich weltweit unter Linux nutzern grosser Beliebtheit und es gibt bis anhin dafür noch keine SRTP Implementation.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Analyse 27 / 68 Voice over IP security
VIII Analyse
1 SRTP Integration
1.1 Allgemein Die Integration der SRTP Komponenten soll in KPhone möglichst wenig Spuren hinterlassen. Es wird darum eine Wrapper Klasse geschaffen, die sämtliche Koordination der Funktionen bezüg- lich SRTP übernimmt. Die Basismethoden protect (verschlüsseln) und unprotect (entschlüsseln) werden in KPhone an geeigneter stelle aufgerufen. KPhone soll möglichst wenig über die SRTP Klassen wissen, um die Kopplung gering zu halten. Von KPhone werden daher nur die Schnitt- stellenmethoden protect() und unprotect() des Wrappers verwendet. Die Erweiterung soll sich einfach ein- und ausschalten lassen, so kommen sämtliche beschriebenen SRTP Abläufe nur bei eingeschalteter Verschlüsselung zum Tragen. In den folgenden Beschreibungen wird angenommen, dass die Verschlüsselung auf beiden Sei- ten aktiviert und der Schlüssel gültig ist.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Analyse 28 / 68 Voice over IP security
1.2 Domain Model
Kphone SRTPWrapper libSRTP
+SRTPEnable:boolean +sk:Session_Kontext 0..1 +MasterKey:String 1 +Init(): +protect(p: RTP Packet):SRTP_Packet 1 0..1 +newSession():Session_Kontext +receive():SRTP_Packet +unprotect(p: SRTP_Packet):RTP_Packet +srtp_protect(p: RTP_Packet):SRTP_Packet +send(p: SRTP_Packet):vo +srtp_unprotect(p: SRTP_Packet):RTP_Pack
1.2.1 KPhone Attribute SRTPEnable • Verschlüsselung ein oder aus (true/false) MasterKey • Der Masterkey wird aus dem der Session Key abge- leitet. Methoden receive() • SRTP-Paket wird aus dem Netz empfangen send(SRTP_Packet) • Ein verschlüsseltes RTP-Paket (SRTP-Paket) wird an den Kommunikationspartner gesendet.
1.2.2 SRTPWrapper Attribute Session_Kontext • Der Session Kontext speichert die Informationen die für die Verbindung benötigt werden. D.h.: Er kann mehrere Streams speichern und die verwendetet MasterKeys. Zudem enthält er eine Cryptopolicy, wel- che Informationen über die Art der Verschlüsselung enthält. Methoden pro- • Gibt das unverschlüsselte RTP Paket an die SRTP tect(RTP_Packet) Library zur Verschlüsselung weiter. Ein SRTP Paket wird zurückgegeben. snprotect( • Gibt das verschlüsselte SRTP Paket an die SRTP Lib- SRTP_Packet) rary weiter. Ein RTP Packet wird zurückgegeben.
1.2.3 libSRTP Methoden init() • Initialisiert die Library (muss ausgeführt werden!) newSession() • Stellt einen Session Kontext zusammen. srtp_protect() • Verschlüsselt ein RTP Packet srtp_unprotect() • Entschlüsselt ein SRTP Packet
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Analyse 29 / 68 Voice over IP security
1.3 Verschlüsseltes Paket senden Die Audiodaten werden von KPhone mit dem entsprechend Codec codiert, mit den Stream In- formationen versehen und das fertige Paket schliesslich an den Socket weitergegeben. Kurz vor dem Socket greift die SRTP Erweiterung das Paket auf und gibt es weiter zur Verschlüsselung. Ist es das erste abgehende Paket und wurde bisher noch kein Paket empfangen, besteht noch keine Session. Die libSRTP muss in diesem Fall zuerst initialisiert und die Session erstellt wer- den. Dazu soll der MasterKey von dem der SEK (Session Encryption Key) für die aktuelle Session abgeleitet wird aus dem Konfigurationsfile von KPhone gelesen werden. Die libSRTP stellt nun aus den Informationen einen geeigneten Session-Kontext zusammen und stellt diesen der Wrapperklasse für weitere Verschlüsselungen zur Verfügung. Das RTP-Paket kann nun mittels srtp_protect() durch die libSRTP mit dem Session Key verschlüsselt werden. Über den Wrapper gelangt das verschlüsselte SRTP Paket an KPhone zurück, welches dieses nur noch abschicken muss. [Abbildung 5 und Abbildung 6] newRTPConnection()
Abbildung 5: Übersicht, Paket verschlüsseln
kphone wrapper Kphone SRTPWrapper libSRTP
1: protect(RTP Packet):SRTP_Packet 1.1:[noSessionAvailable] Init():
1.2:[noSessionAvailable] newSession():Session_Kontext
1.3: srtp_protect(RTP_Packet):SRTP_Packet
2: send(SRTP_Packet):void
Abbildung 6: Ablauf, Paket verschlüsseln Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Analyse 30 / 68 Voice over IP security
1.4 Paket empfangen KPhone empfängt ein verschlüsseltes SRTP Paket. Das Paket wird an den Wrapper weitergelei- tet. Ist es das erste eingehende Paket und wurde bisher auch noch kein Paket verschickt, besteht noch keine Session. Die libSRTP muss in diesem Fall zuerst initialisiert und die Session erstellt werden. Dazu soll der MasterKey von dem der SEK (Session Encryption Key) für die aktuelle Ses- sion abgeleitet wird aus dem Konfigurationsfile von Kphone gelesen werden. Daraus wird ein Session-Kontext erstellt. Das SRTP Paket wird zusammen mit dem aktuellen Session-Kontext über die Methode srtp_unprotect() der libSRTP zur Entschlüsselung weitergegeben. Diese überprüft die mit Hilfe des Session Authentication Keys die Authentizität des Pakets und entschlüsselt dieses mit Hilfe des SEK’s. Das so entstandene RTP Paket wird schliesslich an Kphone zur Weiterverarbeitung weitergegeben. [Abbildung 7 und Abbildung 8]
kphone
Paket_empfangen()
Initialization SRTP-Paket [yes] srtp_init(); unprotect(SRTP-Packet) [first Packet] newRTPConnection() 1. Initialize() [initalizes the library Must be executed prior to [no] any other command] kPhoneKonfigFile TEK:=readMasterKey()
New SRTPSession() configureStreamPolicy() SRTP-Paket addStream()
SRTP-Paket newRTPConnection() deriveKey()
Packet Encryption SRTP-Paket
unprotect() 1. srtpUnprotect(SessionKontext, RTPPaket ) srtp_unprotect()
[Decrypts the SRTP RTP-Packet Packet using Masterkey]
Abbildung 7: Übersicht, Paket entschlüsseln
kphone wrapper Kphone SRTPWrappe libSRTP
1: receive():SRTP_Packet
2: unprotect(SRTP_Packet):RTP_Packet 2.1:[noSessionAvailable] Init(): 2.2:[noSessionAvailable] newSession():Session_Kontext
2.3: srtp_unprotect(SRTP_Packet):RTP_Packet
Abbildung 8: Ablauf, Paket entschlüsseln
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Design 31 / 68 Voice over IP security
IX Design
1 Einleitung
1.1 Allgemein In diesem Dokument werden keine implementationstechnischen Details beschrieben, diese können den Sourcecodedateien und den darin enthaltenen Kommentaren entnommen werden. Es soll ein Überblick über Designentscheide und deren Implementation vermittelt werden.
2 Klassendiagramm
DspOut SRTPWrapper DspOutRtp -countInstances:int=0 -socket:UDPMessageSocket -instance:SRTPWrapper *=0 -portnum:int -libInit:bool=0 -packetbuf:unsigned char * -err_array:string [16]=0[16] -codec:codecType -sessionActive:bool -ssrc:int 0..1 -outboundStreamActive:bool -stunSrv:QString -inboundStreamActive:bool -wrapper:SRTPWrapper * -session:srtp_t -localSSRC:int +DspOutRtp(newCodec:cons +~DspOutRtp() +getInstance():SRTPWrapper * +writeBuffer():bool +protect(rtp_h:unsigned char *,length:int *):void +readBuffer(bytes:int):bool +unprotect(rtp_h:unsigned char *,length:int *):vo +setCodec(newCodec:const +dispose():void #SRTPWrapper() #~SRTPWrapper() QMutex -libError(err:err_status_t):void -getErrorname(err:err_status_t):string -newSession(p0:ssrc_t):void 0..1 +lock():void -SRTPWrapper(:const SRTPWrapper &) +unlock():void -readKey():octet_t *
libsrtp
+srtp_init():err_status_t +srtp_create(session:srtp_t *,policy:const srtp_policy_t *):err_status_t +srtp_protect(ctx:srtp_ctx_t *,rtp_hdr:void *,pkt_octet_len:int *):err_status_ +srtp_unprotect(ctx:srtp_ctx_t *,srtp_hdr:void *,pkt_octet_len:int *):err_stat +crypto_policy_set_rtp_default(p:crypto_policy_t *):void +crypto_policy_set_rtcp_default(p:crypto_policy_t *):void
Abbildung 9: Klassendiagram
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Design 32 / 68 Voice over IP security
2.1 Klasse SRTPWrapper
2.1.1 Allgemein Die Klasse SRTPWrapper kapselt die Library libsrtp und bietet so eine Schnittstelle für eine ein- fache Verwendung. Der SRTPWrapper abstrahiert dabei die internen Mechanismen der Library wie zum Beispiel das Setzen der Policy für die jeweilige SRTP Session, das Auslesen des SRTP Master Keys, sowie die Verwendung der korrekten Methoden für das Aufsetzen einer SRTP Ses- sion, die Verschlüsselung der RTP Pakete und die Entschlüsselung der SRTP Pakete. SRTPWrapper wird dabei durch das Singleton Pattern implementiert, somit ist pro KPhone In- stanz genau eine Instanz von SRTPWrapper verfügbar. Ein Pointer auf diese Instanz kann über die public Methode getInstance() geholt werden.
2.1.2 Methode newSession() Diese private Methode dient dazu, eine neue SRTP Session zu initialisieren. Sie ruft die Methode srtp_create() aus libsrtp auf. Parameter sind der Context (Handler) auf die SRTP Session, sowie die benötigte Policy welche den zu verwendenden Master Key beinhaltet.
2.1.3 Methode readKey() Dies ist eine private Methode. Sie liest den, in der Konfigurationsdatei von KPhone gespeicher- ten, SRTP Master Key ein und gibt einen Pointer darauf zurück. Die Konfigurationsdatei kann über eine Instanz der Klasse QSettings [QSettings] angesprochen werden, welche in allen gängigen Linux Distributionen vorhanden ist. Eine Beschreibung der Klasse QSettings findet man unter [QSettings]. Die Konfigurationsdatei heisst „kphonerc“ und befindet sich im Verzeichnis /usr/qt/3/etc/settings. Läuft KPhone nicht unter root, wird „kphonerc“ von der sich im Home- verzeichnis des jeweiligen Users im Unterordner „.qt“ befindenden „kphonerc“ überschrieben. Der Key kann in der jeweiligen „kphonerc“ unter dem Schlüssel SRTP als Attribut „KeyValue“ eingetragen werden:
[SRTP] KeyValue=SRTPMasterKey
Der SRTP Stack benötigt ein Master Key mit der Länge von 128 Bit, sowie ein Master Salt mit der Länge von 112 Bit um die Session Keys davon ableiten zu können. Bei libsrtp ist es folgendermassen: Sofern der eingegebene Master Key (aus der Konfigurations- datei) kleiner als die gesamten 240 Bit (128 Bit Key + 112 Bit Salt) ist, wählt libsrtp einen zufäl- ligen Salt und füllt mit diesem auf die 240 Bit auf. Dies ist jedoch problematisch da der Gegen- über sicher nicht mit dem gleichen Salt arbeitet, solange es nicht ausgetauscht wird. Um dies zu umgehen ist es nötig, einen 240 Bit langen Master Key einzulesen. Für den Benutzer ist es al- lerdings nicht zumutbar, einen Key mit 30 Zeichen Länge zu definieren. Deshalb wird der aus der Konfigurationsdatei eingelesene Master Key, sofern er nicht 240Bit lang ist, in der readKey() Methode immer mit 0 aufgefüllt und so an libsrtp übergeben.
2.1.4 Methode protect() Dieser public Methode wird ein Pointer auf das zu verschlüsselnde RTP Paket und ein Pointer auf dessen Länge übergeben. Die Methode ruft dann die srtp_protect() Methode von libsrtp an welche der Pointer weitergegeben wird. Nach erfolgreicher Verschlüsselung zeigt der Pointer auf den Anfang des SRTP Paketes, dass nun mit Hilfe der neuen Länge weiterverwendet werden kann.
2.1.5 Methode unprotect() Dieser public Methode wird ein Pointer auf das verschlüsselte SRTP Paket und ein Pointer auf dessen Länge übergeben. Die Methode ruft dann die srtp_unprotect() Methode von libsrtp an welche der Pointer weitergegeben wird. Nach erfolgreicher Entschlüsselung zeigt der Pointer auf
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Design 33 / 68 Voice over IP security den Anfang des RTP Paketes, dass nun mit Hilfe der neuen Länge weiterverwendet werden kann.
2.1.6 Methode getInstance() Diese statische Methode gibt den Pointer auf die Singleton Instanz der Klasse zurück. Bei jedem Aufruf wird ein Zähler erhöht um die Anzahl der gezogenen Instanzen zu speichern.
2.1.7 Methode dispose() Mittels der dispose() Methode, wird der Counter, der von getInstance hochgezählt wurde, wieder heruntergezählt. Wenn der Counter bei 0 ist, kann der Wrapper sich selbst löschen.
2.1.8 Methode getErrorname() Diese Methode gibt einen String zurück mit dem Namen des Fehlers, von welchem der Code als Parameter übergeben wird.
2.1.9 Methode libError() Diese Methode gibt die Fehlermeldung mit dem Fehlernamen, welcher sie durch den Aufruf der Methode getErrorname() erhält, auf den Standartoutput aus. Der Fehlercode der Library wird als Parameter übergeben.
2.2 Klasse DspOutRtp
2.2.1 Allgemein Diese Klasse sendet und empfängt die RTP Pakete in KPhone. Sie beinhaltet die dafür benötig- ten Sockets. Ausserdem beinhaltet sie einen Pointer auf die Singleton Instanz, unsere benannte Wrapper Klasse für den SRTP Stack. Es besteht für jeden RTP (SRTP) Stream eine Instanz dieser Klasse, die aber den gleichen Wrapper verwenden.
2.2.2 Methode writeBuffer() Diese Methode sendet die Pakete über einen Socket. Sie unterstützt ausserdem drei Audioco- decs, in welcher die Audiodaten unterschiedlich komprimiert werden. In dieser Methode erfolgt auch der Aufruf der protect() Methode des SRTPWrapper Objekts. Die- ser erfolgt kurz vor dem send() Aufruf des Socket Objektes.
2.2.3 Methode readBuffer() Diese Methode beinhaltet ein Socket zum Empfang der RTP Pakete. Nach dem Empfang wird der Audiocodec festgestellt und die Daten werden entsprechend behandelt. In dieser Methode erfolgt der Aufruf der unprotect() Methode, dies passiert kurz nach dem recei- ve() auf dem Socket Objekt. Dies muss vor der Weiterverarbeitung durch KPhone passieren, da kphone die verschlüsselten Daten nicht lesen kann.
2.2.4 Methode setCodec() Mittels dieser Methode wird der Codec mit dem KPhone arbeiten soll, gesetzt. Er wird in der lokalen Variable der DspOutRtp Instanz gespeichert und kann über das User Interface ausge- wählt werden.
2.3 SRTP Stack (Library) libsrtp
2.3.1 Allgemein Libsrtp ist eine reine C-Library, also vollständig nicht Objektorientiert. Sie bietet alle benötigten Funktionen um ein SRTP Session aufbauen zu können. Grundsätzlich wird die Library über die in der Datei srtp.h deklarierten Methoden angesprochen. Sie beinhaltet ebenfalls alle relevanten Datentypen und wird durch die Datei srtp.c implementiert. Um auf die Library zugreifen zu kön- Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Design 34 / 68 Voice over IP security nen, reicht es die Datei srtp.h zu includen. Es ist jedoch wichtig, dass die library unter /usr/local/lib installiert ist sowie die Headerdateien der Library unter /usr/local/include/srtp.
2.3.2 Methode init() Mit dieser Methode wird die ganze libsrtp zur Benutzung initialisiert. Sie muss vor allen anderen Methoden aufgerufen werden.
2.3.3 Methode srtp_protect() Diese Methode verschlüsselt die RTP Daten auf die der übergebene Pointer zeigt, anhand des ebenfalls übergebenen Session Context (beinhaltet Policy mit SRTP Master Key).
2.3.4 Methode srtp_unprotect() Diese überprüft den Authentication Header des SRTP Paketes auf welchen der übergebenen Pointer zeigt, entfernt ihn und entschlüsselt das Paket anhand des übergebenen Session Con- text, der die Policy mit SRTP Master Key beinhaltet. Falls es sich bei dem übergebenen Paket nicht um ein Verschlüsseltes handelt, sondern um ein ganz normales RTP Paket ohne Authentication Header, unternimmt die Library nichts und das Paket kann unverändert weiterverarbeitet werden. Stimmt der Authentication Header nicht, wird eine Ausnahmebehandlung ausgelöst. In beiden Fällen wird ein entsprechender Fehler Code zurückgegeben.
2.3.5 Methode srtp_create() Diese Methode baut eine neue SRTP Session auf. Es wird ihr ein Pointer auf den Session Con- text mitgegeben, sowie die zu verwendende Policy.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Design 35 / 68 Voice over IP security
3 Systemarchitektur
3.1 Systemoperationen
3.1.1 RTP Paket in SRTP Paket verschlüsseln
dsp wrapper mutex DspOutRtp SRTPWrapper QMutex libsrtp
1: protect(unsigned char *,int *):void 1.1:[sessionActive == false] lock():void
1.2:[sessionActive == false] newSession(ssrc_t):void
1.2.1: crypto_policy_set_rtp_default(crypto_policy_t *):void 1.2.2: crypto_policy_set_rtcp_default(crypto_policy_t *):void
1.2.3: readKey():octet_t *
1.2.4: srtp_create(srtp_t *,const srtp_policy_t *):err_status_t
1.3: unlock():void
1.4: srtp_protect(srtp_ctx_t *,void *,int *):err_status_t
Abbildung 10: Paket verschlüsseln
Eine Instanz der Klasse DspOutRtp aus KPhone, ruft die Methode protect() der Singleton Instanz der Klasse SRTPWrapper auf. Dabei wird ein Pointer auf das RTP Paket sowie die Länge des Paketes angegeben. Die Singleton Instanz überprüft, ob bereits eine bestehende SRTP Session vorhanden ist. Falls keine Session vorhanden ist, wird eine Session Policy erstellt, für welche der SRTP Master- key aus dem Konfigurationsfile von KPhone gelesen wird. Dazu wird die Methode readKey() auf- gerufen, welche einen Pointer auf den Key zurückliefert. Nun wird eine neue SRTP Session er- stellt, indem die Methode srtp_create() von libsrtp (SRTP Library) augerufen wird. Ist eine Session vorhanden, wird die Methode srtp_protetct() aufgerufen, welcher der Pointer auf den Session Context, der Pointer auf das RTP Paket, sowie die Länge des Paketes mitgegeben wird. Die Library verschlüsselt nun das Paket, danach wird es von KPhone versendet.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Design 36 / 68 Voice over IP security
3.1.2 SRTP Paket in RTP Paket entschlüsseln
dsp wrapper mutex DspOutRtp SRTPWrapper QMutex libsrtp
1: unprotect(unsigned char *,int *):void 1.1:[sessionActive == false] lock():void
1.2:[sessionActive == false] newSession(ssrc_t):void
1.2.1: crypto_policy_set_rtp_default(crypto_policy_t *):void 1.2.2: crypto_policy_set_rtcp_default(crypto_policy_t *):void
1.2.3: readKey():octet_t *
1.2.4: srtp_create(srtp_t *,const srtp_policy_t *):err_status_t
1.3: unlock():void
1.4: srtp_unprotect(srtp_ctx_t *,void *,int *):err_status_t
Abbildung 11: Paket entschlüsseln
Eine Instanz der Klasse DspOutRtp aus KPhone, ruft die Methode unprotect() der Singleton In- stanz der Klasse SRTPWrapper auf. Dabei wird ein Pointer auf das empfangene SRTP Paket sowie die Länge des Paketes angegeben. Die Singleton Instanz überprüft, ob bereits eine bestehende SRTP Session vorhanden ist. Falls keine Session vorhanden ist, wird eine Session Policy erstellt, für welche der SRTP Master- key aus dem Konfigurationsfile von KPhone gelesen wird. Dazu wird die Methode readKey() auf- gerufen, welche einen Pointer auf den Key zurückliefert. Nun wird eine neue SRTP Session er- stellt, indem die Methode srtp_create() von libsrtp (SRTP Library) augerufen wird. Ist eine Session vorhanden, wird die Methode srtp_unprotect() aufgerufen, welcher der Pointer auf den Session Context, der Pointer auf das RTP Paket sowie die Länge des Paketes mitgege- ben wird. Die Library entschlüsselt nun das Paket, danach wird es von KPhone weiter verarbeitet.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Design 37 / 68 Voice over IP security
4 KPhone Erweiterung
4.1 Allgemein Es ist wichtig, dass KPhone so wenig wie möglich angepasst werden muss. Es ist jedoch unum- gänglich, an einigen Stellen zusätzlichen Code anzubringen, um die Wrapper Klasse SRTPWrap- per zu integrieren. Auch in der grafischen Oberfläche sind wenige Erweiterungen hinzugekommen. Die Erweiterungen im Detail, sind im Dokument KPhone Anpassungen ersichtlich.
4.2 Klasse DspOutRtp Grundsätzlich gibt es in KPhone genau eine Klasse zu erweitern, um die Grundfunktionalität von SRTP zu implementieren. Die Klasse „DspOutRtp“. Diese ist für das Senden und Empfangen der Daten (RTP Pakete) verantwortlich. Dieser Klasse wird zusätzlich ein Pointer auf die Singleton Instanz von SRTPWrapper als lokale Variable angefügt. Die Deklaration der Klasse sowie der Variabeln, findet sich in der Datei dspoutrtp.h, die Implementation in der Datei dspoutrtp.cpp. Der Pointer auf die Wrapper Instanz erfolgt im Konstruktor der Klasse DspOutRtp. Bevor dieser jedoch initialisiert wird, wird in der Konfigurationsdatei nachgeprüft ob SRTP eingeschaltet ist oder nicht. Falls SRTP nicht eingeschaltet ist, wird der Pointer mit 0 initialisiert. Anderenfalls wird er mir der Adresse der Singleton Instanz initialisiert (getInstance() auf SRTPWrapper). Im Destruktor der Klasse DspOutRtp wird durch den Aufruf der dispose() Methode der Singleton Instanz das Objekt vernichtet. Die dispose() Methode wird nur aufgerufen, wenn der Pointer nicht mit 0 initialisiert ist. Zudem werden, wie oben bereits beschrieben, die Methoden readBuffer() und writeBuffer() mit einigen Code Fragmenten erweitert.
4.3 User Interface Damit der SRTP Master Key nicht direkt in der Konfigurationsdatei eingeben werden muss, wird die graphische Oberfläche um ein Eingabefeld für diesen Key erweitert. Zusätzlich wird dem Benutzer ebenfalls ermöglicht, die Benutzung von SRTP ein- und auszuschalten, dies ebenfalls in der grafischen Oberfläche mittels Radiobuttons. Diese Erweiterungen finden alle in der Klasse KSipPreferences statt, welche durch das Eigen- schaften-Fenster (abgeleitet von QTabDialog) repräsentiert wird. Das gesamte GUI ist in QT pro- grammiert.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Design 38 / 68 Voice over IP security
5 Fehlerbehandlung
5.1 Allgemein Die Fehlerbehandlung soll so gehalten werden, dass im Fehlerfall soweit wie möglich klare Feh- lermeldungen ausgegeben werden. Geschieht ein Fehler in der libsrtp, soll dieser wenn Möglich interpretiert, ansonsten mindestens der Fehlercode von libsrtp ausgeben werden. Durch die Art wie der Wrapper in KPhone integriert wurde, ist es nicht ohne weiteres möglich im Fehlerfall, den Verbindungsaufbau zu unterbrechen. Daher wird bei Problemen in der Regel le- diglich eine Fehlermeldung ausgegeben und die Verbindung dennoch aufgebaut. Unter Umstän- den ist aber dann eine Kommunikation mit dieser Verbindung nicht möglich.
5.2 Fehlerbehandlung im SRTP-Wrapper
5.2.1 Konstruktor Es beginnt bereits beim Aufruf, der srtp_init() Methode der SRTP Library. Diese Methode liefert einen Error Code zurück welcher, falls die Methode fehlschlägt, auf einen bestimmten Fehler hinweist. Tatsache ist, dass wenn diese Methode fehlschlägt, die Library nicht funktionsfähig ist und somit keine Kommunikation über SRTP stattfinden kann. Deshalb haben wir uns entschie- den, im Falle des Fehlschlagens von srtp_init(), KPhone zu beenden.
5.2.2 NewSession Der Aufruf zum Erstellen einer neuen Session kann bei libsrtp Fehler erzeugen. Diese werden an die Methode libError() weitergegeben. Wenn das Erzeugen der Session nicht erfolgreich war, wird beim nächsten empfangenen oder gesendeten RTP/SRTP-Packet ein neuer Versuch ge- startet.
5.2.3 Protect/Unprotect Fehler können hier beim Aufruf der libsrtp Funktionen passieren. Der Fehler wird in diesem Fall registriert und an die Methode libError() weitergegeben, welche die Fehler ausgibt. Die Applika- tion läuft aber weiter.
5.2.4 readKey Hier wird ein Wert aus dem KPhone-Konfigurationsfile gelesen. Ist der Wert oder das File nicht vorhanden wird ein Fehler angezeigt und die Initialisierung abgebrochen. Programm wird been- det, da die Session nicht mehr initialisiert werden kann.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Softwaredokumentation 39 / 68 Voice over IP security
X Softwaredokumentation
1 Einleitung Dieses Dokument beschreibt die in der Studienarbeit 2 entwickelte Erweiterung an der VoIP Software „KPhone“ für Linux. KPhone ist ein populärer VoIP SIPv2 Client, welcher als Uebertra- gungsprotokoll RTP verwendet. Geschrieben wurde er vollständig in C++. Die entwickelte Erwei- terung beinhaltet die verschlüsselte und sichere Übertragung der Sprachdaten mittels SRTP.
2 Business Logik Die SRTP Erweiterung von KPhone besteht grundsätzlich aus der Library libsrtp. Diese Library implementiert den ganzen SRTP-Stack in der Programmiersprache C und ist unter der BSD Li- zenz frei verfügbar. KPhone benutzt diese Library zur Verschlüsselung der Sprachdaten, sendet also die Daten sicher via SRTP und nicht mehr via RTP.
2.1 Schnittstelle zur SRTP Library Damit KPhone diese Library verwenden kann, wurde eine Wrapper-Klasse in C++ entwickelt, die Klasse „SRTPWrapper“. Diese Klasse bietet KPhone ein Interface um auf die SRTP Library zugreifen zu können. Sie stellt die wichtigsten Methoden zur Verfügung: protect(Daten) und unprotect(Daten). KPhone ruft die Methoden der Instanz der Wrapper-Klasse auf und übergibt jeweils die Daten (Pakete). Die SRTPWrapper Instanz übernimmt die gesamten notwendigen Schritte um die Daten zu verschlüsseln, konkret die gesamte Kommunikation mit der SRTP Lib- rary. Dies beinhaltet zum Beispiel den Aufbau einer Session, den Aufbau eines Streams und das ver- und entschlüsseln eines Pakets. Libsrtp ist aus der Sicht von KPhone eine so genannte Black-Box. Technische Details sind im Dokument Design.doc ersichtlich.
2.2 Sicherheit
2.2.1 Technische Daten Die SRTP Erweiterung benutzt die libsrtp mit den in RFC3711 festgelegten default Werten. Art: Grösse: Verschlüsselung AES counter mode 128Bit Authentifizierung SHA1 Hash mit HMAC 80Bit (nur 32Bit verwendet) Key derivation AES counter mode 128Bit Tabelle 3:verwendete Werte
Detailliertere Daten über das SRTP Protokoll, können dem Dokument SRTP.doc entnommen werden.
2.2.2 Kompromisse Bei der Entwicklung der SRTP Erweiterung mussten, aufgrund des fehlenden Key Managements, gewisse Kompromisse betreffend Sicherheit gemacht werden. Diese haben jedoch nur sehr ge- ringfügige Auswirkungen und sind darum nur beschränkt relevant.
SSRC Jede VoIP Quelle erhält laut Standard (RFC’s) eine SSRC durch welche sie eindeutig identifiziert wird. KPhone selber vergibt jedoch an alle Quellen dieselbe SSRC. Dies spielt bei der Verwen- dung von RTP grundsätzlich keine Rolle. Wird aber SRTP verwendet (insbesondere die Library Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Softwaredokumentation 40 / 68 Voice over IP security libsrtp), ist es notwendig, dass jede Quelle eine Einzigartige SSRC besitzt. Deshalb weist die SRTP Erweiterung (Wrapper-Klasse) jeder Quelle eine zufällige SSRC zu, diese wird allerdings nicht auf ihre Einzigartigkeit überprüft und so könnte es- mit einer sehr kleinen Wahrscheinlich- keit denn die SSRC besitzt 32Bit- vorkommen, dass eine bereits verwendete SSRC an eine an- dere Quelle vergeben wird. Das würde bedeuten, dass wenn zusätzlich noch derselbe SRTP Ses- sion Key und das gleiche Salz verwendet würden, ein gleiches Keystream-Segment erzeugt werden könnte. Eine solche Kollision begünstigt gewisse Angriffe auf die Chiffrierung [MF00].
Stateless Um eine vollumfängliche Sicherheit garantieren zu können, sollten gewisse Daten wie z. B. der Zähler der Pakete gespeichert werden um eine zu häufige Verwendung des Master Keys zu ver- hindern.
Key derivation rate Ein weiteres (sehr kleines) Sicherheitsrisiko besteht darin, dass der Schlüssel während einer Session nie ausgewechselt wird. Dies ist vom SRTP her nicht zwingend notwendig und deshalb in der libsrtp auch nicht implementiert, also die derivation rate ist Null. Dies kann dazu führen, dass nach Ablauf einer gewissen Zeit (248 SRTP Pakete oder 231 SRTCP Pakete) die Zähler wie- der bei Null anfangen und deshalb die gleichen Keystreams verwendet werden. So könnten Wiederholungen festgestellt werden und Rückschlüsse auf den Key gemacht werden. Bei 200 SRTCP Pakete pro Sekunde wäre dies jedoch erst nach rund 4 Monaten ununterbrochener Kommunikation der Fall.
Master Salt Ein weiterer Kompromiss wurde mit der Festlegung des Master Salt gemacht. Vom Standard gegeben wird, dass das Master Salt zufällig gewählt werden soll. In der SRTP Erweiterung von KPhone jedoch, ist das Master Salt hart einprogrammiert, es ist also immer gleich. Dies hat den Vorteil, dass das Salt nicht mit dem zu kommunizierenden Partner ausgetauscht werden muss, denn es ist ja bei allen gleich. Die Trennung von Session- und Master Key hat im Grunde den Sinn den Schaden, den ein kom- promittierter Session Key anrichtet, zu Beschränken. So können vom Angreifer nur die Pakete gelesen werden, die von genau diesem Session Key verschlüsselt wurden. Der Master Key und damit alle anderen von ihm abgeleiteten Session Keys bleiben sicher. In dieser Implementation wird jedoch immer das gleiche Master Salt verwendet, da kein Mana- gement für den Austausch desselben integriert ist. Das heisst vom gleichen Master Key wird in jedem Fall immer der gleiche Session Key erzeugt. Es könnten also von einem Angreifer im falle eines gebrochenen Schlüssels alle Pakete gelesen werden die mit diesem Master Key ver- schlüsselt wurden.
Keylänge Der Session Key wird bekanntlich aus dem 128Bit Master Key und dem 112Bit Salt gebildet. Wenn nun der vom Benutzer eingegebene Master Key kleiner als 30 Zeichen lang ist <240Bit, wird der Rest mit 0 aufgefüllt. Das heisst wie oben beschrieben, ist das ganze Salz 0. Wenn der Master Key kleiner als 16 Zeichen ist, wird dieser (wie das Salt) auch mit 0 ergänzt. Der Schlüs- sel wird somit schwächer. Also reicht im Gunde die Eingabe eines 16 Zeichen langen Keys, ob- schon das Master Salt in dieser Implementation genauso geheim ist wie der Master Key selbst und damit auch etwas zur Sicherheit beiträgt. Uebersteigt der eingegebene Master Key die Länge von 30 Zeichen, ist es nicht notwendig, 0 einzufügen. Das Salt wird in diesem Falle auch durch den Benutzer definiert. Der Benutzer wird daher vor jeder Verbindung mit einem schwachen Key, über eine Warnung darauf hingewiesen.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Softwaredokumentation 41 / 68 Voice over IP security
2.3 QT Multithreading KPhone verwendet, falls dies von der darunter liegenden Plattform unterstützt wird, QT Mul- tithreading. Anderenfalls wird mit nur einem Thread gearbeitet, was auch funktioniert, wobei jedoch das GUI schlecht reagiert, da es nicht zu jeder Zeit Antworten entgegen nehmen kann. Wird QT Multithreading unterstützt, arbeitet grundsätzlich ein Thread pro Stream. Das heisst pro Quelle ein Thread.
2.3.1 Konsequenzen Was hat die Verwendung QT Multithreading für Konsequenzen für die Programmierung der SRTP Wrapper Klasse? Die korrekte Benutzung von libsrtp schreibt einen Sessionaufbau vor. Diese Session muss von einem der Threads aufgebaut werden. Ist die Session einmal aufgebaut, können in dieser die Streams integriert werden. Wichtig ist, dass die Session nur einmal aufgebaut wird, anderenfalls gibt es einen Fehler, welcher dazu führen kann, dass das Programm abstürzt. Deshalb wird nach einem erfolgreichen Aufbau, ein Flag gesetzt. Es könnte daher zu der Situation kommen, dass der eine Thread erfolgreich eine Session aufgebaut hat, jedoch das Flag noch nicht setzen konn- te, bevor ein Threadwechsel stattfindet. Um dies zu verhindern, muss der Sessionaufbau sowie das Setzen des Flags, unter gegenseitigem Ausschluss (Mutex) stattfinden. Dies wurde im Wrapper so implementiert.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Softwaredokumentation 42 / 68 Voice over IP security
3 GUI Das GUI wurde soweit erweitert, dass es möglich wird den zur Verwendung von SRTP benötigten Master Key via GUI einzutragen. Auch ist es möglich, die SRTP Unterstützung ein oder auszu- schalten. Ist sie ausgeschaltet, wird wie ursprünglich das RTP Protokoll zum Senden der Sprach- daten verwendet.
Abbildung 12: SRTP GUI
Das oben abgebildete Fenster ist im Hauptfenster von KPhone über das Menü „Preferences- >SIP Preferences…“ erreichbar.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security User Manual 43 / 68 Voice over IP security
XI User Manual
1 Installation
1.1 Allgemein KPhone wird gleich wie alle andern gängigen Programme unter Linux installiert. Es kann von http://www.wirlab.net/kphone downgeloadet werden. Es wird davon ausgegangen, dass die SRTP Erweiterung in KPhone integriert ist. Sollte dies nicht der Fall sein, so muss KPhone nach dem Herunterladen mit dem Patch für die SRTP Erweite- rung versehen werden. Dies zieht mit sich, dass im KPhone Verzeichnis nach dem Ausführen des Patchs, „autoconf“ ausgeführt werden muss.
1.2 Voraussetzungen Falls die SRTP Erweiterung bei der Kompilation in KPhone integriert werden soll so ist es not- wendig, dass die SRTP Library „libsrtp“ (libsrtp.a) im Verzeichnis /usr/local/lib vor- handen ist. Die Headerdateien müssen im Verzeichnis /usr/local/include/srtp vorhan- den sein. Es kann also der ganze Inhalt des Ordners „include“ aus dem Verzeichnis der Library in den genannten Pfad kopiert werden. Die Library kann von http://srtp.sourceforge.net/srtp.html downgeloadet werden.
1.3 Schrittweise 1) KPhone Archiv entpacken und entzippen tar –xvzf „kphone-X.X.X.tar.gz“ 2) In das erstellte Verzeichnis wechseln und das configure Skript ausführen. ./configure Falls KPhone mit SRTP Unterstützung kompiliert werden soll muss folgende Option hin- zugefügt werden (Voraussetzungen müssen erfüllt sein): ./configure –-enable-srtp oder –-enable-srtp=yes Wird das Konfigurationsskript ohne Parameter ausgeführt, ist die SRTP Unterstützung nicht integriert. 3) Nun mit make das Programm kompilieren (optional auch make install, kopiert aus- führbare Datei nach /usr/local/bin). 4) Nun ist KPhone zur Benutzung bereit.
1.4 Konfiguration Zu konfigurieren gibt es nicht sehr viel, beim ersten Aufstarten muss ein Profil angelegt werden. Das heisst es muss ein Name angegeben werden sowie die SIP URL.
1.4.1 SRTP Diese Einstellungen können nur getätigt werden, falls KPhone mit SRTP Unterstützung installiert wurde. Im Preferences Menü, kann der SRTP Master Key festgelegt und auch die Wahl getroffen wer- den, ob SRTP verwendet wird oder nicht. Beim Betrieb über SRTP ist es wichtig, dass der Ge- genüber den genau gleichen Master Key verwendet. Andernfalls können die Audiodaten nicht entschlüsselt werden und es ist nur ein Rauschen aus den Lautsprechern zu hören. Ein ähnli- ches Verhalten tritt auch dann auf, wenn der eine Gesprächspartner die Benutzung von SRTP aktiviert hat der andere jedoch nicht.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security User Manual 44 / 68 Voice over IP security
1.4.2 Audio Ebenfalls im Preferences Menü, kann zwischen drei verschiedenen Audiocodecs gewählt wer- den. Die Unterschiede werden an dieser Stelle nicht näher erläutert. Auch hier ist es wieder wichtig, dass beide Gesprächspartner den gleichen Codec verwenden.
1.4.3 Netzwerkprotokoll Ausserdem kann im Menü Preferences auch ausgewählt werden, ob SIP über TCP oder UDP laufen soll.
2 Grundsätzliches Der Grundsatz bestand darin, möglichst wenige Dateien (Klassen) von KPhone zu verändern. Zusätzlich wird der hinzugefügte Code in Präprozessorbedingungen eingepackt, und kann so mittels Argument (--enable-srtp) beim Konfigurationsskript ein- und ausgeschaltet werden. Per Default ist die Integration von SRTP ausgeschaltet, das heisst wenn bei der Ausführung des Kon- figurationsskriptes kein Argument angegeben wird, wird der SRTP Code nicht integriert.
Alle unten beschriebenen Modifikationen gelten ausschliesslich für die KPhone Version 4.1.1.
3 Betroffene Dateien
3.1 Konfigurations Skript und Makefiles
3.1.1 Datei configure.in Einige Änderungen finden auch im Konfigurationsskript statt. Diese sind in der Datei configu- re.in getätigt worden.
Für den Fall das QT Multithreading unterstützt ist, muss ein spezielles Kompilerflag gesetzt wer- den, da in der Klasse SRTPWrapper die Klasse QMutex benötigt wird. Dieses Flag muss im Ma- kefile des srtp Unterverzeichnisses gesetzt werden. In dieser Makedatei befindet sich die Variab- le @THREAD_FLAG@, welche vom Konfigurationsskript durch den zugewiesenen Wert ersetzt wird (Kompilerflag). Falls Multithreading nicht unterstützt wird, bleibt die Variable leer. 98: THREAD_FLAG=“-DQT_THREAD_SUPPORT“ 99: AC_SUBST(THREAD_FLAG) … 102: else 103: THREAD_FLAG=““ 104: AC_SUBST(THREAD_FLAG)
Wie oben schon genannt, kann mittels Argument angeben werden, ob SRTP verwendet werden soll oder nicht. Zudem ist es notwendig eine Präprozessorvariable (SRTP) zu definieren, welche anzeigen soll, ob der SRTP Code mit kompiliert werden soll oder nicht, sie wird in den Präpro- zessorbedingungen überprüft. Ebenfalls befindet sich in einigen Makefile.in Dateien die Variable @ENABLE_SRTP@, welche durch das Konfigurationsskript mit dem darin enthaltenen Wert ersetzt werden. 109: AC_MSG_CHECKING(whether to enable srtp) 110: srtp_default=”no” 111: AC_ARG_ENABLE(srtp, [ --enable-srtp=[no/yes] use SRTP 112: [default=no]],, enable_srtp=$srtp_default) 113: 114: if test „$enable_srtp“ = “yes“; then 115: AC_DEFINE(SRTP) 116: ENABLE_SRTP=“yes“ 117: AC_SUBST(ENABLE_SRTP) Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security User Manual 45 / 68 Voice over IP security
118: AC_MSG_RESULT(yes) 119: else 120: AC_MSG_RESULT(no) 121: fi
In diesen Zeilen wird festgelegt ob das Makefile des srtp Unterverzeichnisses auch dazugehört oder nicht, je nachdem ob SRTP aktiviert wurde oder nicht. 207: if test “$enable_srtp” = “yes”; then 208: srtp_make=srtp/Makefile 209: else 210: srtp_make=““ 211: fi 212: 213: AC_OUTPUT(Makefile kphone/Makefile dissipate2/Makefile … $srtp_make)
3.1.2 Datei config.h.in Um eine Definition einer Präprozessorvariable zu ermöglichen, ist eine zentrale Headerdatei config.h vorhanden. Damit das Konfigurationsskript den Eintrag in config.h auch erstellt ist es nötig, die Variable in der Datei config.h.in zu deklarieren. 12: #undef SRTP
3.1.3 Datei Makefile.in Diese Datei muss aufgrund des Verzeichnisses ’srtp’ welches neu hinzukommt, angepasst wer- den. Wie oben bereits erwähnt, wird die Variable @ENABLE_SRTP@ vom Konfigurationsskript ersetzt, falls SRTP aktiviert ist mit „yes“. 1: ifeq (@ENABLE_SRTP@,yes) 2: SUBDIRS=po dissipate2 gsm ilbc srtp kphone 3: else 4: SUBDIRS=po dissipate2 gsm ilbc kphone 5: endif
3.1.4 Datei kphone/Makefile.in Im Makefile.in des Unterverzeichnisses „kphone“, sind ausserdem noch zusätzliche Äenderun- gen notwendig. Es muss hier noch das Verzeichnis, in welchem sich die Headerdateien von libsrtp befinden, angegeben werden. 11: ifeq (@ENABLE_SRTP@,yes) 12: CFLAGS=-I/usr/local/include/srtp –I- @CFLAGS@ -I. –i../gsm … 13: else 14: CFLAGS=@CFLAGS@ -I. –I../gsm … 15: endif
Die Library libsrtp selbst muss auch noch angegeben werden. 17: ifeq (@ENABLE_SRTP@,yes) 18: LIBS=@LIBS@ -lssl –lcrypto –lresolv –lsrtp @LIBJACK@ @LIBALSA@ 19: else 20: LIBS=@LIBS@ -lssl –lcrypto –lresolv @LIBJACK@ @LIBALSA@ 21: endif
Die Library der Klasse SRTPWrapper muss separat angegeben werden. 20: ifeq (@ENABLE_SRTP@,yes) 21: SUBLIBS=dissipate2 gsm ilbc srtp 22: else 23: SUBLIBS=dissipate2 gsm ilbc 24: endif
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security User Manual 46 / 68 Voice over IP security
3.2 Sourcecode
3.2.1 Business Layer In der Logik wurde die Instanz der Klasse SRTPWrapper der Klasse von kphone verfügbar ge- macht, welche direkt über die Sockets die Daten sendet und empfängt. Unmittelbar vor dem Senden und Empfangen, werden dann, sofern SRTP aktiviert ist, die Methoden zur Verschlüsse- lung (SRTPWrapper) aufgerufen.
Betroffen ist die Klasse DspOutRtp. Deklaration in der Datei dspoutrtp.h 14: #include “../config.h” 15: #ifdef SRTP 16: #include „../srtp/SRTPWrapper.h“ 17: #endif … 120: #ifdef SRTP 121: SRTPWrapper* wrapper; 122: #endif In dieser Datei muss config.h eingebunden werden damit die Präprozessorvariable „SRTP“ ü- berprüft werden kann.
Implementation in der Datei dspoutrtp.cpp 42: #ifdef SRTP 43: QSettings settings; 44: if(settings.readEntry(„/kphone/SRTP/Enable“, „“) == „Yes“){ 45: wrapper = SRTPWrapper::getInstance(); 46: } else{ 47: wapper = 0; 48: } 49: #endif … 94: #ifdef SRTP 95: if(!wrapper == 0){ 96: wrapper->dispose(); 97: } 98: #endif … 201: #ifdef SRTP 202: int* length = new int(sizeof( rtp_hdr_t ) + tmpsize); 203: if(!wrapper == 0){ 204: wrapper->protect(packetbuf, length); 205: } 206: if( socket->send( (char *) packetbuf, *length) < 0) { 207: #else 208: if( socket->send( (char *) packetbuf, siezof( rtp_hdr_t ) + tmpsi… 209: #endif … 248: #ifdef SRTP 249: int* length = new int(sizeof( rtp_hdr_t ) + tmpsize); 250: if(!wrapper == 0){ 251: wrapper->protect(packetbuf, length); 252: } 253: if( socket->send( (char *) packetbuf, *lenght) < 0 ) { 254: #else 255: if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + tmpsi… 256: #endif … 309: #ifdef SRTP 310: int* length = new int(sizeof( rtp_hdr_t ) + fixedrtplen); 311: if(!wrapper == 0){ 312: wapper->protect(packetbuf, length); 313: } 314: if( socket->send( (char *) packetbuf, *length ) < 0 ) {
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security User Manual 47 / 68 Voice over IP security
315: #else 316: if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) fixedrtp… 317: #endif … 379: #ifdef SRTP 380: if(!wrapper == 0){ 381: int* length = new int(recvsize); 382: wrapper->unprotect(packetbuf, length); 383: recvsize = *length; 384: } 385: #endif
3.2.2 GUI Im GUI wurde im Menü „Preferences“ ein neuer Reiter hinzugefügt in welchem SRTP ein- oder ausgeschaltet werden kann und in welchem sich auch der SRTP Master Key eintragen lässt.
Betroffen ist die Klasse KSipPreferences. Deklaration in der Datei ksippreferences.h 8: #include “../config.h” … 34: #ifdef SRTP 35: enum Srtp { enableSRTP, disableSRTP }; 36: #endif … 59: #ifdef SRTP 60: QButtonGroup* srtp; 61: QLineEdit* masterKey; 62: #endif Auch hier ist das Einbinden von config.h notwendig, damit die Präprozessorvariable „SRTP“ ü- berprüft werden kann.
Implementation in der Datei ksippreferences.cpp 52: #ifdef SRTP 53: QVBox* sboxs = new QVBox(); 54: sboxs->setFixedHeight(100); 55: addTab( sboxs, “SRTP”); 56: 57: srtp = new QHButtonGroup( tr(“SRTP”), sboxs ); 58: QRadioButton* enabled = new QRadioButton( tr(“Enable SRTP”), srtp ); 59: srtp->insert( enabled, enableSRTP ); 60: QRadioButton* disabled = new QRadioButton( tr(“Disable SRTP”), srtp); 61: srtp->insert( disabled, disableSRTP ); 62: 63: (void) new QLabel( tr(“SRTP Master Key (length 30 char…):”), sboxs ); 64: masterKey = new QLineEdit( sboxs ); 65: #endif .. 214: #ifdef SRTP 215: switch( srtp->id( srtp->selected() ) ) { 216: case enableSRTP: 217: Settings.writeEntry( “/kphone/SRTP/Enable”, “Yes”); 218: break; 219: default: 220: settings.writeEntry( “/kphone/SRTP/Enable”, “No”); 221: break; 222: } 223: settings.writeEntry( “/kphone/SRTP/KeyValue”, masterKey->text() ); 224: #endif … 312: #ifdef SRTP 313: if(settings.readEntry(“/kphone/SRTP/Enable”, “No”) == “Yes”) { 314: srtp->setButton( enableSRTP ); 315: } else { 316: srtp->setButton( disableSRTP ); 317: } 318: Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security User Manual 48 / 68 Voice over IP security
319: masterKey->setText( settings.readEntry( “/kphone/SRTP/KeyValue”,“”)); 320: #endif
3.2.3 Zusätzliche Dateien Mit der SRTP Erweiterung kommt das zusätzliche Verzeichnis „srtp“ in de KPhone Verzeichnis- struktur (Ersichtlich in Abbildung 13). Dieses enthält die Klasse SRTPWrapper, welche aus zwei Dateien besteht. Die Deklaration (Interface) befindet sich in der Datei SRTPWrapper.h die Imple- mentation in der Datei SRTPWrapper.cpp. Zusätzlich ist im Verzeichnis noch eine Makfile.in Datei enthalten aus welcher das Makefile für dieses Verzeichnis erstellt wird.
Abbildung 13: SRTP Folder
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Glossar 49 / 68 Voice over IP security
XII Glossar
1 Stichwortverzeichnis Abkürzung Ausdruck Beschreibung AES Advanced Encryption Standard Dieser Standard legt fest wie Daten symmet- risch ver- und entschlüsselt werden können. [RFC 3268] DH Diffie-Hellmann Algorithmus Public-Key Algorithmus [RFC 2631] DoS At- Denial of Service Attack Netzwerkangriff in dem eine Maschine (Server) tack von vielen Anfragen überflutet wird und ab- stürzt. H.323 Standard für audiovisuelle Kom- Üebergeordnete Empfehlung der ITU. Definiert munikationsprotokolle Protokoll in ASN.1. Gegensatz zu SIP. HMAC Keyed-Hashing for Message Au- Wird für die Verschlüsselung von Hashes be- thentication nutzt [RFC 2104] IP Internet Protocol Netzwerkprotokoll [RFC 791] ITU International Telecommunication Internationale Organisation zur Koordination Union globaler Telekommunikations-Netzwerke und - Dienste. KEYMGT Key Management Extension Key Management Extensions für das Session Description Protocol (SDP) und das Real Time Streaming Protocol ([RTSP]) https://www.keymgt.org/ KPhone Populärer VoIP SIP Client unter Linux http://www.wirlab.net/kphone/ libsrtp Freie open source SRTP Library, Implemen- tierung des SRTP Protokollstack in C. http://srtp.sourceforge.net/srtp.html MIKEY Multimedia Internet Keying Key Management Protokoll [RFC 3830] Minisip VoIP SIP Client unter Linux http://www.minisip.org/ MKI Master Key Identifier Kann optional einem als 32Bit Feld dem SRTP Paket beigefügt sein um den zu diesem Paket gehörenden Master Key zu Identifizieren. Dient dem Key Management zur Steuerung des Re- Keyings. [RFC 3711] NAT Network Address Translation Internet IP Adresse werden durch eine aktive Netzwerkkomponente (Router) ausgetauscht und durch eine andere IP Adresse ersetzt. PKI Public Key Infrastructur Web of Trust mit elektronischen Zertikfikaten (Public-/ Private Key Verfahren) [RFC 2459, RFC 3820] ROC Rollover counter Zählt die Durchgänge des 16Bit Sequenz- nummer-Zählers für SRTP Pakete. Aus Ihm kann der Paket-Index mit [i=2^16 * ROC + Sequenznummer] berechnet werden. Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Glossar 50 / 68 Voice over IP security
RTCP Real-time Transport Control Pro- Protokoll welches innerhalb einer RTP Session tocol Steuerungsinformationen oder auch QoS aus- tauscht. [RFC 3605] RTP Real-time Transport Protocol Protokoll mit welchem zeitkritische Daten ü- bertragen werden können (meist VoIP). [RFC 3550] RTSP Real-Time Streaming Protocol Netzwerkprotokoll zur Steuerung von kontinu- ierlicher (Streams) audiovisueller Übertragun- gen. [RFC 2326] SDMS Security Description for Media Key Management Protokoll Streams SDP Session Description Protocol Protokoll zur Beschreibung von Multicastsit- zungen [RFC 2327] ([RFC 3556]) SHA1 Secure Hash Algorithm Anhand dieses Algorithmus lässt sich ein Hash über eine beliebige Anzahl Daten erzeugen. [RFC 3174] SIP Session Initiation Protocol Protokoll für den Verbindungsaufbau von meist VoIP Verbindungen, http ähnlich. [RFC 3261] SRTCP Secure Real-time Transport Con- Protokoll welches innerhalb einer SRTP Sessi- trol Protocol on Steuerungsinformationen oder QoS aus- tauscht. (Verschlüsselt) SRTP Secure Real-time Transport Pro- Protokoll mit welchem zeitkritische Daten ver- tocol schlüsselt übertragen werden können (meist VoIP). [RFC 3711] SSRC Synchronisation Source Identifier Eindeutige Identifikation einer Quelle welche über SRTP oder RTP kommuniziert. STUN Simple traversal of UDP over NAT Einfaches Netzwerkprotokoll welches Compu- tern mit Applikationen in einer NAT Umgebung ermöglicht, Daten aus dem Internet empfan- gen zu können (z. B. SIP Clients). TCP Transmission Control Protocol Verbindungsorientiertes Kommunikationspro- tokoll [RFC 793] UDP User Datagram Protocol Verbindungsloses Kommunikationsprotokoll [RFC 768] URI Uniform Resource Identifier Bezeichner für eine abstrakte oder physikali- sche Ressource. (Z. B. Adresse für VoIP Client: SIP URI) VoIP Voice over IP Sprachdaten über das Internet Protokoll (In- ternettelefonie).
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Glossar 51 / 68 Voice over IP security
2 Quellen
Ausdruck Beschreibung [AES-CM] Review of Counter Mode Encryption http://csrc.nist.gov/CryptoToolkit/modes/workshop1/papers/lipmaa- ctr.pdf [Diplomarbeit] Diplomarbeit „SIP Security“ (Andreas Gisler, Manfred Loretz, Andreas Stricker) [MF00] „Attacks on Encryption of Redundant Plaintext and Implications on Internet Security“ (McGrew, D. and S. Fluhrer, Springer Verlag) [QSettings] http://doc.trolltech.com/3.3/qsettings.html [RFC 3711] http://www.faqs.org/rfcs/rfc3711.html [RFC 3550] http://www.faqs.org/rfcs/rfc3550.html [RFC 3605] http://www.faqs.org/rfcs/rfc3605.html [RFC 3556] http://www.faqs.org/rfcs/rfc3556.html [RFC 3268] http://www.faqs.org/rfcs/rfc3268.html [RFC 2104] http://www.faqs.org/rfcs/rfc2104.html [RFC 3830] http://www.faqs.org/rfcs/rfc3830.html [RFC 2326] http://www.faqs.org/rfcs/rfc2326.html [RFC 2631] http://www.faqs.org/rfcs/rfc2631.html [RFC 2459] http://www.faqs.org/rfcs/rfc2459.html [RFC 3820] http://www.faqs.org/rfcs/rfc3820.html [NSA Venona Project] http://www.nsa.gov/venona/index.cfm
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Projektplan 52 / 68 Voice over IP security
XIII Anhang: Projektplan
1 Einleitung
1.1 Ziel und Zweck Dieses Dokument beschreibt das Projekt „Voice over IP Security“. Die Planung und Konventio- nen für den ganzen Projektverlauf sollen dadurch schriftlich festgehalten werden.
2 Über das Projekt
2.1 Beschreibung Im Rahmen einer Semesterarbeit soll ein Voice over IP Client entwickelt werden, der eine siche- re Datenverbindung über SRTP erlaubt und zum Verbindungsaufbau, das SIPv2 Protokoll be- nutzt. Es soll von einem geeigneten OpenSource SIPv2 Client ausgegangen werden. Der Client soll in C++ für alle gängigen Linux Distributionen verfügbar sein.
2.2 Vision Das Zeitalter der IP Telefonie scheint nun definitiv angebrochen. Die Gratis Software Skype hat diese Bewegung merklich beschleunigt. Skype ist gut, zuverlässig und bietet hohe Übertra- gungsqualität. Nur, diese Software ist stark proprietär implementiert und verwendet keinerlei anerkannte Standards. Dies verhindert zum einen die Zusammenarbeit mit Clients anderer Hersteller und könnte durch die Geheimhaltung des Codes schwerwiegende Sicherheitslücken aufweisen. Skype verspricht zwar hohe Abhörsicherheit, Beweise dafür gibt es jedoch keine (Security by Obscurity). Open Source Projekte wie KPhone verwenden den offiziellen Standard zur Übertragung von Mul- timedia-Daten RTP (Realtime Transport Protokoll). Zur Signalisierung bzw. zum Gesprächsauf- bau wird das, ebenfalls offiziell standardisierte Session Initiation Protokoll (SIPv2) verwendet. Beide Protokolle übertragen komplett unverschlüsselt. Das heisst sie könnten von einem poten- tiellen Angreifer (Eavesdropper) abgehört werden. Beim Gesprächsaufbau ist das nicht ganz so problematisch, da es weniger interessant ist zu wissen wer mit wem Telefoniert. Interessanter ist da das Gespräch selber. Wird es regulär mit RTP übertragen, kann jeder bessere Sniffer, wie Ethereal oder Cain das Gespräch mitschneiden und als Audiodatei exportieren. Auf dem herkömmlichen Telefon Netz brauchten sich die Leute keine Gedanken um die Abhör- sicherheit ihrer Gespräche zu machen. Man musste schon bei der Telefongesellschaft oder beim Staat in geeigneter Position arbeiten um Gespräche abhören zu können. In der IP Telefonie ist dies wie oben beschrieben alles andere als selbstverständlich. Als Lösung bietet sich die Verschlüsselung mittels des SRTP (Secure Realtime Transport Proto- koll) Standards an. Dieses verwendet im Grunde die Struktur von RTP, nur dass die Payload ver- schlüsselt wird. Die Verschlüsselung geschieht mit einem 128Bit (oder 192Bit) symmetrischen (AES) Master Key, welche mit heutigen Mitteln praktisch nicht geknackt werden kann. Als Plattform soll der, in den meisten aktuellen Linux Distributionen mitgelieferte, SIPv2 Client KPhone verwendet werden. In einer Anfangsphase geschieht die Verschlüsselung mittels eines Preshared Keys. Des Weiteren könnte ein Key-exchange Mechanismus, z.B. mit MIKey, imple- mentiert werden.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Projektplan 53 / 68 Voice over IP security
2.3 Teamstruktur Name Kürzel Leiter für: Silvan Geser SG - Anforderungen - Analyse und Design Christian CH - Projektplan und Organisation Höhn - Tests - Qualtitätssicherung/Qualitätskontrolle Alle Alle - Implementation - persönliche Zeiterfassung - Teilnahme an Sitzungen - Protokollieren von Sitzungen - Dokumentation der Erzeugnisse Tabelle 4: Teamstruktur
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Projektplan 54 / 68 Voice over IP security
3 Dokumente
3.1 Übersicht Titel Dokument: Aufgabenstellung Aufgabenstellung_Studienarbeit_SS_2005_VoIP.doc Abstract kurzfass.doc Management Summary Management Summary.doc Anforderungsspezifikation Anforderungsspezifikation.doc Analyse Analyse.doc Design Design.doc Software Dokumentation Software Dokumentation.doc Kphone Anpassungen Kphone Anpassungen.doc SRTP Dokumentation SRTP.doc User Manual UserManual.doc Programmierrichtlinen Programmierrichtlinein.doc Evaluation SIP Clients Evaluation_SIP_Clients.doc MIKEY Analyse MIKEY Analyse.doc Glossar und Quellen Glossar.doc Persönlicher Bericht SG PersBericht_SG.doc Persönlicher Bericht CH PersBericht_CH.doc Projektplan ProjektPlan.doc Arbeitspakete Arbeitspakete.xls Risikomanagement Risiko_Kosten.xls Zeiterfassung SG Zeiterfassung_SG.xls Zeiterfassung CH Zeiterfassung_CH.xls Voice over IP security Voice over IP security.doc Tabelle 5: Dokumente des Projekts
3.2 Abstract Dieses Dokument bietet ein kurzer Überblick (eine Seite) über die ganze Arbeit und ist auch für nicht Techniker lesbar.
[kurzfass.doc]
3.3 Anforderungsspezifikation Die Anforderungsspezifikation (Requirement Specification) stellt sicher, dass die Ziele des Pro- jekts klar, präzise, definitiv und schriftlich festgehalten sind. Sobald diese von beiden Parteien abgesegnet wurden, dürfen daran keine wesentlichen Änderungen mehr gemacht werden. Es geht dabei vor allem um funktionale Anforderungen (formuliert in Use Cases) aber auch um nicht-funktionale Anforderungen an das System. Sie dienen als Grundlage zur Architektur Spezi- fikation.
Sie enthalten: • Funktionale Anforderungen • Use cases, die die Verwendung und Funktionen des Produkts behandeln • Fehlertoleranz und Stabilität • Leistungsanforderung • Qualitätsmerkmale
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Projektplan 55 / 68 Voice over IP security
Dokument: [Anforderungsspezifikation.doc]
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Projektplan 56 / 68 Voice over IP security
3.4 Analyse Dieses Dokument soll alle Analyse-Erzeugnisse zusammenfassen.
Es enthält: • Domainmodell • Konzepte • Systemoperationen
Dokument: [Analyse.doc]
3.5 Design Dieses Dokument fasst die Designerzeugnisse zusammen. Die implementationsspezifischen Aspekte der Software werden hier aufgezeigt.
Es enthält: • Softwarekonzepte • Klassendiagramm • Interaktionsdiagramme
Dokument: [Design.doc]
3.6 Software Dokumentation Dieses Dokument beschreibt die Funktion der Software KPhone mit der SRTP Erweiterung.
[Software Dokumentation.doc]
3.7 Kphone Anpassungen Dieses Dokument beschreibt die Änderungen welche im Code von KPhone vorgenommen wur- den.
[Kphone Anpassungen.doc]
3.8 SRTP Dokumentation Dieses Dokument bietet einen kurzen Überblick über SRTP.
[SRTP.doc]
3.9 User Manual In diesem Dokument wird die Konfiguration des VoIP Clients beschrieben. Das User Manual be- schreibt den detaillierten Ablauf für die Installation und den Betrieb des Clients.
Dokument: [UserManual.doc]
3.10 Programmierrichtlinien Beschreibt den Programmierstiel, die Sprache und Schreibkonventionen.
Dokument: [Programmierrichtlinien.doc]
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Projektplan 57 / 68 Voice over IP security
3.11 Evaluation SIP Clients In diesem Dokument wurden die Vor- und Nachteile verschiedener gefundener SIP VoIP Clients verglichen.
[Evaluation_SIP_Clients.doc]
3.12 MIKEY Analyse In diesem Dokument findet sich ein kurzer Überblick, über das MIKEY Protokoll.
[MIKEY Analyse.doc]
3.13 Persönliche Berichte Diese Dokumente beinhalten die persönlichen Erfahrungen der Teammitglieder.
Dokument: [PersBericht_SG.doc] Dokument: [PersBericht_CH.doc]
3.14 Voice over IP security Dieses Dokument beinhaltet alle anderen.
[Voice over IP security.doc]
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Risk Management 58 / 68 Voice over IP security
XIV Anhang: Risk Management
Tabelle 6: Risikoübersicht
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Zeiterfassung 59 / 68 Voice over IP security
XV Anhang: Zeiterfassung
1 Zeitkontrolle
1.1 Arbeitsstunden pro Woche
Übersicht der geleisteten Arbeitsstunden pro Projektwoche 25
20
15 Soll Silvan Geser Christian Höhn 10
5
0 1 2 3 4 5 6 7 7.5 8 9 10 11 12 13 14 Projektwoche
Abbildung 14: Arbeitsstunden pro Woche
1.2 Kumulierte Zeit Übersicht Wie zu erwarten war, ist die geleistete Zeit etwas höher als die geplante soll Zeit.
Übersicht der geleisteten Arbeitsstunden 250
200
150 Soll Silvan Geser Christian Höhn 100
50
0 12345677.5891011121314 Projektwoche
Abbildung 15: Kumulierte Zeit
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Zeiterfassung 60 / 68 Voice over IP security
1.3 Zeitaufteilung nach Bereichen Die Grafik zeigt die Prozentuale Verteilung der effektiv geleiste- 7% ten Arbeit auf die verschiednen 22% 10% Bereiche. Auffallend ist der ge- ringe Anteil in der Sparte De- sign. Im Wesentlichen ist dies Projektplanung Evaluation darauf zurück zu führen, dass Analyse 6% ein grosser Teil der Arbeit die Des ign Analyse von schon bestehen- 23% Implementation dem Code war. Daher überla- Testing Dokumentation gern sich die Bereiche Design und Analyse und es ist eine Fra- ge der Interpretation welches 25% Arbeitspaket wo zugeordnet 7% wird. Obwohl verhältnis mässig we- Abbildung 16:Zeitaufteilung, ist nig neuer Code generiert wurde, nimmt die Implementation ei- 7% nen grossen Stellenwert ein. Dies hat in erster Linie damit zu 25% 10% tun, dass die Materie für uns relativ neu war und viele Projektplanung unerwartete Probleme Evaluation aufgetaucht sind. Analyse Des ign 19% Implementation 7% Testing Dokumentation
20% 12%
Abbildung 17: Zeitaufteilung, soll
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Zeiterfassung 61 / 68 Voice over IP security
1.4 Bereiche: soll/ist Wie schon oben erwähnt haben wir die Bereiche Implementation und Analyse unterschätzt. Der Rest bewegt sich im erwarteten Rahmen.
120
100
80
soll 60 ist
40
20
0 Projektplanung Evaluation Analyse Design Implementation Testing Dokumentation
Abbildung 18: Vergleich soll/ist
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Persönliche Berichte 62 / 68 Voice over IP security
XVI Anhang: Persönliche Berichte
1 Bericht, Christian Höhn Da mein Interesse an VoIP und Netzwerkkommunikation gross ist, war ich unserer Aufgabe ge- genüber von Anfang an sehr positiv eingestellt. Auch was mein Partner Silvan Geser und unseren Betreuer Prof. Dr. A. Steffen angeht, waren alle sehr positiv auf die Aufgabe eingestellt.
Zu Beginn speziell war, dass die Aufgabenstellung noch nicht vollständig definiert war. Es galt also, sich zuerst einmal schlau zu machen was eigentlich möglich wäre und was nicht, um dann die Aufgabenstellung definieren zu können, wie das Finden eines geeigneten VoIP Clients. Ähn- liches habe ich jedoch auch in der letzten Studienarbeit erfahren und wusste deshalb was auf mich zukommen würde. So lief dann die Evaluationsphase auch gut ab. Gefunden wurde der VoIP Client „KPhone“. Es galt auch sich in die RFC’s einzulesen, welche die Protokolle zur Ver- schlüsselung (SRTP) und auch Schlüsselmanagement (MIKEY) beschreiben. Schade war, dass die Linuxstationen, welche uns von der Schule netterweise zur Verfügung ge- stellt wurden, zuerst einmal über die ersten zwei Wochen in Schwung gebracht werden mussten. Mit dieser Aufgabe verloren wir ein wenig Zeit und die Motivation sank auch etwas. Die Arbeit unter Linux sehe ich jedoch trotz einigen Problemen als Plus, es erweitert meinen „Microsoft“ Horizont.
Der Einstieg ins C++ (welches ich bis anhin nur aus der Theorie der Vorlesungen kannte), war dann etwas harzig. Dank unserer positiven Einstellung zum Ganzen, konnten wir uns aber fan- gen und schnell einarbeiten. Es war mal etwas anderes, ein ganzes, funktionsfähiges Tool (KPhone) auseinander zu nehmen und Code zu analysieren, welcher von jemand völlig anderem geschrieben wurde. Die Suche der SRTP Libraries stellte sich als einigermassen schwierig her- aus, wir fanden am Ende nur die in C geschriebene „libsrtp“ als einzige Open-Source Library. Die Integration von C Code in C++ barg dann auch so ihre Tücken, welche wir aber nach langem Probieren und dem Einholen von Expertenwissen bewältigen konnten. Typischerweise ist C++ Objektorientiert jedoch gibt es in C keine Objekte. Erschwert wurde das Ganze auch durch das nicht Vorhandensein einer anständigen Dokumentation der Library. Auch hier musste also vor allem Code Analyse und Debugging betrieben werden.
Was nebst der Programmierung auch noch gemacht werden musste, war das ganze Projektma- nagement und die Dokumentation. Unser Betreuer legte jedoch vor allem auf die Funktionalität des Tools Wert, was auch wir sehr begrüssten. So lief das ganze Projektmanagement auf Spar- flamme, und wir mussten am Schluss noch einiges zulegen. Die Dokumentation (auch häufig ein leidiges Thema), wurde dank unserer Disziplin gut geführt.
Alles in allem brachte diese Arbeit sehr viele Erfahrungen im Bereich Verschlüsselung, VoIP, C++ und Linux. Es konnte also ein breites Spektrum der Informatik abgesteckt werden, was mich sehr aufstellt. Ich habe viel dazugelernt und bin zuversichtlich, im Hinblick auf die folgende Dip- lomarbeit, welche in der genau gleichen Konstellation des Teams stattfinden wird. Da wir auch am selben Thema arbeiten werden, benötigen wir keine lange Einarbeitungszeit, was auch von Vorteil ist. Motivierend ist auch, dass wir unser Werk in der Diplomarbeit weiter ausbauen kön- nen. Auch werden wir einige Punkte (Projektmanagement, Zeitplanung) im Rückblick auf die Studienarbeit verbessern.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Persönliche Berichte 63 / 68 Voice over IP security
2 Bericht, Silvan Geser Kaum war die erste Studienarbeit vorbei, war schon die Zeit gekommen uns für die zweite Stu- dienarbeit zu bewerben. Das Bewerbungsverfahren war wie gewohnt chaotisch und unstruktu- riert. Wir konnten uns jedoch relativ schnell auf ein Thema einigen und hatten glücklicherweise auch bald die definitive Zusage von Herrn Prof. Dr. Andreas Steffen als Betreuer. Die Aufgabe war es, einen bestehenden VoIP Client so zu erweitern, dass verschlüsseltes Telefonieren unter Verwendung des SRTP Protokolls möglich wird. Anfangs konnten wir uns eigentlich nicht viel unter dem den einzelnen Aspekten dieser Aufga- benstellung vorstellen. Auch die Linux-Umgebung und das Programmieren mit C++ war für mich relativ neu und ungewohnt. Als grösste Einstiegshürde erwies sich jedoch die schlechte Linux Installation die uns Anfangs einiges an Kopfzerbrechen bereitete. Herr Steffen stellte uns zum Einstieg eine Diplomarbeit zur Verfügung die in etwa das gleiche Thema behandelte, deren Software jedoch nie Praxis tauglich wurde. Wir konnten uns so einen guten Überblick über die ganze Verschlüsselungsproblematik verschaffen. Wie üblichen bei ei- nem neuen Thema, mussten wir uns sehr genau in die RFC’s einlesen um den technischen Hin- tergrund zu kennen. Die Wahl des Clients war anfangs relativ offen. Es gab aber Vorschläge und Referenzen in der Aufgabenstellung für Clients wie Kphone und Minisip. Wir mussten einen Client finden, der mit definierten Standards arbeitete und der frei erhältlich ist. Nach einer Evaluationsphase haben wir uns dann für Khone entschieden. Dafür gibt es noch keine SRTP Implementation und der Client erfreut sich grosser Beliebtheit, da er in den meisten Linux Distributionen mitgeliefert wird. Auf der SRTP-Stack Seite haben wir uns relativ bald für die libsrtp Library entschieden. Als einzi- ge frei erhältliche SRTP Implementation ist sie professionell programmiert und erprobt. Sie ist komplett in C programmiert. Um die beiden Teile zu verbinden haben wir uns nach einiger Überlegung für eine Wrapper bzw. Adapter Lösung entschieden. So mussten wir bei Kphone nur wenige Extension Points einbauen um die gewünschte Funktionalität zu erhalten. Dieser Wrapper übernimmt die Steuerung der Verschlüsslung mit der SRTP Library. Am Anfang hatten wir das Gefühl, dass es sich dabei um eine sehr einfache Aufgabe handelt und wir innert weniger Wochen fertig sein würden. Wir waren daher verwundert, dass Herr Stef- fen so wenige Punkte in den Anforderungen verlangte. Wie sich bald zeigte, wusste er aber bes- ser was er da verlangte und dass immer ungeahnte Probleme auftauchen würden. Uns wurde bewusst, dass Debugging in C++ nicht so einfach ist, wie wir es von Java gewohnt waren. Zudem mussten wir uns in die ganze Autoconf/Makefile Erstellung einarbeiten, von der wir bis anhin noch praktisch nichts wussten. So kam es, dass wir schlussendlich für relativ wenig Code sehr viel Zeit brauchten. Auf den ers- ten Blick wenig beeindruckend ist zudem, dass sich bei KPhone augenscheinlich sehr wenig verändert hat. Doch wie so oft, bleibt die grösste Arbeit dem Betrachter einer Software verbor- gen. So spielt sich auch bei dieser Erweiterung das meiste im Hintergrund ab. Und die verlangte Funktionalität konnten wir schliesslich vollständig implementieren. Rückblickend war es ein interessantes Projekt bei dem es viel neues zu Lernen gab. Natürlich gab es auch einige Tiefpunkte, wo wir wegen C++ oder Linux Problemen etwas nervös wurden. Die Stimmung innerhalb des Projektteams war jedoch meistens gut und produktiv. Mein Stu- dienarbeitspartner Christian Höhn und ich haben uns gut ergänzt und ich blicke auf eine ange- nehme und effiziente Zusammenarbeit zurück. Auch unser Betreuer Herr Steffen, war während des Projekts sehr hilfreich. Er liess uns in Punk- to Projektmanagements sehr viele Freiheiten und auch in wichtigen Designentscheidungen hat- ten wir mehr oder weniger freie Hand. Besonders bei hartnäckigen Problemen konnte er uns mit seiner Erfahrung in diesem Gebiet meist weiterhelfen. Etwas verunsichert hat uns aber das spär- liche Feedback, dass wir von seiner Seite erhielten. Wir waren nicht ganz sicher ob das was wir taten auch gut war, bzw. seinen Ansprüchen genügen würde. Es gab denn auch nur wenige Sit- zungen (im Schnitt alle 2-3 Wochen). Da die Aufgabenstellung relativ klar formuliert war, kamen aber gar nicht erst so viele Fragen auf. Der Client sollte zuverlässig Sprachdaten ver- und ent- schlüsseln, und das tat er dann auch. :) Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Persönliche Berichte 64 / 68 Voice over IP security
Leider konnten wir eines der anfänglichen Ziele, unsere Erweiterung in die offizielle KPhone Distribution einfliessen zu lassen, bis dato nicht erreichen. Trotz anfänglich positiver Resonanz scheint der zuständige Finnische Entwickler Pekka Raisio lieber in einem Fjord zu Fischen als unseren Code einzubinden. ;) Eventuell klappt es doch noch im Rahmen der Studienarbeit, an- sonsten werden wir Ihm während der Diplomarbeit wieder Druck machen. Im Rahmen der Diplomarbeit werden wir im Herbst diese Arbeit weiterführen und den SRTP Client um ein Key Management erweitern. Wir konnten uns während dieser Studienarbeit sehr gut in dieses Thema einarbeiten und hatten schon während des Designs des Wrappers eine allfällige Erweiterung um ein Key Management im Kopf. Ich kann mich daher schon jetzt auf eine sehr interessante Diplomarbeit freuen, die sicherlich viel herausfordernde Software Engineering- und Programmierarbeit beinhalten wird.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: MIKEY Analyse 65 / 68 Voice over IP security
XVII Anhang: MIKEY Analyse
1 Überblick
1.1 Einleitung Eine Sinnvolle, skalierbare Verschlüsselung von RTP [RTP] mittels SRTP [SRTP] verlangt nach einem ausgereiften Schlüsselmanagement. Eine einfache Variante wäre das Benutzen des „k=“ SDP [SDP] Feldes das zum Transport von Schlüsseln vorgesehen ist, dieses lässt sich jedoch leider nicht erweitern, um den Anforderungen an ein „richtiges“ Key Management gerecht zu werden. Eine bessere Lösung wäre die Verwendung eines ausgeklügelten Key Management Pro- tokoll wie MIKEY (Multimedia Internet Keying [MIKEY]).
1.2 Szenarios MIKEY wurde vor allem für Echtzeit Multimedia Anwendungen entwickelt die über einen oder mehrere gesicherten Kommunikationskanäle verfügen. Es deckt in erster Linie die folgenden drei Kommunikationsszenarien ab: Peer-to-peer: Zwei Kommunikationspartner die entweder eine gemeinsame Sicherheit vereinbaren oder aber jeder für die Sicherheit seines Kanals sorgt. Simple one-to-many Z.B Echtzeitpräsentationen. Der Initiator steuert hier die Sicherheit. Many-to-many Mehrere Kommunikationspartner kommunizieren gleichzeitig über sichere Datenkanäle mitein- ander. Der Initiator agiert als Group-Server und kann bestimmen wer der Session beitreten darf.
1.3 Design Ziele • End-to-end security (nur Kommunikationsteilnehmer haben Zugang zu den Schlüsseln • Einfachheit • Effizienz (niedrige Bandweite, wenig Overhead, kleiner Code, wenige Roundtrips) • Tunneling über Session establishment Protokolle (z.B. SIP [SIP]) • Unabhängigkeit von Sicherheitsfunktionen unterer Netzwerkebenen.
1.4 Funktionsübersicht
Security Protokoll parameters (policies) Crypto Session DATA SA CSB TEK (Security Protokoll SP Input Key transport / (e.g. SRTP)) exchange TEK TGK TEK derivation
Abbildung 19:Funktionsübersicht
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: MIKEY Analyse 66 / 68 Voice over IP security
2 Methoden zum Schlüsselaustausch/Vereinbarung Zur Übertragung der Schlüssel sind in MIKEY 3 verschiedene Methoden definiert: Pre-Shared Keys Der gemeinsame Schlüssel (Shared Secret) muss vorgängig beiden Parteien bekannt sein. D.h. er muss über eine sichere Art (hier nicht definiert) an die andere Partei übermittelt werden. + Sehr effizient da nur sehr wenig Overhead - Skaliert schlecht und eignet sich daher nicht für grosse Gruppen Public-Key Cryptography Das Public Key verfahren ist hoch skalierbar hat aber eine schlechtere Performance als p-s Keys. Zudem wird eine Public Key Infrastruktur benötigt. Einmal erstellte symmetrische Schlüs- sel könnten zwischengespeichert und wieder verwendet werden so kann die Performance ver- bessert werde. Diffie Hellman Das Diffie-Hellman verfahren benötigt am meisten Ressourcen bietet aber sog. „Perfect For- ward“ Security. DH eignet sich allerdings nur für peer-to-peer Verbindungen da vor jeder Übertra- gung einen unvorhersagbaren Zufalls Schlüssel erzeugt wird.
3 MIKEY Begriffe Data Security Association (Data) Verschlüsselungsdaten für das Sicherheitsprotokoll (TEK und parameter/policies) Crypto Session (CS) Uni oder bidirektionale Datenströme die mit einer einzigen Instanz eines Sicherheitsprotokolls gesichert sind. Beispielsweise ein SRTP Strom und der zugehörige SRTCP Strom werden mit dem gleichen SRTP Kontext gesichert. Crypto Session Bundle (CSB) Sammlung von einer oder mehreren CS welche über die gleichen TGK’s und Sicherheitsparame- ter verfügen können Crypto Session ID Eindeutiger Identifierer einer Session innerhalb einer Crypto Session TEK Generation Key (TGK) Ein von beiden Seiten anerkannter bit-String der zu einem CSB gehört. Von diesem TGK können ohne weiteren Austausch TEK’s generiert werden. Traffic-Encrypting Key (TEK) Der eigentliche symmetrische Schlüssel der vom Sicherheitsprotokoll (z.B. SRTP) zum ver- schlüsseln der Pakete oder zum ableiten weiterer Schlüssel verwendet wird. Er wird vom TGK des jeweilgigen CSB abgeleitet. TGK re-keying Mit dem sog. Re-keying können wärend dem Betrieb neue TGK’s ausgehandelt werden (und dadurch auch neue TEK’s). Initiator Der Auslöser des Key Echange Prozesses. Nicht zwangsläufig der Auslöser der Kommunikation. Responder Kommunikationspartner des Initiators Salting Key Zufällige oder Pseudozufällige Strings schützen gegen offline Attacken auf dem darunter lie- genden Sicherheitsprotokolls.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Programmierrichtlinien 67 / 68 Voice over IP security
XVIII Anhang: Programmierrichtlinien
1 C++ Headerdatei Beispiel: #ifndef BEISPIELKLASSE_H #define BEISPIELKLASSE_H
#include
/** * Doku zur Klasse */ class Beispielklasse{ public: /** * Doku zum jeweiligen Element */ Public Elemente (1. Static Elemente, 2. Konstruktoren, 3.Destruktoren, 4. Methoden)
protected: /** * Doku zum jeweiligen Element */ Protected Elemente (falls vorhanden)
private: /** * Doku zum jeweiligen Element */ Private Elemente (1. Static Elemente, 2. Methoden, 3.Attribute) };
#endif // BEISPIELKLASSE_H Der Dateiname ist derselbe wie der Name der Klasse, die Endung ist „.h“. Am Dateianfang wird eine Präprozessorvariable definiert, diese hat den gleichen Namen wie die Klasse, welche in dieser Datei deklariert wird, alle Zeichen sind jedoch gross geschrieben und hinten hängt noch ein „_H“ daran. In der Headerdatei werden keine Namensräume eingebunden, es muss also der Scope Opera- tor(::) benutzt werden. Die Methodennamen werden klein geschrieben, wobei bei zusammengesetzten Wörtern jeweils der erste Buchstabe gross geschrieben wird. Gleiches gilt für die Namen der Attribute und Da- tenfelder. Bei den Klassennamen gilt das Selbe ausser, dass dort bereits der erste Buchstabe gross ge- schrieben wird.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007
Studienarbeit Voice over IP Security Anhang: Programmierrichtlinien 68 / 68 Voice over IP security
2 C++ Sourcedatei Beispiel: #include
#include “Headerdatei.h” using namespace namensraum;
Initialisierung von Static und const Elementen.
Klasse::Klasse(){ … }
Klasse::~Klasse(){ … }
Klasse::methode1(){ … }
Klasse::methode2(){
} Der Dateiname ist gleich wie der Klassenname, Endung ist „.cpp“. Die geschweiften Klammern beginnen auf derselben Zeile wie die Methode oder das Flusskon- trollelement. Ansonsten gelten auch hier die gleichen Konventionen wie für die Headerdatei.
Team: Christian Höhn, Silvan Geser Letzte Änderung: Betreuer: Prof. Dr. Andreas Steffen 16.01.2007