Konzeption und Implementierung einer zusätzlichen Verschlüsselungsschicht für Skype

Transkript

1 Konzeption und Implementierung einer zusätzlichen Verschlüsselungsschicht für Skype Felix Schuster 4. September 2011 Diplomarbeit Ruhr-Universität Bochum Lehrstuhl für Netz- und Datensicherheit Professor Jörg Schwenk Professor Thorsten Holz

2 Ich danke Prof. Dr. Jörg Schwenk und Dominik Birk für die Betreuung dieser Arbeit. Ebenfalls bedanken möchte ich mich bei Ingrid und Norbert Schuster und Josefin Annemüller für das Korrekturlesen. 2

3 Erklärung Ich erkläre, dass das Thema dieser Arbeit nicht identisch ist mit dem Thema einer von mir bereits für eine andere Prüfung eingereichten Arbeit. Ich erkläre weiterhin, dass ich die Arbeit nicht bereits an einer anderen Hochschule zur Erlangung eines akademischen Grades eingereicht habe. Ich versichere, dass ich die Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen benutzt habe. Die Stellen der Arbeit, die anderen Werken dem Wortlaut oder dem Sinn nach entnommen sind, habe ich unter Angabe der Quellen der Entlehnung kenntlich gemacht. Dies gilt sinngemäß auch für gelieferte Zeichnungen, Skizzen, bildliche Darstellungen und dergleichen. 3

4 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung Überblick Vorwort Bereits vorhandene Abhörschutzmaßnahmen und Unsicherheiten Aufbau des Skype-Netzwerks und grundlegende Abläufe Vertrauen im Skype-Netzwerk Man-In-The-Middle Angriff Zielstellung Vergleich der Vertrauensmodelle Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen Spezielle Schwierigkeiten bei der Verschlüsselung von Skype-Verbindungen Prä Audio-Codec Verschlüsselung Skype API Bewertung Netzwerkpaketverschlüsselung Direkte Eintragung eines lokalen Proxy-Server Umleitung von Windows Sockets API Aufrufen Zuordnung von Netzwerkpaketen Bewertung Implementierung der Verschlüsselungslösung Vorgaben und Ziele Konzeptionelle Ziele Implementierungstechnische Vorgaben Das Programm watchasayin Funktionen Aufbau und Design Das Threading-Modell Programmkern und Einstiegsfunktion Verwendung des Component Object Models Basismodul - Surface Kommunikation mit anderen watchasayin Instanzen Ereignisverarbeitung

5 Inhaltsverzeichnis 3.5 Manipulationsmodul - Bottom Laden der Bottom DLL in den Prozess des Skype-Clients Umleiten von Windows Sockets API Funktionen Verwendung der Windows Cryptography API Identifikation von zu schützenden Verbindungen Betriebsmodi der Bottom DLL Starten eines COM Servers im Skype-Prozess Kryptographiemodul - Kryptonite Wahl der externen Bibliotheken für AKE Die libotr Bibliothek Ableitung der Bottom-Sitzungsschlüssel Die fertige Anwendung Funktionale Einschränkungen und Fehler Zukünftige Entwicklung Fazit 78 Literaturverzeichnis 79 Abkürzungsverzeichnis 83 A Anhang 84 5

6 1. Einleitung 1 Einleitung 1.1 Überblick Mit dieser Arbeit wird erstmals eine überprüfbar sichere Verschlüsselungslösung für über Skype geführte Telefonate präsentiert. Nach einer einleitenden Beschreibung des Skype-Netzwerks und der Motivation des Vorhabens werden zwei grundsätzlich unterschiedliche Ansätze zur Erreichung dessen vorgestellt und evaluiert. Anschließend wird im dritten und mit Abstand größten Teil dieser Arbeit die Softwarelösung beschrieben, welche aufbauend auf einem der beiden zuvor beleuchteten Ansätze entwickelt wurde. Die fertige Anwendung, welche nur in Hinblick auf die Windows entwickelt wurde, lässt sich in ihrer grundlegenden Funktionsweise mit dem bekannten Programm PGP für den verschlüsselten Versand von Nachrichten vergleichen: Zwei kommunikationswillige Anwender verifizeren den kryptographischen Fingerprint des jeweils anderen und können im Anschluss sicher miteinander kommunizieren. 1.2 Vorwort Es ist wohl unbestritten, dass mit dem rasanten Vordringen des Internets in viele Bereiche des alltäglichen Lebens sich auch die Kommunikationsgewohnheiten der Menschen radikal gewandelt haben. Wurde das Internet lange Jahre im privaten Bereich vor allem zum Austausch von s verwendet, entstanden und entstehen im Zuge des als Web 2.0 Revolution bezeichneten Umbruchs im Netz völlig neue Kommunikationsformen wie zum Beispiel Kurznachrichtendienste oder soziale Netzwerke. Auch erfahren vermehrt klassische Kommunikationsmedien wie zum Beispiel das Telefon große Konkurrenz durch ihre webbasierten Pendants, die mit reizvollen neuen oder zumindest kostenlosen Funktionen aufwarten. Einer der wohl bekanntesten Vertreter dieser neuen Zunft der internetbasierten Kommunikationsdienste ist Skype. Es ist Instant-Messenger, VoIP-Client und Videotelefon in einem und konnte dank einfacher Benutzbarkeit und überragender Qualität seit dem Start im Jahre 2003 große Marktanteile von ehemals sehr populären Diensten wie ICQ oder AIM für sich gewinnen. Dabei beschränkt sich Skype schon lange nicht mehr nur auf den klassischen Windows-PC. Neben Varianten für OS X und Linux sind mittlerweile auch kostenlose Apps für alle gängigen Smartphones erhältlich. Die eigentliche Besonderheit von Skype liegt jedoch in der Struktur des zugrunde liegenden 6

7 1. Einleitung Netzwerks. Dieses ist, basierend auf der Technologie des mittlerweile eingestellten File-Sharing Dienstes Kazaa, voll auf sogenannte Peer-To-Peer Verbindungen - Direktverbindungen zwischen einzelnen Geräten - ausgelegt. So werden nur für den Vorgang der Anmeldung von Nutzern Server von Skype selbst bereitgestellt. Alle anderen für das Betreiben der verschiedenen Kerndienste notwendigen Aufgaben werden auf die Endgeräte der Nutzer ausgelagert. Diese spezielle Struktur gepaart mit der Tatsache, dass die Betreiberin Skype Ltd. allgemein bemüht ist technische Details über ihr Produkt geheimzuhalten, wirft natürlich Fragen zur Sicherheit der übertragenen Daten auf. Können geführte Telefonate abgehört werden? Wird irgendwo gespeichert wer mit wem telefoniert hat? Wie weiter unten dargelegt wird, hat Skype Ltd., welche nach einer mehrjährigen Zugehörigkeit zum Internetkonzern ebay und einer Phase der Eigenständigkeit kürzlich von Microsoft aufgekauft wurde, in jedem Fall technisch die Möglichkeit Gespräche zwischen zwei Parteien mitzuschneiden. Ob von dieser Möglichkeit auch tatsächlich Gebrauch gemacht wird, steht auf einem anderen Blatt. Unbestritten ist jedoch, dass zumindest Geheimdienste aus aller Welt ein großes Interesse daran haben, über Skype geführte Gespräche abzuhören [46]. Ob Berichte wie [2], die von gebotenen Milliardensummen für eine Hintertür sprechen, ernst zu nehmen sind, sei einmal dahingestellt. Dazu bleibt selbst für den Fall, dass Skype Ltd. als voll vertrauenswürdig und unbestechlich eingestuft werden kann, die durchaus reale Gefahr, dass die Sicherheit von Gesprächen im Skype-Netzwerk durch unbewusste Fehler bei der Implementierung kryptographischer Verfahren gefährdet ist. All diese Unsicherheiten wurden vom Autor bereits in [38] zum Anlass genommen, mögliche Verfahren zu beschreiben und zu evaluieren, mit denen Gespräche und andere Kommunikation über das Skype-Netzwerk abhörsicher geführt werden könnten. Aufbauend darauf wird hier nun eine konkrete und voll funktionsfähige Lösung präsentiert und eingehend beschrieben, die in den letzten Monaten im Rahmen dieser Arbeit programmiert wurde. Um die während der Designphase jener Lösung getroffenen Entscheidungen besser erörtern zu können, wird auch hier, wie bereits in [38] geschehen, im folgenden Kapitel zunächst ein Überblick über identifizierte mögliche Ansätze zur zusätzlichen Verschlüsselung von Kommunikationssitzungen über Skype gegeben. Bevor die genaue Zielstellung dieser Arbeit formuliert werden kann, sind hier zudem noch einige Aspekte des Skype-Netzwerks und der darin agierenden Parteien genauer zu betrachten. 7

8 1. Einleitung 1.3 Bereits vorhandene Abhörschutzmaßnahmen und Unsicherheiten In 2006 wurde auf der IT-Sicherheitskonferenz BlackHat in Las Vegas ein Vortrag von Ingenieuren des Unternehmens EADS gehalten [42], der einen tieferen Einblick in die damalige Version der Skype-Clients für Windows und Linux bot. Die Autoren unterstreichen die Vehemenz mit der der Skype-Client für Windows sich gegen jegliche Arten des Reverse Engineerings zur Wehr setzt. Trotzdem kommen sie in ihrem Vortrag zu dem Schluss, dass Kommunikation über Skype, geschützt durch die bekannten und bewährten Algorithmen AES und RSA, vor Abhörversuchen dritter sicher sei. Jedoch weisen sie auch darauf hin, dass das Unternehmen Skype Ltd. als Betreiberin der notwendigerweise vertrauenswürdigen Certificate Authority (CA) des Dienstes sehr wohl zu sogenannten Man-In-The-Middle Attacken in der Lage ist. Das heißt, wenn das Unternehmen Skype Ltd. ein Interesse daran hat ein Gespräch zwischen zwei Skype-Clients abzuhören, dann ist es dazu auch fähig. Um den genauen Ablauf einer solchen Abhöraktion nachvollziehen zu können, ist es notwendig die grundlegenden Abläufe innerhalb des Skype-Netzwerks zu kennen. Diese werden in den folgenden Abschnitten beschrieben Aufbau des Skype-Netzwerks und grundlegende Abläufe Nach [42] verteilen sich sämtliche Akteure innerhalb des Skype-Netzwerks auf die Rollen Node, Supernode, Login Server sowie verschiedene weitere Servertypen 1. Während die ersten beiden für gewöhnlich von auf Nutzerendgeräten laufenden Skype-Clients eingenommen werden, werden alle anderen vermutlich ausschließlich von einer überschaubaren Anzahl von von Skype Ltd. betriebenen Servern ausgefüllt. Während Nodes normal mit dem Netzwerk verbundene Clients darstellen, handelt es sich bei Supernodes um ehemalige Nodes, die aufgrund der Erfüllung bestimmter Kriterien, wie zum Beispiel dem Vorhandensein einer besonders leistungsfähigen Internetanbindung, mit weiterreichenden Aufgaben innerhalb des Netzwerks bedacht wurden. Die wohl wichtigste dieser Aufgaben stellt das Vermitteln von Gesprächen dar. Will ein Skype- Client in seiner Funktion als Node mit einem anderen Node eine Kommunikationssitzung beginnen, so teilt er diesen Wunsch einem ihm bekannten Supernode mit. Ist der fragliche Node aktuell im Netzwerk angemeldet, so erhält der anfragende Node im Normalfall alle Informationen zurückgesandt, die nötig sind, um eine kryptographisch gesicherte Kommunikation mit dem gewünschten Node zu beginnen [42]. Supernodes stellen also eine Art Telefonbuch oder Vermittlungsstelle des Skype-Netzwerks dar. Die Übertragung von Daten zwischen Supernode und Node erfolgt dabei gesichert durch asymmetrische Kryptographie. 1 Im Rahmen dieser Arbeit wurde mit Hilfe von Reverse Engineering eine nicht notwendigerweise vollständige Liste der unterschiedlichen Servertypen innerhalb des Skype-Netzwerks aus dem Skype-Client für Windows gewonnen. Auf Seite 84 in Tabelle A.1 sind diese zusammen mit ihren fest kodierten IP-Adressen zu finden. 8

