Moglichkeiten der Implementierung einer

sicheren, zusatzlichen

Sprachverschlusselungsschicht fur Skype

Seminar Netz- und Datensicherheit (SoSe 2010)Horst Gortz Institut fur IT-Sicherheit

Ruhr-Universitat Bochum

Felix SchusterMatr.-Nr:1008006253627

felix.schuster@rub.de

9. Juli 2010

1

Inhaltsverzeichnis

I Einleitung 3

1 Das Programm Skype 3

2 Bereits vorhandene Abhorschutzmaßnahmen 3

II Mogliche Ansatze 4

3 Allgemeine Schwierigkeiten 4

4 Pre Audio Codec Verschlusselung 54.0.1 Skype API . . . . . . . . . . . . . . . . . . . . . . . . . . 64.0.2 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 10

5 TCP/UDP Paketverschlusselung 105.1 Win32 API Hooking . . . . . . . . . . . . . . . . . . . . . . . . . 115.2 Konzept zur Implementierung . . . . . . . . . . . . . . . . . . . . 15

5.2.1 C# Komponente - GUI . . . . . . . . . . . . . . . . . . . 155.2.2 C/C++ Komponente - hook.dll . . . . . . . . . . . . . . . 16

5.3 Zusammenfasung . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2

Teil I

Einleitung

1 Das Programm Skype

Skype ist zweifelsohne die bekannteste und beliebteste nicht im Browser lau-fende Anwendung der Web 2.0 Ara. Es ist Instant-Messenger, VoIP-Client undVideotelefon in einem und konnte dank einfacher Benutzbarkeit und uberran-gender Qualitat seit dem Start im Jahre 2003 große Marktanteile von ehemalssehr popularen Anwendungen wie ICQ oder AIM fur sich gewinnen.Die Besonderheit von Skype liegt in der Struktur des zugrunde liegenden Netz-werkes. Dieses ist, basierend auf der Technologie des mittlerweile eingestelltenFile-Sharing Dienstes Kazaa, voll auf so genannte Peer-To-Peer Verbindungen -Direktverbindungen zwischen einzelnen Computern - ausgelegt.So werden nur fur den Vorgang der Anmeldung von Nutzern Server von Skypeselbst bereitgestellt. Alle anderen fur das Betreiben der verschiedenen Dienstenotwendigen Aufgaben werden auf die Endgerate der Nutzer ausgelagert.Diese spezielle Struktur gepaart mit der Tatsache, dass das Unternehmen Sky-pe, welches mittlerweile zum Internetkonzern eBay gehort, allgemein bemuhtist, technische Details uber sein Produkt geheimzuhalten, werfen naturlich Fra-gen zur Sicherheit der ubertragenen Daten auf.Konnen gefuhrte Telefonate abgehort werden? Wird irgendwo gespeichert wermit wem telefoniert hat?Unbestritten ist auf jeden Fall, dass Geheimdienste aus aller Welt ein großesInteresse daran haben, uber Skype gefuhrte Gesprache abzuhoren[4].Diese Unsicherheiten werden in dieser Arbeit zum Anlass genommen, moglicheVerfahren zu beschreiben und zu evaluieren, mit denen Gesprache uber Sky-pe abhorsicher - das heisst geschutzt durch sichere Kryptographieverfahren wieAES - gefuhrt werden konnten. Die besondere Herausforderung ist hier durchdie ungewohnlich komplexen Verschleierungsmaßnahmen von Seiten der Skype-Clients gegeben.

2 Bereits vorhandene Abhorschutzmaßnahmen

In 2006 wurde auf der bekannten IT-Sicherheitskonferenz BlackHat in Las Vegasein Vortrag von Ingenieuren des Unternehmens EADS gehalten [1], der einentieferen Einblick in die damalige Version des Skype-Clients fur Windows bot.In ihrem Vortrag unterstreichen Philippe Biondi und Fabrice Desclaux die Ve-hemenz mit der der Skype-Client fur Windows sich gegen jegliche Arten desReverse Engineerings zur Wehr setzt.Trotz dessen kommen die beiden Autoren zu dem Schluss, dass Kommunika-tion uber Skype, geschutzt durch die bekannten und bewahrten AlgorithmenAES und RSA, prinzipiell sicher ist. Jedoch weisen sie auch darauf hin, dass dasUnternehmen Skype als Betreiberin der Certificate Authority des Dienstes sehr

