Sie sind auf Seite 1von 64

Bachelorarbeit zum Thema

Security in Next Generation Networks (NGN)


zur Erlangung des akademischen Gerades
Bachelor of Communication Systems(FH)
vorgelegt dem
Fachbereich VII Communication Systems der Beuth-Hochschule
Berlin
Felix Lange
26. August 2009
Bachelorarbeitsbetreuer: Dipl. Ing. Eike Klein
Inhaltsverzeichnis
Einleitung 4
1 Einfhrung in Next Generation Networks 5
1.1 Denition eines NGNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Entwicklung von NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Grund der Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Vor - und Nachteile der Technik . . . . . . . . . . . . . . . . . . . 7
1.3 Ausblick auf die Zukunft von NGN . . . . . . . . . . . . . . . . . . . . . 8
2 Security in Next Generation Networks 9
2.1 Warum mssen NGNs gesichert werden? . . . . . . . . . . . . . . . . . . 9
2.2 Grundbegrie der Informationssicherheit . . . . . . . . . . . . . . . . . . 10
2.2.1 Vertraulichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Integritt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3 Verfgbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4 Authenzitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.5 Verbindlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Kryptographische Methoden . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Symmetrische Verschlsselung . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Asymmetrische Verschlsselung . . . . . . . . . . . . . . . . . . . 12
2.3.3 Digitale Unterschrift . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.4 Zertikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.5 Zertikatsherachien . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Hashfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Secure Hash Algorithm (SHA) . . . . . . . . . . . . . . . . . . . . 17
2.5 Security Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.1 Das TLS-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 Das SRTP-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 Verschlsselungsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6.1 Die AES-Verschlsselung . . . . . . . . . . . . . . . . . . . . . . . 30
2.7 Schlsselaustauschverfahren . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7.1 Das Di Hellman Verfahren . . . . . . . . . . . . . . . . . . . . . 33
2.7.2 Das RSA-Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2
2.8 Key Management Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.8.1 Das MiKey Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.9 Einsatz einer (Voice)Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.9.1 State Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.9.2 Application Layer Gateway . . . . . . . . . . . . . . . . . . . . . 39
2.9.3 Session Border Controller . . . . . . . . . . . . . . . . . . . . . . 40
2.10 Angrismethoden auf NGNs . . . . . . . . . . . . . . . . . . . . . . . . . 40
3 Praktische Anwendung am Open Scape Voice Server (HiPath8000) 42
3.1 Planung von Securityrichtlinien in NGN . . . . . . . . . . . . . . . . . . 42
3.1.1 Sicherung der Komponenten auf physikalischer Ebene . . . . . . . 43
3.1.2 Sicherung des Netzwerkbetriebs auf logischer Ebene . . . . . . . . 43
3.1.3 Verschlsselung der Sprachdaten und der Signalisierung . . . . . . 43
3.1.4 Einsatz von Zertikaten und Zertikatsherachien . . . . . . . . . . 44
3.2 Einrichtung der Securityrichtlinien am Open Scape Voice Server in einer
Laborumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.1 Aufbau der Laborumgebung . . . . . . . . . . . . . . . . . . . . . 44
3.2.2 Aufbau einer Zertikatsherachie . . . . . . . . . . . . . . . . . . . 44
3.2.3 Zertikatsverteilung fr die einzelnen Komponenten . . . . . . . . 53
3.2.4 Aufbau gesicherter Verbindungen zwischen Servern und Telefonen 53
3.2.5 Aufbau einer gesicherten Verbindungen zwischen OpenScape Voice
Server und der HG 35xx . . . . . . . . . . . . . . . . . . . . . . . 54
3.3 Simuliertes Angrisszenario . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.1 ARP-Spoong und ARP Cache Poisoning . . . . . . . . . . . . . 56
3
Einleitung
Motivation
Diese Bachelorarbeit entsteht im Auftrag der Siemens Enterprise Communications GmbH
& CO. KG. Sie soll Mitarbeitern ein Einstieg in das komplexe Thema der gesicherten
Internet-Kommunikation geben. Dazu dient sie auch als Leitfaden, um eine gesicherte
und verschlsselte Kommunikation am Open Scape Voice Server einzustellen.
Aufbau
Die Arbeit ist in 3 Teile gegliedert. Im Kapitel "Einfhrung" wird das Thema Next Gene-
ration Networks (kurz NGN) beleuchtet. Im Kapitel "Security" werden alle theoretischen
Grundlagen fr die Verschlsselung, die der Open Scape Voice Server verwendet, gelegt.
Im letzten Kapitel "Praktische Anwendung am Open Scape Voice Server (HiPath8000)"
wird gezeigt wie man Securityrichtlinien plant und sie am Server einrichtet. Hinzu kommen
Darstellungen wie eine gesicherte Verbindung aussieht und abluft. Zum Schluss wird
ein Angrisszenario auf eine ungesicherte Verbindung zwischen 2 Endgerten simuliert,
um die Wichtigkeit einer gesicherten Kommunikation zu verdeutlichen.
4
Kapitel 1
Einfhrung in Next Generation
Networks
1.1 Denition eines NGNs
Die International Telecommunication Union (ITU) hat in ihrer Recommendation Y.2001
(12/2004) eine exakte Denition von Next Generation Networks vorgegeben.
bersetzt aus dem Englischen[IT]:
Ein NGN ist ein paketvermittelndes Telekommunikationsnetz, das fhig ist, seinen Nut-
zern Telekommunikationsdienste bereitzustellen. Es macht sich die vielen breitbandigen
und QOS-fhigen Transporttechnologien zu nutze, in denen die Dienst-relevanten Funk-
tionen unabhngig von den darunter liegenden Transport-relevanten Technologien sind.
Es erlaubt uneingeschrnkten Zugri fr die Nutzer auf Netzwerke, auf verschiedene
Dienstleister und Dienste ihrer Wahl. Es untersttzt die generelle Mobilitt und erlaubt
die einheitliche und allgegenwrtige Bereitstellung der Dienste fr den User.
Zustzlich hat die ITU-T Charakteristiken fr ein NGN festgelegt (bersetzung ber-
nommen von Wikipedia [Wikb]):
Paketbertragung
Aufteilung der Steuerfunktionen in bermittlungseigenschaften, Ruf/Verbindung
und Anwendung/Dienst
Abkopplung des Diensteangebots vom Netz und Bereitstellung von oenen Schnitt-
stellen
Untersttzung eines groen Spektrums von Diensten, Anwendungen und Mechanis-
men auf der Grundlage von Dienste-Bausteinen (Dienste-Modulen) (einschlielich
5
Echtzeit/Streaming/Nicht-Echtzeit-Dienste und Multimedia)
Breitband-Fhigkeiten mit durchgehender Dienstgte und Transparenz
Zusammenarbeit mit vorhandenen Netzen ber oene Schnittstellen
Generelle Mobilitt
Uneingeschrnkter Zugang der Nutzer zu verschiedenen Diensteanbietern
Vielzahl von Identikationsschemata
Einheitliche Dienstemerkmale fr den gleichen Dienst aus der Sicht des Nutzers
Konvergenz von Diensten zwischen fest/mobil
Unabhngigkeit von dienstbezogenen Funktionen von den zugrunde liegenden
Befrderungstechnologien
Einhaltung aller regulatorischen Anforderungen, z. B. bei Notrufen sowie Sicher-
heit/Vertraulichkeit usw.
bereinstimmend mit allen regulatorischen Anforderungen (z. B. Notfallkommuni-
kation, Sicherheit, "privacy", Lawful Interception usw.)
1.2 Entwicklung von NGN
1.2.1 Grund der Entwicklung
Aufgrund der rasanten Entwicklung des Internets, des IP-Protokolls und der immer
hher werdenden Bandbreite ist es mglich geworden, smtliche Dienste der Telekom-
munikation ber das Internet abwickeln zu knnen. Es ist dadurch mglich geworden,
statt fr jeden Dienst eine separate Infrastruktur aufzubauen, alles in die vorhandende
Internet-Infrastruktur zu integrieren. Zwar ist das alte Telekommunikationsnetz eines der
ausfallsichersten und von der Qualitt her besten Netze unser Zeit aber es gengt den
Anforderungen der modernen Informationsgesellschaft nicht mehr. Die Unexibilitt der
Technik ist nicht mehr vereinbar mit der mobilen und sich stetig verndernden Zukunft.
Klar zu erkennen, ist dies an dem Konzept der Sharing-Arbeitspltze, wo Mitarbeiter
oft an anderen Arbeitspltzen innerhalb des Hauses arbeiten und auf ein Telefon mit
ihrer eigenen Nummer angewiesen sind. Dieser Dienst der Rufnummernmitnahme wre
6
ber die alte Technik nicht so einfach zu realisieren gewesen und wenn nur mit groen
administrativen Aufwand.
Hinzu kommt, dass fr die Betreiber der Telekommunikationsnetze der Kostendruck zu
hoch geworden ist. Der Aufbau, die Pege und Wartung des heterogenen Telekommunika-
tionsnetz ist sehr kostenintensiv, da fr unterschiedliche Dienste (z. B. Festnetztelefonie,
Datenbertragung, usw.) eine eigene Infrastruktur aufgebaut werden musste. Die Kon-
kurrenz, bestehend aus Anbietern von Internetdienstleistungen (z. B. Skype), haben mit
ihren Angeboten zum kostenlosen Telefonieren ber das Internet die groen Betreiber
unter Zug zwang gestellt.
Es wird aber weiterhin noch das leitungsvermittelnde Netz geben. Eine schlagartige
Umstellung auf das paketvermittelnde Netz ist nicht mglich. Daher ist es wichtig erstmal
Schnittstellen zwischen der alten und neuen Technik zu schaen.
1.2.2 Vor - und Nachteile der Technik
Der Vorteil von NGN liegt in der einheitlichen Technik (DSL und IP) des Netzes.
Die seperate Verkabelung einmal fr Telefonie und einmal frs Netzwerk/Internet entfllt,
da beide Dienste ber eine gemeinsame Leitung bereitgestellt werden knnen.
Die Mitarbeiter mssen nur fr ein Netz und dessen Management geschult werden,
dadurch wird der Betrieb und die Wartung kostengnstiger.
Das Implementieren neuer Dienste wird einfacher, weil auf der Transportebene nichts
mehr verndert werden muss. Es spielt sich somit alles nur noch auf der Applikationsebene
ab. Dies ist ein Vorteil der Trennung von Transport und Diensten.
Eines der grten Nachteile von NGN ist die Abhngigkeit vom lokalen Stromnetz. Bei
einem Stromausfall wrde bei einer homogenen NGN-Struktur die gesamte Telefonie
ausfallen. Es wre nicht mglich, einen Notruf abzusetzen. Abhilfe knnten unterbre-
chungsfreie Spannungsversorgungen (USV) schaen, die aber wiederum teuer in der
Anschaung sind und fr die Massentauglichkeit in groen Unternehmen weniger vorteil-
haft sind.
Der Energieverbrauch von NGNs ist auch nicht zu verachten. Die gesamte Infrastruktur
wrde von Routern, Switchen, PC und IP-Telefonen geprgt sein. All diese Gerte laufen
fast ununterbrochen und ziehen damit Strom. Dies verursacht mehr Stromkosten fr ein
Unternehmen.
Ein weiteres Problem ist die gemeinsame Nutzung der Bandbreite fr Daten und Sprache.
Bei hohem Verkehrsaufkommen kann es zu Verzgerungen bei einem Gesprch kommen,
was fr den Gesprchsteilnehmer meist unangenehm ist. Eine Lsung ist die Einfhrung
von QOS (Priorisierung des Datenverkehrs).
7
1.3 Ausblick auf die Zukunft von NGN
Fr die zuknftige Entwicklung von NGN ist es von entscheidender Bedeutung, dass die
Ablsung des alten Netzes weiter von statten geht. Weiterhin muss auch weiter in die
DSL-Infrastruktur investiert werden, so dass eine 100%ige Netzabdeckung erreicht wird.
Es wird in Zukunft sich nicht mehr auf die IP-Telefonie beschrnken, sondern auch andere
Dienste geben wie Viedeo-Telefonie und der weitere Ausbau von IP-TV.
Auerdem muss noch eine Lsung fr die sogenannten "Emergency Services" gefunden
werden. Frher war es mglich, den Anrufer zu lokalisieren, von wo er anruft, dies ist
bei NGN nicht mehr Fall. Es muss auch geklrt werden wie Notrufe bei Stromausfall
abgesetzt werden knnen.
8
Kapitel 2
Security in Next Generation
Networks
2.1 Warum mssen NGNs gesichert werden?
Durch den Einsatz des IP-Protokolls fr die bertragung von Daten innerhalb des NGNs
ergeben sich die gleichen Angrismethoden auf die Sprachbermittlung wie auf jeden
anderen Dienst im Internet. Auf die einzelnen Methoden werde ich am Ende des Kapitels
eingehen. Eine Vielzahl der Angrie sind soweit entwickelt und automatisiert worden, dass
selbst Computerlaien mit ein wenig Hintergrundwissen, diese anwenden knnen. Es gibt
bereits kleine Programme im Internet zu nden, die den gesamten Angri bernehmen,
dabei muss der User lediglich die Ziele angeben. Durch diese Verschiebung der Bedrohung
von Spezialisten (Hacker) hin zu einfachen Usern wird es immer wichtiger Sprach- und
Signalisierungsdaten zu schtzen und die Hindernisse fr einen erfolgreichen Angri zu
erhhen.
Um dies noch mehr zu verdeutlichen, kann man eine Analogie zu der Sicherung seiner
eigenen Wohnung ziehen. Niemand wrde seine Wohnungstr und Fenster oen lassen,
damit Fremde einfach reinspazieren knnen. Tr, Fenster und Schlsser dienen dazu
"einfache User" fern zu halten und ihnen keine Mglichkeit bzw. Gelegenheit zu verschaen.
Fr einen Spezialisten bzw. Einbrecher sind diese Sicherungmethoden zu umgehen. Sie
bentigen dafr einen hheren Zeitaufwand und setzen sich damit einer greren Gefahr
aus, entdeckt zu werden. Wenn man das auf die Sicherung des Datenverkehrs bezieht,
wrde eine einfache und unverschlsselte Verbindung, die oene Haustr symbolisieren,
die quasi dazu einldt, mal zu schauen, was sich da drin bendet. Sichert man diese
Verbindung ab, also verriegeln die Haustr mit Schlssern, schreckt man schon einen
Groteil der Angreifer ab. Der Spezialist bzw. Hacker wird sich berlegen, ob es sich
lohnt, diese Verbindung zu knacken. Er wird abwgen, ob die investierte Zeit und die
Gefahr, in die er sich begibt, in Relation zu dem Wert der erbeuteten Information stehen.
Letztendlich lsst sich sagen, dass jede Sicherungsmethode auch ihre Schwachstelle hat.
Eine vollstndige Sicherheit kann nicht garantiert werden. Aber sie kann, richtig eingesetzt,
9
einen Groteil der Angreifer abschrecken oder ihm den Angri massiv erschweren.
2.2 Grundbegrie der Informationssicherheit
In diesem Kapitel gehe ich auf die Begriichkeiten der Informationssicherheit ein. Die
Begrie sind in der Sicherheitstechnik allgemein gltig. Sie zeigen auf, wo die Bedrohungen
bei einem Angri liegen. Ich fge neben der Vertraulichkeit, Integritt und Verfgbarkeit
noch 2 weitere Begrie dazu (Authenzitt und Verbindlichkeit), da diese beiden Punkte
fr Unternehmen, die auf NGN bauen, von juristischer Seite her sehr wichtig sind.
2.2.1 Vertraulichkeit
Vertraulichkeit bedeutet, dass nur die Person die Information einsehen darf, fr die diese
auch bestimmt ist. Um die Vertraulichkeit aufrecht zu erhalten, mssen Personen, die
die Information nicht einsehen drfen, daran gehindert werden.
2.2.2 Integritt
Integritt bedeutet, dass die Daten vom Sender unverflscht bzw. unverndert den
Empfnger erreichen. Ein Bruch der Integritt wrde bedeuten, dass sicherheitsrelevante
Merkmale nicht mehr vertrauenswrdig sind und die Daten in der empfangenen Form
nicht vom Sender verschickt worden sind.
2.2.3 Verfgbarkeit
Verfgbarkeit ist die Sicherstellung, dass ein Dienst oder System zur Erfllung seiner Auf-
gabe stetig bereit ist. Ein Ausfall wrde bedeuten, dass wichtige Signale oder Nachrichten
nicht mehr den Empfnger erreichen wrden oder abgesetzt werden knnen.
2.2.4 Authenzitt
Bei der Authentizitt handelt es sich um die Kontrolle, ob die vorgegebene, virtuelle
Intenditt auch mit der tatschlichen, realen Indentitt bereinstimmt.
10
2.2.5 Verbindlichkeit
Die Verbindlichkeit ist eine Art des Versprechens bei Vertragsabschlssen. Es ist juristisch
sehr wichtig, dass die Verbindlichkeit gewahrt und nachvollzogen werden kann, dies
geschieht durch die eindeutige Indentizierung des Urhebers und die Integritt der
Information.
2.3 Kryptographische Methoden
Um die Verletzung der zuvor genannten Grundbegrie zu verhindern, wurden verschie-
dene kryptographische Methoden entwickelt. Ich werde hier nur theoretisch und auf
die allgemeine Funktionsweise der einzelnen Methoden eingehen. Dies soll helfen, die
Security Protokolle im nchsten Kapitel besser zu verstehen, da alle Protkolle auf diese
kryptographischen Methoden zurckgreifen.
2.3.1 Symmetrische Verschlsselung
Bei dem symmetrischen Verschlsselungsverfahren wird fr das Ver- und Entschlsseln
der Information der identische Schlssel verwendet. Dies bedeutet, dass der Sender zum
verschlsseln der Nachricht denselben Schlssel benutzt, wie der Empfnger zum entschls-
seln der Nachricht. Daher ist die Mglichkeit der Umkehrung der Verschlsselungsfunktion
sehr wichtig.
Grundvoraussetzung ist, dass beide Parteien den gleichen Verschlsselungsalgorithmus
verwenden und das der Schlssel geheim ist. Darin liegt wiederum ein entscheidener
Nachteil dieser Methode, nmlich die geheime bermittelung des privaten Schlssel an
den Empfnger. Der Schlssel msste ber einen gesicherten Kanal bertragen werden.
Der nchste Nachteil des Verfahren ergibt sich aus der Anzahl der Kommunikationsteil-
nehmer. Wenn man ein groes Unternehmen betrachtet mit tausenden von Mitarbeitern.
Wrde man, damit jeder Mitarbeiter mit jedem im Unternehmen kommunizieren knnte,
eine immense Anzahl an Schlsseln bentigen. Man bruchte denn fr n Mitarbeiter
n(n-1)/2 Schlssel. Der grte Vorteil in der symmetrischen Verschlsselung liegt in
der schnellen Verarbeitung der Daten. Die Daten knnen entweder Blockweise oder im
Strom ver- und entschlsselt werden. Um die Nachteile dieser Methode zu umgehen,
benutzt man die asymmetrische Verschlsselung, um ber einen ungesicherten Kanal den
geheimen, symmetrischen Schlssel auszutauschen.
11
Daten im
Klartext
Schlssel K
Daten im
Geheimtext
Daten im
Klartext
Schlssel K
Sender Empfnger
Abbildung 2.1: Schematische Darstellung der symmetrischen Verschlsselung
2.3.2 Asymmetrische Verschlsselung
Die asymmetrische Verschlsselung verfolgt einen anderen Ansatz als die symmetrische.
Anstatt eines identischen Schlssel fr beide Kommunikationsteilnehmer gibt es fr jeden
Kommunikationsteilnehmer ein Schlsselpaar bestehend aus privatem und entlichem
Schlssel. Der private Schlssel muss vom Anwender geheim gehalten werden, da nur
mit diesem Nachrichten dechiriert werden knnen. Der entliche Schlssel dagegen
steht jedem zu Verfgung, da mit diesem die Nachricht chiriert wird. Es gilt, dass
Nachrichten, die mit einem entlichen Schlssel chiriert worden sind, nur mit dem
dazugehrigen privaten Schlssel wieder dechiriert werden knnen!
Ein Nachteil dieser Verschlsselung ist der relativ groe Aufwand der Verschlsselung.
Wenn man von einem kontinuierlichen Bitstrom ausgeht, wie es bei einem Telefongesprch
der Fall ist, wre diese Methode schlicht zu langsam. Deshalb wird die asymmetrische
(geheimer Schlsselaustausch ber einen ungesicherten Kanal) und symmetrische Ver-
schlsselung (schnellere Ver- und Entschlsselung) kombiniert, um die Vorteile beider zu
vereinen.
Ein weiterer Nachteil liegt in der Bekanntgabe der entlichen Schlssel. Wer versichert
mir das dieser nicht von einem Angreifer in der Mitte kommt? Also bentigt man eine
dritte Instanz, der beide Teilnehmer vertrauen. Diese Instanz gibt ber ihr Zertikat das
Vertrauen in den empfangenen Schlssel. Das Thema Zertikate kommt am Ende dieses
Kapitels.
12
Daten im
Klartext
ffentlicher Schlssel des Empfngers
Daten im
Geheimtext
Daten im
Klartext
Privater Schlssel des Empfngers
Sender Empfnger
Abbildung 2.2: Schematische Darstellung der asymmetrischen Verschlsselung
2.3.3 Digitale Unterschrift
Die beiden vorher genannten Verschlsselungverfahren dienten dazu. Die Informationen
vertraulich zu halten. Nun bentiget man noch ein Verfahren, welches die Integritt,
Authenzitt und Verbindlichkeit gewhrleistet. Dies geschieht durch die Umkehrung des
asymmetrischen Verschlsselungverfahrens und der Hashfunktion. Die Hashfunktion ist
eine Einwegrechenoperation, bedeutet dass diese nicht zurckgerechnet werden kann.
Um die Integritt sicherzustellen, wird ber das Dokument/Information ein Hashwert
gebildet. Man kann dies mit dem Fingerabdruck eines Menschen vergleichen. Das selbe
Dokument hat immer den gleichen Hashwert. Sollte es verndert worden sein, wrde sich
auch der Hashwert ndern. Damit wird sichergestellt, dass die Nachricht unterwegs nicht
verflscht worden ist.
Um nun noch die Authenzitt und Verbindlichkeit sicherzustellen, wird der erzeugte
Hashwert mit dem eigenen privaten Schlssel chiriert. Es geht nicht darum den Hashwert
geheim zu bertragen, schlielich knnte jeder mit dem zugehrigen entlichen Schlssel
den Wert dechirien. Viel mehr geht es darum, dass der private Schlssel nur im Besitz
einer Person ist und man mit dem dazugehrigen entlichen Schlssel diese Person
einwandfrei identizieren kann.
2.3.4 Zertikate
Ein groes Problem beim asymmetrischen Verschlsselungsverfahren ist die einwandfreie
zu Ordnung des entlichen Schlssel zu einer Person. Die Zertikate bernehmen
13
Dokument m
Hash-Algorithmus
Hash-Wert
Privater Schlssel des Senders
Digitale Unterschrift
Digitale Unterschrift
ffentlicher Schlssel des Senders
empfangener
Hashwert =
errechneter
Haswert ?
Dokument m
Hash-Algorithmus
Sender
Empfnger
Abbildung 2.3: Schematische Darstellung der digitalen Unterschrift
14
X.509 Zertifikat von X
ffentlicher Schlssel
von X
Seriennummer des
Zertifikates
Gltigkeit in Tagen
Eindeutiger Name von X
Eindeutiger Name der
Zertifizierungsstelle
Digitale Unterschrift der
Zertifizierungsstelle
Abbildung 2.4: Schematischer Aufbau eines X.509 Zertikates
die vertrauensbildene Instanz, indem sie garantieren knnen, das Schlssel und Person
zusammenpassen. Dies bedeutet wiederum, dass die Instanz vorher die Identitt der
Person ermittelt hat (z.B. Vorlage eines Lichtbildausweises), desweiteren muss dieser
Instanz vertraut werden. Das Vertrauen wird geschaen, indem das Zertikat eine digitale
Unterschrift bzw. Signatur aufweist, die ber ihren entlichen Schlssel zurckverfolgt
werden kann. In der Abbildung 2.4 wird der Aufbau eines X.509 Zertikates erlutert,
das auch im OpenScape Voice Server verwendet wird.
2.3.5 Zertikatsherachien
Da das Zertikat selber den entlichen Schlssel in sich trgt, steht man wieder vor
dem Problem, ob man dem Zertikat und dem entlichem Schlssel trauen kann. Da
setzt die Zertikatsherachie an, indem der entliche Schlssel von der nchsthheren
Instanz beglaubigt wird. Dies geschiet solange bis man an der Spitze zu einem Zertikat
kommt dem man zweifelsfrei vertraut. (siehe Abbildung 2.5) Dies ist in der Regel ein
von der Firma ausgestelltes Zertikat oder eines das von der Internet Policy Registration
Authority (die allerhhste Instanz) ausgestellt wurde. Diese ganze Kette kann durch ein
geflschtes Zertikat ausgehebelt werden, deshalb ist es sehr wichtig, dass Zertikate nur
15
Root CA
Asia CA Europe CA USA CA
Sales CA Marketing CA
Abbildung 2.5: Darstellung einer Zertikatsherachie
mit grter Sorgfalt eingesetzt werden und nur nach einer Prfung weitere Zertikate
zertiziert werden.
2.4 Hashfunktionen
2.4.1 Funktionsweise
Eine kryptographische Hashfunktion ist eine Einwegfunktion. Sie liefert uns fr eine
beliebig lange Nachricht einen Prfwert mit einer festen Lnge den sogenannten Hashwert.
Als Parameter fr die Berechnung des Wertes ist nur die Nachricht selber vorhanden. Es
existieren keine Schlssel oder hnliches. Mathematisch ausgedrckt, heit es, dass eine
Hashfunktion H fr eine beliebig lange Nachricht M einen festen Hashwert h erzeugt.
= H(`)
Es werden folgende Bedingungen an die Hashfunktion gestellt:
1. leichte Berechnung des Hashwertes h
2. Es soll unmglich sein fr den Hashwert X eine Nachricht M zu nden, die den
gleichen Hashwert besitzt. H(`) = A
Eine Hashfunktion, die beide Anforderungen erfllt, nennt man auch schwache
16
Dokument
Hash-Algorithmus
Hash-Wert
Abbildung 2.6: Schematische Darstellung der Hashwertbildung
Hashfunktion. Wenn es fr 2 unterschiedliche Nachrichten ein und den selben
Hashwert gibt, nennt man dies eine Kollision. So etwas muss unbedingt vermieden
werden, deshalb wird die 2. Anforderung noch enger gefasst.
3. Es ist praktisch unmglich, zwei unterschiedliche Nachrichten zu nden, die eine
Kollision ergeben.
Die Realisierung einer Hashfunktion geschieht durch eine Folge von gleichartigen Kom-
pressionsalgorithmen. Ein Kompressionsalgorithmus liefert fr eine Eingabe fester Lnge
eine krzere Ausgabe fester Lnge. Die Daten werden blockweise verarbeitet und daraus
schlielich der Hashwert erzeugt.
Die Hashfunktion gibt uns die Mglichkeit einmal die Integritt zu wahren, da bei jeder
Vernderung der Nachricht sich auch der Hashwert verndert. Wenn der Empfnger also
einen Hashwert berechnet und dieser nicht identisch mit dem vom Sender bermittelten
Hashwert ist, kann man davon ausgehen, dass die Nachricht unterwegs manipuliert worden
ist. Andererseits kann man mit dem Hashwert auch die Authentizitt prfen. Dafr muss
der Sender den erstellten Hashwert mit seinem privaten Schlssel verschlsseln. Kann
man diesen Wert mit dem dazugehrigen entlichen Schlssel vom Sender entschlsseln,
hat man die Indentitt eindeutig festgestellt.
2.4.2 Secure Hash Algorithm (SHA)
Ich werde nun speziell auf den sha-1 Algorithmus zu sprechen kommen, da die vorherige
Hashfunktion MD4 bzw. MD5 nicht mehr sicher ist. Der sha-1 Algorithmus wurde fr
den Einsatz im Digital Signature Standard (DSS) entwickelt.
17
Der sha-1 Algorithmus generiert einen 160 Bit Hashwert und besitzt eine feste Einga-
benlnge von 2
64
Bit. Das Padding, also das aullen einer Nachricht mit Bits, muss
so erfolgen, dass die Lnge modulo 512 genau den Wert 64 ergibt. Das erste Bit beim
Padding ist immer eine logische 1 darauolgt nur noch die logische 0.
Es werden 5 x 32 Bit Konstanten denierte:
= 67452301
16
1 = 11C1189
16
C = 9811C11
16
1 = 10325476
16
1 = C3121110
16
In der Hauptschleife des Programms wird die Nachricht in 512 Bit Blcken verarbeitet.
Die Schleife luft 4 Runden mit jeweils 20 Einzeloperationen. Es handelt sich hierbei um
nicht-lineare Funktionen )

