Bewertung und Beschreibung des...

Fachhochschule Gießen-FriedbergFachbereich Mathematik, Naturwissenschaften, Datenverarbeitung

Prof. Dr. Hartmut SiebertProf. Dr. Stefan Euler

Bewertung und Beschreibung des MIKEY-Protokolls

Sichere Internet-Telefonie vor dem Durchbruch ?

Eingereicht von:Sven WeibergObere Liebfrauenstr. 1461169 [email protected]

Studiengang: MathematikFachrichtung: Angewandte InformatikMatrikel-Nr: 666622

Inhaltsverzeichnis1 Einführung........................................................................................................................................................3

1.1 Umbruch in der Echtzeitkommunikation.................................................................................................31.2 Neue Herausforderungen: Dienstegüte und Sicherheit............................................................................3

2 Protokolle und Standards................................................................................................................................. 52.1 Der Standard RTP.................................................................................................................................... 62.2 Der SRTP-Standard................................................................................................................................. 7

2.2.1 Ablauf der Sicherung....................................................................................................................... 82.3 Das Protokoll MIKEY............................................................................................................................. 9

2.3.1 Ablauf der MIKEY-Kommunikation.............................................................................................103 Kryptographische Standards.......................................................................................................................... 13

3.1 Das AES-Verfahren............................................................................................................................... 133.1.1 Arbeitsweise des Verfahrens......................................................................................................... 143.1.2 Sicherheit von AES........................................................................................................................15

3.2 Das HMAC-SHA1-Verfahren............................................................................................................... 153.2.1 Beschreibung................................................................................................................................. 153.2.2 Sicherheit....................................................................................................................................... 16

3.3 Die Public-Key Verschlüsselung nach RSA..........................................................................................163.3.1 Beschreibung................................................................................................................................. 163.3.2 Funktionsweise.............................................................................................................................. 173.3.3 Sicherheit....................................................................................................................................... 17

3.4 Signaturen nach RSA.............................................................................................................................183.4.1 Beschreibung................................................................................................................................. 183.4.2 Sicherheit....................................................................................................................................... 18

4 Die C++ Bibliothek........................................................................................................................................194.1 Allgemeines........................................................................................................................................... 19

4.1.1 Unterstützte Aufgaben................................................................................................................... 194.1.2 Dokumentation...............................................................................................................................20

4.2 Entstehungsprozeß................................................................................................................................. 204.2.1 Motivation......................................................................................................................................204.2.2 Wahl der Programmiersprache...................................................................................................... 204.2.3 Entwicklung eines Klassenmodells............................................................................................... 204.2.4 Verwendung von Hilfsmitteln....................................................................................................... 214.2.5 Schwierigkeiten bei der Entwicklung............................................................................................ 214.2.6 Erstellung der Dokumentation....................................................................................................... 224.2.7 Ausblick......................................................................................................................................... 224.2.8 Das Testprogramm.........................................................................................................................22

4.3 Einsatzmöglichkeiten der MIKEY-Bibliothek...................................................................................... 224.3.1 Softphone....................................................................................................................................... 224.3.2 Sicherheits-Proxy...........................................................................................................................23

4.4 Verwendung vorhandener PGP-Schlüssel im Rahmen von MIKEY.................................................... 235 Weitere Entwicklung der IP-basierten Mediendienste...................................................................................24

5.1 Technischer Vergleich........................................................................................................................... 245.2 Bisherige Verbreitung............................................................................................................................245.3 Ausblick................................................................................................................................................. 25

5.3.1 Privatanwender.............................................................................................................................. 255.3.2 Nutzung bei Firmen/Institutionen..................................................................................................255.3.3 Spit................................................................................................................................................. 26

Weiberg: Bewertung und Beschreibung des MIKEY-Protokolls Seite 2

Einführung

1 Einführung

1.1 Umbruch in der EchtzeitkommunikationDie Entwicklung die Anfang der 90er Jahre des letzten Jahrhunderst mit der Etablierung des Internet begann 1 hat weitreichende Folgen, sowohl für die Gesellschaft, als auch im technischen Bereich. Ein durch diese Entwicklung bedingter Wandel betrifft einen wesentlich älteren Bereich der Fernkommunikation: Die Telefonie. Im Rahmen immer breiter verfügbarer Rechnernetze und schneller, multimediafähiger Rechner gewinnt das Thema VoIP2 (Voice over Internet Protocol), also die Abwicklung von Sprach sowie (mittel- und langfristig) Videotelefonaten über IP-Netze zunehmend an Relevanz. Technisch bedeutet dies einen radikalen Wechsel von der seit 150 Jahren praktizierten schaltungsorientierten Verbindungserstellung hin zur Übertragung von Daten über ein öffentliches (Internet) bzw. teilöffentliches (Intranet) Netzwerk3. Bisher basierte sie auf dem Prinzip der Umwandlung eines akustischen Signals in ein elektrisches und wieder zurück, wobei man diese Umwandlung analog durchführte. Zur Realisierung wurde dabei eine direkte Leitungsverbindung zwischen den teilnehmenden Gesprächspartnern hergestellt. Beispielhaft seien hierfür Szenen aus alten amerikanischen Filmen genannt in denen die „Damen vom Amt“ noch wirklich Leitungen von Hand stöpselten4,5.

Die nächste Entwicklungsstufe stellte 1989 die Verabschiedung des ISDN (Integriertes Sprach- und Datennetz, neuerdings: Integrated Services Digital Network) dar6. Dort wurde die Kommunikation nicht analog, sondern digital umgewandelt, was eine Erhöhung der Leitungskapazität und Sprachqualität sowie die Möglichkeit zusätzlicher Komfortfunktionen wie Konferenzgespräche, Makeln, Rufnummernübermittlung etc. bedeutete.

Parallel dazu entwickelte sich in den letzen 10 Jahren das Internet rasant. Technische Basis des Internet ist eine Reihe von Protokollen und Standards die Datenübertragung über verteilte Netze ermöglichen7. Obwohl das wichtigste Protocol des Internets, das ebnso genannte Internet Protocol (IP) nicht auf Echtzeitkommunikation ausgelegt ist wird es seit wenigen Jahren auch für Telefoniedienste verwendet.

1.2 Neue Herausforderungen: Dienstegüte und SicherheitDen bei Nutzung von IP-Telefonie enstehenden Vorteilen wie größerer Benuzterkomfort, Ortsunabhängigkeit und den Kostenvorteilen vor allem durch Wegfall eines zweiten physischen Netzes stehen auch Nachteile gegenüber.Eine der großen zentralen Herausforderungen stellt dabei die Sicherung der Verbindung überhaupt dar. Das Internet Protocol8 garantiert weder eine gewisse Bandbreite zwischen zwei Teilnehmern, noch eine Zeit innerhalb derer Daten von einem zum anderem Punkt übertragen werden. Beides kann, z.B. im Falle eines starken Anstiegs der Netzauslastung, deutlich variieren. Um diese Probleme zu reduzieren bzw. zu beseitigen sind Erweiterungen der Netzinfrastruktur erforderlich, z.B. QoS-fähige Router. QoS (Quality of Service, Dienstegüte) bezeichnet dabei die Fähigkeit, Datenpakete abhängig von ihrem Datentyp unterschiedlich zu behandeln. So können z.B. Datenpakete mit Telefonie-Daten gegenüber "normalen" Datenpaketen priorisiert behandelt werden, so daß diese schneller an Ihrem Ziel ankommen9. Im Rahmen eines Intranets, z.B. eines

1 Zur Entwicklung des Internet siehe z.B. [Gesch1]2 VoIP wird auch unter mit den Begriffen IP-Telefonie oder Internettelefonie beschrieben. Für einen Überblick siehe

z.B. [VoIP1]3 Siehe hierzu auch [Badach1], Kapitel 14 Zu sehen z.B. unter http://www.zdnet.de/glossar/image.htm?image=cb99f10 (Stand 14.08.2006)5 Zur Geschichte des analogen Telefons siehe [Analog1]6 Siehe [ISDN1]7 Siehe [Internet1], [Internet2]8 Siehe [IP1], [RFC791], [RFC2460]9 Siehe hierzu auch [Badach1], Kapitel 4


http://www.zdnet.de/glossar/image.htm?image=cb99f10

Einführung

Firmennetzwerkes ist der Aufbau einer QoS-fähigen Infrastruktur durch Austausch der Komponenten möglich. Im Rahmen des Internets gibt es keine solche QoS-Infrastruktur.

Neben dem Problem der zeitnahen Übertragung der Telefoniedaten stellen sich auch ganz neue Herausforderungen in Bezug auf Sicherheitsaspekte. Gegenwärtig wird der größte Teil der über ein IP-Netz laufenden Sprachkommunikation unverschlüsselt und unauthentifiziert abgewickelt. Dies öffnet umfangreiche Mißbrauchsmöglichkeiten zu deren technischen Durchführung ein durchschnittliches IT-Wissen und etwas Einarbeitung in die Thematik genügen10. Sei es nun der geprellte Mitarbeiter, der mal eben alle Telefonate der Geschäftsführung mitschneidet oder ein autonom arbeitendes Programm im Internet, das beipielsweise den Telefonverkehr einer Krankenkasse aufzeichnet, automatisiert auswertet und meistbietend an Interessierte wie z.B. Versicherungsgesellschaften versteigert, das Interesse an einer Kompromittierung des Telefonverkehrs ist zweifelsohne vorhanden.

Vor diesem Hintergrund wurden in letzter Zeit von dem zuständigen Standardisierungsgremium, im hier vorliegenden Falle der IETF (Internet Engineering Task Force)11 Protokolle und Standards verabschiedet, die eine gesicherte Kommunikation über öffentliche Netze ermöglichen sollen.

10 Eine Beschreibung eines Angriffs findet sich z.B. unter [IX502] oder [PCProf1105]11 "Die Internet Engineering Task Force ist neben der Internet Research Task Force (IRTF) eine von zwei

Arbeitsgruppen des Internet Architecture Board (IAB). Ihr Auftrag ist die Entwicklung und Förderung von Internetstandards, insbesondere die der TCP/IP-Familie. Im Gegensatz zur IRTF kümmert sie sich mehr um die kurzfristige Entwicklung des Internets."(Wikipedia, 15.08.2006) Die IETF ist Herausgeberin der RFC(Request for Comment) Dokumente, die die im Internet benutzen Protokolle und Standards beschreiben. Weitere Infos unter http://www.ietf.org/.


http://de.wikipedia.org/wiki/Internet

http://de.wikipedia.org/wiki/Internetprotokollfamilie

http://de.wikipedia.org/wiki/Internetstandard

http://de.wikipedia.org/wiki/Internet_Architecture_Board

http://de.wikipedia.org/wiki/Arbeitsgruppe

http://de.wikipedia.org/wiki/Internet_Research_Task_Force

Protokolle und Standards