3

wohl zu so genannten Man-In-The-Middle Attacken in der Lage ist.Das heisst, wenn das Unternehmen Skype ein Interesse daran hat ein Gesprachzwischen zwei Skype-Clients abzuhoren, dann ist es dazu auch fahig.

Teil II

Mogliche AnsatzeDas Ziel ist es, uber die bereits vorhandene Verschluselungsschicht des Proto-kolls des Skype-Netzwerkes eine weitere, transparente und kontrollierbare Ver-schlusselungsschicht zu legen, ohne die Qualitat des Dienstes selber merklich zubeeinflussen. Die moglichen Ansatze und die sich ergebenden Schwierigkeitenwerden in diesem Kapitel behandelt. Dabei beziehen sich samtliche Aussagen,sofern nicht gegenteilig angemerkt, auf die Windows Version des Skype-Clients.

3 Allgemeine Schwierigkeiten

Als erste Idee fur die mogliche Realisierung eines Vorhabens wie dem beschrie-benen, ergibt sich naturlich der Weg uber ein mogliches Plugin-Interface o.a.mit Hilfe dessen Sprachdaten nach der Verarbeitung durch einen Audio-Codecund vor dem Versenden uber das Netzwerk abgefangen und verschlusselt werdenkonnten.Im Falle von Skype werden jedoch seit einiger Zeit keine Plugins mehr un-terstutzt und die offizielle API des Programms erlaubt kaum mehr als die Fern-steuerung der Benutzeroberflache[5].Dadurch, dass Skype sich zudem agressiv gegen Versuche des Reverse Enginee-rings wehrt und als nur eine einzelne monolithische .exe Datei von uber 20MBausgeliefert wird, bleibt kaum mehr, als das Programm als Black Box zu betrach-ten. Nach Einschatzung des Autors ergeben sich unter dieser Pramisse genau

Abbildung 1: Betrachtung von Skype als Black Box

4

zwei Ansatzpunkte fur eine zusatzliche Verschlusselungsschicht:Da Skype uber keine eigenen Treiber verfugt, ist es darauf angewiesen mit demWindows Betriebssystem zu kommunizieren, um a) Audiodaten vom Mikrofondes PCs zu lesen und Audiodaten uber die Soundkarte auszugeben und b) allge-mein Daten uber das Netzwerk zu verschicken (siehe auch Abbildung 1). An die-sen Schnittstellen sollte es, ohne genauere Kenntnis der inneren Funktionsweisenvon Skype zu haben, moglich sein, Daten abzugreifen und zu manipulieren.

4 Pre Audio Codec Verschlusselung

Als erster der beiden identifizierten Ansatze, soll hier die Moglichkeit diskutiertwerden Audiodaten vor dem Eingang in die Skype-Software zu verschlusselnund nach der Ausgabe aus dieser (und vor der Ausgabe uber die Lautsprecher)wieder zu entschlusseln.Die allergroßte Problematik bei diesem Ansatz ergibt sich durch die Tatsache,dass Skype selbstverstandlich Audiodaten vor dem Versenden uber das Netzwerkverlustbehaftet komprimiert und nach dem Empfang wieder entsprechend de-komprimiert. Man benotigt also ein Verschlusselungsverfahren, dass zum Einensicher ist und zum Anderen ein solches Komprimier- /Dekomprimierglied zu-verlassig verkraften kann. Ein solches Verfahren konnte trotz intensiver Recher-che nicht gefunden werden und es darf ruhig bezweifelt werden, ob solch einVerfahren uberhaupt technisch realisierbar ist. Im Falle von Skype kommt nocherschwerend hinzu, dass seit dem Jahre 2009 ein hoch komplexer, auf Spracheoptimierter und in jahrelanger Eigenentwicklung entstandener Audio-Codec na-mens SILK zum Einsatz kommt. Der Programmcode fur diesen Codec ist aller-dings offentlich zuganglich und ließe sich folglich einfach analysieren.