9 1. Einleitung Node Skype Ltd. Node Supernode P2P Verbindung Supernode Weitere Server Supernode Node Node Login Server Login Server Client Abbildung 1.1.: Schematischer Aufbau des Skype-Netzwerks nach [42] Hat ein Node die nötigen Daten für einen Verbindungsaufbau zu einem anderen Node erhalten, so wird zunächst versucht eine P2P Verbindung - also eine Direktverbindung - zwischen beiden aufzubauen. Gelingt dies aufgrund von Netzwerkbegebenheiten wie zum Beispiel bestimmten Firewalleinstellungen nicht, so kann die Hilfe eines dritten, von beiden Parteien erreichbaren, beliebigen Nodes in Anspruch genommen werden [24]. Dieser agiert dann im Stile eines von beiden Parteien sichtbaren Spiegels und leitet für die Kommunikation notwendige Netzwerkpakete weiter. Man spricht in diesem Zusammenhang auch von einem Relay Host. Bis hierhin funktioniert das Skype-Netzwerk ganz ohne Mitwirken von zentralen Einheiten rein auf P2P Basis. Als grundlegende zentrale Instanzen treten die Login Server nur beim Prozess der Anmeldung von Clients am Skype-Netzwerk auf. Um zu klären, warum diese Server die Grundlage der vertraulichen und authentischen Kommunikation innerhalb des Netzwerks sind und warum es in dem gegebenen Modell zwingend notwendig ist, dass diese Server von Skype Ltd. zentral betrieben werden, muss der Prozess der Anmeldung genauer betrachtet werden Der Anmeldevorgang im Netzwerk Die globalen IP-Adressen der Login Server sind in den verschiedenen Clients fest kodiert. Zudem gibt es eine von Skype Ltd. generierte Menge K RSA keypairs,skype von n RSA Schlüsselpaaren mit (key i,pub,skype, key i,priv,skype ) K RSA keypairs,skype und 0 i < n. Zumindest von einer ge- 9

10 1. Einleitung wissen Untermenge dieser Schlüsselpaare sind in jedem Skype-Client die öffentlichen Schlüssel key i,pub,skype ebenfalls fest kodiert. Will sich ein Nutzer nun im Skype-Netzwerk anmelden, so wird nach [42] folgender Vorgang angestoßen: Zunächst berechnet der Skype-Client ein frisches, nur für die anstehende Sitzung gültiges Paar aus öffentlichem Schlüssel keypub,u session und privatem Schlüssel keypriv,u session für RSA mit 1024 Bit langem Modulus. Zudem wird aus dem gegebenen Nutzernamen u zusammen mit dem eingegebenen Passwort p auf bestimmte Art und Weise ein Hashwert h berechnet. Dieser wird dann zusammen mit dem zuvor neu berechneten, eigenen öffentlichen Schlüssel unter Verwendung eines dem Client bekannten öffentlichen Schlüssels key l,pub,skype aus K RSA keypairs,skype asymmetrisch verschlüsselt und an einen Login Server gesandt. Da dieser natürlich in Kenntnis der geheimen Schlüssel aus K RSA keypairs,skype ist, kann der Login Server das erhaltene Datagramm mit Hilfe des passenden key l,priv,skype entschlüsseln. Anschließend überprüft der Login Server, ob der erhaltene Hashwert h mit dem für den angefragten Nutzernamen lokal gespeicherten Hashwert h identisch ist. Ist dies der Fall, so signiert der Login Server das Tupel (u, key session pub,u ) über einem geheimen Schlüssel key s,priv,skype aus K RSA keypairs,skype und reicht es, vermutlich zusammen mit der IP-Adresse und dem Netzwerkport unter denen der betreffende Client zu erreichen ist, an die im Netzwerk aktiven Supernodes weiter. Der Client ist damit erfolgreich am Skype-Netzwerk angemeldet und agiert von da an in diesem als gewöhnlicher Node mit der Möglichkeit Kommunikationssitzungen mit anderen Clients aufzubauen Sitzungsaufbau zwischen zwei angemeldeten Clients Wollen zwei Nodes u 1 und u 2 wie bereits oben beschrieben über eine P2P Verbindung miteinander kommunizieren, so erhalten sie von einer ihnen bekannten Supernode im Netzwerk jeweils das von einem Login Server signierte Tupel sign keyi,pub,skype (u i, keypub,u session i ) des anderen Node. Mit Hilfe der fest kodierten öffentlichen Schlüssel wird daraufhin auf beiden Seiten die Authentizität des empfangenen Tupels verifiziert. Bei Erfolg überprüfen beide Seiten in einem Challenge-Response Protokoll, ob die jeweils andere Seite tatsächlich im Besitz des passenden privaten Schlüssels key session priv,u i zu dem erhaltenen öffentlichen Schlüssel key session pub,u i Anders ausgedrückt: u 1 beweist u 2 direkt, dass er in Besitz von key session priv,u 1 ist. ist und beweist damit im selben Zug indirekt, dass er sich, vorausgesetzt die geheimen Schlüssel aus K RSA keypairs,skype sind nur den Login Servern bekannt, mit Hilfe eines gültigen Passworts zuvor am Netzwerk angemeldet hat und umgekehrt. Nach dieser Authentisierung bestimmen beide Seiten laut [42] sicher einen gemeinsamen Sitzungsschlüssel für symmetrische Verschlüsselung und kommunizieren fortan geschützt miteinander. 10

11 1. Einleitung Vertrauen im Skype-Netzwerk Die beschriebenen Vorgänge zwischen zwei Nodes beim Aufbau einer geschützten Kommunikationssitzung stellen einen Authenticated Key-Exchange (AKE) [40] dar, wobei die von Skype Ltd. betriebenen Login Server die Rolle der Certificate Authority übernehmen, indem diese die Korrektheit der an Passwörter gebundenen Identitäten der einzelnen Nodes mit ihrer Signatur der Tupel (u i, keypub,u session i ) bestätigen. Nach [40] ist eine vertrauenswürdige dritte Partei für einen AKE zwingend notwendig, sofern beide Parteien nicht bereits einen geheimen Schlüssel teilen und auch ansonsten nicht auf einen sicheren Kanal zurückgreifen können. Ungeachtet der Details der Abläufe innerhalb des Skype-Netzwerks, die sich unter Umständen seit der Veröffentlichung von [42] in 2006 auch wieder geändert haben könnten, müssen alle Sicherheitsannahmen innerhalb dieses Netzwerks also zwingend auf der Vertrauenswürdigkeit von bestimmten Instanzen, wie den Login Servern und der Sicherheit ihrer kryptographischen Primitiven und den entsprechenden geheimen Schlüsseln, fußen. Mit Hilfe der Login Server wird hier nach [45] eine Public-Key Infrastructure (PKI) mit einer einzelnen CA realisiert. In [45] werden solche PKIs mit einer einzelnen CA ( A single certificate authority ) als nicht zweckmäßig bezeichnet, weil es den Autoren als unwahrscheinlich erscheint, dass ein jeder bereit ist dieser zu vertrauen ( [...] it is highly unlikely for everyone to trust the same CA [...] the CA is a single point of failure for the entire system. ). Schlussendlich bedeutet dies, dass sich Sicherheitsziele wie Vertraulichkeit, Authentizität und Integrität dann verletzen lassen, wenn die Instanzen denen vertraut werden muss ein fehlerhaftes, fahrlässiges oder gar böswilliges Verhalten an den Tag legen. Wie Skype Ltd. entsprechend dem letzten Fall die Kommunikation zwischen zwei Clients durch einen Man-In-The-Middle Angriff zuverlässig und unbemerkt abhören und manipulieren könnte, wird im Folgenden nach [42] skizziert Man-In-The-Middle Angriff Als Man-In-The-Middle Angriff bezeichnet man gemeinhin das Abhören oder Manipulieren von Kommunikation zwischen zwei Parteien A und B durch eine dritte Partei C, einem Angreifer. Dieser Angreifer fängt dabei alle oder einen Teil der Nachrichten zwischen A und B ab und leitet diese nach der eigenen Auswertung für gewöhnlich, möglicherweise manipuliert, weiter. Nimmt man nun für den Fall des oben beschriebenen Sitzungsaufbaus zwischen zwei Clients einen Angreifer an, der zwar sämtliche Netzwerkpakete zwischen A und B manipulieren und lesen kann, der jedoch keine Gewalt über die Login Server hat, so wird dieser Angreifer trotz seiner Fähigkeiten unter der Annahme, dass die verwendeten kryptographischen Primitiven ausreichend stark sind, nicht in der Lage sein integrale Sicherheitsziele unbemerkt zu verletzen. 11

12 1. Einleitung Anders verhält es sich jedoch für das Unternehmen Skype Ltd. selbst oder einen außenstehenden Angreifer der die Certificate Authority des Netzwerks kontrolliert. Ihm ist es mit Hilfe der privaten Schlüssel der Login Server möglich, das oben beschriebene Datagramm sign keyi,pub,skype (u i, keypub,u session i ) zu fälschen und dort einen öffentlichen Schlüssel keypub,u session i einzutragen, zu dem ihm der entsprechende private Schlüssel bekannt ist. So ein gefälschtes Datagramm würde der Angreifer für jeden abzuhörenden Client in den Datenbanken der Supernodes ablegen. Versucht in diesem Szenario dann beispielsweise A ein Telefongespräch mit B aufzubauen, so gibt sich der Angreifer C gegenüber A als Teilnehmer B aus und umgekehrt, ohne dass dies die beteiligten Parteien registrieren könnten. Möglich ist dies dadurch, dass C sämtliche über keypub,b session verschlüsselten Pakete von A an B öffnet und vor dem Weiterleiten diese über dem tatsächlichen öffentlichen Schlüssel keypub,b session wieder verschlüsselt. Entsprechend verfährt er in die entgegengesetzte Richtung. Für den wahrscheinlichen Fall, dass der Angreifer nicht sämtliche Pakete zwischen A und B abfangen kann, könnte er neben den gefälschten Datagrammen auch IP-Adressen unter seiner Kontrolle anstelle der eigentlichen IP-Adressen von A und B in die Supernodes eintragen lassen. Alternativ könnte er womöglich auch auf einem unbestimmten Weg einen Node unter seiner Kontrolle zum Relay Host für das anstehende Gespräch zwischen A und B machen. 1.4 Zielstellung Die Sicherheit von Verbindungen innerhalb des Skype-Netzwerks hängt unmittelbar von Skype Ltd. und der Sicherheit der von ihr betriebenen Server ab. Abgesehen von der Ausnahme des hauseigenen Audio-Codecs SILK [31] und kleinerer Beispielprogramme, ist sämtliche Software von Skype Ltd. nicht quelloffen. Da sich zudem die verschiedenen aus dem Internet beziehbaren Client-Versionen aktiv gegen Versuche des Reverse Engineerings zur Wehr setzen, bleibt den Nutzern nicht viel, als auch eine sichere Implementierung der verwendeten kryptographischen Algorithmen und Sicherheitsmechanismen wohlwollend anzunehmen. Durch die hohe Marktdurchdringung 2 und die bis heute unerreichte Qualität des Dienstes, sowohl in Hinsicht auf die allgemeine Qualität von Sprachverbindungen als auch auf die beeindruckende Fähigkeit von Skype auch schwierigste Netzwerktopologien zu überbrücken, dürfte sich jedoch aufgrund dieser Unsicherheiten kaum ein Anwender dazu durchringen können zu einem überprüfbareren Dienst mit vergleichbarem Angebot zu wechseln. Daher ist es das erklärte Ziel dieser Arbeit, das bestehende Angebot von Skype für den Anwender nachvollziehbar und überprüfbar sicher zu machen. So soll eine quelloffene Anwendung entwickelt werden, die die grundsätzliche Nutzererfahrung während 2 Im Januar 2011 waren laut Skype Ltd. zum ersten mal mehr als 28 Millionen Nutzer gleichzeitig im Netzwerk angemeldet [36]. 12