2 Protokolle und StandardsBei der Herstellung einer Medienverbindung zur Sprach- und/oder Videotelefonie sind zwei grundsätzlich verschiedene Protokollebenen zu unterscheiden. Die sog. Signalisierungssteuerung auf der einen Ebene und die eigentliche Medienübertragung auf der anderen Ebene. Die Aufgabe der Signalisierungssteuerung ist es, einen Verbindungsaufbau zwischen den Gesprächswilligen zu initiieren. Dazu gehört die Ermittlung der aktuellen Verbindungsdaten (IP-Adresse, etc), die Aushandlung des zu verwendenden Mediencodecs sowie die Steuerung von Komfortfunktionen wie Konferenzgespräche. Hierzu existieren zur Zeit zwei konkurrierende Standards, nämlich das binäre H.323 Rahmenwerk mit den Protokollen H.225 und H.24512 sowie das an HTTP angelehnte SIP (Session Initialization Protocol)13. Gegenwärtig scheint sich zweiteres immer weiter durchzusetzen. Diese Diplomarbeit wird sich daher fast ausschließlich auf SIP als Signalisierungsprotokoll beziehen.

Zur eigentlichen Medienübertragung wird durchgängig das RTP (Real-Time-Transport Protocol)14 verwendet. Im März 2004 verabschiedete die IETF das SRTP (Secure RTP) Protokoll15, ein Profil des RTP-Protokolls. Mittels SRTP ist es möglich Mediendaten verschlüsselt und authentifiziert zu übertragen. SRTP

12 Für weitere Informationen zu H.323 siehe [H323] sowie [Badach1], Kapitel 6.13 Für weitere Informationen zu SIP siehe [SIP1], [RFC3261] sowie die Erweiterungen in den RFC 3262-326514 Siehe [RFC3550]15 Siehe [RFC3711]


Abbildung 1: Protokollebenen bei der VoIP Kommunikation


baut auf dem bekannten AES (Advanced Encryption Standard)16 auf. SRTP alleine erfüllt jedoch noch nicht alle Anforderungen, die nötig sind um eine gesicherte Medienverbindung aufzubauen. Es fehlt noch ein Protokoll, das den Austausch und die Verwaltung der verwendeten Schlüssel regelt. Hierzu wurde im August 2004 das Protokoll MIKEY (Multimedia Internet KEYing)17 verabschiedet. Dieses Protokoll legt fest, welche Schlüssel für die Kommunikation mittels SRTP zu verwenden sind.

2.1 Der Standard RTPDas Protokoll RTP wird zur Übertragung von Mediendaten (Audio- und Videodaten) in IP-Netzen verwendet. Es ist auf der Anwendungsschicht im TCP/IP-Referenzmodell18 angesiedelt (vergleichbar mit OSI-Schicht19 5-7) und verwendet i.d.R. das verbindungslose UDP20 Protokoll in der Transportschicht (vergleichbar mit OSI-Schicht 4) zur Kommunikation. Es wurde erstmal 1996 im RFC 1889 spezifiziert und 2003 überarbeitet. Seitdem ist das Kernprotokoll im RFC 3550 und einige Erweiterungen in den RFC 3551 bis 3555 zu finden.

Ziel des RTP-Protokolls ist es, eine möglichst kontinuierliche und zeitnahme Übertragung der Daten zu gewährleisten. Es ist möglich mehrere Medienströme, z.B. einen für Sprache und einen für Video, gleichzeitig zu übertragen. Zur Identifizierung wird daher jeder RTP-Medienstrom mit einem sog. SSRC (Synchronisation Source Identifier) versehen. Zu den Aufgaben die mittels RTP erfüllt werden zählen:• Übermittlung von Echtzeitmedien in RTP-Paketen

Die Medienströme werden durcht RTP als eine zusammenhängende Folge von RTP-Paketen in einer RTP-Sitzung übertragen.

• Garantie der Reihenfolge von RTP-Paketen Die übertragenen Pakete werden nummierert, so daß ihre ursprüngliche Reihenfolge beim Empfänger wiederhergestellt werden kann. Dies ist nötig da es bei der Übertragung mittels UDP/IP vorkommt, daß Pakete in einer anderen Reihenfolge beim Empfänger ankommen, als Sie beim Sender versendet wurden.

• Garantie der Isochronität Die übertragenen Pakete werden mit einem Zeitstempel versehen, so daß die Zeitabstände zwischen den Paketen am Ziel wiederhergestellt werden können.

• Transport unterschiedlicher Formate

16 AES ist ein weit verbreiteter und moderner Standard für symmetrische Verschlüsselung. Siehe [FIPS197] , [Wobst1], Kapitel 5.5 sowie [AES1]

17 Siehe [RFC3830]18 Siehe [RFC1122]19 Siehe [OSI1]20 Siehe [RFC768]


Abbildung 2: Einordnung von RTP im TCP/IP Schichtenmodell


RTP eignet sich zur Übertragung unterschiedlicher Formate von Sprache, Audio und Video, die durch sog. Profiles bestimmt sind. Diese Profiles finden sich in RFC 3551.

• Einsatz von Translator und Mixer RTP ermöglicht den Einsatz von sog. Translatoren und Mixern. Ein Translator übersetzte Medien aus einem Medienformat in ein anderes, ein Mixer führt mehrere Medienströme zu einem zusammen (z.B. Mehrere Sprachströme zu einem im Rahmen von Konferenzschaltungen).

(vlg. [Badach1], S.153f)RTP stellt nicht sicher, daß alle Pakete vom Sender zum Empfänger übertragen werden. Der Ausfall

einzelner Pakete muß daher beim Empfänger in der Medienapplikation entsprechend verarbeitet werden.Das Protokoll RTP wird stets zusammen mit dem Protokoll RTCP (RealTime Control Protocol)

verwendet. RTCP ist ebenso wie RTP im RFC 3550 spezifiziert. Für jede RTP-Sitzung werden mittels RTCP in regelmäßigen Abständen Statusinformationen übertragen. Die wichtigsten Aufgaben von RTCP sind:• Überwachung der Übertragunsqualität

Hierfür werden zwischen Sender und Empfänger laufend Informationen über die Übertragungsqualität wie z.B. Laufzeitunterschiede, Paketverlustrate etc ausgetauscht. Dies ermöglicht dem Sender z.B. bei Verschlechterung der Übertragungsqualität auf einen Mediencodec mit niedrigerer Bandbreite umzuschalten, sofern dies unterstützt wird.

• Identifikation der Quelle RTCP ermöglicht eine eindeutige Bezeichnung, einen sog. kanonischen Namen (CNAME) zu übertragen. Dieser ermöglicht eine Identifikation einer Medienquelle, auch wenn deren SSRC durch den Einsatz eines Mixers oder Translators geändert wurde oder mehrere SSRC in einer Quelle zusammengefaßt werden (z.B. Sprache und Video)

• Unterstützung der Mehrpunkt-Kommunikation In Szenarien mit mehreren Kommunikationspartnern kann RTCP dazu verwendet Statusinformationen auszutauschen. Dies ermöglicht z.B. im Rahmen von Konferenzgesprächen über zugehende und abgehende Teilnehmer des Konferenzgesprächs zu berichten.

(vgl. [Badach1], S. 159)Die RTP-Spezifikation umfasst jedoch weder Vorgehensweisen für den Verbindungsaufbau zwischen

Kommunikationspartnern noch zur Aushandlung der Sitzungsparameter wie z.B. der verwendeten Mediencodecs. Hierzu sind andere Protokolle wie z.B. SIP (Verbindungsaufbau) und SDP21 (Sitzungsparameter) zu verwenden.

2.2 Der SRTP-StandardDas oben beschriebene RTP-Protokoll ermöglicht jedem Netzwerkteilnehmer dem es gelingt, die Netzwerkdaten abzufangen ein Mitschneiden oder Verändern der Daten. Dies kann in einigen Situationen unerwünscht sein. Daher wurde mit dem Secure RTP-Standard ein Profil von RTP entwickelt, das eine geschützte und sichere Kommunikation auch über ein offenes Netz ermöglicht. SRTP wurde im März 2004 verabschiedet und ist im RFC 371122 beschrieben. Ebenso wie beim Protokollpaar RTP/RTCP gibt es ein Protokoll SRTCP, welches dem gesicherten Austausch von Statusinformationen dient und ebenfalls in RFC 3711 beschrieben ist. SRTCP funktioniert genauso wie SRTP, so daß hier auf eine weitere Beschreibung verzichtet wird. Mit SRTP lassen sich folgende zentrale Sicherheitsfunktionen realisieren:• Vertraulichkeit durch Verschlüsselung

21 Session Descripton Protocol. Siehe [RFC2327]22 Siehe [RFC3711]



Die Datenpakete werden bei SRTP vor dem Versenden verschlüsselt. Dadurch kann ihr Inhalt nicht von anderen "abgehört" werden

• Authentifizierung des Absenders Da sich die IP-Adresse eines Absenders relativ leicht fälschen läßt besteht Bedarf an einer Authentifizierung des Absenders. SRTP bietet die Möglichkeit mittels des MAC (Message Authentication Code) sicherzustellen, daß das Paket auch wirklich vom erwarteten Absender stammt.

• Überprüfung der Integrität Angreifer, die sich in den Datenverkehr zwischen Sender und Empfänger "einklinken" können RTP-Pakete verändern ohne daß dies bemerkt wird. Um dies zu verhindern kann mit SRTP sichergestellt werden daß der Inhalt der Pakete auf dem Weg zwischen Sender und Empfänger nicht verändert wird. Auch dies geschieht mittels des MAC.

• Anti-Replay-Schutz Bei einer sog. Replay Attacke werden mitgeschnittene Datenpakete vom Angreifer nochmals an einen Empfänger verschickt. Dies kann z.B. bei Videodaten die von einer Überwachungskamera kommen sehr unangenehme Auswirkungen haben. SRTP verfügt daher über Mechanismen eine solche Attacke zu verhindern.

(vgl. [Badach1], S. 169f)Damit eine gesicherte Kommunikation mittels SRTP erfolgen kann, müssen sich die

Kommunikationspartner vorher auf ein paar grundlegende Parameter sowie einen gemeinsamen Schlüssel einigen. Hierzu wird ein sog. Key Management Protocol (KMP) benötigt. Ein bekanntes Protokoll dieser Kategorie ist IKE23 (Internet Key Exchange) das z.B. bei IPSec verwendet wird. Da IKE jedoch nicht den Anforderungen an multimediale Echtzeikommunikation gerecht wird, wurde ein weiteres Protokoll entwickelt: Das MIKEY-Protokoll (s.u.).