Ungeachtet der ganz eigenen Problematik die die Verschlusselung eines nochzu komprimierenden Audiostroms mit sich bringt, stellt sich hier als nachstesnaturlich die Frage, auf welche Art die Audiodaten am besten abgegriffen wer-den.Die nahe liegendste Herangehensweise fur so ein Vorhaben ist vermutlich dasProgrammieren eines speziellen Treibers der sich gegenuber dem Skype-Clientals Soundkarte mit Mikrofoneingang und Lautsprecherausgang ausgibt. DieserTreiber wurde als eine Art Vermittler zwischen der realen Soundkarte des Sys-tems und dem Skype-Client agieren und erst einmal einfach samtliche Datenund Anfragen weiterreichen. Zur Verschlusselung eines Telefonats wurden dannsamtliche von der realen Soundkarte kommenden Signale vor der Weiterleitungverschlusselt und samtliche von Skype kommenden Audiosignale vor der Wei-tergabe an die Soundkarte wieder entschlusselt.Auch wenn dieser Ansatz auf den ersten Blick als durchaus praktikabel erschei-nen mag, so erweist er sich bei naherer Betrachtung als außerst unpraktisch.So ist erst einmal das Programmieren eines Treibers eine außerst komplizierteund teure Angelegenheit, die auch noch sehr Plattform spezifisch ist - sollteso eine Software einmal auf ein anderes Betriebssystem wie z.B. Apples OS X

5

portiert werden sollen, so ware das Schreiben eines komplett neuen Treibersunerlasslich. Zudem ware es fur so eine

”Software-Soundkarte“ wohl unmoglich

zwischen tatsachlichen Sprachdaten und anderen Audioausgaben von Skype zuunterscheiden, was zu erheblichen Problemen bei der Synchronisation der Ent-schlusselung fuhren durfte.Die Losung liefert hier ein Blick in die Dokumentation der offentlichen API desSkype-Clients.

4.0.1 Skype API

Die Skype-Clients fur unterschiedliche Plattformen stellen uber eine API Funk-tionalitat fur eine automatische, textbasierte Bedienung bereit[5]. So lassensich beispielsweise mit dem Kommando

”SEARCH FRIENDS“ alle gespeicher-

ten Kontakte fur den aktuell eingeloggten Account erfragen und anschließendmit

”CALL myFriend“ einer dieser Kontakte anrufen. Skype-Clients antworten

ebenfalls in textbasierter Form.Interessant fur das gegebene Vorhaben sind die folgenden drei Befehle[5]:

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 ihnen ist es moglich, fur ein bestimmtes Telefonat die Audioein- und ausgangedes Skype-Clients sowie den Mikrofoneingang des Computers auf eine beliebigeSoundkarte, Datei oder einen Netzwerk-Port zu setzen. Dadurch ist es moglichdie Audiostrome so uber besimmte Netzwerk-Ports umzuleiten, dass diese ein-fach abgegriffen und manipuliert werden konnen - ohne das das Programmiereneines Treibers notig wird. Eine Skizze des Ansatze ist in Abbildung 2 zu sehen.Es bleibt die Frage, auf welchem Wege solche Befehle und die entsprechendenAntworten mit dem Skype-Client ausgetauscht werden. Unter Windows erfolgtdies uber so genannte Window Messages[7]. Diese Art der Kommunikation istfur Anwendungen wie die gegebene eher ungewohnlich und ist wohl der Tatsachegeschuldet, dass Skype prinzipiell versucht seine Client-Software abzuschotten.Um Nachrichten an das Fenster des Skype-Clients senden zu konnen mussman zunachst wissen welches der womoglich vielen Fenster auf einem Win-dows Desktop das gesuchte ist. Dazu sendet man eine so genannte

”Broadcast

Message“ an samtliche Fenster und wartet auf eine Anwort des Skype-Clients(Abbildung 3). Danach konnen textbasierte Kommandos einfach per WindowsAPI SendMessage() [8] direkt an das Skype Fenster gesendet werden. Auf dieentsprechenden Antworten von Skype lasst sich danach mit WaitMessage() [9]warten.Das Open-Source Projekt Skype4Py hat es sich zur Aufgabe gemacht, dieses

6

Abbildung 2: Umleitung von Audiostromen des Skype-Clients und des Mikrofonsuber Netzwerk-Ports

Abbildung 3: Identifizierung des Skype Fensters

doch recht unhandliche System zu Kapseln und ein einfacheres Interface fur dieSkriptsprache Python bereitzustellen[10]. Neben Windows ist dieses fur OS Xund Linux erhaltlich und somit quasi plattformunabhangig.Im Rahmen dieser Arbeit wurde zu Demonstrationszwecken ein Python Skripterstellt, dass unter Verwendung von Skype4Py die Audiostrome des Skype-Clients nach Abbildung 2 so umleitet, dass diese manipuliert werden konnen:

Listing 1: Verschlusselung des ausgehenden Audiostroms

import sysimport Skype4Pyimport socke t

def encrypt ( audio ) :encrypted = ””#dummy encryp t ion !

7

for b in audio :encrypted += chr ( ( ord (b)ˆ0xAA)&0xFF)

return encrypted

def OnCall ( c a l l , s t a t u s ) :global Cal lS ta tusglobal WavFileglobal outPortCa l lS ta tus = s t a t u sprint ’ Ca l l s t a t u s : ’ + skype . Convert . Cal lStatusToText ( s t a t u s )

i f ( s t a t u s == Skype4Py . c l sEar lyMedia or s t a t u s ==Skype4Py . c l s I n P r o g r e s s ) and outPort != ’ ’ :

print ’ Saving vo i c e to ’ + outPortc a l l . OutputDevice ( Skype4Py . ca l l IoDeviceTypePort , OutPort )outPort=’ ’

i f s t a t u s == Skype4Py . c l s I n P r o g r e s s and micPort != ’ ’ :print ’ Writing mic−in to ’ + micPortc a l l . CaptureMicDevice ( Skype4Py . ca l l IoDev iceTypePort , micPort )

i f s t a t u s == Skype4Py . c l s I n P r o g r e s s and inPort != ’ ’ :print ’ Reading vo i c e from ’ + inPortc a l l . InputDevice ( Skype4Py . ca l l IoDeviceTypePort , inPort )

def AttachmentStatusText ( s t a t u s ) :return skype . Convert . AttachmentStatusToText ( s t a t u s )

# This hand ler i s f i r e d when Skype at ta tchment s t a t u s changesdef OnAttach ( s t a t u s ) :

print ’API attachment s t a t u s : ’ + AttachmentStatusText ( s t a t u s )i f s t a t u s == Skype4Py . ap iAttachAva i lab le :

skype . Attach ( )

def OnReply ( va lue ) :print ”Reply : ” +value . Reply

def OnCommand( value ) :print ”Command: ” +value .Command

def OnApplicationSending ( va lue ) :print ” Appl i ca t ion sending : ” +value

8

#s e t t i n g p o r t sinPort = ”22042”

outPort = ””micPort =”22041”

# Creat ing Skype o b j e c t and a s s i g n i n g event h a n d l e r s . .skype = Skype4Py . Skype ( )skype . OnAttachmentStatus = OnAttachskype . OnCallStatus = OnCallskype .OnCommand = OnCommandskype . OnApplicationSending = OnApplicationSending

# S t a r t i n g Skype i f i t ’ s not running a l r e a d y . .i f not skype . C l i en t . IsRunning :

print ’ S t a r t i ng Skype . . ’skype . C l i en t . S ta r t ( )

# A t t a t c h i n g to Skype . .print ’ Connecting to Skype . . ’skype . Attach ( )

print ’ Ca l l i ng echo123 ’

callCmd = ”CALL echo123 ”

skypeCmd = Skype4Py . skype .Command(Command=callCmd , Blocking=True )skype . SendCommand( skypeCmd)print skypeCmd . Reply

serverMic = socket . socke t ( socket . AF INET , socket .SOCK STREAM)serverMic . bind ( ( ”” , 22041))

s e r v e r I n = socket . socke t ( socket . AF INET , socket .SOCK STREAM)s e r v e r I n . bind ( ( ”” , 22042))

serverMic . l i s t e n (1 )( c l i entMic , address ) = serverMic . accept ( )

s e r v e r I n . l i s t e n (1 )( c l i e n t I n , address ) = s e r v e r I n . accept ( )

print ” got connec t i ons ”

while ( True ) :

9

mic = c l i en tMic . recv (1000)

#encrypt audio stream from micencryptedMic = encrypt ( mic )

c l i e n t I n . send ( encryptedMic )

Das Skript startet ein Telefonat mit dem immer erreichbaren Skype-Testnutzerecho123 und leitet dabei samtliche vom Mikrofon des PCs kommende Audioda-ten durch die Funktion encrypt() bevor diese an den Skype-Client weitergereichtwerden.Es sei angemerkt, dass Teile des Programmcodes aus Beispielskripten des Sky-pe4Py Projektes ubernommen wurden.