13 1. Einleitung des Benutzens von Skype so wenig wie möglich ändert und nur an den entscheidenden Stellen eingreift. Schon allein aufgrund des sehr großen Aufwands der dafür nötig wäre, soll keine eigenständige Client Software entwickelt werden. Stattdessen sollen bereits existierende, offizielle Clients in ihrem Verhalten gesteuert und funktional erweitert werden. Dadurch kann sich jedoch bei den Sicherheitsannahmen keine komplette Unabhängigkeit von Skype Ltd. ergeben. Den betreffenden Clients von Skype Ltd. wäre weiterhin zumindest so weit zu vertrauen, als dass diese nicht aktiv vertrauliche Daten wie zum Beispiel kryptographische Schlüssel von einem Endgerät kopieren oder bewusst kryptographische Berechnungen stören. Von außen betrachtet sollen sich Skype-Clients mit einer Verschlüsselungserweiterung in ihrem Verhalten nicht merklich von herkömmlichen Skype-Clients unterscheiden. Es soll möglichst keine Auswirkungen auf das Skype-Netzwerk geben. Diese Anforderungen sind alleine schon wichtig, um eine Konfrontation mit Skype Ltd. zu vermeiden, zudem kann so die Privatsphäre der Anwender geschützt werden. Die zu entwickelnde Anwendung soll einen AKE ohne die Notwendigkeit einer zentralen CA ermöglichen und darauf aufbauend zumindest die sichere Übertragung von Gesprächsdaten zwischen zwei Clients durchsetzen. Wie bereits weiter oben erwähnt, ist nach [40] ein AKE nur dann ohne eine vertrauenswürdige dritte Partei möglich, wenn ein sicherer Kanal zu Verfügung steht. Im Falle von modernen Public-Key basierten AKE Protokollen beschränkt sich die Nutzung eines solchen sicheren Kanals häufig auf den einmaligen und unverfälschten Austausch von so genannten Fingerprints. Ist solch ein kryptographischer Fingerabdruck einmal lokal für einen Kontakt gespeichert, so lässt sich dieser in jedem folgenden AKE Protokolllauf dazu verwenden die Identität des Gegenübers eindeutig zu verifizieren. Vorausgesetzt natürlich, der zu dem Fingerprint gehörige Private-Key ist nur diesem Gegenüber bekannt. Praktisch gestaltet sich der hinreichend sichere Austausch weniger kompliziert als es sich vielleicht zunächst vermuten lässt. So muss nicht etwa sichergestellt werden, dass der fragliche Fingerprint geheim bleibt, sondern nur, dass er unmanipuliert seinen Empfänger erreicht. In den meisten Fällen dürfte es also genügen die im Regelfall nur einige Dutzend Zahlen und Buchstaben langen Zeichenketten einander am Festnetztelefon vorzulesen oder auf der eigenen Homepage zu veröffentlichen, wie es beispielsweise im Falle von sicherer Kommunikation mittels PGP üblich ist. Auch könnte zum Beispiel ganz allgemein auf die bereits für PGP existierenden Landschaft von öffentlichen Schlüsselservern zurückgegriffen werden. Bei den in den nächsten Kapiteln folgenden Ausführungen zur konkreten Implementierung einer solchen Erweiterung für Skype-Clients wird sich auf Microsoft Windows 7 und den entsprechenden Skype-Client betreffende Aspekte beschränkt. Dies ist sowohl der hohen Verbreitung dieses Betriebssystems als auch den Vorlieben des Autors geschuldet. 13

14 1. Einleitung Die letztlich zu präsentierende Lösung soll möglichst modular aufgebaut sein, sodass sich einfach beispielsweise verwendete kryptographische Bibliotheken oder einzelne Protokolle austauschen lassen Vergleich der Vertrauensmodelle Notwendige Annahme Skype Skype mit eigener Erweiterung Skype-Clients sind nicht bösartig X X Endgerät ist nicht kompromittiert X X Kryptographische Maßnahmen von Skype Ltd. sind sicher X - Skype CA ist sicher X - Skype CA ist vertrauenswürdig X - Frei wählbare kryptographische Maßnahmen sind sicher - X Zusätzliche quelloffene Software ist sicher - X Zusätzlicher integerer Kanal verfügbar - X (Übertragung von Fingerprints) Tabelle 1.1.: Notwendiges Vertrauen für eine sichere Kommunikation über Skype Da die Eckpfeiler der zu entwickelnden Anwendung gesteckt sind, lässt sich ohne Kenntnis der genauen Details der eigenen Implementierung bereits ein Vergleich zwischen dem Vertrauensmodell dieser und dem der herkömmlichen Skype-Clients anstellen. Ein solcher Vergleich ist in Tabelle 1.1 abgebildet. Erklärungsbedürftig ist dort womöglich die Zeile für den Eintrag Endgerät ist nicht kompromittiert. Diese besagt, dass die Sicherheit bei beiden Varianten zwingend voraussetzt, dass das verwendete Endgerät nicht unter der unbemerkten Kontrolle eines Angreifers steht oder von einem Virus befallen ist. Dass solch eine Gefahr zumindest für Windows-PCs nicht nur theoretischer Natur ist, zeigt die Tatsache, dass der Firma Symantec ein Virus bekannt ist, welcher die unverschlüsselten Audioströme zwischen Skype-Client und Soundkarte abgreift und speichert [4]. Auch ist unter [39] der komplette Quellcode eines Programms mit identischer Funktionalität erhältlich, das obendrein noch sämtliche gesammelten Sprachdaten an einen beliebigen Rechner im Internet versendet. Auch wenn in beiden Spalten der Vergleichstabelle fünf notwendige Grundannahmen identifiziert werden konnten, sind die Annahmen der linken Spalte in jedem Fall als erheblich stärker und schwerer zu überprüfen einzustufen. Dies wird zur Motivation genommen, in den nun anschließenden Kapiteln den Weg zu einer Anwendung mit den Annahmen der rechten Spalte darzulegen. 14

15 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen 2 Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen Das besagte Ziel dieser Arbeit ist es, den bereits vorhandenen Skype-Client für Windows so zu beeinflussen, dass ein von Skype Ltd. unabhängiger Authenticated Key-Exchange möglich wird. Aufbauend auf diesem soll dann für die Dauer von Gesprächen und womöglich anderer Kommunikation, zusätzlich zur Kryptographieschicht des Protokolls des Skype-Netzwerks, eine weitere, transparente und kontrollierbare symmetrische Verschlüsselungsschicht aufgebaut werden. Dabei soll die Benutzererfahrung und die Qualität des Dienstes selber nicht merklich beeinflusst werden. Ebenso sollen für das Anwenden der Lösung keine System- oder Administrationsrechte nötig sein, sodass sie beispielsweise auch in Internet-Cafés anwendbar bleibt. Die möglichen Ansätze und die sich ergebenden Schwierigkeiten werden in diesem Kapitel behandelt. Dabei geht es vor allem darum, die Möglichkeiten der Implementierung der symmetrischen Verschlüsselungsschicht auszuloten. Lässt sich diese erst einmal realisieren, kann der ebenfalls geforderte AKE leicht hinzugefügt werden. Das Hauptaugenmerk liegt auf der Sicherung eines Telefonats zwischen zwei Parteien. Andere über Skype mögliche Kommunikationsformen wie beispielsweise Gruppenvideotelefonate bleiben erst einmal außen vor. Sofern nicht anders angemerkt, beziehen sich sämtliche Aussagen in den folgenden Abschnitten auf die Windows Variante des Skype-Clients in der zu Beginn der Niederschrift dieser Arbeit aktuellen Version Spezielle Schwierigkeiten bei der Verschlüsselung von Skype-Verbindungen Als erste Idee für die mögliche Realisierung eines Vorhabens wie dem beschriebenen ergibt sich vermutlich der Weg über ein mögliches Plugin-Interface oder Ähnliches, mit Hilfe dessen Sprachdaten nach der Verarbeitung durch einen Audio-Codec und vor dem Versenden über das Netzwerk abgefangen und verschlüsselt werden könnten. Im Falle von Skype werden jedoch seit einiger Zeit keine Plugins mehr unterstützt und die offizielle API des Programms erlaubt kaum mehr als die Fernsteuerung der Benutzeroberfläche [32]. Nach Aussagen von Skype Ltd. ist sie vornehmlich dazu gedacht, Drittherstellern die Möglichkeit der Entwicklung von speziell an Skype angepasster Hardware zu geben. Dadurch, dass der Skype-Client sich wie erwähnt aggressiv gegen Versuche des Reverse Engineerings wehrt und als nur eine einzelne monolithische.exe Datei von über 20 MB ausgeliefert 15

16 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen wird, bleibt kaum mehr, als das Programm zunächst in weiten Teilen als Black Box zu betrachten. Grundsätzlich sei zudem angemerkt, dass eine rein auf Reverse Engineering beruhende Lösung, die Teile der ursprünglichen Programmdatei des Clients manipuliert - also ein auf Patching beruhender Ansatz - mit großer Wahrscheinlichkeit nicht den gewünschten Sicherheitsgewinn liefern könnte. Denn angenommen man fände beispielsweise jene Adressen im Speicher, an denen der Client zur Laufzeit symmetrische Sitzungsschlüssel ablegt und würde diese ebenfalls zur Laufzeit durch sichere Schlüssel austauschen, so bliebe in jedem Fall die Unsicherheit, dass der Client unter gewissen Umständen während einer Sitzung auf die Verwendung anderer Schlüssel umschwenken könnte, die beim bis dahin vollzogenen Prozess der Analyse nicht entdeckt wurden. Auch müsste jede neu erscheinende Version eingehend und aufwändig auf neu hinzugekommene Funktionalität hin überprüft werden. Endgerät A Endgerät B Skype Clients und Netzwerk Black Box NIC NIC Abbildung 2.1.: Betrachtung von Skype als Black Box Nach Einschätzung des Autors ergeben sich unter diesen Vorüberlegungen genau zwei Ansatzpunkte für eine zusätzliche Verschlüsselungsschicht für Gespräche über Skype: Da Skype über keine eigenen Treiber verfügt, ist es darauf angewiesen mit dem Windows Betriebssystem zu kommunizieren, um 1.) Audiodaten vom Mikrofon des PCs zu lesen und Audiodaten über die Soundkarte auszugeben und 2.) allgemein Daten über das Netzwerk zu verschicken (siehe auch Abbildung 2.1). An diesen Schnittstellen ist es, ohne genauere Kenntnis der inneren Funktionsweisen von Skype zu haben, möglich, Daten abzugreifen und zu manipulieren. Diese beiden Ansätze werden im Folgenden mit Prä Audio-Codec Verschlüsselung und Netzwerkpaketverschlüsselung bezeichnet. 2.2 Prä Audio-Codec Verschlüsselung Als erster der beiden identifizierten Ansätze soll hier die Möglichkeit diskutiert werden, Audiodaten vor dem Eingang in den Skype-Client zu verschlüsseln und nach der Ausgabe aus diesem 16

17 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen (und vor der Ausgabe über die Lautsprecher) wieder zu entschlüsseln. Die allergrößte Problematik bei diesem Ansatz ergibt sich durch die Tatsache, dass Skype selbstverständlich Audiodaten vor dem Versenden über das Netzwerk verlustbehaftet komprimiert und nach deren Empfang diese wieder entsprechend dekomprimiert. Man benötigt also ein Verschlüsselungsverfahren, dass zum einen sicher ist und zum anderen ein solches Komprimier- /Dekomprimierglied zuverlässig verkraften kann. Ein solches Verfahren konnte trotz intensiver Recherche nicht gefunden werden und es darf ruhig bezweifelt werden, ob ein solches überhaupt technisch realisierbar ist. Im Falle von Skype wird die Situation dadurch erschwert, dass seit dem Jahre 2009 ein komplexer, auf Sprache optimierter und in mehrjähriger interner Entwicklungsarbeit bei Skype Ltd. entstandener Audio-Codec namens SILK zum Einsatz kommt [31]. Der Programmcode für diesen Codec ist allerdings öffentlich zugänglich und ließe sich folglich einfach analysieren. Stellt man die hier ungelöste Problematik der Verschlüsselung eines noch zu komprimierenden Audiostroms hinten an, so stellt sich bei der in diesem Abschnitt behandelten Thematik als nächstes die Frage, auf welche Art die Audiodaten am besten abgegriffen werden. Die naheliegendste Herangehensweise für so ein Vorhaben ist vermutlich das Programmieren eines speziellen Treibers der sich gegenüber dem Skype-Client als Soundkarte mit Mikrofoneingang und Lautsprecherausgang ausgibt. Dieser Treiber würde als eine Art Vermittler zwischen der realen Soundkarte des Systems und dem Skype-Client agieren und zunächst einfach sämtliche Daten und Anfragen weiterreichen. Zur Verschlüsselung eines Telefonats würden dann alle von der realen Soundkarte kommenden Signale vor der Weiterleitung verschlüsselt und entsprechend wiederum sämtliche von Skype kommenden Audiosignale vor der Weitergabe an die Soundkarte entschlüsselt. Auch wenn dieser Ansatz auf den ersten Blick als durchaus praktikabel erscheinen mag, so erweist er sich bei näherer Betrachtung als äußerst unpraktisch. So ist das Programmieren eines Treibers eine komplizierte und teure Aufgabe, die zudem sehr plattformspezifisch ist. Selbst für diverse unterschiedliche Varianten des Windows Betriebssystems 1 müssten hier eigenständige Versionen entwickelt werden. Zudem wäre es für solch eine, gewissermaßen in Software implementierte Soundkarte, wohl unmöglich zwischen tatsächlichen Sprachdaten und anderen Audioausgaben des Skype-Clients zu unterscheiden, was zu erheblichen Problemen bei der Synchronisation der Entschlüsselung führen dürfte. Eine deutlich günstigere und portablere technische Alternative für die Manipulation von einund ausgehenden Audioströmen stellt der Skype-Client selbst bereit. So erlaubt die bereits erwähnte öffentliche API des Skype-Clients unter anderem die Umleitung von sämtlichen Au- 1 Windows 7 32 Bit, Windows XP 32 Bit und Windows 7 64 Bit sind beispielsweise alle auf Treiber-Ebene inkompatibel, letzteres verlangt zudem nach offiziell signierten Treibern. 17