SRTP verfügt über Mechanismen mit denen der zur Kommunikation und Authentifizierung verwendete Schlüssel von einem für die Sitzung geltenden sog. SRTP Master Key auf kryptographisch sichere Weise abgeleitet wird. Der abgeleitete und verwendete Schlüssel wird dabei als Session Key bezeichnet. Diese Ableitung dieses Schlüssels kann im Rahmen einer Sitzung gemäß einer vorher ausgehandelten Häufigkeit öfter erfolgen, so daß ein potenzieller Angreifer nie über größere Mengen an verschlüsselten Daten verfügt, die mit dem selben Schlüssel berechnet wurden.

2.2.1 Ablauf der SicherungDie Sicherung eines Paketes mit SRTP/SRTCP erfolgt folgendermaßen:

1. Zunächst werden die Nutzdaten (der sog. Payload) des RTP Paketes verschlüsselt. Dabei wird der für das Paket gültige Session Key verwendet. Das Verfahren für die Verschlüsselung ist AES (Advanced Encryption Standard) mit einer Schlüssellänge von i.d.R. 128 Bits. Der Header des RTP- Paketes bleibt unverschlüsselt.

2. Anschließend werden über die (verschlüsselten) Nutzdaten und den Header ein sog. MAC (Message Authentication Code)24 gebildet. Dabei wird ein spezieller Hash-Wert25 gebildet in den der Session Key mit einfließt. Der so errechnete Wert wird an das Paket angefügt. Das Verfahren für die

23 Siehe [RFC2409]24 Siehe [MAC1]25 Ein Hash-Wert ist das Ergebnis einer Hash-Funktion. Eine solche Funktion erhält einen beliebigen Wert/Datenstrom

als Eingabe und liefert einen Wert einer bestimmten Länge zurück. Bei kryptographischen Hash-Funktionen ist es wichtig daß aus dem Ergebnis der Hash-Funktion keinerlei Rückschlüsse auf den Eingabewert gezogen werden können.



Ermittlung des Hash-Wertes ist HMAC-SHA126. Wichtig ist hierbei die Einbeziehung des Headers, so daß eine Veränderung von Daten im Header während der Übertragung ausgeschlossen ist.

3. Der Empfänger des Paketes schneidet den MAC vom Paket ab und berechnet ihn aufgrund der empfangen Daten auf dieselbe Weise wie der Sender. Er vergleicht seinen so errechneten MAC mit dem Empfangenen. Sind beide gleich, so ist sichergestellt daß das Paket nicht verändert wurde und vom angenommen Absender stammt. Anschließend entschlüsselt er die Nutzdaten des Paketes.

2.3 Das Protokoll MIKEYDas Protkoll MIKEY (Multimedia Internet KEYing) dient der Etablierung eines gemeinsamen Schlüssels sowie der Sicherheitsparameter für die gesicherte Kommunikation mit SRTP. Es ist auf der Anwendungsschicht im TCP/IP-Referenzmodell27 angesiedelt und wurde im August 2004 von der IETF verabschiedet. Die Spezifikation findet sich im RFC 3830.Zu den Zielen und Aufgaben von MIKEY zählen vor allem:• Eignung für multimediale Echtzeitkommunikation

MIKEY soll dazu geeignet sein die Etablierung gemeinsamer Parameter mit möglichst wenig und möglichst kurzen Nachrichten zu erreichen. In den allermeisten Fällen beschränkt sich die Kommunikation die durch MIKEY verursacht wird auf eine Nachricht vom Sender an den Empfänger sowie evtl. eine Verifizierungsnachricht vom Empfänger an den Sender.

• Sichere Etablierung eines gemeinsamen Schlüssels MIKEY ermöglicht die Etablierung gemeinsamer Schlüssel über unsichere Kanäle. Alle sensiblen Informationen werden daher verschlüsselt übertragen und es findet eine Authentitäts- sowie Integritätsprüfung der Daten statt. Die verwendeten Verfahren sind dabei wie bei SRTP AES und HMAC-SHA1. Auf diese Weise kann in Zusammenarbeit mit einem geeigneten Transferprotokoll eine abgesicherte Kommunikation über einen offenen Kanal wie z.B. das Internet stattfinden.

• Unterstützung mehrerer Einsatzszenarien MIKEY ist so konzipiert, daß es sowohl bei der Kommunikation zwischen zwei Partnern als auch in kleinen Gruppen (z.B. bei Telefon-/Videokonferenzen) eingesetzt werden kann. Desweiteren unterstützt MIKEY drei verschiedene Methoden zur Verschlüsselung seiner Nachrichten: mittels eines geheimen Schlüssel über den die Kommunikationspartner verfügen, mittels eines öffentlichen Schlüssels sowie mittels einer Diffie-Hellman Schlüsselvereinbarung (s.u.).

• Erweiterbarkeit Momentan (August 2006) ist MIKEY nur für die Vereinbarung eines Schlüssels und der Sicherheitsparameter für das SRTP Protokoll spezifiziert. Der Standard ist jedoch offen gehalten und kann bei Bedarf auch für andere Protokolle erweitert werden.

26 Siehe [HMAC1] sowie [RFC2104] und [RFC2201]27 Siehe [RFC1122]


Abbildung 3: Verschlüsselung und Authentifizierung bei SRTP


Mikey verfügt ähnlich wie SRTP über eine Methode zur Ableitung von Schlüsseln. So ist es möglich einen gemeinsamen Hauptschlüssel (den sog. TGK28) zu etablieren und aus diesem mehrere Schlüssel, z.B. jeweils für Audio- und Video-Datenströme, zu generieren (die sog. TEK). Auch ist dies sinnvoll bei Transferprotokollen die nicht über einen automatischen Mechanismus zur Schlüsselerneuerung verfügen.

Welche Methode oder welches Protokoll zum Versenden der MIKEY-Nachrichten verwendet wird ist bewußt offen gehalten. Diese Flexibilität ermöglicht es z.B. die Nachrichten in ein Signalisierungsprotokoll wie SIP zu "verpacken" und so den Zusatzaufwand für MIKEY gering zu halten.

2.3.1 Ablauf der MIKEY-KommunikationDie Ermittlung der gemeinsamen Hauptschlüssel gestaltet sich bei MIKEY je nach Einsatzszenario etwas unterschiedlich. Im Folgenden soll eine solche Vereinbarung für jedes Szenario beispielhaft beschrieben werden.Mit geheimem SchlüsselIn diesem Falle wird davon ausgegangen, daß die Kommunikationspartner über einen geheimen Schlüssel verfügen den Sie vorher z.B. über einen sicheren Kanal ausgetauscht haben. Aus diesem geheimen Schlüssel, einer in der Spezifikation bestimmten Konstante sowie einem Zufallswert wird ein weiterer Schlüssel gebildet, der sog. Encryption Key. Nun erzeugt der Initiator (I) einen oder mehrere zufällige TGKs/TEKs. Diese werden mittels des Encryption Key per AES verschlüsselt und zusammen mit dem Zufallswert an den Empfänger (R) übertragen.

Der Schlüssel für die Authentifizierung und Integritätssicherung (Authentication Key) wird ebenfalls aus dem geheimen Schlüssel ermittelt. Das dabei verwendete Verfahren ist dasselbe wie zur Ermittlung des Encryption Key, lediglich unter Verwendung einer anderen Konstante.

Der Empfänger bildet aus dem ihm ebenfalls bekannten geheimen Schlüssel und dem empfangenen Zufallswert den Enryption Key sowie den Authentication Key und verwendet diese zur Entschlüsselung und Prüfung der TGKs. Anschließend verfügen beide Partner über gemeinsame Schlüssel (TGKs) für die Kommunikation.

Dieses etwas kompliziert erscheinende Verfahren wird angewandt damit für Verschlüsselung und Authentifizierung unterschiedliche Schlüssel verwandt werden. Die Aufgabe des Zufallswertes ist es dabei, Replay-Attacken zu verhindern.

28 TGK steht für TEK Generation Key. TEK steht für Traffic Encryption Key. Der TEK ist der Schlüssel der an das Transferprotokoll übergeben wird. Bei SRTP dient der TEK als SRTP Master Key.


Abbildung 4: Verschlüsselung der TGKs in MIKEY


Mit öffentlichem SchlüsselBei Verwendung eines öffentlichen Schlüssel erzeugt der Initiator (I) der Nachricht einen zufälligen Schlüssel, den er mit dem öffentlichem Schlüssel des Empfängers nach dem RSA-Verfahren verschlüsselt, den sog. Envelope Key. Dieser Envelope Key erfüllt anschließend die Funktion des "geheimen Schlüssels". Das Vorgehen ist nun ähnlich wie bei Existenz eines geheimen Schlüssels. Der Initiator erzeugt einen oder mehrere TGKs, verschlüsselt diese mit Hilfe des Encryption Key und sendet den verschlüsselten Envelope Key, seinen öffentlichen Schlüssel, sowie die zufällig erzeugten TGKs/TEKs an den Empfänger. Zur Sicherung der Authentizität und Integrität wird die Nachricht mit Hilfe des geheimen Signaturschlüssels von I signiert29.

Der Empfänger entschlüsselt den Envelope Key mit Hilfe des geheimen Teils seines öffentlichen Schlüssels und bildet aus Ihm den Encryption Key. Dieser wird dann zur Entschlüsselung der TGKs verwendet. Die angehängte Signatur prüft R mit dem öffentlichen Teil des Signaturschlüssels von I.

Mit Diffie-Hellman SchlüsselvereinbarungDie Diffie-Hellman Schlüsselvereinbarung ist nur zwischen zwei Kommunikationspartnern möglich. Hierbei wird der Encryption Key nicht übertragen sondern nach einem mathematischen Verfahren ermittelt. Ein Vorteil dieser Schlüsselvereinbarung ist, daß sie nicht im Nachhinein kompromittiert werden kann. Die beiden oben beschriebenen Verfahren hängen jeweils davon ab daß Informationen über die mindestens ein Kommunikationspartner verfügt geheim gehalten werden müßen. Gelangt ein Angreifer an diese Informationen, so kann er z.B. aufgezeichnete Nachrichten entschlüsseln und die Vertraulichkeit ist nicht

29 Eine Signatur bildet aus einer Nachricht und dem geheimen Teil eines öffentlichen Schlüssels einen Hash-Wert. Sie erfüllt damit die selben Aufgaben wie ein MAC. Der zentrale Unterschied ist daß eine Signatur auf einem öffentlichen Schlüssel basiert, während ein MAC auf einem geheimen Schlüssel basiert. Bei einem Signaturschlüssel gibt es einen öffentlichen Teil sowie einen geheimen Teil. Mit dem geheimen Teil wird die Signatur erstellt, mit dem öffentlichen Teil wird sie geprüft. Das Verfahren das bei MIKEY zur Signaturbildung zum Einsatz kommt ist RSA-PKCS. Weitere Informationen dazu unter [PSS]


Abbildung 5: Ermittlung und Verwendung des Envelope Key