4.0.2 Zusammenfassung

Es wurde gezeigt, dass es ohne Verwendung von speziellen Treibern mit Hilfe desOpen Source Projekts Skype4Py plattformunabhangig moglich ist, die ein- undausgehenden Audiostrome des Skype-Clients abzufangen und zu manipulieren.Weiterhin ungeklart ist jedoch, wie und ob es moglich ist, Audiodaten verlasslichund sicher zu verschlusseln, die einen verlustbehafteten Audio-Codec durchlau-fen.TODO: Voteile

5 Netzwerkpaketverschlusselung

Als zweiter Ansatz zur Verschlusselung von Telefonaten uber das Skype Netz-werk, wurde das Manipulieren von Daten auf Netzwerkpaketebene identifiziert.Anders als beim bereits behandelten Ansatz des Abfangens von Audiostromen,stellt die Skype API jedoch keinerlei Funktionalitat betreffend des Netzwerk-verkehrs des Skype-Clients bereit. Hier ist also eine andere Herangehensweisenotwendig.Um Daten uber das Netzwerk verschicken zu konnen, ist jeder Skype-Clientdarauf angewiesen diese an das Betriebssystem zu ubergeben. Unter Windowsfuhrt dafur fur kein Programm ein Weg vorbei an der Verwendung der Windowseigenen API-Funktionen. Um diese Verwenden zu konnen, muss ein Prozess diepassenden Dlls wie z.B. kernel32.dll oder user32.dll des Betriebssystem in sei-nen Adressraum laden und die entsprechenden Funktionen aus diesen aufrufen.Der Kontrollfluss eines Programms verzweigt also in gegen Analyse ungeschutzteDlls des Windows Betriebssystems (sie auch Abbildung 4).

Diese Tatsache wird sich allgemein haufig zunutze gemacht, wenn unter Win-dows das Verhalten eines Programmes (z.B. eines Virus) generisch uberpruftoder manipuliert werden soll.So uberschreiben beispielsweise eine Vielzahl von Anti-Viren Losungen die Ein-stiegspunkte von API-Funktionen der System-Dlls dynamisch mit einer Art Um-leitung in ihren eigenen Programmcode - im Fachjargon

”Hook“ genannt - um

10

Abbildung 4: Skype Prozess mit geladenen Windows System-Dlls

Programme auf verdachtige Verhaltensmuster hin zu uberprufen.Mit genau dieser Technik ist es auch moglich die Interaktion zwischen Skype-Client und Windows Betriebssystem abzuhoren und zu manipulieren.

5.1 Win32 API Hooking

Die”Best Practice“ zur Umleitung von Aufrufen von Windows-APIs innerhalb

eines beliebigen Prozesses wird in [11] beschrieben. Wie dort dargelegt, lasstsich unter allen neueren Windows Betriebssystemen mit einem Kniff eine belie-bige Dll in jeden Prozess laden. So wird es moglich, Daten und Kontrollflusseinnerhalb eines Prozesses beinahe beliebig zu verandern - und somit auch Hooksan Einstiegspunkten zu Windows-APIs zu platzieren.Eine entsprechende Dll zum

”hooken“ von API-Funktionen, zusammen mit ei-

nem flexliblen Interface fur die Skriptsprache Python wurde vom Autor dieserArbeit bereits fur ein fruheres Projekt in Grundzugen implementiert. Die Funk-tionsweise des Ansatzes ist schematisch in Abbildung 5 dargestellt.Nach dem Laden der hook.dll in den Adressraum des Skype-Prozesses nimmt je-ne Dll uber so genannte

”Named Pipes“ Kontakt mit dem Python-Interface auf

und wartet auf Anweisungen. Soll nun eine bestimmte API-Funktion gehooktwerden, so wird der Einstiegspunkt dieser Funktion mit einem Sprung zu einerbestimmten Funktion in hook.dll uberschrieben. Sobald hook.dll so den Aufrufeiner API-Funktion registriert, teilt es dies dem Python-Interface mit, wo dannbeliebige Aktionen durchgefuhrt werden konnen (z.B. Auslesen von Argumentender gehookten API-Funktion).

Fur diese Arbeit wurde der Programmcode der Dll und des Interfaces erheb-lich um Funktionalitat erweitert und angepasst. So ist es beispielsweise in deraktuell vorliegenden Version mit den folgenden Zeilen Python-Code moglich, alle