18 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen dioströmen über frei wählbare lokale Netzwerkports oder Dateien. Genauere Erläuterungen dazu und zur API der Skype-Clients im Allgemeinen werden im Folgenden gegeben Skype API Die Skype-Clients für unterschiedliche Plattformen stellen über eine API Funktionalität für eine automatische, textbasierte Bedienung bereit [32]. So lassen sich beispielsweise mit dem Kommando SEARCH FRIENDS alle gespeicherten Kontakte für den aktuell eingeloggten Account erfragen. Mit dem Befehl CALL friend0 ließe sich im Anschluss ein Anruf zu dem Kontakt mit der Kennung friend0 aufbauen. Geantwortet wird von den Skype-Clients ebenfalls in textbasierter Form. Interessant für das gegebene Vorhaben der Manipulation von ein- und ausgehenden Audioströmen sind primär die folgenden drei Befehle [32]: ALTER CALL <id> SET_INPUT SOUNDCARD="default" PORT="port_no" FILE="FILE_LOCATION" ALTER CALL <id> SET_OUTPUT SOUNDCARD="default" PORT="port_no" FILE="FILE_LOCATION" ALTER CALL <id> SET_CAPTURE_MIC PORT="port_no" FILE="FILE_LOCATION" Mit diesen ist es möglich, für ein bestimmtes Telefonat die Audioein- und ausgänge des Skype- Clients sowie den Mikrofoneingang des Computers auf eine beliebige Soundkarte, Datei oder einen Netzwerkport zu setzen. Dies erlaubt es, die Audioströme so über bestimmte Netzwerkports umzuleiten, dass Audiodaten einfach abgegriffen und manipuliert werden können - ohne dass das Programmieren eines Treibers nötig wäre. Eine Skizze des Ansatzes ist in Abbildung 2.2 zu sehen. Es bleibt die Frage, auf welchem Wege solche Befehle und die entsprechenden Antworten mit einem Skype-Client ausgetauscht werden. Unter Windows erfolgt dies über so genannte Window Messages. Diese Art der Kommunikation ist für Anwendungen wie der gegebenen eher ungewöhnlich und ist wohl der Tatsache geschuldet, dass Skype Ltd. prinzipiell versucht seine Client-Software abzuschotten. Skype Ltd. selbst stellt für Windows ein Kommandozeilenprogramm namens msgapitest als Programmierbeispiel bereit, welches zur händischen, textbasierten Kommunikation mit einem Sykpe-Client verwendet werden kann [32]. Ein Blick in den in der Programmiersprache C vorliegenden Quellcode des Programms offenbart, dass das direkte Arbeiten mit der nativen Windows 18

19 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen Port X Mic-Out Enc k Port Y Audio-In Skype-Client Port Z Dec k Audio-Out Abbildung 2.2.: Umleitung von Audioströmen des Skype-Clients und des Mikrofons über Netzwerk- Ports API zur Übertragung von Kommandos an einen Skype-Client und zum Empfang der entsprechenden Antworten durchaus aufwändig ist. Für Windows, Linux und OS X liefert das Open-Source Projekt Skype4Py als Alternative eine objekt- und ereignisorientierte Kapselung für die Kommunikation mit Skype-Clients, die sich auf den drei unterstützten Plattformen einheitlich und komfortabel mit der Skriptsprache Python ansprechen lässt [1]. Skype4Py wurde im Rahmen dieser Arbeit mehrfach für Tests und das Erstellen von Prototypen eingesetzt. Das Skript in Listing A.1 auf Seite 84 demonstriert exemplarisch, wie mit Hilfe von Skype4Py und wenigen Zeilen Programmcode in der Sprache Python ein Telefonat über das Skype- Netzwerk aufgebaut werden kann, wobei die Audioströme wie in Abbildung 2.2 über Netzwerkports umgeleitet werden. In dem gegebenen Beispielskript werden die Platzhalterfunktionen encrypt() und decrypt() verwendet, durch die sämtliche Audiodaten vor der Weiterleitung vom Mikrofon an den Client bzw. vom Client zur Audioausgabe durchgeleitet werden. Sollte ein sicheres Verschlüsselungsverfahren speziell für den Codec SILK gefunden werden, so müsste dies nur in der Funktionen encrypt() und decrypt() implementiert werden, um die grundlegende Fragestellung dieser Arbeit zu lösen. Neben Skype4Py stellt Skype Ltd. selbst für Windows ein COM-Komponente 2 namens Skype4COM bereit, die ebenfalls die Kommunikation mit einem Skype-Client über ein objekt- und ereignisorientiertes Interface ermöglicht [32]. Aufgrund dessen, dass sich ActiveX Komponenten 2 Bei COM handelt es sich um einen objektorientierten Standard für Interfaces, der vor allem auf Windows- Plattformen Verwendung findet. Auf COM und seine Rolle in dieser Arbeit wird in Abschnitt 3.3 näher eingegangen. 19

20 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen sehr gut mit.net basierten Programmiersprachen wie C# verwenden lassen, fiel bei der weiter unten beschriebenen, endgültigen Implementierungsarbeit die Wahl auf Skype4COM Bewertung Seit der Anfertigung von [38] konnten zu diesem Ansatz keine neuen Erkenntnisse gewonnen werden. So ist dieser Abschnitt auch eher als eine konzentriertere Wiederholung der dort bereits präsentierten Ergebnisse zu sehen, in der abermals gezeigt wurde, dass es ohne Verwendung von speziellen Treibern mit Hilfe der offiziellen Skype API plattformunabhängig realisierbar ist, die ein- und ausgehenden Audioströme eines Skype-Clients abzufangen und zu manipulieren. Weiterhin ungeklärt bleibt jedoch, wie und überhaupt ob es möglich ist, Audiodaten verlässlich und sicher zu verschlüsseln, die einen verlustbehafteten Audio-Codec durchlaufen. Diese grundlegende Problematik verhindert bis auf Weiteres die Verfolgung dieses Ansatzes. Der große Vorteil dieses Verfahrens wäre in jedem Fall die Tatsache, dass die eigentlichen funktionalen Abläufe innerhalb der Client-Software komplett unangetastet blieben, woraus sich eine sehr geringe Fehleranfälligkeit ergäbe. So könnten durch solch einen High Level Ansatz die Eigenheiten des Skype-Netzwerks komplett außer Acht gelassen werden. Zu guter Letzt gesellte sich als Pluspunkt noch die völlige rechtliche Unbedenklichkeit des Ansatzes hinzu, da keinerlei Manipulationen der Programmdatei oder Maßnahmen innerhalb des laufenden Prozesses des Clients durchgeführt werden müssten. 2.3 Netzwerkpaketverschlüsselung Unter der gegebenen Vorgabe der Betrachtung des Skype-Netzwerks und der darin verbundenen Clients als einer gesamtheitlichen Black Box, kann sich neben der im vorangegangenen Abschnitt beschriebenen Prä-Audio-Codec-Verschlüsselung nur ein einziger weiterer Ansatz zur Realisierung einer zusätzlichen Verschlüsselungsschicht ergeben: Die Verschlüsselung von zu versendenden Netzwerkpaketen vor deren tatsächlicher Versendung und umgekehrt die Entschlüsselung von erhaltenen Netzwerkpaketen vor der Weiterreichung an den laufenden Skype- Client. Nach dem Schema in Abbildung 2.1 wird in diesem Abschnitt, abstrakt gesprochen, die Möglichkeit der Manipulation der Datenströme zwischen Skype-Client und Netzwerkkarte betrachtet. Gewissermaßen soll also nach Wegen gesucht werden, sämtlichen Netzwerkverkehr des Skype-Clients über einen transparenten, lokalen Proxy-Server bis hierhin ansonsten noch unbestimmter Ausprägung umzuleiten. Dabei soll die Problematik der Identifizierung der unterschiedlichen Netzwerkpakete zunächst außer Acht gelassen werden. Bis auf weiteres wird davon 20

21 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen ausgegangen, es existiere bereits ein Verfahren, welches die ein- und ausgehenden Netzwerkpakete eines Skype-Clients eindeutig verschiedenen Kommunikationssitzungen zuordnet. Eine tatsächliche Lösung für dieses integrale Problem wird in Abschnitt präsentiert. Ein weiteres grundlegendes Problem dieses Ansatzes stellen indirekte Verbindungen über Relay Hosts dar. Ohne eine genaue Kenntnis des Aufbaus unterschiedlicher Skype-Pakete und Protokolle dürfte es kaum möglich sein ausgehende Pakete so zu verschlüsseln, dass diese kein Informationsleck darstellen, jedoch von dem betreffenden Relay Host als gültig erkannt und weitergeleitet werden. Diese Problematik wird in dieser Arbeit nicht mehr gelöst, jedoch an gegebenen Stellen noch einmal aufgegriffen werden. Anders als bei der Manipulation von Audioströmen, erweist sich die Skype API beim hier zu betrachtenden alternativen Ansatz als wenig hilfreich. So ist es mit keiner der öffentlich bereitgestellten Funktionen möglich das Verhalten eines Skype-Clients in Bezug auf seine Netzwerkverbindungen zu beeinflussen. Über den Dialog Optionen lässt sich jedoch zur Laufzeit ein Proxy-Server manuell eintragen, über den sämtlicher Netzwerkverkehr abgewickelt werden soll. Diese durchaus vielversprechende Funktion wird im Folgenden weiter begutachtet Direkte Eintragung eines lokalen Proxy-Server Wird zur Laufzeit des Skype-Clients im Dialog für Optionen ein Proxy-Server mit Host und Port eingetragen 3, so werden diese Eingaben vom Skype-Client in der Datei shared.xml im Ordner für Anwendungsdaten des aktuellen Nutzers gespeichert. Anschließend wird der Nutzer des Clients aufgefordert, diesen zu beenden und erneut zu starten, um die getätigten Änderungen wirksam werden zu lassen. Dies ist jedoch nur möglich, sofern nicht bereits ein Proxy-Server für Skype in der Registry des betreffenden Systems unter der Verwendung von Administrationsrechten eingetragen wurde 4. Widersprechen sich die Eintragungen in einer Konfigurationsdatei wie shared.xml und der Registry, so gewichtet ein Skype-Client letzteres immer höher. Es wäre also möglich ein Programm zu entwickeln, welches sich selbstständig als Proxy-Server für den auf dem betreffenden System installierten Skype-Client in die Datei shared.xml einträgt. Typischerweise würde solch ein Programm als Host die loopback IP-Adresse wählen und anschließend selbst auf dem angegebenen Port auf eine Verbindung des Skype-Clients warten, um nach dem Erfolgen dieser die geforderte zusätzliche Verschlüsselungsschicht für ausund eingehende Netzwerkpakete zu realisieren. 3 Optional lässt sich zudem noch zwischen den beiden Protokollen SOCKS5 und HTTPS wählen. Daneben kann noch ein Nutzername/Passwort Paar zur Authentisierung eingetragen werden. 4 Skype Ltd. stellt für Systemadministratoren ein so genanntes Administrative Template für Gruppenrichtlinien (GPO) bereit [29]. Mit Hilfe dessen lassen sich bestimmte Verhaltensrichtlinien für Skype-Clients innerhalb der Registry auf für mehrere Computer setzen. Neben dem Festlegen eines Proxy-Servers werden auch andere, nicht über die Benutzeroberfläche verfügbare Optionen angeboten, wie beispielsweise der Run in memory-only Mode welcher den Skype-Client daran hindert auf das Dateisystem zuzugreifen. 21