mehr gegeben. Diese Gefahr besteht bei Diffie-Hellman nicht, da der ermittelte Schlüssel nach Beendigung der Kommunikation nicht mehr benötigt wird und vernichtet werden kann.Das Verfahren läuft folgendermaßen:

1. Die Kommunikationspartner einigen sich zunächst auf eine Primzahl p und eine Primitivwurzel g mod p mit 2<=g<=p-1. Diese Parameter ergeben sich aus der sog. Diffie-Helmann Gruppe.

2. Beide Kommunikationspartner erzeugen jeweils eine geheim zu haltende Zufallszahl a bzw. b aus dem Bereich zwischen 1 und p-2. a und b werden nicht übertragen, bleiben also dem jeweiligen Kommunikationspartner, aber auch potenziellen Lauschern unbekannt.

3. Die Kommunikationspartner berechnen A = gamod p bzw. B = gbmod p. Nun werden A und B über das unsichere Medium übertragen.

4. Die Kommunikationspartner berechnen nun Bamod p = (gbmod p)amod p = (gba)mod p = (gab)mod p = (gamod p)bmod p = Abmod p = K. Das Ergebnis K ist für beide Partner gleich und kann als Schlüssel für die weitere Kommunikation verwendet werden.

(vgl. hierzu [DifHel1])

Zur Sicherung der Authentizität und Integrität wird in diesem Falle, wie auch bei Verwendung eines öffentlichen Schlüssels, eine Signatur über die Nachricht gebildet.


Abbildung 6: Prinzip der Diffie-Hellmann Schlüsselvereinbarung

http://de.wikipedia.org/wiki/Zufallszahl

http://de.wikipedia.org/wiki/Primitivwurzel

http://de.wikipedia.org/wiki/Primzahl

Kryptographische Standards

3 Kryptographische StandardsDie Sicherheit der hier vorgestellen Protokolle SRTP und MIKEY basiert auf offenen kryptographischen Verfahren. Die Vorgehensweise dieser Verfahren ist frei zugänglich und sie werden in der kryptographischen Öffentlichkeit diskutiert und untersucht. Die Verwendung offener Verfahren ergibt sich hauptsächlich aus zwei Gründen:

1. Da die beschriebenen Protokolle alle offen sind, müßen auch die in den Protokollen verwendeten Verfahren offen sein.

2. Es hat sich herausgestellt daß Verfahren die geheim entwickelt werden und Ihre Arbeitsweise nicht preisgeben oft nicht die gewünschte Sicherheit erreichen und von findigen Kryptanalytikern geknackt werden. Die hier vorgestellten öffentlichen Verfahren sind lange Zeit von Kryptanalytikern untersucht worden und konnten lange Zeit nicht geknackt werden.

Im folgenden werden die zugrundeliegenden Verfahren beschrieben und Ihre Sicherheit bewertet sowie auf bekannte Angriffe hingewiesen.

3.1 Das AES-VerfahrenDas AES (Advanced Encryption Standard) Verfahren ist ein sehr häufig verwendetes Verfahren zur symmetrischen Verschlüsselung. Es wird bei SRTP und MIKEY in verschiedenen Betriebsmodi für alle symmetrischen Verschlüsselungen benutzt.

AES wurde im Oktober 2000 vom US-amerikanischen National Institute of Standards and Technology(NIST)30 bekannt gegeben. Der Veröffentlichung war ein offener Wettbewerb vorangegangen, der von vielen Kryptologen als vorbildlich angesehen wurde. Das neue Verfahren sollte den Nachfolger des veralteteten DES31-Standards darstellen und folgende Kriterien erfüllen:• AES muss ein symmetrischer Algorithmus sein, und zwar eine Blockchiffre. • AES muss mindestens 128 Bit lange Blöcke verwenden und Schlüssel von 128, 192 und 256 Bit

Länge einsetzen können. • AES soll gleichermaßen leicht in Hard- und Software zu implementieren sein. • AES soll in Hardware wie Software eine überdurchschnittliche Performance haben. • AES soll allen bekannten Methoden der Kryptoanalyse widerstehen können, insbesondere Power-

und Timing-Attacken. • Speziell für den Einsatz in Smartcards sollen geringe Ressourcen erforderlich sein (kurze Codelänge,

niedriger Speicherbedarf). • Der Algorithmus muss frei von patentrechtlichen Ansprüchen sein und muss von jedermann

unentgeltlich genutzt werden können. Als Sieger aus diesem Wettbewerb ging ein in Belgien von Joan Demen und Vincent Rijmen entwickeltes Verfahren hervor, weshalb AES auch als Rijndael-Verfahren bezeichnet wird. Das Verfahren erfüllte die oben genannten Kriterien am besten und wurde deshalb unter den 15 Kandidaten zum Sieger gekürt. AES arbeitet mit einer Blocklänge von 128 Bit und ermöglicht wie gefordert Schlüssellängen von 128, 196 und 256 Bit. Bei der Verwendung im Rahmen des MIKEY sowie des SRTP Protokolls wird eine Schlüssellänge von 128 Bit benutzt.

30 Das NIST ist eine US-amerikanische Standardiesierungsbehörde. Weitere Informationen unter http://www.nist.gov31 DES stellt einen inzwischen veralteten Verschlüsselungsstandard dar, der vom NIST-Vorgänger und IBM mit

Unterstützung der NSA (National Security Agency – Eine der vielen US-amerikanischen Geheimdienste. Unter anderem zuständig für die Inlandsüberwachung) entwickelt. Als 3DES wird ein auf DES basierendes Verfahren noch heute verwendet. Weitere Informationen unter [DES1]


http://de.wikipedia.org/wiki/Patent

http://de.wikipedia.org/wiki/Speicherbedarf

http://de.wikipedia.org/wiki/Ressource

http://de.wikipedia.org/wiki/Smartcard

http://de.wikipedia.org/wiki/Kryptoanalyse

http://de.wikipedia.org/wiki/Performance_(Informatik)

http://de.wikipedia.org/wiki/Software

http://de.wikipedia.org/wiki/Hardware

http://de.wikipedia.org/wiki/Implementierung

http://de.wikipedia.org/wiki/Blockchiffre

http://de.wikipedia.org/wiki/Symmetrischer_Verschl?sselungsalgorithmus

http://www.nist.gov/


3.1.1 Arbeitsweise des VerfahrensAES basiert auf sehr einfachen Operationen wie Substitution, Vertauschung von Bytes und XOR-Verknüpfungen die sich leicht in Software und Hardware implementierten lassen. Im folgenden soll die Arbeitsweise des AES-Verfahrens grob beschrieben werden:

1. Ein Klartextblock aus 16 Bytes (128 Bit) wird in eine 4x4 Matriz geschrieben. Diese Matrix wird in mehreren Runden verändert. Bei einer Schlüssellänge von 128 Bit werden 10 Runden angewandt, bei größeren Schlüssellängen bis zu 14. Nach dem Durchlaufen der Runden steht in der Matrix der verschlüsselte Text.Desweiteren werden aus dem Benutzerschlüssel 10 bis 14 Rundenschlüssel erzeugt, die genauso lang sind wie der Benutzerschlüssel. Diese fließen in jeder Runde in die Verschlüsselung ein.

2. In jeder Runde werden nun folgende Schritte abgearbeitet:• Substitution: Die einzelnen Bytes der Matrix werden gemäß einer fest definierten sog. S-Box ersetzt.• ShiftRow: "In diesem Schritt werden die Zeilen der Matrix um eine bestimmte Anzahl von Spalten

nach links verschoben. Überlaufende Zellen werden von rechts fortgesetzt.". Dabei wird die 1. Zeile um 0 Spalten verschoben, die 2. Zeile um 1 Spalte, die 3. Zeile um 2 Spalten und die 4. Zeile um 3 Spalten

• MixColumn: "Schließlich werden die Spalten vermischt. Es wird zunächst jede Zelle einer Spalte mit einer Konstanten multipliziert und anschließend die Ergebnisse XOR verknüpft. Hinter dieser Vorgehensweise steckt ein komplizierter mathematischer Zusammenhang, der hier nicht näher erläutert wird. Die Konstante wird folgendermaßen bestimmt: Zeile 1: 2; Zeile 2: 3; Zeile 3: 1; Zeile 4: 1"

• KeyAddition: "Hierbei wird eine bitweise XOR-Verknüpfung zwischen dem Block und dem aktuellen Rundenschlüssel vorgenommen. Dies ist die einzige Funktion in AES, die den Algorithmus vom Benutzerschlüssel abhängig macht."

Vor der ersten Runde wird eine zusätzliche KeyAddition durchgeführt und in der letzten Runde wird die MixColumn-Transformation nicht durchgeführt.



3.1.2 Sicherheit von AESDas AES-Verfahren wurde vor seiner Veröffentlichung lange und ausgiebig diskutiert und durch Kryptanalytiker untersucht. Bis jetzt sind noch keine durchführbaren Angriffe (außer natürlich Brute-Force) auf das Verfahren bekannt. 2002 wurde jedoch von Nicolas Courtois und Josef Pieprzyk ein Papier veröffentlicht32 in dem gezeigt wird, daß sich das AES-Verfahren als ein überdefiniertes System von multivarianten quadratischen Gleichungen darstellen läßt. Seitdem werden in der Kryptanalytik große Anstrengungen unternommen, Verfahren zur Lösung solcher Gleichungen zu entwickeln. (Der sog. algebraische Angriff)

3.2 Das HMAC-SHA1-Verfahren

3.2.1 Beschreibung"Ein keyed-hash message authentication code, oder HMAC ist eine Art Message Authentication Code (MAC), der basierend auf einer kryptografischen Hash-Funktion berechnet wird."

Bei SRTP und MIKEY wird HMAC in Verbindung mit SHA1 als kryptografische Hash-Funktion zur Authenitifizierung und Integritätssicherung verwandt.

"Der HMAC wird aus der Nachricht N und einem geheimen Schlüssel K mittels der Hash-Funktion H wie folgt berechnet. K wird auf die Blocklänge der Hash-Funktion aufgefüllt. Falls die Länge von K größer als die Blocklänge der Hash-Funktion ist, wird K durch H(K) ersetzt.

32 siehe [CouPie1]


Abbildung 7: Prinzip des Ablaufs bei AES

http://de.wikipedia.org/wiki/Geheimer_Schl?ssel

http://de.wikipedia.org/wiki/Hash-Funktion

http://de.wikipedia.org/wiki/Kryptografie

http://de.wikipedia.org/wiki/Message_Authentication_Code


Die Werte opad und ipad sind dabei Konstanten, steht für die bitweise XOR-Operation und für die Verknüpfung durch einfaches Zusammensetzen."

SHA1 bezeichnet einen Standard aus der Gruppe der vom NIST veröffentlichten sog. Secure Hash Algorithm. Das verwendete SHA1 wurde in seiner jetzigen Form 1995 veröffentlicht. Es erzeugt einen Hash-Code von 160 Bit Länge aus einer Nachricht mit einer Länge von bis zu 2^64 - 1 Bits. SHA1 wird in vielen Standards und Protkollen als Hash-Algorithmus verwendet