11

Abbildung 5: Python API-Hooking Framework mit Skype Prozess

Aufrufe von samtlichen API-Funktionen der System-Dll WS2 32.dll1 innerhalbdes Skype-Prozesses mitzuschneiden und auszugeben.

Listing 2: Mitschneiden von Aufrufen von API-Funktionen aus WS2 32.dll

from hookClass import hookedProcessfrom ctypes import ∗from win32 import ∗import p e f i l e

#. . .

kerne l32 = wind l l . ke rne l32user32 = wind l l . user32

def printApiName ( process , apiName , addrRet , args ) :

#p r i n t name o f c a l l e d API f u n c t i o nprint ”WS2 32.%s ( ) ” % apiNamereturn True

proce s s = hookedProcess ( )#s e t skype . exe as t a r g e tproce s s . setUp ( ” skype . exe ” , HOOK PATH, PIPE SEND , PIPE RECIEVE)

1WS2 32.dll stellt unter Windows u.a. samtliche Standard-C Netzwerkfunktionen wieconnect(), send() oder recv() bereit und ist somit hier von besonderem Interesse.

12

#load ws2 32 . d l lpe = p e f i l e .PE( ”c :\\Windows\\ system32 \\ws2 32 . d l l ” )#i t e r a t e over a l l named e x p o r t s . . .for exp in pe .DIRECTORY ENTRY EXPORT. symbols :

i f exp . name != None :#. . . and hook themproce s s . hookAPI ( ” ws2 32 . d l l ” , exp . name , 0 , printApiName )

#run Skypeproce s s . run ( )

In dem gegebenen Beispielskript wird mit Hilfe des Open-Source Projektspefile zunachst uber alle von WS2 32.dll bereitgestellten API-Funktionen ite-riert. Jede vorhandene API-Funktion wird dabei gehookt, wobei als so genannter

”Callback“ die Python-Funktion printApiName() angeben wird. Dies bewirkt,

dass der Name jeder aufgerufenen Api-Funktion auf der Konsole ausgegebenwird.So meldet das Skript beispielsweise folgende Aufrufe unmittelbar nach dem Startder Skype.exe:

WS2_32.WSAStartup()WS2_32.WahCreateHandleContextTable()WS2_32.WahOpenApcHelper()WS2_32.WahOpenCurrentThread()WS2_32.socket()WS2_32.WahOpenCurrentThread()WS2_32.WSASocketW()WS2_32.WahCreateHandleContextTable()WS2_32.WahInsertHandleContext()WS2_32.WahInsertHandleContext()WS2_32.WahReferenceContextByHandle()WS2_32.ioctlsocket()WS2_32.WSAIoctl()WS2_32.WahReferenceContextByHandle()WS2_32.WahReferenceContextByHandle()WS2_32.setsockopt()WS2_32.WahReferenceContextByHandle()WS2_32.WahReferenceContextByHandle()WS2_32.setsockopt()WS2_32.WahReferenceContextByHandle()WS2_32.WahReferenceContextByHandle()WS2_32.ntohl()WS2_32.htonl()WS2_32.ntohs()WS2_32.htons()WS2_32.bind()

13

WS2_32.WahReferenceContextByHandle()WS2_32.WahReferenceContextByHandle()WS2_32.getsockname()WS2_32.WahReferenceContextByHandle()WS2_32.WahReferenceContextByHandle()WS2_32.ntohl()WS2_32.htonl()WS2_32.ntohs()WS2_32.htons()WS2_32.ntohl()WS2_32.htonl()WS2_32.ntohs()WS2_32.htons()WS2_32.sendto()WS2_32.WahReferenceContextByHandle()WS2_32.WahReferenceContextByHandle()WS2_32.ntohs()WS2_32.htons()WS2_32.socket()WS2_32.ntohl()WS2_32.WSASocketW()WS2_32.htonl()WS2_32.WahInsertHandleContext()WS2_32.ntohs()WS2_32.WahInsertHandleContext()WS2_32.htons()WS2_32.WahReferenceContextByHandle()WS2_32.sendto()WS2_32.WSAIoctl()WS2_32.WahOpenCurrentThread()WS2_32.WahReferenceContextByHandle()...