(A. 1. 2), genauer um logische Funktionen.


)
0>19
(A. 1. 2) = (A 1 ) (

A 2)
)
20>39
(A. 1. 2) = A 1 2
)
40>59
(A. 1. 2) = (A 1 ) (A 2) (1 2)
)
60>79
(A. 1. 2) = A 1 2
Fr jede Runde wird nun noch eine additive 32 Bit Konstante 1

deniert:
1
0>19
= 5827999
16
1
20>39
= 6119111
16
1
40>59
= 81111C1C
16
1
60>79
= C62C116
16
Jeder 512 Bit Block wird von 16x32 Bit Datenwrter auf 80x32 Bit Datenwrter mittels
einer Expansionsgleichung erweitert. Fr t = 16 > 79 gilt:
\

= \
3
\
8
\
16
<< 1
Der zyklische Linksshift in der Gleichung erhhert die Sicherheit von sha-1. Nun muss
noch die 5x32 Bit Konstanten in die Variablen a,b,c,d,e initialisieren.
18
c =
/ = 1
c = C
d = 1
c = 1
Es folgt einer der 80 Verarbeitungschritte:
fr t = 0 > 79:
tc:j = (c << 5) +)

(/. c. d) +c +\

+1

c = d
d = c
c = / << 30
/ = c
c = tc:j
Am Ende jeder Schleife werden die jeweiligen Hashwerte aufaddiert und die 5x32 Bit
Einzelwerte zusammengefgt, so dass man einen 160 Bit langen Hashwert erhlt.
2.5 Security Protokolle
Im folgenden Kapitel mchte ich auf die wichtigen Sicherheitsprotokolle zu sprechen
kommen, die fr eine gesicherte Verbindung am OpenScape Voice Server wichtig sind.
Da sich diese Arbeit ausschlielich auf die Sicherheitsaspekte bezieht, gehe ich nicht auf
die ungesicherten Standardprotokolle ein.
2.5.1 Das TLS-Protokoll
Das Transport-Layer Security Protokoll liegt, wie der Name schon sagt, auf der Trans-
portebene im OSI-Modell. Genauer liegt es zwischen der Sitzungsschicht und der Trans-
portschicht (siehe Abbildung 2.7).
Das TLS-Protokoll ist eine Weiterentwicklung des Secure Socket Layer (SSL)-Protokolls,
das damals von Netscape entwickelt worden ist. Bei der Standardisierung des SSL-
Protokolls durch die IETF wurde es umbenannt zu TLS. Somit ist das TLS-Protokoll im
eigentlichen Sinne das SSL-Protokoll in der Version 3.1.
19
Transportschicht (4)
TLS
Handshake
Protokoll
TLS Change
Cipher Spec
Protokoll
TLS Alert
Protokoll
TLS
Application
Data
Protokoll
Vermittlungsschicht (3)
Sicherungsschicht (2)
bertragungsschicht (1)
Sitzungsschicht (5)
Darstellungsschicht (6)
Applikationsschicht (7)
TLS Record Protokoll
Abbildung 2.7: TLS im OSI-Modell
20
Die IETF hat es unter RFC2246 folgendermaen standardisiert [All]:
Die wichtigste Aufgabe des Protokolls ist es, die Vertraulichkeit und die Datenintegritt
zwischen zwei Kommunikationspartnern zu wahren.
Ein Vorteil des Protokolls ist seine Unabhngigkeit gegenber dem Application-Layer. Es
ist egal welche Anwendung auf TLS zugreifen will. Die hherliegenden Protokolle knnen
sich transparent ber TLS legen. Die Entscheidung wie ein Handshake eingeleitet wird
und wie ein Authentizierungszertikat Austausch interpretiert wird, liegt ganz in der
Hand der Designer und Entwickler.
Fr eine gesicherte Verbindung ber TLS wurden noch weitere wichtige Punkte festge-
legt:
Kryptographische Sicherheit: TLS sollte benutzt werden, um eine gesicherte Ver-
bindung zwischen 2 Teilnehmern herzustellen.
Interoperabilitt : Programmierern soll es mglich sein Anwendungen zu entwicklen,
die TLS nutzen und erfolgreich kryptographische Parameter austauschen knnen.
Ohne zu verstehen und zu sehen wie der genaue Programmcode ist.
Erweiterbarkeit: TLS will den Anspruch erfllen, dass neue entliche Schlssel
Methoden und Verschlsselungsverfahren einfach implementiert werden knnen.
Somit muss kein neues Protokoll entworfen werden mit all seinen vermeintlichen
Risiken und Schwchen.
Ezienz : Da kryptographische Schlsselberechnungen sehr rechenintensiv sind,
gibt es bei TLS eine Mglichkeit Verbindungen zu cachen. Also einmal etablierte
Verbindungen knnen einfach wieder aufgenommen werden ohne erneuten Schlsse-
laustausch. So lsst sich die Netzwerklast senken.
Das TLS Protokoll ist, wie in Abbildung 2.7, noch einmal in 2 schichten getrennt und
besitzt viele Einzelprotokolle, die fr bestimmte Aufgaben spezialisiert sind.
TLS-Record-Protokoll
Das TLS-Record-Protokoll liegt unterhalb der anderen Protokolle. Die Schicht ist fr die
Sicherung der Datenverbindung verantwortlich.
Bei eingehenden Daten also die von den hheren Schichten kommen:
werden die Daten in kleine Blcke fragmentiert
21
sie werden komprimiert
ein HASH-Wert wird zu gewiesen
und denn verschlsselt.
Bei ausgehenden Daten also welche an die nchsthhere Schicht gehen:
werden erst entschlsselt
der HASH-Wert wird kontrolliert
dann dekomprimiert
und die Fragmente wieder zusammengefgt.
TLS Handshake Protocol
Das TLS Handshake Protocol dient den Kommunikationsteilnehmern dazu Sicherheits-
richtlinien fr ihre Verbindung zu vereinbaren. Genauer handelt es sich dabei um Verschls-
selungsverfahren, die Authentizierung und dem Austausch eines geheimen Schlssels
fr die sptere symmetrische Verschlsselung. Am Anfang einer TLS-Verbindung steht
immer der Handshake. Die Vorgehensweise und die unterschiedlichen Handshakearten
werden spter noch nher beleuchtet.
TLS ChangeCipherSpec Protokoll
Alle ber das Handshake-Protokoll ausgehandelten Parameter werden nicht sofort ber-
nommen, erst mit dem Empfang der ChangeCipherSpec Nachricht. Alle weiteren nde-
rungen der Sicherheitsparameter werden ber diese Nachricht angezeigt.
TLS Alert Protokoll
ber das TLS Alert Protokoll werden Alarmmeldungen untereinander verschickt. Sollte
es zu fatalen Fehlern kommen, wird die Verbindung sofort unterbrochen. Ein falscher
Hashwert oder ein falsches Zertikat kann zu einer Alert-Meldungen fhren.
22
C
lient H
ello
S
e
rv
e
r H
e
llo
S
e
rv
e
r C
e
rtific
a
te
C
lient C
ertificate
C
ertificate verify
F
in
is
h
e
d
Server
Client
S
e
rv
e
r K
e
y
E
x
c
h
a
n
g
e
C
e
rtific
a
te
R
e
q
u
e
s
t
S
e
rv
e
r H
e
llo
D
o
n
e
C
lient K
ey E
xchange
Finished
Abbildung 2.8: gesamter Verlauf eines TLS-Handshakes
TLS ApplicationData Protokoll
Dieses Protokoll dient der eigentlichen Datenbertragung an den Application-Layer ber
TLS.
TLS Handshake und die verschiedenen Arten
Ein kompletter TLS Handshake ist in der Abbildung 2.8 einmal schematisch dargestellt.
Welche Nachrichten beim Handshake genau bentigt werden, hngt von der Art des
Handshakes ab. Auf die Arten komme ich spter noch zurck.
Hinter den ausgetauschten Nachrichten verbergen sich die Sicherheitsparameter, die fr
eine gesicherte Verbindung notwendig sind. Ich werde auf alle einzelnen jetzt zu sprechen
kommen.
ClientHello
Das ClientHello ist die erste Nachricht, die der Client an den Server schickt, um eine
23
TLS-Verbindung aufzubauen. In dieser Nachricht benden sich Informationen ber die
Verschlsselungsmethoden und die Komprimierungsarten, die der Client untersttzt und
preferiert. Der Server sucht sich aus dieser Liste die strksten und besten Methoden
aus. Zustzlich enthlt das ClientHello eine Zufallszahl, die fr die Berechnung des
MasterSecret Passwort wichtig ist.
ServerHello
Das ServerHello ist die Antwort auf das ClientHello. In dieser Nachricht stehen nun die
vom Server ausgewhlten Sicherheitsmethoden drin. Zu dem enthlt diese Nachricht auch
eine Zufallszahl fr die Berechnung des MasterSecret Passwort.
ServerCerticate
Das ServerCerticate bertrgt das Zertikat des Servers im x509v3 Format. Dabei wird
nicht nur das von dem Server bertragen sondern dazu auch die gesamte Zertikatskette
bis hin zum Stammzertikat (ROOT-Zertikat). So kann der Client die Zertikatsherachie
analysieren und prfen, ob das empfangene Zertikat auch vertrauenswrdig ist.
ServerKeyExchange
In der ServerKeyExchange-Nachricht bietet der Server dem Client 3 verschiedene Schls-
selaustauschverfahren an (Die-Hellman, RSA, FORTEZZA). Die Funktionsweise der
ersten beiden Verfahren erlutere ich spter. Im Grunde genommen steht in dieser Nach-
richt der entliche Schlssel des Servers. Je nach Art des Handshakes wird entweder
das ServerCerticate gesendet oder aber das ServerKeyExchange.
CerticateRequest
Mit der CerticateRequest-Nachricht kann der Server das Zertikat des Clients verlangen
damit dieser sich authentiziert.
ServerHelloDone
Die ServerHelloDone-Nachricht signalisiert das Ende des ServerHellos. Ab jetzt wartet
der Server auf eine Nachricht vom Client.
ClientCerticate
Wenn der Server zuvor ein Zertikat vom Client angefordert hat, sendet dieser mit der
ClientCerticate-Nachricht sein Zertikat einschlielich der Zertikatsherachie. Sollte
der Client kein Zertikat besitzen und der Server verlangt eines, kommt es zu einem
Fatal-Error und die Verbindung wird abgebrochen.
ClientKeyExchange
Sollte der Server kein Zertikat verlangen, ist dies die erste Nachricht, die auf das
ServerHelloDone folgt. In der ClientKeyExchange-Nachricht bendet sich nun je nach
Schlsselaustausch-Methode das Premaster Secret, das aus 46 zuflligen Bytes besteht.
Wenn RSA als Schlsselaustausch-Methode gewhlt worden ist, wurde das Premaster
Secret mit dem entlichen Schlssel des Servers verschlsselt und bertragen. Nun sind
24
C
lient H
ello
S
e
rv
e
r H
e
llo S
e
rv
e
r K
e
y
E
x
c
h
a
n
g
e
S
e
rv
e
r H
e
llo
D
o
n
e
C
lient K
ey E
xchange
Finished
F
in
is
h
e
d
Server
Client
Abbildung 2.9: Server anonym - Client anonym
beide Seiten in der Lage aus den vorhandenen Daten das Master Secret zu bilden.
CerticateVerify
Die CerticateVerify-Nachricht ist eine weitere berprfung des Clients. In dieser Nach-
richt bendet sich die digitale Unterschrift des Clients. Der Server kann mit Hilfe des
zuvor bertragenen entlichen Schlssel die Identitt des Clients eindeutig feststellen.
Finished
Die Finished-Nachricht, die beide austauschen, ist die erste Nachricht die mit dem Master
Secret verschlsselt worden ist. Wenn es beiden gelingt diese Nachricht zu entschlsseln, ist
sichergestellt, dass beide das gleiche Master Secret errechnet haben. Somit wurde die TLS-
Verbindung erfolgreich aufgebaut und die Anwendungsdaten knnen bertragen werden.
Natrlich werden alle Anwendungsdaten nun mit dem Master Secret verschlsselt.
Es werden nicht immer alle Nachrichten verwendet, die ich aufgezhlt habe. Je nach Art
des Handeshake wird eine bestimmte Kombination der Nachrichten verwendet. Es gibt
3 Arten wie ein Client und ein Server eine gesicherte Verbindung ber TLS aufbauen
knnen.
Server und Client ohne Authentizierung
Bei diesem Handshake sind sowohl Server als auch Client anonym. (siehe Abb.
2.9) Dies bedeutet es werden keine Zertikate ausgetauscht, die mein gegenber
25
C
lient H
ello
S
e
rv
e
r H
e
llo
S
e
rv
e
r C
e
rtific
a
te S
e
rv
e
r H
e
llo
D
o
n
e
C
lient K
ey E
xchange
Finished
F
in
is
h
e
d
Server
Client
Abbildung 2.10: Server mit Authentizierung - Client anonym
identizieren. Darin liegt auch die Gefahr, dass sich jemand zwischen die Kommu-
nikationspartner schalten kann (Man in the middle attack). Daher ist diese Art des
Handshakes nicht empfehlenswert.
Server mit Authentizierung - Client ohne Authentizierung
Bei diesem Handshake ist nur der Client anonym. Wie man am Ablauf-Diagramm
sehen kann (Abb. 2.10), sendet der Server sein Zertikat an den Client. Dieser
benutzt den entlichen Schlssel, der im Zertikat des Servers steht und verschls-
selt mit diesem das Premaster Secret. Das Geheimnis kann nur noch vom Server
entschlsselt werden, der auch den dazugehrigen privaten Schlssel besitzt. Einem
man in the middle ist es nicht mglich, sich als falschen Server auszugeben.
Server und Client mit Authentizierung serverauthclientauth.pdf
Diese Form des Handshakes ist die sicherste! (siehe Abb. 2.11) Sowohl Client als
auch Server sind nicht mehr anonym, sondern knnen sich mittels Zertikaten
ausweisen. Im praktischen Teil dieser Arbeit wird der Begri Mutual Transport
Layer Security (MTLS) fallen, damit ist diese Art des Handshakes gemeint. Im
englischen nennt man es auch two-way authentication.
26
Server Client
Client Hello
Server Hello
Certificate (CLIENT, server CA, root CA)
Certificate (CLIENT, server CA, root CA)
Finished
Client Hello
Server Hello Certificate (SERVER, server CA, root CA)
Certificate (CLIENT, server CA, root CA)
Certificate verify
Finished
Abbildung 2.11: Server mit Authentizierung - Client mit Authentizierung
27
RTP-Header
MKI
Authentication Tag
32 Bit Lnge
Payload
Bildung eines
Hashwertes ber
die Felder
Verschlsselung
der Nutzdaten
Abbildung 2.12: Darstellung des SRTP-Headers
2.5.2 Das SRTP-Protokoll
Das Secure Real-Time Transport Protocol schtzt die Daten auf der Anwendungsschicht
im OSI-Modell. Es wurde konzipiert um einen konstanten Audio/Video-Stream ber das
UDP-Protokoll zu bertragen. SRTP bietet die Sicherheit der Vertraulichkeit, Authentizi-
tt, Integritt und den Schutz vor Replay-Attacken. Da es sich um einen kontinuierlichen
Bitstrom aus Audio bzw. Videodaten handelt, bentigt man fr die Echtzeitverschlsse-
lung ein Stromchireverfahren. In diesem Fall wird AES verwendet. Die Funktionsweise
von AES (Advanced Encryption Standard) wird im Kapitel Verschlsselungsverfahren
behandelt.
Um die Sicherheitsverfahren und Parameter fr einen SRTP-Stream zu vereinbaren, ist
ein Key Management Protokoll erforderlich. Dieses Protokoll bietet die Mglichkeit, dass
die Kommunikationsteilnehmer ein Master Key berechnen knnen. Der Master Key ist
die Voraussetzung fr die Erzeugung der Session Keys, die fr die Verschlsselung und
Authentizierung der Pakete in einer Sitzung genutzt werden.
Die IETF hat es unter RFC3711 folgendermaen standardisiert [Bau]:
Die Sicherheitsmerkmale von SRTP sind einmal die Vertraulichkeit der Payloads in RTP
und RTCP zu wahren und auf der anderen Seite die Integritt der RTP und RTCP
Pakete sicherzustellen.
SRTP-Header
Der Header des SRTP-Protokolls wurde gegenber dem RTP-Header um 2 Felder ergnzt
(siehe Abbildung 2.12), die die Sicherheitsaspekte realisieren.
28
MKI (Master Key Identier)
In diesem Feld wird festgelegt, welcher Master Key fr das RTP-Paket verwendet
werden soll. Voraussetzung fr die Generierung des Master Keys ist ein Key
Management Protkoll. Fr Multimediaanwendungen wurde speziell das MiKey-
Verfahren (Multimedia Internet KEYing) entwickelt. Auf das Verfahren komme ich
im Kapitel Schlsselaustauschverfahren zu sprechen.
Authentication tag
In diesem Feld bendet sich der Wert der Hashfunktion. Der Hashwert wird ber
dem RTP-Header und dem RTP-Payload gebildet und garantiert die Integritt.
Ablauf einer SRTP-Verbindung
1. Aufbau einer ungesicherten RTP-Session
Zu erst wird ber ein Signalisierungsprotokoll z.B. SIP eine normale RTP-Session
aufgebaut. Beim Einsatz von MiKey als Key Management Protokoll wird ber die
Nachrichten des Signalisierungsprotokoll der Master Key generiert.
2. Berechnung der Session Keys
Nachdem beide Teilnehmer den Master Key berechnet haben, erzeugen sie aus ihrem
gemeinsamen Geheimnis die Session Keys. Es gibt unterschiedliche Sessions Keys
einmal fr die Verschlsselung des Payloads und einmal fr die Authentizierung
des Absenders
3. Kommunikation ber SRTP
In diesem Schritt werden die RTP-Pakete um die beiden Felder MKI und Authenti-
cation Tag erweitert. Nun handelt es sich um SRTP-Pakete, die verschlsselt ihren
Weg durchs Netz nehmen. Mit den Session Keys knnen die Kommunikationsteil-
nehmer die Pakete wieder entschlsseln. Im Grunde verhlt sich der SRTP-Stream
genauso wie ein RTP-Stream, nur dass die Pakete verschlsselt sind.
4. Abbau der SRTP-Session
Mit Hilfe des Signalisierungsprotokoll wird die Sitzung, wie jede ungesicherte
RTP-Verbindung, abgebaut und beendet.
29
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Abbildung 2.13: AES Block mit 128 Bit (1 Block = 1 Byte)
2.6 Verschlsselungsverfahren
2.6.1 Die AES-Verschlsselung
Die AES-Verschlsselung ist ein symmetrisches Verfahren. Es ist der Nachfolder des Data
Encryption Standard (DES). Mit diesem Verfahren knnen Blcke von 128 Bit Gre
durch Schlssel mit einer Lnge von 128, 192 oder 256 Bit verschlsselt werden. Die
Entstehung des Algorithmus mchte ich hier nicht weiter behandeln. Bei Interesse ndet
man unter folgender Quelle Informationen. [Wika]
Funktionsweise
Der AES-Standard ist eigentlich eine besondere Form des Rijndael-Algorithmus. Dieser
ist ein symmetrischer Blockchirealgorithmus. Es werden also Blcke mit bestimmten
Gren aus den Daten erstellt und daraufhin verschlsselt. Der Rijndael-Algorithmus
kann Blcke von 192 oder 256 bits verarbeiten. Im AES-Standard wurde aber eine Gre
von 128 Bit festgelegt.
Ein AES-Block besteht demzufolge aus 128 Bit = 16 Byte. Dabei werden die ersten 4
Bytes von oben nach unten geschrieben. Beim 5. Byte geht man ein Schritt nach rechts
und schreibt wieder 4 Bytes untereinander. (siehe Abbildung 2.13) Diese erstellten Blcke
werden die verschiedenen Stationen im Algorithmus durchlaufen.
Anhand des Flussdiagramms (Abbildung 2.14) kann man den Weg der Daten verfolgen.
Im folgenden werden alle einzelnen Zwischenschritte behandelt.
Wie man an dem Diagramm erkennen kann, gibt es den Befehl round(). Die Daten mssen
abhngig von der Blockgre und der Schlssellnge eine bestimmte Anzahl an Runden
durchlaufen. Da es sich hier um AES handelt, sind nur die Runden, bezogen auf die feste
Blockgre von 128 Bit und den verschiedenen Schlssellngen, von Bedeutung. In der
Tabelle 2.1 sind die Runden aufgefhrt.
30
D
a
t
e
n
s
t
r
o
m
X
O
R
AddRoundKey()
S
u
b
B
y
t
e
(
)
S
h
i
f
t
R
o
w
s
(
)
M
i
x
C
o
l
u
m
s
(
)
X
O
R
AddRoundKey()
S
h
i
f
t
R
o
w
s
(
)
S
u
b
B
y
t
e
(
)
D
a
t
e
n
s
t
r
o
m