3.2.2 SicherheitIn letzter Zeit wurden vermehrt Schwachstellen der Hashfunktion SHA1 bekannt. Der wohl schwerwiegendste Angriff wurde erst im August 200633 veröffentlicht. Bei diesem Angriff ist es möglich, bei freier Wahl von 25 % einer Eingangsnachricht zwei Nachrichten zu erzeugen, die denselben Hash-Wert bilden. Aufgrund dieses sog. Kollisionsangriffs kann SHA1 als geknackt bezeichnet werden.

Praktisch sind die Auswirkungen dieses Angriffs bei der Verwendung im Zusammenhang mit dem HMAC-Verfahren jedoch nicht relevant, da HMAC auch dann noch als sicher gilt, wenn Kollisionsangriffe möglich sind. Aufgrund der neuen Situation ist jedoch davon auszugehen, daß die Entwicklung neuer Hash-Funktionen ganz oben auf der Agenda der öffentlichen kryptographischen Forschung steht.

3.3 Die Public-Key Verschlüsselung nach RSA

3.3.1 BeschreibungDas RSA Verfahren ist das wohl am meisten verwendete asymmetrische Verschlüsselungsverfahren. Es wurde von Ronald R Rivest, Adi Shamir und Leonard Adleman im Jahre 1977 entwickelt als diese versuchten zu zeigen daß asymmetrische Kryptographie nicht möglich ist.

Bei asymmetrischer Kryptographie geht es darum, daß zur Verschlüsselung und zur Entschlüsselung unterschiedliche Schlüssel verwendet werden. Somit läßt sich der Schlüssel in einen öffentlichen (zur Verschlüsselung) und einen geheimen (zur Entschlüsselung) Teil aufteilen. Wenn nun Alice an Bob eine verschlüsselte Nachricht verschicken möchte, funktioniert das folgendermaßen:

1. Alice besorgt sich den öffentlichen Schlüssel von Bob. Sie verschlüsselt die Nachricht mit diesem öffentlichen Schlüssel.

2. Alice sendet die Nachricht über einen offenen Kanal an Bob3. Bob empfängt die Nachricht und entschlüsselt Sie mit seinem geheimen Schlüssel. Da nur er über

diesen Schlüssel verfügt kann die Nachricht von niemand anderem entschlüsselt werden.

Mit asymmetrischer Kryptograhpie ist es möglich geheime Nachrichten über offene Kanäle zu schicken, ohne daß vorher ein Austausch eines geheimen Schlüssels stattgefunden hat. Jedoch besteht weiterhin das Problem, daß die Authentizität des Schlüssels sichergestellt werden muß, d.h. der öffentliche Schlüssel den

33 siehe hierzu [SHAAtt1]


Abbildung 8: Prinzip asymetrischer Kryptographie


Alice verwendet muß auch wirklich der von Bob sein, und nicht etwa vom bösen Mallory34. Ist dies nicht sichergestellt könnte Mallory mit einer "Man in the Middle" Attacke35 die geheime Nachricht abhören und verändern.

Da das RSA-Verfahren etwa um den Faktor 1000 langsamer arbeitet als symmetrische Verschlüsselungsverfahren wird es wie z.B. beim berühmeten PGP36 in der Regel nur zur Übertragung des Schlüssels für ein symmetrisches Verfahren verwendet. Dies wird dann als hybrides Verfahren bezeichnet. Auch bei MIKEY wird RSA nur zur Verschlüsselung des sog. Envelope Key verwendet. Alle weiteren Verschlüsselungen basieren auf dem symmetrischen AES-Verfahren.

3.3.2 FunktionsweiseDas RSA-Verfahren gliedert sich in 3 Schritte: Schlüsselerzeugung, Verschlüsselung und Entschlüsselung. Diese 3 Schritte werden folgendermaßen durchgeführt:Schlüsselerzeugung

1. Wähle zwei große Primzahlen p und q2. Bilde n= p*q. n sei N Bit lang.3. Wähle ein e>1 das zu (p-1)(q-1) teilerfremd ist.4. Berechne ein d mit d*e= 1 mod (p-1)(q-1).5. n und e bilden den öffentlichen Schlüssel, d den privaten.

Verschlüsselung1. Zerlege den Klartext in Blöcke zu je N-1 Bit.2. Berechne zu jedem Block mit Wert m>n: c = me mod n. c ist der Geheimtext für diesen Block und N

Bit lang.Entschlüsselung

1. Zerlege den Geheimtext in Blöcke von N Bit Länge.2. Berechne zu jedem Block k = cd mod n. k ist der Klartext für diesen Block.

3.3.3 SicherheitDie Sicherheit des RSA-Verfahrens beruht auf folgenden mathematischen Problemstellungen:

• RSA-Problem (RSAP): Gegeben sind der öffentliche Schlüssel (n,e) sowie der Geheimtext c. Gesucht wird der Klartext k wobei gilt: k e≡c mod nDas Problem liegt hier in der Schwierigkeit Wurzeln modulo n zu ziehen, was zur Bestimmung des Klartexts n notwendig ist.

• RSA-Schlüsselproblem (RSAP*): Gegeben ist der öffentliche Schlüssel (n,e). Gesucht wird der geheime Schlüssel d wobei gilt: ed≡1 mod nDas Problem liegt hier in der Schwierigkeit die Eulersche φ-Funktion von n ohne Kenntnis der Faktoren p und q zu berechnen.

34 In der Kryptologie werden die Partner einer Kommunikation in der Regel als Alice und Bob bezeichnet. Mögliche Angreifer bezeichnet man als Mallory, manchmal auch als Eve.

35 Bei diesem Angriff tauscht Mallory einfach Bobs öffentlichen Schlüssel durch seinen aus und läßt allen Datenverkehr über ihn laufen. Alice würde dann die Nachricht mit Mallorys öffentl. Schlüssel verschlüsseln, den Sie für Bobs hielte. Mallory fängt die Nachricht ab, entschlüsselt sie, verändert sie ggf. und verschlüsselt sie wieder, diesmal mit Bobs öffentlichem Schlüssel und sendet sie weiter an Bob. Weder Alice noch Bob haben die Kompromittierung wahrgenommen.

36 PGP ist ein einstmals freies Programm zur Verschlüsselung von E-Mails. Das Original ist zwar inzwischen kommerzialisiert worden, es sind aber freie Implementierungen wir z.B. GnuPG verfügbar.


http://de.wikipedia.org/wiki/Eulersche_?-Funktion

http://de.wikipedia.org/wiki/Modulo_(Rest)


Für hinreichend große Primzahlen, z.B. wenn n 2048 Bits groß ist (RSA2048) sind diese Probleme mit den zur Zeit bekannten Algorithmen praktisch nicht lösbar. Die Komplexität dieser Fragestellungen ist jedoch mathematisch nicht bewiesen, es ist lediglich kein Verfahren bekannt, diese Probleme in angemessener Zeit zu lösen.

Besondere Aufmerksamkeit ist in diesem Zusammenhang auch der weiteren Entwicklung der Quantenrechner zu widmen. Im Jahre 1994 entwickelte Shor ein Verfahren mit dem sich auf Quantencomputern große Zahlen in kürzester Zeit faktorisieren lassen. Damit wäre das RSA-Verfahren geknackt.

3.4 Signaturen nach RSA

3.4.1 BeschreibungDie bei MIKEY im Public-Key und Diffie-Hellman Szenario angehängten Signaturen basieren ebenfalls auf asymmetrischer Kryptographie. Da es bei Signaturen jedoch um Verschlüsselung geht, sondern die Authentizität und Integrität einer Nachricht sichergestellt werden soll, wird hier etwas anders vorgegangen. Öffentlicher Schlüssel und geheimer Schlüssel haben hier quasi vertauschte Rollen. Die Signierung findet mit dem geheimen Schlüssel statt, die Prüfung mit dem öffentlichen Schlüssel.

Wenn Alice Ihre Nachricht signieren möchte, so daß Bob sie überprüfen kann werden folgende Schritte durchgeführt:

1. Alice erstellt einen Hash-Wert Ihrer Nachricht2. Sie verschlüsselt diesen Hash-Wert unter Verwendung ihres geheimen(!) Schlüssels, und versendet

Ihn mitsamt der Nachricht an Bob3. Bob bildet nun ebenfalls den Hash-Wert der Nachricht (ohne Signatur). Er entschlüsselt den

angehängten Hash-Wert mit dem öffentlichen Schlüssel von Alice und vergleicht diesen mit dem von Ihm ermittelten. Sind beide gleich, so ist die Authentizität sichergestellt.

3.4.2 SicherheitÜber die Sicherheit der Signierung mit RSA können im Prinzip die gleichen Aussagen gemacht werden wie zur Verschlüsselung. Das Problem liegt hier jedoch an anderer Stelle: Der empfohlene Hash-Algorithmus für die Signierung nach PKCS, wie sie bei MIKEY verwendet wird ist SHA1. Leider ist dieser Hash-Algorithmus vor kurzer Zeit geknackt worden. Damit wäre es einem Angreifer Mallory unter Umständen möglich, Bob eine Nachricht unterzuschieben, die denselben Hash-Wert hat, wie die Ursprungsnachricht. Da dies dann auch zum selben verschlüsselten Hash-Wert führt, würde Bob die Fälschung nicht bemerken. Die Sicherheit der Signaturen in MIKEY ist daher nur noch sehr eingeschränkt gewährleistet! Auch die anderen erlaubten Hash-Algorithmen schaffen hier wenig Abhilfe, da auch Sie nicht als sicher gelten und hauptsächlich aus Kompatibilitätsgrunden noch gestattet sind.

Aufgrund der Tragweite die das "Ende" von SHA1 hat bleibt daher nur zu hoffen, daß in den nächsten Jahren ein sicherer Hash-Algorithmus entwickelt wird.37

37 Zitate in diesem Kapitel sind ausschließlich den Wikipedia-Artikeln entnommen, die unter den entsprechenden Stichwörtern zum Zeitpunkt 29. bis 31. August 2006 zu finden waren.


Die C++ Bibliothek

4 Die C++ Bibliothek

4.1 AllgemeinesBegleitend zu dieser Diplomarbeit wurde eine Klassenbibliothek in C++ entwickelt, die die Entwicklung MIKEY-basierter Anwendungen erleichtern soll. Ziel der Klassenbibliothek mit der Bezeichnung libmikeys war eine möglichst universelle Einsetzbarkeit auf vielen denkbaren Platformen wie z.B. PC's, PDA's, Smartphones etc. Um die Realsierung dieses Zieles zu unterstüzten wurde die Entwicklung parallell unter Windows und Linux durchgeführt. Unter Windows wurde zusätzlich wurde ein einfaches grafisches Testprogramm entwickelt, daß die Funktionen der C++ Bibliothek benutzt.