Lasst man genau dieses Skript wahrend eines Gesprachs mit einem anderenSkype-Teilnehmer laufen, so zeigt sich, dass zum Aufbau einer Verbindung dieSocket gebundenen API-Funktionen send() und recv() verwendet werden, umKontakt mit dem Skype-Client des gewunschten Gesprachspartners aufzuneh-men.Sobald jedoch eine Verbindung hergestellt und der Angerufene das Gesprachakzeptiert hat, werden die eigentlichen Gesprachsdaten verbindungslos in ein-zelnen UDP-Paketen mit Hilfe der API-Funktionen sendto() und recvfrom()gesendet bzw. empfangen[12].Die Pakete wurden dabei in allen im Rahmen dieser Arbeit durchgefuhrten Testsdirekt und ohne Umwege zwischen den beiden beteiligten Clients hin und her ge-sandt. Die entsprechenden IP-Adressen konnten aus den an die API-Funktionensendto() und recvfrom() ubergebenen Argumenten direkt entnommen werden.

14

Ebenso konnte ohne Probleme auf die zu sendenden und empfangenen Nutzda-ten zugegriffen werden.Es ist also moglich, samtliche Sprachpakete2 eines Gesprachs an der Schnittstel-le zwischen Skype und der Windows-API abzufangen, zu manipulieren und derjeweiligen Empfanger- bzw. Absender IP-Adresse zuzuordnen.Somit kann eine weitere, uberprufbare Verschlusselungsschicht unter Windowsrealisiert werden.

5.2 Konzept zur Implementierung

Im vorangegangenen Abschnitt wurde gezeigt, dass es moglich ist, Gesprachezwischen zwei Skype-Clients unter Windows gezielt zu verschlusseln.In diesem Abschnitt sollen dazu ein konkretes Konzept fur eine tatsachliche Im-plementierung entworfen werden.

Die Problematik bei der Realisierung der gestellten Aufgabe ist, dass nichtsamtliche uber WS2 32.sendto() ausgehende Pakete verschlusselt werden durfen.Umgekehrt gilt das Gleiche fur uber WS2 32.recvfrom() eingehende Pakete.Denn neben den eigentlichen Gesprachsdaten verwendet Skype diese API-Funktionenfur eine Vielzahl anderer Kommunikationsaufgaben innerhalb des Skype-Netzwerkes.Sollten dabei die falschen Pakete manipuliert werden, so ware es sehr wahr-scheinlich, dass die Funktionalitat des betroffenen Clients eingeschrankt wurde.Es ist also unabdingbar, ein- und ausgehende Pakete korrekt in Bezug aufEmpfanger/Absender als auch Inhalt zuzuordnen. Letzteres ist ohne Kenntnisder nicht offentlichen Verschlusselungsverfahren des Skype-Netzwerkes naturlichnur mit heuristischen Ansatzen moglich.Fur die konkrete Implementierung erscheint eine Losung aus zwei Komponentenam komfortabelsten. Der Aufbau dieser beiden Komponenten wird im Folgen-den umrissen. Eine schematische Darstellung ist in Abbildung 6 zu sehen.

5.2.1 C# Komponente - GUI

In der Programmiersprache C# ist es besonders einfach grafische Oberflachenfur Windows Betriebssysteme zu entwickeln. Entsprechend liegt es nahe, die Be-nutzeroberflache der Verschlusselungslosung mit dieser Sprache zu entwickeln.Hinzu kommt, dass mit Hilfe des Open-Source Projektes Skype4COM, ahnlichwie bei Skype4Py fur Python, sehr komfortabel auf die Skype-API zugegriffenwerden kann.

Mit Hilfe von Skype4COM, soll die C# GUI-Komponente auf ein- und aus-gehende Telefonate warten. Trifft eines der beiden Ereignisse ein, so soll eine

2Diese Sprachpakete wurden zuvor in jedem Fall bereits von Skype verschlusselt. Ohnegenaue Kenntnis des internen Verschlusselungsverfahren des Skype-Netzwerkes ist es also nichtmoglich den eigentlichen Inhalt der Pakete einzusehen.

15

Abbildung 6: Konzept der zu entwickelnden Software