22 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen Obwohl dieser Ansatz als sehr praktikabel und gut implementierbar erscheinen mag, wurde er während der Planungsphase dieser Arbeit wieder verworfen, weil einige Nachteile existieren die, bei den weiter unten besprochenen Ansätzen so nicht zu finden sind. So müsste das als Proxy-Server agierende Programm entweder permanent auf dem betreffenden System laufen oder dafür Sorge tragen, dass die Datei shared.xml ständig aktuell ist. Auch wäre es nicht möglich ohne Administrationsrechte einen bereits in der Registry eingetragenen Proxy-Server zu ersetzen. Auf Systemen mit einer restriktiv eingestellten Firewall wäre es zudem unter Umständen ebenfalls nicht möglich ohne Administrationsrechte die notwendigen Netzwerkports für den lokalen Proxy-Server zu öffnen. Aufgrund dieser Limitierungen wird im Folgenden ein weiteres Verfahren beschrieben, welches schließlich auch für die konkrete Implementierung gewählt wurde. Dieses mag auf den ersten Blick komplizierter wirken als das soeben vorgestellte, jedoch verfügt es über einige signifikante Vorteile, welche den Mehraufwand lohnend machen Umleitung von Windows Sockets API Aufrufen Verfügt eine Anwendung über keinen eigenen Treiber, so ist es dieser in aller Regel nicht möglich direkt mit den Endgeräten eines Computers zu kommunizieren. Stattdessen stellen moderne Betriebssysteme im Allgemeinen standardisierte Schnittstellen bereit, über welche Programme beispielsweise Audiodateien abspielen, Bewegungen der Computermaus abfragen oder eben Netzwerkpakete verschicken lassen können ohne tatsächlich Kenntnis über die dahinterstehenden Hardwarekomponenten zu haben. Das Windows Betriebssystem stellt Programmen für derlei und andere Aufgaben 5 die so genannte Windows API bereit. Aus Anwendungssicht stellt sich diese Windows API als Sammlung von Dynamic Link Library (DLL) dar, welche jeweils eine Menge von Funktionen verfügbar machen, die ein bestimmtes Gebiet betreffen. So exportiert die DLL Kernel32.dll alle grundlegenden Funktionen des Systems, wie zum Beispiel Dateisystemzugriffe oder das Erstellen von neuen Prozessen, während zum Beispiel User32.dll vornehmlich die Erstellung von GUI-Elementen über Funktionen wie MessageBoxA() ermöglicht. Interessant für das gegebene Vorhaben ist die DLL Ws2_32.dll. Diese stellt sämtliche, die dritte und vierte Schicht des ISO/OSI-Modells [22] betreffende Netzwerkfunktionalität bereit. Abgesehen von der Möglichkeit der direkten Kommunikation mit einschlägigen Systemtreibern wie Afd.sys oder Tcpip.sys [20], gibt es nach Erkenntnissen des Autors für Anwendungen unter Windows keinen anderen Weg neben der Verwendung dieser DLL um auf dem IP-Protokoll 5 Tatsächlich wird die Windows API nicht nur für die abstrahierte Kommunikation mit Endgeräten verwendet. Stattdessen wird über diese die gesamte Bandbreite der Funktionen des Betriebssystem den im Userland laufenden Anwendungen zur Verfügung gestellt. Dies beinhaltet zum Beispiel auch sämtliche Funktionen zum Erstellen von GUI-Elementen oder den Heap einer Anwendung betreffende Funktionen. 22

23 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen basierende Netzwerkverbindungen - beispielsweise TCP oder UDP Protokollsitzungen - aufzubauen. Es sei angemerkt, dass die direkte Kommunikation mit Systemtreibern zur Übertragung von Netzwerkpaketen äußerst unüblich und aufwändig ist (zum Beispiel können Unterschiede zwischen einzelnen Windows Versionen existieren) und hier nur der Vollständigkeit halber erwähnt wird. Soll ein Programm über das Internet kommunizieren, so kommt es also im Allgemeinen schlichtweg nicht umhin, die DLL Ws2_32.dll zu verwenden. Folglich müssen auch sämtliche Netzwerkpakete des Skype-Clients Funktionen dieser DLL passieren. Damit ein Programm von einer DLL bereitgestellte Funktionen aufrufen kann, muss die betreffende DLL zur Laufzeit in den Adressraum jenes Programmes geladen werden. Folglich ist im Adressraum sämtlicher Programme, die über Netzwerkfunktionalität der Schichten drei oder vier verfügen, die Datei Ws2_32.dll zur Laufzeit zumindest zu einem bestimmten Zeitpunkt vorzufinden. Um beispielsweise ein UDP-Paket zu versenden, muss so ein Programm dann nur noch die Funktion send() innerhalb von Ws2_32.dll mit den entsprechenden Parametern aufrufen [12]. Genauso wie hier Skype-Prozess Skype-Client Kernel32.dll, User32.dll,... Black Box socket( ) send( ) WSASendTo( ) recv( )... Ws2_32.dll NIC Abbildung 2.3.: Skype-Prozess mit geladenen System-Dlls allgemein rudimentär beschrieben, stellen sich auch die Abläufe innerhalb des Prozesses des Skype-Clients dar: Schlussendlich wandert sämtlicher ein- und ausgehender Netzwerkverkehr des Skype-Clients durch wenige von Ws2_32.dll bereitgestellter Funktionen (siehe auch Abbildung 2.3). Konkret werden folgende API-Funktionen für das Senden und Empfangen von Netzwerkpaketen aufgerufen: send() (TCP) recv() (TCP) sendto() (UDP) recvfrom() (UDP) 23

24 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen Offensichtlich genügt es, diese Funktionen aus Ws2_32.dll innerhalb des Prozesses des Skype-Clients zu ersetzen oder hinreichend zu modifizieren, um die geforderte Kontrolle über den Netzwerkverkehr zu erhalten. Um solch einen gewissermaßen prozessinternen Proxy-Server zu realisieren, gibt es mehrere bekannte Ansätze auf die hier im einzelnen nicht eingegangen werden soll. Die dabei wohl am weitesten verbreitete Technik nennt sich API Hooking. Diese wird im Folgenden genauer erläutert und findet auch Verwendung in der konkret programmierten Verschlüsselungslösung für Skype. Neben dieser Technik wurde auch die Möglichkeit der Programmierung eines so genannten Layered Service Providers erwogen [8]. Ist solch einer auf einem System installiert, so wird die zugehörige DLL automatisch immer zusätzlich zu Ws2_32.dll in den Adressraum eines Prozesses geladen und erhält Zugriff auf alle eingehenden und ausgehenden Netzwerkpakete. Da somit alle Prozesse mit Netzwerkinteraktion auf einem System betroffen sind, wird diese Technik häufig auch von Firewall-Lösungen unter Windows eingesetzt. Da für die Installation eines Layered Service Providers Administrationsrechte erforderlich sind, wurde der Ansatz hier jedoch wieder verworfen Windows API Hooking Die Technik des API Hookings wird sich allgemein häufig zunutze gemacht, wenn unter Windows das Verhalten eines Programmes zur Laufzeit verändert oder generisch überprüft werden soll. So überschreiben beispielsweise eine Vielzahl von Anti-Viren-Lösungen die Einstiegspunkte von API Funktionen der Windows DLLs in jedem neuen Prozess dynamisch mit einer Art Umleitung in ihren eigenen Programmcode - im Jargon Hook genannt - um Programme auf verdächtige Verhaltensmuster hin zu überprüfen [33]. Auch die Firma Microsoft verwendet solche Hooking Techniken um das Einspielen von Updates im laufenden Systembetrieb zu ermöglichen. Anstatt nur Systemdateien auf der Festplatte zu ändern und anschließend einen Neustart zu fordern, werden die Einstiegspunkte von zu aktualisierenden Funktionen im Arbeitsspeicher so verändert, dass bei einem Aufruf die Programmausführung automatisch zur fehlerbereinigten Version jener Funktion verzweigt. Im Falle des zu beeinflussenden Skype-Clients bietet die breite Verwendung dieser Technik den Vorteil, dass Skype-Clients sich gegen diese nicht zur Wehr setzen können, sofern die Herstellerin Skype Ltd. keine Fehlalarme bei Anti-Viren Produkten oder Inkompatibilitäten riskieren möchte. Im Kontrast zu den ansonsten allgegenwärtigen Abschottungsversuchen des Skype- Clients, lassen sich so auch tatsächlich die Einstiegspunkte von geladenen DLLs zur Laufzeit nach belieben manipulieren. Es bleibt die Frage, auf welchem Wege diese Umleitungen innerhalb des Skype-Prozess installiert werden können. In [25] wird dazu unter anderem eine Vorgehensweise präsentiert, mit deren Hilfe sich nachträglich beliebige DLLs in einen fremden Prozess laden lassen. So wird es möglich Daten und Kontrollflüsse innerhalb eines Prozesses beinahe 24

25 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen beliebig zu verändern - und somit natürlich auch Hooks an Einstiegspunkten zu Windows APIs zu platzieren. Für dieses Platzieren von Hooks in Funktionen stellt die Firma Microsoft eigens ein Softwareentwicklungskit (SDK) namens Detours für die Programmiersprache C öffentlich zum Download bereit [37]. Dieses kann nach der gegebenen Lizenz für den privaten Gebrauch und zu Forschungszwecken kostenlos verwendet werden. Für den kommerziellen Gebrauch sind jedoch Lizenzgebühren vorgesehen. Trotz dieser nicht vollkommen freien Lizenz, wird dieses SDK in der hier noch genauer vorzustellenden Implementierung verwendet. Es ließe sich jedoch vermutlich auch leicht durch eine freiere Alternative wie [34] ersetzen. Bereits in [38] wurde ein vom Skype-Prozess Skype-Client Kernel32.dll, User32.dll,... Black Box send( ) recv( ) hook.dll socket( ) send( ) WSASendTo( ) recv( )... Ws2_32.dll Kommandos Argumente API-Funktionen Python Interface Abbildung 2.4.: Skype-Prozess mit gehookten Funktionen send() und recv() (über Python Interface). Autor entwickeltes Interface für die Sprache Python vorgestellt, welches wie beschrieben eine eigene DLL in einen beliebigen Prozess lädt, um anschließend das Hooken von beliebigen API- Funktionen zu ermöglichen. Python-Skript und DLL kommunizieren dabei über so genannte Named Pipes, wobei die Python Seite die Namen abzufangender API-Funktionen und andere Kommandos übergibt und anders herum im Falle eines Treffers die an die betreffende API-Funktion übergebenen Argumente erhält. Dieses Interface wurde gerade zu Anfang dieser Arbeit häufig zum Prototyping und zur Beobachtung des Verhaltens des Skype-Clients zur Laufzeit verwendet - gerade auch in Bezug auf Aufrufe in Ws2_32.dll. Eine schematische Darstellung dieser Lösung ist in Abbildung 2.4 zu sehen. Für die Implementierung der eigentlichen Verschlüsselungslösung eignet sich dieses Interface jedoch nicht, da sowohl die Skriptsprache Python als auch die gewählte Architektur sich im Zusammenspiel mit Skype als zu langsam für die Echtzeitverschlüsselung erwiesen hat. 25

26 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen Zuordnung von Netzwerkpaketen Im vorangegangenen Abschnitt wurde ein Verfahren präsentiert, mit dessen Hilfe sich der Netzwerkverkehr des Skype-Clients lokal beliebig mitschneiden und manipulieren lässt. Da sämtlicher Verkehr innerhalb des Skype-Netzwerks massiv obfuskiert und in den allermeisten Fällen verschlüsselt ist [42], lassen sich die ein- und ausgehenden Pakete eines Skype-Clients zunächst nicht analysieren und einer bestimmten Sitzung oder Zweck zuordnen. Dies ist jedoch für die geforderte Verschlüsselungslösung unerlässlich, denn schließlich sollen ausnahmslos alle zu einer zu schützenden Kommunikationssitzung gehörenden Netzwerkpakete vor dem endgültigen Versenden noch einmal nachvollziehbar sicher verschlüsselt werden und umgekehrt möglichst alle eingehenden Pakete vor dem Weiterleiten an den Skype-Client wieder korrekt entschlüsselt werden. Ist eines von beiden nicht gewährleistet, so liefert die zusätzliche Verschlüsselungsschicht keinen Sicherheitsgewinn oder die Interaktion des Skype-Clients mit dem übrigen Netzwerk wird gestört, was zu einem deutlichen Qualitätsverlust für den Anwender führen kann. Im Folgenden werden daher zwei Ansätze zur Klassifizierung des Netzwerkverkehrs eines Skype- Clients zur Laufzeit diskutiert. Beide sind dabei grundverschieden und liefern alleine keine abschließende, allumfassende Lösung. Auch wenn zum aktuell vorliegenden Entwicklungsstand der angefertigten Verschlüsselungslösung nur der zweite von beiden zum Einsatz kommt und so zumindest die unbedingte Sicherheit von Telefonaten garantiert, so wäre doch im äußersten Idealfall eine Kombination aus beiden Ansätzen wünschenswert Deobfuskierung von Netzwerkpaketen Wie bereits erwähnt, obfuskiert ein Skype-Client sämtlichen Payload 6 ausgehender Netzwerkpakete zusätzlich zu jedweder Verschlüsselung. Nach [42] wird für diese Obfuskierung eine Abwandlung der Stromchiffre RC4 verwendet. Während die eigentliche Schlüsselstromgenerierung unangetastet blieb, wurde der initiale Schritt zur dynamischen Berechnung der GF (2) 8 GF (2) 8 abbildenden S-Box aus einem theoretisch bis zu 256 Bits langem Schlüssel [44] bewusst so abgewandelt und aufgebläht, dass ein Nachvollziehen - gerade in assemblierter Form - zu einem aufwendigen Prozess wird. Trotz dessen wurde in 2010 mit [35] eine Rekonstruktion dieser abgewandelten Initialisierungsroutine in der Programmiersprache C veröffentlicht, welche aus über 2500 Zeilen Programmcode besteht. Zum Vergleich: Eine Implementierung der Standardfunktion kommt typischerweise mit weniger als zwanzig Zeilen aus. Um die Implementierung aus [35] in der Praxis zur Deobfuskierung von Netzwerkpaketen zum Zwecke der Zuordnung zu Kommunikationssitzungen nutzen zu können, ist es natürlich notwendig, den zur Initialisierung 6 Selbstverständlich müssen die Headerinformationen des UDP- bzw. des TCP-Protokolls unangetastet bleiben. Gleiches gilt natürlich auch für das darunterliegende IP-Protokoll. 26