4.1.1 Unterstützte AufgabenFolgende Aufgaben können mit den Klassen der Bibliothek erledigt werden:• Erzeugung einer Nachricht im Pre-Shared und Public-Key Szenario, mit und ohne Notwendigkeit

einer Verifkationsnachricht.• Untersuchen (Parsen) einer Nachricht im Pre-Shared und Public-Key Szenario sowie einer

Verifikations- oder Fehlernachricht. • Verarbeiten einer geparsten Nachricht. Dazu gehört das Prüfen auf Authentizität und Integrität, das

automatische Versenden einer Verifikationsnachricht falls erforderlich, das Entschlüsseln der übertragenen Schlüssel sowie das Speichern der Schlüssel in die interne Datenbank.

• Schneller Zugriff auf die in der internen Datenbank gespeicherten Schlüssel für SRTP-Sitzungen.• Unterstützung aller minimal erforderlichen (mandatory) Verschlüsselungs- und

Authentifizierungsalgorithmen wie sie in RFC 3830 spezifiziert sind.• Unterstüztung der NULL-Verschlüsselung.• Automatisches Erzeugen von Fehlernachrichten.• Schutz gegen Replay-Angriffe durch Prüfung des Zeitstempels und Speichern von Nachrichten in

einem Replay-CacheNicht durch die Funktionalität unterstützt werden folgende Aufgaben:• Das eigentliche Senden oder Empfangen von Nachrichten über das Netzwerk. Empfangene

Nachrichten müssen im Speicher des Rechners abgelegt werden. Der Bibliothek ist die Adresse des Speichers zu übergeben. Das Versenden von Nachrichten geschieht mittels einer Callback-Funktion

• Das Ver- oder Entschlüsseln mittels des RSA Algorithmus sowie das Verarbeiten der Public-Key Zertifikate, die den öffentlichen Schlüssel eines Kommunikationspartners enthalten. Dies ist mittels einer Callback-Funktion von der implementierenden Anwendung zu realisieren. Dasselbe gilt für das Prüfen einer Signatur mittels RSA

• Das Verwalten und Speichern von Zertifikaten oder geheimen Schlüsseln. Diese werden mittels einer Callback-Funktion abgefragt.

• Das dynamische Anpassen des Akzeptanzbereichs für den Zeistempel und der Größe des Replay-Caches wie in Abschnitt 5.4 von RFC 3830 beschrieben.

• Das Erstellen oder Parsen von Nachrichten im Diffe-Hellmann Szenario.Einige dieser Punkte sind aufgrund von Zeitmangel nicht bzw. noch nicht in der Klassenbibliothek implementiert. Manche Aufgaben wie z.B. das Verwalten der Zertifikate und Schlüssel, die Bewertung der Vertrauenswürdigkeit eines Zertifikats sowie das Versenden und Empfangen von Nachrichten über das Netz sind nicht originäre Aufgabe einer Klassenbibliothek sondern der sie verwendenden übergordneten Applikation. Diese Aufgaben werden daher auf absehbare Zeit nicht in der Klassenbibliothek implementiert


Die C++ Bibliothek

werden. Die Funktionen, die dagegen als sinnvoll anzusehen sind sollen auf längere Sicht noch implementiert werden, insbesondere die Behandlung von Diffie-Hellmann Nachrichten und das dynamische Anpassen der Größe des Replay-Cache.

Es ist geplant die Klassenbibliothek samt Dokumentation nach Abschluß der Diplomarbeit unter einer geeigneten Open-Source Lizenz ins Netz zu stellen. Nach gegenwärtigem Kenntnissstand des Autors gibt es zur Zeit keine vergleichbare freie Bibliothek zur Unterstützung des MIKEY-Protokolls.

4.1.2 DokumentationDie Bibliothek verfügt über eine Dokumentation die sich in zwei Bereichen findet. Zum einen werden die Klassen, Eigenschaften und Methoden beschrieben. Dies geschieht im Quelltext selbst und in einer zusätzlichen HTML-Dokumentation. Ergänzend dazu wurde eine grobe Beschreibung der Struktur und der Arbeitsweise der Bibliothek in einem Textdokument erstellt, das im PDF-Format verfügbar ist. Aufgrund der internationalen Ausrichtung des Projektes wurde sämtliche Dokumentation in Englisch erstellt.

4.2 Entstehungsprozeß

4.2.1 MotivationGrundlegende Motivation des Projekts war der Wunsch sich mit der Entwicklung kryptographischer Software auseinanderzusetzen und die Kentnisse in der Entwicklung von Softwareprojekten unter Verwendung objektorientierter Sprachen zu vertiefen. Aufgrund der hohen Aktualität war dabei ein Bezug zum Thema Internettelefonie erwünscht. Die Implementierung einer Klassenbibliothek zur Nutzung des MIKEY-Protokolls bot sich dabei an, da dieses Protokoll noch relativ neu war. Nach Kenntnisstand des Autors gibt es bis dato keine freie Implementierung des MIKEY-Protokolls. Diese Lücke soll nun geschlossen werden.

Auch die Umsetzung eines "frischen" Standards zu dem es naturgemäß noch wenig Sekundärliteratur gibt, stellte eine interessante Herausforderung dar.

4.2.2 Wahl der ProgrammierspracheBei der Wahl der Programmiersprache wurden folgende Anforderungen gestellt:• Eine möglichst breite Einsatzfähigkeite unter verschiedenen Hard- und Softwareplatformen• Eine hohe Verbreitung und ein anerkannter Standard um eine Weitentwicklung auch unter

Beteiligung anderer Entwickler zu ermöglichen• Eine möglichst kurze Ausführungszeit des Codes• Eine hohe Flexibilität und Mächtigkeit der Sprache

Unter diesen Voraussetzungen entschied sich der Entwickler für die Sprache C++, welche die oben genannten Forderungen erfüllt. C++ ist in der ISO-Norm 14882 spezifiert. Die Sprache verfügt über eine hohe Verbreitung, bietet mit der Unterstützung von objektorientierter Programmierung sowie Vorlagen und umfangreichen zum Standard zugehörigen Biblotheken mächtige Sprachwerkzeuge und es gibt Compiler für eine große Auswahl an Hardwareplatformen.

4.2.3 Entwicklung eines KlassenmodellsNach dem Studium der Spezifikation wurde als erster Schritt der Entwicklung ein Klassenmodell erstellt, daß als Grundlage der Implementierung diente. Dabei wurde nach dem Prinzip vorgegangen für bestehende Entitäten jeweils eine Klasse zu modellieren. Gemeinsamkeiten von Entitäten wurden in entsprechenden Basisklassen modelliert. So ergab sich z.B. eine Klasse CMessage für alle Formen von MIKEY-Nachrichten.


Die C++ Bibliothek

Für spezifische Nachrichten wurden von dieser Klasse abgeleitete Klassen entworfen, z.B. CPreSharedMessage und CPublicKeyMessage.

Im Laufe der Entwicklung erfuhr das Klassenmodell einige Veränderungen, die zum Teil auf fehlerhaftem Verständnis der Spezifikation beruhten, zum anderen Teil durch neue Anforderungen im Entwicklungsprozeß nötig geworden waren. Die Grundstruktur wurde jedoch während des gesamten Entwicklungsprozeßes beibehalten.

4.2.4 Verwendung von HilfsmittelnNiemand entwickelt ein größeres Softwareprojekt nur mit einem Kommandozeilencompiler und einem Editor. Die Verwendung geeignter Hilfmittel sowie der Rückgriff auf vorhande Bibliotheken für die Erfüllung bestimmter Aufgaben ist eine Selbstverständlichkeit. Ebenso verhält es sich auch bei dem hier vorgestellten Projekt. Die verwenden Bibliotheken und Programme sollen hier kurz beschrieben werden.

Als integrierte Entwicklungsumgebung wurde unter Linux auf KDevelop zurückgegriffen. KDevelop ist Teil des KDE-Paketes und unterstützt neben C++ auch andere Programmiersprachen. Als Compiler verwendet KDE den C++ Compiler aus der Gnu Compiler Collection (GCC). Unter Windows wurde die frei verfügbare Express Edition von Visual C++ verwendet. Diese ist abgespeckte Variante des Visual Studio welches eine Art De-Facto Industriestandard bei der Entwicklung von Windows-Anwendungen darstellt.

Zur Erstellung von Klassendiagrammen nach dem UML-Standard38 wurde das UML-Programm Enterprise Architect verwendet. Das Windows-Programm unterstützt den aktuellen Stand der UML-Spezifikation, ist einfach und flexibel zu bedienen und untersützt das sog. Round-Trip-Engineering, also die Erzeugung von Quellcode aus Klassendiagrammen und vice versa.

Zur Erstellung der Dokumentation wurde auf das Open-Source Programm Doxygen39 zurückgegriffen. Dieses ermöglicht die Extrahierung von Beschreibungen direkt aus dem Quelltext, so daß eine Pflege von parellellen Dokumentationsquellen entfällt.

Zur Realisierung der kryptographischen Funktionen wurde auf die offene Klassenbibliothek Crypto++ zurückgegriffen. Diese Klassenbibliothek bietet plattformunabhängige C++ Implementierungen aller gängigen kryptographischen Algorithmen an. Im Rahmen von Libmikeys wird Crypto++ zur Erzeugung von Zufallszahlen, zur Ver- und Entschlüsselung mit AES sowie zur Erzeugung von HMAC-SHA1 Authentifizierungscodes verwendet.

4.2.5 Schwierigkeiten bei der EntwicklungInsgesamt gestaltete sich die Entwicklung schwieriger als zunächst erwartet. Die Komplexität der Umsetzung eines Protokolls wie MIKEY es darstellt erwies sich dabei als große Herausforderung. MIKEY zeichnet sich durch eine relativ hohe Flexibilität aus. Viele der Angaben in einer Nachricht sind optional, d.h. sie können gesendet werden oder nicht. Dies im Quelltext zu realisieren erfordert eine gut durchdachte und anpassungsfähige Klassenstruktur.

Ein weiteres Hinderniß stellte insbesondere zu Beginn der Entwicklung die Spezifikation dar. Da der Autor bis dato über keine Erfahrung im Umgang mit Spezifikationen verfügte, die von der IETF herausgegeben wurden entstanden zu Beginn Unsicherheiten und Mißverständnisse, die sich erst im Laufe der Zeit und mit fortlaufendem Entwicklungsstadium auflösten.

38 Unified Modelling Language. Ein Standard zur Modellierung von Software und anderen System. UML definiert dabei Bezeichner und grafische Notationen. Weitere Informationen unter http://www.uml.org

39 Weitere Informationen zu Doxygen unter http://www.stack.nl/~dimitri/doxygen/index.html


Die C++ Bibliothek