Textnachricht an den Gesprachspartner geschickt werden, um zu uberprufen, obdieser uber eine kompatible Verschlusselungssoftware verfugt. Ist dies der Fall,so sollen beide Seiten zunachst ihre IP-Adressen austauschen (fur die spate-re Zuordnung von Netzwerkpaketen) und anschließend einen kryptographischenSchlussel fur die anstehende Sitzung vereinbaren.Danach stoßt die C# Anwendung die Injezierung einer Dll (hook.dll im Folgen-den) zum hooken der beiden API-Funktionen WS2 32.sendto() und WS2 32.recvfrom()in den Prozess der Skype.exe an. Bevor das anstehende Telefonat freigegebenwird, wird hook.dll noch uber eine Named Pipe der zu vereinbarte Sitzungs-chlussel und die IP-Adresse des Gesprachspartners mitgeteilt. Von diesem Zeit-punkt an, soll hook.dll alle Pakete an diese IP-Adresse mit dem gegebenenSchlussel verschlusseln und umgekehrt eingehende Pakete entschlusseln.

5.2.2 C/C++ Komponente - hook.dll

Aus Gesichtspunkten der Verarbeitungsgeschwindigkeit ist es nicht sinnvoll,dass fur das Prototyping verwendete Hooking-Framework auch in der fertigenAnwendung zu benutzen. Stattdessen soll besagte hook.dll neu in der Spra-che C entwickelt werden, die sich auf das Hooken von WS2 32.sendto() undWS2 32.recvfrom() zur Ver- bzw. Entschlusselung beschrankt. Als einzige wei-tere Funktion ist das Lesen von Sitzungsschlussel und Gesprachspartner-IP voneiner Named Pipe zu implementieren.Zur konkreten Realisierung der API-Hooking Funktionalitat bietet sich die Ver-wendung von Microsofts kostenlosem SDK Detours an [13].Ob zur Ver- bzw. Entschlusselung am besten eine Strom- oder eine Blockchiffrenzu verwenden ist, muss noch geklart werden.

5.3 Zusammenfasung

Es wurde gezeigt, dass es mit Hilfe von API-Hooking unter Windows moglichist Gesprache zwischen zwei Skype-Clients zu verschlusseln. Dazu wurde ein

16

konkretes Konzept zur Entwicklung einer entsprechenden Anwendung geliefert.Ungeklart bleibt die Frage wie Konferenzgesprache zu handhaben sind. Diesewurde in den durchgefuhrten Versuchen nicht berucksichtigt.Des Weiteren bleibt zu klaren wie im Falle des Relaying von Gesprachen zuverfahren ist. Dabei werden nach [2] die Daten eines Gesprachs nicht direkt zwi-schen den Clients ausgetauscht, sondern uber einen dritten Skype-Teilnehmergeleitet. Die zuordnung nach IP-Adressen durfte hier also erstmal fehlschlagen.Das der Ansatz des API-Hookings auch auf anderen Betriebssystemen als Win-dows sinnvoll zu implementieren ist zu erwarten, bleibt aber ebenfalls ungeklart.

17

Literatur

[1] Biondi, Desclaux (2006), Silver Needle in the Skype

[2] Hayes (2008), Skype: A Practical Security Analysis

[3] Microsoft Developer Network, Winsock Reference [Online] http://msdn.microsoft.com/en-us/library/ms741394(VS.85).aspx

[4] heise online, Bericht: NSA bietet Milliarden, um Skype ab-zuhoren [Online] http://www.heise.de/newsticker/meldung/Bericht-NSA-bietet-Milliarden-um-Skype-abzuhoeren-195547.html

[5] Skype Public API [Online] http://developer.skype.com/accessories

[6] SILK: Super Wideband Audio Codec [Online] http://developer.skype.com/silk

[7] Microsoft Developer Network, About Messages and Message Queu-es [Online] http://msdn.microsoft.com/en-us/library/ms644927(VS.85).aspx

[8] Microsoft Developer Network, SendMessage [Online] http://msdn.microsoft.com/en-us/library/ms644950(VS.85).aspx

[9] Microsoft Developer Network, WaitMessage [Online] http://msdn.microsoft.com/en-us/library/ms644956(v=VS.85).aspx

[10] SourceForge, Skype4Py [Online] http://sourceforge.net/projects/skype4py/files/

[11] Ivo Ivanov, API hooking revealed [Online] http://www.codeproject.com/KB/system/hooksys.aspx

[12] Microsoft Developer Network, sendto [Online] http://msdn.microsoft.com/en-us/library/ms740148(VS.85).aspx

[13] Microsoft Blogs, detours [Online] http://blogs.msdn.com/b/junfeng/archive/2006/08/24/720978.aspx

18