c
h
i
f
f
r
i
e
r
t
R
o
u
n
d
(
)
F
i
n
a
l
R
o
u
n
d
(
)
T
e
i
l
s
c
h
l

s
s
e
l
S
c
h
l

s
s
e
l
L
e
t
z
t
e
r

T
e
i
l
s
c
h
l

s
s
e
l
Abbildung 2.14: Fludiagramm von der Funktionsweise des AES-Algorithmus
31
Schlssellnge Datenblocklnge 128 Bit
128 Bit 10
192 Bit 12
256 Bit 14
Tabelle 2.1: Anzahl der Runden bezogen auf die Schlssellnge und einer Blockgre von
128 Bit
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
0 x Linksshift
1 x Linksshift
2 x Linksshift
3 x Linksshift
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Abbildung 2.15: Darstellung der ShiftRow() Funktion
Fr Nr-viele Runden bentigt man Nr-Teil-Schlssel also fr jede Runde einen Schlssel.
Da der Schlssel nur 128 bis 256 Bit lang ist, muss er erweitert werden. Dies geschieht
durch ein mathematisches Verfahren, das abhngig vom Schlssel weitere Werte erzeugt,
die mglichst unvorhersagbar sind. Derselbe Startwert erzeugt immer wieder die gleichen
Werte fr die Teil-Schlssel.
Mit der Funktion AddRoundKey() wird jeder Schlsselblock mit den Daten "exclusiv"
verodert (XOR-Funktion). Dies geschieht vor der ersten Runde und nach jeder durch-
laufenden Runde. Dabei wird nur in der ersten Runde der eigentliche Schlssel vom
Benutzer mit dem Datenblock verodert. Bei allen weiteren Runden werden die zuvor
erzeugten Teilschlssel verwendet.
Die ShiftRow() Operation verschiebt die einzelnen Zeilen nach einem bestimmten Muster
und zwar werden je nach Lnge des Datenblocks die einzelnen Zeilen nach links verschoben.
(siehe Abbildung 2.15) Die Tabelle 2.2 veranschaulicht um wieviele Stellen die Zeilen
nach links geschoben werden beim AES-Standard.
Zeile Datenblocklnge 128 Bit
1 0
2 1
3 2
4 3
Tabelle 2.2: Shift-Werte fr Blocklnge 128 Bit
32
Die Funktion SubByte() wendet eine Art Substitutionsverfahren auf den Datenstrom
an. Wichtig ist die Substitutionstabelle (S-Box). Die S-Box arbeitet jedes Byte einzeln
ab. Fr jeden Wert den ein Byte annehmen kann, gibt es in der Substitutionstabelle
einen Wert, der daraufhin eingesetzt wird. Man bezeichnet dies auch als monoalphabe-
tische Verschlsselung. Dabei werden bestimmte Buchstaben bzw. Werte durch andere
Buchstaben bzw. Werte ersetzt.
Die Funktion MixColums() ist fr die Durchmischung der Spalten verantwortlich. Die 4
Bytes einer Spalte werden mit einer 4x4 Byte Matrix multipliziert. Man erreicht so eine
Wechselwirkung zwischen jedem Byte in der Spalte.
Die Entschlsselung des Datenstroms erfolgt logischerweise in der umgekehrten Reihen-
folge der eben beschriebenen Schritte.
2.7 Schlsselaustauschverfahren
Es gibt verschiedene Verfahren mit denen Schlssel ausgetauscht werden knnen. Ich
werde hier speziell auf das Di Hellman Verfahren und auf das RSA-Verfahren zu
sprechen kommen, weil diese auch vom Open Scape Voice Server verwendet werden. Der
Sinn hinter den Schlsselaustauschverfahren liegt in der Bildung eines Geheimnisses
zwischen den beiden Kommunikationsteilnehmern, obwohl diese noch nie mit einander
kommuniziert haben und kein geheimer Kanal (abhrsichere Verbindung) zur Verfgung
steht. ber die asymmetrische Verschlsselung wird dem Kommunikationspartner ein
symmetrischer Schlssel bermittelt. So hat man die Mglichkeit ber einen ungesicherten
Kanal vertrauliche Daten zu bermitteln. Es ist nicht mehr notwendig einen geheimen
Kanal zu erzeugen.
2.7.1 Das Di Hellman Verfahren
Bei dem Di Hellman Verfahren handelt es sich um ein asymmetrisches Verfahren. Streng
genommen handelt es sich bei diesem Verfahren nicht um einen Schlsselaustausch,
sondern um eine Schlsselvereinbarung, da beide Seiten ein gleiches Geheimnis berechnen.
Wie kann so etwas funktionieren?
Die Grundlage fr dieses Verfahren bietet uns die diskrete Exponentialfunktion:
c c := p