4.2.6 Erstellung der DokumentationNach (vorläufigem) Abschluß der Entwicklungsarbeiten wurde die Dokumentation der Bibliothek durchgeführt. Diese erfolgte hauptsächlich durch Kommentare direkt im Quelltext. Unter Zuhilfenahme des Programms Doxygen wurden diese Kommentare extrahiert und eine HTML-Dokumentation aufgebaut. Der späte Zeitpunkt dieser Arbeit wurde bewußt gewählt. Zum einen entfällt dadurch erstmal die Aktualisierung der Dokumentation nach Änderungen, zum anderen erfolgt so quasi nebenbei nochmal eine fast komplette Sichtung des Quelltextes. Dabei wurden auch einige kleinere Fehler entdeckt und beseitigt.

4.2.7 AusblickEs ist geplant die Bibliothek nach Abschluß der Diplomarbeit der Allgemeinheit zur Verfügung zu stellen. Vorraussichtlich wird eine Veröffentlichung im Open-Source Repository Sourceforge unter der LGPL (Lesser Gnu General Public License)40 erfolgen. Diese Veröffentlichung erfolgt aus zwei Gründen. Zum einen soll damit die Open-Source Gemeinde um ein weiteres hoffentlich nützliches Werkzeug bereichert werden. Der Autor selbst hat bereits desöfteren mit Open-Source Software gearbeitet und dabei zum Teil sehr positive Erfahrungen gemacht. Daraus entstand der Wunsch für die kostenlos erhaltene Software der Gemeinschaft "etwas zurückzugeben". Zum anderen ist die Freigabe mit der Hoffnung verbunden, daß sich weitere Personen an der Entwicklung der Bibliothek beteiligen und diese letzlich zu einer leistungsfähigen Standardbibliothek wird. Insbesondere die für Open-Source-Verhältnisse relativ annehmbare Dokumentation soll dabei einen leichten Einstieg ermöglichen.

4.2.8 Das TestprogrammParallell zur Klassenbibliothek wurde ein Windows-Programm entwickelt, mit dem die Funktionalität der Bibliothek getestet wird. Das Programm dient lediglich diesem Zweck und erfüllt keine üblichen Standards bezüglich Nutzerfreundlichkeit und Funktionsumfang. Zur Entwicklung wurde ebenfalls auf Visual C++ in der freien Express Edition zurückgegriffen.

4.3 Einsatzmöglichkeiten der MIKEY-BibliothekEigenständig macht die Verwendung der MIKEY-Bibliothek keinen Sinn. Sinnhaft und produktiv nutzbar wird Sie nur bei Verwendung im Rahmen einer gesamtheitlichen Applikation. An dieser Stelle sollen daher einige mögliche Einsatzszenarien aufgezeigt werden.

4.3.1 SoftphoneDie wohl naheliegendste Nutzungsmöglichkeit ist die Entwicklung eines Programms, daß einem mittels Soundkarte das Telefonieren über das Internet ermöglicht, ein sog. Softphone. Solche Programme mit Unterstützung für die Protokolle SIP und RTP gibt es bereits mehrfach41. Dem Autor ist allerdings noch kein solches Programm mit integrierter Unterstützung für das MIKEY-Protokoll bekannt. In diesem Zusammenhang könnte vor allem von der Möglichkeit gebrauch gemacht werden, MIKEY in die Nachrichten des SIP Protokolls zu integrieren.

Für die meisten Aufgaben die zur Realisierung eines solchen Softphones erledigt werden müßen gibt es bereits freie Bibliotheken die verwendet werden können. So z.B. libsrtp42, die SIP-Api aus der SIPfoundry43 und eben auch libmikeys, so daß die Implementierung eines solchen Projekts innerhalb weniger Monate erfolgen könnte.

40 http://www.gnu.org/licenses/lgpl.html41 siehe z.B http://sipx-wiki.calivia.com/index.php/Phones_%26_Gateways42 http://srtp.sourceforge.net/srtp.html43 http://www.sipfoundry.org


Die C++ Bibliothek

4.3.2 Sicherheits-ProxyEine andere interessante Möglichkeit wäre die Entwicklung eines SIP/RTP Proxys zur Absicherung des Mediendatenverkehrs. Damit könnte man auch mit einem VoIP-Telefon oder Softphone, das keine gesicherten Verbindungen mittels MIKEY/SRTP unterstützt abhörsicher telefonieren. Das Protokoll SIP definiert bereits einen Proxy-Server, so daß SIP-fähige Telefone entsprechend konfigurierbar sind. In einen solchen SIP-Proxy kann die hier beschriebene Funktionalität integriert werden.

Der Proxy erledigt dabei nicht nur die der SIP-Spezifikation gemäßen Aufgaben wie z.B. die Lokalisierung des gewünschten Gesprächspartners, sondern fügt auch die MIKEY-Nachrichten in den SIP Datenstrom ein. Da die aktuelle SIP-Adresse des Gesprächspartners auch mittels SIP übertragen wird ist es somit gleich möglich den RTP-Verkehr umzuleiten und jedes RTP-Paket gemäß den mittels MIKEY ausgehandelten Parametern zu verschlüsseln und zu authentifizieren bevor es an den eigentlichen Gesprächspartner weitergeleitet wird und vice versa.

4.4 Verwendung vorhandener PGP-Schlüssel im Rahmen von MIKEYIm Rahmen des Programms PGP hat sich die Verteilung öffentlicher Schlüssel bereits bewährt. Viele Menschen verfügen über den öffentlichen PGP-Schlüssel von wichtigen und häufigen Kommunikationspartnern und haben diesen z.T. auch schon authentifiziert44. Es wäre daher wünschenswert einen solchen Schlüssel auch für die VoIP-Kommunikation einsetzen zu können.

Ob dies gelingt oder nicht, hängt im wesentlichen davon ab, in welchem Format der öffentliche Schlüssel vorliegt. MIKEY erwartet den öffentlichen Schlüssel in Form eines Zertifikats nach dem Standard X.50945. Die Schlüssel die der Autor in freier Wildbahn zusammengetragen hat liegen lediglich einzeln in einer ASCII-Datei vor. In dieser Form sind sie für MIKEY nicht zu verwenden. Es besteht jedoch die Möglichkeit mit Hilfe von freien Tools wie z.B. OpenSSH46 eigene X.509 – Zertifikate zu erstellen und dabei auch vorhandene Schlüssel zu verwenden. Diese Zertifikate sind jedoch nicht von einer dritten vertrauenswürdigen Stelle authentifiziert, so daß die Sicherheitsapplikation, die die Zertifikate prüft, diese wahrscheinlich als unsicher einstufen wird. Um dem zu entgehen ist es möglich eine eigene Zertifizierungsinstanz einzurichten und diese bei der Sicherheitsapplikation als vertrauenswürdig einzustufen. Die selbst erstellten Zertifikate sollten dann diese selbst erstellte Zertifizierungsintanz angeben. In diesem Falle hat man sich quasi selbst das Vertrauen ausgesprochen.

Eine andere Möglichkeit besteht darin, ausschließlich X.509 Zertifikate zu verwenden, die von einer vertrauenswürdigen Instanz geprüft wurden. Da diese jedoch in der Regel Geld kosten werden Sie wohl nicht von vielen Kommunikationspartnern angeboten werden.

44 Eine Authetifizierung kann z.B. durch einen fernmündlichen Vergleich des sog. Fingerprints ohne großen Aufwand erfolgen.

45 für weitere Informationen zu X.509 siehe [X509]46 http://www.openssh.com/de/index.html


Abbildung 9: Funktionsweise eines RTP/SRTP-Proxys

Weitere Entwicklung der IP-basierten Mediendienste

5 Weitere Entwicklung der IP-basierten MediendiensteWichtig für die Frage inwieweit die hier vorgestellten Sicherheitsprotokolle in absehbarer Zeit Anwendung finden ist auch, in welchem Rahmen sich IP-basierte Sprach- und Videokommunikation etablieren und ausbreiten wird. Wie bereits erwähnt ist der technische Sprung, den diese Entwicklung im Telefoniebereich bedeutet, enorm. Es soll hier versucht werden die zukünftige Entwicklung insbesondere im Hinblick auf die Telefonie abzuschätzen.

5.1 Technischer VergleichDie technischen Konzepte zwischen IP-basierter und leitungsgebundener Telefonie unterscheiden sich grundlegend. Bei der leitungsgebundenen Telefonie wird eine direkte Verbindung zwischen zwei Gesprächstpartnern hergestellt während bei VoIP Datenpakete über ein öffentliches Netz versendet werden. Diese Verfahren haben spezifische Eigenschaften die hier kurz beleuchtet werden sollen.Leitungsgebundene Telefonie • Hohe Ausfallsicherheit, bedingt durch die technische Konzeption und die Ausgereiftheit aufgrund

der langen Nutzung.• Hoher Schutz gegen Abhören, Verändern und Stören der Verbindung bedingt durch direkte

Leitungsverbindung.• Relativ hohe Kosten, insbesondere abhängig von der Entfernung zwischen den Gesprächspartnern.• Hohe Ortsgebundenheit eines Anschlußes

IP-Telefonie• Geringe Ausfallsicherheit, insbesondere bei Versendung der Daten über das Internet.• Ohne zusätzliche Maßnahmen kein Schutz gegen Abhören, Verändern und Stören der Verbindung.• Geringe Kosten aufgrund der hohen Kapazitätsreserven im Internet.• Keine Ortsgebundenheit eines Anschlußes

5.2 Bisherige VerbreitungDie Entwicklung der IP-Telefonie wäre ohne die vorherige Verbreitung des Internet gar nicht möglich gewesen. Die Anfänge der IP-Telefonie stellten Instant-Messaging Programme dar, die über zusätzliche Funktionen für direkte Sprachkommunikation verfügten, z.B. Microsoft Netmeeting. Inzwischen ist das Angebot deutlich umfangreicher geworden, insbesondere auch bedingt durch die Verabschiedung und Etablierung technischer Standards wie z.B. SIP und RTP. Die meisten Anbieter von Kommunikationsdienstleistungen und Internet-Zugängen haben inzwischen auch VoIP-Dienste in Ihrem Angebot. Dabei werden insbesondere auch Verbindungen vom IP-Telefon ins klassische Telefonnetz sowei eine Erreichbarkeit des IP-Telefonnetz aus dem klassischen Telefonnetz angeboten. Diese zeichnen sich meistens durch geringere Gesprächsgebühren (im Vergleich zur leitungsgebundenen Telefonie) aus. Auch gibt es inzwischen ein umfangreiches Angebot an Hardware. Hierzu gehören IP-Telefone genauso wie VoIP fähige Router die eine weitere Verwendung analoger oder ISDN-Telefone ermöglichen.