27 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen verwendeten Schlüssel zu kennen. Nach [42] aus 2006 wird zur Obfuskierung von Paketen im Skype-Netzwerk sowohl für UDP als auch TCP jeweils ein 32 Bit langer Schlüssel verwendet, welcher sich in beiden Fällen einfach aus im Paket im Klartext enthaltenen Werten berechnen lässt (tatsächlich genügt es im Falle von TCP-Paketen die ersten vier Bytes abzulesen). Ein Paket kann also für sich genommen komplett deobfuskiert werden - eine Kenntnis weiterer Pakete oder anderer Informationen ist nicht notwendig. Ob dies zum Zeitpunkt der Niederschrift dieser Arbeit, knapp fünf Jahre später, immer noch der Fall ist, ist unklar. Eigene Erkenntnisse durch Reverse Engineering 7 legen zumindest nahe, dass dies nicht mehr uneingeschränkt gilt. Zu einem Test der rekonstruierten Funktionen aus [35] in der Praxis kam es während der Recherche für diese Arbeit nicht, da eine Verwendung in der eigenen Verschlüsselungslösung aufgrund der mit [35] verbundenen Lizenz im Voraus ausgeschlossen wurde. Diese sieht eine freie Nutzung ausschließlich für Forschungszwecke vor, was wohl einer Verbreitung eines Programms zur privaten Nutzung widerspricht. Stattdessen wurde selbst mittels Reverse Engineering die modifizierte RC4 Initialisierungsfunktion innerhalb der Programmdatei des Skype-Clients lokalisiert und analysiert. Mit Hilfe der so gewonnenen Informationen und dem bereits besprochenen Detours SDK konnte eine DLL entwickelt werden, welche sämtlichen Netzwerkverkehr eines laufenden Skype-Clients mitliest und versucht nach [42] zu deobfuskieren. Es sei betont, dass dabei keine eigene Variante der modifizierten Initialisierungsroutine entwickelt wurde. Stattdessen wurde direkt zu der betreffenden Funktion innerhalb des Programmcodes des Skype-Clients gesprungen und die Ergebnisse anschließend ausgewertet und in einer Datei protokolliert (siehe Abbildung 2.5). Ein Auszug des Programmcodes zur Deobfuskierung von Paketen ist in Listing Skype-Prozess Skype-Client RC4_Init( ) send( ) recv( ) sendto( ) recvfrom( ) deob.dll... send( ) recv( ) sendto( ) recvfrom( ) Ws2_32.dll Logdatei Abbildung 2.5.: Deobfuskierung und Protokollierung von Netzwerkpaketen. A.2 auf Seite 87 zu finden. Der vollständige Programmcode der DLL ist auf dem beiliegenden 7 Aufgrund des gegebenen Rahmens dieser Arbeit werden die beim Prozess des Reverse Engineerings des Skype- Clients vollzogenen Schritte hier nicht näher erörtert. Es sei nur angemerkt, dass zur Laufzeit ein Abbild des im Speicher entschlüsselten Programmcodes erstellt wurde, welches dann mit Hilfe des Programms IDA Pro weitestgehend statisch analysiert wurde. 27

28 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen Datenträger enthalten. Eine Analyse der so gewonnenen Protokolldateien zeigt, dass zumindest einige TCP Pakete korrekt deobfuskiert werden konnten. So ist mehrfach die Byte-Folge F zu finden, welche zwar nicht komplett der in [42] beschriebenen entspricht, jedoch mit an Sicherheit grenzender Wahrscheinlichkeit den Fixwert zur Verifizierung einer korrekten Deobfuskierung darstellt. Bei sämtlichen anderen Paketen konnte durch die reine Analyse im Hexeditor kein Hinweis auf eine korrekte Deobfuskierung gefunden werden. Mangels Zeit und den nur langsam zu erwartenden neuen Erkenntnissen wurde auf eine weitere Analyse mittels Reverse Engineering und Anderem hier verzichtet. Es bleibt jedoch festzuhalten, dass dieser Ansatz durchaus soweit ausgebaut werden könnte, dass zu jedem Paket, handele es sich um TCP oder UDP, anhand von enthaltenen Metadaten der Datentyp und der Empfänger bestimmt werden könnte. Somit ließen sich im Vertrauen auf die Korrektheit jener Metadaten (Stichwort Skype- Client ist nicht bösartig, siehe Abschnitt 1.4.1) Pakete wie gewünscht zuordnen. Solche Pakete die ein zu verschlüsselndes Telefonat beträfen, würden verschlüsselt, alle anderen nicht. Es bliebe jedoch das bereits schon zuvor öfter erwähnte Problem, dass unter bestimmten, bis dato unbekannten Umständen ein Skype-Client ein unerwartetes Verhalten an den Tag legen könnte und so eigentlich zu schützende Informationen ohne zusätzliche Verschlüsselung übertragen würden. Ein möglicher Weg aus dieser Problematik ist das ausschließliche Übertragen von zusätzlich verschlüsselten Paketen während einer entsprechenden Sitzung. Diese Herangehensweise lässt sich jedoch einfacher auf anderem Wege, wie im Folgenden beschrieben, realisieren Austausch von Verbindungslisten Da die Zuordnung von Netzwerkpaketen anhand ihres Inhalts im Falle von Skype aufwendig ist und zudem auch dem Ansatz des Betrachtens des Skype-Clients als Black Box widerspricht, soll hier ein weiteres, einfacheres Verfahren vorgestellt werden, mit Hilfe dessen ein- und ausgehende Netzwerkpakete des Skype-Clients unterschiedlichen Sitzungen zugeordnet werden können. Wie bereits dargelegt werden die für eine Kommunikationssitzung notwendigen Daten zwischen zwei Clients im Skype-Netzwerk im Regelfall über P2P Verbindungen ausgetauscht. Folglich genügt es dann die für die jeweilige P2P Verbindung verwendeten IP-Adressen, Protokolle (TCP oder UDP) und Ports zu kennen und die über diese übertragenen Daten zu verschlüsseln, respektive zu entschlüsseln, und gegebenenfalls sämtliche anderen Verbindungen temporär zu unterbinden. Die naheliegendste Herangehensweise wäre dabei wohl, dass die Verschlüsselungslösungen auf beiden Seiten einer Kommunikationssitzung sicher ihre IP-Adressen austauschen um anschließend an der Sitzung beteiligte Protokolle und Ports zu bestimmen. Dieser Ansatz birgt jedoch mindestens zwei Unklarheiten: 1.) Ist es in den meisten Fällen wohl nicht gegeben, 28

29 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen dass ein PC ohne weiteres seine eigene IP-Adresse in Bezug auf das Internet kennt 8 und 2.) muss auf irgendeinem Wege vor einer Verschlüsselung eine Verbindung mit dem Partner aufgebaut werden, um beispielsweise die Bereitschaft zur zusätzlichen Verschlüsselung zu erfragen, obwohl dessen IP-Adresse prinzipbedingt noch nicht bekannt sein kann. Bei der Lösung von 2.) ist von Ansätzen wie dem Senden von Erkennungsnachrichten an alle bekannten, mit dem Skype-Client in Verbindung stehenden Hosts abzusehen, da bereits in Abschnitt 1.4 festgelegt wurde, dass sich die zusätzliche Verschlüsselungslösung minimal inversiv verhalten - also nicht unnötig auf ihr Vorhandensein im Skype-Netzwerk aufmerksam machen soll. Hier bietet die öffentliche Skype API die Möglichkeit der Kontaktaufnahme mit einem neuen Kommunikationspartner im Einklang mit dieser Vorgabe. So ist es über jene API möglich Textnachrichten zu versenden und auf bereits empfangene zur Laufzeit lesend zuzugreifen. Auch kann sich ein Programm im Falle von Ereignissen wie neu ein- oder ausgehender Anrufe benachrichtigen lassen. So ist es möglich, im Falle eines neuen Anrufes, eine Textnachricht an die Gegenseite mit etwa der Aufforderung zur Verschlüsselung des anstehenden Gesprächs und anderen Informationen zu senden. Läuft zu diesem Zeitpunkt auf der Gegenseite dieselbe Verschlüsselungslösung, so kann diese entsprechend antworten. Um 1.) - das Problem der Identifizierung von zu verschlüsselnden Verbindungen - zu lösen, sind nun wohl mehrere Herangehensweisen denkbar. Hier soll davon nur eine besprochen werden, nämlich diejenige, die auch schließlich für die Implementierung der eigenen Verschlüsselungslösung gewählt wurde. Geht man davon aus, dass sämtlicher Netzwerkverkehr des Skype-Clients mittels Hooking der entsprechenden Funktionen aus Ws2_32.dll überwacht wird, so ist es möglich, eine Liste aller getätigten Verbindungen des Skype-Clients seit dessen Start zu führen. Eine solche Verbindung wird definiert durch IP-Adresse des anderen Hosts, Protokoll sowie ausgehendem und eingehendem Port. Vermutlich um sich vor einer generischen Erkennung durch Firewalls zu schützen, verwenden unterschiedliche Skype-Client Installationen einen unterschiedlichen festen Port für eingehende TCP und UDP Verbindungen. Wobei anscheinend während des Installationsvorgangs zumindest teilweise zufällig ein Wert aus der für Ports möglichen Menge 0,..., gewählt wird. Dieser festgelegte eingehende Port ist also bis zu einem gewissen Grad charakteristisch für eine Skype-Client Installation. Es lässt sich jedoch auch einfach über das Optionsmenü des Skype- Clients manuell verändern. Offenbar wird in den Supernodes des Skype-Netzwerks zu jedem angemeldeten Client auch dieser Port vorgehalten, denn wann immer ein Client eine Verbindung zu einem anderen aufzubauen versucht, so geschieht dies zunächst über jenen Port. Für den Fall, dass es aufgrund lokaler Netzwerkbegebenheiten keine Möglichkeit zu einer freien Portwahl 8 Heutzutage werden PCs nur noch in den seltensten Fällen über ein Modem direkt mit dem Internet verbunden. In den meisten Fällen befindet sich zwischen Internet und PC noch ein Router. 29

30 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen gibt, so versucht Skype über die unverdächtigen Ports 80 (HTTP) und 443 (HTTPS), welche eigentlich für die Übertragung von Webseiten verwendet werden, Verbindungen aufzubauen 9. Dieses Verhalten lässt sich ebenfalls über das Optionsmenü abschalten. Neben den fest eingestellten Ports verwenden nach empirischen Untersuchungen Skype-Clients mitunter noch eine kleine Zahl von weiteren Ports, welche wie zufällig für die jeweilige Sitzung gewählt erscheinen. So ergab sich beispielsweise für ein Telefonat zwischen zwei mit dem Intranet der Ruhr-Universität verbundenen PCs das in Tabelle 2.1 gegebene Bild, welches als exemplarisch angesehen werden kann Client Charakt. Port Ausgehende Verbindungen A , UDP , TCP , TCP B , UDP , TCP , TCP Tabelle 2.1.: Verbindungen zwischen Client A und Client B im lokalen Netzwerk nach Anruf von B durch A. Bis zum Zeitpunkt des Gesprächsaufbaus, hatten beide Skype-Clients im konkreten Beispiel noch jeweils rund 20 Verbindungen mit anderen IP-Adressen und Ports aufgebaut (und möglicherweise auch schon wieder geschlossen). Es ist nicht unüblich, dass die Länge solcher Verbindungslisten auch um ein vielfaches höher liegt. Ohne Vorkenntnisse über IP-Adressen oder Ports zu haben, war es in jenem und in jedem der weiteren durchgeführten Tests, sowohl im Inter- als auch Intranet, möglich, nur mit Kenntnis beider Verbindungslisten, die für die Kommunikation zwischen beiden beteiligten Clients verwendeten P2P Verbindungen eindeutig zu bestimmen. Können zwei Clients ihre Verbindungslisten austauschen, so ist es ihnen also in den meisten Fällen möglich, ohne Kenntnis der eigenen IP-Adresse oder der des Gegenübers, die an ihrer gemeinsamen Kommunikation über das Skype-Netzwerk beteiligten P2P Verbindungen genau zu bestimmen. Entsprechend ist es anschließend möglich die betreffenden Verbindungen zusätzlich zu sichern. Das genaue Vorgehen beim Bestimmen der zwischen zwei Partnern existierenden Verbindungen mit Hilfe besagter Verbindungslisten beider Seiten ist einfach und intuitiv: Kommt ein Paar, bestehend aus eingehendem und ausgehendem Port, aus der Verbindungsliste von Client A in umgekehrter Richtung auch in der Verbindungsliste von Client B vor, so ist davon auszugehen, dass diese Ports für eine Direktverbindung zwischen beiden Clients verwendet werden. In der Praxis muss der Austausch solcher Verbindungslisten natürlich kryptographisch gesi- 9 Beobachtungen legen nahe, dass häufig Supernodes auf Port 433 auf Verbindungen warten. 30