:od(j)(c `)
33
Diese Funktion ist eine Einwegfunktion. Die Berechnung in die eine Richtung ist einfach
durchzufhren aber die Rckrechnung ist ohne eine geheime Information nicht mehr
mglich. Es muss also von beiden Kommunikationspartnern eine geheime Zahl bestimmt
werden, damit eine Rckrechnung der trapdoor-Einwegfunktion mglich ist.
Bestimmung der geheimen Zahl (Information):
1. Beide Partner einigen sich auf eine Primzahl p und eine natrlich Zahl g (1<g<p).
2. In (p, g) liegt noch kein Geheimnis diese Zahlen knnen entlich sein. Sie bilden
die Grundlage fr die Berechnung der geheimen Zahl.
3. Es wird auf jeder Seite eine zufllige natrliche Zahl a bzw. b generiert (a<p-1,
b<p-1).
4. Berechnung von c bzw.
c := p

:od(j)
bzw.
:= p

:od(j)
5. Nun werden c und ber den ungesicherten Kanal ausgetauscht.
6. Die Rckrechnung erfolgt ber die eigens gewhlte Zufallszahl a oder b.
7. Das ausgetauschte c bzw. wird nun mit der Zufallszahl potenziert.
/ :=

:od(j)
bzw.
/

:= c

:od(j)
8. k und k sind identisch, somit haben beide Seiten ein und dasselbe Geheimnis.
Das k und k wirklich identisch sind, lsst sich beim zurckverfolgen der Rechnung
beweisen.
fr k:
/ :=

:od(j) = (:

:od(j) = :

:od(j)
34
Sender Empfnger
- Einigung auf eine Primzahl p
- Whlen einer zuflligen Zahl g
(1<g<p)
Generierung einer
Zufallszahl a (a<p-1)
Generierung einer
Zufallszahl b (b<p-1)
Berechnung von Berechnung von
p g
a
mod p g
b
mod
Berechnung von k Berechnung von k

p k
a
mod p k
b
mod
Abbildung 2.16: Schematische Darstellung des Di-Hellman Schlsselaustausches
fr k:
/

:= c

:od(j) = (:

:od(j) = :

:od(j)
Wenn :

= :

ist, denn muss folglich / = /

sein.
Sicherheitsaspekte
Weshalb ist dieser Schlsselaustausch so sicher wenn man die Primzahl p und die natrliche
Zahl g preisgibt und sogar noch die errechneten Werte c und unsicher bertrgt?
Ein Hindernis fr den Angreifer ist die Ermittlung der Zufallszahlen a und b. Da liegt
auch der Kni der Einwegfunktion. Die diskrete Exponentialfunktion ist relativ leicht
durchfhrbar, ihre Umkehrung die diskrete Logarithmusfunktion nicht. Es ist nach den
heutigen Kenntnissen in der Mathematik nahezu unmglich die Gleichung c := p

:od(j)
nach a aufzulsen. Um durch probieren an die Zufallszahlen zu gelangen, bruchte man
10
100
Versuche, da die Zufallszahlen 100 bis 200 Dezimalstellen besitzen.
2.7.2 Das RSA-Verfahren
Das RSA-Verfahren wurde entwickelt, um zu beweisen, dass eine Public-Key-Kryptographie
unmglich ist. Der Name RSA bildet sich aus den Anfangsbuchstaben der Nachnamen
von den Entwicklern. R. Rivest, A. Shamir und L.Adelman haben den Algorithmus 1978
entwickelt. Es ist, wie das Di Hellmann Verfahren, ein asymmetrisches Schlsselaus-
tauschverfahren.
Die mathematische Voraussetzung ist einmal die Berechnung des Modulus ber 2 groe
Primzahlen p und q.
35
: = j
Es wird nun ein entlicher Exponent e gewhlt, der aber teilerfremd zu (p-1)(q-1) sein
muss. Ansonsten existiert kein modulares Inverse. Der erweiterte Euklidische Algorithmus
hilft nun das d zu bestimmen.
c d = 1[:od((j 1)( 1))]
Nun besitzt man mit dem Zahlenpaar (n,e) den entlichen Schlssel und mit d den
privaten Schlssel. Wichtig ist fr die Sicherheit des Verfahrens, dass die beiden Prim-
zahlen zerstrt oder geheimgehalten werden, ansonsten knnte man daraus den privaten
Schlssel errechnen.
Eine Information k wird anschlieend ber diese Gleichung verschlsselt.
c = /

:od(:)
Die Entschlsselung erfolgt ber diese Gleichung.
/ = c

:od(:)
Die Mglichkeit, das RSA-Verfahren zu knacken, liegt darin aus n wieder p und q zu
erhalten, um daraus den privaten Schlssel d zu berechnen. Genau da liegt die Sicherheit
des Verfahrens. Es ist zwar einfach 2 Zahlen zu multiplizieren aber es wird immer
schwieriger zu faktorisieren je grer die Zahl n ist.
Die Schlssellnge fr RSA, also der Modulus n, liegt heute zwischen 768 Bit und 2048
Bit. Je hher die Schlssellnge ist, umso mehr Sicherheit kann garantiert werden. Der
Nachteil liegt bei grerer Schlssellnge in der hheren Systemlast.
2.8 Key Management Protokoll
2.8.1 Das MiKey Verfahren
Das Multimedia Internet KEYing (MiKey) Verfahren wurde entwickelt, um ein Schlssel-
mangement speziell fr die Echtzeit-Kommunikation zur Verfgung zu stellen.
Die IETF hat das Verfahren unter RFC3830 folgendermaen standardisiert [Ark]:
36
I-M
e
s
s
a
g
e
R
-M
essage
Abbildung 2.17: Messageaustausch von MiKey
Sicherheit von Ende-zu-Ende. Nur die jeweiligen Kommunikationspartner haben
Zugri auf die erzeugten Schlssel
Einfachheit
Ezienz
diese wird realisiert durch einen geringen Verbrauch an Bandbreite und Rechenlei-
stung, einen schlanken Code und dass die Parameter fr den Schlsselaustausch in
einem Round trip bertragen werden
Das Mikey-Verfahren im Zusammenhang mit SRTP ist dafr zustndig den Master
Key und Master Salt auf sichere Art und Weise zu verteilen. Es wird zuvor ein TEK
Generation Key (TGK) erzeugt und verteilt. Mit Hilfe eines Algorithmus, der von MiKey
zur Verfgung gestellt wird, kann von SRTP der Master Key und Master Salt erstellt
werden.
Es gibt 3 Arten fr die Verteilung der Schlssel:
Pre-Shared Key
Public Key
Die-Hellmann
An der Abbildung 2.17 kann man erkennen, wie der grundstzliche Nachrichtenaustausch
von Mikey aussieht. Die I-Message wird vom Initiator der Schlsselverteilung geschickt.
37
Der Empfnger schickt als Besttigung eine R-Message, die schon verschlsselte Informa-
tionen enthlt. Die R-Message kommt aber nicht bei jeder Betriebsart vor und ist somit
optional.
MiKey mit Pre-Shared Key
In diesem Betriebsmode wurde schon vorher ein Geheimnis bermittelt ein Pre-Shared-
Key (PSK), dies kann ber eine manuelle Konguration erfolgen. Mit Hile eines Pseudo-
zufallszahlengenerator erstellt der Initiator ein TGK und verschlsselt diesen mit dem
PSK. Diese Information wird mit einer weiteren Zufallszahl und einem Time Stamp in
ein Paket verpackt. ber das ganze Paket wird ein Hashwert erzeugt und im Message
Authentication Code Feld abgespeichert. Die so erstellte I-Message wird bertragen. Der
Empfnger errechnet den Hashwert erneut und vergleicht ihn mit dem empfangenen
Message Authentication Code. Wenn beide bereinstimmen wurde die Integritt gewahrt,
demnach ist der Absender authentisiert und kennt das PSK.
MiKey mit Public Key
In diesem Betriebsmode wird auf den RSA-Algorithmus zurck gegrien. Dies bedeutet,
dass man ein asymmetrisches Verschlsselungsverfahren verwendet, das Zertikate und
entliche bzw. private Schlssel bentigt. Wichtig ist in diesem Fall, dass der Initiator
den entlichen Schlssel seines Gegenbers bentigt. Um einen TGK zu erzeugen,
generiert der Initiator einen Envelope Key und verschlsselt diesen mit dem entlichen
Schlssel des Empfngers. Es wird wie bei MiKey mit Pre-Shared Key eine I-Message
erzeugt mit dem selben Inhalten, auer dass der verschlsselte Envelope Key und das
Zertikat des Senders mit drin enthalten ist. Statt des Message Authentication Code
wird hier eine Signatur mit geschickt. Bei der Signatur handelt es sich um eine digitale
Unterschrift (siehe Kapitel Digitale Unterschrift).
Der Empfnger prft beim Empfang der I-Message das Zertikat vom Sender und ermittelt
so die Echtheit des entlichen Schlssel. Mit diesem entlichen Schlssel kann die
Signatur berprft werden und die Integritt der Nachricht und die Authentizitt des
Senders festgestellt werden. Der verschlsselte TGK kann mit dem entlichen Schlssel
des Empfngers entschlsselt werden. Nun ist der Empfnger in der Lage aus dem TGK
die Master Keys und Master Salts zu berechnen.
MiKey mit Die-Hellmann
In diesem Betriebsmodus wird das Prinzip des Di-Hellman Verfahrens angewendet.
(siehe Kapitel Das Di-Hellman Verfahren) Da die Schlsselgenerierung von beiden Seiten
durchgefhrt werden muss, kommt hier die R-Message ins Spiel. Nach dem Austausch
besitzen beide Partner das c bzw. des Anderen. Beide sind dadurch in der Lage einen
geheimen Schlssel zu erzeugen, der wiederum der TGK ist.
38
2.9 Einsatz einer (Voice)Firewall
Nachdem alle Protokolle behandelt wurden, die den Datenstrom verschlsseln, mchte
ich nun auf eine andere Art der Sicherheit in NGNs kommen. Bisher habt man die Daten
vor Mitlauschen und Vernderung geschtzt. Damit man einem Angreifer aber erst gar
nicht die Chance gibt in das Netz einzudringen, gibt es die Mglichkeit eine Firewall
zwischen dem sicheren Netz und dem unsicheren Netz zuschalten. Ein Problem bei
VoIP-Gesprchen ist das Transportprotokoll UDP. Es ist durch seinen verbindungslosen
Charakter nicht dafr geeignet durch Firewalls erkannt zu werden und mittels einer
Portregel einen Port zu nen an der Firewall. Wenn man nun dauerhaft einen Port
freischaltet, ist dies auch gleich eine Sicherheitslcke in dem Netz. Eine Lsung bietet die
State Tables.
2.9.1 State Table
Die Funktionsweise einer State Table ist relativ simpel. Normalerweise werden UDP-
Pakete aus einem unsicheren Netz generell abgewiesen. Wenn aber ber eine bestimmte
Adresse innerhalb des sicheren Netzes Datenpakete nach auen gehen, wird genau fr
diese Adresse dynamisch eine Ausnahme (Portregel) in der State Table erstellt. Die
Firewall lsst nun auch Verkehr aus dem unsicheren Netz durch. Da es bei UDP keinen
Verbindungsabbau gibt, wird der Eintrag in der State Table nach ca. 30s Inaktivitt
gelscht. Dies verhindert, dass Angreifer unntig viel Zeit bekommen, um ber diese
oene Stelle einzufallen.
Wie soll man mittels einer State Table nun die verschiedenen RTP- und RTCP-Strme
mit den zugehrigen Ports auseinanderhalten die eine TK-Anlage fr jedes Gesprch
hndeln muss? Man muss der Firewall mehr Intelligenz verpassen und ihr die Mglichkeit
geben die Signalisierung ber SIP zu verstehen.
2.9.2 Application Layer Gateway
Ein Application Layer Gateway hat Kenntnis ber Anwendungen, die ber Layer 4
des OSI-Modells hinausgehen. Dies bedeutet, dass das Gateway die Signalisierung von
VoIP lesen und verstehen kann. So kann aus dem Signalisierungsprotokoll entnommen
werden, mit welchem Teilnehmer eine Verbindung aufgenommen bzw. abgebaut wird
und ber welche Transportadresse und Ports dies geschiet. In einer State Table werden
die entsprechenden Eintrge vorgenommen und alle relevanten Port fr die Dauer des
Gesprchs genet.
39
2.9.3 Session Border Controller
Der Session Border Controller (SBC) stellt eine Abwandlung des MIDCOM-Konzeptes
(RFC3303 Middlebox communication architecture and framework) dar. Dies besagt, dass
man einer Firewall nicht unbedingt mehr Anwendungsintelligenz geben muss, wenn diese
schon durch SIP-Proxys vorhanden ist. Man kann auch den Servern (MIDCOM Agent)
die Mglichkeit geben eine Firewall (Middlebox) entsprechend zu steuern.
Der SBC besitzt einen SIP-Proxy (MIDCOM-Agent) und einen Media-Proxy (Middlebox).
Der SIP-Proxy schaltet sich in den Signalisierungsweg mit ein und alle Gesprche die
nach extern gefhrt werden, haben als Urheber den SBC. Somit gehen alle Signalisierungs-
und Medienstrme ber den SBC. Darin liegt auch ein Vorteil des SBCs. Es gibt einen
zentralen Punkt fr die Carrier, ber den alle Daten laufen, somit wird ihnen das
richterliche Abhren und das Accounting vereinfacht. Auerdem muss eine Firewall nicht
mehr als Application Layer Gateway konguriert werden.
2.10 Angrismethoden auf NGNs
Alle vorher besprochenen Protokolle sollen einen Angri auf NGNs verhindern oder
zumindest erschweren. Da man das IP-Protokoll nutzt, um die Daten durch das Netz zu
transportieren, hat man mit den gleichen Angrien zu kmpfen, wie bei den klassischen
Internetanwendungen.
Man kann einen Angri in 2 Klassen aufteilen einmal der passive und der aktive Angri.
Bei dem passiven Angri beschrnkt sich der Angreifer auf das Mitlesen, Protkollieren
und Auswerten der Daten.
Der aktive Angreifer ist weitaus gefhrlicher. Er hat die Mglichkeit Pakete zu verndern
oder neue zu generieren, die er seinem ahnungslosen Opfer einfach unterschieben kann.
Ein gefhrlicher aktiver Angri stellt die Man-in-the-middle Attacke dar. Ein bswilliger
Nutzer schaltet sich zwischen 2 Teilnehmern. In dieser Position hat er die Mglichkeit,
den gesamten Datenstrom ber ihn laufen zu lassen. Er kann den Inhalt der Pakete lesen,
verndern oder aber Pakete im Namen eines Teilnehmers erzeugen, ohne das dieser es
bemerkt. Die einfachste Form diesem Angri entgegen zutreten, ist die Verschlsselung
der Daten mittels SRTP.
Das Bundesamt fr Sicherheit in der Informationstechnik hat 4 Angrie dargestellt, die
fr VoIP gefhrlich sind [fSidI05] :
Netzwerk- und Port-Scans
Bei Netzwerk- und Port-Scans sendet der Angreifer Anfragen in ein Netzwerk oder an
einen Rechner, um bestimmte Informationen (wie Rechner eines Subnetzes, installierte
40
Dienste, installierte Betriebssysteme und deren Versionen) zu ermitteln. In der Praxis
werden sie meist zum Aunden mglicher Schwachstellen und zur Vorbereitung des
eigentlichen Angris verwendet.
Spoong Angrie
Bei Spoong Angrien sendet der Angreifer Nachrichten oder Pakete mit geflschten
Informationen. Diese werden hug als Baustein oder in Kombination mit weiteren
Angristechniken verwendet. Bekannte Spoong Angrie umfassen das IP Spoong, wobei
der Angreifer Teile des IP-Headers (meist die IP-Quelladresse) flscht, beispielsweise, um
Adressen-basierendes Vertrauen in dem Opfersystem auszunutzen. Beim ARP Spoong
flscht der Angreifer ARP-Antworten, wodurch das Opfersystem eine IP-Adresse mit
einer falschen MAC-Adresse (engl. medium access control) assoziiert und somit IP-Pakete
im Ethernet-LAN fehlgeleitet werden. Beim DNS Spoong flscht der Angreifer DNS-
Antworten und kann dadurch das Opfersystem auf seine eigene IP-Adresse umleiten.
Replay Angrie
Replay Angrie bestehen darin, dass ein Angreifer (authentisierte) Nachrichten aufzeich-
net, um sie zu einem spteren Zeitpunkt erneut zu senden.
DoS und DDoS Angrie
DoS (engl. denial of service) Angrie zielen auf die Verfgbarkeit von IT-Systemen,
indem deren Ressourcen wie Speicher, Rechenleistung oder Netzwerkbandbreite in hohem
Mae durch den Angreifer verbraucht werden. DoS Angrie knnen darin bestehen,
dass der Angreifer den Service des Opfersystems regulr nutzt (beispielsweise eine
groe Anzahl legaler Suchanfragen startet). Huger werden jedoch Schwachstellen
in Implementierungen (z. B. des Netzwerkstacks beim Ping of Death [Kle01]) oder in
Protokollen (z. B. der TCP-Handshake beim SYN-Flooding oder der Broadcast von ICMP
Echo Request beim Smurf-Angri [Kle01]) ausgenutzt. Unter DDoS (engl. distributed
denial of service) Angrien versteht man einen konzertierten DoS Angri, bei dem mehrere
Systeme, hug durch den Einsatz von Malware und durch einen einzelnen Angreifer
gesteuert, einen DoS Angri gegen das Opfersystem durchfhren. Durch die hohen
QoS-Anforderungen von VoIP-Systemen sind diese extrem anfllig gegen DoS-Angrie.
41
Kapitel 3
Praktische Anwendung am Open
Scape Voice Server (HiPath8000)
In diesem Kapitel mchte ich die zuvor gelegten theoretischen Grundlagen auf eine
praktische Anwendung beziehen. Der OpenScapeVoice Server ist ein Element zum Aufbau
eines NGNs. Der Server verwaltet alle Clients und ist fr den Aufbau der Kommunikation
zwischen 2 oder mehr Teilnehmer verantwortlich. Er ist auerdem der Mittelpunkt, um
gesicherte und verschlsselte Verbindungen herzustellen.
Die Planung und Einrichtung der Sicherheitsrichtlinien bezieht sich auf eine Laborumge-
bung, die von mir erstellt worden ist. Im Kapitel Planung von Securityrichtlinien werde
ich auf die fr die Laborumgebung relevanten Richtlinien zu sprechen kommen. Ein
allgemeine Planung von Richtlinien und Manahmen kann aus dem Dokument VoIPSEC
- Studie zur Sicherheit von Voice over Internet Protocol vom Bundesamt fr Sicherheit in
der Informationstechnik entnommen werden. [fSidI05]
3.1 Planung von Securityrichtlinien in NGN
Bevor wir uns an die Konguration der Sicherheitsmerkmale am Open Scape Voice
Server machen, mu man sich zuvor erstmal Gedanken um die Sicherheitsrichtlinien
machen. Die Fragen, die man sich dabei stellen sollte, lauten: Wie sichere ich auf der
physikalischen Ebene meinen Server und weiter Komponenten? Wie sichere ich den
Netzwerkbetrieb auf logischer Ebene vor internen und externen Angrien? Wie hoch soll
die Sicherheit fr den Datenaustausch zwischen den Kommunikationsteilnehmern sein?
Verschlsselt man nur die Sprachdaten oder verschlsselt man auch die Signalisierung?
Bentigt man Zertikate oder sogar eine Public Key Infrastructure (PKI) also eine
Zertikatsherachie? Das Sicherheitskonzept ist keine universale Einzellsung, sondern
besteht vielmehr aus vielen Einzelschritten, die fr sich allein genommen wenig Schutz
42
bieten. Im Zusammenspiel knnen sie die Angrimglichkeiten deutlich reduzieren und
den Dienst sicher und ausfallfrei halten.
3.1.1 Sicherung der Komponenten auf physikalischer Ebene
Es ist beraus wichtig das alle Komponenten vor dem direkten Zugri nicht-autorisierter
Personen geschtzt werden. Dies kann man erreichen, indem die Komponenten in Zutritts
gesicherten Rumen aufgebaut werden. Die Rume sind entweder durch Schlsser gesichert
oder nur ber eine Smartcard und Eingabe eines Pins zu betreten. Innerhalb dieser
Rumlichkeiten ist es auch wichtig Manahmen gegen Stromausfall, Wasserschaden
oder Feuer zu ergreifen, um die Verfgbarkeit sicherzustellen. Kabeltrassen, die zu
dem Serverraum fhren, sollten ebenso vor fremden Zugrien geschtzt werden. Der
Grundgedanke hinter diesen Manahmen ist, dass der direkte Zugri eines Angreifers auf
die Hardware alle anderen Sicherungsmanahmen aufhebt, da sie vom Angreifer direkt
manipuliert werden knnen!
3.1.2 Sicherung des Netzwerkbetriebs auf logischer Ebene
Zunchst sollte, aufgrund von Skalierbarkeit und Management der Netze, das Datennetz
und das Sprachnetz von einander getrennt werden. Dies geschiet auf Ebene 2 des OSI-
Modells durch virtuelle LANs (VLANs). Die Netze knnen so logisch getrennt werden.
Das allein reicht zum Schutz nicht aus. Ein Angreifer knnte sich immer noch an den
VLAN-Port hngen und wre so auch im Sprachnetz. Unterbinden kann man dies durch
dynamische oder statische Zuordnung der MAC-Adresse zu Port und VLAN-Zugrislisten.
So knnen Angrie von innen heraus vereitelt werden. Gegen externe Angrie hilft eine
VoiceFirewall, um Attacken von auen in das Netz hinein aufzuhalten.
3.1.3 Verschlsselung der Sprachdaten und der Signalisierung
Die Verschlsselung der Sprachdaten ist wichtig, um das Abhren von Gesprchen zu
vermeiden. Man kann dafr einen VPN-Tunnel zwischen den Teilnehmern aufbauen, da
dieser zu viel Overhead hat, nutzen wir ein bekanntes Protokoll zum Verschlsseln der
Sprachdaten, nmlich SRTP. Weitaus wichtiger ist die Verschlsselung der Signalisie-
rungsdaten. Eine Manipulation dieser Daten kann verheerende Folgen haben. Da auch
Gebhren ber die Signalisierung abgerechnet werden, liee sich so ein Gebhrenbetrug
realisieren zum Schaden der Firma oder ein anderes Beispiel wre die Mglichkeit in
der Firma alle Telefone luten zu lassen oder vereinzelt Klingelstreiche durchzufhren.
43
Wir sichern deshalb unseren SIP-Verkehr zwischen den einzelnen Instanzen mit TLS ab,
bedeutet das zwischen 2 SIP-Intanzen eine TLS-Verbindung aufgebaut wird.
3.1.4 Einsatz von Zertikaten und Zertikatsherachien
Bei einer Kommunikation zwischen 2 Teilnehmern ist es immer wichtig, dass jeder
Teilnehmer sich sicher sein kann, dass sein Gegenber auch wirklich er selbst und
vertrauenswrdig ist. Damit sich Server und Telefone untereinander authentisieren knnen,
werden Zertikat eingesetzt. Damit man nun auch den Zertikaten vertrauen kann, wird
eine ganze Zertikatsherachie bentigt. So kann die Zertikatskette zurckverfolgt werden
und die Echtheit des Zertikats besttigt werden.
3.2 Einrichtung der Securityrichtlinien am Open
Scape Voice Server in einer Laborumgebung
Nun mchte ich auf die eigentliche praktische Anwendung bzw. Integration unseres
Sicherheitskonzepts zu sprechen kommen. Zunchst einmal bentigen wir eine geeignete
Laborumgebung in der wir die Richtlinien aufsetzen und testen knnen.
3.2.1 Aufbau der Laborumgebung
Wie aus Abbildung 3.1 zu entnehmen ist besteht die Teststellung aus 2 Open Scape Voice
Server (Node 1 und 2), einer HG8700 und einer HG35xx. Die 5 Telefone dienen als Client.
Die Beziehungen zu einander sind logisch aufgebaut. Die physikalische Anbindung wurde
anders realisiert.
3.2.2 Aufbau einer Zertikatsherachie
Fr die Authentisierung der Telefone am Open Scape Voice Server, zwischen den beiden
Servern und zwischen Server und HG35xx bentigt man Zertikate und eine Zertikats-
herachie. Zum Erstellen eigener Zertikate und Herachien nutzt man das frei verfgbare
Programm OpenSSl. Dieses Tool ist auch schon im Open Scape Voice Server integriert.
Fr Testzwecke reichen selbst erstellte Zertikate vollkommen aus. Ein Problem entsteht,
wenn man den Open Scape Voice Server in eine bestehende Public-Key-Infrastructure
44
S
e
c
u
r
i
t
y
-
V
o
i
c
e
n
e
t
z
p
l
a
n

(
l
o
g
i
s
c
h
)
N
o
d
e

1
N
o
d
e

2
1
0
4
5
1
0
4
6
1
0
4
7
H
G

3
5
x
x

A
c
c
e
s
s

G
a
t
e
w
a
y
1
0
4
8
1
0
6
4
R
G

8
7
0
0
T
r
a
n
s
i
t
I
S
D
N

/

A
M
T
T
K
-
N
e
t
z

a
l
t
D
a
r
s
t
e
l
l
u
n
g

d
e
r

l
o
g
i
s
c
h
e
n

S
t
r
u
k
t
u
r

d
e
r

T
e
s
t
s
t
e
l
l
u
n
g

z
u
m

t
e
s
t
e
n

v
o
n

S
e
c
u
r
i
t
y
-
M
e
r
k
m
a
l
e
n

i
m

N
G
N
.

A
l
l
e

r
e
l
e
v
a
n
t
e
n

B
a
u
e
l
e
m
e
n
t
e
,

T
e
i
l
n
e
h
m
e
r

u
n
d

d
e
r
e
n

B
e
z
i
e
h
u
n
g
e
n

u
n
t
e
r
e
i
n
a
n
d
e
r

s
i
n
d

a
u
s

d
e
r

A
b
b
i
l
d
u
n
g

z
u

e
n
t
n
e
h
m
e
n
.
Abbildung 3.1: Netzplan der Laborumgebung (logisch)
45
Zertifizierungsstellen-Stammzertifikat ROOT CA
Zertifizierungsstellen-Zertifiakt SERVER CA
Zertifikat SERVER +
privaten Schlssel
Zertifikat CLIENT +
privaten Schlssel
Zertifizierungsstellen-Stammzertifikat
ROOT CA signiert das
Zertifizierungsstellenzertifikat SERVER
CA und das Zertifikat CLIENT mit seinem
ffentlichen Schlssel. Die SERVER CA
signiert das Zertifikat SERVER mit
seinem ffentlichem Schlssel.
Abbildung 3.2: Zertikatsstruktur fr die Laborumgebung
von Microsoft Windows integrieren mchte. Man kann in diesem Fall auf OpenSSL und
die Sicherheitsverwaltung von Windows Server zurckgreifen.
Zertikate/-herachien erstellen mit OpenSSL
OpenSSL ist ein Kommandozeilen-Tool. Mit dessen Hilfe werden Zertikate und Zerti-
katsantrge erzeugt. Es wird eine Zertikatsstruktur erstellt, wie sie in der Abbildung
3.2 zu sehen ist.
Erstellung des Root CA Zerti fi kats
Bei diesem Zertikat handelt es sich um ein Zertizierungsstellen-Stammzertikat. Es ist
die Wurzel einer Herachie und somit die hchste Instanz der man vertraut. Ein Root-CA
wird meitens einmal erstellt, um damit weitere Stammzertikate zu erstellen. Es besitzt
eine lange Lebensdauer und wird unter den hchsten Sicherheitsvorkehrungen unter
Verschlu gehalten. Ein Verlust des Vertrauens in dieses Zertikat wrde die gesamte
Zertikatskette aufheben. Es sei erwhnt, dass folgende Vorgehensweise zur Erstellung
der Zertikate nur in einer Teststellung Anwendung nden sollte.
Alle Befehle mssen als Root ausgefhrt werden:
1. openssl req -newkey rsa:1024 -sha1 -keyout rootkey.pem -out rootreq.pem -cong
46
root.cnf nodes
Mit "openssl req" erstellen wir ein Zertikatsrequest, bedeutet eine Zerti-
katsanfrage.
Die Option "-newkey rsa:1024" erstellt uns einen 1024 Bit langen privaten
RSA Schlssel. Die Schlssellngen knnen von512 bis 2048 gewhlt werden.
"-sha 1" ist die Wahl fr den Secure Hash Algorithm, um das Zertikat zu
signieren.
"-keyout rootkey.pem" speichert den privaten Schlssel in der Datei root-
key.pem
"-out rootreq.pem" speichert die Anfrage in die Datei rootreq.pem
"-cong root.cnf" weit an die Vorlage root.cnf zu nutzen um Daten wie Name,
Ablaufzeit, Lnderkennung usw. ins Zertikat einzutragen
"-nodes" lsst den privaten Schlssel im Klartext stehen
2. openssl x509 -req -in rootreq.pem -sha1 -extle root.cnf -extensions v3_ca -signkey
rootkey.pem -out rootcert.pem -days 3650
Der Befehl "openssl x509" signiert Zertikate und Zertikatsanfragen
Die Option "-req -in rootreq.pem" stellt ein Zertikat auf eine Zertikatsan-
frage aus. In unserem Fall wird dafr die rootreq.pem als Zertikatsanfrage
gewhlt.
"-extle root.cnf -extensions v3_ca" Es soll wieder die Vorlage root.cnf
verwendet werden. Extensions v3_ca makiert das Zertikat eindeutig als
Zertizierungsstellen-Stammzertikat
"-signkey rootkey.pem" Eine Root-CA signiert sich immer selber, dies geschiet
durch den Befehl signkey mit anschlieender Angabe des privaten Schlssels
der Root-CA.
"-out rootcert.pem" Das Zertikat wird erstellt und in rootcert.pem gespeichert
"-days 3650" gibt die Tage bis zum Ablauf des Zertikats an
3. openssl x509 -text -noout -in rootcert.pem
47
Mit der Option "-text -noout -in rootcert.pem" knnen wir uns das erstellte
Zertikat anschauen
Nun besitzt man ein Zertizierungsstellen-Stammzertikat mit dessen Hilfe man viele
weitere Zertizierungstellen zertizieren knnte. Es folgt die nchste Ebene der Zertikate,
die sogenannten Intermediate CA.
Erstellung des Server CA Zerti fi kats
Diese Zertizierungstelle ermglicht es Zertikate fr Server zu signieren ohne dabei
auf die Root-CA zugreifen zu mssen. Man wird im Verlauf sehen, dass das Server CA
Zertikat von der Root-CA zertiziert wird.
1. openssl req -newkey rsa:1024 -sha1 -keyout serverCAkey.pem -out serverCAreq.pem
-cong serverCA.cnf nodes
Der erste Befehl ist identisch wie der zur Erstellung der Root-CA. Einzige
nderung sind die Namen der erstellten und genutzten Dateien
2. openssl x509 -req -in serverCAreq.pem -sha1 extle serverCA.cnf -extensions v3_ca
CA rootcert.pem CAkey rootkey.pem -CAcreateserial -out serverCAcert.pem -days
3650
Die interessante Stelle in diesem Befehl ist " CA rootcert.pem CAkey root-
key.pem " hier wird jetzt mit dem Root-CA das Server CA signiert
"-CAcreateserial" erstellt eine Seriennummer fr das Zertikat
3. cat serverCAcert.pem serverCAkey.pem rootcert.pem > serverCA.pem
Der Befehl fgt jetzt das Server-CA Zertikat inklusive Schlssel und Root-
CA Zertikat zusammen in die Datei serverCA.pem. Jetzt besitzen wir eine
intermediate CA, die von der Root-CA signiert wurde und das Root-CA
Zertikat enthlt.
Nun besitzt man eine 2-stuge Zertikatsherachie. Das Server-CA enthlt die Zerti-
katskette bis zur Root-CA hoch. Mit dieser Zertizierungsstelle generiert man ein Server
Zertikat.
Erstellung ei nes Server Zerti fi kats
1. openssl req -newkey rsa:1024 -sha1 -keyout serverkey.pem -out serverreq.pem -cong
server.cnf nodes
48
Die Erstellung der Zertikatsanfrage gleicht denen der vorher erstellten
2. openssl x509 -req -in serverreq.pem -sha1 extle server.cnf -extensions v3_req CA
serverCA.pem Cakey serverCAkey.pem -CAcreateserial -out servercert.pem -days
3650
Die Server-CA signiert das Server Zertikat und erstellt wieder eine Serien-
nummer
3. cat servercert.pem serverkey.pem serverCAcert.pem rootcert.pem > server.pem
Zusammenfgen des Server Zertikats mit dem Schlssel und der Zertikats-
kette (Server-CA und Root-CA) in eine Datei server.pem
Erstellung ei nes Cli ent Zerti fi kats
1. openssl req -newkey rsa:1024 -sha1 -keyout clientkey.pem -out clientreq.pem -cong
client.cnf nodes
Die Erstellung der Zertikatsanfrage gleicht denen der vorher erstellten.
2. openssl x509 -req -in clientreq.pem -sha1 extle client.cnf -extensions v3_req CA
rootcert.pem CAkey rootkey.pem -CAcreateserial -out clientcert.pem -days 3650
Die Root-CA signiert das Client Zertikat und erstellt wieder eine Seriennum-
mer
3. cat clientcert.pem clientkey.pem rootcert.pem > client.pem
Zusammenfgen des Client Zertikats mit dem Schlssel und der Zertikats-
kette (diesmal nur die Root-CA) in eine Datei client.pem
Es ist vollbracht. Nun besitzt man eine Zertikatsherachie und mit Hilfe der Zertizie-
rungstellen werden 2 Zertikate erstellt eins fr die Server und eins fr die Clients. Man
muss beachten, dass mit Clients nicht die Telefone gemeint sind, die authentizieren sich
auf eine andere Art am Server. Mit Clients ist zum Beispiel eine HG35xx gemeint.
49
Zertikate/-herachien erstellen in einer WindowsSecurity-Umgebung mit
OpenSSL
In diesem Abschnitt erstellt man keine eigene Zertikatsherachie. Es gibt eine vorgegebene
Public-Key-Infrastructure in einer Windows Server Umgebung. Wichtige Voraussetzung
ist eine Domne in der die Zertikatsdienste installiert sind und eine Root CA plus Server
CA existiert. Leider ist die Vorgehensweise etwas umstndlich, da Windows und der
Open Scape Voice Server unterschiedliche Formate fr die Speicherung von Zertikaten
inklusive Schlssel nutzen. Auf die Formate komme ich zu gegebener Stelle zu sprechen.
Ich habe 2 Linux-Skripte erstellt damit man die Vorgehensweise etwas automatisieren
kann und dass sich keine Fehler bei der Durchfhrung einschleichen. Bei Bedarf knnen
diese Skripte (siehe Abbildung 3.3 & 3.4) abgeschrieben und modiziert werden.
Skript genCertReq.sh (generate Certicate Request):
Mit diesem Skript erstellt man die passenden Zertikatsanfragen an den Windows Zerti-
katsdienst. Der Befehl ist identisch mit dem 1. Befehl bei der Erstellung des Server- oder
Client-Zertikats aus dem vorherigen Kapitel. Es wird die Schlsselstrke angegeben, der
Name fr die Request-PEM-File, der Name fr die Schlsseldatei und optional ist die
Angabe einer Kongurationsdatei. Der erzeugte Zertikatsrequest, kann an die Zertikats-
stelle von Windows geschickt werden. Ein Securityadmin kann den Request bearbeiten
und daraus ein Zertikat erstellen. Wichtig ist, dass er die gesamte Zertikatskette mit
einbringt und nicht nur das einzelne Zertikat erstellt. Die Zertikatskette muss im
Format .p7b vorliegen. Es ist eine Containerdatei, die den gesamten Zertikatsverlauf
enthlt.
Skript conCert.sh (convert Certicate:
Wenn man von dem Securityadmin das ausgestellte Zertikat inklusive des Zertikats-
verlauf erhalten hat (.p7b Datei), kann man das Skript conCert.sh ausfhren. Zunchst
muss man die erhaltene Datei ins .pem Format berfhren. Der nchste Schritt ist
die Verknpfung des ausgestellten Zertikats mit dem zum Zertikatsrequest erstellten
privaten Schlssel. Man muss einen kleinen Umweg ber das .p12 Format nehmen, um
das entgltige Zertikat erstellen zu knnen. Der private Schlssel wurde vorher nicht im
Klartext gespeichert und ist somit durch ein Passwort geschtzt. Das heit man kann
die Dateien nicht einfach wieder zusammenfgen. Das .p12 Format ist eine gesicher-
te Container-Datei, die Zertikat und Schlssel enthlt. Der Vorteil des Formates ist
der Passwortschutz, da man ohne gltiges Passwort den Container nicht nen kann.
Nach dem Zusammenfhren von Zertikat und Schlssel kann man die .p12 Datei ins
.pem Format konvertieren und besitzt nun ein Zertikat mit eigenem Schlssel und der
Zertikatskette in der Windows Securityumgebung.
50
E:\studium\Security\wincerts\skripte\genCertReq.sh Donnerstag, 13. August 2009 17:18
#!/bin/sh
#
#genCertReq - generiert einen Schlssel und die dazugehrige Zertifikatsanforderung an eine
Windows Zertifizierungsstelle
#
#Autor: Felix Lange (felix.lange@siemens-enterprise.com)
#Date: 10.03.2006
#Company: SEN, Hamburg(Germany)
clear
echo "Dieses Shell-Skript generiert einen Schlssel und die dazugehrige
Zertifikatsanforderung an eine Windows Zertifizierungsstelle."
echo "Bitte geben Sie alle Dateinamen ohne Endung an!"
echo -e "\nBitte geben Sie die gewnschte Schlsselstrke an! (512, 1024, 2048)"
read KEYSTR
echo "Bitte geben Sie den Zertifikatsanforderungsnamen an!"
read CERTNAME
echo "Bitte geben Sie den Schlsselnamen an!"
read KEYNAME
echo "Gibt es eine Vorlage (cnf-Datei) fr das Zertifikat? Antwort mit (j)a oder (n)ein."
read -n 1 TASTE
if [ "$TASTE" == "j" ] ; then
echo -e "\nBitte geben Sie den Namen der Conf-Datein an"
read CONFNAME
echo -e "\nSchlssel und Zertifikastsanforderung werden erstellt!"
openssl req -newkey rsa:$KEYSTR -sha1 -keyout $KEYNAME.pem -out $CERTNAME.pem -config
$CONFNAME.cnf
elif [ "$TASTE" == "n" ] ; then
echo -e "\nSchlssel und Zertifikastsanforderung werden erstellt!"
openssl req -newkey rsa:$KEYSTR -sha1 -keyout $KEYNAME.pem -out $CERTNAME.pem
fi
clear
echo "Folgende Zertifikatsanforderung wurde erstellt"
echo -e "\n"
openssl req -in $CERTNAME.pem -text
echo -e "\n"
echo -e "\nLassen Sie sich jetzt mit Hilfe der "$CERTNAME".pem ein Zertifikat vom
Windows-Admin austellen und lassen sich die Zertifikatskette geben. (besitzt die Endung .p7b)"
echo "Kopieren sie die p7b-Datei in das Verzeichnis mit dem dazugehrigen Schlssel und
fhren die conCert.sh aus!"
echo -e "\n"
echo -e "\n"
-1-
Abbildung 3.3: Das Skript genCertReq.sh
51
E:\studium\Security\wincerts\skripte\conCert.sh Donnerstag, 13. August 2009 17:17
#!/bin/sh
#
#conCert - Konvertiert die Zertifikatskette (p7B) in das pem-Format und fgt den privaten
Schlssel ein
#
#Autor: Felix Lange (felix.lange@siemens-enterprise.com)
#Date: 10.03.2006
#Company: SEN, Hamburg(Germany)
clear
echo "Dieses Skript wandelt die Zertifikatskette (p7b) in das pem-Format um. Zustzlich wird
der zum Zertifikat passende private Schlssel mit eingefgt!"
echo "Bitte geben Sie alle Dateinamen ohne Endung an!"
echo -e "\nBitte geben Sie den Namen der Zertifikatskette an!"
read CERTCHAIN
echo "Zertifikatskette wird in das pem-Format konvertiert"
openssl pkcs7 -inform pem -in $CERTCHAIN.p7b -print_certs -out $CERTCHAIN.pem
echo -e "\nDie Datei" $CERTCHAIN".pem wurde erzeugt!"
echo -e "\nBitte geben Sie den Namen der zum Zertifikat miterzeugten Schlsseldatei an!"
read KEYNAME
echo "Die Zertifikatskette und der private Schlssel werden zusammen gefgt!"
openssl pkcs12 -export -inkey $KEYNAME.pem -in $CERTCHAIN.pem -out $CERTCHAIN.p12
echo -e "\nDie Datei" $CERTCHAIN".p12 wurde erzeugt!"
echo -e "\nDie PKCS12 Datei wird in das pem-Format berfhrt!"
echo "Bitte geben Sie den entgltigen Namen des Zertifikats an! (fr die H8K server oder
client)"
read CERTNAME
openssl pkcs12 -in $CERTCHAIN.p12 -out $CERTNAME.pem -nodes
clear
echo "Folgendes Zertifikat wurde erstellt"
echo -e "\n"
openssl x509 -in $CERTNAME.pem -text
-1-
Abbildung 3.4: Das Skript conCert.sh
52
HiPath 8000 RG 8700 HG 35xx SIP Phone
Zertifizierungsstellen-
Stammzertifikat ROOT CA
Diffie-Hellman
Zufallszahlen
/usr/local/ssl/certs/
Zertifizierungsstellen-
Stammzertifikat ROOT CA
Diffie-Hellman
Zufallszahlen
/data/ssl/certs
Zertifikat SERVER +
privaten Schlssel
Zertifikat CLIENT +
privaten Schlssel
Umbenennen:
ROOT CA CAcert.pem
Zertifikat SERVER muss ein
Duplikat vom Zertifikat CLIENT
sein
Zertifikate mssen im PEM-
Format (Base64) vorliegen
Diffie-Hellman Zufallszahlen
knnen ber OpenSSL erzeugt
werden
Zertifikat CLIENT +
privaten Schlssel
SPE Zertifikat
Zertifizierungsstellen-
Stammzertifikat ROOT CA
SPE CA-Zertifikat
Einspielen der Zertifikate ber
das Web Based Management
der HG 35xx
Zertifizierungsstellen-
Stammzertifikat ROOT CA
Telefonspeicher
Einspielen des Zertifikates ber
Deployment Service IP
Device IP Phone
Konfiguration Signalling und
Payload Encryption (SPE)
Zertifikat SERVER +
privaten Schlssel
Zertifikat CLIENT +
privaten Schlssel
/usr/local/ssl/private/
Abbildung 3.5: Zertikatsverteilung an die Komponenten
3.2.3 Zertikatsverteilung fr die einzelnen Komponenten
Die erstellten Zertikaten sind speziell fr die jeweiligen Komponenten gedacht. Die
Verteilung der Zertikate ist aus der Abbildung 3.5 zu sehen. Das SIP-Telefon bekommt
nur die ROOT CA mit, damit es das Zertikat vom OpenScape Voice Server (HiPath8000)
validieren kann. Deshalb besitzt auch die HG 35xx das ROOT CA zustzlich hndelt
es sein CLIENT-Zertikat um sich z.B. bei der HiPath zu authentisieren. Die RG 8700
ist in diesem Fall nicht von Interesse. Die HiPath 8000 hlt alle Zertikate vor. Das
SERVER-Zertikat dient zur Authentisierung als Server gegenber dem Telefon oder der
HG 35xx und das CLIENT-Zertikat dient beim Mutual Handshake dazu sich auch in
der Rolle als Client zu authentisieren.
3.2.4 Aufbau gesicherter Verbindungen zwischen Servern und
Telefonen
Nach dem alles konguriert und eingerichtet ist, mssen die verschiedenen Komponenten
untereinander eine gesicherte Verbindung aufbauen. Ich stelle die verschiedenen TLS-
Handshakes einmal schematisch dar und fge als Beweis einen Mitschnitt des Handshakes
durch Wireshark mit an. In Abbildung 3.6 wird der Kommunikationsverlauf dargestellt
53
und erlutert. Der Wireshark Trace ist in Abbildung ?? zu sehen. Die wichtigen Pakete fr
den Handshake sind schwarz hervorgehoben. Der Handshake und die anschlieende SIP
Registrierung ist in dem Trace im Klartext zusehen. Der Grund dafr ist das einbinden des
Serverzertikats in Wireshark. Das Programm kann so den Schlelaustausch mitverfolgen
und erhlt somit auch alle Schlssel, die ntig sind, um die Pakete zu dechirieren.
3.2.5 Aufbau einer gesicherten Verbindungen zwischen
OpenScape Voice Server und der HG 35xx
Bei diesem Verbindungsaufbau handelt es sich um ein Mutual TLS Handshake. Beide
Server authentisieren sich gegenseitig durch ein Zertikat. Die Besonderheit bei dem
Open Scape Voice Server liegt in seinen 4 SIPSM Schnittstellen. Die SIPSM 1/2 sind
fr die Authentisierung von Telefonen verantwortlich und zum Erkennen von Mutual
TLS Handshake Anfragen von Servern wie der HG 35xx. Nachdem sich die HG35xx
erst am SIPSM 1/2 angemeldet hat, ohne vorzeigen des Zertikates. Muss sie ber die
Schnittstelle SIPSM 3/4 eine erneute Anmeldung vornehmen diesmal mit Vorlage des
Zertikates. Dabei wechseln der OpenScape Voice Server und die HG 35xx jeweils ihre
Rolle und sind somit einmal Server bzw. Client. (siehe Abbildung 3.8)
In Abbildung 3.9 ist der gesamte Kommunikationsverlauf mittels Wireshark protokolliert.
(siehe schwarz-makierte Pakete) Als erstes erfolgt die anonyme Anmeldung der HG am
Open Scape Voice Server ber die Schnittstelle SIPSM 1/2. Darauf muss sich die HG 35xx
mit ihrem Zertikat an der Schnittstelle SIMSM 3/4 anmelden und verlangt auch vom
OpenScape Voice Server ein Zertikat. Bei Erfolg werden die Rollen getauscht und die
Anmeldung wiederholt. Wenn auch diese erfolgreich war, ist eine gesicherte Verbindung
aufgebaut worden.
3.3 Simuliertes Angrisszenario
In diesem Kapitel wird aufgezeigt, weshalb es so wichtig ist, sich Gedanken ber eine
Sicherung des Sprachverkehrs zu machen. Ich mchte an dieser Stelle sensibilisieren und
darstellen, wie einfach es geworden ist eine Man-in-the-middle Attacke auszufhren. Viele
sehen in der Absicherung des Datenverkehrs nur eine teure Investition, die keinen eektiven
Mehrwert bieten. Der Mehrwert lsst sich leider erst berechnen wenn ein erfolgreicher
Angri auf die Netzinfrastruktur statt gefunden hat und denn ist es meitens auch schon
zu spt! Eine gut geplante und kongurierte Securityrichtlinie verursacht Kosten, aber
diese Kosten stehen nicht in Relation zu den Schden, die ein Angreifer verursachen kann.
Somit gilt Vorsicht ist besser als Nachsicht!
54
D
a
s

T
e
l
e
f
o
n

s
c
h
i
c
k
t

e
i
n

C
l
i
e
n
t

H
e
l
l
o


a
n

d
e
n

O
p
e
n
S
c
a
p
e

V
o
i
c
e

S
e
r
v
e
r
.

D
i
e
s
e
r

s
c
h
i
c
k
t

d
a
r
a
u
f
h
i
n

e
i
n

S
e
r
v
e
r

H
e
l
l
o


u
n
d

s
e
i
n

Z
e
r
t
i
f
i
k
a
t

S
E
R
V
E
R

d
a
z
u
.

D
a
s

T
e
l
e
f
o
n

v
e
r
i
f
i
z
i
e
r
t

d
a
s

Z
e
r
t
i
f
i
k
a
t

S
E
R
V
E
R
,

d
a
s

m
i
t

d
e
m

p
r
i
v
a
t
e
n

S
c
h
l

s
s
e
l

d
e
r

R
O
O
T

C
A

s
i
g
n
i
e
r
t

w
u
r
d
e
,

m
i
t

H
i
l
f
e

d
e
s

z
u

V
e
r
f

g
u
n
g

s
t
e
h
e
n
d
e
n

f
f
e
n
t
l
i
c
h
e
n

S
c
h
l

s
s
e
l

d
e
s

S
t
a
m
m
z
e
r
t
i
f
i
k
a
t
e
s
.

N
a
c
h

e
r
f
o
l
g
r
e
i
c
h
e
r

V
e
r
i
f
i
z
i
e
r
u
n
g

w
i
r
d

e
i
n

P
R
E
M
A
S
T
E
R

S
E
C
R
E
T

m
i
t

d
e
m

f
f
e
n
t
l
i
c
h
e
n

S
c
h
l

s
s
e
l

d
e
s

S
e
r
v
e
r
s

v
e
r
s
c
h
l

s
s
e
l
t

u
n
d

b
e
r

C
l
i
e
n
t

K
e
y

E
x
c
h
a
n
g
e

b
e
r
t
r
a
g
u
n
g
.

D
e
r

N
a
c
h
f
o
l
g
e
n
d
e

D
a
t
e
n
v
e
r
k
e
h
r

w
i
r
d

m
i
t

s
y
m
m
e
t
r
i
s
c
h

v
e
r
s
c
h
l

s
s
e
l
t
.

D
i
e

T
L
S

V
e
r
b
i
n
d
u
n
g

i
s
t

p
e
r
s
i
s
t
e
n
t

,

h
e
i

t

d
e
r

H
a
n
d
s
h
a
k
e

w
i
r
d

n
i
c
h
t

p
e
r
i
o
d
i
s
c
h

a
u
s
g
e
f

h
r
t
.

E
r
s
t

b
e
i

e
i
n
e
m

N
e
u
s
t
a
r
t

d
e
r

G
e
r

t
e

g
e
s
c
h
i
e
h
t

d
i
e
s
.
C
l
i
e
n
t

H
e
l
l
o
S
e
r
v
e
r

H
e
l
l
o
S
e
r
v
e
r

C
e
r
t
i
f
i
c
a
t
e
S
e
r
v
e
r

H
e
l
l
o

D
o
n
e
C
l
i
e
n
t

K
e
y

E
x
c
h
a
n
g
e
F
i
n
i
s
h
e
d
F
i
n
i
s
h
e
d
Z
e
r
t
i
f
i
k
a
t

S
E
R
V
E
R
Z
e
r
t
i
f
i
z
i
e
r
u
n
g
s
s
t
e
l
l
e
n
-
S
t
a
m
m
z
e
r
t
i
f
i
k
a
t

R
O
O
T

C
A
D
a
s

T
e
l
e
f
o
n

s
c
h
i
c
k
t

e
i
n

C
l
i
e
n
t

H
e
l
l
o


a
n

d
e
n

O
p
e
n
S
c
a
p
e

V
o
i
c
e

S
e
r
v
e
r
.

D
i
e
s
e
r

s
c
h
i
c
k
t

d
a
r
a
u
f
h
i
n

e
i
n

S
e
r
v
e
r

H
e
l
l
o


u
n
d

s
e
i
n

Z
e
r
t
i
f
i
k
a
t

S
E
R
V
E
R

d
a
z
u
.

D
a
s

T
e
l
e
f
o
n

v
e
r
i
f
i
z
i
e
r
t

d
a
s

Z
e
r
t
i
f
i
k
a
t

S
E
R
V
E
R
,

d
a
s

m
i
t

d
e
m

p
r
i
v
a
t
e
n

S
c
h
l

s
s
e
l

d
e
r

R
O
O
T

C
A

s
i
g
n
i
e
r
t

w
u
r
d
e
,

m
i
t

H
i
l
f
e

d
e
s

z
u

V
e
r
f

g
u
n
g

s
t
e
h
e
n
d
e
n

f
f
e
n
t
l
i
c
h
e
n

S
c
h
l

s
s
e
l

d
e
s

S
t
a
m
m
z
e
r
t
i
f
i
k
a
t
e
s
.

N
a
c
h

e
r
f
o
l
g
r
e
i
c
h
e
r

V
e
r
i
f
i
z
i
e
r
u
n
g

w
i
r
d

e
i
n

P
R
E
M
A
S
T
E
R

S
E
C
R
E
T

m
i
t

d
e
m

f
f
e
n
t
l
i
c
h
e
n

S
c
h
l

s
s
e
l

d
e
s

S
e
r
v
e
r
s

v
e
r
s
c
h
l

s
s
e
l
t

u
n
d

b
e
r

C
l
i
e
n
t

K
e
y

E
x
c
h
a
n
g
e

b
e
r
t
r
a
g
u
n
g
.

D
e
r

N
a
c
h
f
o
l
g
e
n
d
e

D
a
t
e
n
v
e
r
k
e
h
r

w
i
r
d

s
y
m
m
e
t
r
i
s
c
h

v
e
r
s
c
h
l

s
s
e
l
t
.

D
i
e

T
L
S

V
e
r
b
i
n
d
u
n
g

i
s
t

p
e
r
s
i
s
t
e
n
t

,

h
e
i

t

d
e
r

H
a
n
d
s
h
a
k
e

w
i
r
d

n
i
c
h
t

p
e
r
i
o
d
i
s
c
h

a
u
s
g
e
f

h
r
t
.

E
r
s
t

b
e
i

e
i
n
e
m

N
e
u
s
t
a
r
t

d
e
r

G
e
r

t
e

g
e
s
c
h
i
e
h
t

d
i
e
s
.
C
l
i
e
n
t

H
e
l
l
o
S
e
r
v
e
r

H
e
l
l
o
S
e
r
v
e
r

C
e
r
t
i
f
i
c
a
t
e
S
e
r
v
e
r

H
e
l
l
o

D
o
n
e
C
l
i
e
n
t

K
e
y

E
x
c
h
a
n
g
e
F
i
n
i
s
h
e
d
F
i
n
i
s
h
e
d
Z
e
r
t
i
f
i
k
a
t

S
E
R
V
E
R
Z
e
r
t
i
f
i
z
i
e
r
u
n
g
s
s
t
e
l
l
e
n
-
S
t
a
m
m
z
e
r
t
i
f
i
k
a
t

R
O
O
T

C
A
Abbildung 3.6: TLS Handshake zwischen Telefon und Server
55
Abbildung 3.7: Wireshark Trace - TLS Handshake zwischen Server und Telefon
3.3.1 ARP-Spoong und ARP Cache Poisoning
Mit Hilfe des Programms Cain & Abel sind sogar Computernutzer mit geringem Kennt-
nisstand in der Lage ARP-Nachrichten zu spoofen und somit ein ARP Cache Poisoning
durchzufhren. In der Laborumgebung wollen 2 Teilnehmer mit einander telefonieren.
Der Angreifer konnte alle Sicherheitssperren bis zu dem Access-Switch durchbrechen.
Dies war auch ziemlich einfach weil die Access-Switche in der Etage nicht gegen Zutritt
gesichert wurden! (aktive Komponenten wie Switche mssen in verschlossen und zutritts-
gesicherten Rumen untergebracht werden!)
Der Angreifer sitzt also in einem hochsensiblen Bereich und schliet seinen Laptop mittels
RJ-45 Kabel an den Switch, an dem sich auch die beiden Kommunikationsteilnehmer
benden.
Der Angreifer kann nun mit dem ARP-Spoong beginnen. Zuvor muss aber noch geklrt
werden, was sich hinter dem Begri ARP verbirgt. Das Address Resolution Protocol
(ARP) dient zur Ermittlung der MAC-Adresse zu einer vorhanden IP-Adresse. Wenn ein
IP-Paket verschickt werden soll und die MAC-Adresse des Empfngers nicht bekannt ist,
wird ein Broadcast-Frame mit der Ziel Adresse )) )) )) )) )) ))
16
verschickt.
Jeder in der Broadcastdomne kann diesen Frame empfangen und schaut nach, ob es
sich um seine IP-Adresse handelt. Ist dies der Fall, antwortet der Empfnger dem Sender
und schickt seine MAC-Adresse und IP-Adresse. Der Sender speichert die Kombination
in seiner ARP-Tabelle (ARP-Cache).
Bei der Entwicklung von ARP haben sich die Verantwortlichen kaum Gedanken um eine
Absicherung der Anfragen und Antworten (ARP-Request und ARP-Reply) gemacht. Es
gibt keine Authentisierung, also kein Nachwei ber die Echtheit des Urhebers! Somit
kann jeder Teilnehmer die Eintrge in den ARP-Listen des anderen manipulieren, auch
wenn dieser die Eintrge gar nicht generiert hat. ARP arbeitet also stupide seine Befehle
ab ohne zu fragen wer den Request und den Reply geschickt hat.
Genau da liegt auch die Sicherheitslcke des Protokolls. Ein Angreifer kann ARP-Request
oder ARP-Replys selber erstellen (spoofen) und in das Zielnetz schicken. Die Methode
ist sehr simpel. Eine schematische Darstellung des Angris ist der Abbildung 3.10 zu
entnehmen.
56
M
u
t
u
a
l

T
L
S

H
a
n
d
s
h
a
k
e

H
8
K

<
-
>

H
G

3
5
x
x
C
l
i
e
n
t

H
e
l
l
o
S
e
r
v
e
r

H
e
l
l
o
S
e
r
v
e
r

C
e
r
t
i
f
i
c
a
t
e
S
e
r
v
e
r

H
e
l
l
o

D
o
n
e
C
l
i
e
n
t

K
e
y

E
x
c
h
a
n
g
e
F
i
n
i
s
h
e
d
F
i
n
i
s
h
e
d
C
l
i
e
n
t

H
e
l
l
o
S
e
r
v
e
r

H
e
l
l
o
C
e
r
t
i
f
i
c
a
t
e

(
C
L
I
E
N
T
)
C
e
r
t
i
f
i
c
a
t
e

(
C
L
I
E
N
T
)
F
i
n
i
s
h
e
d
Z
e
r
t
i
f
i
k
a
t

S
E
R
V
E
R
Z
e
r
t
i
f
i
k
a
t

C
L
I
E
N
T
Z
e
r
t
i
f
i
k
a
t

C
L
I
E
N
T
s
i
p
s
m

I
P
:

1
0
.
7
.
3
4
.
1
0
2
s
i
p
s
m

I
P
:

1
0
.
7
.
3
4
.
1
0
4
C
l
i
e
n
t

H
e
l
l
o
S
e
r
v
e
r

H
e
l
l
o
C
e
r
t
i
f
i
c
a
t
e

(
S
E
R
V
E
R
)
C
e
r
t
i
f
i
c
a
t
e

(
C
L
I
E
N
T
)
C
e
r
t
i
f
i
c
a
t
e

v
e
r
i
f
y
F
i
n
i
s
h
e
d
H
G

3
5
x
x
I
P
:

1
0
.
7
.
3
4
.
7
2
Abbildung 3.8: Schematische Darstellung zum Verbindungsaufbau Open Scape <-> HG
35xx
57
Abbildung 3.9: Mutual TLS Handshake zwischen OpenScape Voice Server und HG 35xx
58
Endgert A
Mac Adresse:
Siemens_2f:b4:dc
IP Adresse:
10.7.34.154
Angreifer
Mac Adresse:
Fujitsu_06:31:06
Endgert B
Mac Adresse:
Siemens_2f:c3:64
IP Adresse:
10.7.34.149
1. ARP-Request
2. senden des gespooften
ARP-Replys
10.7.34.149 is at
Fujitsu_06:31:06
1. ARP-Request
2. senden des gespooften
ARP-Replys
10.7.34.154 is at
Fujitsu_06:31:06
Regulrer Weg der Daten
Weg der Daten nach
dem Angriff
Abbildung 3.10: Schematische Darstellung des Angris
59
1. Der Angreifer schickt an Endgert A und an Endgert B jeweils ein ARP-Request
und fragt nach der passenden MAC-Adresse zu der gegebenen IP-Adresse (dabei
ist die Ziel-IP-Adresse, die des Opfers). Durch das Schicken eines Request bereitet
sich das Endgert auch auf das Eintragen eines neuen Eintrags in den Cache vor.
2. Der Angreifer schickt gleich zwei gespoofte ARP-Reply-Nachrichten an Endgert A
und an Endgert B. In der Nachricht wird die IP-Adresse von Endgert A und die
IP-Adresse von Endgert B mit der MAC-Adresse des Angreifers kombiniert und in
den Cache geschrieben. (Dieser Eintrag wird vom Angreifer immer wieder erneuert,
damit die falschen ARP-Eintrge nicht gelscht werden.) Dies bedeutet, dass jeder
Datenverkehr zwischen den IP-Adressen erst den Rechner des Angreifers durchluft.
Eigentlich mssten diese Pakete verloren gehen, wenn sie ber den Angreifer laufen
aber das Programm Cain & Abel bernimmt die Switchingaufgabe. So gehen keine
Pakete verloren und niemand merkt das jemand zwischen den beiden Endgerten
hngt.
In Abbildung 3.11 wurde der Angri mit Wireshark aufgezeichnet. Man kann an dem
Trace gut erkennen, wie die Endgerte erst mittels einem Request vorbereitet werden
(ARP-Frame 51 und 52) und anschlieend eine gespoofte Reply-Nachricht bekommen
(ARP-Frame 54 und 55). Im weiteren Trace (ab Paket 115) kann man sehen wie der
RTP-Stream ber den Angreifer luft. Bei genauerer Betrachtung des Paktes 115 kann
man im MAC-Header als Destination-Adresse die Adresse des Angreifers lesen, obwohl im
IP-Header noch die Ziel-IP-Adresse des Telefons steht. So ist es mglich ein ungesichertes
Telefongesprch mit aufzuzeichnen. Das Programm Cain & Abel schneidet den Stream
mit und speichert alles in einer Soundle, die nach dem Gesprch angehrt werden kann.
Es wrde aber auch das mitschneiden mit Wireshark gengen, da uns auch Wireshark aus
einem RTP-Stream ein Audiole erzeugt. Um dies zu vermeiden, sollte der Sprachverkehr
niemals in Klartext bertragen werden! Htten wir SRTP aktiviert, wrde der Angreifer
in seiner Soundle nur Rauschen hren. Damit die vergiftete Route bestehen bleibt sendet
der Angreifer kontinuierlich die gespooften ARP-Replys (ARP-Frame 93 und 94). Das
Intervall kann im Programm selber bestimmt werden.
60
Abbildung 3.11: Wireshark-Trace einer ARP-Spoong Attacke
61
Literaturverzeichnis
[All] Allen, Di erks: The TLS Protocol Version 1.0.
http://tools.ietf.org/html/rfc2246.
[Ark] Arkko, J.: MIKEY: Multimedia Internet KEYing.
http://www.ietf.org/rfc/rfc3830.txt.
[Bad06] Badach, Anatol: Voice Over IP- die Technik. Hanser Verlag, 2006.
[Bau] Baugher, M.: The Secure Real-time Transport Protocol (SRTP).
http://tools.ietf.org/html/rfc3711.
[Beu01] Beutelspacher, Albrecht: Moderne Verfahren der Kryptographie.
Vieweg Verlag, 2001.
[fSidI05] Informati onstechni k, BSI Bundesamt fr Si cherhei t
i n der: VoIPSEC - Studie zur Sicherheit von Voice over Internet Proto-
col. BSI, 2005.
[IT] ITU-T: ITU-Ts Denition of NGN. http://www.itu.int/ITU-
T/ngn/denition.html.
[Kle01] Klei n, Tobi as: Linux-Sicherheit: Security mit Open-Source-Software
Grundlagen und Praxis. dpunkt-Verlag, 2001.
[Kom] Kompendi um, Elektroni k: NGN - Next Generation Network.
http://www.elektronik-kompendium.de/sites/kom/1103261.htm.
[LH] Laurent Haan, StarShaper: Advanced Encryption Standard
(AES). http://www.codeplanet.eu/tutorials/cpp/51-advanced-encryption-
standard.html.
[Wika] Wi ki pedi a: Advanced Encryption Standard.
http://de.wikipedia.org/wiki/AdvancedEncryptionStandard.
62
[Wikb] Wi ki pedi a: Next Generation Network. http://de.wikipedia.org/wiki/Next-
Generation-Network.
[Wikc] Wi ki pedi a: RSA-Kryptosystem. http://de.wikipedia.org/wiki/RSA-
Kryptosystem.
[Wikd] Wi ki pedi a: Secure Hash Algorithm. http://de.wikipedia.org/wiki/Sha1.
[Wt08] Wtjen, Di etmar: Kryptographie - Grundlagen, Algorithmen, Protokolle.
Spektrum Akademischer Verlag, 2008.
63
Abbildungsverzeichnis
2.1 Schematische Darstellung der symmetrischen Verschlsselung . . . . . . . 12
2.2 Schematische Darstellung der asymmetrischen Verschlsselung . . . . . . 13
2.3 Schematische Darstellung der digitalen Unterschrift . . . . . . . . . . . . 14
2.4 Schematischer Aufbau eines X.509 Zertikates . . . . . . . . . . . . . . . 15
2.5 Darstellung einer Zertikatsherachie . . . . . . . . . . . . . . . . . . . . . 16
2.6 Schematische Darstellung der Hashwertbildung . . . . . . . . . . . . . . . 17
2.7 TLS im OSI-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 gesamter Verlauf eines TLS-Handshakes . . . . . . . . . . . . . . . . . . 23
2.9 Server anonym - Client anonym . . . . . . . . . . . . . . . . . . . . . . . 25
2.10 Server mit Authentizierung - Client anonym . . . . . . . . . . . . . . . 26
2.11 Server mit Authentizierung - Client mit Authentizierung . . . . . . . . 27
2.12 Darstellung des SRTP-Headers . . . . . . . . . . . . . . . . . . . . . . . . 28
2.13 AES Block mit 128 Bit (1 Block = 1 Byte) . . . . . . . . . . . . . . . . . 30
2.14 Fludiagramm von der Funktionsweise des AES-Algorithmus . . . . . . . 31
2.15 Darstellung der ShiftRow() Funktion . . . . . . . . . . . . . . . . . . . . 32
2.16 Schematische Darstellung des Di-Hellman Schlsselaustausches . . . . . 35
2.17 Messageaustausch von MiKey . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1 Netzplan der Laborumgebung (logisch) . . . . . . . . . . . . . . . . . . . 45
3.2 Zertikatsstruktur fr die Laborumgebung . . . . . . . . . . . . . . . . . 46
3.3 Das Skript genCertReq.sh . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4 Das Skript conCert.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5 Zertikatsverteilung an die Komponenten . . . . . . . . . . . . . . . . . . 53
3.6 TLS Handshake zwischen Telefon und Server . . . . . . . . . . . . . . . . 55
3.7 Wireshark Trace - TLS Handshake zwischen Server und Telefon . . . . . 56
3.8 Schematische Darstellung zum Verbindungsaufbau Open Scape <-> HG
35xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.9 Mutual TLS Handshake zwischen OpenScape Voice Server und HG 35xx 58
3.10 Schematische Darstellung des Angris . . . . . . . . . . . . . . . . . . . . 59
3.11 Wireshark-Trace einer ARP-Spoong Attacke . . . . . . . . . . . . . . . 61
64