Die Qualität der VoIP Verbindungen ist nach Aussagen von Anwendern inzwischen meistens brauchbar, jedoch ist die Zuverlässigkeit nicht immer gegeben. Hier spielt vor allem das Thema QoS (Qualitiy of Service) eine große Rolle. Es gibt eben keine Garantie, daß ein Datenpaket innerhalb einer für VoIP vertretbaren Zeit den Weg von einem Kommunikationspartner zum anderen findet.

Etwas anders stellt sich die Situation im Rahmen von nichtöffentlichen Netzen, also Intranets dar, z.B. beim Telefonieverkehr einer Firma oder z.B. auch einer Hochschule. Auch hier werden vermehrt klassiche Telefonanlagen durch IP-basierte Netze ersetzt. Der Vorteil liegt auch hier meist in geringeren Kosten, da die



parellele Einrichtung und Wartung von zwei Netzen (eins für Daten, eins für Telefonie) entfällt und dadurch Synergieeffekte genutzt werden können. Hier bietet sich zusätzlich der Vorteil, daß die Kontrolle über die Netzinfrastruktur gegeben ist. Dies ermöglicht die Einrichtung QoS-fähiger Netzhardware und sichert so die benötigte Zuverlässigkeit und Qualität. Insbesondere für Einrichtungen mit mehreren Standorten, die über eine Standleitung mit fester Datenrate verbunden sind bieten sich so enorme Einsparmöglichkeiten. Sobald ein Telefongespräch den internen Bereich verläßt wird dabei meist wieder auf klassisches ISDN zurückgegriffen. Die Umsetzung von VoIP in ISDN übernimmt dabei eine sog. VoIP-PBX wie z.B. das offene Programm Asterisk.

Auch die klassischen Telekommunikationsanbieter stellen nicht mehr wirklich eine Leitungsverbindung zwischen zwei Gesprächspartnern z.B. eines ISDN-Telefonats her, sondern setzen die Verbindungen ab der Orstvermittlungsstelle meist auch in IP-Protokolle um, da dies die physischen Leitungen besser auslastet.

5.3 Ausblick

5.3.1 PrivatanwenderLetztlich verfügt VoIP über einige Vorteile, die eine weitere Zunahme dieser Technik erwarten läßt. Die Sprachqualität und Zuverlässigkeit ist für den Bereich der Privatanwender ausreichend und das Angebot sowohl an Dienstleistungen als auch an Hardware und Software ist groß. Trotzdem ist nicht mit einem schnellen Ende von klassischen Telefonanschlüssen zu rechnen. Dies liegt insbesondere daran, daß sich die Leitung in die eigene Wohnung im Eigentum der Telekom befindet. Auch wenn der Anschluß wie z.B. beim Autor komplett von einem anderen Anbieter gestellt wird, so zahlt dieser der Telekom Miete für die Leitung von der Ortsvermittlungsstelle zum Hausanschluß.

Da die Telekommunikationsanbieter kein Interesse daran haben, ihre eigene Geschäftsgrundlage zu schädigen ist nicht davon auszugehen daß sie auf absehbare Zeit Internetanschlüsse ohne Telefon mitsamt der dazugehörigen Grundgebühr anbieten werden. Alternativen zum Internetzugang über die Telekom-Leitung sind bislang eher rar gesät. Auf Grundlage leitungsgebundener Technik verfügen lediglich die Kabelanbieter und Stromkonzerne noch über eine Leitung in eine nennenswerte Zahl von Haushalten. Bis jetzt scheinen sich diese in Deutschland allerdings nicht sonderlich darum zu bemühen, ihre Infrastruktur entsprechend auszubauen und als Anbieter von Internet-Zugängen in Erscheinung zu treten. Bei Ihnen besteht keine Koppelung an den Telefonanschluß. Es ist jedoch davon auszugehen, daß z.B. im Bereich der Kabelanbieter eine Kopplung mit einem Fernsehanschluß die Regel sein wird.

Drahtlose Netzwerktechniken für den Weitbereich sind bis jetzt noch nicht etabliert. Auch wenn sich hier in absehbarer Zeit neue Techniken wie z.B. das WiMax etablieren sollten, so stellt dies für die breite Masse der Intenet-Nutzer wohl keine Alternative dar. Leitungsungebundene Netzwerktechniken sind in Bezug auf Bandbreite, Zuverlässigkeit, Verzögerung, Sicherheit und Gesundheitsgefährdung der leitungsgebundenen Technik unterlegen.

5.3.2 Nutzung bei Firmen/InstitutionenEin Ersatz der Leitungsgebundenen Telefonie durch VoIP-Techniken ist nach Auffassung des Autors am ehesten im Bereich interner Kommunikationsnetzwerke zu erwarten. Hier überwiegen die Vorteile klar. Gerade bei Neueinrichtungen und Neubauten kann auf das Verlegen zweier Leitungsnetze verzichtet werden. Bei verbundenen Standorten sind Standleitungen für den Datenverkehr meist sowieso bereits vorhanden. Auch die Kosten für leitungsgebundene Telefonanlagen liegen oft über denen für eine VoIP-basierte Einrichtung. Die Ausfallsicherheit von Datennetzen hat inzwischen ebenfalls ein sehr hohes Niveau erreicht.

Der Autor geht daher davon aus, daß insbesondere bei Neueinrichtungen in Zukunft immer seltener auf klassische Telefonanlagen zurückgegriffen wird. Für die Kommunikation außerhalb des internen Netzes wird allerdings noch längere Zeit auf klassisches ISDN zurückgegriffen werden. Hier spielt vor allem die Qualität



und Verfügbarkeit eine wichtige Rolle. Für einen Privatanwender mag es akzeptabel sein, wenn die Telefonverbindung gelegentlich unzuverlässig oder von mangelnder Qualität ist. Für Insitutionen wie Verwaltungen, Firmen, etc. ist dies jedoch nicht hinnehmbar. Interessant ist in diesem Zusammenhang die Frage ob die Telekommunikationsfirmen irgendwann dazu übergehen, VoIP Anschlüße mit der Zusicherung von QoS-Parametern anbieten werden. Diese Anschlüße wären auch für Firmenkunden interessant..

5.3.3 SpitEin weiteres Thema im Zusammenhang mit der Verbreitung von VoIP soll hier noch angesprochen werden. Das tätigen unerwünschter, zeit- und nervenraubender Werbeanrufe. Dies wird als Spit (Spam over Internet Telephony) bezeichnet. Ein Vorteil der Internet-Telefonie wird hier zu seinem Nachteil: Die äußerst geringen Kosten. Dies ermöglicht es, ähnlich wie bei E-Mail, Massen unerwünschter Werbung zu verbreiten. Der Autor erhält pro Tag etwa 50 bis 100 unerwünschter Mails. Dank adaptiver Filtersysteme hält sich der damit verbundene Arbeitsaufwand und Störeffekt jedoch im Rahmen. Sollte sich eine ähnlich dramatische Entwicklung bei der Telefonie ergeben, würde dies die vollständige Abschaltung des Telefonanschlußes zur notwendigen Folge haben. Bis jetzt ist Spit noch nicht besonders verbreitet, sollte sich dies jedoch wie zu erwarten ändern, so kann dies ein ernsthaftes Hindernis in der weiteren Entwicklung IP-basierter Telefoniedienste darstellen.



Literaturverzeichnis[Badach1], Voice over IP, die Technik, 2004[Gesch1] http://de.selfhtml.org/intro/internet/index.htm (Stand: 14.08.2006)[Analog1] http://www.irf.uka.de/seminare/rkt/analog (Stand: 14.08.2006)[VoIP1] http://de.wikipedia.org/wiki/Voip (Stand: 14.08.2006)[ISDN1] http://de.wikipedia.org/wiki/Isdn (Stand: 14.08.2006)[Internet1] http://de.selfhtml.org/intro/internet/standards.htm (Stand: 14.08.2005)[Internet2] http://de.wikipedia.org/wiki/Internet (Stand: 14.08.2006)[IP1] http://de.wikipedia.org/wiki/Internet_Protocol (Stand: 14.08.2006)[RFC791] http://www.ietf.org/rfc/rfc791.txt (Stand: 14.08.2006)[RFC2460] http://www.ietf.org/rfc/rfc2460.txt (Stand: 14.08.2006)[IX502] IX, 5/2002, Seite(n) 118, http://www.heise.de/ix/artikel/2002/05/118/[PCProf1105] Belauschen von VoIP-Telefonaten, 11/2005, Seite(n) , http://www.testticker.de/pcpro/praxis/netzwerke/article20051006042.aspx[SIP1] http://de.wikipedia.org/wiki/Session_Initiation_Protocol (Stand: 14.08.2006)[H323] http://www.openh323.org/standards.html (Stand: 14.08.2006)[RFC3261] http://www.ietf.org/rfc/rfc3261.txt (Stand: 14.08.2006)[RFC3830] http://tools.ietf.org/html/rfc3830 (Stand: 14.08.2006)[RFC3711] http://tools.ietf.org/html/rfc3711 (Stand: 14.08.2006)[RFC3550] http://www.ietf.org/rfc/rfc3550.txt (Stand: 14.08.2006)[FIPS197] http://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdf (Stand: 14.08.2006)[Wobst1]Wobst, Reinhard, Abenteuer Kryptographie, 2001[AES1] http://de.wikipedia.org/wiki/Advanced_Encryption_Standard (Stand: 14.08.2006)[RFC768] http://tools.ietf.org/html/rfc768 (Stand: 14.08.2006)[OSI1] http://de.wikipedia.org/wiki/OSI-Modell (Stand: 15.08.2006)[RFC1122] http://tools.ietf.org/html/rfc1122 (Stand: 14.08.2006)[RFC2327] http://tools.ietf.org/html/rfc2327 (Stand: 14.08.2006)[RFC2409] http://tools.ietf.org/html/rfc2409 (Stand: 14.08.2006)[HMAC1] http://de.wikipedia.org/wiki/HMAC (Stand: 16.08.06)[MAC1] http://de.wikipedia.org/wiki/Message_Authentication_Code (Stand: 16.08.06)[RFC2104] http://tools.ietf.org/html/rfc2104 (Stand: 14.08.2006)[RFC2201] http://tools.ietf.org/html/rfc2201 (Stand: 14.08.2006)[PSS] http://www.rsalabs.com (Stand: 14.08.2006)[DifHel1] http://de.wikipedia.org/wiki/Diffie-Hellman (Stand: 23.08.2006)[DES1] http://de.wikipedia.org/wiki/Data_Encryption_Standard (Stand: 31.08.2006)[CouPie1] http://eprint.iacr.org/2002/044 (Stand: 31.08.2006)[SHAAtt1] http://www.heise.de/newsticker/meldung/77235 (Stand: 31.08.2006)[X509] http://de.wikipedia.org/wiki/X.509 (Stand: 4.09.2006)


Bewertung und Beschreibung des...

Documents

Transcript of Bewertung und Beschreibung des...