31 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen chert erfolgen und dem Ergebnis kann zudem auch nicht abschließend vertraut werden. So ist es notwendig, während die identifizierten P2P Verbindungen verschlüsselt werden, sämtliche anderen Verbindungen zu blockieren, um Irrtümern oder dem unvorhergesehenem Verhalten eines Skype-Clients vorzubeugen. Auch werden natürlich durch einen Austausch von kompletten Verbindungslisten Informationen über Verbindungen zu dritten Parteien innerhalb des Skype-Netzwerks preisgegeben (es sei hier jedoch schon einmal erwähnt, dass zumindest die Übermittlung von konkreten IP-Adressen nicht notwendig ist, anonyme Platzhalter sind hier ausreichend). Zudem dürfte klar sein, dass Verbindungen über Relay Hosts sich in den meisten Fällen wohl nicht eindeutig identifizieren lassen. Trotz dieser Widrigkeiten, wird dieses Verfahren als alleiniges in der eigenen Verschlüsselungslösung verwendet. Wie dabei im Detail verfahren wird und welche Protokolle zwischen zwei verschlüsselungswilligen Parteien ablaufen, wird im anschließenden Kapitel eingehend behandelt Bewertung Im Unterschied zur Prä-Audio-Codec-Verschlüsselung ist die Netzwerkpaketverschlüsselung mit gewöhnlichen symmetrischen und asymmetrischen kryptographischen Algorithmen sowie bekannten technischen Methoden realisierbar. Daher fiel für die Implementierung der zusätzlichen Verschlüsselungsschicht auch die Wahl auf diesen Ansatz. Im Speziellen wird dabei eine Kombination aus Windows Sockets API-Hooking und dem beschriebenen Austausch von Verbindungslisten zwischen zwei Clients über Textnachrichten angewandt. Wie genau damit die Kommunikation zwischen zwei Teilnehmern über P2P Verbindungen nachvollziehbar gesichert und auf welche kryptographischen Verfahren und Protokolle dabei geeigneter Weise zurückgegriffen werden kann, wird im folgenden Kapitel adressiert. Unbehandelte Probleme bleiben Kommunikationssitzungen mit mehreren Teilnehmern und die Sicherung von Verbindungen über Relay Hosts. Auch wenn zu letzterem nur sporadische Versuche und Nachforschungen angestellt wurden, ist davon auszugehen, dass sich dieses Problem im Falle der Netzwerkpaketverschlüsselung nicht ohne die in Abschnitt behandelte Deobfuskierung von ausgehenden Paketen zur Laufzeit lösen lässt. Anders ausgedrückt ist eine Deep Packet Inspection hier wohl unerlässlich. Die eigentlich gewünschte Betrachtungsweise des Skype-Prozesses als Black Box müsste dafür zumindest in Teilen aufgegeben werden. In der alltäglichen Anwendung sollten Verbindungen über Relay Hosts jedoch eher selten vorkommen. Nach Ansicht des Autors ist daher für die Verschlüsselungslösung legitim, diese nicht zu unterstützen, sofern der Nutzer darauf hingewiesen wird, dass beispielsweise das von ihm angestrebte Telefonat nicht zu verschlüsseln ist. Was Kommunikationssitzungen mit mehreren Teilnehmern anbetrifft, wurden ebenfalls nur ver- 31

32 2. Mögliche Ansätze zur Verhinderung von Man-In-The-Middle Angriffen einzelte Versuche durchgeführt. Hier scheinen die noch zu nehmenden Hürden jedoch bedeutend niedriger zu sein als bei Relay Hosts. So ist es durchaus denkbar, dass die ausgewählten Verfahren mit minimalen Anpassungen eingesetzt werden könnten. Inwieweit die Manipulation des Verhaltens des Skype-Prozesses durch das Laden einer zusätzlichen DLL in diesen im Einklang mit dem End-user License Agreement (EULA) von Skype Ltd. steht, scheint nicht eindeutig beurteilbar. So verbietet die EULA neben dem Reverse Engineering zumindest die Modifizierung und das Hacking der Skype Software [30]. Nach Ansicht des Autors stellt die Umleitung von Funktionsaufrufen in Ws2_32.dll keinen Verstoß dar, da die Integrität des Skype-Clients im Speicher weiterhin gegeben ist. Anders könnte es sich jedoch in Bezug auf die separaten API Terms of Use verhalten. Hier schließt Skype Ltd. jegliche Verwendung der Skype API aus, sofern die Qualität von Anrufen oder die Stabilität der Skype Software beeinflusst wird [28]. Diesen Bestimmungen könnte das beschriebene Unterbinden von ausgehenden Verbindungen während eines gesicherten Telefonats entgegenlaufen. Da in der noch zu präsentierenden Verschlüsselungslösung die Skype API jedoch nicht direkt für diesen Vorgang verwendet und stattdessen nur für das Versenden von Textnachrichten und das Reagieren auf Ereignisse in Anspruch genommen wird, ist ein tatsächlicher Verstoß wohl nicht gegeben. Durch die strenge Modularität der Komponenten können zudem die Einheit zur Manipulation von Verbindungen und die zur Verwendung der Skype API als zwei getrennte Programme betrachtet werden. Kurzum: Die rechtliche Unbedenklichkeit ist nicht eindeutig zu klären, sie scheint aber wahrscheinlich. 32

33 3. Implementierung der Verschlüsselungslösung 3 Implementierung der Verschlüsselungslösung Nachdem in den beiden vorangegangenen Kapiteln zunächst die Entwicklung einer zusätzlichen Verschlüsselungslösung für Skype motiviert und anschließend die dafür geeigneten Ansätze identifiziert wurden, werden in diesem Kapitel schließlich die Details der Implementierung der entsprechend im Rahmen dieser Arbeit programmierten Anwendung watchasayin behandelt. Der Fokus soll dabei klar auf der Erläuterung der strukturellen und funktionalen denn auf der technischen Ebene liegen. Wobei auch einzelne technische Lösungsansätze exemplarisch diskutiert werden. Während der Implementierungsphase wurde von Anfang an großer Wert auf eine ausführliche, standardisierte Kommentierung im XML-Format gelegt [13], sodass die automatisierte Erstellung einer Dokumentation möglich war. Diese liegt wie im Allgemeinen üblich nur in Englisch vor. Sie ist auf dem beiliegenden Datenträger zu finden und liefert genauere Einblicke in die konkreten technischen Realisierungen. Daneben befinden sich auf diesem auch der komplette Quellcode der Anwendung sowie eine fertig kompilierte Variante. Bevor die einzelnen Teilkomponenten für sich beleuchtet werden, wird im Folgenden zunächst ein Überblick über die gesamte Anwendung, ihren strukturellen Aufbau und getroffene Designentscheidungen gegeben. 3.1 Vorgaben und Ziele Die in den vorherigen Kapiteln allgemein formulierten konzeptionellen Ziele seien hier für die Anwendung watchasayin zunächst noch einmal zentral in konzentrierter Form wiedergegeben. Daneben sollen im Anschluss zudem eine Reihe von teilweise bisher noch nicht besprochenen, die konkrete Implementierung betreffende technische Vorgaben formuliert werden Konzeptionelle Ziele Die Anwendung watchasayin muss folgende Funktionalität und Eigenschaften aufweisen: 1. Sichere Verschlüsselung von Gesprächen mit zwei Teilnehmern unter herkömmlichen Bedingungen (vgl. Kapitel 1) 2. Authenticated Key-Exchange zwischen verschlüsselungswilligen Parteien (vgl. Kapitel 1) 3. Minimalinversives Verhalten in Bezug auf das Skype-Netzwerk, ein Vorhandensein von watchasayin soll von außen nicht bemerkbar sein (vgl. Kapitel 1) 33

34 3. Implementierung der Verschlüsselungslösung 4. Fingerprintvalidierung durch Nutzer sichert AKE und ersetzt Vertrauen in Certificate Authority von Skype Ltd. (vgl. Kapitel 1) Implementierungstechnische Vorgaben Bei der Implementierung der oben genannten Funktionen sollen folgende Vorgaben eingehalten werden: 1. Betrachtung des Skype-Client als Black Box soweit möglich (vgl. Kapitel 2) 2. Realisierung von bilateraler Kommunikation zwischen watchasayin Instanzen über Textnachrichten (vgl. Kapitel 2) 3. Identifizierung von zu verschlüsselnden Verbindungen über Austausch von Verbindungslisten (vgl. Kapitel 2) 4. Möglichst modularer Aufbau zum einfachen Austausch von Komponenten (vgl. Kapitel 1) 5. Kontrolle des Skype-Netzwerkverkehrs über Windows Sockets API Hooking (vgl. Kapitel 2) 6. Objektorientierte Entwicklung der Kernkomponenten in C# 7. Objektorientierte Entwicklung von nativen Komponenten in C++ 8. Kapselung von Skype spezifischem Programmcode, minimale Berührungspunkte zum Skype-Client 9. Kommentierung des Quellcodes mit der Möglichkeit der automatisierten Erstellung einer Dokumentation 10. Integration aller Komponenten in Visual Studio 2010 als einheitliches Projekt Die Punkte sechs bis zehn werden hier zum ersten Mal aufgeführt. Dabei geben die Punkte sechs und sieben zunächst die Wahl der Programmiersprachen vor. Für die eigentliche Anwendung und ihre grundlegende Logik ist die Programmiersprache C# zu verwenden. In C# entwickelte Anwendungen sind zwar nur bedingt auf andere Plattformen als Windows portierbar 1, jedoch stellt C# eine der effektivsten Möglichkeiten der Entwicklung von komplexeren Programmen unter Windows dar und bekommt daher den Vorzug gegenüber Java oder anderen Sprachen. 1 Mit Mono existiert ein von der Firma Novell unterstütztes Open-Source Projekt, welches in C# entwickelte Anwendungen auf verschiedenen Plattformen wie Linux oder OS X zum Laufen bringt [43]. Die aktuelle.net Framework Version 4, für die auch watchasayin entwickelt wurde, wird zum momentanen Zeitpunkt jedoch noch nicht von Mono unterstützt. 34

35 3. Implementierung der Verschlüsselungslösung Dies sei zudem noch einmal dadurch gerechtfertigt, dass aufgrund der überragenden Verbreitung von Windows dies die ausschließliche Zielplattform dieser Arbeit ist. Da sich mit C# keine nativen Programme für die x86 Architektur entwickeln lassen - sprich Programme die in unmittelbar in vom Prozessor ausführbaren Befehlsfolgen vorliegen - können nicht alle Teile von watchasayin in dieser Sprache entwickelt werden. So ist es beispielsweise für das Hooking von Windows Sockets API Funktionen im Prozess des Skype-Clients beinahe unerlässlich eine in nativem Code vorliegende DLL zu entwickeln. In derartigen Fällen soll objektorientiert in der Sprache C++ programmiert werden. Punkt acht sieht vor, dass die Berührungspunkte mit dem Skype-Client minimal gehalten werden und Skype spezifischer Programmcode nur in klar abgetrennten Programmteilen zu finden sein soll. So soll der Arbeitsaufwand für eine mögliche Portierung von watchasayin für andere VoIP Produkte minimal gehalten werden - nur die Skype betreffenden Programmteile müssten neu entwickelt werden. Punkt neun fordert eine derartige Kommentierung des Programmcodes, dass, wie bereits weiter oben erwähnt, die automatisierte Generierung einer technischen Dokumentation möglich wird. Schließlich wird unter 10 die Vorgabe gemacht, dass die gesamte Anwendung mit ihren Teilkomponenten (nach Punkt zwei) in einem einzelnen Visual Studio 2010 Projekt vorliegen soll. So wird der Aufwand der Kompilierung der Anwendung auf ein Minimum beschränkt, womit eine höhere Produktivität während der Entwicklung einhergeht. Visual Studio 2010 stellt nach Ansicht des Autors zudem allgemein die effektivste erhältliche Entwicklungsumgebung für C# dar. Mit diesen Vorgaben und Zielen im Hintergrund werden im folgenden Abschnitt die Funktionen der Anwendung watchasayin und ihr struktureller Aufbau betrachtet. 3.2 Das Programm watchasayin Das Programm watchasayin realisiert die sichere, von Skype Ltd. unabhängige Verschlüsselung von Telefongesprächen zwischen zwei Skype-Nutzern. Es wurde für Windows 7 mit Hilfe von Microsofts Visual Studio 2010 in den Programmiersprachen C++ und C# entwickelt. Durch Letzteres wird zur Ausführung des Programms das.net Framework 4.0 benötigt, welches sich kostenlos von Microsoft beziehen lässt. Um eine möglichst breite Verwendung der Anwendung zu unterstützen, ist sämtliche Kommunikation mit dem Anwender in Englisch gehalten. 35

36 3. Implementierung der Verschlüsselungslösung Abbildung 3.1.: Screenshot der Anwendung watchasayin während eines verschlüsselten Telefonats mit dem Skype-Nutzer flx Funktionen Gegenüber dem Anwender präsentiert sich die Anwendung watchasayin mit nur wenigen Funktionen. Wird das Programm über die Datei Surface.exe gestartet, so öffnet sich, vorausgesetzt das entsprechende.net Framework ist installiert, unmittelbar eine grafische Benutzeroberfläche wie in Abbildung 3.1 zu sehen. Diese informiert mit Hilfe von drei permanent sichtbaren Dialogelementen den Benutzer über den aktuellen Ausführungszustand der Anwendung. Einmal gestartet, verrichtet das Programm automatisch seinen Dienst, ohne dass eine Bedienung durch den Anwender erforderlich ist. Eine aktive Interaktion zwischen Nutzer und Programm findet ausschließlich mit Hilfe so genannter Message Boxes statt. Diese kommen zur Anwendung bei einmaligen Aktionen wie dem Erstellen eines neuen privaten Schlüssels (siehe Abbildung 3.2) oder im Fehlerfall. Dabei wird der Nutzer ausschließlich nach seiner Zustimmung zu einer bestimmten anstehenden Aktion befragt. In den folgenden Abschnitten werden die nach außen sichtbaren Funktionen der Anwendung einzeln besprochen. Diese Abschnitte können als kurzes Handbuch verstanden werden, in dem zur Orientierung ein Überblick über das Programm aus Anwendersicht gegeben wird bevor die eigentlichen technischen Details erörtert werden. 36

37 3. Implementierung der Verschlüsselungslösung Abbildung 3.2.: Message Box zur Abfrage der Zustimmung des Nutzers zur Erstellung eines neuen privaten Schlüssels Elemente der grafischen Benutzeroberfläche Als Oberstes von dreien ist, direkt unter dem Logo, in auffälliger Farbgebung die Anzeige des Fingerprints des geheimen Schlüssels des aktuell angemeldeten Nutzers untergebracht. Die 40- stellige Zeichenkette, welche den Fingerprint repräsentiert, wird angezeigt, sobald watchasayin sich erfolgreich mit dem Prozess eines Skype-Clients verbinden konnte. Diese Anzeige kann sich während einer laufenden Sitzung niemals ändern und soll durch ihre permanente und auffällige Präsenz dem Anwender eine einfache Möglichkeit geben, schnell andere Skype-Teilnehmer mit watchasayin Anwendung über den eigenen Fingerprint zu informieren - wie schon in Abschnitt 1.4 besprochen, beispielsweise über eine verschlüsselte oder verbal über ein ungeschütztes Skype-Telefonat. Direkt unter der Fingerprintanzeige befindet sich eine so genannte List-View, in welcher dem Anwender in Tabellenform Informationen über aktuell laufende Kommunikationssitzungen gegeben werden. Für jede aktive, von watchasayin unterstützte Sitzung wird hier eine neue Zeile angelegt, welche nach Beendigung der entsprechenden Sitzung wieder gelöscht wird. Da in der aktuell vorliegenden Version von watchasayin ausschließlich Telefonate mit zwei Teilnehmern unterstützt werden, werden auch nur solche hier angezeigt. Die Tabelle verfügt, wie auch in Abbildung 3.1 zu sehen, über vier Spalten. Dabei ist unter Name der Skype-Name des jeweiligen Kommunikationspartners gegeben, während in der Spalte Type die Art der Sitzung (zum Beispiel call) angezeigt wird. Während diese beiden für jede unterstützte Sitzungsart angezeigt werden, kommen die beiden letzten Spalten nur bei tatsächlich über watchasayin gesicherte Verbindungen zum Tragen. Unter Status wird dabei der Status der Sitzung in Bezug auf ihre Sicherheit angezeigt. Mögliche Zustände sind hier secure für eine sichere Verbindung sowie - und insecure für eine nicht gesicherte bzw. unsichere Verbindung. Um den Nutzer unmittelbar auf den Wechsel zwischen zwei Zuständen aufmerksam zu machen, werden im Falle eines solchen unterschiedliche Tonfolgen ausgegeben. Es sei bemerkt, dass ein Wechsel von secure nach insecure während eines laufenden Telefonats nicht vorgesehen ist, jedoch im Falle 37

38 3. Implementierung der Verschlüsselungslösung eines unerwarteten Fehlers in einer Komponente denkbar ist und daher auch dem Nutzer soweit wie möglich kenntlich gemacht werden soll. Im unteren Drittel des Programmfensters ist die Ausgabe für Laufzeitinformationen zu finden. Hier werden dem Nutzer während eines Programmlaufs dynamisch Informationen zu internen Abläufen gegeben. Im normalen Betrieb beschränken sich diese Informationen auf ein Minimum, während im Fehlerfall erweiterte Protokolle des betroffenen Moduls angezeigt werden Verbindung zu Skype-Client Prozess Unmittelbar nach ihrem Start sucht die Anwendung nach einer bereits laufenden Instanz eines Skype-Clients. Wird solch eine gefunden, so wird sich, wie in den Abschnitten 3.4 und 3.5 noch genauer dargelegt wird, auf unterschiedliche Arten mit dem Prozess des Skype-Clients verbunden. Konnte keine laufende Instanz des Skype-Clients gefunden werden, so wird versucht eine solche neu zu starten. Nach einer erfolgreichen Verbindung zu einer so implizit gestarteten Instanz des Skype-Clients enthält die Ausgabe für Laufzeitinformationen folgende Zeilen (vergleiche auch Abbildung 3.1): Info: Skype appears not to be running. Trying to start it... Successfully attached to Skype process with id: 1234 Connecting to Skype... Connected. Soll zum ersten Mal eine Verbindung zwischen einer bestimmten Version von watchasayin und der Skype-Installation auf einem PC für einen bestimmten Nutzer hergestellt werden, so ist es nötig, dass der Anwender diese Verbindung auf Seiten des Skype-Clients bestätigt 2. Tut er dies nicht, so verwehrt der Skype-Client der watchasayin Anwendung den Zugriff auf seine öffentliche API und das Programm bricht mit einer Fehlermeldung ab Verwaltung von privaten Schlüsseln und Fingerprints Ist die Anwendung watchasayin erst einmal mit einem zu schützenden Skype-Client verbunden, so werden im nächsten Schritt der private Schlüssel und der zugehörige Fingerprint-Store aus lokalen Dateien geladen, wobei Letzterer einfach eine Liste von bekannten und bereits verifizierten Fingerprints anderer Parteien darstellt. Wie diese Dateien intern aufgebaut sind 2 Will sich ein Programm erstmalig mit einem Skype-Client verbinden, so wird in einem gelb hinterlegten Bereich innerhalb des Hauptfensters des Skype-Clients eine entsprechende Frage eingeblendet. Der Nutzer hat dort die Möglichkeit auf Zulassen oder Nicht zulassen zu klicken. 38

39 3. Implementierung der Verschlüsselungslösung soll nicht weiter betrachtet werden. Hier sei nur festgehalten, dass sämtliche kryptographische Daten im Ordner %AppData%\watchasayin\Kryptonite 3 für das gerade angemeldete Windows- Nutzerkonto abgelegt werden. Dabei werden die Dateien zur Speicherung von privatem Schlüssel und Fingerprint-Store entsprechend dem Skype-Kontonamen benannt, für den sie erstellt wurden. Es ist also möglich, dass die Anwendung watchasayin von mehreren unterschiedlichen Windows- Nutzerkonten auf einem Computer aus verwendet wird, ohne dass kryptographisch sensible Daten miteinander geteilt werden müssten. Auch können von ein und demselben Windows-Nutzer unterschiedliche Skype-Konten verwendet werden - die korrekten Dateien werden automatisch geladen und geschrieben. Zudem lassen sich die Dateien ohne Weiteres auf ein anderes Windows System kopieren und dort verwenden. Wird watchasayin von einem Windows-Nutzerkonto zum ersten Mal für ein angemeldetes Skype-Konto gestartet, so sind selbstverständlich noch kein privater Schlüssel oder ein Fingerprint- Store vorhanden. In diesem Fall wird die Zustimmung des Anwenders erfragt, ob diese neu erstellt werden sollen (siehe auch Abbildung 3.2). Wurde ein neuer privater Schlüssel erstellt oder konnte ein bereits vorhandener erfolgreich geladen werden, so wird der zugehörige Fingerprint im Anschluss im oberen Drittel des Anwendungsfensters angezeigt. Die Anwendung ist dann bereit auf ein- und ausgehende Telefonate zu reagieren und diese zu verschlüsseln Verbindungsaufbau mit Gegenseite Konnte sich die Anwendung zu einem laufenden Skype-Client verbinden und zudem sowohl einen privaten Schlüssel laden oder neu generieren als auch einen Fingerprint-Store laden oder neu erstellen, so können im Anschluss Telefonate verschlüsselt werden. Voraussetzung dafür ist selbstverständlich, dass auch auf der Gegenseite eine voll initialisierte Instanz von watchasayin zu finden ist. Tätigt ein Anwender aus der Benutzeroberfläche von Skype heraus einen neuen Anruf, so wird dies von watchasayin detektiert und wie bereits beschrieben durch einen neuen Eintrag in der Tabelle der Kommunikationssitzungen angezeigt. Im Hintergrund versucht watchasayin mit der Gegenseite Kontakt aufzubauen, um das Vorhandensein einer kompatiblen Anwendung zu erfragen. Antwortet die Gegenseite und signalisiert Bereitschaft zu einer zusätzlichen Verschlüsselung des gerade angestoßenen Telefonats, so vollziehen beide Seiten einen AKE. Sollte dies zum ersten Mal zwischen beiden Parteien der Fall sein, so müssen im Verlauf des AKE die 3 Der Ordner %AppData% fungiert dabei als Platzhalter, der abhängig vom aktuell unter Windows angemeldeten Nutzer ist. Unter Windows 7 entspricht dieser für das Nutzerkonto abc123 dem Pfad C:\Users\abc123\AppData \Roaming. Dieser Ordner ist allgemein nur für den entsprechenden Nutzer oder Systemadministratoren zugänglich. 39

40 3. Implementierung der Verschlüsselungslösung Anwender auf beiden Seiten den Fingerprint des privaten Schlüssels des jeweils anderen verifizieren. Dazu wird auf beiden Seiten eine Message Box wie in Abbildung 3.3 angezeigt. Wird so die Korrektheit eines Fingerprints bestätigt, wird dieser zusammen mit dem zugehörigen Skype-Kontonamen im Fingerprint-Store des aktuell aktiven Nutzers gespeichert. Fortan muss dieser Fingerprint nicht mehr verifiziert werden - alle folgenden AKE finden vollautomatisch statt. Abbildung 3.3.: Message Box zur einmaligen Verifizierung des Fingerprints der Gegenseite bei einem Telefonat (hier mit dem Skype-Nutzer flx224 ) Logging Während der Entwicklung von watchasayin wurde auf eine genaue Protokollierung von Vorgängen innerhalb des Programms geachtet. Um den normalen Anwender nicht zu überfordern, wird in der Release Version von watchasayin nur ein Bruchteil der eigentlich anfallenden Statusmeldungen ausgegeben. In der Debug Version der Anwendung werden sämtliche Ereignisse in den externen Teilmodulen von Bottom und Kryptonite zur Laufzeit in Dateien im Ordner %AppData%\watchasayin geschrieben. Protokolliert werden so unter Anderem die Eckdaten sämtlicher ein- und ausgehender Pakete geschützter Verbindungen Aufbau und Design Die Anwendung watchasayin ist unterteilt in drei große unabhängige Module, welche sich wiederum ihrerseits, soweit möglich, aus unabhängigen Teilmodulen zusammensetzen. Dazu kommt eine eigenständige grafische Benutzeroberfläche (GUI), welche als zusätzliches viertes Modul angesehen werden kann, jedoch ordnungstechnisch auf Programmcodeebene dem Surface-Modul zuzuordnen ist. Die Kommunikation zwischen Modulen und Teilmodulen erfolgt dabei über klar definierte und einheitliche Schnittstellen. So soll eine größtmögliche Flexibilität erreicht 40