SPIT und Privacy im Kontext des IMS

Transcrição

Hochschule Darmstadt
- Fachbereich Informatik -
Spam over Internet Telephony und Privacy im Kontext des IP Multimedia
Subsystem
Abschlussarbeit zur Erlangung des akademischen Grades
Master of Science (M.Sc.)
vorgelegt von
Jürgen Müller
Referent:
Prof. Dr. Michael Massoth
Korreferent: Prof. Dr. Stephan Karczewski
Ausgabedatum: 31.03.2009
Abgabedatum:
30.09.2009
ii
Erklärung
Ich versichere hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine
anderen als die im Literaturverzeichnis angegebenen Quellen benutzt habe. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder noch nicht veröffentlichten
Quellen entnommen sind, sind als solche kenntlich gemacht. Die Zeichnungen oder
Abbildungen in dieser Arbeit sind von mir selbst erstellt worden oder mit einem entsprechenden Quellennachweis versehen. Diese Arbeit ist in gleicher oder ähnlicher Form
noch bei keiner anderen Prüfungsbehörde eingereicht worden.
Darmstadt, den 30.09.2009
Jürgen Müller
iii
Erklärung
iv
Abstrakt
Die Umstellung auf die nächste Generation der Netze, die sogenannten Next Generation
Networks (NGNs) schreitet immer weiter voran. Eine der essenziellen Technologien für die
neuen Kernnetze ist das IMS.
Parallel hierzu entwickelt sich das Aufkommen von Spam stark steigend. In den vergangenen Jahren hat sich die Quantität von E-Mail-Spam auf rund 85 % gesteigert. Eine derartige
Entwicklung im Voice over IP (VoIP)-Bereich könnte den gesamten Dienst gefährden. Dass
es Spam over Internet Telephony (SPIT) gibt, belegt ein Versuch der Universität DuisburgEssen. Auf einem dort testweise eingerichteten Honeypot konnte der Versand von SPIT nachgewiesen werden. Damit ist belegt, dass es sich bei SPIT um kein fiktives Problem handelt.
Deshalb werden im Rahmen dieser Arbeit Abwehrmaßnahmen ermittelt, die das SPITAufkommen eindämmen. Diese Mechanismen sind jedoch wirkungslos, wenn keine starken
Identitäten gewährleistet sind. Aus diesem Grund werden Sicherheitsverfahren beschrieben,
die den Teilnehmer authentifizieren.
Das Session Initiation Protocol (SIP) gewährt jedoch die Möglichkeit, Telefonate direkt
zwischen zwei Endgeräten zu führen. Da durch die direkte Übertragung des SPIT das IMS
umgangen wird, kann das Endgerät nicht serverseitig geschützt werden. Deshalb wird im
Rahmen dieser Arbeit ein Konzept entworfen und untersucht, um in solchen Fällen Schutz
zu bieten.
The change into Next Generation Networks (NGNs) is in progress. One of the keytechnologies for the new corenetworks is the IMS.
At the same time the amount of E-Mail-Spam is growing. The quantity of E-Mail-Spam
has risen to around 85 %. This development in the Voice over IP (VoIP)-Sector threatens
the whole service. The existance of Spam over Internet Telephony (SPIT) was proven by an
experiment of the University of Duisburg-Essen. The distribution of SPIT was demonstrated
by an experimental Honeypot. This proves, that SPIT is a real problem.
v
Abstrakt
The object of this thesis is to establish methods of SPIT-prevention. However, these methods only work with strong identitys. For this reason the thesis at hand describes securityprocedures for authentication of the participants.
But the Session Initiation Protocol (SIP) allows peer-to-peer-calls. Since the direct transmission of SPIT bypasses the IMS, servers are not able to check the messages for SPIT.
Therefore this thesis developes a concept to provide protection against this form of SPIT.
Schlüsselwörter: IP Multimedia Subsystem, Next Generation Network, Spam, Spam over
Internet Telephony, Session Initiation Protocol, Voice over IP.
vi
Vorwort
Anders als bei meiner Bachelorarbeit muss ich dieses Mal dem wichtigsten Menschen in
meinem Leben als erstes Danken. Janina, ohne dich wäre ich heute vermutlich kein Student.
Ohne dich würde ich mich und meine Umgebung nicht reflektieren, ich würde nicht darauf
achten, was ich esse, wie ich mich kleide oder wo ich in meinem Leben hin will. Kurz, du
gibst mir sehr viel und ich hoffe, ich kann es dir wieder zurückgeben. Das Wichtigste was ich
dir hier sagen will, ich liebe dich von ganzem Herzen.
Meinen Eltern gilt ein ganz besonderer Dank. Während des Masterstudiums mussten sie
mir leider deutlich öfters helfen, als während des Bachelors. Für die liebevolle Hilfe möchte
ich mich daher hier nochmals bedanken.
Ganz besonders muss ich Christine danken. Im Masterstudium haben wird oft zusammengearbeitet und waren immer ein gutes Team. Doch gerade beim Schreiben dieser Arbeit war
sie mir eine sehr große Hilfe. Sie hat besonders oft, früh und viel für mich korrektur gelesen,
danke.
Aber Christine war zum Glück nicht die Einzige, die mir hilfreich zur Seite stand. Als
nächstes will ich hier Klaus und Stephan danken. Wir haben zusammen angefangen zu
studieren und wären alleine nicht entsprechend erfolgreich gewesen. Vielen Dank.
Natürlich will ich all meinen restlichen Korrekturlesern danken. Rebecca danke für die
Hilfe beim englischen Abstrakt. Andreas danke für deine weitsichtigen Kritiken an meinem
Aufbau und der Hinterfragung meiner schriftlichen Aussagen.
Nach meinen schlechten Erfahrungen während der Bachelorarbeit war ich sehr skeptisch,
ob ich einen Betreuer brauche oder will. Trotz, dass ich in Kassel wohne und das FraunhoferInstitut sehr weit weg ist, war mir Rachid eine sehr große Hilfe, ohne die ich es nicht geschafft
hätte. Dafür möchte ich ihm sehr danken.
Natürlich will ich auch meinen Referenten Prof. Dr. Michael Massoth und Prof. Dr.
Stephan Karczewski danken. Darüber hinaus muss ich Prof. Dr. Elke Hergenröther
danken, da sie für mich meine Mentorin war.
Natürlich habe ich nicht alle genannt, die vielleicht genannt werden müssten. Vermutlich
habe ich im Abgabestress vergessen, euch zu erwähnen. Daher anonymer weise, vielen Dank.
vii
viii
Inhaltsverzeichnis
Erklärung
iii
Abstrakt
v
Vorwort
vii
Abbildungsverzeichnis
xiii
1 Einleitung
1
1.1
Motivation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Wirtschaftlicher Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.4
Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Next Generation Network
2.1
2.2
2.3
5
Session Initiation Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
Begriffserklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.2
Nachrichtenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.1.3
Nachrichtentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.1.4
Adressierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.1.5
Prozeduren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.1.6
Netzelemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
IP Multimedia Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.2.1
27
2.2.2
Adressierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.2.3
Prozeduren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.2.4
Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3 Spam over Internet Telephony
37
ix
Inhaltsverzeichnis
3.1
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.1.1
Herkunft des Wortes Spam . . . . . . . . . . . . . . . . . . . . . . . .
38
3.1.2
Bedeutung in dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . .
38
3.1.3
Formen von Spam mittels Session Initiation Protcol . . . . . . . . . .
39
3.2
Soziale Auswirkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.3
Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.3.1
Informationen sammeln . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.3.2
Sitzung etablieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.3.3
Nachricht übertragen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.4
Kostenberechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.5
Gesetzeslage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.5.1
48
3.5.2
Rechtmäßiges Direktmarketing . . . . . . . . . . . . . . . . . . . . . .
48
3.5.3
Möglichkeiten der Strafbarkeit . . . . . . . . . . . . . . . . . . . . . .
50
3.5.4
Regelungen für Internet Service Provider . . . . . . . . . . . . . . . .
51
52
3.6
4 Abwehrmaßnahmen
4.1
53
Identität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.1.1
Blacklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.1.2
Whitelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.1.3
Graylists
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.1.4
Device Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.1.5
Reputationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.2
Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.3
Interaktiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.3.1
Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.3.2
Payments at Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.3.3
Turingtests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.3.4
Computational Puzzles
. . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.3.5
Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
Präventiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.4.1
Adressen verbergen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.4.2
Adressen streuen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.4.3
Teilnehmerverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.4.4
Umgang mit empfangenem Spam . . . . . . . . . . . . . . . . . . . . .
72
72
4.4
4.5
5 Sicherheitsverfahren
5.1
x
Hypertext Transport Protocol Authentication . . . . . . . . . . . . . . . . . .
75
76
Inhaltsverzeichnis
5.2
5.3
5.4
5.5
5.6
5.1.1
Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.1.2
Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.1.3
Anwendungsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.1.4
Authentication and Key Agreement . . . . . . . . . . . . . . . . . . .
82
Session Initiation Protocol Security . . . . . . . . . . . . . . . . . . . . . . . .
84
5.2.1
Transport Layer Security . . . . . . . . . . . . . . . . . . . . . . . . .
84
5.2.2
Anwendungsszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
Privacy-Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
5.3.1
Anonymisierungsstufen
. . . . . . . . . . . . . . . . . . . . . . . . . .
87
5.3.2
Anonymisierungsverhalten . . . . . . . . . . . . . . . . . . . . . . . . .
87
Secure/Multipurpose Internet Mail Extensions . . . . . . . . . . . . . . . . .
88
5.4.1
Schlüsselaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
5.4.2
Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
Internet Protocol Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.5.1
Sicherheitsassoziationen . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.5.2
Sicherheitsmodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.5.3
Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
92
6 Direct-IP-SPIT-Schutz
95
6.1
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
6.2
Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
6.2.1
Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
6.2.2
Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
Machbarkeitsstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
6.3.1
Existenz des Anrufers beim Betreiber überprüfen . . . . . . . . . . . .
99
6.3.2
Direkte Überprüfung der Existenz des Anrufers . . . . . . . . . . . . . 102
6.3.3
Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.3.4
Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.3
6.4
6.5
Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.4.1
Performance
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.4.2
Akzeptanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.4.3
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7 Zusammenfassung
113
7.1
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.2
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Glossary
117
xi
Inhaltsverzeichnis
Literatur- und Quellenverzeichnis
125
Request for Comments-Verzeichnis
133
CD-ROM (im rückseitigen Einband)
xii
2.1
Server- und Client-Rollenverteilung bei einem normalen Telefonat. . . . . . .
7
2.2
Verteilung von Transactions und Sitzung. . . . . . . . . . . . . . . . . . . . .
8
2.3
Three-Way-Handshake mit zwei Transactions. . . . . . . . . . . . . . . . . . .
8
2.4
Three-Way-Handshake mit einer Transaction. . . . . . . . . . . . . . . . . . .
9
2.5
Veranschaulichung des Dialogs. . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.6
Aufbau einer SIP-Nachricht. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.7
Relation zwischen permanentem und temporärem SIPURI. . . . . . . . . . .
22
2.8
Teilnehmerregistrierung mittels Session Initiation Protocol. . . . . . . . . . .
22
2.9
Der Three-Way-Handshake. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.10 Beispiele für einen User Agent. . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.11 Veranschaulichung des SIP-Trapezoid-Begriffs.
. . . . . . . . . . . . . . . . .
26
2.12 Relation zwischen IMPI und IMPU. . . . . . . . . . . . . . . . . . . . . . . .
29
2.13 Ablauf der Registrierung im IMS. . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.14 Sitzungsaufbau im IMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.15 Ausschnitt aus der Referenzarchitektur des IMS. . . . . . . . . . . . . . . . .
31
2.16 Skizze einer Universal Integrated Circuit Card. . . . . . . . . . . . . . . . . .
34
3.1
Drei Schritte zum SPIT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.2
Ablauf beim Double-Opt-IN. . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.1
Kategorisierung der Abwehrmaßnahmen. . . . . . . . . . . . . . . . . . . . . .
53
4.2
Ein Beispiel für ein bildbasiertes CAPTCHA. . . . . . . . . . . . . . . . . . .
62
4.3
Umgehung eines CAPTCHAs. . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.4
Explosionsskizzenbeispiel einer Bild-Adresse aus mehreren Teilen. . . . . . . .
67
5.1
Kategorisierung der Sicherheitsverfahren. . . . . . . . . . . . . . . . . . . . .
75
5.2
Berechnung des gemeinsamen Geheimnises mittels MD5-Algorithmus. . . . .
77
5.3
Registrierung mit HTTP Authentication. . . . . . . . . . . . . . . . . . . . .
79
5.4
Proxy-Sitzungsaufbau mit HTTP Authentication. . . . . . . . . . . . . . . . .
80
xiii
5.5
Peer-to-Peer-Sitzungsaufbau mit HTTP Authentication. . . . . . . . . . . . .
82
5.6
Berechnung des Nonce-Wertes mit AKA. . . . . . . . . . . . . . . . . . . . . .
83
5.7
Transport Layer Security-Schichtenmodell. . . . . . . . . . . . . . . . . . . . .
85
5.8
Domainübergreifender SIPS-Verbindungsaufbau. . . . . . . . . . . . . . . . .
86
5.9
Ende-zu-Ende-Sicherung.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.10 Netz-zu-Netz-Sicherung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
5.11 Integration des AH-Headers in ein IP-Paket. . . . . . . . . . . . . . . . . . . .
92
6.1
Abfolge der Responses 100 Trying und 180 Ringing. . . . . . . . . . . . . . .
97
6.2
Konzeptionelle Änderung im Ablauf eines Direct-IP-Calls. . . . . . . . . . . .
98
6.3
Ablauf eines verifizierten Anrufs mit DERIVE. . . . . . . . . . . . . . . . . . 101
6.4
Erfolgreicher Angriff trotz DERIVE. . . . . . . . . . . . . . . . . . . . . . . . 102
6.5
Implementierte Änderung im Ablauf eines Direct-IP-Calls. . . . . . . . . . . . 105
6.6
Boxplot der Messergebnisse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.7
Boxplot der Messergebnisse bis zum 90 % Perzentil. . . . . . . . . . . . . . . 108
6.8
Standardabweichung um das arithmetische Mittel. . . . . . . . . . . . . . . . 109
6.9
Konfidenzintervall beider Messungen. . . . . . . . . . . . . . . . . . . . . . . . 110
6.10 Verteilung der Spamkosten für das Jahr 2009. . . . . . . . . . . . . . . . . . . 111
7.1
xiv
Reduktion von SPIT via Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Kapitel
1
Einleitung
Zu Beginn wird die Motivation beschrieben, die zur Erstellung dieser Arbeit geführt hat (vgl.
Abschn. 1.1, S. 1). Anschließend wird die genaue Aufgabenstellung zur Anfertigung dieser
Masterarbeit dargestellt (vgl. Abschn. 1.2, S. 2). Danach wird der wirtschaftliche Nutzen
dieser Arbeit beschrieben (vgl. Abschn. 1.3, S. 2). Als letztes folgt ein kurzer Überblick über
den Aufbau der vorliegenden Arbeit (vgl. Abschn. 1.4, S. 3).
1.1 Motivation
Seit dem Wintersemester 2007 wird an der Hochschule Darmstadt das Projekt Systementwicklung mit dem Ziel Entwicklung und Betrieb eines IMS“ angeboten [Mas-2009].
”
Seitdem wurden vier Veröffentlichungen auf Konferenzen und ein Artikel im hochschulweiten
Magazin Querschnitt veröffentlicht. Außerdem wurden drei Bachelor- und vier Masterarbeiten
(die hier vorliegende Arbeit inbegriffen) erstellt.
Seit dem Sommer 2009 ist das Projekt Teil des Next Generation Telecommunication
Factory (NextFactor)-Projekt. Dieses Projekt hat die folgenden Ziele [Mas-2008, S. 2–3]:
1. IMS/NGN-Infrastruktur mit Testing and Test Control Notation Version 3 (TTCN-3)
”
basierter Testautomationsplattform als Service für kleinere und mittlere Unternehmen
(KMU) und Unternehmenspartner“.
2. Entwicklung einer umfassenden IMS/NGN-Sicherheitsinfrastrukur“.
”
3. Entwicklung eines sicheren SIP-basierten mobilen Bezahldienstes mit Integration von
”
Near Field Communication (NFC)“.
Das Projekt ist in mehrere Arbeitspakete unterteilt. Diese Arbeit ist dem Arbeitspaket
AP Sec4 Endgerätesicherheit (inkl. SPIT/SPAM)“ [Mas-2008, S. 14–18] zugeordnet. Die
”
Aufgabenstellung für diese Masterarbeit wird im nächsten Abschnitt (vgl. Abschn. 1.2, S. 2)
näher beschrieben.
1
Kapitel 1. Einleitung
Für die Bearbeitung des Themas Spam over Internet Telephony (SPIT) ist eine Betrachtung hinsichtlich Privacy unumgänglich. Mittlerweile ist deutlich geworden [RFC-5039,
S. 23], dass ohne starke Identitäten das SPIT nicht in den Griff zu bekommen ist. Eine starke
Identität bezeichnet eine vertrauenswürdige Bindung zwischen Teilnehmer und Netzwerk.
Doch wie können starke Identitäten im IMS gesichert werden?
Ob SPIT aufkommen wird, galt lange als ungewiss. Ein Versuch der Universität DuisburgEssen belegt die Existenz dieses Problems [Hof-2009, S. 9]. Sie betreibt einen Honeypot
für SPIT, auf den bereits zugegriffen wurde. Außerdem prognostiziert das Bundesamt für
Sicherheit in der Informationstechnik (BSI) für SPIT eine ähnliche quantitative Entwicklung
wie bei E-Mail-Spam [BSI-2009, S. 4].
Wenn jetzt etwas unternommen wird, kann diese Entwicklung aufgehalten werden. Kommt
es zu einer Verbreitung von SPIT, kann dies den gesamten Einsatz von Voice over IP (VoIP)
gefährden. Schließlich will niemand die selbe Masse an unerwünschten Anrufen, wie an unerwünschten E-Mails.
1.2 Aufgabenstellung
Frühere Untersuchungen haben gezeigt, dass zur erfolgreichen Spambekämpfung ein gewisses
Maß an Privatsphäre nötig ist [RFC-5039, S. 23–24]. Insbesondere das Vorhandensein starker
Identitäten ist eine der Schlüsselrollen gegen Spam.
Doch im Kontext moderner Netzarchitekturen, insbesondere des IMS, werden viele Identitäten ausgetauscht. Da sie für die Funktion der Architektur unumgänglich sind, können sie
nicht entfernt werden. Folglich geht es mehr um einen effektiven Schutz.
Im Kontext der Spambekämpfung bedeutet dies, dass die Identitäten mittels Authentifizierungsmaßnahmen geschützt werden müssen. Ziel dieser Arbeit ist daher die Ermittlung
von Mechanismen zur Abwehr von SPIT und Gewährung von starken Identitäten.
Abschließend wird eine Anti-SPIT-Maßnahme für direkte Anrufe implementiert. Da
das NextFactor-Projekt noch im Anfangsstadium ist, wird zunächst eine Machbarkeitsstudie
entworfen, die eine generelle Möglichkeit bestätigt.
1.3 Wirtschaftlicher Nutzen
Das Aufkommen von SPIT kann dafür sorgen, dass der VoIP-Dienst vom Teilnehmer abgelehnt wird. Da die Next Generation Networks (NGNs) von diesem Problem betroffen sind
[TIS-2008, S. 20], ergibt sich ein direktes Interesse der ISP, SPIT möglichst frühzeitig einzudämmen.
SPIT verursacht vor allem beim Ziel des Spams hohe Kosten. Der größte Bestandteil dieser Kosten ist mit 85 % der entstehende Produktivitätsverlust [Jen-2009]. Die Kosten cs
2
1.4. Aufbau der Arbeit
für einen Anruf ergeben sich aus dem durchschnittlichen Stundenlohn lh für die entgangene Arbeitszeit tc (vgl. Formel 1.1, S. 3). Da der Mitarbeiter durch den Anruf aus seiner
Tätigkeit gerissen wird, entgeht dem Arbeitgeber zusätzliche Arbeitszeit tx . Bei mehreren
Spamvorfällen summiert sich dieser Betrag weiter auf.
cs = (tc · tx ) ·
lh
360
(1.1)
Diese Arbeit präsentiert die notwendigen Abwehrmaßnahmen und Sicherheitsverfahren.
Dabei führt sie in die Probleme ein, die im Kontext von SPIT auftreten können. Insbesondere
wird die Relevanz von starken Identitäten, in Form von authentisierten Teilnehmern, beschrieben.
Zusätzlich wird ein Konzept zur Abwehr von Direct-IP-SPIT beschrieben. Direct-IP-SPIT
ist als besonders gefährlich einzustufen, da es das IMS umgeht und somit eine Abwehr kaum
möglich macht.
1.4 Aufbau der Arbeit
Das Thema SPIT wird in dieser Arbeit im Kontext des IMS betrachtet. Deshalb wird in
einem einleitenden Kapitel (vgl. Kap. 2, S. 5) in die für diese Arbeit wichtigsten Themen
eingeführt, die unter dem Schlagwort NGNs zusammengefasst werden. Da das Session Initiation Protocol (SIP) für das IMS und die Zustellung des SPIT von zentraler Bedeutung
ist, wird zunächst die Funktionsweise dieses Protokolls vorgestellt. Auf Basis dieses Wissens
wird in die Thematik des IMS eingeführt werden.
Anschließend wird das SPIT erklärt (vgl. Kap. 3, S. 37). Dafür wird zunächst definiert,
was unter dem Ausdruck SPIT in dieser Arbeit zu verstehen ist. Bevor auf die Arbeitsweise
eines Spammers eingegangen wird, werden ausgewählte soziale Auswirkungen von SPIT vorgestellt. Danach wird das Vorgehen beim Senden von SPIT erklärt. Des Weiteren wird untersucht, ob sich SPIT für den Versender finanziell lohnt. Abschließend wird in die rechtlichen
Rahmenbedingungen um das Thema Spam eingeführt.
Da es seit mehreren Jahren E-Mail-Spam gibt, steht die Forschung dem Thema SPIT
nicht unvorbereitet gegenüber. Viele Ansätze der klassischen Spambekämpfung sind auf
SPIT übertragbar. Unterteilt in vier Gruppen (z. B. identitätsbasiert, präventiv) werden
diese Abwehrmaßnahmen vorgestellt (vgl. Kap. 4, S. 53).
Dem Thema Privacy kommt eine Schlüsselfunktion für die erfolgreiche SPIT-Bekämpfung
zu. Aus diesem Grund werden im nächsten Kapitel (vgl. Kap. 5, S. 75) die Sicherheitsverfahren vorgestellt, die hierfür im IMS eingesetzt werden können.
Zwar lässt sich SPIT wie E-Mail-Spam nicht vollständig unterbinden, doch zeigt sich, dass
eine Form des SPIT besonders kritisch ist. Das sogenannte Direct-IP-SPIT“ kann fast
”
nicht abgewehrt werden. Um diesem Problem entgegenzuwirken, wurde im Rahmen dieser
3
Kapitel 1. Einleitung
Arbeit ein Konzept zur Abwehr von Direct-IP-SPIT definiert und im Rahmen einer Machbarkeitsstudie realisiert (vgl. Kap. 6, S. 95).
Abschließend werden die Erkenntnisse aus dieser Arbeit zusammengefasst und bewertet.
Die Zusammenfassung wird durch einen Ausblick ergänzt.
4
Kapitel
2
Next Generation Network
Im Kontext der digitalen Konvergenz der Netze sind die sogenannten Next Generation Networks (NGNs) [ITU-2004] als Integrationsplattform das tragende Konzept. Sie bieten
zukünftig ein zentrales paketorientiertes Basisnetz z. B. für Telefonie und Internet. Zur Steigerung der Skalierbarkeit und Modularisierung sind die Kontrollfunktionen und der Transport voneinander getrennt. Um Telefonie über paketorientierte Netze zu ermöglichen, ist
eine sogenannte Quality of Service (QoS) integriert. Da ohne QoS jedes Paket im Internet
gleichberechtigt ist, kann es während eines Telefonats vermehrt zu Störgeräuschen kommen.
Beispielsweise kann ein Sprachpaket stark verzögert eingehen, sollte ein großer Dateitransfer
dazwischenkommen. Jetzt ist es möglich, Sprachpakete bevorzugt zuzustellen, um dem Echtzeitcharakter dieser Anwendung Rechnung zu tragen.
Eines der tragenden Protokolle für die Internettelefonie in den NGNs ist das Session
Initiation Protocol (SIP) (vgl. Abschn. 2.1, S. 5). Es stellt dem Netzwerk eine Sitzungssteuerungsfunktionalität zur Verfügung. Wenn ein Angreifer Spam versenden will, wird
er nach dem heutigen Stand auf das SIP zugreifen müssen.
Im Kern dieses konvergenten Netzes wird das IMS (vgl. Abschn. 2.2, S. 27) eingesetzt.
Es definiert die zentralen Steuerfunktionen zur Durchführung verschiedener Services, wie
z. B. Telefonie. Somit hat das IMS eine Schlüsselfunktion in der Bekämpfung von Spam over
Internet Telephony (SPIT) (vgl. Kap. 3, S. 37).
Da jeder der genannten Technologien für den Vertrieb sowie die Bekämpfung von SPIT
relevant ist, werden diese nachfolgend genauer vorgestellt. Eine Untersuchung auf die Angriffsmöglichkeiten erfolgt später in dieser Arbeit (vgl. Kap. 4, S. 53).
2.1 Session Initiation Protocol
Voice over IP (VoIP) leistet einen wichtigen Beitrag zur Konvergenz der Netze. Mit VoIP
ist ein Teilnehmer in der Lage, von jedem beliebigen Endgerät (z. B. Handy) Telefonate zu
führen, solange dieses internetfähig ist.
5
Kapitel 2. Next Generation Network
Doch diese Flexibilität bedeutet zusätzlichen Aufwand. Ein Mobiltelefon ist in der Regel
nicht in der Lage die Sprache in derselben Qualität zu übertragen wie ein Telefon. Das liegt
an der unterschiedlichen Bandbreite. Mittels Mobilfunknetz wird beim Global System for
Mobile Communications (GSM) ca. 10 kbit/s oder mittels General Packet Radio Service
(GPRS) ca. 8–10 kbit/s zur Verfügung gestellt [3GP-2009]. Ein an das Integrated Service
Digital Network (ISDN) angeschlossenes Telefon hat jedoch 64 kbit/s.
Deshalb muss zur Abstimmung der Möglichkeiten eine sogenannte Sitzungssteuerung
eingesetzt werden. Sie ermittelt im Rahmen der Signalisierung die Fähigkeiten der beteiligten Endgeräte. Zur Beschreibung der Fähigkeiten kommt ein Sitzungsbeschreibungsprotokoll
(z. B. das Session Description Protocol (SDP) [RFC-4566]) zum Einsatz. Mit diesen Informationen kann eine Kommunikationsverbindung aufgebaut werden, die den Möglichkeiten aller
Teilnehmer gerecht wird. Des Weiteren ist eine Sitzungssteuerung für den generellen Aufund Abbau einer Sitzung und für die Verwaltung dieser Sitzung zuständig.
Der Begriff Sitzung bezeichnet den Austausch von Daten zwischen zwei beteiligten Teilnehmern [RFC-3261, S. 8]. Zur besseren Darstellung lässt sich dieser Begriff an folgendem
Beispiel beschreiben: Alice sitzt an ihrem Computer und will Bob auf seinem Mobiltelefon erreichen. Nach der Eingabe der Mobilfunknummer findet die Sitzungssteuerung die
Fähigkeiten von allen beteiligten Endgeräten heraus. Da Bob über ein Handy telefoniert,
kommt ein etwas schlechterer Codec zum Einsatz. Falls Bob während des Gesprächs in ein
Gebiet mit schlechterem Empfang kommt, kann der aktuelle Codec eventuell nicht mehr
genutzt werden. Deshalb wird der verwendete Codec in einer solchen Situation von der Sitzungssteuerung gewechselt. Beendet Alice ihr Telefonat mit Bob, sorgt die Sitzungssteuerung
dafür, dass die Verbindung getrennt wird. Der gesamte Prozess von Rufauf- bis Rufabbau
wird als Sitzung bezeichnet.
Das Session Initiation Protocol (SIP) [RFC-3261] ermöglicht eine solche Sitzungssteuerung.
Beim Entwurf des SIP wurde besonders auf die Verständlichkeit und leichte Handhabung Wert gelegt. Aus diesem Grund ist die Syntax sehr ähnlich zur der des Hypertext
Transport Protocol (HTTP) [RFC-1945][RFC-2616].
Um Nachrichten zwischen den Teilnehmern auszutauschen, kommen mehrere Transportprotokolle in Frage. Das gewählte Protokoll muss jedoch von beiden beteiligten Teilnehmern
unterstützt werden, um eine Verbindung zu etablieren. Um das SIP zu transportieren, kann
auf die folgenden Protokolle zurückgegriffen werden [RFC-3261, S. 141–142][RFC-4168]:
• Transmission Control Protocol (TCP) [RFC- 793].
• User Datagram Protocol (UDP) [RFC- 768].
• Session Control Transmission Protocol (SCTP) [RFC-4960].
Das SCTP und TCP bieten eine Übertragungssicherung. Eine Übertragungssicherung
beinhaltet eine Nachrichtenwiederholung bei Verlust oder Beschädigung, Einhaltung der
6
2.1. Session Initiation Protocol
Sendereihenfolge und Eliminierung von Duplikaten. Da das SIP eine Übertragungssicherung
bereitstellt, kann der Einsatz des SCTP und des TCP einen unnötigen zusätzlichen Overhead
aufgrund doppelt ausgeführter Tätigkeiten bedeuten [TW-2007, S. 124]. Deshalb kommt oft
das verbindungslos arbeitende UDP zum Einsatz, da es keine Übertragungssicherung einsetzt.
2.1.1 Begriffserklärung
Im Kontext vom SIP wird von Wörtern und Begriffen Gebrauch gemacht, die eventuell ungeläufig sind beziehungsweise in Zusammenhang mit anderen Thematiken verwendet werden.
Um Irritationen zu vermeiden, werden in diesem Abschnitt kurz die Begrifflichkeit bestimmter
Ausdrücke erklärt.
User Agent Client und Server
Ein UA (vgl. Abschn. 2.1.6, S. 24) besteht aus zwei Komponenten, einem UAC und einem UAS. Die Bezeichnung unterscheidet sich von der klassischen Verwendung des Client- /
Server-Begriffs. Ob ein UA als Client oder als Server agiert, sagt nichts über seine eigentliche
Funktion aus. Er kann eine Endeinrichtung oder ein Netzelement sein. Die Angabe, ob es
sich um einen Client oder einen Server handelt, ist nur eine fallbezogene Bezeichnung.
Alice
INVITE
Bob
100 Trying
User Agent
Client
180 Ringing
200 OK
User Agent
Server
ACK
Sitzung
User Agent
Server
BYE
200 OK
User Agent
Client
Abb. 2.1: Server- und Client-Rollenverteilung bei einem normalen Telefonat.
Startet ein UA eine Kommunikation durch das Senden eines INVITE-Request, nimmt er
die Rolle des UAC ein (vgl. Abb. 2.1, S. 7). Der angerufene UA übernimmt automatisch die
Rolle des UAS. Seine Funktion ist die Beantwortung der Requests mit Responses.
7
Transaction
Das Anfrage-Antwort-Verfahren bei SIP wird als Transaction [RFC-3261, S. 122–141]
bezeichnet. Im Rahmen einer Transaction werden eine Request und ein oder mehr Responses
ausgetauscht [RFC-3261, S. 122]. Eine Transaction wird mit einer finalen Response beendet.
Wenn die Request-Methode z. B. INVITE oder SUBSCRIBE (vgl. Abschn. 2.1.3, S. 18)
ist, leitet die Transaction einen Dialog (vgl. Abschn. 2.1.1, S. 9) ein. Diese Sitzung wird
wiederum durch eine weitere Transaction beendet (vgl. Abb. 2.2, S. 8).
Alice
INVITE
Bob
Transaction 1
200 OK
ACK
Transaction 2
Sitzung
BYE
Transaction 3
200 OK
Abb. 2.2: Verteilung von Transactions und Sitzung.
Um einzelne Nachrichten einer Transaction zuzuordnen, werden die folgenden HeaderFelder ausgewertet:
• Der brach-Wert im via-Header-Feld.
• Der Wert des CSeq-Header-Feld.
Eine Ausnahme [RFC-3261, S. 125–129] für die Transaction ist der Three-Way-Handshake
(vgl. Abschn. 2.1.5, S. 22). Abhängig davon, wie der Verbindungsaufbau verläuft, besteht er
aus mehr oder weniger Requests und Responses [RFC-3261, S. 122–123].
• Erfolgreicher Verbindungsaufbau (vgl. Abb. 2.3, S. 8): Das heißt der INVITERequest wird mit einem Response vom Typ 2xx beantwortet (vgl. Abb. 2.9, S. 23).
In diesem Fall besteht der Three-Way-Handshake aus einer normalen“ Transaction
”
(INVITE und 200 OK) und einer Transaction mit nur einem Request (ACK).
Alice
INVITE
200 OK
ACK
Bob
Transaction 1
Transaction 2
Abb. 2.3: Three-Way-Handshake mit zwei Transactions.
8
• Erfolgloser Verbindungsaufbau (vgl. Abb. 2.4, S. 9): Dies ist der Fall, wenn der
INVITE-Request durch einen Response vom Typ 3xx bis 6xx beantwortet wird. Dann
besteht die Transaction aus zwei Requests (INVITE und ACK) und einer Response
(3xx bis 6xx).
Alice
INVITE
Bob
404 Not Found
Transaktion 1
ACK
Abb. 2.4: Three-Way-Handshake mit einer Transaction.
Dialog
Eine zusammenhängende Folge von Transactions wird als Dialog [RFC-3261, S. 69]
bezeichnet. Der Austausch der Medieninformationen, wie z. B. bei VoIP der Austausch der
Sprachdaten, fällt ebenfalls unter diesen Begriff.
Alice
INVITE
Bob
200 OK
INVITE-Dialog
ACK
Sitzung
Sitzungs-Dialog
BYE
200 OK
BYE-Dialog
Abb. 2.5: Veranschaulichung des Dialogs.
Die an einem Dialog beteiligten Transactions werden über die folgenden Header-Felder
zugeordnet:
• Der Wert des Call-ID-Header-Feld.
• Der Wert des tag-Parameters im From-Header-Feld.
• Der Wert des tag-Parameters im To-Header-Feld.
Ein Dialog wird von keinem Netzelement außer den Endsystemen terminiert. Ausnahmen
stellen Netzelemente dar, die als Endsystem auftreten können, wie beispielsweise der B2BUA
(vgl. Abschn. 2.1.6, S. 26).
9
Event
Als Event [RFC-3265] wird bei SIP ein Ereignis bezeichnet, dass zu einem bestimmten
Zustand gehört. Events werden beispielsweise für die Durchführung einer Presence-Funktion
[RFC-3856] genutzt. Bei einem Presence Event wird z. B. der Abonnent informiert, wenn sich
der überwachte Teilnehmer registriert.
Um ein Event zu abonnieren, wird ein SUBSCRIBE-Request (vgl. Abschn. 2.1.3, S. 19)
an den gewünschten Zielteilnehmer gesendet. Sobald sich der abonnierte Zustand dieses Teilnehmers ändert, sendet sein UA einen NOTIFY-Request an den abonnierenden Teilnehmer.
Diese Prozedur der Überwachung und Information wird als SIP-Specific Event Notification
[RFC-3265] bezeichnet. Eine vollständige Liste aller möglichen Event Packages ist auf der
Seite der Internet Assigned Numbers Authority (IANA) [IAN-2009] zu finden.
2.1.2 Nachrichtenstruktur
Beim SIP besteht eine Nachricht aus zwei bis vier Elementen. Sie enthält immer die folgenden
beiden Komponenten:
1. Start-Line.
2. Header.
Die Nachrichten sind zustätzlich in der Lage eine Nutzlast zu transportieren. In den meisten
Fällen ist dies eine Beschreibung der zu verwendenden Codecs. Enthält eine Nachricht eine
Nutzlast, erweitert sich der Aufbau der Nachricht wie folgt:
1. Start-Line.
2. Header.
3. Leerzeile.
4. Body.
Die Leerzeile hat die einzige Funktion, als Separator zwischen dem Header und dem Body
zu dienen. Im Folgenden werden die restlichen Bestandteile einer Nachricht beschrieben.
Start-Line
Wie der Name bereits suggeriert, besteht die Start-Line aus nur einer einzigen Zeile. Sie
enthält die wichtigsten Informationen zur Verarbeitung der Nachricht. Es gibt zwei
Arten von Nachrichten. Zum einen initiierende Nachrichten, zum anderen die korrespondierende Antwort. Diese Requests und Responses (vgl. Abschn. 2.1.3, S. 17) unterscheiden sich
im Aufbau leicht voneinander.
10
Start Line
Header
Optional
Leerzeile
Body
Abb. 2.6: Aufbau einer SIP-Nachricht.
Zunächst wird an dieser Stelle der Request beschrieben. Abgesehen von der Methode des
Requests, ist in der Start-Line der URI des Adressaten und eine Versionsnummer enthalten.
Eine Methode ist die Art des Requests, z. B. REGISTER für einen Registrationsversuch. Die
Versionsnummer gibt die verwendete Version des SIP an. Diese drei Bestandteile sind in der
folgenden Reihenfolge angegeben (vgl. Notation 2.1, S. 11):
1. Methode
2. Request-URI
3. SIP-Version
REGISTER sip : registrar . atlanta . com SIP /2.0
Notation 2.1: Beispiel einer Start-Line in einem Request.
Bei einem Response ist die Start-Line ein wenig anders aufgebaut als beim Request. Sie
enthält neben der SIP-Version einen sogenannten Status-Code und eine Reason Phrase. Die
Reason Phrase dient der verbalen Beschreibung des Status-Codes. Sie werden in der folgenden
Reihenfolge angegeben (vgl. Notation 2.2, S. 11):
1. SIP-Version
2. Status-Code
3. Reason Phrase
SIP /2.0 2 00 OK
Notation 2.2: Beispiel einer Start-Line in einem Response.
Bei Requests sowie bei Responses werden diese drei Komponenten durch ein Leerzeichen
separiert. Die Status-Line wird mit einem Wagenrücklauf-Zeichen beendet.
11
Header
Der Header beinhaltet eine Liste mit Attributen. Sie geben Aufschluss über weitere Informationen zur Nachricht. Beispielsweise wird über Attribute das Routing oder eine Identifikation durchgeführt. Die Syntax der Attribute ist dieselbe wie beim HTTP. Auf einen
Attributsnamen folgt mindestens ein Attributswert.
Syntax:
Name: Wert(e)
Beispiel:
From: Alice <sip:[email protected]>
Manche Attribute müssen in jeder Nachricht enthalten sein, andere sind optional. Je nach
Nachrichtentyp (vgl. Abschn. 2.1.3, S. 17) können weitere Attribute verpflichtend sein. Nachfolgend werden die Attribute beschrieben, die in allen Nachrichten enthalten sein müssen
[RFC-3261, S. 162–163] und anhand eines Beispiels (vgl. Notation 2.3, S. 12) erklärt.
From : Alice < sip : alice@atlanta . com >; tag =888 a
To : Bob < sip : bob@biloxi . com >; tag =888 b
Via : SIP /2.0/ UDP proxy . atlanta . de :5060; branch = z9hG4bK87asdks7
Max - Forwards : 70
Call - ID : 20091023 @atlanta . com
CSeq : 1 INVITE
Notation 2.3: Minimalbeispiel eines Headers.
• Call-ID [RFC-3261, S. 166]: Der Call-ID ist eine eindeutige Identifikation der Sitzung.
Über ihn wird die Zusammengehörigkeit der Nachrichten ermittelt.
Syntax:
Call-ID: Identifikation
Beispiel:
Call-ID: [email protected]
• CSeq [RFC-3261, S. 170]: Die CSeq ist eine fortlaufende Sequenznummer. Mit ihr wird
die aktuelle Nachricht einer Transaction ermittelt. Sie besteht aus einer Zahl und dem
Namen der Request-Methode. Die Zahl muss ganzzahlig und maximal 32 bit lang sein.
Syntax:
CSeq: Sequenznummer Request-Methode
Beispiel:
CSeq: 1 INVITE
• From [RFC-3261, S. 172]: Dieses Feld gibt an, wer die Sitzung begonnen hat. Es besteht
aus einem optionalen Anzeigenamen und einem Kontakt-URI. Der Anzeigename wird
genutzt, um ihn beispielsweise auf dem Display beim Klingeln anzuzeigen. Soll nichts
12
angezeigt werden, muss Anonymous“ als Displayname eingetragen werden. Der tag”
Wert dient der Zuordnung der Nachricht zu einem Dialog.
Syntax:
From: Anzeigename SIP URI;tag=Wert
Beispiel:
From: Alice <sip:[email protected]>;tag=888a
• Max-Forwards [RFC-3261, S. 173]: Der Wert dieses Feldes gibt die maximale Anzahl
der Weiterleitungen für diese Nachricht an. Sie wird von jedem passierten Proxy oder
Gateway dekrementiert. Erreicht der Wert des Feldes die 0, wird die Nachricht nicht
mehr weitergeleitet. Der Standard nennt einen Initialwert von 70 Weiterleitungen.
Syntax:
Max-Forwards: Anzahl
Beispiel:
Max-Forwards: 70
• To [RFC-3261, S. 178–179]: Dieses Header-Feld beschreibt, an wen die Nachricht gesendet werden soll. Genau wie das Header-Feld From besteht es aus einem optionalen
Anzeigenamen und einem Kontakt-URI. Wie beim Header-Feld From, kann der Anzeigename zur Darstellung auf dem Display genutzt werden. Entsprechend kann die
Angabe des Nutzernamens durch die Angabe des Anzeigenamens Anonymous“ un”
terdrückt werden. Der unter To angegebene URI ist derselbe, wie er in der Start-Line
angegeben ist. Wie beim From-Header-Feld dient der tag-Wert der Zuordnung der
Nachricht zu einem Dialog.
Syntax:
To: Anzeigename <SIP URI>;tag=Wert
Beispiel:
To: Bob <sip:[email protected]>;tag=888b
• Via [RFC-3261, S. 179–180]: Das Header-Feld Via enthält das verwendete Transportprotokoll und die Adresse des Clients. Es hat eine ähnliche Funktion wie ein Logbuch.
Jeder durchlaufene Proxy trägt sich hier ein. Somit wird ermöglicht, dass ein Response
durch dieselben Proxys wieder zurückfindet. Der Wert des branch-Parameters dient
der Zuordnung zu einer Transaction.
Syntax:
Via: Protokoll Adresse:Port;branch=Wert
Beispiel:
Via: SIP/2.0/UDP proxy.atlanta.de:5060;branch=z9hG4bK87asdks7
Zusätzlich können je nach Anwendung weitere Header-Felder in der Nachricht enthalten
sein. Beispielsweise enthält ein INVITE-Request in der Regel eine Medienbeschreibung in
seinem Body. Um zu beschreiben was und wie viel im Body transportiert wird, gibt es separate
13
Header-Felder. Deshalb werden nachfolgend zusätzliche Header-Felder vorgestellt, die in einer
Nachricht vorhanden sein können.
• Alert-Info [RFC-3261, S. 164]: Das Header-Feld Alert-Info gibt einen URI zu einer
Audiodatei an. Erreicht ein INVITE-Request mit diesem Header-Feld ein Endgerät,
wird die angegebene Audiodatei als Klingelton genutzt. Unterstützt das Endgerät dieses Header-Feld nicht, wird es ignoriert und mit dem normalen Ton geläutet. Bei einer
180 Ringing-Response ersetzt es das Wartezeichen. Es muss dem Teilnehmer allerdings
möglich sein, die Auswertung dieses Header-Feldes zu deaktivieren.
Syntax:
Altert-Info: <URI>
Beispiel:
Altert-Info: <http://www.atlanta.com/sounds/ringing.wav>
• Authorization [RFC-3261, S. 165–166]: Ist eine Autorisation des anfragenden Teilnehmers nötig, wird dieses Header-Feld von einem UAS oder Registrar (vgl. Abschn. 2.1.6, S. 26) eingefügt. Es beinhaltet alle für die Autorisation erforderlichen Informationen (vgl. Abschn. 5.1.3, S. 78).
Syntax:
Authorization: Digest username="Nutzername", realm="Domain",
nonce="Nonce", uri="URI", response"Geheimnis"
Beispiel:
Authorization: Digest username="alice", realm="atlanta.com",
nonce="ea9c[...]", uri="sips:atlanta.com", response="dfe5[...]"
• Contact [RFC-3261, S. 167]: Dieses Header-Feld muss in jedem Request enthalten
sein, der eine Kommunikation etabliert. Das ist z. B. bei einem INVITE-Request der
Fall. Das Contact-Feld enthält einen URI für eine folgende Kontaktaufnahme.
Syntax:
Contact: <SIP URI>
Beispiel:
Contact: <sip:[email protected]>
• Event [RFC-3265, S. 7]: Benennt das zu abonnierende Event-Package. Es darf pro
SUBSCRIBE-Request maximal ein Event abonniert werden.
Syntax:
Event: Eventtyp
Beispiel:
Event: presence
• Expires [RFC-3261, S. 171–172]: Das Expires-Feld gibt an, wie lange eine gesendete
Botschaft gültig ist. Die Zeitangabe kann einen Wert von 0 bis 232 −1 Sekunden haben.
14
Besonders wichtig ist dieser Wert bei der Registrierung (vgl. Abschn. 2.1.5, S. 22).
Syntax:
Expires: Dauer in Sekunden
Beispiel:
Expires: 7200
• P-Asserted-Identity [RFC-3325, S. 8]: Dieses Header-Feld wird zwischen vertrauenswürdigen Netzelementen eingesetzt. Der Sender der Nachricht versichert hiermit,
dass er den genannten Teilnehmer kennt und authentifiziert hat.
Syntax:
P-Asserted-Identity: "Teilnehmername"<SIP URI>
Beispiel:
P-Asserted-Identity: "Alice"<sip:[email protected]>
• Privacy [RFC-3323, S. 11–12]: Dient der Nutzung eines Privacy-Services (vgl. Abschn. 5.3, S. 86). Je nach Feldwert werden diverse Bereiche der Nachricht anonymisiert.
Syntax:
Privacy: Privacylevel
Beispiel:
Privacy: user
• Proxy-Authenticate [RFC-3261, S. 174–175]: Dient der Authentifikation eines Teilnehmers durch einen Proxy (vgl. Abschn. 5.1.3, S. 78). Er beinhaltet alle zur Berechnung eines gemeinsamen Geheimnis benötigten Informationen.
Syntax:
Proxy-Authenticate: Digest realm="Domain", nonce="Nonce"
Beispiel:
Proxy-Authenticate: Digest realm="atlanta.com", nonce="ea9c[...]"
• Proxy-Authorization [RFC-3261, S. 175]: Dieses Header-Feld wird von einem Proxy
beigefügt, wenn eine Autorisation (vgl. Abschn. 5.1.3, S. 78) gefordert ist. Es beinhaltet
alle für die Autorisation erforderlichen Informationen.
Syntax:
Proxy-Authorization: Digest username="Nutzername", realm="Domain",
nonce="Nonce", uri="URI", response"Geheimnis"
Beispiel:
Proxy-Authorization: Digest username="alice", realm="atlanta.com",
nonce="ea9c[...]", uri="sips:atlanta.com", response="dfe5[...]"
• Subscription-State [RFC-3265, S. 15]: Gibt den Status des abonnierten Events an.
Der Status kann active (akzeptiert), pending (in Bearbeitung) und terminated (beendet) sein. Ist das Abonnement akzeptiert oder in Bearbeitung, sollte eine Gültigkeits-
15
dauer angegeben werden. Wird es abgelehnt, sollte eine Begründung angegeben werden.
Syntax:
Subscription-State: Status;expires=Dauer;reason=Begründung
Beispiel:
Subscription-State: active;expires=0
• WWW-Authenticate [RFC-3261, S. 182]: Dient der Authentifikation eines Teilnehmers durch einen UAS oder Registrar (vgl. Abschn. 5.1.3, S. 78). Dieses Header-Feld
beinhaltet einen Nonce-Wert, der in der angegebenen Domain gültig ist. Er dient der
Berechnung eines gemeinsamen Geheimnis, das zur Autorisation verwendet wird.
Syntax:
WWW-Authenticate: Digest realm="Domain", nonce="Nonce"
Beispiel:
WWW-Authenticate: Digest realm="atlanta.com", nonce="ea9c[...]"
Die oben genannten Header-Felder können für manche Nachrichten verpflichtend sein. Im
Umkehrfall ist es in vielen Situationen nicht erlaubt, diese Header-Felder in bestimmten
Nachrichten einzusetzen. Um Klarheit zu schaffen, werden diese Eigenschaften hier zusammengefasst (vgl. Tab. 2.1, S. 16).
Header-Feld
Wo ACK BYE CAN INV MES NOT OPT REG SUB
Alert-Info
–
–
–
o
–
–
–
–
–
Authorization
R
o
o
o
o
o
–
o
o
–
Contact
R
o
–
–
m
–
m
o
o
m
Contact
1xx
–
–
–
o
–
o
–
–
o
Contact
2xx
–
–
–
m
–
m
o
o
o
R
–
–
–
–
?
m
–
–
m
–
–
–
o
o
–
–
o
o
–
–
–
o
o
–
–
o
m
P-Asserted-Identity
–
o
–
o
?
o
o
–
o
Privacy
o
o
o
o
o
o
o
o
o
Proxy-Authenticate 401
–
o
o
o
o
?
o
o
?
Proxy-Authenticate 407
–
m
–
m
m
m
m
m
m
Proxy-Authorization
o
o
–
o
o
o
o
o
o
Req
–
–
–
–
?
m
–
–
–
WWW-Authenticate 401
–
m
–
m
m
m
m
m
m
WWW-Authenticate 407
–
o
–
o
o
?
o
o
?
Event
Expires
Expires
Subscription-State
2xx
Tab. 2.1: Zusammenfassung der relevanten optionalen Header-Felder.
16
Die in der Tabelle genannten Abkürzungen in der Spalte Wo“ geben die betroffenen
”
Nachrichtentypen an. Steht in einer Zeile nichts in dieser Spalte, gelten die Informationen
für alle Nachrichten. Wird ein dreistelliger Statuscode angegeben, betrifft die Angabe die
entsprechenden Responses oder Response-Gruppen. Sind nur Requests betroffen, wird das
Kürzel R“ angezeigt. Um zu beschreiben, inwiefern ein Header-Feld in einer der Nachrichten
”
vorhanden sein kann, werden folgende Kürzel verwendet:
• –: Das Header-Feld darf in dieser Nachricht nicht verwendet werden.
• o: Das Header-Feld kann in dieser Nachricht verwendet werden, muss aber nicht.
• m: Das Header-Feld muss immer in dieser Nachricht vorhanden sein.
• ?: Im Standard wird auf diese Konstellation nicht eingegangen, daher ist kein Zusammenhang bekannt.
Body
Sofern ein Body vorhanden ist, enthält er zusätzliche Informationen, die für die reine
Nachrichtenübermittlung irrelevant sind. Theoretisch kann fast jede Information mit dem SIP
tranportiert werden. In der Praxis beläuft sich die Art des Inhaltes auf wenig Verschiedene.
Beispielsweise beinhaltet eine MESSAGE-Request (vgl. Abschn. 2.1.3, S. 18) die gesendete
Nachricht im Klartext.
Am wichtigsten ist der Body beim Sitzungsaufbau. Zu dieser Phase wird die Beschreibung der Medieninformationen im Body transportiert. Dafür kommt vor allem das Session
Description Protocol (SDP) [RFC-4566] zum Einsatz. Da der Nutzdatenaustausch für diese
Arbeit irrelevant ist, wird an dieser Stelle nicht weiter darauf eingegangen.
2.1.3 Nachrichtentypen
Bevor näher auf die Funktionsweise von SIP eingegangen wird, ist es für das Verständnis wichtig, die Nachrichtentypen zu kennen. Bei Prozeduren, wie beispielsweise dem Verbindungsaufbau, werden nur die Namen der Nachrichten zur Beschreibung verwendet. Wie bereits
erwähnt, werden die Nachrichten in zwei Nachrichtentypen unterteilt:
• Requests.
• Response.
Requests initiieren in der Regel eine Kommunikation. Ein Request wird mit dem Senden
einer Response vom UAS beantwortet. Im Folgenden werden beide Arten sowie einige wichtige
Vertreter beschrieben.
17
Requests
Um eine Transaction zu starten, sendet der UAC einen Request an den UAS. Requests
können von bestätigender Form sein (z. B. ACK). Selbst wenn sie als Bestätigung fungieren
sind sie kein Response. Die Methode eines Request wird durch ihren Namen gegeben. Im
Folgenden werden die für diese Arbeit relevanten Requests kurz vorgestellt.
• ACK [RFC-3261, S. 129–130]: Der ACK-Request (ACKnowledge) besagt, dass der
Response auf den zuvor gesendeten INVITE-Request erfolgreich empfangen wurde. Da
diese Nachricht nur bestätigend fungiert, wird sie niemals selbst bestätigt.
• BYE [RFC-3261, S. 89–91]: Wenn Bob das Telefonat beendet, sendet er ein BYE an
Alice. Daraufhin kann die Verbindung getrennt werden.
• CANCEL [RFC-3261, S. 115]: Wenn Alice z. B. während des Klingelns den Hörer
auflegt, sendet sie ein CANCEL an Bob. Dadurch wird der Verbindungsaufbau abgebrochen und es kommt keine Verbindung zustande. Bobs Telefon hört auf zu klingeln
und Bob weiß, dass er nicht mehr abnehmen muss.
• INVITE [RFC-3261, S. 78–86]: Will Alice mit Bob telefonieren, sendet sie einen
INVITE-Request an ihn. Dieser Request kann bereits Informationen über von Alices
Endgerät unterstützten Codecs enthalten. Bobs Endgerät gleicht diese angebotenen
Codecs mit seinen unterstützten Codecs ab und bestätigt die Übereinstimmungen.
Der Verbindungsaufbau wird weiter unten (vgl. Abschn. 2.1.5, S. 22) ausführlicher behandelt, daher wird an dieser Stelle nicht weiter darauf eingegangen. Wenn während
einer laufenden Sitzung ein INVITE-Request gesendet wird, dient dies in der Regel
der Änderung des verwendeten Codecs und wird als re-INVITE bezeichnet [RFC-3261,
S. 16].
• MESSAGE [RFC-3428]: Mittels eines MESSAGE-Request kann Alice eine Kurznachricht an Bob senden. Dieser, als Instant Messaging bekannte Service, wurde durch ICQ
[ICQ-2009] populär. Ursprünglich wurden nur sehr kurze Nachrichten ausgetauscht.
Mit SIP ist diese Beschränkung jedoch nicht mehr gegeben. In der Regel werden diese Nachrichten nicht in Form einer bidirectionalen Kommunikation genutzt. Vielmehr
werden sie wie Pager unidirektional verwendet.
• NOTIFY [RFC-3265, S. 34]: Über ein NOTIFY-Request wird ein Zustandswechsel bekannt gegeben. Der NOTIFY-Request bildet zusammen mit dem SUBSCRIBE-Request
die Basis für einen Präsenz-Dienst. Somit kann eine Feundesliste mit dem Onlinestatus
aller Freunde realisiert werden. Das Interesse an einem Zustand wird über das Senden
des SUBSCRIBE-Requests ausgedrückt.
18
• OPTIONS [RFC-3261, S. 66–69]: Nicht alle UAs unterstützen dieselben Codecs, Methoden, Erweiterungen usw. Um einen anderen Teilnehmer nach seinen Fähigkeiten zu
fragen, wurde dieser Request definiert.
• REGISTER [RFC-3261, S. 57–58]: Um Telefonate führen zu können, muss sich ein
Endgerät im Netz anmelden. Dafür sendet es ein REGISTER-Request an den LocationService (vgl. Abschn. 2.1.6, S. 26). Ein registriertes Endgerät muss sich innerhalb eines
bestimmten Intervalls erneut mit einem REGISTER-Request beim Location-Service
melden. Somit wird dafür gesorgt, dass nur aktive Teilnehmer registriert bleiben. Will
sich ein Teilnehmer vom Netzwerk abmelden, sendet er ein REGISTER-Request mit
einem Time-out mit dem Wert 0 an den Location-Service.
• SUBSCRIBE [RFC-3265, S. 34]: Wenn Alice eine Information bekommen will, wenn
Bob sein Telefonat beendet hat und wieder erreichbar ist, sendet sie ein SUBSCRIBERequest für das Presence-Event Package (vgl. Abschn. 6.3.1, S. 99). Sobald Bob fertig
telefonieren ist, erhält Alice einen NOTIFY-Request, dass Bob wieder verfügbar ist.
Responses
Eine Antwort seitens des UAS wird als Response bezeichnet. Diese Nachrichten werden
über ein Nummerierungssystem identifiziert, das sich an HTTP [RFC-1945, S. 32–37] anlehnt.
Eine Nachricht vom Typ 404 bezeichnet beispielsweise analog zum HTTP [RFC-1945, S. 36]
einen nicht auffindbaren Teilnehmer.
Die Responses haben einen dreistelligen Code als Bezeichner. Zusätzlich zum Code
enthält jede Response eine sogenannte Reason Phrase. Maßgeblich für die Verarbeitung ist
jedoch nicht die Reason Phrase sondern der dreistellige Code. Zusätzlich werden sie in sechs
Gruppen unterteilt, wobei die erste Ziffer des Codes die Gruppenzugehörigkeit angibt.
• 1xx Provisional: Teilt dem Teilnehmer mit, dass sein Request in Bearbeitung, aber
noch nicht abgeschlossen ist. In der Regel ist das Senden und Verarbeiten dieser Nachrichten optional. Deshalb werden in allen Abbildungen in dieser Arbeit die Nachrichten
vom Typ 1xx entweder ausgelassen oder mit gestrichelten Linien dargestellt.
• 2xx Success: Der Request wurde erfolgreich empfangen, verstanden und akzeptiert.
• 3xx Redirection: Der Teilnehmer ist unter dem angegebenen URI nicht erreichbar.
Dieser Response teilt dem UAC mit, wie er den gewünschten Gesprächspartner erreichen kann.
• 4xx Client Error: Der Request enthält eine fehlerhafte Syntax oder kann bei diesem
Server nicht verarbeitet werden.
• 5xx Server Error: Der Server ist nicht in der Lage, den Request zu bearbeiten.
19
• 6xx Global Failure: Der Request kann überhaupt nicht verarbeitet werden.
Der Standard definiert eine Vielzahl von Responses. Für diese Arbeit sind jedoch nicht alle
relevant. Daher werden hier nur die wichtigen Nachrichten näher vorgestellt.
• 100 Trying [RFC-3261, S. 183]: Der Request ist vom nächsten Kommunikationspunkt erfolgreich empfangen worden. Der Kommunikationspunkt führt jedoch momentan nicht näher spezifizierte Bearbeitungen durch. Beispielsweise kann dies eine
Datenbankabfrage sein.
• 180 Ringing [RFC-3261, S. 183]: Ein INVITE-Request wurde vom UAS empfangen
und dieser versucht, den Benutzer ans Telefon zu rufen.
• 200 OK [RFC-3261, S. 183]: Der Request ist angenommen.
• 401 Unauthorized [RFC-3261, S. 185]: Der gesendete Request bedarf einer Authentifizierung (vgl. Abschn. 5.1.3, S. 78). Die für die Authentifizierung benötigten Informationen werden im Header übertragen. Diese Nachricht wird von einem UAS oder
einem Registrar-Server gesendet.
• 404 Not Found [RFC-3261, S. 186]: Es gibt keinen Teilnehmer unter dem angefragten
URI oder unter der besagten Domain.
• 407 Proxy Authentication Required [RFC-3261, S. 186]: Der gesendet Request
bedarf einer Authentifizierung. Die für die Authentifizierung benötigten Informationen
werden im Header übertragen. Diese Nachricht wird von einem Proxy-Server gesendet.
• 433 Anonymity Disallowed [RFC-5079]: Die Annahme des Request wird verweigert,
da der anfragende Teilnehmer anonym ist.
• 434 Suspicious Call [Kut-2008, S. 6]: Der Request wird abgelehnt, weil der anfragende
Teilnehmer nicht verifiziert werden konnte.
• 480 Temporarily Unavailable [RFC-3261, S. 188]: Die angefragte Ressource ist
momentan nicht verfügbar. Dies ist der Fall, wenn versucht wurde einen Teilnehmer
anzurufen, der momentan offline ist.
• 481 Call/Transaction Does Not Exist [RFC-3261, S. 188]: Der empfangene Request, kann keiner laufenden Transaction oder keinem laufenden Dialog zugeordnet
werden.
• 486 Busy Here [RFC-3261, S. 189–190]: Das Zielsystem wurde erfolgreich kontaktiert,
aber der Teilnehmer ist zurzeit Beschäftigt.
• 489 Bad Event [RFC-3265, S. 35]: Das mittels SUBSCRIBE-Request angefragte
Event-Package wird nicht unterstützt.
20
2.1.4 Adressierung
Bei der Internettelefonie gibt es, wie bei der klassischen Telefonie, zu viele Endgeräte,
um sie manuell zu vermitteln. Beim Festnetz wird die Zuordnung über Nummern im
sogenannten E.164-Format [ITU-2005] durchgeführt. Für SIP wurde ein anderer eindeutiger
Identifikationsmechanismus entworfen.
Das Schema des sogenannten Session Initiation Protocol Uniform Ressource Identifier (SIP
URI) folgt den Richtlinien für Internet-URI [RFC-3986]. Der Aufbau ist stark an den einer
E-Mail-Adresse angelehnt. Genauer hat ein SIP URI die gleiche Syntax wie eine E-MailAdresse, angeführt vom doppelpunktseparierten Präfix sip“.
”
Syntax:
sip:user:password@host:port;uri-parameters?headers
Beispiel:
sip:[email protected]
Der Standard [RFC-3261, S. 77–87] sieht vor, dass ein Teilnehmer auf mehreren Endgeräten unter einer Nummer erreichbar ist. Dies lässt sich mit nur einem SIP URI
nicht verwalten. Daher sind zwei SIP URI-Typen definiert [RFC-3261, S. 148–158], die sich
in ihrer Funktion folgendermaßen unterscheiden (vgl. Abb. 2.7, S. 22):
• Permanenter SIP URI: Der permanente SIP URI wird benutzt, um mit einem
Teilnehmer in Kontakt zu treten. Es sind keinerlei Kenntnisse über den Aufenthaltsort
des Teilnehmers notwendig. Er besteht aus einem Anschlussnamen, der in der Regel
vom Betreiber festgelegt wird. Der Host-Teil hat die gleiche Struktur wie bei einer
E-Mail-Adresse und ist von Betreiber zu Betreiber verschieden.
• Temporärer SIP URI: Der temporäre SIP URI dient der Zuordnung auf die angemeldeten Endgeräte. Der Anschlussname wird auf die gleiche Weise gebildet, wie bei
einem permanenten SIP URI. Anstelle eines Domainnamens wird nach dem @-Zeichen
die tatsächliche IP-Adresse des Endgerätes eingesetzt. Somit hat jedes Gerät eine eindeutige Adresse, mit der es lokalisiert werden kann.
Um sich die Funktionsweise der beiden SIP URI zu verdeutlichen, kann sich folgendes
Szenario vorgestellt werden (vgl. Abb. 2.7, S. 22). Bob bekommt von seinem Telefonanbieter
den permanenten SIP URI sip:[email protected] zugewiesen. In unserem Fall hat Bob einen
Computer und ein Handy, die beide VoIP-fähig sind. Wenn sich Bob mit diesen Geräten beim
Registrar anmeldet, werden beide Geräte unter einem separaten temporären SIP URI abgelegt. Außerdem erstellt er eine Relation von Bobs permanenten SIP URI zu diesen Einträgen.
Wird Bob angerufen, können beide Geräte gleichzeitig angesprochen werden. Das Telefonat
wird an das Gerät vermittelt, an dem Bob sich zuerst meldet.
21
SIP-Teilnehmer
Permanenter SIP-URI
Temporärer SIP-URI 1
Temporärer SIP-URI 2
Temporärer SIP-URI n
Abb. 2.7: Relation zwischen permanentem und temporärem SIPURI.
2.1.5 Prozeduren
Der Ablauf der Standardprozeduren wird im Standard vom SIP beschrieben [RFC-3261].
Für unsere Betrachtungen sind die Registrierung und der Sitzungsaufbau besonders
wichtig. Zum einen entscheiden sie über die Zugangsmöglichkeiten ins Netz, zum anderen
wird über den Verbindungsaufbau die Spamübertragung eingeleitet.
Damit ein Netzelement die Adresse eines anzusprechenden Netzelementes kennt, fordert es
diese beim Domain Name Service (DNS) [RFC-3263] an. Da dieser Schritt für die Darstellung
der Prozeduren nicht essenziell ist, wird er hier der Übersichtlichkeit halber nicht aufgeführt.
Registrierung
Um ein Telefonat initiieren zu können, muss sich ein Teilnehmer zunächst dem Netz bekannt machen. Dies geschieht über die Registrierung. Die Aufenthaltsinformationen über
den Teilnehmer werden über den Registrar beim Location Service (vgl. Abschn. 2.1.6, S. 24)
hinterlegt.
Alice
REGISTER
Registrar
401 Unauthorized
REGISTER
200 OK
Abb. 2.8: Teilnehmerregistrierung mittels Session Initiation Protocol.
Um dem Registrar seine aktuelle Kontaktadresse mitzuteilen [RFC-3261, S. 56–66], sendet
der UA dem Registrar einen REGISTER-Request. Mit dieser Nachricht übermittelt er alle
für die Registrierung wichtigen Informationen (vgl. Notation 2.4, S. 23).
Mit der Angabe seines permanenten SIP URI identifiziert sich der Teilnehmer gegenüber
dem Registrar. Im Contact-Header-Feld nennt der UA den temporären SIP URI, unter der
er momentan erreichbar ist.
22
REGISTER sip : atlanta . com SIP /2.0
From : Alice < sip : alice@atlanta . com >
To : Alice < sip : alice@atlanta . com >
CSeq : 1 REGISTER
Contact : < sip : alice@192 .0.2.65 >
Expires : 7200
[...]
Notation 2.4: REGISTER-Request während der Registrierung.
Die Registrierung gilt nur für die Dauer in Sekunden, die das Expires-Header-Feld
angibt. Meldet sich der UA bis zum Ablauf der angegebenen Anzahl an Sekunden nicht erneut
beim Registrar, wird die Registrierung aufgehoben. Mit dieser Regelung wird verhindert, dass
ein UA im Falle eines UA-Absturzes registriert bleibt.
Will sich der Teilnehmer gezielt Deregistrieren, sendet er einen erneuten REGISTERRequest an den Registrar. Um zu signalisieren, dass er sich abmeldet, trägt der UA eine
Gültigkeitsdauer von null Sekunden ein. Die Registrierung läuft dadurch direkt wieder ab
und der Registrar hebt diese wieder auf.
Aus Gründen der Sicherheit schreibt der Standard [RFC-3261, S. 64] vor, die Registrierung zu authentifizieren. Inwieweit sich der Registrierungsprozess dadurch verändert, wird
in dieser Arbeit detailliert dargestellt (vgl. Abschn. 5.1.3, S. 78).
Sitzungsaufbau
Zum Sitzungsaufbau gehört nicht nur der reine Aufbau einer Punkt-zu-Punkt-Verbindung,
sondern ebenso das Auffinden des Zielteilnehmers. Wie anfangs erwähnt, ist es mit SIP
möglich, auf mehreren Geräten erreichbar zu sein.
Um eine Kommunikationsverbindung zwischen zwei Teilnehmern aufzubauen, verwendet
SIP analog zum TCP den Three-Way-Handshake (vgl. Abb. 2.9, S. 23). Alice sendet in der
Rolle des UAC einen INVITE-Request an Bob. Sobald Bob das Telefonat annimmt, sendet
sein UA einen 200 OK-Response als Bestätigung an Alice zurück. Falls Alice nach wie vor
an der Kommunikation interessiert ist, sendet sie ein ACK an Bob.
Alice
INVITE
Bob
200 OK
ACK
Abb. 2.9: Der Three-Way-Handshake.
23
Warum sind für eine Kommunikationsverbindung drei Schritte notwendig? Bei einem normalen Nachrichtenaustausch reichen normalerweise zwei Nachrichten aus! Der Grund liegt
in der unterschiedlichen Antwortzeit. Bei einem normalen Request antwortet eine Maschine,
wodurch sehr schnell ein Response zustande kommt. Im Falle eines INVITE muss der angerufene Teilnehmer auf das Klingeln des Telefons reagieren. Bis er das getan hat, kann es
sein, dass der Anrufende längst aufgelegt hat. Der Three-Way-Handshake dient demnach der
Sicherung, dass nach wie vor beide Teilnehmer an einer Verbindung interessiert sind.
2.1.6 Netzelemente
SIP benötigt für seine Funktionsfähigkeit die Unterstützung einiger Netzelemente. Eine Ausnahme bildet der B2BUA, er wird nicht zwangsweise benötigt. In der Praxis hat sich jedoch
gezeigt, dass er aus Sicherheitsgründen oft eingesetzt wird. Im Folgenden werden diese Netzelemente vorgestellt.
User Agent
Wenn ein Teilnehmer einen anderen Teilnehmer anrufen will, benötigt er dafür eine Schnittstelle. Diese Schnittstelle bietet sich in Form eines UA.
Der Standard [RFC-3261] nennt keine Vorgaben, wie die Gestalt eines UA zu sein hat. Diese
Entscheidung wurde aus Gründen der Flexibilität getroffen, um zukünftigen Entwicklungen
nicht im Wege zu stehen. Heute können UAs anhand ihres Aufbaus grob in zwei Gruppen
unterteilt werden:
1. Hard-Phone.
2. Soft-Phone.
Bei einem Hard-Phone (vgl. Abb. 2.10(a), S. 25) handelt es sich um eine komplette
Einheit. Sie sind in der Regel konstruiert wie ein herkömmlicher Telefonapparat mit einigen
Zusatztasten für die erweiterte Funktionalität (z. B. eine Taste, um die ausgehende Identität
zu wählen). Technisch eher unversierte Nutzer haben es mit dieser Version eines UAs deutlich
leichter, da die Handhabung sehr nah am gewohnten Festnetztelefon ist.
Ein Soft-Phone (vgl. Abb. 2.10(b), S. 25) ist ein UA der nur in Form einer Software
existiert. Es benötigt eine laufende Trägerplattform wie einen Computer, um einsatzfähig zu
sein. Der Vorteil dieser Variante ist, dass er sehr leicht ausgetauscht und erweitert werden
kann.
Unabhängig von der Art des UAs ist seine eigentliche Funktion immer gleich. Er ist dazu
da Telefonate zu erzeugen, zu terminieren und zu verwalten. Zusätzlich kann der UA Zusatzfunktionen unterstützen. Viele UAs bieten die Möglichkeit, Videotelefonate oder Konferenzen
zu führen. Da der Fokus dieser Arbeit auf SPIT liegt, wird auf derartige Zusatzfunktionen
nicht weiter eingegangen.
24
(a) Hard-Phone [sno-2009].
(b) Soft-Phone [HSC-2009].
Abb. 2.10: Beispiele für einen User Agent.
Proxy
Wenn ein Telefonat aufgegeben wird, ist der Proxy [RFC-3261, S. 91–122] die erste Anlaufstelle. Er nimmt den Telefonwunsch entgegen, wertet ihn aus und leitet ihn in Richtung des
Zielteilnehmers weiter.
Bevor der Proxy die Nachricht verarbeitet, überprüft er zunächst die Berechtigung des
Teilnehmers. Ist der Teilnehmer berechtigt, wird die Nachricht auf syntaktische Fehler und
Korrektheit des Inhalts überprüft. Beispielsweise werden die angegebenen Codecs auf ihre
Unterstützbarkeit untersucht.
Sind die Nachricht und der Teilnehmer verifiziert, schreibt oder entfernt der Proxy gegebenenfalls Informationen innerhalb der Nachricht. Ein Statefull-Proxy muss seine Adresse über
das Via-Header-Feld eintragen, um an der Kommunikation beteiligt zu bleiben.
Zur Weiterleitung der Nachricht überprüft der Proxy, ob sich der Zielteilnehmer im Heimatoder in einem Fremdnetz befindet. Ist er selbst für diesen Teilnehmer zuständig, fragt er
beim Location-Server den temporäre SIP URI des Teilnehmers an. Anschließend leitet er die
Nachricht an einen anderen Proxy weiter. Der Aufbau dieses Verfahrens der Weiterleitung ist
bekannt als SIP-Trapezoid [RFC-3261, S. 118], da sich die Kommunikation hier in einem
Trapezoid darstellen lässt (vgl. Abb. 2.11, S. 26).
Proxys werden zwischen Statefull und Stateless unterschieden. Diese beiden Proxys verhalten sich im Wesentlichen in der Verarbeitung der Nachrichten anders.
Wie der Name bereits andeutet, ist der Stateless-Proxy [RFC-3261, S. 116–118] nicht
in der Lage Informationen länger zu speichern. Geht bei ihm eine Nachricht ein, wird sie
verarbeitet und weitergeleitet. Anschließend hat der Stateless-Proxy keinerlei Informationen
mehr über diese Nachricht.
Ein Statefull-Proxy [RFC-3261, S. 92–94] ist dagegen in der Lage, sich eine Kommunikation zu merken. Dadurch kann nur der Statefull-Proxy einen Anruf an mehrere UAs splitten
25
alice.de-Proxy
bob.de-Proxy
SIP
SIP
SIP
Daten
Alice
Bob
Abb. 2.11: Veranschaulichung des SIP-Trapezoid-Begriffs.
(Call Forking). In diesem Fall tritt dieser Proxy als UAC auf, da er n neue INVITE-Requests
generiert. Nimmt der Teilnehmer auf einem UA an, werden alle anderen Anrufe abgebrochen
und der Verbindungsaufbau auf das abgenommene Endgerät normal weitergeführt.
Location Service
Der Location Service [RFC-3261, S. 22] ist im Grunde eine Datenbank, die sich den aktuellen
Aufenthaltsort des Teilnehmers merkt. Diese Information wird im Rahmen der Registration
vom Registrar an den Location Service gesendet. Konkret handelt es sich um eine Zuordnung
von permanenten zu temporären SIP URI.
Jeder Teilnehmer kann mehrere Geräte auf ein und denselben permanenten SIP URI anmelden. Dadurch kann ein Anruf von einem Statefull-Proxy auf mehrere Geräte gleichzeitig
geleitet werden.
Registrar
Der Registrar [RFC-3261, S. 24] ist der Ansprechpunkt zur Registrierung eines Teilnehmers. Durch die Registrierung des temporären SIP URI beim Registrar wird die Ortstransparenz des permanenten SIP URI erzielt. Dazu trägt der Registrar die aktuellen Informationen über den temporären SIP URI in den Location-Service ein. Meldet sich ein Teilnehmer
innerhalb eines angegebenen Intervalls nicht erneut beim Registrar, wird er automatisch
Deregistriert. In der Praxis werden Registrar und Location Service oft in einer physischen
Komponente umgesetzt.
Back to Back User Agent
Ein B2BUA [RFC-3261, S. 20] ist eine logische Einheit die als UAC und UAS fungieren
kann. Er wird vorrangig zur Trennung zweier Netzwerke oder Netzwerkbereiche
eingesetzt. Sinnbildlich gesprochen handelt es sich bei einem B2BUA um zwei Rücken an
Rücken stehende UA. Aus diesem Grund kann der B2BUA jede Art von Request erzeugen.
26
2.2. IP Multimedia Subsystem
Da er Nachrichten terminiert, bleibt er ähnlich, wie ein Statefull-Proxy an der Kommunikation
beteiligt. Anders als dieser bleibt der B2BUA am Nutzdatenaustausch beteiligt.
2.2 IP Multimedia Subsystem
Das IMS [TSG-2009d] ist ein wichtiger Bestandteil des Kernnetzes der NGNs. Es dient der
Bereitstellung eines SIP-basierten Multimediaservice. In diesem Abschnitt werden die im
Kontext von SPIT relevanten Bestandteile des IMS vorgestellt.
Wie beim SIP werden im Kontext des IMS Wörter verwendet, die der Leser aufgrund gegebener Vorkenntnisse falsch verstehen kann oder neu sind. Deshalb wird in diesem Abschnitt
kurz auf spezielle Terminologien eingegangen.
Heimat- und Fremdnetz
Das IMS hat seinen Ursprung in der Mobiltelekommunikation. Dadurch hat es einige Konzepte von den Mobilfunkstandards GSM und GPRS übernommen [CGM-2008, S. 40–42]. Auf
diese Weise wird das Konzept der Aufenthaltsnetze im IMS umgesetzt.
Dieses Konzept lässt sich anschaulicher in der Mobilfunkwelt erklären. Wenn ein Teilnehmer sich von zu Hause mit seinem Mobiltelefon einwählt, befindet er sich im Heimatnetz.
Das Heimatnetzwerk gehört dem Anbieter, von dem der Teilnehmer den Service bezieht.
Befindet sich der Teilnehmer z. B. im Ausland und versucht sich einzuwählen, hält er
sich im Fremdnetz auf. Dieses Netz gehört in der Regel nicht dem Betreiber, von dem der
Teilnehmer den Dienst bezieht.
Um dem Teilnehmer den Dienst im Fremdnetz zur Verfügung zu stellen, müssen die beiden Betreiber eine Vereinbarung treffen. Diese Vereinbarung enthält Punkte wie z. B. die
anfallenden Kosten, die QoS oder eine Authentifizierung.
Referenzpunkte
Die Funktionen des IMS werden durch sogenannte Referenzpunkte [TSG-2009e, S. 76–85] verbunden. Sie werden mit einer zwei- bis dreistelligen Buchstabenkombination benannt. Durch
die Referenzpunkte ist es möglich, mit wenig Sprachaufwand, die beteiligten Funktionen sowie
das zu verwendende Protokoll zu bezeichnen.
27
2.2.2 Adressierung
Das IMS ordnet jedem Teilnehmer mehrere Identitäten zu. Diese werden zur externen und
internen Unterscheidung der Teilnehmer benötigt. Beim IMS werden die folgenden beiden
Adresstypen unterschieden:
• IMPI.
• IMPU.
Zur internen Identifikation des Teilnehmers wird die IMPI [TSG-2009d, S. 33] verwendet.
Jedem Teilnehmer wird mindestens eine IMPI zugeordnet. Sie wird vom Betreiber des IMS
permanent vergeben und identifiziert das Teilnehmerkonto eindeutig. Die Identifikation betrifft allerdings nur das Konto und nicht den Teilnehmer selbst. Die Syntax der IMPI sollte
sich an die eines NAI [RFC-2486] richten.
Syntax:
username@realm
Beispiel:
[email protected]
Die IMPI wird beispielsweise für die Registrierung, die Authorisation oder das Accounting des Teilnehmerkontos eingesetzt. Sie wird jedoch nicht für das Routing von normalen
Nachrichten verwendet.
Seitens des Betreibers wird sie im Home Subscriber Server (HSS) (vgl. Abschn. 2.2.4, S. 33)
gespeichert. Dieser nutzt sie, um weitere Informationen über das Teilnehmerkonto abzulegen.
Im Rahmen der Registration, Reregistration oder Deregistration greift zusätzlich die S-CSCF
(vgl. Abschn. 2.2.4, S. 32) auf die IMPI zu.
Zur externen Identifikation des Teilnehmers wird die IMPU [TSG-2009d, S. 33–34] verwendet. Jedem Teilnehmer wird mindestens ein IMPU zugeordnet. Sie dient den Teilnehmern zur gegenseitigen Adressierung. Ihre Form sollte der eines SIP URI oder eines Tel-URI
[RFC-3966] gleichen. Abhängig von der Form der IMPU wird der Teilnehmer über eine normale Telefonnummer oder den SIP URI kontaktiert.
Beide Adressen werden im UE (vgl. Abschn. 2.2.4, S. 35) sicher innerhalb des ISIM
(vgl. Abschn. 2.2.4, S. 34) gespeichert. Das UE darf jedoch nicht auf sie zugreifen oder sie
verändern. Hat der Teilnehmer weder ein ISIM noch ein USIM, können beide Adressen in den
eventuell im Endgerät vorhandenen IMS Credentials (IMC) [TSG-2009f, S. 15] gespeichert
werden. Die IMC beschreibt die Sicherheitsverfahren und Daten für den Zugang ins IMS.
Relation zwischen den Adressen
Einem Teilnehmer wird immer genau eine IMPI zugeordnet. Zusätzlich kann dieser Teilnehmer zu dieser IMPI weitere IMPUs nutzen. Diese werden der IMPI zugeordnet (vgl. Abb. 2.12,
S. 29). Die Information, unter welchen zusätzlichen IMPUs ein Teilnehmer erreichbar ist, wird
im HSS hinterlegt.
28
IMS-Teilnehmer
Private User Identity
Public User Identity 1
Public User Identity 2
Service Profil
Public User Identity n
Service Profil
Abb. 2.12: Relation zwischen IMPI und IMPU [TSG-2009d, S. 35].
Der IMPU werden vom Betreiber des Netzes Service Profiles [TSG-2009c, S. 49–52] zugeordnet. Jedes Service Profile definiert die Rahmenbedingungen für die assoziierte Registrierung. Sie umfassen z. B. die assoziierten SIP URI, Tel-URI, Voraussetzungen für eine
erfolgreiche Registrierung, usw.
2.2.3 Prozeduren
Für den Ablauf der Prozeduren wie Registrierung und Sitzungsaufbau folgt das IMS den
Vorgaben des SIP. Da sich die Funktionen im IMS nicht vollständig mit den Netzelementen
des SIP decken, unterscheiden sie sich leicht im Ablauf. Deshalb wird hier erneut auf diese beiden Prozeduren eingegangen. Es wird gezeigt, wie der Nachrichtenaustausch im IMS
abläuft. Der Übersicht halber werden Anfragen beim DNS nicht dargestellt, wenngleich diese
zum Teil durchgeführt werden müssen.
Registrierung
Wie beim SIP muss ein UE zunächst eine Registrierungdurchführen, um sich dem Netz bekannt zu machen. Im IMS übernimmt der HSS die Rolle des Registrar. Für die nachfolgende
Beschreibung der Prozedur wird unterstellt, dass es nur einen HSS gibt. Sind mehrere vorhanden, wird zusätzlich der für den Teilnehmer zuständige HSS bei der Subscription Locator
Function (SLF) ermittelt (vgl. Abschn. 2.2.4, S. 33).
Zunächst sendet das UE ein REGISTER-Request an seine P-CSCF. Die P-CSCF ermittelt,
anhand des Domainnamens in der Anfrage, die Adresse des Heimatnetzes und leitet die
Nachricht an die dort zuständige I-CSCF weiter.
Die I-CSCF muss zunächst überprüfen, ob der Teilnehmer bereits registriert ist und ob er
sich registrieren darf. Ist der Teilnehmer berechtigt und unregistriert, wird der I-CSCF vom
HSS der Name der zuständigen S-CSCF übermittelt. Nachdem die I-CSCF die Adresse der
zuständigen S-CSCF von einem DNS erhalten hat, leitet sie die Nachrichten an weiter. Die
S-CSCF melden den Teilnehmer anschließend beim HSS an.
29
Fremdnetz
UE
Heimatnetz
P-CSCF
REGISTER
HSS
I-CSCF
REGISTER
S-CSCF
Cx-Query / Cx-Sel...
Cx-Query Resp / Cx-...
REGISTER
Cx-put / Cx-Pull
Cx-put Resp / Cx-...
200 OK
200 OK
200 OK
Abb. 2.13: Ablauf der Registrierung im IMS [TSG-2009d, S. 59].
Sitzungsaufbau
Die nachfolgende Veranschaulichung des Sitzungsaufbaus unterstellt, dass sich Alice und Bob
in verschiedenen Netzen befinden. Dieses Szenario wird ausgewählt, da es das Generischste
ist. Es lässt sich beliebig vereinfachen, bis hin zu dem Punkt, an dem Alice und Bob an
derselben P-CSCF angeschlossen sind.
Um eine Sitzung zu Bob aufbauen zu können, sendet Alice den INVITE-Request zunächst
an ihre P-CSCF (vgl. Abb. 2.14, S. 30). Nachdem diese die Struktur dedr Nachricht, Berechtigung, etc. erfolgreich überprüft hat, leitet sie die Nachricht an die für Alice zuständige
S-CSCF weiter. Diese führt gegebenenfalls Änderungen, die für Alice voreingestellt wurden
durch und leitet die Nachricht anschließend an die I-CSCF von Bobs Netzwerk weiter.
Netz von Alice
P-CSCF
1
9
Alice
Netz von Bob
S-CSCF
I-CSCF
S-CSCF
P-CSCF
2
3
6
7
9
9
9
9
4
5
HSS
8
9
Bob
Abb. 2.14: Sitzungsaufbau im IMS.
Diese ermittelt beim HSS die Adresse der für Bob zuständigen S-CSCF und leitet die Nachricht an diese weiter. Falls für Bob besondere Schritte vorkonfiguriert sind, wird die Nachricht
30
dort verändert. Danach sendet sie die Nachricht an die P-CSCF, an die Bob angeschlossen
ist. Diese übergibt die Nachricht an Bobs UE.
Alle Nachrichten, die im Anschluss an Alice zurückgesendet werden (z. B. 200 OK), werden
über dieselben Call Session Control Functions (CSCFs) zu Alice geleitet.
2.2.4 Funktionen
Im Rahmen der IMS-Spezifikation werden diverse Funktionen standardisiert. Diese Funktionen sind nicht zwangsweise als eigenständige Netzelemente zu verstehen. Mehrere logische
Funktionen können in der Praxis in ein physikalisches Netzelement integriert werden.
Dh
AS
Sh
HSS
Anwendungsschicht
ISC
Ma
Cx
Cx
SLF
Dx
S-CSCF
Mw
Kontrollschicht
Mw
Dx
P-CSCF
Ut
I-CSCF
Mw
Gm
Transportschicht
Mm
UE
Mm
IP Multimedia
Netzwerk
Diameter
IP
SIP
Abb. 2.15: Ausschnitt aus der Referenzarchitektur des IMS [TSG-2009d, S. 21].
Das IMS bietet weitere Funktionen und Dienste, wie z. B. QoS oder Gateways in andere
Netze (z. B. das Public Switched Telephone Network (PSTN)). Da der Fokus dieser Arbeit
auf SPIT und Privacy ruht, wird nicht das ganze IMS vorgestellt. Im Folgenden wird nur auf
die Funktionen eingegangen, die mit SPIT oder Privacy zu tun haben. Beispielsweise wird
auf eine Einführung in die Gateway-Funktionen verzichtet. Zwar kann SPIT theoretisch ins
PSTN geleitet werden, aber aufgrund der dadurch entstehenden Kosten ist dieses Szenario
unwahrscheinlich (vgl. Abschn. 3.4, S. 46).
Der für diese Arbeit relevante Ausschnitt der Referenzarchitektur (vgl. Abb. 2.15, S. 31)
enthält die folgenden Komponenten, die im Anschluss näher beschrieben werden.
31
Call Session Control Function
Die Call Session Control Functions (CSCFs) [TSG-2009d, S. 40–40] sind einige der wichtigsten Funktionen im IMS. Die CSCFs sorgen für die Signalisierung der Nachrichten,
entspreched wie ein SIP-Proxy. Es existieren drei verschiedene CSCF:
1. P-CSCF.
2. I-CSCF.
3. S-CSCF.
Der erste Kontaktpunkt im IMS ist für ein UE die P-CSCF. Um die richtige P-CSCF zu
kontaktieren, bestehen drei Möglichkeiten [TSG-2009d, S. 53–54]:
1. Dem UE wird bei der Registrierung automatisch eine P-CSCF zugeordnet.
2. Er ermittelt die IP-Adresse der P-CSCF über eine Anfrage beim DNS.
3. Die Adresse der P-CSCF ist im UE fest eingetragen.
Sofern sich der Teilnehmer erfolgreich authentifizieren kann, dient ihm die P-CSCF als
Makler in Form eines Statefull-Proxys. Je nach Möglichkeit wird entweder mit Internet
Protocol Security (IPsec) oder mit Authentication and Key Agreement (AKA) (vgl. Kap. 5,
S. 75) ein Tunnel zwischen dem UA und der P-CSCF aufgebaut [TSG-2009a, S. 23]. Aufgrund
dieses Tunnels muss sich der Teilnehmer in Zukunft bei keiner anderen IMS-Funktion mehr
authentifizieren.i Dies signalisiert die P-CSCF, indem sie das P-Asserted-Identity-HeaderFeld in den Header die Nachricht einfügt [TSG-2009a, S. 85]. Die anderen IMS-Funktionen
vertrauen darauf, dass die P-CSCF nur für authentifizierte Teilnehmer einen Tunnel öffnet.
Zusätzlich überprüft die P-CSCF die angenommenen Nachrichten. Hierdurch wird sichergestellt, dass keine ungültigen oder fehlerhaften Nachrichten vom UE kommen. Da SIP ein
textbasiertes Protokoll ist, verbraucht es relativ viel Bandbreite. Dies kann z. B. bei einem
angeschlossenen W-LAN zu starken Verzögerungen führen. Aus diesem Grund kann die PCSCF die Nachrichten komprimieren und wieder dekomprimieren. Des Weiteren wird eine
eventuelle Abrechnung bei kostenpflichtigen Diensten durch die P-CSCF durchgeführt.
Für externe Anfragen an das IMS, ist die I-CSCF der erste Kontaktpunkt. Ihre Adresse
wird über einen DNS-Eintrag publiziert, sodass sie von außerhalb auffindbar ist.
Im Rahmen der Registrierung ermittelt die I-CSCF die Nutzerdaten des Teilnehmers.
Hierfür wird zunächst über Diameter die Adresse der zuständigen HSS bei der SLF abgefragt. Anschließend kann beim HSS die Adresse des zuständigen S-CSCF ermittelt werden.
Somit kann die Registrierungsanfrage an die S-CSCF weitergeleitet werden, die den Request
abschließt. Geht ein Request mit einer E.164-Nummer [ITU-2005] im Header ein, wandelt die
I-CSCF diese in einen Tel-URI [RFC-3966] um. Optional kann die I-CSCF alle Informationen
über das eigene Netz mittels THIGin den Nachrichten chiffrieren.
32
Die S-CSCF tritt als Makler zwischen dem UE und einem angefragten Dienst auf. Aus
diesem Grund wird die Sitzungskontrolle von dieser Funktion durchgeführt. Um zu entscheiden, ob ein Teilnehmer berechtigt ist einen angeforderten Dienst zu nutzen, fragt er beim
zuständigen HSS die Teilnehmerinformationen ab. Wie bereits erwähnt, führt die S-CSCF
die Registrierung durch. In dem Sinne fungiert diese Funktion als Registrar. Das heißt, es wird
eine Relation zwischen den Aufenthaltsinformationen des Teilnehmers (z. B. die IP-Adresse
des Teilnehmers) und seiner IMPU aufgebaut. Anschließend ist die registrierende S-CSCF
dem Teilnehmer für die Dauer der Registrierung zugeordnet.
Nach der Registrierung werden alle Nachrichten des UE über die zugeordnete S-CSCF geleitet. Hierdurch wird der Application Server (AS) festgelegt, an den die Nachrichten geleitet
werden, sofern der Teilnehmer zum angefragten Dienst berechtigt ist.
Enthält der Request des Teilnehmers keinen SIP URI sondern z. B. eine Festnetznummer,
tranformiert die S-CSCF diese Nummer. In der Regel wird dies durch eine Anfrage beim
E.164 Number Mapping (ENUM)-Dienst [RFC-3761] durchgeführt.
Sicherheitstechnisch zu den wichtigsten Aufgaben der S-CSCF zählt die Einhaltung der
Netzwerk-Policy. Beispielsweise darf es keinem unautorisierten Teilnehmer möglich sein, einen
Dienst zu nutzen.
Alle CSCFs sind in der Regel redundant angelegt. Das heißt, in einem gegebenen
IMS befinden sich immer mehrere Ausprägungen der P-CSCF, I-CSCF und S-CSCF. Hierdurch wird einerseits eine Ausfallsicherheit gewährleistet und andererseits die Skalierbarkeit
des Netzes sichergestellt.
Die CSCFs kommunizieren mit Ausnahme der Datenbankdienste mittels des SIP. Anfragen
an den HSS oder die SLF werden über einen diameterbasierten Referenzpunkt abgewickelt.
Datenbankfunktionen
Das IMS enthält zwei Datenbankfunktionen zur Verwaltung aller relevanten Informationen.
1. Home Subscriber Server (HSS).
2. Subscription Locator Function (SLF).
Der HSS [TSG-2009d, S. 125–126] fungiert als zentrale Anlaufstelle für alle teilnehmerrelevanten Informationen. In ihm werden Daten zur Sitzungssteuerung hinterlegt. Beispielsweise
werden hier Aufenthalts-, Sicherheits- und Profilinformationen sowie die aktuell zugewiesene
S-CSCF abgespeichert.
In großen Netzwerken können mehrere HSS vorhanden sein. Die Informationen zu einem
bestimmten Teilnehmer sind jedoch immer nur in einem HSS vorhanden. Um den richtigen
HSS zu ermitteln, existiert die SLF [TSG-2009d, S. 126–128] . In ihr werden TeilnehmerHSS-Relationen hinterlegt.
Sowohl der HSS als die SLF werden über einen auf Diameter [RFC-3588] basierenden
Referenzpunkt kontaktiert.
33
Application Server
Der Application Server (AS) bietet dem Netzwerk Dienste an. Im Rahmen dieser Ausarbeitung ist der AS jedoch weitestgehend uninteressant, da er von SPIT kaum betroffen wird.
Als Ausnahme sei hier zu nennen, dass der AS als B2BUA im Sinne des SIP fungieren kann.
IP Multimedia Services Identity Module
Das ISIM [TSG-2009b] ist der Träger für wichtige Teilnehmerinformationen. Ist kein
ISIM vorhanden, können die Teilnehmerinformationen im USIM gespeichert werden. Dies ist
für eine erfolgreiche Authentifikation erforderlich, somit kann ohne USIM keine Kommunikation mit dem IMS stattfinden. Im Mobilfunkbereich ist das ISIM zusammen mit dem SIM
oder dem USIM auf der UICC des Teilnehmers hinterlegt.
Abb. 2.16: Skizze einer Universal Integrated Circuit Card.
Der Ausdruck SIM wird in der Praxis oft für eine UICC synonym verwendet. Bei der Karte
(vgl. Abb. 2.16, S. 34), die in ein Mobiltelefon zur Registrierung im Netz eingesetzt werden
muss, handelt es sich um die UICC und nicht um das SIM. Das SIM ist neben dem ISIM ein
Modul, dass auf der UICC abgelegt ist.
Wie beschrieben, beinhaltet das ISIM Informationen, die für eine erfolgreiche Registrierung
erforderlich sind. Auf alle im ISIM gespeicherten Informationen kann nur lesend zugegriffen werden. Im Detail handelt es sich um folgende Daten [TSG-2009b, S. 9–17]:
• IMPI: Das ISIM speichert die IMPI des Teilnehmers. Auf einem ISIM kann immer
nur eine IMPI gespeichert sein.
• Heimatnetz-Domain-URI: Der SIP URI des Heimatnetzes wird in diesem Feld gespeichert. Es wird benötigt, um im Registrationsprozess die Adresse des Heimatnetzes
zu ermitteln. Auf einem ISIM kann immer nur ein Heimatnetz-Domain-URI gespeichert
werden.
• IMPU: Auf dem ISIM werden ein oder mehrere IMPUs gespeichert.
• Long-term-Secret: Das Long-term-Secret wird für die Authentifikation benötigt. Mit
diesem können die gesendeten Nachrichten verschlüsselt und die empfangenen Nachrichten entschlüsselt werden.
34
2.3. Zusammenfassung
User Equipment
Das UE [TIS-2009, S. 29–30] bezeichnet die Endgeräte des Teilnehmers, über die es Zugang
zum IMS erhält. Damit das UE für VoIP genutzt werden kann, beinhaltet es den UA im Sinne
des SIP.
2.3 Zusammenfassung
Das IMS stellt den Rahmen für diese Arbeit bereit. Nachdem im nächsten Kapitel das SPIT
genauer beschrieben wird, werden sich die Betrachtungen danach auf das IMS beziehen. Ob
sich SPIT unterbinden lässt, ist maßgeblich von den Fähigkeiten des IMS abhängig.
Hierbei spielt das SIP eine tragende Rolle. Will ein Spammer seine Botschaften verteilen,
wird dies in der Regel über dieses Protokoll abgewickelt. Um die Möglichkeiten zu verstehen,
ist daher eine Einführung in die Funktionsweise des SIP unumgänglich.
In diesem Kapitel wurde auf beide Themen ausführlich eingegangen, sodass die folgenden
Kapitel leichter zu verstehen sind.
35
36
Kapitel
3
Spam over Internet Telephony
In dieser Arbeit wird beschrieben, inwieweit Spam over Internet Telephony (SPIT) für das
IMS problematisch ist. Nachdem in die Thematik des IMS eingeführt wurde, wird in diesem
Kapitel das SPIT erklärt.
Zunächst wird definiert, was im Rahmen dieser Arbeit unter SPIT zu verstehen ist (vgl.
Abschn. 3.1, S. 37). Anschließend wird untersucht, welchen sozialen Einfluss Spam im Allgemeinen auf die Gesellschaft nimmt (vgl. Abschn. 3.2, S. 40). Um die Auswirkungen von
SPIT auf das IMS zu identifizieren, wird die Arbeitsweise der Spammer vorgestellt (vgl. Abschn. 3.3, S. 41). Im Anschluss daran wird analysiert, ob sich SPIT finanziell lohnt (vgl.
Abschn. 3.4, S. 46). Abschließend wird der rechtliche Rahmen für Spam in Deutschland kurz
vorgestellt (vgl. Abschn. 3.5, S. 48).
3.1 Definition
Um SPIT zu verstehen, muss das klassische E-Mail-Spam betrachtet werden. Den Ausdruck SPIT gäbe es vermutlich nicht, wenn es vorher kein E-Mail-Spam gegäben hätte. Das
liegt daran, dass beides Unterbegriffe des Ausdrucks Spam sind. Da E-Mail-Spam die erste Form von Spam ist, trug es maßgeblich zur Definition des Spambegriffs bei. In diesem
Abschnitt werden die Gemeinsamkeiten zwischen diesen beiden Begriffen beschrieben.
Um das Wort Spam begreiflicher zu machen, wird zunächst die Herkunft des Wortes beschrieben. Im Anschluß wird das Wort Spam genauer definiert, um zu beschreiben, was
im Rahmen dieser Arbeit unter Spam zu verstehen ist. Abschließend wird der Unterschied
zwischen E-Mail-Spam und SPIT erklärt, womit ein eindeutiges Gesamtbild für das SPIT
entsteht.
37
Kapitel 3. Spam over Internet Telephony
3.1.1 Herkunft des Wortes Spam
R (SPAM)
R anlehnt. Wie
Spam ist ein Wort, was sich vermutlich an die Marke Spiced Ham
R das heute bekannte Spam wurde, ist nicht vollständig bekannt. Im Wesentlichen
aus SPAM
scheinen zwei Ereignisse eine tragende Rolle zu spielen [Zdz-2005, S. 4]:
• Ein Sketch namens SPAM“ [Mon-2009] aus der Sendung Monty Python’s Flying
”
”
Circus“.
• In Newsgroups wurde das Wort Spamming“ für das übermäßige Senden von Infor”
mationen genutzt.
Eggendorfer [Egg-2005, S. 19–20] bestätigt diese beiden Thesen, sieht sie aber nicht unabhängig voneinander. Demnach war die Schlüsselrolle der Sketch von Monty Python.
Das Wort Spamming wurde nämlich am 31. März 1993 erstmals in einer Newsgroup
erwähnt. Damals war Monty Python sehr beliebt und einige der Newsgroup-Nutzer waren
große Fans von ihm. Dadurch soll diese Anspielung auf den Sketch verstanden worden und
das Wort Spam seine Bedeutung erhalten haben.
3.1.2 Bedeutung in dieser Arbeit
Da das Wort Spam keinen direkten Rückschluss auf seine Bedeutung zulässt, wird es oft
sehr unterschiedlich verwendet. Für die einen ist Spam jede Art von massenhaft versendeten
E-Mails, für andere sind es nur solche mit werbendem Charakter. Die Definition scheint sich
jedoch immer enger um den Begriff UCE zu schnüren. E-Mail-Spam hat demnach werbenden Charakter und ist unerwünscht. Dieser Ausdruck wird mittlerweile sowohl vom
Bundesamt für Sicherheit in der Informationstechnik (BSI) [BSI-2005, S. 14] und der International Telecommunication Union - Telecommunication Standardization Sector (ITU-T)
[ITU-2006a, S. 7] eingesetzt.
Die Verwendung des Wortes Spam in der Wissenschaft steht jedoch im Widerspruch mit
der Definition im Duden [Dud-2006, S. 977]. Dort wird Spam wie folgt beschrieben:
[...] unaufgefordert an viele Internetnutzer auf einmal versandte E-Mail (zu Wer”
bezwecken o. Ä.) [...] an viele Newsgroups gleichzeitig übermittelte Nachricht [mit
belanglosem Inhalt] [...]“
Diese Definition ist zu allgemein. Demnach ist das Versenden einer Geburtstagseinladung
als Spam zu bezeichnen. Sie wird in der Regel unaufgefordert an viele Internetnutzer gleichzeitig mit einen werbeähnlichem Betreff gesendet. Aus diesem Grund ist der in der Wissenschaft
verwendete Ausdruck UCE treffender.
UCE müssen werbenden Charakter haben und unerwünscht sein. Dieser Punkt spiegelt
sich in der Erfahrung eines jeden E-Mail-Nutzers wieder. In Spam wird unter anderem für
38
3.1. Definition
Pharmaka, Druckerpatronen, Aktien, etc. geworben. Besonders gefährlich sind sogenannte Phishing-Mails oder Vishing-Anrufe. Hier wird dem Teilnehmer die Echtheit einer
wichtigen Nachricht vorgetäuscht. Beispielsweise wird mit einer falschen Bankmail versucht,
die Kontodaten zu erschleichen.
Rein rechtlich gesehen ergibt sich beim Umgang mit UCE eine wichtige Unterscheidung
(vgl. Abschn. 3.5, S. 48). Ist der Sender der vermeintlichen UCE dem Empfänger bekannt,
wurde die E-Mail nur an diesen gesendet, dann handelt es sich nicht mehr um Spam.
Massenhaft versendete E-Mails, die einen Teilnehmer über angebliche Gefahren warnen,
sogenannte Hoaxes“ [Zie-2009], fallen aus diesem Grund nicht unter Spam. Hoaxes werden
”
nämlich in der Regel durch befreundete Teilnehmer weitergeleitet.
Mit SPIT verhält es sich ähnlich wie mit E-Mail-Spam. Im Ausdruck SPIT ist die Bezeichnung Spam enthalten, daher muss es Gemeinsamkeiten geben. Der werbende Charakter
ist auf jeden Fall ein wesentlicher Bestandteil von SPIT. Außerdem ist die massenhafte Zustellung ein wichtiger Bestandteil von SPIT. Trotz der Gemeinsamkeiten unterscheidet sich
SPIT von E-Mail-Spam.
Der essenziellste Unterschied liegt in der Zustellung. Eine E-Mail kann vom Server auf
Spam-Schlagwörter und dergleichen untersucht werden. Findet er keine, wird die E-Mail
normal zustellt. Bei einer E-Mail kommt es nicht darauf an, ob sie sofort oder leicht verzögert
zugestellt wird.
Bei SPIT ist das nicht möglich. Im Gegensatz zur E-Mails ist beim Telefondient diese
Verzögerung unerwünscht. Zusätzlich ist der Inhalt des Anrufs erst bekannt, wenn der
Teilnehmer abgenommen hat. Wegen des Störfaktors ist es für Gegenmaßnahmen jedoch zu
spät, wenn das Endgerät des Teilnehmers klingelt.
Selbst wenn eine UCE zugestellt wird, kann der Nutzer selbst entscheiden, ob er sie liest
oder löscht. Bei einem SPIT-Anruf kann der Teilnehmer den SPIT nur erkennen, wenn er ihn
anhört.
Auch wenn dies nicht der eigentlichen Definition von SPIT entspricht, wird im Rahmen
dieser Arbeit eine umfassendere Bedeutung benutzt. Denn der massenhafte Anruf ohne werbenden Charakter kann in Form eines Denial of Service (DoS)-Angriffs gefährlich sein.
Aus diesem Grund wird die allgemeinere Definition für diese Arbeit verwendet.
3.1.3 Formen von Spam mittels Session Initiation Protcol
Inwiefern kann Spam mit dem Session Initiation Protocol (SIP) betrieben werden? Für das
SIP gibt es viele denkbare Möglichkeiten zu werben. Die folgenden drei Möglichkeiten haben
sich jedoch in der Forschung herauskristallisiert [RFC-5039, S. 3–8]:
• Call-Spam: Mit Call-Spam ist der massenhafte Versuch, Werbeanrufe zu initiieren gemeint. Genauer beschreibt Call-Spam das Senden von INVITE-Requests. Der Spammer
versucht, eine Verbindung aufzubauen und dann seine Werbebotschaft durchzugeben.
39
Dies kann durch ein Callcenter, eine automatisch abgespielte Nachricht usw. geschehen.
Call-Spam ist dasselbe wie SPIT.
• Instant Message-Spam: Ähnlich zum E-Mail-Spam werden dem Rezipienten bei
dieser Form Textnachrichten zugesandt. Nur geschieht dies hier in der Regel über
eine MESSAGE-Request. Instant Message-Spam wird als Spam over Instant Messaging
(SPIM) bezeichnet.
• Presence-Spam: Presence-Spam ist auf den ersten Eindruck etwas ungewöhnlich. Im
Grund ist es recht ähnlich zu SPIM. Der Spammer versucht, über ein SUBSCRIBERequest in die Freundesliste des Opfers zu gelangen. Sobald er auf der Freundesliste
ist, kann er jegliche andere Form von Spam gegen das Opfer einsetzen. Diese Form des
Spams wird als Spam over Presence Protocol (SPPP) bezeichnet.
Selbst wenn diese Formen des Spams in ihrer Ausführung absolut unterschiedlich sind,
können manche Gegenmaßnahmen für alle Formen von Spam eingesetzt werden.
3.2 Soziale Auswirkungen
Nach Berichten von Cisco System [Cis-2008, S. 13], MessageLabs [Mes-2009, S. 5] und der
ITU-T [ITU-2008, S. 9], waren 2007 und 2008 ungefähr 85 % der versendeten E-Mails
Spam. Findet SPIT eine ähnlich große Verbreitung, kann des Medium Voice over IPs (VoIPs)
unbrauchbar werden.
Denn die Auswirkungen von E-Mail-Spam gehen oft schon über die reine Belästigung hinaus. Bei manchen Nutzern ist der E-Mail-Spamandrang derart gewaltig, dass ihre Postfächer
überlaufen. In einer solchen Masse von Spam-E-Mails gehen erwünschte E-Mails unter, EMail-Server können zusammenbrechen und nicht zuletzt wehren schlecht konfigurierte Spamfilter normale E-Mails ab.
2007 wurde außerdem ein Wandel im Vorgehen der Spammer beobachtet. Es enthielten
83 % des versendeten Spams Links, die zu URI-basierten Viren führen [GW-2008, S. 225].
Die Situation ist bei SPIT nicht besser. Doch anders als bei E-Mail-Spams ist der Störfaktor
bei SPITs deutlich höher. Wenn bei einem Teilnehmer nur jeder zehnte Anruf erwünscht
ist, kann sich die Teilnehmer vom VoIPs abwenden. Außerdem sind durch SPITs nicht nur
nationale Gespräche gebührenfrei. Insbesondere für internationale Teilnehmer ist es sehr lukrativ, über VoIPs zu telefonieren. Deshalb kann es passieren, dass der amerikanische Spammer mitten in der Nacht versucht, seinen SPITs an einen deutschen Teilnehmer zuzustellen.
Spätestens jetzt ist die Reizschwelle vieler Nutzer überschritten. Zumal diese Problematik
mit einem Festnetzanschluss weniger präsent ist.
Einen eher ungewöhnlichen Blick auf Spam nahm eine Studie von McAfee [McA-2009].
Nach dieser Studie sind 2008 geschätzte 62 Billionen Spam-E-Mails versandt worden. Dieses
40
3.3. Vorgehen
Spamaufkommen hat ungefähr 33 Milliarden Kilowattstunden Abwärme produziert.
Das entspricht dem Stromverbrauch von 2,4 Millionen Haushalten. Spam ist demnach ebenfalls ein ökologisches Problem.
3.3 Vorgehen
Um SPIT erfolgreich zu unterbinden, muss klar werden, wie SPIT entsteht. SPIT ist mehr
als der Anruf selbst. Er kann nur durchgeführt werden, wenn zuvor Adressen potenzieller
Opfer gesammelt und eine Verbindung zu ihnen aufgebaut wurde.
In seiner Diplomarbeit [ElK-2008, S. 37–40] hat Rachid El Khayari drei Schritte (vgl.
Abb. 3.1, S. 41) vorgestellt, die zur Durchführung von SPIT notwendig sind. Demnach gehört
das Sammeln der Zieladressen zum SPIT-Prozess dazu. Auf Basis der gesammelten Adressen
wird eine Verbindung zu möglichst vielen Teilnehmern aufgebaut und die Werbebotschaft
übertragen. Im Folgenden werden diese drei Schritte genauer beschrieben.
Schritt 1
Informationen
sammeln
Schritt 2
Sitzung
etablieren
Schritt 3
Nachricht
übertragen
Abb. 3.1: Drei Schritte zum SPIT [ElK-2008, S. 37].
3.3.1 Informationen sammeln
Um einen Anruf zu starten, benötigt der Spammer zunächst valide Adressen der Teilnehmer. Woher erhält ein Spammer diese Adressen? In der Literatur werden insgesamt die
folgenden vier Möglichkeiten identifiziert [CDT-2003, S. 14–15][ElK-2008, S. 37–39][Egg-2005,
S. 16–17].
1. Kaufen.
2. Harvesting.
3. Aktiver Scan.
4. Passiver Scan.
Jedes Verfahren ist für sich unabhängig einsatzfähig, es ist aber eine Kombination der
Verfahren denkbar. Im Folgenden wird auf die einzelnen Möglichkeiten separat eingegangen.
Kaufen
Der einfachste und technisch aufwandloseste Weg an Adressen zu gelangen, besteht im
Kauf einer fertigen Liste. Manche Spammer bieten interessierten Teilnehmern ihre Listen zum
41
Kauf an. Beispielsweise können über das Internet eine Millionen E-Mail-Adressen für 39,95 $
[Bul-2008] gekauft werden. Gegen den Verkauf von solchen Listen lässt sich im Nachhinein
prinzipiell nichts mehr unternehmen. Wohnt der Verkäufer in einem Land mit gültigem AntiSpam-Gesetz, kann rechtlich gegen ihn vorgegangen werden. Unabhängig davon wurde die
Liste bis dahin vermutlich weiterverkauft und kann somit nicht mehr aus dem Umlauf entfernt
werden.
Harvesting
Harvesting beschreibt das automatische Sammeln von Adressen, die im Internet zu finden
sind. Das Internet bietet zwei potenzielle Quellen [CDT-2003, S. 14–15][Egg-2005, S. 16–17],
die Zugang zu Adressen bieten.
1. Internetseiten.
2. Verzeichnisse.
Zum Sammeln der Adressen kommen sogenannte Bots zum Einsatz. Bots sind kleine
Programme, die automatisch im Internet nach Adressen suchen. Sie verfolgen beispielsweise
die Links, um auf weiteren Internetseiten suchen zu können.
Zumindest in Deutschland, ist das Sammeln der Adressen über die Internetseiten ein
sehr vielversprechender Ansatz. Denn das deutsche Gesetz [BMJ-2008b, § 5 Abs. 1 Nr. 2]
verpflichtet die Inhaber von kommerziell genutzten Internetseiten zur Angabe einer elektronischen Kontaktadresse, insbesondere mittels elektronischer Post. Diese elektronische
Kontaktaufnahme läuft in der Regel auf eine E-Mail-Adresse hinaus. Durch dieses Gesetz
muss auf jeder kommerziell genutzten Internetseite mindestens eine E-Mail-Adresse hinterlegt sein. Setzt sich VoIP flächendeckend durch, kann davon ausgegangen werden, dass eine
Kontaktmöglichkeit mittels VoIP in die Kontaktangaben aufgenommen wird.
Eine weitere interessante Quelle für Adressen sind elektronische Verzeichnisse. Für SIPAdressen ist das klassische Telefonbuch die beste Datenquelle. In ihm stehen überwiegend
valide Nummern. Es handelt sich zwar bisher nur um klassische Festnetznummern, doch
zukünfigt wird sich dieses Problem sicherlich ändern. Zum einen, weil durch das E.164 Number
Mapping (ENUM) [RFC-3761] ein Mechanismus bereit steht, um Festnetznummern in EMail-Adressen, Session Initiation Protocol Uniform Ressource Identifier (SIP
URI) usw. umzuwandeln. Aus diesem Grund wird ENUM als potentielle Goldgrube für
Spammer bezeichnet [RFC-5039, S. 14]. Ungeachtet vom ENUM könnten manche VoIPProvider die normale Festnetznummer als User-Teil für ihre SIP URI einsetzen.
42
3.3. Vorgehen
Aktiver Scan
Bei einem aktiven Adressscan versucht der Angreifer durch Ausprobieren die zugeteilten
SIP URI zu erraten. Da SIP zwei Arten von SIP URI bereitstellt, kann der Scan auf zwei
Weisen durchgeführt werden.
1. Aktiver Scan nach permanenten SIP URI.
2. Aktiver Scan nach temporären SIP URI.
Diese beiden Varianten unterscheiden sich leicht in ihrer Ausführung. Aus diesem Grund
werden sie nacheinander vorgestellt. Zunächst wird auf den aktiven Scan nach permanenten
SIP URI eingegangen, da hierdurch Vorarbeit für die temporären SIP URI geleistet werden
kann. Um effizient nach permanenten SIP URI scannen zu können, benötigt ein Angreifer
zunächst zwei Dinge:
1. Mindestens einen gültigen Account.
2. Wissen über den Aufbau des SIP URI des Betreibers.
Ein gültiger Account ist leicht eingerichtet. Angenommen der Angreifer hat bei einem
Anbieter namens beispiel.de einen Account. Bei beispiel.de haben alle SIP URI bsp“ als
”
Präfix, gefolgt von einer 5-stelligen Zahl. Somit können 100.000 Adressen von sip:bsp00000@
beispiel.de bis sip:[email protected] zugeordnet werden.
Der Angreifer weiß nicht, welche dieser Adressen zugeordnet sind und welche nicht. Bei
einem aktiven Scan versucht er dies herauszufinden, indem er jeden möglichen Account
ausprobiert. Am geeignetsten dafür ist das Senden eines INVITE-Requests, da dieser im
Erfolgsfall direkt in einer Kommunikation endet [ElK-2008, S. 38]. Je nachdem, ob der SIP
URI vergeben ist oder nicht, ergeben sich daraus drei Szenarien:
1. SIP URI ist zugewiesen: In diesem Fall sendet der UAS ein 200 OK an den UAC
zurück. Es kann eine Verbindung direkt aufgebaut und der SIP URI als zugewiesen
gespeichert werden.
2. SIP URI ist zugewiesen, momentan aber nicht registriert: In diesem Fall sendet
der Proxy ein 480 Temporarily Unavailable zurück. Der SIP URI kann als zugewiesen
aber nicht erreichbar gespeichert werden.
3. SIP URI ist nicht zugewiesen: In diesem Fall sendet der Proxy ein 404 Not Found
an den UAC zurück. Dieser SIP URI kann als nicht zugewiesen separat gespeichert
werden.
Auf diese Weise erhält der Angreifer drei Listen mit SIP URI. Eine Liste mit zugeordneten Adressen, die sofort angerufen werden können. Eine Liste mit zugeordneten Adressen,
43
die momentan nicht registriert sind. Sowie eine Liste mit nicht zugeordneten Adressen. Wobei
die letzte Liste für zukünftige Scans genutzt werden kann.
Will der Angreifer temporäre anstatt permanente SIP URI muss er etwas anders vorgehen. Doch warum sollte er versuchen, temporäre SIP URI zu erlangen? Normalerweise reicht
ein permanenter SIP URI völlig aus, um einen Teilnehmer zu kontaktieren.
Der Vorteil des temporären SIP URI liegt in der Möglichkeit, den Teilnehmer unter Ausschluss der Proxy direkt anzurufen. Da der Proxy umgangen wird, können die Nachrichten nicht von ihm auf SPIT untersucht werden. Somit kann er durch den Ausschluss der
Proxy jeden beliebigen Namen als Absender eingeben. Außerdem ist es nicht mehr nötig, das
der Angreifer selbst einen validen Account des Betreibers hat.
Wurde vor dem Scan nach temporären SIP URI nach permanenten SIP URI gesucht, kann
dies vorteilhaft sein. Denn in der Implementierung mancher Proxy wird in der Response das
Contact-Header-Feld mit eingefügt [ElK-2008, S. 38]. Somit erhält ein Angreifer praktisch
gratis den temporären SIP URI dazu.
Wird nur nach temporären SIP URI gescannt, muss der Angreifer mehr Aufwand betreiben
als im obigen Fall. Der Angreifer braucht nach wie vor die Information über den Aufbau
eines SIP URI, wenn er keinen eigenen Account beim Anbieter hat. Sei beispiel.de nicht nur
ein VoIP-Provider, sondern zusätzlich ein ISP. Er verteilt für alle seine Kunden IP-Adresse
von 192.0.2.0 bis 192.0.2.255. Ein Angreifer muss für jeden möglichen Benutzernamen
(bsp00000 bis bsp99999) ein INVITE-Request an jede mögliche IP-Adresse senden, bis er
Erfolg hat. Den Request sendet er, je nach Transportprotokoll, an den korrespondierenden
Port.
Passiver Scan
Das aktive Sammeln ist eine sehr effektive Quelle für valide SIP URI. Der Angreifer geht
jedoch das Risiko ein, entdeckt zu werden. Alternativ dazu kann er durch einen passiven
Scan an SIP URI gelangen.
Bei einem passiven Scan veröffentlicht der Angreifer einen Service, beispielsweise auf einer Internetseite. Um diesen Service nutzen zu können, muss sich der Interessent entweder
registrieren oder eine Hotline anrufen. Der Angreifer merkt sich alle SIP URI der
Hotline-Anrufer und der registrierten Nutzer.
Solange der Service interessant genug ist, sammelt der Angreifer auf diese Weise jede Menge
SIP URI. Normalerweise erlangt der Angreifer dadurch permanente SIP URI. Handelt es sich
jedoch um eine Hotline, werden ihm zusätzlich die temporären SIP URI übermittelt. Diese
Adressen erhält der Spammer, da im Standard das Contact-Header-Feld für eine INVITERequest vorgeschrieben ist [RFC-3261, S. 162]. Da temporäre SIP URI maximal 24 Stunden
gültig sind, müssen diese zeitnah für die SPIT-Zustellung genutzt werden.
44
3.3. Vorgehen
3.3.2 Sitzung etablieren
Hat der Spammer genügend Adressen gesammelt, kann er beginnen das Spam zu verteilen. Dazu muss er eine Verbindung mit den potenziellen Opfern herstellen. Aufgrund der
gesammelten Listen bieten sich dem Spammer zwei Möglichkeiten die Anrufe zu initiieren
[ElK-2008, S. 39]:
1. SPIT via Proxy: Hierbei greift der Spammer auf die Liste mit den permanenten SIP
URI zu. Die Verbindung wird über die Infrastruktur des VoIP-Betreibers aufgebaut.
Dies ermöglicht dem Betreiber, die Nachrichten mit geeigneten Anti-Spam-Maßnahmen
abzuwehren. Außerdem kann er den Spammer bestrafen, da dessen Identität dem Betreiber bekannt ist.
2. Direct-IP-SPIT: Hierbei greift der Spammer auf die Liste mit den temporären SIP
URI zu. Die Verbindung wird direkt mit dem Spamopfer hergestellt. Dadurch können
keine serverseitigen Anti-Spam-Maßnahmen des VoIP-Betreibers eingreifen. Somit gibt
es keine Instanz, die den Spammer durch Analysen erkennen und identifizieren kann.
3.3.3 Nachricht übertragen
Der letzte Schritt, den der Angreifer durchführen muss, ist das Senden der Nachricht. Je nach
Art der Nachricht lassen sich drei Szenarien unterscheiden [Han-2006, S. 1–2]:
• Callcenter: In einem Callcenter sind mehrere Personen angestellt, die telefonische
Werbeanrufe durchführen. Ein Computer sorgt dafür, dass jeder Mitarbeiter mit Kunden versorgt wird. Ein Callcenter benötigt viel Geld für Mitarbeiter, Räume und Technik, kann aber sehr viel SPIT produzieren.
• Calling-Bots: Calling-Bots bauen automatisch eine Verbindung zum Zielteilnehmer
auf. Sobald eine Verbindung steht, übertragen sie eine vorher aufgezeichnete Werbebotschaft und beenden das Gespräch wieder. Sie sind deutlich günstiger als Callcenter,
da sie keine Gehälter, Räumlichkeiten oder größere Technik benötigen. Trotzdem kann
durch sie ein sehr großer Durchsatz erzielt werden.
• Ringtone-SPIT: Einige Telefone sind werksmäßig in der Lage, das Alert-Info-HeaderFeld auszuwerten. Der dort angegebene URI enthält dann einen Link zu einer Audiodatei mit der Werbebotschaft. Die Werbung wird in Form des Klingeltons abgespielt.
Dadurch verbreitet das Telefon den SPIT, bevor der Teilnehmer den Hörer abnimmt.
Wenn das Header-Feld Altert-Info nicht unterstützt wird, ist diese Form des SPIT die
störendste. Der SPIT ist dann nur dazu da, den Teilnehmer zu stören. Da durch dieses Header-Feld kein wirklicher Mehrwert produziert wird, empfiehlt es sich, dessen
Auswertung zu deaktivieren.
45
3.4 Kostenberechnung
Durch den Versuch der Universität Duisburg-Essen [Hof-2009, S. 7–9] ist mittlerweile klar,
das SPIT ein reales Problem ist. Bleibt zu klären, ob sich SPIT gegenüber der normalen
Telefonwerbung durchsetzen wird. Zwischen diesen beiden gibt es zwei wesentliche Unterschiede. Das Netz ist nicht IP-basiert und die Häufigkeit ist deutlich geringer. Trotz der
geringeren Quantität fühlen sich bereits dadurch viele Teilnehmer gestört.
Das SPIT mit großer Sicherheit aufkommen wird, liegt genau an dieser niedrigen Quantität.
Das Problem an der Telefonwerbung sind die Kosten. Ein Anruf aus dem deutschen Festnetz,
in das deutsche Festnetz ist relativ teuer. Somit ist es eine reine Frage des Geldes, wie viel
Telefonwerbung es gibt.
Und genau dort setzt SPIT an. Viele VoIP-Telefonate sind kostenfrei. Das ermöglicht
den Werbeagenturen deutlich höhere Gewinnmargen. Doch warum haben die Werbeagenturen
nicht bereits auf VoIP umgestellt? Momentan sind noch viele Anschlüsse am Festnetz angemeldet. Und Telefonate aus dem VoIP-Netz ins Festnetz kosten ebenfalls Geld (ca. 0,029 e).
Aber wenn in Zukunft mehr Teilnehmer auf VoIP wechseln, lohnt sich das Geschäft mehr.
Um die Kosten zu verdeutlichen, wird im Folgenden ein kurzes Rechenbeispiel eingeführt.
Die Preise sind aus einem Memo der Internet Engineering Task Force (IETF) entnommen
[RFC-5039, S. 4–6]. Die Kosten von Spam drücken sich im Preis pro Anruf pc aus. Für die
Berechnung werden folgende Informationen benötigt:
• ns :
Die Anzahl an Anrufen, die parallel abgeschlossen werden können.
• pm :
Der monatliche Preis für die Bereitstellung der Telefon- oder Internetleitung.
• ps :
Die Gebühr, die pro Sekunde eines Telefonats berechnet wird.
• sc :
Die Anzahl der Sekunden, die eine Nachricht dauert.
• sm :
Die Anzahl der Sekunden, die ein Monat hat.
Spam wird günstiger, je mehr Anrufe getätigt werden, denn dadurch sinkt der Anteil
der Fixkosten pro Anruf. Für dieses Beispiel wird eine Monatslänge von 30 Tagen und eine
Anruflänge von 10 Sekunden je durchgeführten SPIT-Anruf angenommen. Sobald alle Informationen vorhanden sind, kann der Wert pc mit der folgenden Formel berechnet werden:
pm
+ ps = pc
(3.1)
sc ·
s m · ns
Um SPIT über das Festnetz zu verteilen, empfiehlt es sich, eine T1- oder T3-Leitung zu
mieten. Mit einem analogen Telefonanschluss sind nur ein und bei Integrated Service Digital
Network (ISDN) zwei Telefonate parallel möglich. Mit einer T1-Leitung können 24 Anrufe
simultan durchgeführt werden. Je mehr Anrufe gleichzeitig laufen können, je geringer fallen
die Kosten pro Anruf aus. Eine T1-Leitung kostet pro Monat ungefähr 250 $. Eine Sekunde
46
3.4. Kostenberechnung
Telefonieren wird mit 0,025 Cent berechnet. Werden alle diese Informationen in die Formel
(vgl. Formel 3.1, S. 46) eingesetzt, berechnet sich folgender Wert:
250 $
$
+ 0, 00025 /s = 0, 00254019 $
10 s ·
2.592.000 s · 24
(3.2)
Durch den Einsatz von SIP können diese Kosten deutlich gesenkt werden. Angenommen
ein INVITE-Request benötigt ungefähr 1 KB. Zur Übertragung der Sprache wird eine starke Kompression wie z. B. G.723.1 [ITU-2006b] mit 5,3 Kbps genutzt. Zusammen mit dem
Overhead durch das Real-time Transport Protocol (RTP), User Datagram Protocol (UDP)
und Internet Protocol (IP) benötigt ein Anruf 16 Kbps. Mit einem Upstream von ungefähr
1000 Kbps können 62 Anrufe parallel durchgeführt werden. Ein Internetanschluss kostet
durchschnittlich 50 $ im Monat. Da keine Gebühren für eine Telefoneinheit anfallen, entsteht
nach vorher beschriebender Formel (vgl. Formel 3.1, S. 46) folgender Preis:
50 $
$
+ 0, 00000 /s = 0, 00000311 $
10 s ·
2.592.000 s · 62
(3.3)
Offensichtlich ist die Festnetz-Telefonwerbung mit 254.019 µCent, runde 800-mal teurer
als SPIT mit 311 µCent. Zu den Telefonkosten kommen die Kosten für die Hardware. Wobei
dort VoIP ebenfalls günstiger ist, da es mit einem einfachen Computer durchgeführt werden
kann. Wie zu erkennen ist, sind die Kosten bei der Festnetz-Telefonwerbung im Wesentlichen von der Gebühr für eine telefonierte Sekunde abhängig. Die Fixkosten rücken in den
Hintergrund. Sie können somit vernachlässigt werden, da sie weit seltener anfallen, als der
Monatsmietpreis.
In dieser Berechnung wird jedoch nicht berücksichtigt, dass viele Spammer sogenannte Botnetze aufbauen, um Spam zu versenden [Bru-2003][ENI-2007, S. 3]. Bei einem
Botnetz versucht der Spammer, die Steuerung über einen am Internet angeschlossenen Computer zu erlangen. Dies geschieht beispielsweise durch die Einschleusung eines Trojaners.
Dadurch wird der Computer zu einem sogenannten Zombie“. Der Spammer nutzt anschlie”
ßend sein Botnet zum Versenden von Spam. Ein Spammer ist jedoch nicht darauf angewiesen,
sich die Arbeit zu machen, selbst ein Botnetz aufzubauen. Mittlerweile können fertige Botnetze im Internet für 5 bis 100 $ für 1.000 Zombie“-Rechner gekauft werden [Fin-2009, S. 3].
”
Dadurch sinken die Kosten für SPIT nahezu auf die Kosten das Botnet.
Telefonwerbung ist allerdings nicht die einzige Konkurrenz zu SPIT. Im Internet wird
Werbung bereits mittels E-Mail übertragen. Da E-Mails deutlich weniger Bandbreite als
ein Telefonat benötigen, können mehr Nachrichten versendet werden. Bei einem Telefonat
ist die Verbindung für die Dauer des Gesprächs für weitere Telefonate blockiert. E-Mails
können parallel gesendet werden und blockieren die Leitung anschließend nicht. E-MailSpam ist aber leichter zu entdecken und abzuwehren. Dadurch durchqueren nur sehr
wenige Nachrichten die Spamfilter. In diesem Sinne kann SPIT deutlich attraktiver sein, da
es wahrscheinlicher ist, jemanden zu erreichen.
47
3.5 Gesetzeslage
Da Gesetze grundsätzlich eine Angelegenheit der Nationen sind, gibt es keine einheitliche
Regelung. Dieser Abschnitt beschränkt sich daher nur auf in Deutschland direkt anwendbare
Gesetze. Darunter fallen die Vorgaben der Europäischen Union (EU) sowie die deutschen
Gesetzestexte und Rechtssprechungen.
Innerhalb der EU spielt nur eine geringe Rolle, in welchem Land sich der Versender des
Spams befindet, da die EU einheitliche Richtlinien erlassen hat. Daher greift das sogenannte Herkunftslandprinzip [BMJ-2008b, § 3 Abs. 4 Nr. 3]. Das bedeutet, dass immer der
Rechtsrahmen des Landes angewendet wird, in dem sich der Empfänger der Nachrichten
befindet.
Bisher wird der Versender von unerwünschten Nachrichten stets als Spammer bezeichnet.
Dieser Ausdruck ist jedoch nur treffend, sofern es sich um rechtswidrige Werbung handelt. Um
in die Gesetzeslage einzuführen, muss von einem rechtmässigen Werber ausgegangen werden.
Aus diesem Grund wird für diesen Abschnitt der Ausdruck Direktmarketing verwendet.
Direktmarketing ist eine Form des Marketing, bei dem der Kontakt zum Kunden direkt hergestellt wird. Für Direktmarketing gibt es Gesetze, die ihr einen rechtlichen Rahmen geben.
Missachtet das ausführende Marketingcenter diese Gesetze, kann die durch diese Marketingform versandte Werbung als Spam bezeichnet werden. Aus diesem Grund wird in diesem
Abschnitt geklärt, was rechtmäßiges Direktmarketing ist.
Der Gesetzgeber verwendet in seinen Texten einige Worte, die einer genaueren Definition
bedürfen. Um diese Informationen dem Leser nicht vorzuenthalten, werden hier die wichtigsten Begriffe kurz vorgestellt [Kar-2006, S. 8–22].
• Diensteanbieter [BMJ-2008b, § 2 Abs. 1]: Mit einem Diensteanbieter ist jede juristische oder natürlich Person gemeint, die eigene oder fremde Telemedien zur Nutzung
bereithält oder einen Zugang zu diesen ermöglicht.
• Personenbezogene Daten [BMJ-2009a, § 3 Abs. 1]: Mit personenbezogenen Daten werden Einzelangaben über die persönlichen oder sachlichen Verhältnisse einer
bestimmten oder bestimmbaren natürlichen Person bezeichnet.
3.5.2 Rechtmäßiges Direktmarketing
Der Unterschied zwischen Marketing und Spam ist in großem Maße von der Rechtmäßigkeit
abhängig. Ein betroffener Teilnehmer muss in der Regel der Nutzung seiner Daten zustimmen. Wann und in welcher Art und Form diese Zustimmung sein muss, ist von dem
48
3.5. Gesetzeslage
jeweiligen Land abhängig. Generell existieren zwei gegensätzliche Ansätze, um die Einwilligung eines Teilnehmers einzuholen:
• Opt-IN.
• Opt-OUT.
Das Opt-OUT-Verfahren wird hauptsächlich in Amerika eingesetzt. Dieses Verfahren
basiert auf einer nachträglichen Entfernung aus der Verteilerliste des Werbers. Das bedeutet,
dass die initiale Werbebotschaft rechtlich erlaubt ist. Erst wenn sich der Empfänger
der Botschaft beim Werber meldet und ihm mitteilt, dass er keine Werbung mehr erhalten
will, ist die Werbung verboten.
Dieses Prinzip hat im Kontext von Spam einen gravierenden Nachteil. Angenommen der
Spammer befindet sich nicht in Amerika, dann braucht er dass dort geltende Gesetz nicht
zu fürchten. Wenn sich ein Teilnehmer bei ihm meldet, weil er keine Werbung mehr erhalten
möchte, kann er dies als Bestätigung ansehen, dass die Adresse genutzt wird.
In der EU [EPR-2002, § 13 Abs. 1] und somit in Deutschland [BMJ-2008a, § 7 Abs. 2 Nr. 3]
wird allerdings das Opt-IN-Verfahren verwendet. Hier ist der Versand der Werbung erst
nach einer vorhergehenden Zusage des Empfängers erlaubt. Wenn sich der Empfänger
selbst in die Verteilerliste eingetragen hat, darf er beworben werden. Hierbei muss beim Versenden der Werbung immer eine gültige Identität des Absenders angeführt werden. Demnach
darf die Identität des Absenders weder verschleiert, verheimlicht oder unterschlagen werden
[EPR-2002, § 13 Abs. 4][BMJ-2008a, § 7 Abs. 2 Nr. 4].
Für bestehende Geschäftsbeziehungen existieren besondere Richtlinien. Im Rahmen bestimmter Umstände ist es demnach möglich zusätzliche Werbung zuzustellen. Dafür müssen
allerdings alle der folgenden Punkte erfüllt sein [EPR-2002, § 13 Abs. 2][BMJ-2008a, § 7
Abs. 3]:
• Dem Kunden wurde ein Produkt oder eine Dienstleistung verkauft.
• Im Zusammenhang mit diesem Verkauf wurde die Kontaktadresse erworben.
• Der Kunde muss die klare und deutliche Möglichkeit erhalten haben, gebührenfrei und
problemlos den Versand von Werbung abzulehnen.
• Es wird nur mit ähnlichen Produkten oder Dienstleistungen geworben.
Die Einwilligung muss freiwillig erteilt worden sein [BMJ-2009a, § 4a Abs. 1][BMJ-2009e,
§ 95 Abs. 1] und darf nicht an die Nutzbarkeit des Dienstes gekoppelt sein [BMJ-2008a, § 4
Abs. 6]. Anschließend muss dem Kunden jederzeit die Möglichkeit angeboten werden, sich
wieder abzumelden [BMJ-2008b, § 13 Abs. 4 Nr. 1][BMJ-2008b, § 13 Abs. 4 Nr. 1].
Im Streitfall muss der Versender der Werbung nachweisen können, dass eine Einwilligung
zum Erhalt von Werbung vorlag [LG-2008]. Dies zu beweisen ist nicht ganz einfach. Das die
49
betreffende Adresse in die Liste eingetragen ist beweist nicht, dass dies vom Besitzer der
entsprechenden Adresse kommt.
Aus diesem Grund empfiehlt sich für den Versender der Werbung der Einsatz des DoubleOpt-IN-Verfahrens [Kar-2006, S. 13]. Dieses Verfahren setzt sich aus den folgenden Schritten zusammen (vgl. Abb. 3.2, S. 50):
1. Der Diensteanbieter erhält eine Nachricht, dass die Teilnehmerin Alice in die Liste
eingetragen werden will.
2. Automatisch wird eine Nachricht an Alice gesendet, in der sie aufgefordert wird, die
Eintragung zu bestätigen.
3. Trifft die Bestätigung beim Diensteanbieter ein, kann er von einem ehrlichen Interesse
an der Werbung ausgehen.
Alice
Diensteanbieter
Registrierung
Nachfrage
Bestätigung
Abb. 3.2: Ablauf beim Double-Opt-IN.
3.5.3 Möglichkeiten der Strafbarkeit
Handelt ein Teilnehmer den beschriebenen Regelungen zuwider, kann gegen ihn rechtlich vorgegangen werden. Die Möglichkeiten ergeben sich in Abhängigkeit vom konkreten Spamopfer.
Eine Privatperson kann nur seine bürgerlichen Rechte geltend machen, da das Wettbewerbsrecht nicht für Privatpersonen gilt [BMJ-2008a, § 8 Abs. 3]. Somit steht ihm eine Klage auf
Unterlassung [BMJ-2009b, § 1004 Abs. 1] und Schadensersatz [BMJ-2009b, § 823 Abs. 1]
zu. Unternehmen haben dementsprechend zusätzlich die Möglichkeit, aufgrund des Wettbewerbsrechts auf Unterlassung [BMJ-2008a, § 8] und Schadensersatz [BMJ-2008a, § 9] zu
klagen.
Da sich Spam, nach der Deutung im Kontext dieser Arbeit, nicht nur auf Werbung beschränkt, ergeben sich zusätzliche Möglichkeiten. Diese Möglichkeiten hängen von der Art
des Spams ab und werden im Folgenden kurz vorgestellt:
• Phishing / Vishing: Verschafft sich der Spammer selbst oder für einen Dritten durch
Phishing-E-Mails oder Vishing-Anrufen einen Vermögensvorteil, ist dies rechtswidrig.
Bereits der Versuch dies zu unternehmen, ist strafbar [BMJ-2009d, §§ 263, 263a].
50
3.5. Gesetzeslage
• Pornografie: Das Verbreiten von pornografischen Materialien erfordert die Aufforderung des Empfängers, das im Falle von Spam nicht vorliegt [BMJ-2009d, § 184 Abs. 1
Nr. 6]. Des Weiteren kann der Spammer nicht sicher stellen, dass seine Mails nicht von
Minderjährigen eingesehen werden können [BMJ-2009d, § 184 Abs. 1 Nr. 5].
• Schadsoftware: Abhängig von der Art der Schadsoftware (z. B. Viren und Würmer),
kommen unterschiedliche Gesetzestexte zur Geltung. Deshalb wird im Folgenden einzeln auf die verschiedenen Ausprägungen von Schadsoftware eingegangen:
– Wird über die Schadsoftware der Inhalt von persönlichen Schriftstücken erspäht,
verletzt dies das Briefgeheimnis [BMJ-2009d, § 202].
– Verändert die Schadsoftware das Erscheinungsbild beim Opfer, wird dies als Sachbeschädigung oder Computersabotage gewertet. Analog zum Phishing / Vishing
ist hier bereits der Versuch dies zu tun strafbar [BMJ-2009d, §§ 303, 303b].
– Werden durch die Schadsoftware Daten gelöscht, unterdrückt oder unbrauchbar
gemacht, fällt dies unter Datenveränderung. Hier ist ebenfalls der Versuch bereits
strafbar [BMJ-2009d, § 303a].
– Durch den massenhaften Versand von Spam kann es zu Störungen bis hin zu
Zusammenbrüchen von Telekommunikationsanlagen kommen. Dieser Tatbestand
liegt vor, wenn der Spammer fahrlässig handelt [BMJ-2009d, § 317].
Um den Spammer belangen zu können, muss der Empfänger zunächst die Anschrift des
Versenders ermitteln. Ist dies nicht direkt möglich, ergibt sich die Möglichkeit, die Anschrift
beim Betreibers des Dienstes zu erfragen [BMJ-2009c, § 13a].
3.5.4 Regelungen für Internet Service Provider
Sofern der ISP Maßnahmen gegen Spam ergreift, muss er bestimmte Gesetzeslagen beachten.
Die Problematik ist insbesondere bei falschen Positiven der Fall. Falsche Positive sind
erwünschte Nachrichten, die nicht zugestellt werden, da sie für Spam gehalten werden.
Wird eine Nachricht auf Spam untersucht, wird zumindest bei E-Mails in der Regel der
Inhalt der Nachricht ermittelt. Daraus kann sich eine Verletzung diverser Gesetze ergeben.
Zunächst betrifft dies das Brief- [BMJ-2009d, § 202] und Post- und Fernmeldegeheimnis
[BMJ-2009d, § 206][BMJ-2009e, § 88]. Hier kann der ISP eventuell aufgrund des Ausspähens
von Daten belangt werden [BMJ-2009d, § 206]. Wird die Nachricht verändert (z. B. als
Spam markiert), ist dies eine Datenveränderung [BMJ-2009d, § 303a] und ein Eingriff in den
Datenschutz des betreffenden Teilnehmers [BMJ-2009a, § 4 Abs. 1].
Um derartige Probleme zu verhindern, ist es daher ratsam, im Voraus die Einwilligung
des Teilnehmers einzuholen. Im Idealfall kann der ISP die Einwilligung beim Vertragsabschluss einholen [BSI-2005, S. 28]. Hierbei muss der Betreiber jedoch das Kopplungsverbot
51
[BMJ-2008a, § 4 Abs. 6] beachten. Das heißt, der Zugang zu seinem Dienst darf nicht von
dieser Einwilligung abhängig sein.
Unproblematisch sollten Filtermaßnahmen sein, wenn sie dazu da sind, Schadsoftware abzuwehren. Denn der Betreiber hat die Pflicht, geeignete Maßnahmen zum Schutz seiner Systeme zu ergreifen [BMJ-2009e, § 109].
3.6 Zusammenfassung
Das neuartige Problem SPIT, lässt sich als das massenhafte Aussenden von unerwünschter
Werbung definieren. Um eine globalere Betrachtung dieses Phänomens bieten zu können, wird
im Rahmen dieser Arbeit zusätzlich das generelle massenhafte Senden von Nachrichten
als SPIT definiert.
Dass diese neue Form von Spam aufkommen wird, kann aufgrund bestehender Versuche
nicht mehr angezweifelt werden. Darüber hinaus hat sich gezeigt, dass es deutlich Kostengünstiger ist, als konventionelle Telefonwerbung. Mit steigender Zahl VoIP-Nutzer wird
demnach immer häufiger mit SPIT zu rechnen sein.
Normale Telefonwerbung wird aufgrund der Kosten eher selten international getätigt. Mit
VoIP kann der potenzielle Kunde Werbeanrufe in einer fremden Sprache und zu jeder Uhrzeit
erhalten. Dadurch wird SPIT deutlich störender werden als klassische Telefonwerbung es
heute ist.
Da sich E-Mail-Spam und SPIT im Kern ähneln, wird erwartet, dass viele Anti-E-MailSpammaßnahmen auf SPIT angewendet werden können. Da jedoch bei einem Anruf
bereits das Klingeln des Telefons störend sein kann, ist es bei SPIT nicht möglich Inhaltsfilter
zu Abwehr einzusetzen.
Trotz der vielen Gesetze, die Spam einschränken oder verbieten, können nur in wenigen
Fällen Gesetze zum Einsatz kommen. Meist müssen sich Opfer, Täter und der ISP im selben
Land oder innerhalb der EU befinden. Somit kann nichts gegen international arbeitende
Spammer unternommen werden. Selbst wenn es entsprechende Gesetze geben würde, können
die Spammer ihre Identität verschleiern, indem sie z. B. Botnets einsetzen.
Aus diesem Grund ist es wichtig, jetzt etwas gegen SPIT zu unternehmen. Wir hätten
heute weniger E-Mail-Spam, wenn schon vorher geeignete Gegenmaßnahmen existiert hätten
[RFC-5039, S. 3]. Wenn jetzt ein guter Schutz vor SPIT erarbeitet wird, werden Ausmaße
wie beim E-Mail-Spam möglicherweise verhindert.
52
Kapitel
4
Abwehrmaßnahmen
Nachdem das Problem beschrieben wurde, wird in diesem Kapitel auf die Abwehr von Spam
over Internet Telephony (SPIT) eingegangen. Da eine große Ähnlichkeit zum E-Mail-Spam
besteht, können bisherige Abwehrmaßnahmen übernommen werden.
In der Regel handelt es sich dabei um Ansätze, die für einen Einsatz im IMS konzipiert
sind. Wenige Maßnahmen können zusätzlich in einem Endgerät realisiert werden und andere
wirken vorbeugend. Zusammen mit der Überprüfung des Nachrichteninhalts, lassen sich die
Verfahren in vier Gruppen einteilen (vgl. Abb. 4.1, S. 53):
Abwehrmaßnahmen
Identität
Inhalt
Interaktiv
Präventiv
Intrusion Detection
Adressen verbergen
Whitelists
Payments at Risk
Adressen streuen
Graylists
Turingtests
Teilnehmerverhalten
Device Fingerprinting
Computational Puzzle
Reputationssysteme
Honeypots
Blacklists
Inhaltsfilter
Abb. 4.1: Kategorisierung der Abwehrmaßnahmen [Sis-2009, S. 300].
Als Erstes wird in diesem Kapitel auf identitätsbasierte Abwehrmaßnahmen eingegangen. Sie versuchen, SPIT aufgrund verschiedener Werte (z. B. dem Session Initiation Protocol Uniform Ressource Identifier (SIP URI)) als Spam zu identifizieren (vgl. Abschn. 4.1,
S. 54). Das Inhaltsfilter bei SPIT nicht eingesetzt werden können, wurde zwar bereits
erwähnt, wird in diesem Abschnitt jedoch nochmals ausgeführt (vgl. Abschn. 4.2, S. 59). Interaktive Abwehrmaßnahmen versuchen die Kosten für die Spamzustellung zu erhöhen.
Durch die gestiegenen Kosten soll der finanzielle Anreiz für Spammer geschmälert werden
(vgl. Abschn. 4.3, S. 60). Ergänzend zu allen anderen Maßnahmen sind die präventiven
53
Kapitel 4. Abwehrmaßnahmen
Ansätze zu sehen. Hier werden Möglichkeiten beschrieben, die eine Zustellung des SPIT
im Vorfeld erschweren. In der Regel bedeutet dies, zu verhindern, das der Spammer an eine
valide Adresse gelangt (vgl. Abschn. 4.4, S. 64).
Wird ein serverseitiges Verfahren gewählt, muss ein ISP immer beachten, dass vorher
eine Einwilligung des Teilnehmers vorliegen muss. Handelt er dieser Aufforderung zuwider,
macht er sich strafbar. Das gilt auch, wenn kein Zweifel besteht, dass es sich um Spam handelt.
4.1 Identität
Identitätsbasierte Abwehrmaßnahmen entscheiden je nach Maßnahme aufgrund unterschiedlicher Identitätswerte, ob der Anruf abgelehnt oder durchgestellt wird. Beispielsweise kann
ein bestimmter SIP URI als Quelle für SPIT bekannt oder der Nachrichtenaufbau untypisch
sein. Diese Art der Abwehrmaßnahmen verbraucht nur sehr wenig Rechenaufwand, da in
der Regel einfache Vergleiche durchgeführt werden. Außerdem kann hiermit das SPIT bereits
auf der Call Control und Sitzungssteuerungsebene abgewehrt werden.
4.1.1 Blacklists
Der Einsatz von Listen [RFC-5039, S. 9–10] zur Abwehr von Spam gehört zu den ältesten
und bekanntesten Ansätzen. Die Funktionsweise ist simpel, abhängig vom Eintrag in einer
Liste wird eine Nachricht weitergeleitet oder nicht.
Die Funktionsweise einer Blacklist kann sehr anschaulich mit einem Casino verglichen
werden. Wenn ein Gast in einem Casino oft unangenehm auffällt, bekommt er Hausverbot.
Versucht er daraufhin erneut in das Casino zu gehen, wird er nicht mehr hineingelassen, weil
sein Name auf einer Blacklist steht.
Im konkreten Fall der Spamabwehr bedeutet dies, dass die Quelle einer empfangenen
Spamnachricht auf die Blacklist gesetzt wird. Eine E-Mail von einer gelisteten Adresse oder
aus einer gelisteten Domain wird anschließend nicht mehr in den Posteingang geleitet. Dafür kommen prinzipiell zwei Möglichkeiten in Betracht. Es gibt lokale Blacklists,
sie werden auf dem Endgerät des Teilnehers hinterlegt. Welcher Absender auf dieser Liste
steht, entscheidet der jeweilige Nutzer. Globale Blacklists werden auf einem Internetserver
zur Verfügung gestellt. Sie sind immer aktuell gehalten und können von der Filtersoftware
abonniert werden.
Die Auswahl beim Blacklisting findet im Voraus statt, womit das Klingeln des Telefons
gut verhindert werden kann. Im Falle von erfolgreich erkanntem Spam bedeutet dies keine
Störung für den Teilnehmer. Außerdem benötigt die Spambewertung nur sehr wenig Rechenaufwand, da nur ein Vergleich stattfindet.
54
4.1. Identität
Durch den Einsatz von gobalen Listen ist dieses Verfahren mit wenig Aufwand vom Teilnehmer einsetzbar. Die lokalen Listen können leicht nach den persönlichen Neigungen der
Kunden eingestellt werden.
Der Nachteil ist, dass der Schutz durch eine Blacklist einsetzt, nachdem Spam vom
angegebenen Teilnehmer entdeckt wird. Insbesondere bei einer lokalen Liste bedeutet
dies, dass kein 100%iger Spamschutz gewährleistet werden kann. Da es fraglich ist, ob ein
zweites mal Spam vom selben Absender an den jeweiligen Teilnehmer gesendet wird, kann
selbst dieser Eintrag zwecklos werden.
Da serverseitige Blacklists durch Direct-IP-SPIT umgangen werden, kann eine Blacklist
nur auf der Clientseite greifen. Durch das Auslassen der Proxy ist der Spammer nicht mehr
verpflichtet einen gültigen SIP URI anzugeben. Da er in der Lage ist jeden beliebigen Absender einzutragen, kann er nicht durch die Blacklist abgewehrt werden.
Ohne Direct-IP-SPIT lässt sich Blacklisting in gleicher Weise leicht umgehen. Bemerkt
ein Spammer, dass seine E-Mails durch Blacklists abgewehrt werden, legt er sich eine neue
Adresse zu. Da diese Adresse neu und somit für Spam nicht bekannt ist, kann er erneut
Spam versenden. Diese Strategie erfordert jedoch viel Aufwand, weshalb sich der Einsatz
einer Blacklist trotzdem lohnen kann.
4.1.2 Whitelists
Über eine Whitelist wird definiert, von welchem Absender Nachrichten entgegengenommen
werden. Eine ähnliche Liste wie die Whitelist kommt häufig bei speziellen Anlässen zum
Einsatz. Angenommen, ein normaler Bürger versucht auf die Geburtstagsfeier von einem
Prominenten zu gehen. Dann wird er am Eingang nicht mehr weiterkommen, da sein Name
nicht auf der Gästeliste oder Whitelist steht.
Anders als bei der Blacklist, muss der Vermerk in einer Whitelist eingetragen werden,
bevor die Nachricht ankommt. Nur wenn der Teilnehmer auf der Liste steht, wird seine
Nachricht zugestellt.
Zusätzlich zur eigenen Whitelists ist es möglich, die Whitelists ausgewählter Teilnehmer
über sogenannte Vertrauensnetze [TNG-2006, S. 11] heranzuziehen. Insbesondere eignen
sich dafür Teilnehmer, die auf der eigenen Whitelist gelistet sind. Somit werden Nachrichten
von Teilnehmern akzeptiert, denen die eigenen akzeptierten Teilnehmer vertrauen.
Wie das Blacklisting findet das Whitelisting im Voraus statt und erspart somit dem Teilnehmer das klingelnde Telefon. Gleiches gilt für den Rechenaufwand. Da nur ein Adressvergleich notwendig ist, benötigt dieses Verfahren kaum Rechenleistung.
Da der Angreifer keinerlei Kenntnisse über die gelisteten Adressen hat, kann er die Liste mit
vorgetäuschten SIP URI nicht einfach umgehen. Die einzige Lösung für den Spammer bleibt
ein Brute-Force-Angriff , indem er alle möglichen SIP URI ausprobiert. Das ist jedoch sehr
unwahrscheinlich, da für diesen hohen Aufwand zu wenig Spam zugestellt werden kann.
55
Eine Whitelist ist leider etwas zu effektiv. Da der Absender bei Eingang der Nachricht
auf der Liste stehen muss, ergibt sich die Frage nach der initialen Kontaktaufnahme. Beispielsweise kennt ein Bewerber nicht den SIP URI des Personalbeauftragten. Somit kann
dessen Adresse nicht auf der Liste stehen und keine Nachricht von ihm eingehen. Besonders
kritisch sind in diesem Kontext anonyme Anrufe. Entweder können sie gar nicht durchgestellt
werden oder sie bedürfen einer Sonderregelung, die wieder von Spammern ausgenutzt werden
kann. Diese als Einführungsproblem bekannte Schwierigkeit kann durch den Einsatz einer
interaktiven Abwehrmaßnahme gelöst werden. Hier wird vorgeschlagen, solche Teilnehmer
einem Turingtest (vgl. Abschn. 4.3.3, S. 62) zu unterziehen [RFC-5039, S. 10].
Werden die Whitelists von anderen Teilnehmern genutzt, kann ein Angreifer die Whitelists
umgehen [Han-2006, S. 3]. Dafür muss er sich einen gültigen Account beim Betreiber zulegen
und den Zielteilnehmer auf seine eigene Whitelist setzen. Somit kann er die Whitelist dieses
Teilnehmers nutzen, wodurch er die Informationen über diese Liste erhält. Durch die somit
errungenen Adressen kann er Direct-IP-SPIT zustellen.
Der Einsatz von verteilten Whitelists wird jedoch vom europäischen Recht eingeschränkt. Für die Weitergabe der gelisteten Adressen muss die Erlaubnis der betreffenden
Personen vorliegen. Ist dies nicht der Fall, kann somit das Verfahren der verteilten Whitelists
nur eingeschränkt eingesetzt werden.
4.1.3 Graylists
Weniger anschaulich ist die Funktionsweise einer Graylist. Bei einer Graylist wird jeder Kontaktversuch beim ersten mal geblockt. Meldet sich dieser Teilnehmer innerhalb einer festgelegten Zeit erneut, wird unterstellt, dass ein ernsthafter Kontaktversuch vorliegt. Die Adresse
des Teilnehmers wird in die Liste aufgenommen und er kann in Zukunft ohne dieses Verfahren
Kontakt aufnehmen.
Anders als Black- oder Whitelists sind Graylists weniger streng in ihrer Durchführung. Dies
hat Vorteile. Sie ermöglichen anders als Whitelists unbekannten Teilnehmern, ein Telefonat
aufzubauen. Trotzdem sind sie in der Lage Spamversender zurückzuweisen.
Eine Graylist kann durch eine geringe Anpassung der Spambots oder der Anweisungen in
den Callcentern leicht umgangen werden. Wird der Spamversuch beim ersten Anlauf abgewiesen, müssen die Spambots oder Callcenter-Mitarbeiter einen zweiten Versuch initiieren.
Eine Variante der Graylist ist das Consent-Based Communications [RFC-5039, S. 10–
12]. Hier wird der Anruf eines unbekannten Teilnehmers immer abgewiesen. Der Anrufversuch
wird jedoch in der Graylist notiert. Anschließend muss der angerufene Teilnehmer manuell
entscheiden, ob er in Zukunft Anrufe von diesem Teilnehmer erhalten möchte oder nicht. Bis
zu einer manuellen positiven Entscheidung des angerufenen Teilnehmers wird jeder weitere
Kontaktversuch des Anrufers unterbunden.
56
4.1. Identität
4.1.4 Device Fingerprinting
Unter der Annahme, dass die VoIP-Software von Spammern eine andere Implementierung aufweist, wurde das Konzept des Device Fingerprintings [Yan-2006] entwickelt. Die
Vermutung wird darin begründet, dass Spammer mehr Wert auf hohen Durchsatz legen und
deshalb den Programmcode ihrer Spamsoftware (in diesem Fall des UA) klein halten.
Dieses Verfahren versucht, die Spamsoftware zu erkennen. Dafür wird im ersten Verfahren
der Aufbau des INVITE-Request untersucht. Im zweiten Ansatz wird das Verhalten der
VoIP-Software getestet.
Um die Anwendbarkeit dieses Verfahrens zu untersuchen, wurde das Verhalten von 20
verschiedenen Programmen verglichen. Hierbei wurde herausgefunden, dass sich alle 20 Programme unterschiedlich verhalten. Um dies herauszufinden, waren nur wenige Tests notwendig.
Beim Passive Fingerprinting [Yan-2006, S. 5] wird der Aufbau eines empfangenen
INVITE-Request untersucht. Angenommen der Fingerprinter-Dienst hat Kenntnis über den
Aufbau des INVITE-Request-Header aller UA. Dann findet die Klassifikation anhand der
Reihenfolge der Header-Felder statt. Stimmt die Reihenfolge mit der einer bekannten SIPSoftware überein, wird die Nachricht weitergeleitet. Andernfalls wird sie als SPIT deklariert.
Beim Active Fingerprinting [Yan-2006, S. 6–10] wird die kontaktierende VoIP-Software
auf ihr Reaktionsverhalten untersucht. Wie beim Passive Fingerprinting benötigt dafür der
Fingerprinter-Dienst Informationen über das Verhalten bekannter VoIP-Lösungen. Um die
Software auf ihr Antwortverhalten zu testen, werden ihr mehrere OPTIONS-Request Variationen zugesandt. Für jede Nachricht wird die Antwort mit dem Verhalten aller bekannten
VoIP-Lösungen verglichen. Die Requests können die folgenden Eigenschaften haben:
• RFC-Kompatibel.
• Falsche SIP-Version (z. B. SIP/99.9).
• Ungültige Via-Adresse (z. B. via="localhost").
• Falsche Content-Length (z. B. Länge angegeben, aber kein Body enthalten).
• Ungültige CSec (z. B. ohne den Eintrag OPTIONS).
• Fehlende Call-ID (kein Call-ID-Feld).
• Fehler im Transportprotokoll (z. B. UDP verwendet, aber TCP angegeben).
Beide Verfahren überprüfen den Anruf während er eingeht. Somit ist eine Entscheidung
möglich, bevor das Telefon klingelt und der Teilnehmer gestört wird. Das Passive Fingerprinting lässt sich mit geringem Wissen sehr schnell durchführen. Der Aufwand beim Active
Fingerprinting ist durch den zusätzlichen Nachrichtenaustausch zwar etwas höher, aber nach
wie vor schnell zu bewältigen.
57
Wie die Autoren selbst erwähnen [Yan-2006, S. 5], ist das Passive Device Fingerprinting
leicht zu umgehen. Der Angreifer muss den Aufbau seiner Nachrichten nur entsprechend
gestalten, wie es bei einer bekannten Software der Fall ist. Diese Schwäche betrifft aber
ebenfalls das Active Fingerprinting [ElK-2008, S. 45]. Die Spamsoftware muss sich nur wie
eine bekannte VoIP-Lösung verhalten, um nicht entdeckt zu werden.
Besonders problematisch an diesem Verfahren ist, dass es nur anwendbar ist, solange es
begrenzt viele UAs gibt [ElK-2008, S. 45–46]. Bereits eine aktuellere Software-Version hat
unter anderem eine Änderung der Reihenfolge in den Header-Feldern sowie des Antwortverhaltens zur Folge. Da die Vorgängerversionen trotz alledem weiterhin in Betrieb bleiben, erhöht sich somit der Zeit die Anzahl möglicher Kombinationen. Angesichts der großen
Vielfalt an E-Mail-Client-Lösungen ist zu erwarten, dass die Anzahl der SIP-Lösungen in
Zukunft zunehmen wird. Mit der Zeit gibt es somit mehr gültige als ungültige Kombinationsmöglichkeiten, bis es theoretisch nur noch valide Kombinationen gibt.
Das Fingerprinting-Verfahren kann nur serverseitig zum Einsatz kommen, da ein Endkunde
in der Regel nicht aktuell über das benötigte Wissen über valide Clients verfügt.
4.1.5 Reputationssysteme
Wenn eine Nachricht von einem unbekannten Teilnehmer ankommt, ist in der Regel nicht
bekannt, ob es sich um einen normalen Anrufer oder Spam handelt. Um dem Angerufenen eine Entscheidungsgrundlage zu bieten, wurde das Reputationssystem-Verfahren
[Nic-2007][RFC-5039, S. 12–13] entwickelt. Dieses Verfahren kann dem Teilnehmer in Form
einer Bewertung eine Information über den Anrufer auf dem Display angeben.
Die Bewertung der Teilnehmer ergibt sich aus dem Feedback anderer Teilnehmer, die
bereits mit dem Anrufer telefoniert haben. Beispielsweise kann dafür eine Taste vorgesehen
werden, über die der Teilnehmer während oder nach dem Telefonat seine Bewertung abgeben
kann. Die Bewertung kann auf Basis zweier Ansätze geschehen.
Bei einem negativen Feedback werden störende Teilnehmer mit schlechten Wertungen
versehen. Somit weiß der angerufene Teilnehmer, ab einem gewissen Wert, das der anrufende Teilnehmer negativ aufgefallen ist. Eine schlechte Gesamtwertung darf nie auf nur einer
schlechten Wertung basieren, sondern die Meinung mehrerer Teilnehmer wiederspiegeln.
Alternativ dazu kann ein positives Feedback gegeben werden. Hier wird über die Wertung ausgedrückt, dass der Anruf angenommen werden kann, da er bisher nicht negativ
aufgefallen ist. Dieses Verfahren kommt hauptsächlich beim Instant Messaging (IM) zum
Einsatz.
Eine Bewertung über einen Teilnehmer bietet anderen Teilnehmern ein subjektives Kriterium, welchen Anrufern vertraut werden kann. Da der Kunde selbst eine Bewertung abgeben kann, ist der Mechanismus für ihn transparent.
58
4.2. Inhalt
Beim IM kommt durch die Freundeslisten eine Whitelist zum Einsatz. Dieser Umstand
kann als automatische Bewertung integriert werden. Teilnehmer auf der Freundesliste sind
in der Regel solche, denen ein Teilnehmer vertraut. Ähnlich wie bei Whitelists können die
Freundeslisten der Freunde mitbewertet werden. Dadurch kann eine automatische Bewertung
erzielt werden, die den sozialen Netzwerken entspricht.
Reputationssysteme mit negativen Bewertungen haben dieselben Schwächen wie Blacklists.
Effektiv bedeutet eine sehr negative Bewertung dasselbe wie auf einer Blacklist zu stehen.
Weiterhin muss ein Teilnehmer sehr gestört werden, bis er die Bewertungstaste nutzt. Um
das Konzept zu unterwandern haben sich sogenannte Reputations Mafias [RFC-5039, S. 13]
gebildet. Dort sammeln sich viele Teilnehmer, um in der Masse einen anderen Teilnehmer
zu bewerten. Diese versuchen entweder eine Bewertung zu maximieren (Ballot Stuffing) oder
zu minimieren (Bad Mouthing) [Del-2000, S. 2]. Das Konzept der Bewertung wird somit
unwirksam.
Basiert die Bewertung auf einem positivem Feedback, ergibt sich ein Problem mit neuen
Teilnehmern. Da diese bisher nicht bewertet sind, haben sie keine gute Wertung. Um dieses Problem zu umgehen, kann eine Art Schutzmechanismus für neue Mitglieder eingeführt
werden. Das bewirket, dass neue Teilnehmer als solche gekennzeichnet sind und somit für
andere Teilnehmer die fehlende gute Bewertung transparent wird. Diesen Umstand können
Spammer jedoch für sich ausnutzen.
Reputationssysteme können jedoch nicht als SPIT-Abwehrmaßnahme angesehen werden,
da eine Bewertung erst einsehbar wird, sobald das Telefon klingelt. Es kann trotzdem als gute
Ergänzung genutzt werden, um mit Anrufern umzugehen, die durch andere Maßnahmen nicht
klassifiziert werden konnten.
4.2 Inhalt
Viele der im E-Mail-Spam-Bereich eingesetzten Ansätze basieren darauf, Spam am Inhalt
einer Nachricht zu erkennen. Manche Autoren sind sogar der Ansicht, dass das Filtern des
Nachrichteninhalts bis heute der einzige gut funktionierende Schutzmechanismus ist
[Ble-2005, S. 478]. Der Inhalt der Nachricht wird auf verschiedene Eigenschaften untersucht.
Anhand einer Klassifikation wird anschließend entschieden, ob die Nachricht normal zugestellt
wird oder andere Maßnahmen getroffen werden.
Leider ist dieses Verfahren im SPIT-Bereich vollkommen nutzlos. Für die Untersuchung von SPIT kommen zwei Szenarien in Frage [RFC-5039, S. 8].
1. Untersuchung des laufenden Telefonats: Das Untersuchen des laufenden Telefonats auf SPIT kann erst stattfinden, wenn das Telefonat durchgestellt wurde. SPIT
muss jedoch erkannt werden, bevor der Teilnehmer gestört wird.
59
2. Zwischenspeichern der Nachricht: Bevor ein Teilnehmer eine Nachricht erhält,
kann diese zwischengespeichert werden. Dies kann beispielsweise in Form eines Anrufbeantworters realisiert werden. Die gespeicherte Nachricht kann dann untersucht
und anschließend weitergeleitet werden. Dieser Ansatz ist für normale Gespräche nicht
umsetzbar, da hiermit nur eine unidirektionale Kommunikation möglich ist.
Selbst wenn einer der beiden Ansätze verfolgt wird, ist die Erfolgschance eher gering. Der
Spammer muss nur genügend Hintergrundgeräusche, mit Akzent oder schlechtem Deutsch
senden und die automatische Untersuchung gestaltet sich nach heutigen Maßstäben als zu
schwierig.
4.3 Interaktiv
Die große Verbreitung des Spams liegt an den geringen Kosten für den Versand. Mit interaktiven SPIT-Abwehrmaßnahmen wird erreicht, dass diese Kosten steigen. Auf diese Weise
wird SPIT eingedämmt [Sis-2009, S. 307].
Dies wird erreicht, indem der Spammer gezwungen wird, rechenintensive Aufgaben zu lösen
oder Geld zu bezahlen. Diese können idealerweise den identitätsbasierten Abwehrmaßnahmen
nachgeschaltet werden, um SPIT zu erkennen, der durch diese Verfahren nicht erkannt wird.
4.3.1 Intrusion Detection
Ein Intrusion Detection Mechanism [ElB-2006] ist ein System, mit dem das Teilnehmerverhalten innerhalb eines Netzwerks überwacht werden kann. Mit diesem System können
verschiedene Angriffe erkannt werden. Beispielsweise äußert sich ein Scan-Angriff durch
eine große Anzahl angesprochener Ziele. Um einen Angriff zu klassifizieren, werden gewisse
Eigenschaften definiert und in eine CPT eingetragen.
In einer CPT sind neben den Eigenschaften eines normalen Anrufs, die Eigenschaften
verschiedener Angriffe eingetragen. Die Autoren definieren sieben Eigenschaften zur Charakterisierung der Angriffe.
• Anzahl der Requests.
• Anzahl der 4xx- bis 6xx-Responses.
• Anzahl unterschiedlicher Ziele.
• Maximale Anzahl an Dialogen im Wartestatus.
• Anzahl offener Ports.
• Die Verteilung der Request-Methoden.
60
4.3. Interaktiv
• Die Verteilung der Response-Codes.
Beispielsweise wird bei der CPT für die Verteilung der Request-Methoden die prozentuale Verteilung ausgewählter Request-Methoden eingetragen (vgl. Tab. 4.1, S. 61). Hier ist
bei SPIT besonders auffällig, dass im Verhältnis zur Gesamtheit aller Nachrichten, keine
REGISTER- und CANCEL-Requests vorkommen.
Request
INV
REG
ACK
CAN
BYE
Normaler Anruf
0,30
0,10
0,30
0,10
0,10
Scan-Angriff
0,40
0,05
0,40
0,10
0,05
SPIT
0,40
0,00
0,40
0,00
0,20
Denial of Service (DoS)
0,90
0,10
0,00
0,00
0,00
Passwort Cracking
0,10
0,40
0,40
0,00
0,00
Firewall Traversion
0,40
0,00
0,40
0,00
0,20
Tab. 4.1: CPT für die Request-Methoden-Verteilung [ElB-2006, S. 5].
Mit einer guten Eigenschaftsdefinition ließe sich SPIT effektiv serverseitig abwehren. Außerdem ist dieses Verfahren nicht nur auf die SPIT-Bekämpfung beschränkt, sondern kann
vielmehr generell für die Sicherheit eingesetzt werden.
Die große Schwierigkeit besteht in der Erstellung der CPT. Da für SPIT noch keine empirischen Werte vorliegen, existieren noch keine realen Verhaltensmuster. Die von den Autoren vorgeschlagenen Werte (vgl. Tab. 4.1, S. 61) erscheinen zwar schlüssig, entspringen
jedoch keiner empierischen Untersuchung. Insbesondere muss es eine Möglichkeit geben, legale Call-Center vor einer negativen Bewertung zu schützen. Andererseits muss
eine Möglichkeit existieren, sogenannte schwarze Schafe“ unter den legalen Call-Centern zu
”
erkennen.
Desweiteren kann der Angreifer das Verhalten seiner Bots anpassen [ElK-2008, S. 52]. Im
obigen Beispiel (vgl. Tab. 4.1, S. 61) bedeutet das, dass die Bots sich gelegentlich neu regestrieren und manche Anrufversuche durch einen CANCEL-Request abbrechen. Der Durchsatz
des Spammers wird sich dadurch zwar senken, ist aber schwerer zu entdecken.
4.3.2 Payments at Risk
Payments at Risk [Aba-2003] ist ein Ansatz aus der E-Mail-Spam-Bekämpfung. Dieser Ansatz
kann auf Voice over IP (VoIP) übertragen werden [RFC-5039, S. 17–18]. Möchte beispielsweise
Alice Bob anrufen, überweist sie einen kleinen Geldbetrag auf sein Konto. Bestätigt Bob
den Anruf im Nachhinein als normal, erhält Alice ihr Geld zurück. Markiert Bob den Anruf
als SPIT, behält er den Betrag.
61
Payment at Risk kann der Lösung des Einführungsproblems einer Whitelist dienen.
Ein genereller Einsatz zieht zu viele Transaktionen nach sich und bringt keinen Mehrwert. Ist
ein Teilnehmer auf der Whitelist, gibt es in der Regel keinen Grund mehr, ihm zu misstrauen.
Zur Durchführung des Payment at Risk ist seitens des Anrufers kein Aufwand nötig. Einzig
der angerufene Teilnehmer muss anschließend eine Bewertung abgeben.
Ob der Anruf SPIT enthält, kann erst festgestellt werden, nachdem das Telefonat begonnen
wird. Somit kann hiermit der initiale SPIT nicht verhindert werden.
Anders als die bisherigen Ansätze ist dieses Verfahren besonders kritisch zu betrachten,
wenn der SPIT von einem sogenannten Zombie“-Rechner gesendet wird. Mit Payment at
”
Risk muss der Eigentümer des Rechners für die Zahlung aufkommen.
4.3.3 Turingtests
Den Turingtest hat Alan M. Turing [Tur-1950] im Jahr 1950 entwickelt. Mit ihm sollte die
Frage geklärt werden, ob es möglich ist, Maschinen und Menschen über ein Frage-AntwortSpiel zu unterscheiden. Beim Test muss ein Fragesteller anhand der Antworten herausfinden,
ob eine Maschine oder ein Mensch antwortet. Kann er beide nicht unterscheiden, ist der Test
bestanden.
Abb. 4.2: Ein Beispiel für ein bildbasiertes CAPTCHA.
Um das Einführungsproblem der Whitelists zu lösen wurde der Einsatz von Completely Automated Public Turing Tests to Tell Computers and Humans Apart (CAPTCHAs)
[Ahn-2003] (vgl. Abb. 4.2, S. 62) vorgeschlagen [Tsc-2008]. Bei einem CAPTCHA wird dem
aufrufenden Teilnehmer eine Aufgabe gestellt, die er lösen muss. Diese Aufgabe muss derart konzipiert sein, dass sie leicht vom Menschen aber schwer vom Computer lösbar ist.
Bei VoIP kommen akustische CAPTCHAs zum Einsatz. Beispielsweise muss der Teilnehmer
die genannten Ziffern in sein Telefon eingeben. Um eine automatische Spracherkennung zu
verhindern, werden Störgeräusche oder Musik eingespielt.
Es gilt als sehr vielversprechender Ansatz, Probleme aus der Künstlichen Intelligenz (KI)
auf Probleme der Internet Protocol Security (IPsec) anzuwenden. Schließlich ist es unmöglich,
dass Bots Probleme lösen, die bisher in der KI ungelöst sind. Hätte der Spammer doch die
Fähigkeiten, solche Bots zu programmieren, wäre er nicht mehr auf das Geld durch Spam
angewiesen.
Der Einsatz von CAPTCHAs schützt jedoch nur vor Bots. Wird der SPIT über ein
Call-Center vertrieben, ist dieser Ansatz wirkungslos.
62
4.3. Interaktiv
Dienst
Nutzer
Spammer
Starten der Malware
Zugriff auf den Dienst
CAPTCHA
CAPTCHA
Lösung
Lösung
Zugang erteilt
Abb. 4.3: Umgehung eines CAPTCHAs.
Von Trend Micro wurde eine CAPTCHA-Relaytechnik entdeckt [Ord-2007]. Für die
Lösung der CAPTCHAs wurde Malware verteilt. Diese Malware beinhaltet ein Spiel. Der
Nutzer musste in diesem Spiel CAPTCHAs lösen. Für jeden erfolgreich beantworteten CAPTCHA kam der Spieler eine Stufe weiter. Der Trick war, dass dem Nutzer CAPTCHAs von
echten Internetseiten vorgelegt werden. Seine Lösung wird anschließend zum Umgehen des
CAPTCHAs genutzt (vgl. Abb. 4.3, S. 63).
Diese Anwendung ließe sich leicht auf ein VoIP-Szenario übertragen. Angenommen der
Angreifer hat eine gut genutzte kostenpflichtige Hotline. Dann kann er dort die akustischen
CAPTCHAs wiedergeben und die dortigen Kunden lösen die Aufgaben.
4.3.4 Computational Puzzles
Für die Abwehr von SPIT wird der Einsatz von sogenannten computational Puzzles vorgeschlagen [RFC-5039, S. 17]. Hierbei wird dem UAC eine Aufgabe gesendet, die dieser beantworten muss und an den UAS oder Proxy zurücksendet. Diese Aufgabe ist derart konzipiert,
dass sie von keinem Menschen gelöst werden kann. Zusätzlich muss es aufwendig genug
sein, um den Durchsatz des Spammers zu senkt und somit seine Kosten zu steigern.
Bei diesem Verfahren handelt es sich jedoch nicht um eine SPIT-Abwehrmaßnahme.
Selbst wenn der Anruf von einem Spammer kommt, wird er durchgestellt. Deshalb werden
Computational Puzzles in dieser Arbeit nicht weiter betrachtet.
4.3.5 Honeypots
Spam funktionert, weil die Kosten pro durchgesetzter Nachricht sehr gering sind. Mit Hilfe von Honeypots wird versucht, diesen Durchsatz zu senken. Wenn die Spammer weniger
durchsetzen, lohnt es sich eventuell ihn nicht mehr.
Zusätzlich ist es mit Honeypots möglich herauszufinden, woher das Spam stammt. Diese
Informationen können anschließend in einer Blacklist vermerkt werden. Befindet sich der
63
Spammer in einem Land mit gültigem Anti-Spam-Gesetz kann er rechtlich zur Verantwortung
gezogen werden.
Um diese Funktionen zu realisieren, werden viele solcher Honeypot-Server im Netz verteilt.
Sie bearbeiten eingehende Requests möglichst langsam. Dadurch werden die Ressourcen der Spammer gebunden und der Durchsatz sinkt. Jede Verbindung wird protokolliert,
sodass anschließend nach Spam-Quellen für die Blacklists gesucht werden kann.
Es bleibt die Frage zu klären, wie ein Spammer in einen Honeypot geleitet werden kann. Die
Grundidee des Honeypot-Verfahrens ist analog zum Prinzip vom Bären und dem Honigtopf.
Der Bär (Spammer) sucht, anders als die anderen Tiere, gezielt nach Honig (Adressen). Aus
diesem Grund werden die Adressen der Honeypots großflächig im Internet verteilt. Um zu
verhindern, dass normale Teilnehmer diese Adressen nutzen, werden sie im Browser nicht
dargestellt. Nur die auf HTML-Code-Ebene arbeitenden Harvester können sie erreichen.
4.4 Präventiv
Präventive Maßnahmen dienen eigentlich nicht der Abwehr, sondern der Vorbeuge. Sie verhindern im Voraus, dass SPIT aufkommt. Dies wird erreicht, indem das Sammeln oder
Validieren der URI erschwert wird.
4.4.1 Adressen verbergen
Da SIP URI dieselbe Syntax haben wie eine E-Mail-Adresse, können die Bots diese ohne
große Modifikationen zusätzlich sammeln. Bisher ist unklar, ob Bots dies nicht schon längst
tun. Gleiches gilt für das Sammeln von Telefonnummern.
Dies wirkt zunächst nachteilig. Eine gemeinsame Syntax ermöglicht jedoch auch die
Nutzung der Vorteile. SIP URI können dadurch auf die gleiche Weise vor Harvestern versteckt
werden, wie E-Mail-Adressen. Es ist zu erwarten, dass auch der Erfolg derselbe ist.
Es ist wichtig, dass der SIP URI nach wie vor für den Menschen gut leserlich bleibt.
Nur Bots dürfen sie nicht lesen können. Internetseiten werden von den Harvestern auf der
Ebene der Hypertext Markup Language (HTML) [W3C-1999][W3C-2001] durchsucht. Die
Schreibweise eines Textes in HTML ist aber nicht identisch mit dem, was der Teilnehmer
sieht.
Die Adresse kann im HTML-Code in Form von Unicode-Zeichen hinterlegt werden.
Da das @-Symbol für die Harvester das wichtigste Merkmal ist, muss zumindest dieses als
@ [Dix-2008, S. 7][CDT-2003, S. 2] codiert werden. Eine Modifikation der Harvester
dahingehend, dass sie Unicode-Zeichen übersetzen, ist jedoch kein großer Aufwand.
64
4.4. Präventiv
Schreibweise
Zu den beliebtesten Verfahren, eine Adresse für einen Bot unlesbar zu machen, zählt die
Änderung der Schreibweise. Da SIP URI dieselbe Syntax wie E-Mail-Adressen haben, kann
davon ausgegangen werden, dass derselbe Nutzen erzielt wird [RFC-5039, S. 14]. Nehmen
wir an, der zu sichernde URI lautet sip:[email protected]. Man kann diese Adresse z. B. wie
folgt umschreiben:
• sip:bob[at]biloxi.com.
• sip[doppelpunkt]bob[at]biloxi.com.
• s i p : b o b @ b i l o x i . c o m.
Die Änderung der Schreibweise bewirkt einen Schutz vor dem automatischen Finden durch
Bots. Ein SIP URI kann an zwei Merkmalen erkannt werden.
1. Das sip:-Präfix.
2. Dem @-Zeichen.
Diese Suchweise muss gestört werden. Bei der ersten Schreibweise wird nur das @-Zeichen
durch die Zeichenkette [at]“ ersetzt. Dieses sehr verbreitete Vorgehen verhindert jedoch
”
nicht, dass der Bot diese Adresse sammelt, da das Präfix vorhanden bleibt. Der SIP URI
ist zwar durch die Ersetzung des @-Zeichens ungültig, dieser Fehler kann jedoch durch den
Einsatz von Grammatiken korrigiert werden.
Eine Erweiterung der ersten Schreibweise ergibt sich aus der Entfernung des Präfixes.
Analog zum @-Zeichen kann dies wie im zweiten Fall durch die Zeichenkette [doppelpunkt]“
”
geschehen. Dieses Verfahren bleibt jedoch vor regulären Ausdrücken ungeschützt.
Um den SIP URI vor regulären Ausdrücken zu schützen, empfiehlt es sich die Bestandteile
des SIP URI mit ertkeerzeichen separiert zu schreiben. Ein Bot kann die Leerzeichen entfernen
und das @-Zeichen sowie das Präfix umwandeln. Da er jedoch nicht weiß, wo der URI beginnt
und aufhört, ist das nicht praktikabel. Wenn nur ein Buchstabe zu viel oder zu wenig in die
Zeichenkette eingefügt wird, ist sie ungültig.
Problematisch ist bei allen bisherigen Schreibweisen, dass sie nicht für blinde Teilnehmer
geeignet sind. Da die Barrierefreiheit des Internets nicht reduziert werden darf, können die
genannten Schreibweisen nicht zur Anwendung kommen. Selbst ohne die Berücksichtigung
von blinden Teilnehmern ist es Möglich, dass manche Internetbenutzer die Ersetzung der
Sonderzeichen nicht verstehen. Aus diesem Grund sind in der letzten Schreibweise die Sonderzeichen nicht ersetzt. Dafür sind alle Zeichen durch Leerzeichen getrennt. Somit bleiben
sie für jeden Menschen gut lesbar und aufgrund der oben genannten Problematik für Bots
nicht erkennbar.
65
JavaScript
Für dieses Verfahren wird die Tatsache genutzt, dass Bots in der Regel nur auf der Textebene arbeiten. Die Konsequenz daraus ist, dass dieses Verfahren nicht darin besteht, die
Adresse im Text zu verbergen. Mit der Unterstützung von JavaScript bietet HTML eine
solche Möglichkeit.
Die Adresse wird erst durch die Ausführung eines JavaScript-Skripts [Wes-2007] zusammengesetzt (vgl. Notation 4.1, S. 66). Der größte Vorteil an diesem Verfahren ist, dass die
hierdurch erzeugten Adressen verlinkt werden können. Selbst wenn ein Bot den JavaScriptCode liesst, kann er die Adresse darin nicht finden.
< script language = " JavaScript " type = " text / javascript " >
var username = " bob " ;
var hostname = " biloxi . com " ;
documte . write ( " <a href = " + " mail " + " to : " + username + " @ " +
hostname + " >" + username + " @ " hostname + " <\/a > " ) ;
</ script >
Notation 4.1: Adresse mit JavaScript verbergen.
Der Einsatz von JavaScript zur Verbergung der Adresse hat jedoch Nachteile. Aus Sicherheitsgründen wird Anwendern oft empfohlen, die JavaScript-Unterstützung in ihren Browsern zu deaktivieren. Ist JavaScript deaktiviert, ist der Nutzer nicht mehr in der Lage
die Adresse zu lesen. Hinzu kommt, dass die Bots nach wie vor angepasst werden können.
Der Aufwand dafür ist zwar beträchtlich größer, aber bei geeigneter Verbreitung wird diese
Funktion mit großer Wahrscheinlichkeit in die Bots integriert werden.
Bilder
Adressen können nicht langfristig unter Einsatz von Webtechnologien geschützt werden. Das
gilt für alle Maßnahmen, die Adressen mittels einer Technik präsentieren, die ein Browser
inhaltlich versteht. Egal wie aufwendig das eingesetzte Verfahren ist, müssen die Bots nur
das lernen, was Browser heute schon können. Um die Adressen wirklich effektiv vor den Bots
zu verbergen, darf keine Webtechnologie eingesetzt werden.
Aus diesem Grund empfiehlt es sich, die Adressen in eine Art Umschlag zu packen. Dieser
wird vom Browser nur gezeigt, kann aber nicht von ihm verstanden werden. Hierfür eignet
sich insbesondere der Einsatz von Bildern.
Anstelle einer textuellen Adresse wird ein Bild gezeigt, auf dem eine Adresse zu lesen
ist. Natürlich kann Text durch den Einsatz von Optical Character Recognition (OCR) aus
Bildern erkannt werden. Ein Spammer kann das Bild herunterladen und mit einem OCR-
66
4.4. Präventiv
Programm auslesen. In naher Zukunft dürfte solch ein Verhalten allerdings nicht zu erwarten
sein. Grundsätzlich stellen sich dem Spammer bei einem solchen Vorgehen die folgenden
Probleme:
1. Weiß er nicht, in welchem Bild die Adresse ist, muss er demnach alle Bilder der Internetseite herunterladen und analysieren. Da Bilder zu den größeren Inhalten einer
Internetseite gehören, bedeutet dies ein sehr großes Downloadvolumen.
2. Der Spammer muss alle Bilder nach möglichen Adressen durchsuchen. Durch die große
Masse an Bildern benötigt dieser Vorgang sehr viel Rechenzeit und -leistung.
Die Probleme beruhen auf Einschränkungen in der Leistung, einerseits des Internetzugangs,
andererseits des verarbeitenden Computers. Moores Law [Moo-1965] sagte alle 18 Monate eine
Verdopplung der Rechenkapazität voraus. Da dieses Gesetz ungebrochen scheint [Sch-1997,
S. 59], handelt es sich nur um einen Vorteil auf Zeit. Aber anders als bei textuellen Lösungen
kann dieses Verfahren weiter erschwert werden.
sip:[email protected]
Abb. 4.4: Explosionsskizzenbeispiel einer Bild-Adresse aus mehreren Teilen.
Für diese Steigerung wird das Bild mit dem Text in mehrere Teile getrennt (vgl.
Abb. 4.4, S. 67). Das Bild sollte derart unterteilt werden, dass die Buchstaben geteilt sind.
Daraus ergeben sich mehrere Vorteile gegenüber der Variante mit einem ganzen Bild.
1. Der Bot muss auf der Internetseite die Bilder herausfinden, die zum Adressbild gehören.
2. Er muss die korrekte Reihenfolge der Bilder herausfinden.
Möchte mit dieser Erweiterung ein Spammer die Adresse sammeln, benötigt er viele Zusatzinformationen und entsprechende Ressourcen. Dieses Verfahren funktioniert nur, weil der
Gesetzgeber keine Verlinkung der Adresse vorschreibt [BMJ-2008b, § 5 Abs. 1].
4.4.2 Adressen streuen
Nutzt ein Teilnehmer nur eine Adresse, kann er leicht Opfer von SPIT werden [CDT-2003,
S. 3]. Dies liegt daran, dass er bei jeder Aufforderung genau diese Adresse eingeben muss.
67
Durch die hohe Verteilung dieser Adresse ist es für Spammer leichter, auf sie aufmerksam
zu werden. Wird ein Spammer auf diese Adresse aufmerksam, bleibt sie ein valides Ziel von
SPIT.
Fiktive Adressen nutzen
Die Eingabe einer fiktive Adresse ist ein sehr effektives Mittel, um selbst kein Spam zu erhalten. Diese Vorgehensweise ist jedoch nicht empfehlenswert und es wird davon abgeraten.
Selbst wenn die Adresse nur ausgedacht ist, kann es trotzdem vorkommen, dass diese
Adresse vergeben ist. Das Spam wird entsprechend an einen unbekannten Dritten zugestellt,
der davon nichts weiß.
Im schlimmsten Fall gibt der Versender des E-Mail-Spam eine nicht existente Adresse
als Absender an. Existiert die angesprochene fiktive Adresse nicht, kann es zu Endlosschleifen
zwischen den beteiligten Mailservern kommen. Beide Server versuchen, sich dann gegenseitig
die Fehlermeldungen zuzustellen [Egg-2005, S. 38].
Spam Sammeldienste nutzen
Bei manchen Internetseiten ist oft im Voraus klar, dass die Angabe einer Adresse Spam zur
Folge hat (z. B. Gewinnspiele). Da aber einige Dienste ohne die Angabe der E-Mail-Adresse
oft gar nicht nutzbar sind, muss eine Adresse angegeben werden. Aus dieser Motivation
wurden Spam Sammeldienste entwickelt.
Der Betreiber eines solchen Dienstes bietet dem Nutzer kostenlos beliebige Adressen. Diese Adressen können auf spamverdächtigen Seiten eingetragen werden. Kommt anschließend
Spam ist das nicht schlimm, da die Adresse keinen weiteren Nutzen hat als Spam zu sammeln.
Teilweise müssen die Adressen nicht registriert werden und sind ohne Passwort zugänglich
[Man-2009]. Da ohne Passwortschutz jeder beliebige Teilnehmer auf die Adresse zugreifen
kann, können auch Dritte diese lesen. Um dem vorzubeugen, können alternative Adressen angeboten werden. Anstatt [email protected] kann die alternative Adresse M8R-rmtci4@
mailinator.com eingetragen werden. Alle E-Mails, die an die alternative Adresse gesendet
werden, landen im Postfach der Originaladresse.
Manche Portalanbieter wollen nicht, dass sich ein Teilnehmer mit einer solchen Adresse
registriert. Aus diesem Grund filtern sie die Domains von bekannten Sammeldienstanbietern
und sperren sie für die Registrierung. Als Reaktion darauf bieten manche Anbieter alternative Domainnamen an. Sie werden anstelle der eigentlichen Hauptdomain angegeben,
verweisen jedoch auf dasselbe Postfach.
68
4.4. Präventiv
Limited-Use-Adressen nutzen
Verwendet ein Teilnehmer nur eine E-Mail-Adresse, ist nicht nachvollziehbar, wo das Spam
herkommt. Somit kann keine Quelle identifiziert werden, die für das Spam verantwortlich
sein könnte.
Da E-Mail-Adressen meistens kostenfrei sind, kann jeder Teilnehmer mehrere Adressen
anmelden und diese entsprechend verwalten [RFC-5039, S. 14–15]. Somit lassen sich mehrere
Verhaltensweisen realisieren.
• Eine Adresse pro soziale Gruppe (Firma, Universität, Freundeskreis).
• Eine Adresse pro Teilnehmer.
• Zeitlich beschränkt gültige Adressen.
Wenn eine spezielle Adresse nur für eine bestimmte soziale Gruppe gültig ist, muss im
Spamfall nur ein Teil der E-Mail-Nutzung eingestellt werden. Kommt das Spam von
Firmamenkontakten, sind nach einer Deaktivierung der Adresse die Freunde oder Kommilitonen nach wie vor in der Lage Nachrichten zu senden. Nur die Kollegen müssen neu informiert
werden.
Wird dieses Konzept auf die Spitze getrieben, erhält jeder Teilnehmer eine eigene Adresse.
Dadurch ist im Spamfall nur der entsprechende Teilnehmer betroffen, der das Spam verursacht
hat.
Für die Nutzung bei Gewinnspielen und dergleichen kann es sinnvoll sein, zeitlich beschränkt gültige Adressen anzulegen. Diese können ohne Schwierigkeiten bei Gewinnspielen etc. eingetragen werden. Beispielsweise werden diese Adressen quartalsweise deaktiviert
und durch neue Adressen ersetzt.
Wenn jede Adresse nur begrenzt weitergegeben wird, kann die Spamquelle genauer bestimmt werden. Die Spamzustellung kann sehr effektitv unterbunden werden, indem die betroffene Adresse wieder deaktiviert wird.
Da die weitergegebene Adresse ungültig wird, sobald Spam eintrifft, kann eine soziale
Gruppe oder ein Teilnehmer keine Nachrichten mehr zustellen. Insbesondere wenn die Adresse
für eine soziale Gruppe war, muss sehr vielen Teilnehmern eine neue Adresse bekannt
gegeben werden.
Mit steigender Granularität der Adressverteilung, steigt der Aufwand den Überblick zu
behalten. Was für Adressen gibt es, wohin wurden sie publiziert? Die Verwaltung dieser
Zusammenhänge kann bei vielen Teilnehmern sehr umständlich und den Aufwand nicht Wert
sein. Zur Lösung dieses Problems, wird die Verwendung eines Presence-URI vorgeschlagen
[RFC-5039, S. 15]. Ein Presence-URI ermöglicht den Zugriff auf den aktuellen Presence-Status
des betroffenen Teilnehmers. Bevor ein Teilnehmer eine Nachricht senden will, fragt er über
den Presence-URI die Adresse des Teilnehmers ab, unter der er gegenwärtig zu erreichen ist.
69
4.4.3 Teilnehmerverhalten
Um SPIT zu verhindern, sind nicht unbedingt algorithmische Lösungen notwendig. Die besten
Schutztechniken haben keinen Effekt, wenn die Nutzer sich unvorsichtig verhalten. Diese
Nachlässigkeit beruht nicht auf Absicht, sondern oft auf Unwissen.
Grundsätzlich besteht die Gefahr, dass gültige E-Mail-Adressen in gültige SIP URI umgewandelt werden können. Beispielsweise wird die Adresse [email protected] mit ziemlicher
Sicherheit beim Session Initiation Protocol (SIP) unter sip:[email protected] ebenfallls eingesetzt werden. Aus diesem Grund wird hier auf Maßnahmen eingegangen, die nur auf E-Mails
anwendbar sind.
Wahl der Adressen
Zunächst erscheint die Art oder der Aufbau der Adresse als irrelevant. Untersuchungen
[CDT-2003, S. 3–4] haben jedoch ergeben, dass kurze URI mehr Spam erhalten. Insbesondere solche Adressen, die aus einem Wörterbuch entnommen sind oder aus einem Akronym
bestehen, erhalten besonders viel Spam.
Abgesehen von der Länge der Adresse ist die Einfachheit ein wichtiges Kriterium.
Wie bereits erwähnt, sind sie besonders anfällig, wenn sie über einen Wörterbuchangriff zu
erreichen sind. Dies gilt ebenfalls für eine Aneinanderreihung von solchen Wörtern. Analog
zu einem guten Passwort, darf eine spamsichere Adresse nicht zu nah an einem echten Wort
oder Satz sein und möglichst Sonderzeichen und Zahlen enthalten.
Adressen nicht unachtsam verteilen
Viele Anwender geben ihre Adressen freiwillig in die Hand potenzieller Spammer.
Ein sehr beliebtes Mittel dazu ist die Aussicht auf einen Gewinn bei einem Gewinnspiel. Der
Nutzer kann nur am Gewinnspiel teilnehmen, wenn er seine personenbezogenen Daten angibt.
Momentan ist die E-Mail-Adresse und die Festnetznummer oft gefragt. Je verbreiteter SIP
sein wird, je wahrscheinlicher wird in Zukunft zusätzlich nach dem SIP URI gefragt werden.
Insgesamt ließen sich die folgenden Orte identifizieren und gruppieren, an denen Nutzer ihre
Adresse freiwillig bekannt geben:
• Foren und Gästebücher.
• Gewinnspiele, Newsletter und Messestände.
• Internetseiten und soziale Netzwerke.
• Homepage-Empfehlungen und Grußkarten.
In vielen Foren und Gästebüchern ist es verpflichtend seine Kontaktdaten zu hinterlegen.
Nach Möglichkeit müssen diese vor der Einsicht Dritter unzugänglich gemacht werden. Hier
70
4.4. Präventiv
ist das ohne große Schwierigkeiten möglich, da das Verbergen der Adresse die Nutzung der
Plattform nicht beeinträchtigt.
Bei der Teilnahme an einem Gewinnspiel sieht dies etwas anders aus. Hier wird dem Teilnehmer ein Gewinn in Aussicht gestellt, wenn er seine personenbezogenen Daten preisgibt.
Ähnlich verhält es sich an einem Messestand oder beim Abonnement eines Newsletters, auf
dem Teilnehmer ihre Daten angeben können. Der potenzielle Gewinn steht jedoch in
keinem Verhältnis zum Risiko, dass eingegangen wird. Entweder muss das Ausfüllen solcher Bögen unterlassen werden, oder es sollten Limited-Use-Adressen angegeben werden. Das
größte Problem an dieser Quelle ist, dass rechtlich gesehen die Erlaubnis zum Zusenden
von Nachrichten erteilt ist [Egg-2005, S. 33]. Subjektiv wird es als Spam empfunden,
jedoch rechtlich als angefordert und somit gewollt definiert.
Wie bereits beschrieben, ist die Angabe einer Adresse, auf einer Internetseite ein Risiko.
Internetseiten werden hauptsächlich von Spammern durchsucht und somit ist die Gefahr
Spam zu erhalten sehr groß. Kritischer ist die Angabe in einem sozialen Netzwerk. Hier
können einige präventive Schutzmaßnahmen nicht eingesetzt werden. Viele Nutzer
fühlen sich in sozialen Netzwerken sicher, da diese nur für Mitglieder einsehbar sind. Sich bei
einem sozialen Netzwerk anzumelden, ist jedoch kein Hindernis für einen Spammer.
Eine der gefährlichsten Quellen sind elektronische Grußkarten. Eine Person erstellt auf einer Internetseite eine Grußkarte und lässt diese an andere Personen schicken. Ähnlich verhält
es sich, wenn ein Freund auf einer dubiosen Internetseite über Einem Freund empfehlen“ die
”
Adresse eingibt. Gefährlich hieran ist, dass der Empfänger der Grußkarte nichts gegen den
Spam tun kann, da er selbst die Adresse nicht veröffentlicht hat.
Umgang mit Adressen von Dritten
Ist die eigene Adresse in den Verzeichnissen von Spammern, hat man keinen Einfluss mehr
darauf, wer sie bekommt. Hierzu muss die Adresse nicht zwingendermaßen in den Händen
dubioser Gesellschaften oder Personen sein. Manche Harvester werden in Form eines Trojaners
auf den Computer eines Nutzers platziert. Dort untersuchen sie das Adressbuch und das
Postfach nach Adressen.
Das Adressbuch ist sicherlich kein Punkt, in dem Adressen reduziert werden können. Aber
das Postfach ist oft eine sehr gute Quelle für Adressen. Viele Anwender versenden Rundmails
an eine ganze Liste von Personen. Diese Liste ist für jeden Empfänger sichtbar und somit
vom Harvester aus dem Postfach auslesbar.
Das Oberlandesgericht Düsseldorf hat ein Urteil [OLG-2006] ausgesprochen, indem einer
Angeklagten untersagt wird, Newsletter direkt an alle Empfänger zu senden. Aus Gründen des
Datenschutzes und der Sicherheit ist es notwendig, die Empfänger per BCC zu adressieren.
Wird dem genüge getan, können Spammer weniger Adressen über die Postfächer sammeln.
71
4.4.4 Umgang mit empfangenem Spam
Jeder Teilnehmer muss vorsichtig mit eingegangenem Spam umgehen. Dies betrifft zwar vorrangig E-Mail-Spam und Spam over Instant Messaging (SPIM), trotzdem kann eine bestätigte
Adresse auch für SPIT genutzt werden. Im Falle von SPIM sogar direkt, da es sich um einen
SIP URI als Ziel handelt.
Deshalb dürfen Nachrichten nie im HTML-Format, sondern immer in Textformat
dargestellt werden. Spammer gestalten Spam oft derart, dass durch die HTML-Darstellung
Bilder aus dem Internet nachgeladen werden. Anhand des Zugriffs erkennt der Spammer,
dass das Zielkonto genutzt wird und somit gültig ist.
Gleiches gilt für das Aktivieren der Links in einer Spamnachricht. Per Gesetz ist der
Versender dazu verpflichtet, dem Empfänger jederzeit die Möglichkeit zu geben, den Dienst
wieder abzumelden. Dieser Mechanismus wird jedoch von Spammern missbraucht [Kar-2006,
S. 25]. Sobald der Newsletter vermeintlich abbestellt wird, registriert der Spammer das Nutzerkonto als genutzt und gültig.
Auf keinen Fall darf auf Spam geantwortet werden. Einerseits wird diese Handlung
als Bestätigung des Nutzerkontos angesehen, andererseits können dadurch Kosten entstehen.
Insbesondere im Bereich SPIT können ahnungslose Teilnehmer auf kostenpflichtige Nummern
gelockt werden.
Beinhaltet eine Spam-E-Mail einen Anhang, darf dieser niemals geöffnet werden.
Anlagen können Spammern zur Verbreitung von Schadsoftware wie Viren und Würmer dienen.
4.5 Zusammenfassung
Es gibt kein sicheres Mittel gegen SPIT. Doch diese Erkenntnis ist nicht neu, da es für
die Bekämpfung von E-Mail-Spam ebenfalls kein sicheres Mittel gibt. Dementsprechend ist
die beste Option eine Kombination der verfügbaren Mittel zur Reduktion des Aufkommens.
Beispielsweise kann durch den dualen Einsatz von White- und Blacklists eine recht
gute Vorabfilterung durchgeführt werden. Das durch diese beiden Verfahren übrig bleibende
SPIT kann anschließend von einer weiteren Maßnahme untersucht werden. Unsichere Kandidaten können z. B. einem Turingtest unterzogen werden.
Dieser Ansatz kann jedoch nur funktionieren, wenn der Spammer mit einer korrekten
Identität anruft. Gibt er einen beliebigen SIP URI an, ist die Wahrscheinlichkeit gering, dass
er auf der Blacklist steht. Im ungünstigsten Fall ist er in der Lage, Zugang zu einer SIP URI
der Whitelist zu erhalten.
Das verdeutlicht, dass alleine durch den Einsatz von Abwehrmaßnahmen das SPIT nicht
effektiv abgewehrt werden kann. Aus diesem Grund werden in einem Bericht [RFC-5039, S. 23]
72
der Internet Engineering Task Force (IETF) vier Punkte aufgelistet, die zur erfolgreichen
Abwehr von SPIT sehr wichtig sind. Diese Punkte werden im Folgenden kurz vorgestellt:
• Whitelists: Durch den Einsatz von Whitelists kann sehr ressourcenschonend entschieden werden, ob eine Nachricht zugestellt wird. Analog werden alle Nachrichten der
übrigen Teilnehmer weiter auf SPIT untersucht. Die Whitelist kann entweder automatisch aufgrund positiver Erfahrungen oder manuell auf Basis der Entscheidung des
Teilnehmers gepflegt werden.
• Starke Identitäten: Der Einsatz identitäsbasierter Abwehrmaßnahmen nutzt jedoch
nichts, wenn der Spammer einen beliebigen Absender wählen kann. Somit können Whitelists nicht effektiv eingesetzt werden, um Nachrichten auszuwählen, die geprüft werden müssen. Ergo muss die Identität des Anrufers sichergestellt sein. Es muss verhindert
werden, dass unautorisierte Teilnehmer Zugang zu anderen Identitäten erhalten.
• Lösung des Einführungsproblems: Die größste Herausforderung ist die Lösung des
Einführungsproblems. Vertrauenswürdige Teilnehmer müssen auf die Whitelist gelangen. Beispielsweise können Teilnehmer automatisch auf die Whitelist gestetzt werden,
sobald sie eine Aufgabe gelöst haben.
• Nicht warten, bis es zu spät ist: Die Provider dürfen das SPIT-Problem nicht
ignorieren bis es zu spät ist. Sobald ein Provider Anrufe aus den Netzen von anderen
Providern sowie dem Internet zulässt, muss er sich Gedanken um SPIT machen.
Sehr problematisch bleibt weiterhin die Abwehr von Direct-IP-SPIT. Da das SPIT hier
an den Proxyservern vorbeigeschleust wird, können sämtliche serverseitige Schutzmechanismen umgangen werden. Zwar ist die Filterung im UE denkbar, für viele Abwehrmaßnahmen
fehlen jedoch entweder die benötigten Informationen oder die Rechenleistung. Eine adäquate
Maßnahme gegen Direct-IP-SPIT existiert bislang nicht. Aus diesem Grund bleibt dem Teilnehmer hier nur der Einsatz von Listenverfahren (z. B. Whitelists).
73
74
Kapitel
5
Sicherheitsverfahren
Wie im vorhergehenden Kapitel beschrieben, ist eine starke Identität unumgänglich,
um Spam over Internet Telephony (SPIT) effektiv zu unterbinden. Dieses, als Authentizität
bekannte Sicherheitsziel, kann im Kontext des IMS mit mehreren Verfahren sichergestellt
werden.
Im Rahmen dieses Kapitels werden Verfahren vorgestellt, die über die Gewährung einer starken Identität hinaus gehen. Insbesondere die Sicherung der Vertraulichkeit muss
gewährleistet werden. Denn durch das Mitlesen der ausgetauschten Daten kann ein
Angreifer Rückschlüsse auf den Inhalt der Whitelist eines Teilnehmers ziehen.
Die in dieser Arbeit vorgestellten Sicherheitsverfahren können nach dem Open Systems
Interconnection (OSI)-Referenzmodell [ISO-1996] in zwei Gruppen untergliedert werden (vgl.
Abb. 5.1, S. 75). Im Gegensatz zum vorherigen Kapitel, werden die Sicherheitsverfahren ohne
diese Unterteilung vorgestellt. Anders als bei den Abwehrmaßnahmen ergeben sich in Bezug
auf SPIT keine derart relevanten Unterschiede zwischen den Gruppen.
Sicherheitsverfahren
Anwendungsschicht
HTTP Autentication
Vermittlungsschicht
IPsec
AKA
SIPS
S/MIME
Abb. 5.1: Kategorisierung der Sicherheitsverfahren [ElK-2008, S. 31].
75
Kapitel 5. Sicherheitsverfahren
5.1 Hypertext Transport Protocol Authentication
Die Hypertext Transport Protocol (HTTP) Authentication [RFC-2617][RFC-3261, S. 193–
210] authentifiziert einen Teilnehmer mittels Challenge-Response-Verfahren. In der Regel
geschieht dies bei der Registrierung oder bei einem Sitzungsaufbau, es ist aber ebenfalls
eine Authentifizierung zwischen zwei Nutzern möglich. HTTP Authentication bietet generell
mehrere Authentifikationsschemata. Für das Session Initiation Protocol (SIP) wird aufgrund
der Sicherheit nur das Digest-Schema [RFC-3261, S. 193] genutzt.
Beim HTTP Authentication-Verfahren wird die Authentifizierung über ein ausgetauschtes
gemeinsames Geheimnis erzielt. Zur Generierung des Geheimnis wird ein einmalig gültiger
Nonce-Wert an den UAC übertragen. Das gemeinsame Geheimnis wird in verschlüsselter
Form an den UAS zurückgemeldet.
Um das HTTP Authentication-Verfahren durchführen zu können, muss zwischen dem
Teilnehmer und dem Infrastrukturbetreiber ein Vertragsverhältnis bestehen. Denn zur
Authentifizierung eines Teilnehmers ist ein Benutzername sowie ein Passwort nötigt. Diese werden nie im Klartext übertragen, sondern fließen in die Berechnung des gemeinsames
Geheimnis ein.
5.1.1 Challenge
Ist beim Zielnetzelement eine Authentifizierung notwendig, antwortet das Netzelement je
nach Typ mit einem entsprechenden Response von Typ 4xx. Diese Antwort beinhaltet ein
zusätzliches Header-Feld, das die für das gemeinsame Geheimnis notwendigen Informationen
überträgt:
• Realm: Benennt den Gültigkeitsbereich für die Authentifizierung. Dies kann beispielsweise durch einen Domain-Namen geschehen.
• Nonce: Dies ist der einmalige und eindeutige Wert, der anfangs erwähnt wird. Es ist
entweder ein base64 [RFC-4648, S. 5–7] oder hexadezimal codierter Wert.
Darüber hinaus sind weitere optionale Felder möglich. Unter anderem kann angegeben werden, welcher Algorithmus zur Verschlüsselung der Prüfsumme verwendet werden soll. Ist
kein Algorithmus angegeben, wird standardgemäß der Message Digest 5 (MD5)-Algorithmus
[RFC-1321] eingesetzt.
5.1.2 Response
Sobald der UAC diese Nachricht erhalten hat, ist er in der Lage, das gemeinsame Geheimnis
zu berechnen. Für die Berechnung werden die folgenden Bestandteile verwendet:
76
5.1. Hypertext Transport Protocol Authentication
• Benutzername: Der Benutzername nennt die Kennung des zu authentifizierenden
Teilnehmers. Er wird im Rahmen einer Teilnehmervereinbarung im Voraus zugewiesen.
Im IMS wird die IMPI als Benutzername genutzt.
• Realm: Dies ist der zuvor über den 4xx-Response dem Teilnehmer zugesandte Realm.
• Passwort: Das zum Benutzernamen gehörende Passwort, das entweder vom Betreiber
zugewiesen oder nach der Nutzungsvereinbarung vom Teilnehmer gewählt wird.
• Nonce: Dies ist der zuvor über den 4xx-Response dem Teilnehmer zugesandte NonceWert.
• Methode: Dies gibt die zu authentifizierende Request-Methode an. Im Fall einer Registrierung ist die Methode REGISTER enthalten.
• Request-URI: Dies gibt die Zieladresse des gesendeten Request an. Falls Alice versucht Bob anzurufen, wird hier z. B. der Wert sip:[email protected] eingetragen.
Benutzername
Realm
Passwort
SIP-Methode
Nonce-Wert
A1
Request-URI
A2
Response
Abb. 5.2: Berechnung des gemeinsamen Geheimnises mittels MD5-Algorithmus.
Zur Berechnung mit dem MD5-Algorithmus werden zunächst zwei Zeichenketten gebildet (vgl. Abb. 5.2, S. 77). Zum einen werden Benutzername, Realm und Passwort zum Wert
A1 [RFC-2617, S. 13] zusammengefasst, wobei die Anführungszeichen vom Benutzernamen
und dem Realm entfernt werden (vgl. Formel 5.1, S. 77).
A1 = Benutzername:Realm:Passwort
(5.1)
Außerdem fließen die Methode und der Request-URI in den Wert A2 [RFC-2617, S. 14] ein
(vgl. Formel 5.2, S. 77). Wie beim Wert A1 werden die Anführungszeichen von der Methode
und dem Request-URI entfernt.
A2 = Methode:Request-URI
(5.2)
Abschließend werden die Zeichenketten A1 und A2 mit dem MD5-Algorithmus verarbeitet
und zusammen mit dem Nonce-Wert verkettet. Die daraus resultierende Zeichenkette wird
77
wiederum mit dem MD5-Algorithmus verarbeitet (vgl. Formel 5.3, S. 78). Das Ergebnis dieser
Berechnung ist das gemeinsame Geheimnis [RFC-2617, S. 13].
Response = MD5[MD5(A1):Nonce-Wert:MD5(A2)]
(5.3)
Das Endgerät des Teilnehmers kann den Benutzer gegebenenfalls dazu auffordern, den
Benutzernamen und das Passwort manuell einzugeben. Nach der Verschlüsselung sendet
der UAC seinen Request erneut. In einem zusätzlichen Header überträgt er die folgenden
Informationen:
• Benutzername: Der zur Berechnung der Prüfsumme verwendete Benutzername.
• Realm: Eine Wiederholung des Gültigkeitsbereichs, der in der Nachricht des Netzelementes enthalten war.
• Nonce: Eine Wiederholung des Nonce-Wertes, der vom Netzelement zugesandt wurde.
• Request-URI: Der zur Berechnung der Prüfsumme verwendete Request-URI, der den
UAS adressiert.
• Response: Das gemeinsame Geheimnis, das aus den obigen sechs Komponenten besteht.
Nach Erhalt des wiederholten Request vergleicht das Netzelement den gesendeten und empfangenen Nonce-Wert. Außerdem führt er seinerseits die Berechnung der Prüfsumme durch
und verschlüsselt diese entsprechend. Stimmt das Ergebnis mit dem empfangenen ResponseWert überein, wird der Request des UAC bearbeitet. Ansonten wird der Request erneut mit
einer Nachricht vom Typ 4xx abgelehnt.
5.1.3 Anwendungsszenarien
Der Standard sieht drei Szenarien zur Anwendung von HTTP Authentication vor [RFC-3261,
S. 193–210]. Die Authentifizierung gegenüber eines Registrar- oder Proxy-Servers und zwischen zwei Teilnehmern. Im Folgenden werden diese drei Szenarien näher vorgestellt.
Authentifizierung der Registrierung
Um zu verhindern, dass sich unberechtigte Teilnehmer Zugang zu einem Teilnehmerkonto
verschaffen, ist hier eine Authentifizierung notwendig. Im Rahmen dieser Authentifizierung
müssen zwei Faktoren überprüft werden.
1. Ist der Teilnehmer derjenige, für den er sich ausgibt.
2. Ist der Teilnehmer berechtigt, sich an diesem Registrar anzumelden.
78
Fremdnetz
UE
Heimatnetz
P-CSCF
REGISTER
HSS
I-CSCF
REGISTER
S-CSCF
UAR
UAA
REGISTER
MAR
MAA
401 Unauthorized
401 Unauthorized
401 Unauthorized
REGISTER
REGISTER
UAR
UAA
REGISTER
SAR
SAA
200 OK
200 OK
200 OK
Abb. 5.3: Registrierung mit HTTP Authentication.
Für diese Authentifizierung wird im Standard [RFC-3261, S. 64] das HTTP AuthenticationVerfahren vorgeschrieben.
Um sich zu registrieren, sendet der Teilnehmer zunächst einen normalen REGISTERRequest an den Registrar (vgl. Abb. 5.3, S. 79). Der Registrar weist diesen REGISTERRequest mit einem Response vom Typ 401 Unauthorized (vgl. Notation 5.1, S. 79) zurück.
Nach Erhalt dieser Nachricht berechnet der UAC aus den mitgelieferten Informationen das
gemeinsame Geheimnis. Anschließend sendet der UAC einen erneuten REGISTER-Request
(vgl. Notation 5.2, S. 80) an den Registrar. Diese enthält im Header-Feld Authorization
das berechnete gemeinsame Geheimnis sowie weitere Informationen, wie oben beschrieben.
Stimmt das übermittelte gemeinsame Geheimnis mit den Berechnungen des Registrar-Servers
überein, wird die Registration mit einer Nachricht vom Typ 200 OK bestätigt.
SIP /2.0 4 01 Unauthorized
CSeq : 1 REGISTER
WWW - Authenticate : Digest
79
realm =" atlanta . com " ,
nonce =" e a 9 c 8 e 8 8 d f 8 4 f 1 c e c 4 3 4 1 a e 6 c b e 5 a 3 5 9 "
[...]
Notation 5.1: 401 Unauthorized-Response.
REGISTER sip : scscf . biloxi . com SIP /2.0
CSeq : 2 REGISTER
Authorization : Digest
username =" bob " ,
nonce =" e a 9 c 8 e 8 8 d f 8 4 f 1 c e c 4 3 4 1 a e 6 c b e 5 a 3 5 9 " ,
uri =" sip : scscf . biloxi . com " ,
response =" d f e 5 6 1 3 1 d 1 9 5 8 0 4 6 6 8 9 d 8 3 3 0 6 4 7 7 e c c "
[...]
Notation 5.2: REGISTER-Request inklusive Authentifizierungsinformationen.
Authentifizierung gegenüber einem Proxy
Beim Kontakt zu einem Proxy-Server kann eine Authentifizierung sinnvoll sein. Der Betreiber
des durch den Proxy angebotenen Service kann ein Interesse daran haben, dass nur bestimmte
Teilnehmer diesen verwenden können. Um einen solchen Dienst möglich zu machen, muss der
Betreiber einen Statefull-Proxy einsetzen. Der Proxy muss nämlich für die Authentifizierung
unter anderem den gesendeten Nonce-Wert zwischenspeichern. In der Regel wird vorher eine
solche Nutzungsvereinbarung zwischen dem Teilnehmer und dem Betreiber abgeschlossen.
Alice
Bob
Proxy
INVITE
407 Proxy Authent...
ACK
INVITE
100 Trying
180 Ringing
200 OK
ACK
INVITE
100 Trying
180 Ringing
200 OK
ACK
Abb. 5.4: Proxy-Sitzungsaufbau mit HTTP Authentication.
80
Will beispielsweise ein berechtigter Teilnehmer einen Anruf über einen gesicherten Proxy
tätigen, sendet er zunächst einen normalen INVITE-Request an den zuständigen Proxy (vgl.
Abb. 5.4, S. 80). Analog zum Registrar weist der Proxy diesen Request mit einem Response
vom Typ 407 Proxy Authorization Required (vgl. Notation 5.3, S. 81) ab. Im Sinne des ThreeWay-Handshakes bestätigt der UAC diese Nachricht zunächst mit einem ACK-Request. Anschließend erfolgen dieselben Berechnungen wie bei der Registrierung gegenüber dem Registrar. Im erneut gesendeten INVITE-Request (vgl. Notation 5.4, S. 81) wird ein zusätzliches
Header-Feld namens Proxy-Authorization mit dem gemeinsamen Geheimnis usw. eingefügt.
War die Berechnung korrekt, wird die Verbindung unter Teilnahme des Proxys aufgebaut.
SIP /2.0 4 07 Proxy Authorization Required
CSeq : 1 INVITE
Proxy - Authenticate : Digest
nonce =" f 8 4 f 1 c e c 4 1 e 6 c b e 5 a e a 9 c 8 e 8 8 d 3 5 9 "
[...]
Notation 5.3: 407 Proxy Authorization Required.
INVITE sip : bob@biloxi . com SIP /2.0
CSeq : 2 INVITE
Proxy - Authorization : Digest
username =" alice " ,
nonce =" w f 8 4 f 1 c e c z x 4 1 a e 6 c b e 5 a e a 9 c 8 e 8 8 d 3 5 9 " ,
uri =" sip : bob@biloxi . com " ,
response ="42 c e 3 c e f 4 4 b 2 2 f 5 0 c 6 a 6 0 7 1 b c 8 "
[...]
Notation 5.4: INVITE-Request inklusive Authentifizierungsinformationen.
Authentifizierung zwischen zwei Teilnehmern
Da beim Einsatz von Peer-to-Peer-Anrufen kein Proxy zwischengeschaltet ist, der den Anrufer authentifizieren kann, sollte dies der Nutzer übernehmen. Die Authentifizierung verläuft
analog zur Authentifizierung gegenüber eines Registrars, nur dass anschließend eine Sitzung
aufgebaut wird (vgl. Abb. 5.5, S. 82).
In der Praxis kommt dieses Verfahren bisher kaum zum Einsatz [TW-2007, S. 364]. Das
liegt vor allem daran, dass die meisten Teilnehmer keine Zertifikate haben. Im Kontext der
81
SPIT-Bekämpfung empfiehlt es sich jedoch sie durchzuführen, um gegen Direct-IP-SPIT
vorgehen zu können.
Alice
INVITE
Bob
401 Unauthorized
ACK
INVITE
200 OK
ACK
Abb. 5.5: Peer-to-Peer-Sitzungsaufbau mit HTTP Authentication.
5.1.4 Authentication and Key Agreement
Befindet sich im UE eine UICC, kann die HTTP Digest Authentication using Authentication and Key Agreement (AKA) [RFC-3310] eingesetzt werden. Dieses Verfahren wird
hauptsächlich für mobile Zugangsgeräte verwendet. Anstelle des regulären Benutzernamens und Passworts werden hier die Daten der UICC genutzt.
Da zum Zugang in das IMS entweder ein ISIM oder ein USIM auf der UICC vorhanden
sein muss, können prinzipiell zwei Authentifikationsszenarien eintreten. Eines mit ISIM und
eines mit USIM. Da das ISIM auf das IMS zugeschnitten ist, beschränken wir uns diesem
Abschnitt auf die Authentifikation mittels ISIM.
Erhält die S-CSCF einen Registrierungswunsch, besorgt sie sich mehrere Authentifikations Vektoren vom Home Subscriber Server (HSS). Für eine Registrierung wird zwar nur ein
Vektor benötigt, aber um den Kontakt zum HSS gering zu halten, werden mehrere gesendet.
Ein solcher Vektor beinhaltet die folgenden Informationen [RFC-3310, S. 4]:
• Random Challenge (RAND): Die RAND wird vom HSS generiert und basiert auf
einer SQN.
• AUTN: Das AUTN wird vom HSS für jeden Vektor neu berechnet. Es beinhaltet das
gemeinsame Geheimnis und die SQN. Durch die SQN gibt es niemals zweimal denselben
Vektor.
• Expected Response (XRES): Die vom UE erwartete Response (RES) innerhalb
des nächsten REGISTER-Requests.
• IK: Ein Sitzungsschlüssel, der für die Verschlüsselung der Kommunikation benötigt
wird.
82
• CK: Ein Sitzungsschlüssel, der für die Überprüfung der Integrität der Kommunikation
benötigt wird.
Die S-CSCF nutzt den ersten Vektor, um die Authentifikation durchzuführen. Zur Generierung des 401 Unauthorized-Responses wird die Base64-Repräsentation der RAND mit dem
AUTN als Nonce-Wert eingefügt [RFC-3310, S. 6–7] (vgl. Abb. 5.6, S. 83 und Formel 5.4,
S. 83)[RFC-3310, S. 6–7].
Geheimnis
RAND
SQN
AUTN
Nonce
Abb. 5.6: Berechnung des Nonce-Wertes mit AKA.
Nonce = Base64(RAND:AUTN)
(5.4)
Um klarzustellen, dass die Berechnungen auf Basis der AKA durchgeführt werden sollen,
wird der optionale Parameter algorithm“ in das Header-Feld eingefügt (vgl. Notation 5.5,
”
S. 83). Dieser beinhaltet den Wert AKAv1-MD5“, womit der Einsatz der AKA angegeben
”
wird.
SIP /2.0 4 01 Unauthorized
CSeq : 1 REGISTER
WWW - Authenticate : Digest
nonce =" e a 9 c 8 e 8 8 d f 8 4 f 1 c e c 4 3 4 1 a e 6 c b e 5 a 3 5 9 "
algorithm = AKAv1 - MD5
[...]
Notation 5.5: 401 Unauthorized-Response mit AKA.
Wenn der Client den 401 Response erhält, berechnet er aus dem Nonce-Wert wieder das
AUTN. Das AUTN verifiziert er anschließend mit dem gemeinsamen Geheimnis und der
SQN. Stimmt die Berechnung überein, ist das IMS seitens des UE authentifiziert.
Nachdem das IMS authentifiziert wird, berechnet der Client die RES und sendet sie an die
S-CSCF zurück. Diese Berechnung wird analog zu der ohne AKA durchgeführt. Zusätzliche
berechnet der Client mit dem AUTN und dem gemeinsamen Geheimnis die Sitzungsschlüssel
83
CK und IK. Diese werden für zukünftige Kommunikationen mit dem IMS zum Schutz der
Kommunikation verwendet.
Nachdem die RES über einen erneuten Registrationsversuch an die S-CSCF zurückgesendet
wird, vergleicht die S-CSCF die Werte von der RES und der XRES. Stimmen beide Werte
überein, ist der Client authentifiziert und die Registration wird durchgeführt.
Erreichter Schutz:
• Authentitizität: Durch den Einsatz der Benutzernamen und Passwörter zur Berechnung des gemeinsamen Geheimnises.
• Verbindlichkeit: Da Statefull-Proxy an der Kommunikation beteiligt sind und eine
Zuordnung zum Benutzerprofil durchführen können.
• Zugriffskontrolle: Nur Teilnehmer mit einem gültigen gemeinsamen Geheimnis
können eine Kommunikationsverbindung aufbauen.
5.2 Session Initiation Protocol Security
Beim Transfer der Nachrichten ist prinzipiell ein Mitlesen möglich, da das SIP im Klartext übertragen wird. Diese Nachrichten enthalten oft sensible Daten wie Session Initiation
Protocol Uniform Ressource Identifier (SIP URI), IP-Adressen oder Benutzernamen. Daher
empfiehlt sich eine Verschlüsselung der Nachrichtenübertragung durchzuführen.
Dafür kann das durch Session Initiation Protocol Security (SIPS) [RFC-3261, S. 239–240]
bereitgestellte SIPS-URI-Schema verwendet werden. Die Bezeichnung lehnt sich an die
Hypertext Transport Protocol Security (HTTPS) [RFC-2818] (eine verschlüsselte Variante
von HTTP) an. Analog zu HTTPS unterscheiden sich SIP URI und SIPS-URI im Präfix.
• sip:[email protected].
• sips:[email protected].
Jeder SIP URI mit dem Präfix sips erzwingt eine Verschlüsselung mit SIPS. Gibt der
Teilnehmer einen Session Initiation Protocol Security Uniform Ressource Identifier (SIPS
URI) in seinen UA ein, wird automatisch eine SIPS-geschützte Verbindung hergestellt.
5.2.1 Transport Layer Security
Analog zu HTTPS nutzt SIPS die Transport Layer Security (TLS)-Protokollkombination
[RFC-4346]. Da TLS ein verbindungsorientiert arbeitendes Protokoll benötigt, können nur
Transmission Control Protocol (TCP) und Session Control Transmission Protocol (SCTP)
[RFC-3436] eingesetzt werden.
84
5.2. Session Initiation Protocol Security
Zur Durchführung der Verschlüsselung bedient sich TLS mehrerer Subprotokolle (vgl.
Abb. 5.7, S. 85). Diese werden im Folgenden kurz vorgestellt:
• Application Data Protocol [RFC-4346, S. 53]: Das Application Data Protocol bildet
die Schnittstelle zur Anwendung. Es leitet die gesendeten und empfangenen Daten an
die Anwendung weiter und nimmt sie entgegen.
• Alert Protocol [RFC-4346, S. 26–31]: Kommt es zu einem Fehler, versendet das Alert
Protocol entsprechende Fehler- oder Statusnachrichten.
• Handshake Protocol [RFC-4346, S. 31–52]: Zur Aushandlung der Schlüssel wird das
Handshake Protocol eingesetzt. Optional kann das Handshake Protocol zur Authentifizierung der beteiligten Teilnehmer eingesetzt werden.
• Change Cipher Spec Protocol [RFC-4346, S. 25–26]: Das durch das Handshake
Protocol ausgehandelte Schlüsselmaterial wird durch das Change Cipher Spec Protocol
aktiviert.
• Record Layer [RFC-4346, S. 17–23]: Die Record Layer empfängt die unverschlüsselten
Daten und sorgt für eine Fragmentierung, Kompression und Dekompression sowie eine
Verschlüsselung.
Anwendungsdaten
Transport Layer Security (TLS)
Application Data
Alert
Handshake
Change Cipher Spec
Record Layer
Transmission Control Protocol (TCP)
Abb. 5.7: Transport Layer Security-Schichtenmodell [Ble-2005, S. 279].
5.2.2 Anwendungsszenario
Will ein Teilnehmer, dass seine Verbindungen mit TLS verschlüsselt werden, muss er seinen
SIPS URI bekannt geben. In dem Moment, indem ein UA eine SIPS URI-Adresse kontaktieren will, baut er eine SIPS-Verbindung zu seinem P-CSCF auf (vgl. Abb. 5.8, S. 86). TLS ist
allerdings nur ein Hop-by-Hop arbeitendes Protokoll. Das heißt, zwischen jedem Netzelement auf dem Weg zum UAS wird eine separate SIPS-Verbindung aufgebaut. Dies gilt
85
atlanta.com
Alice
Bob
biloxi.com
TCP
TLS
INVITE
100 Trying
TCP
TLS
INVITE
100 Trying
Verschlüsselung
INVITE
180 Ringing
200 OK
ACK
180 Ringing
200 OK
ACK
180 Ringing
200 OK
ACK
Abb. 5.8: Domainübergreifender SIPS-Verbindungsaufbau.
allerdings nur bis zum I-CSCF der Zieldomain. Dort kann ein für diese Domain übliches Verschlüsselungsverfahren genutzt werden. Die Nutzung von TLS wird allerdings bis zum UAS
empfohlen [Aud-2008, S. 7–9].
Erreichter Schutz:
• Datenintegrität: Durch die Verschlüsselung der Daten zwischen zwei Netzelementen.
• Vertraulichkeit: Durch die verschlüsselte Übertragung der Daten zwischen zwei
Netzelementen.
5.3 Privacy-Service
Da einige personenbezogene Daten beim SIP beispielsweise für das Routing benötigt werden,
können diese nicht ohne verschlüsselt werden. Um zu verhindern, dass selbst diese Informationen durch Mithören gesammelt werden, wurde von der Internet Engineering Task Force
(IETF) ein Privacy-Service [RFC-3323] definiert. Dieser Privacy-Service bietet dem Nutzer
einen Anonymisierungsdienst.
86
5.3. Privacy-Service
5.3.1 Anonymisierungsstufen
Die Anonymisierung erfolgt durch die Nutzung des neu definierten Privacy-Header-Feldes.
Es kann entweder von einem UA oder von einem Server in den Header integriert werden und
gewährt je nach zugeordnetem Wert Anonymität. Für den Anonymisierungsdienst werden
die folgenden Feldwerte definiert [RFC-3323, S. 11–12]:
• Header: Es muss sichergestellt werden, dass keinerlei Rückschlüsse auf die bisher
durchlaufenen Netzknoten getroffen werden können. Konkret bedeutet dies eine Anonymisierung der Header-Felder Via, Contact und Route. Am besten eignet sich hierfür
der Einsatz eines B2BUA [TW-2007, S. 377], da dieser die Nachrichten terminiert. Außerdem wird unter Einsatz eines B2BUA gewährleistet, dass das Routing der Nachricht
nicht negativ beeinträchtigt wird.
• None: Die durch den Provider zur Verfügung gestellten Privacy-Services dürfen explizit
nicht zur Anwendung kommen.
• Session: Für den Austausch der Mediendaten werden sensible Informationen in Form
von IP-Adressen sowie Port-Nummern übermittelt. Sollen diese anonymisiert werden,
muss der Privacy-Service dies tun. Dies geschieht in der Regel, indem der PrivacyService eine eigene Schnittstelle zum Empfang der Daten bereitstellt und diese anschließend an das korrekte Ziel weiterleitet. Analog zum Wert Header eignet sich hierfür ein
B2BUA am besten.
• User: Alle Informationen der Nachricht, die eine Identifizierung des Teilnehmers zulassen, werden anonymisiert. Insbesondere betrifft dieser Feldwert die Angaben in den
beiden Header-Feldern From und To.
Außerdem kann eingestellt werden, dass eine Transaction nur zustande kommen, wenn der
angefragte Anonymisierungsdienst zur Verfügung gestellt werden kann. Um dies zu fordern,
muss zusätzlich zum Inhalt des Privacy-Headers der Wert critical“ eingetragen werden. Kann
”
diese Anonymisierung nicht zur Verfügung gestellt werden, muss der Privacy-Service
das Zustandekommen der Transaction mit einem 5xx-Response ablehnen.
5.3.2 Anonymisierungsverhalten
Abhängig von der angeforderten Anonymisierungsstufe, agieren die Proxy unterschiedlich.
Header-Felder können anonymisiert, gelöscht oder nicht hinzugefügt werden. In der hier aufgeführten Tabelle (vgl. Tab. 5.1, S. 88) werden nur diejenigen Header-Felder betrachtet, die
im Rahmen dieser Arbeit relevant sind.
Für das genaue Verhalten eines Proxy gibt es keine starren Regelungen. Es gibt nur eine Empfehlung seitens der IETF, wie bestimmte Header-Felder behandelt werden sollen
[Mun-2008, S. 6] (vgl. Tab. 5.1, S. 88).
87
Header-Feld
User
Header
Session
Call-ID
Anonym
–
–
Contact
–
Anonym
–
From
Anonym
–
–
P-Asserted-Identity
Löschen
–
–
–
Anonym
–
Via
Tab. 5.1: Verhalten beim Privacy-Service [Mun-2008, S. 6].
Erreichter Schutz:
• Privatsphäre: Durch Anbieten eigener neutraler Schnittstellen und anonymer Zuordnung.
5.4 Secure/Multipurpose Internet Mail Extensions
Mit SIPS ist zwar bereits die Verschlüsselung der Nachrichten möglich, doch erfolgt diese
nur zwischen zwei Netzelementen. Falls der Angreifer über die Steuerung eines Netzelementes
verfügt, kann mit SIPS nicht verhindert werden, dass dieser die Nachricht lesen kann. Deshalb
empfiehlt sich eine Ende-zu-Ende-Verschlüsselung.
Muss die Nachricht keine nachrichtenterminierenden Netzelemente (z. B. B2BUA) durchlaufen, eignet sich der Einsatz der Secure/Multipurpose Internet Mail Extensions (S/MIME)
[RFC-3851].
5.4.1 Schlüsselaustausch
Um den Body der Nachricht mit S/MIME zu verschlüsseln, benötigen beide beteiligten
Teilnehmer ein Zertifikat. Der Sender benötigt dann Kenntnis über den Public Key des
Empfängers. Diesen verwendet er für die Verschlüsselung des Body. Anschließend signiert
der Sender die Nachricht mit seinem Private Key und codiert ihn anschließend mit dem
Public Key des Empfängers.
Das größte Problem bei S/MIME ist der Erwerb des Zertifikats des Zielteilnehmers. Es
kann zwar mittels des SIP übertragen werden, dies ist jedoch unsicher. Ein Angreifer kann
die Nachricht abfangen und mit einem gefälschten Zertifikat modifizieren. Aus diesem Grund
emphielt sich der Einsatz einer Public-Key-Infrastruktur (PKI). Eine PKI zu implementieren ist jedoch ein sehr großer Aufwand.
Ein weiteres Problem ist die Vertrauenswürdigkeit des Ausstellers der Zertifikate.
Daher wird die Nutzung von Zertifikaten von autorisierten Betreibern empfohlen. Die Bun-
88
5.5. Internet Protocol Security
desnetzagentur nennt auf ihrer Internetpräsenz alle in Deutschland akkreditierten Aussteller
[Bun-2009].
5.4.2 Authentifizierung
Da S/MIME nur den Message-Body verschlüsselt kann der Sender eigentlich nicht Authentifiziert werden. Um eine Authentifizierung zu erzielen, können die Header-Felder zusätzlich in
den Message-Body geschrieben werden. Der UAS kann dann die empfangenen Header-Felder
mit jenen im Message-Body vergleichen, um herauszufinden, ob sie verändert wurden.
Erreichter Schutz:
• Authentizität: Durch das verschlüsselte Senden der Header-Felder im MessageBody.
• Datenintegrität: Durch die Verschlüsselung der Nutzdaten.
• Privatsphäre: Die in den Nutzdaten transportieren Informationen bleiben vor Angreifern geheim.
• Verbindlichkeit: Durch den Einsatz der Zertifikate.
• Vertraulichkeit: Durch das Verschlüsseln der Nachricht.
• Zugriffskontrolle: Nur Teilnehmer mit einem gültigen Zertifikat und beteiligtem
Schlüssel können auf S/MIME-Daten zugreifen.
5.5 Internet Protocol Security
Die Sicherheitsmaßnahmen müssen sich zur Spambekämpfung nicht nur auf das SIP beschränken. Da das SIP mittels Internet Protocol (IP) übertragen wird, können IP-basierte
Schutzmechanismen eingesetzt werden. Dies ist sinnvoll, da das Internet Protocol Version
4 (IPv4) momentan das Basisprotokoll für das Internet darstellt. In Zukunft wird sich das
nicht ändern, da das Internet Protocol Version 6 (IPv6) als neuer Standard verabschiedet ist.
Für das IMS wird das IPv6 als Standardprotokoll definiert.
Jedoch stellen weder das IPv4 noch das IPv6 eigene Sicherheitsverfahren zur Verfügung.
Zwar werden die Nachrichten über eine Checksumme geschützt, diese beschränkt sich aber
auf die Erkennung von Übertragungsfehlern. Aus diesem Grund ist es sinnvoll, die Internet
Protocol Security (IPsec) [RFC-2401] einzusetzen. Die IPsec erweitert das IP um kryptografische Verfahren zur Authentifizierung der Teilnehmer, Überprüfung der Datenintegrität und
der Datenvertraulichkeit.
89
5.5.1 Sicherheitsassoziationen
Bevor die IPsec eingesetzt werden kann, müssen sich die beteiligten Endpunkte zunächst
über die Sicherheitsvereinbarungen einigen. Diese Sicherheitsvereinbarungen werden bei der
IPsec über sogenannte Sicherheitsassoziationen (SA) [RFC-2401, S. 8–9] definiert. SA
werden unidirektional definiert, für einen kompletten Schutz müssen sie folglich von beiden
Richtungen gesetzt werden. Dieses anscheinend umständliche Verfahren wird auf diese Weise
eingerichtet, um den Endsystemen mehr Flexibilität zu bieten [Ble-2005, S. 211]. In einer SA
werden die folgenden Vereinbarungen getroffen:
• Der zu verwendende Übertragungsmodus.
• Die zu verwendenden Verfahren für die Prüfsummenbildung und Verschlüsselung.
• Das zugehörige Schlüsselmaterial.
• Die aktuell gültige Sequenznummer.
• Die Gültigkeitsdauer der SA.
Eine SA wird über das Tripel aus Zieladresse, Nummer des IPsec-Protokolls (ESP=50,
AH=51) und dem Security Parameter Index (SPI) gebildet. Auf die IPsec-Protokolle wird
weiter unten in diesem Abschnitt ausführlicher eingegangen. Der SPI [RFC-2401, S. 21] ist
ein 32-bit-Wert zur Unterscheidung mehrere SA, zwischen denselben Endpunkten.
5.5.2 Sicherheitsmodi
Mit der IPsec sind zwei Sicherheitsmodi [RFC-2401, S. 7] unterstützt, die im Folgenden kurz
vorgestellt werden:
• Transportmodus (vgl. Abb. 5.9, S. 90): Dieser ist der einfachere der beiden Modi. Die
Nachrichten werden zwischen den beiden Endgeräten geschützt. Dieser Modus fügt nur
einen zusätzlichen IPsec-Header zwischen IP-Header und Nutzdaten ein, sodass kaum
Overhead entsteht.
Alice
IPsec-Sicherung
Bob
Abb. 5.9: Ende-zu-Ende-Sicherung [Ble-2005, S. 212].
• Tunnelmodus (vgl. Abb. 5.10, S. 91): In diesem Modus werden die Nachrichten zwischen zwei Security-Gateways geschützt. Dadurch ist es nicht mehr notwendig, dass
die Endsysteme IPsec-fähig sind. Andererseits erstreckt sich die Sicherheit nur für die
90
5.5. Internet Protocol Security
Carol
Alice
Security
Gateway
IPsec-Sicherung
Security
Gateway
Bob
Dave
Abb. 5.10: Netz-zu-Netz-Sicherung [Ble-2005, S. 212].
Inter-Gateway-Verbindung. Im Gegensatz zum Transportmodus ist hier ein deutlich
höherer Overhead nötig, da das gesamte IP-Paket gekapselt werden muss.
Der Tunnelmodus ist für den Einsatz gegen Spam nicht weiter relevant. Das Einrichten
eines VPN ist nur für lokale Netze eine Lösung, die nicht ans Internet angeschlossen sind. Es
kann nicht davon ausgegangen werden, dass im Internet Tunnel zwischen allen Teilnehmern
eingerichtet werden und somit die Spammer ausgesperrt werden.
5.5.3 Protokolle
Wie bereits erwähnt, bietet die IPsec zwei Protokolle [RFC-2401, S. 6–7]. Sie unterscheiden
sich in der Art des zur Verfügung gestellten Schutzes.
• Authentication Header [RFC-2402]: Dieses Protokoll dient der Sicherung der Authentizität des Senders und der Integrität der Nutzdaten.
• Encapsulating Security Payload [RFC-2406]: Dieses Protokoll dient zusätzlich dem
Schutz der Vertraulichkeit.
Da die Zielsetzung dieses Kapitels in der Einführung in Sicherheitsmaßnahen zur Erbringung einer starken Identität liegt, wird das ESP nicht weiter untersucht. Des Weiteren ist
die Vertraulichkeit der Daten für die Abwehr von SPIT nicht weiter relevant, da keines der
vorgestellten Verfahren auf die Nutzdaten zugreift.
Zur Sicherung der Authentizität des Senders kann der AH eingesetzt werden. Zusätzlich
zur Authentizität wird hierbei eine Datenintegrität geboten, die für die Betrachtungen hier
jedoch nicht weiter relevant ist.
Setzt die IPsec den AH ein, wird zwischen die Nutzdaten und den IP-Header des IP-Pakets
der IPsec-Header eingefügt (vgl. Abb. 5.11, S. 92). Zur Berechnung der Prüfsumme werden
nicht nur die Nutzdaten, sondern Teile des IP-Headers und des IPsec-Headers mit einbezogen.
Der Empfänger berechnet eine Prüfsumme und vergleicht sie mit der mitgesendeten Summe.
Stimmen sie überein, wird das Paket weiterverarbeitet. Die Authentizität des Senders wird
durch die Einbeziehung der Header in die Prüfsumme gewährleistet.
91
IP-Header
IP-Header
IPsec-Header
IP-Nutzdaten
IP-Nutzdaten
Abb. 5.11: Integration des AH-Headers in ein IP-Paket [Ble-2005, S. 215].
In die Berechnung der Prüfsumme wird jedoch nur ein Teil des IP-Headers einbezogen
(vgl. Abb. 5.11, S. 92). Das liegt daran, dass einige Header-Felder während des Transports
verändert werden müssen. Beispielsweise reduziert jedes durchlaufene Netzelement das Time
to Live (TTL)-Feld. Wird dieses Feld mit verrechnet, kann auf der Empfängerseite kein
korrekter Prüfsummenvergleich stattfinden, da unterschiedliche Header vorliegen.
Zur Berechnung der Prüfsumme wird die Verwendung von Message Digest 5 (MD5)
[RFC-1321] oder Secure Hash Algorithm 1 (SHA-1) [NIS-2008][RFC-3174] vorgeschrieben.
Da jedoch sowohl der MD5- [Wan-2004] als der SHA-1-Algorithmus [McD-2009] nicht mehr
lange als sicher angesehen werden können, startete das National Institute of Standards and
Technology (NIST) einen Wettbewerb [NIS-2007], um einen Nachfolger unter dem Namen
Secure Hash Algorithm 3 (SHA-3) zu finden. Der Einsendeschluss für Vorschläge ist mittlerweile verstrichen, ein Sieger steht jedoch noch nicht fest. Sobald dieser feststeht, wird der
SHA-3 vermutlich anstelle vom MD5-Algorithmus und dem SHA-1 für die IPsec eingesetzt.
Erreichter Schutz:
• Authentizität: Durch das verschlüsselte Senden der Header-Felder.
• Datenintegrität: Durch die Verschlüsselung der Nutzdaten.
• Privatsphäre: Die in den Nutzdaten transportieren Informationen bleiben vor Angreifern geheim.
• Vertraulichkeit: Durch das Verschlüsseln der Nachricht.
5.6 Zusammenfassung
Durch die in diesem Kapitel vorgestellten Verfahren kann eine starke Identität für einen
Teilnehmer sichergestellt werden. Bei einer standardkonformen Umsetzung des IMS werden
zwei der vorgestellten Verfahren ohnehin unterstützt. Der Standard schreibt die Nutzung
der HTTP Digest Authentication für die Registrierung vor [RFC-3261, S. 64]. Des Weiteren richtet eine P-CSCF standardgemäß einen IPsec-Tunnel zwischen sich und dem UE ein
[TSG-2009a, S. 23].
Durch das Mitlesen der ausgetauschten Nachrichten können Spammer Aufschluss über die
Einträge von Whitelists erhalten. Aus diesem Grund empfiehlt es sich, die gesendeten Nach-
92
richten zu verschlüsseln oder zu anonymisieren. Zur Anonymisierung kann der Privacy-Service
eingesetzt werden, wodurch ein Spammer nur noch schwer Rückschlüsse auf die tatsächlich
beteiligten Teilnehmer ziehen kann. Um eine höhere Sicherheit zu erzielen, können die Nachrichten mittels IPsec verschlüsselt werden. Der Einsatz von S/MIME empfiehlt sich nicht, da
dieser Ansatz am Aufwendigsten ist und selten unterstützt wird.
Trotzdem bleibt weiterhin der Umgang mit Direct-IP-SPIT ungeklärt. Zwar kann das
HTTP Digest Authentication-Verfahren zwischen zwei Teilnehmern eingesetzt werden, doch
dafür fehlen ihnen in der Praxis die nötigen Informationen. Außerdem fehlt insbesondere den
Hard-Phones oft die nötige Rechenleistung für die Berechnungen.
93
94
Kapitel
6
Direct-IP-SPIT-Schutz
Die im Rahmen dieser Arbeit vorgestellten Sicherheitsverfahren und Abwehrmaßnahmen bieten bereits einen guten Schutz gegen Spam over Internet Telephony (SPIT). Wie sich jedoch
gezeigt hat, sind sie in der Regel nur im IMS einsetzbar. Findet die SPIT-Übertragung direkt
zwischen den Endgeräten statt, kann kein Schutz mehr gewährleistet werden.
Gegen dieses Direct-IP-SPIT können, auf der Seite des Endgerätes, meist nur die Listenverfahren (z. B. Whitelists) eingesetzt werden. Vor allem Whitelists eignen sich zur
Bekämpfung von SPIT besonders. Sie sind jedoch ohne starke Identitäten wirkungslos. Außerdem bedürfen sie eines Verfahrens, die Liste mit neuen Einträgen automatisch zu
ergänzen.
Hierfür wird oft der Einsatz eines Turingtests angeregt. Um diesen Test durchzuführen,
fehlt es in den User Equipments (UEs) meist an Rechenleistung. Darüber hinaus konnte kein
Verfahren erarbeitet werden, das diese Aufgabe mit den Mitteln eines UE bewältigen kann.
Aus diesem Grund wird im Rahmen dieser Arbeit ein Konzept entworfen, das die Vertrauenswürdigkeit eines unbekannten Teilnehmers verifizieren kann. Damit dieses Konzept
in das Next Generation Telecommunication Factory (NextFactor)-Projekt problemlos integriert werden kann, werden einige Bedingungen definiert (vgl. Abschn. 6.1, S. 95). Auf Basis
dieser Anforderungen wird das Konzept entwickelt (vgl. Abschn. 6.2, S. 96) und im Rahmen einer Machbarkeitsstudie testweise realisiert (vgl. Abschn. 6.3, S. 98) und anschließend
Bewertet (vgl. Abschn. 6.4, S. 107).
Um die Übersichtlichkeit in den ab sofort dargestellten Sequenzdiagrammen zu wahren,
wird der Ablauf innerhalb des IMS nicht mehr detailiert dargestellt. Die interne Weiterleitung
der Nachrichten ist für das Verständnis dieses Konzeptes nicht weiter von Bedeutung.
6.1 Anforderungen
Für die Entwicklung und Umsetzung des Konzeptes werden drei Anforderungen definiert.
Ihr Ziel ist es z. B. eine mögliche Integration in das NextFactor-Projekt zu erleichtern. Die
95
Kapitel 6. Direct-IP-SPIT-Schutz
Entwürfe für das Konzept sowie dessen Implementierung müssen diese Bedingungen erfüllen.
Nachfolgend werden diese Anforderungen kurz erklärt:
• Kompatibilität: Das Konzept muss allgemein funktionsfähig sein. Somit dürfen keine
Anpassungen im anrufenden UA sowie im IMS nötig sein. Funktioniert das Konzept
nur, wenn der anrufende UA angepasst ist, wird ein Spammer einen konventionellen
UA einsetzen. Sind Änderungen im IMS nötig, kann das Konzept nur unter diesen
Netzen arbeiten.
• Open Source: Mit der Gründung des Masterprojekt Systementwicklung [Mas-2009]
wird auf Open Source-Systeme gesetzt. Diese Vorgehensweise wird mit dem Konzept
beibehalten. Open Source-Lizenzen sind jedoch nicht immer miteinander kompatibel.
Als Kern wird im Projekt der Open IMS Core [FHG-2009] genutzt.
• Demonstrierbarkeit: Das hier entwickelte Konzept soll für weitere Veröffentlichungen
genutzt werden und auf Fachveranstaltungen vorführbar sein. Daher ist es sinnvoll, eine
Plattform zu wählen, die problemlos transportiert werden kann.
6.2 Konzept
Auf Basis der Anforderungen wird in diesem Abschnitt das Konzept für eine Direct-IP-SPITAbwehr erarbeitet. Für die Entwicklung eines Konzeptes muss nur die Forderung nach einer
hohen Kompatibilität berücksichtigt werden, da hierfür weder eine konkrete Software noch
eine Plattform definiert wird.
Um einen effektiven Schutz gegen Direct-IP-SPIT zu erarbeiten, muss zunächst nachvollzogen werden, warum diese Art Spam so problematisch ist. Danach kann der Entwurf angefertigt
werden, der die analysierten Problemstellen anspricht.
6.2.1 Analyse
Trotz der vielen Möglichkeiten durch Sicherheitsverfahren und Abwehrmaßnahmen, kann
Direct-IP-SPIT nicht effektiv abgewehrt werden. Die meisten Verfahren werden im IMS bereitsgestellt. Dieses wird jedoch beim Direct-IP-SPIT umgangen. Somit muss SPIT nur mit
den Mitteln eines UE erkannt und unterbunden werden.
Ein Problem der meisten Ansätzen, ist der Mangel an Informationen im UA. Im UA
können unmöglich alle Informationen persistent gespeichert werden, die für eine qualifizierte
Bewertung des Anrufers nötig sind. Aus diesem Grund muss der UA mit einem Minimum an
Wissen eine Reaktion auf den Anruf generieren.
Dafür bleibt dem UA jedoch keine Zeit. Ein eingehender INVITE-Request wird in der
Regel sofort mit den beiden Responses 100 Trying und 180 Ringing beantwortet (vgl.
96
6.2. Konzept
Alice
INVITE
Bob
100 Trying
180 Ringing
200 OK
ACK
Abb. 6.1: Abfolge der Responses 100 Trying und 180 Ringing.
Abb. 6.1, S. 97). Das bedeutet, dass das UE direkt zu klingeln anfängt. Genau dieser Zustand
darf erst erreicht werden wenn sichergestellt ist, dass der Anrufer vertrauenswürdig ist.
Angenommen der UA hätte genügend Zeit, eine Untersuchung durchzuführen. Sofern keine
weiteren Abwehrmaßnahmen (z. B. Device Fingerprinting) vorhanden sind, kann der UA nur
die folgenden zwei Informationen zur Bewertung nutzen:
1. Der Teilnehmerkennung des Anrufers (z. B. der Session Initiation Protocol Uniform
Ressource Identifier (SIP URI)).
2. Der Betreibername des Anrufers (z. B. die Internet Protocol (IP)-Adresse oder der
URI).
Da der UA diese beiden Informationen nicht direkt verifizieren kann, muss er versuchen
herauszufinden, ob sie authentisch sind. An dieser Stelle tritt das zweite Problem vieler
Ansätze auf. Um diese Verifikation durchzuführen, stehen dem UA oft nur beschränkte
Leistungskapazitäten zur Verfügung.
Authentisch bedeutet in diesem Kontext, dass der Anrufer derjenige ist, für den er sich
ausgibt. Das ist aus zwei Gründen wichtig:
1. Angenommen der Anrufer ist wirklich beim angegebenen Betreiber registrierter Kunde.
Dann kann und wird der Betreiber selbst gegen den Spammer vorgehen.
2. Spammer verwenden gerade aus diesem Grund Direct-IP-SPIT. Auf diese Weise können
sie schwerer entdeckt werden und die Filterwahrscheinlichkeit ist geringer.
Das Ziel dieses Konzeptes muss demnach sein, die Echtheit des Anrufers zu überprüfen.
Um es zu erreichen, steht kein zusätzliches Wissen zu Verfügung. Die für die Validierung
benötigten Informationen müssen in der geringen vorhandenen Zeit ermittelt werden.
6.2.2 Entwurf
In diesem Abschnitt wird ein Entwurf entwickelt, der unter Nutzung der Teilnehmerkennung
und des Betreibernamens in der Lage ist, Direct-IP-SPIT abzuwehren.
97
Um dem UA Zeit zu verschaffen, eine Untersuchung durchzuführen, ist es notwendig das
Aussenden der beiden Responses voneinander zu trennen. Der UA kann zunächst einen
100 Trying-Response senden, um dem Anrufer mitzuteilen, dass sein Anruf eingegangen ist
und weitere Bearbeitungen durchgeführt werden. Somit hat der UA etwas Zeit, zur Verifikation. Ist die Identität des Anrufers bestätigt, kann ein 180 Ringing-Response ausgesendet
werden.
Alice
IMS
Bob
Anrufversuch
In Bearbeitung
Existiert Alice?
Antwort
Existiert Alice?
Antwort
Telefon klingelt
Anruf angenommen
Abb. 6.2: Konzeptionelle Änderung im Ablauf eines Direct-IP-Calls.
Bis dahin muss der UA in Erfahrung bringen, ob der Anrufer unter der angegebenen
Adresse tatsächlich beim angegebenen Betreiber registriert ist. Eine Liste mit registrierten
Teilnehmern zu speichern ist unmöglich, deshalb muss der UA die Existenz im akuten Fall
selbst ermitteln.
Angenommen der Betreiber kann die Existenz des Anrufers bestätigen, ist noch nicht
sichergestellt, dass der Anruf tatsächlich von diesem Teilnehmer kommt. Ein Kontaktversuch
über den temporären SIP URI ist nicht vielversprechend, da hierdurch zwar die Erreichbarkeit
bestätigt wird, nicht aber der Zusammenhang zum permanenten SIP URI. Deshalb kann
versucht werden, eine Nachricht an den permanenten SIP URI des Betreibers zu senden. Nach
Erhalt einer Rückmeldung kann die enthaltene Adresse im Contact-Header-Feld mit der aus
dem initialen Anruf verglichen werden. Stimmen beide überein, handelt es sich anscheinend
um einen beim angegebenen Betreiber registrierten Teilnehmer.
Wie bereits erwähnt, gewährleistet dieser Zusammenhang nicht, dass kein SPIT übertragen
wird. Das der Anrufer tatsächlich beim angegebenen Betreiber registriert ist, senkt nur die
Wahrscheinlichkeit, das SPIT versendet wird.
6.3 Machbarkeitsstudie
Bevor das Konzept umgesetzt werden kann, müssen die folgenden beiden Punkte weiter
konkretisiert werden:
98
6.3. Machbarkeitsstudie
1. Womit wird die Existenz des Anrufers beim Betreiber überprüft?
2. Womit wird die direkte Existenzüberprüfung des Anrufers durchgeführt?
Auf beide Fragestellungen wird im Laufe dieses Abschnitts eine Antwort erarbeitet. Sind
beide Schritte geklärt, kann die Implementierung des Konzeptes durchgeführt werden.
6.3.1 Existenz des Anrufers beim Betreiber überprüfen
Zunächst muss analysiert werden, mit welchen Mitteln die Existenz des Teilnehmers beim
angegebenen Betreiber überprüft werden kann. In Frage kommen Requests, Sonderfunktionen wie die Event Packages und weitere Entwicklungen und Standards. Das ausgewählte
Verfahren muss in der Lage sein, eine Antwort einzufordern. Anhand dieser Rückmeldung
wird anschließend versucht, die Existenz des Teilnehmers zu verifizieren.
Gegenwärtig existieren für das Session Initiation Protocol (SIP) insgesamt vierzehn verschiedene Requests-Arten. Einige dieser Nachrichten können nicht eingesetzt werden, da sie
entweder nicht beantwortet werden (z. B. ACK) oder im Abbruch der Verbindung enden
(z. B. CANCEL). Das Hauptproblem der meisten Requests ist, dass sie zum zugehörigen
Teilnehmer durchgestellt werden (z. B. MESSAGE) oder der Einsatz nicht standardkonform
ist (z. B. NOTIFY). Außerdem muss der Standard die Angabe des Contact-Header-Feldes
vorschreiben um an den benötigten temporären SIP URI zu gelangen. Das größte Potenzial bietet der SUBSCRIBE-Request, da dieser in der Regel vom IMS beantwortet wird. Die
Antwort auf einen SUBSCRIBE-Request muss das Contact-Header-Feld jedoch nur optional
enthalten (vgl. Tab. 2.1, S. 16). Der Standard schreibt bei einem erfolgreichen Abonnement
jedoch das sofortige Aussenden eines NOTIFY-Requests vor [RFC-3265, S. 14]. Im NOTIFYRequest muss wiederum das Contact-Header-Feld enthalten sein.
Zusammen mit einem Vorschlag der Internet Engineering Task Force (IETF) werden
zwei Event Packges ausgewählt, die Aufschluss über die Existenz des Anrufers ermitteln
können. Im Folgenden werden diese Ansätze genauer vorgestellt und auf ihre Anwendbarkeit
überprüft.
Presence Event Package
Das Presence Event Package [RFC-3856] ermöglicht die Veröffentlichung sowie Abfrage des aktuellen Presence-Status. Presence wird im Rahmen dieses Event Packages als
die Bereitwilligkeit zur Kommunikation mit anderen Teilnehmern definiert. Die PresenceFunktion ist im Instant Messaging (IM)-Bereich sehr verbreitet und in Form von Freundeslisten umgesetzt.
Ursprünglich wird bei der Presence nur zwischen Online“ und Offline“ unterschieden.
”
”
Mit der Zeit wurde eine feinere Granularität erreicht, sodass mittlerweile in der Regel Status
wie z. B. Abwesend“, Beschäftigt“ oder Unsichtbar“ unterstützt werden.
”
”
”
99
Um seinen Status dem Betreiber mitzuteilen, bieten sich dem Teilnehmer die folgenden
Möglichkeiten.
1. REGISTER-Request [RFC-3856, S. 16–17]: Im REGISTER-Request werden die aktuellen Presence-Informationen mitgesendet.
2. Presence-Dokument hochladen [RFC-3856, S. 17]: Der Teilnehmer kann seinen
Presence-Status selbst manipulieren. Wie dies geschieht, ist vom Betreiber abhängig.
Der konkrete Status des Anrufers ist für die Ermittlung im Rahmen des hier vorgestellten
Konzeptes weniger interessant. Doch kann über die Presence-Funktion herausgefunden werden, ob der Teilnehmer online ist. Diese Information darf jedoch nur optional ausgewertet
werden, da sie keine verbindliche Aussage über den tasächlichen Zustand trifft. Letzten Endes kann der Status Offline“ bedeuten, dass der Teilnehmer zwar online ist, dies aber nicht
”
angegeben hat oder das er sich als Unsichtbar“ eingetragen hat. Es ist jedoch denkbar, dem
”
Teilnehmer die Wahl zu lassen, wie streng diese Information bewertet wird.
Dialog Event Package
Das Dialog Event Package [RFC-4235] ermöglicht es anderen Teilnehmern Informationen
über die aktiven Dialogs eines weiteren Teilnehmers zu erhalten. Insbesondere betrifft
dies den INVITE-Dialog, es kann aber auf jede Art von Dialog (z. B. SUBSCRIBE-Dialog)
angewandt werden.
Durch den Einsatz dieses Event-Packages lassen sich diverse Komfortfunktionen realisieren.
Wenn ein Teilnehmer einen anderen nicht erreicht, da dieser momentan telefoniert, kann
das Dialog Event Package dazu eingesetzt werden, einen automatischen Rückruf einzuleiten.
Sobald der INVITE-Dialog des angerufenen Teilnehmers beendet ist, wird erneut versucht
eine Verbindung aufzubauen [RFC-4235, S. 3].
Das Abonnement kann sich auf einen bestimmten Dialog oder allgemein auf einen Teilnehmer beziehen [RFC-4235, S. 4–5]. Wird ein bestimmter Dialog abonniert, endet das Abonnement entweder mit diesem Dialog oder nach Ablauf einer angegebenen Dauer. Wird der
generelle Dialog-Status eines Teilnehmers abonniert, sollte keine zu lange Dauer angegeben
werden. Der Standard empfiehlt hier die Angabe einer Stunde [RFC-4235, S. 6].
Dialog Event for Identity Verification
Mit dem Dialog Event for Identity Verification (DERIVE)-Verfahren [Kut-2008] kann ein angerufener Teilnehmer über den Betreiber ermitteln, ob sich der potenzielle Anrufer wirklich
im Zustand
anrufend“ befindet. Dadurch lässt sich sicher Stellen, das der angegebe”
ne Teilnehmer dem Betreiber bekannt ist und das dieser gegenwärtig versucht einen Anruf
zu initiieren. Somit ermittelt dieses Verfahren eine zusätzliche Information, die Aufschluss
100
über die Korrektheit der Angaben geben kann. Diese Aufgabe wird unter Einsatz des Dialog
Event Package [RFC-4235] durchgeführt.
Alice
Bob
IMS
INVITE
100 Trying
SUBSCRIBE
200 OK
NOTIFY
200 OK
180 Ringing
200 OK
ACK
INVITE
100 Trying
INVITE-Dialog
(Teil 1)
SUBSCRIBE
200 OK
NOTIFY
SUBSCRIBEDialog
200 OK
180 Ringing
200 OK
INVITE-Dialog
(Teil 2)
ACK
Abb. 6.3: Ablauf eines verifizierten Anrufs mit DERIVE [Kut-2008, S. 5].
Erhält ein Teilnehmer einen Anruf versucht er zunächst herauszufinden, ob der potenzielle Anrufer im entsprechenden Zustand ist (vgl. Abb. 6.3, S. 101). Dazu sendet er einen
SUBSCRIBE-Request an diesen Teilnehmer. Daraufhin können drei Fälle eintreten:
1. Der Anruf wird verifiziert [Kut-2008, S. 9–12]: Bei einem verifizierten Anruf wird
der SUBSCRIBE-Request mit einem 200 OK-Response beantwortet. Im darauf eintreffenden NOTIFY-Request wird der Dialog-Status des Anrufers bestätigt.
2. Der Anruf kann nicht verifiziert werden [Kut-2008, S. 12–13]: Dann wird der
SUBSCRIBE-Request mit einem 489 Bad Event-Response abgelehnt. Da der Einsatz
des Event-Package optional ist, wird ohne Einsatz der DERIVE fortgefahren. Demzufolge wird der Anruf angenommen.
3. Der Anruf ist suspekt [Kut-2008, S. 14–15]: Dies ist z. B. der Fall, wenn der UA
des angeblich anrufenden Teilnehmers nicht im entsprechenden Zustand ist. Dann wird
der SUBSRIBE-Request mit einem 481 Call Does Not Exist-Response abgelehnt. Da
hier anzunehmen ist, dass der INVITE-Request von einem Angreifer kommt, wird er
mit einem 434 Suspicious Call-Response abgelehnt.
Dieses Verfahren ist zwar nicht für Direct-IP-SPIT konzipiert, jedoch dem hier vorgestellten
Konzept recht ähnlich. Es weißt jedoch eine essenzielle Schwachstelle auf. Der UA des
101
Anrufers muss das Dialog Event Package unterstützen. Hier widerspricht es einer der für die
hier vorgestellte Lösung aufgestellte Anforderungen. Um DERIVE einsetzen zu können, ist
bei beiden UAs ein Änderungsaufwand nötig.
Somit können keine Teilnehmer verifiziert werden, die dieses Event-Package nicht unterstützen. Problematisch ist es nur im folgenden Szenario (vgl. Abb. 6.4, S. 102):
Angreifer
Alice
Bob
IMS
INVITE
INVITE
SUBSCRIBE
489 Bad Event
200 OK
ACK
SUBSCRIBE
489 Bad Event
200 OK
ACK
Abb. 6.4: Erfolgreicher Angriff trotz DERIVE [Kut-2008, S. 15–16].
Ein Angreifer sendet einen INVITE-Request unter dem Namen Alice an den Zielteilnehmer.
Der UA des angeblichen Anrufers unterstützt das Event-Package jedoch nicht. Aus diesem
Grund wird der Anruf normal (ohne DERIVE) eingeleitet.
Einen solchen Teilnehmer zu finden erfordert wenig Aufwand, im einfachsten Fall ist dies
ein auf den Angreifer angemeldeter Account. Somit ist es für einen Angreifer sehr leicht
DERIVE zu umgehen.
6.3.2 Direkte Überprüfung der Existenz des Anrufers
Als nächstes muss überprüft werden, ob der anrufende Teilnehmer tatsächlich unter dem
angegebenen temporären SIP URI erreichbar ist. Dafür wird ein Request an diesen SIP URI
gesendet. Es ist völlig ausreichend, wenn der entsprechende Request einen Response produziert, um die Existenz zu bestätigen. Die Verwendung dieses Requests darf den Regelungen
der betreffenden Request for Commentss (RFCs) nicht wiedersprechen. Aus diesem Grund
kommen die folgenden Nachrichtentypen in Frage:
• INVITE: Wird bei einem eingehenden Direct-IP-Call ein INVITE ausgesendet, kann
die Korrektheit des Anrufers sehr direkt verifiziert werden. Dieses Vorgehen birgt jedoch einige Nachteile. Verwendet der Anrufer dieselbe Software, sendet sein UA ebenfalls einen INVITE-Request zur Verifikation, was zu einer Schleife führt. Andererseits
können Teilnehmer automatisch auf kostenpflichtige Rufnummern gelockt werden. Aus
diesen Gründen darf der INVITE-Request nicht eingesetzt werden.
102
• MESSAGE: Durch das Senden einer Nachricht mittels MESSAGE-Request tritt ein
ähnlicher Effekt wie beim INVITE-Request auf. Anstelle eines Anrufs erhält der Zielteilnehmer eine Nachricht. Wird vom Anrufer eine falsche Adresse angegeben, wird ein
unbeteiligter Dritter belästigt. Aus diesem Grund wird der MESSAGE-Request nicht
eingesetzt.
• OPTIONS: Beim Senden eines OPTIONS-Request tritt keine Störung beim Zielteilnehmer auf. Selbst wenn die Nachricht an einen Dritten gesendet wird, hat dies keinen
Effekt. Deshalb wird der OPTIONS-Request für die Beschaffung einer zweiten Kontaktadresse gewählt.
6.3.3 Entwicklungsumgebung
Für die Validierung des Anrufers wird das Presence Event Package und der OPTIONSRequest ausgewählt. Als Nächstes muss eine Umgebung gefunden werden, in der das Konzept
testweise realisiert werden kann. Dazu muss eine geeignete Entwicklungsumgebung gefunden
werden.
Die Entwicklungsumgebung umfasst mehrere Komponenten. Zunächst muss eine den Anforderungen entsprechende Plattform gefunden werden. Auf Basis dieser Plattform kann dann
eine VoIP-Software ausgewählt werden, in der das Konzept realisiert wird.
Entwicklungsplattform
Für eine Umsetzung des Konzepts stehen eine Vielzahl von Plattformen zur Verfügung. Aus
dieser Menge muss eine geeignete Plattform gewählt werden, die den Anforderungen gerecht wird. Zunächst betrifft dies die Forderung nach Open Source-Software. Es darf kein
Programmcode eingesetzt werden, der unter keiner GNU General Public License Version 2
(GPLv2)-konformen Lizenz steht.
Zunächst muss ein geeignetes UE ausgewählt werden. Für die Entwicklung im Rahmen
des NextFactor-Projektes kommen die folgenden Arten in Frage:
• Soft-Phone auf einem Computer: Für diesen Ansatz steht eine Vielzahl von Open
Source-Lösungen im Internet bereit. Zusätzlich wird gegenwärtig im Rahmen des Masterprojekt Systementwicklung ein solcher Client entwickelt. Dieser verfügt jedoch momentan nur über eine Basisfunktionalität.
• Soft-Phone auf einem Smartphone: Zur Erfüllung der Anforderungen Demons”
trierbarkeit“ eignet sich jedoch ein Smartphone deutlich besser als ein Computer. Aus
diesem Grund wird die Realisierung einer Lösung basierend auf Smartphones vorgezogen. Sie können leicht transportiert werden und somit gut für Demonstrationen eingesetzt werden.
103
Da jedoch die meisten Smartphones auf proprietärer Basis laufen, ist hier die Auswahl
einer Open Source-Lösung geringer. Gegenwärtig konnten fünf Open Source-Plattformen
für Smartphones ermittelt werden:
• Qt Extended [Tro-2009]: Qt Extended ist eine von der Nokia-Sparte Trolltech entwickelte Anwendungsplattform basierend auf Linux. Jedoch wurde die Weiterentwicklung
von Qt Extended am 5. März 2009 eingestellt [Nok-2009]. Qt Extendet ist zwar weiterhin verfügbar, wird jedoch nur noch ein Jahr lang gewartet. Aus diesem Grund wird
die Verwendung von Qt Extendet für die Entwicklung verworfen.
• Openmoko [Ope-2009]: Das Openmoko-Projekt entwickelt auf Basis eines selbstentwickelten Smartphones eine Open Source-Plattform. Hier sind zwei Dinge problematisch.
Zum einen läuft Openmoko nur auf einem speziellen Smartphone, das in Deutschland
nur als Import erhältlich ist. Zum anderen wurde die Entwicklung neuer Smartphones
in diesem Jahr eingefroren [Mos-2009, S. 20–24]. Somit kann Openmoko für nicht als
Plattform genutzt werden.
• Linux Mobile [LiM-2008]: Das Betriebssystem Linux Mobile (LiMo) wird aktuell von
der LiMo-Foundation gepflegt. Es basiert vollständig auf Open Source und erfüllt somit
die wichtigste Grundvoraussetzung. LiMo-basierte Handys sind in Europa jedoch erst
seit Kurzem erhältlich und noch sehr selten. Ein weiteres Problem ist, dass es für
die LiMo-Plattform bisher keinen SIP-Client gibt. Aus diesem Grund konnte diese
Plattform nicht weiter genutzt werden.
• Symbian OS [Sym-2009]: Die Nokia Firma Symbian hat mit Symbian OS ein Open
Source Betriebssystem unter der Eclipse-Lizenz [Ecl-2004] auf dem Markt. Obwohl
Symbian OS seit mehreren Jahren erhältlich ist, existiert gegenwärtig kein SIP-Client
mit Open Source-Lizenz. Symbian OS kann daher nicht als Entwicklungsplattform
verwendet werden.
• Android [OHA-2009a]: Das von der Open Handset Alliance veröffentlichte Betriebssystem Android ist somit die einzige Plattform, die gegenwertig über einen Open Source SIP-Client verfügt. Da mehrere global tätige Telekommunikationskonzerne Mitglied
[OHA-2009b] in dieser Allianz sind, werden zukünftig voraussichtlich viele Smartphone
mit Android ausgestattet sein. Aus diesen beiden Gründen und aufgrund der Erfüllung
der Anforderungen wird für die Machbarkeitsstudie Android als Entwicklungsplattform
eingesetzt.
Client
Nachdem als Entwicklungsplattform das Betriebssystem Android ausgewählt ist, muss nun
ein SIP-Client bestimmt werden. Android selbst verfügt standardgemäß über keinen eigenen
SIP-Client. Aus diesem Grund muss eine externe Software installiert werden.
104
Gegenwärtig existiert nur ein einziger Open Source SIP-Client für die Android-Plattform.
Somit wird für die Erstellung der Machbarkeitsstudie das Projekt Sipdroid [HSC-2009] von
der Firma Hughes Systique Corporation (HSC) ausgewählt. Sipdroid basiert auf der GNU
General Public License Version 3 (GPLv3). Da die GPLv3 mit der GPLv2 kompatibel ist,
kann Sipdroid ohne Konflikt eingesetzt werden.
6.3.4 Umsetzung
Das Konzept realisiert die Validierung des Anrufers über zwei Schritte. Zunächst wird die
Existenz der Anruferdaten beim Betreiber ermittelt. Anschließend wird die Korrektheit dieser
Angaben über einen Nachrichtenaustausch verifiziert. Zusätzlich mit der zeitlichen Trennung
des Statuscodes 100 Trying und 180 Ringing ergeben sich drei zu realisierende Aufgaben.
Diese werden wie folgt realisiert (vgl. Abb. 6.5, S. 105):
Alice
IMS
Bob
INVITE
100 Trying
INVITE-Dialog
Teil 1
SUBSCRIBE
200 OK
NOTIFY
SUBSCRIBEDialog
200 OK
OPTIONS
486 Busy / 200 OK
OPTIONSTransaction
180 Ringing
200 OK
INVITE-Dialog
Teil 2
ACK
Abb. 6.5: Implementierte Änderung im Ablauf eines Direct-IP-Calls.
1. Zeitliche Trennung vom Statuscode 100 Trying und 180 Ringing: Eine Trennung der beiden Statuscodes ist sehr leicht zu realisieren. Um den UA des Anrufers über
die Bearbeitung der Nachricht zu informieren, wird vor der Überprüfung der Response
100 Trying gesendet (vgl. Abb. 6.5, S. 105). Wird der Anruf als SPIT-frei erkannt,
sendet der UA den Response 180 Ringing.
2. Existenz des Anrufers beim Betreiber überprüfen: Um die Existenz des angegebenen Teilnehmers beim Betreiber zu ermitteln, wird das Presence Event Package ausgewählt. Zur Ermittlung der Existenz des Teilnehmers wird ein SUBSCRIBE-Request
105
auf das Presence-Event an das IMS des angegebenen Betreibers gesendet. Da kein dauerhaftes Interesse an diesem Event besteht, wird der Wert des Header-Feldes Expires
auf 0 gesetzt (vgl. Notation 6.1, S. 106). Dadurch wird bewirkt, dass nur eine Antwort
mit dem gegenwärtigen Presence-Status generiert wird [RFC-3856, S. 6].
SUBSCRIBE sip : alice@atlanta . com SIP /2.0
Event : presence
Expires : 0
[...]
Notation 6.1: SUBSCRIBE-Request an den Presence-Server des Anrufers.
Wird der SUBSCRIBE-Request mit einem 200 OK-Response beantwortet, bestätigt
dies bereits die Existenz des SIP URI beim Betreiber. Trotzdem muss auf das Eintreffen
des NOTIFY-Requests gewartet werden, da dieser das Contact-Header-Feld beinhaltet.
Der Betreiber ist jedoch nicht gezwungen, hier die Kontaktadresse des Teilnehmers zu
hinterlegen. Alternativ kann hier z. B. die Kontaktmöglichkeit zum Betreiber stehen.
Ist dies der Fall, sollte die Validierung abgebrochen werden, da ein korrekter Zusammenhang zwischen permanentem und temporärem SIP URI nicht mehr gewährleistet
werden kann. Dies kann jedoch in der jeweiligen Implementierung individuell abgewägt
und entschieden werden. Außer dem Contact-Header-Feld beinhaltet der NOTIFYRequest den Subscription-State“ des Teilnehmers (vgl. Notation 6.2, S. 106). Dieser
”
gibt bereits an, ob der Teilnehmer online ist oder nicht. Alternativ kann die Presence
Information Data Format (PIDF)-Datei im Body ausgewertet werden. Hier wird jedoch
nur die Existenz des Teilnehmers ermittelt.
NOTIFY sip : bob@192 .0.2.194 SIP /2.0
Subscription - State : active ; expires =0
Contact : Alice@192 .0.2.65
Content - Type : application / pidf + xml
[...]
Notation 6.2: NOTIFY-Request vom Presence-Server des Anrufers.
3. Korrektheit der angegebenen Adresse überprüfen: Wird die Existenz des Anrufers durch das Presence Event Package verifiziert, muss als Nächstes ein OPTIONSRequest an den temporären SIP URI des Teilnehmers gesendet werden. Der RFC
schreibt vor, dass ein OPTIONS-Request genauso beantwortet wird wie ein INVITERequest [RFC-3261, S. 68]. Demzufolge können zwei verschiedene Antworten die Nachricht bestätigen. Normalerweise wird ein 486 Busy Here-Response zurückgesendet, da
106
6.4. Bewertung
der UA gegenwärtig in einen Verbindungsaufbau verwickelt ist. Da einige UAs mehrere
Telefonleitungen zur Verfügung stellen, kann genauso ein 200 OK-Response eintreffen,
da die zweite Telefonleitung unbelegt sein kann. Da nicht immer davon auszugehen
ist, dass das SIP RFC-konform implementiert ist, können auf weitere Responses zur
Bestätigung akzeptiert werden (z. B. jeder 2xx-Response).
Anschließend kann der 180 Ringing-Response gesendet werden und das Telefon anfangen zu klingeln. Die restliche Bearbeitung des INVITE-Dialogs bleibt vom Standard
unverändert.
Kann das Presence Event Package nicht abonniert werden oder wird der OPTIONSRequest nicht korrekt beantwortet, sendet Sipdroid den Response 434 Suspicious Call
an den UA des Anrufers. Durch diese Nachricht wird zum Ausdruck gebracht, dass die Angaben des Anrufers nicht korrekt überprüft werden konnten.
6.4 Bewertung
In diesem Abschnitt wird das Konzept bewertet. Einerseits ergibt sich die Frage nach der
Performance. Der Prototyp ist zwar in der Lage einen Anrufer zu verifizieren, dies braucht
jedoch seine Zeit. Inwieweit dieser Zeitaufwand ins Gewicht fällt, wird in diesem Abschnitt
beschrieben. Ein funktionierender Prototyp ist nicht ausreichend, um die Unternehmen in
der Wirtschaft zu überzeugen, ihn einzusetzen. Aus diesem Grund werden im Anschluss
Umstänge aufgelistet, die eine Einführung dieses Konzeptes rechtfertigen. Abschließend wird
betrachtet, inwiefern das Konzept von Angreifern ausgenutzt werden kann.
6.4.1 Performance
Um Aussagen über die Performance des Prototyps treffen zu können, wurden zwei Testreihen mit je 100 Anrufen durchgeführt. Diese Anrufe wurden auf je einen Prototyp mit
aktiviertem und deaktiviertem Direct-IP-SPIT-Schutz gemessen. Es wurde die Zeit ermittelt, die der Client benötigt um nach dem Eingang des ersten INVITE-Requests eine positive
Antwort zu generieren. Eine positive Antwort ist das Senden eines 180 Ringing-Response.
Zur Durchführung der Tests wurde der Android-Emulator genutzt. Dieser lief auf eiR CoreTM 2 Duo T5450-Prozessor mit 1,66 GHz, 2048 MBnem Testsystem mit Intel
Arbeitsspeicher, 100 MB-Ethernetanschluss und 6 MB-Internetanschluss. Die Tests wurden
mit zwei Accounts bei einem amerikanischen Voice over IP (VoIP)-Anbieter durchgeführt,
dessen Proxy in Denver steht. Durch diese Entfernung sind in jeder Nachricht an den Betreiber rund 0,200 s Übertragungsdauer enthalten. Die Zeiten wurden um 12:00 Uhr deutscher
Zeit und somit zu einer Ruhezeit (4:00 Uhr amerikanische Zeit) des amerikanischen Proxys
ermittelt.
107
Ohne Schutz
s
6,
00
0
s
5,
00
0
s
4,
00
0
s
3,
00
0
s
2,
00
0
s
00
0
1,
0,
00
0
s
Mit Schutz
Abb. 6.6: Boxplot der Messergebnisse.
xmin
x̃0.25
xmed
x̃0.75
xmax
Ohne Schutz
2,405 s
2,531 s
2,837 s
3,000 s
3,538 s
Mit Schutz
4,759 s
5,016 s
5,186 s
5,417 s
6,003 s
Tab. 6.1: Fünf-Punkte-Zusammenfassung.
Zunächst erfolgt die Interpretation der Fünf-Punkte-Zusammenfassung (vgl. Tab. 6.1,
S. 108). Zur besseren Veranschaulichung werden diese Werte in einen Boxplot übertragen (vgl.
Abb. 6.6, S. 108). Offensichtlich sind bei der Messung einige Ausreißer entstanden. Das äußert
sich im großen Abstand zwischen dem oberen Quartil x̃0.75 und dem oberen Whisker xmax .
Außerdem zeigt der hohe Median xmed bei der Messung ohne Schutz an, dass die Werte leicht
linksschief sind. Demnach sind mehr Messungen hoch als umgekehrt. Bei der Messung mit
Schutz zeigt sich ein gegenteiliges Bild. Hier ist sie leicht rechtsschief, die Verarbeitung wird
ergo eher schneller als langsam durchgeführt.
Ohne Schutz
s
0
6,
00
s
5,
00
0
s
4,
00
0
s
3,
0
00
s
0
2,
00
s
00
0
1,
0,
00
0
s
Mit Schutz
Abb. 6.7: Boxplot der Messergebnisse bis zum 90 % Perzentil.
Eine genauere Betrachtung des Bereichs zwischen oberes Quartil und oberer Whisker lohnt
sich. Dieser Bereich ist auffällig groß, was bereits zur Vermutung von Ausreißern geführt hat.
Bei großen Betreibern wird aus diesem Grund anstelle des Maximum das 80 %-, 90 %und 95 %Perzentil gefordert (vgl. Tab. 6.2, S. 109). Werden diese Perzentile berechnet und
eingesetzt bestätigt sich die Vermutung (vgl. Abb. 6.7, S. 108). Hierbei wurden das 80 % und
das 95 % Perzentil als Punkt eingezeichnet.
Nach dieser Betrachtung ergibt sich die Frage nach der Streuung. Da der Wert der empirischen Varianz s2 nicht dasselbe Vorzeichen hat, wie die vorliegenden Messwerte, wird hier
die Standardabweichung s betrachtet (vgl. Tab. 6.3, S. 109). Es wird deutlich, dass beide
108
6.4. Bewertung
80 %
90 %
95 %
Ohne Schutz
3,058 s
3,266 s
3,316 s
Mit Schutz
5,474 s
5,590 s
5,806 s
Tab. 6.2: Zusätzliche Perzentilen der Messergebnisse.
Ohne Schutz
5,
s
00
6,
0
00
00
4,
0
s
s
0
s
0
00
3,
2,
00
0
s
s
0
00
1,
0,
00
0
s
Mit Schutz
Abb. 6.8: Standardabweichung um das arithmetische Mittel.
Messreihen nahezu gleich wenig streuen. Diese Feststellung verdeutlicht sich in der visuellen
Darstellung mittels Fehlerbalken (vgl. Abb. 6.8, S. 109).
Die geringe Streuung lässt ein erwartungsgerechtes Messergebnis vermuten. Um diese Annahme zu bestätigen, wird das Konfidenzintervall berechnet. Das Konfidenzintervall gibt
an, in welchem Bereich um das arithmetische Mittel der Erwartungswert µ mit einer bestimmten Wahrscheinlichkeit α (Konfidenzniveau) liegt. Im Rahmen dieser Arbeit wird das
Konfidenzintervall für Konfidenzniveau von 0,95 % ermittelt (vgl. Tab. 6.4, S. 110).
Offensichtlich befindet sich das Konfidenzintervall ± 0,050 s um das arithmetische Mittel.
Wie nun sehr schön erkannt werden kann (farbig markierter Bereich), ist dieses Intervall
unter Einsatz des Direct-IP-SPIT-Schutzes nicht signifikant größer als ohne diesen Schutz
(vgl. Abb. 6.9, S. 110). Im Mittel handelt es sich bei beiden Messungen um ein Intervall
von rund 0,116 s Länge. Somit ist klar, dass der Einsatz des Direct-IP-SPIT-Schutzes den
Erwartungswert nur verschiebt, aber nicht vergrößert.
Abschließend lässt sich sagen, dass die Aktivierung des Direct-IP-Schutzes im Client nur
eine additive Erhöhung der Verarbeitungsdauer nach sich zieht. Nach rund drei Sekunden
mehr hat der Prototyp den Anrufer verifiziert. Wird berücksichtigt, dass der Proxy in Denver
steht, handelt es sich bei dieser Implementierung um eine sehr effiziente Lösung. Dabei leidet
x̄
s
s2
Ohne Schutz
2,821 s
0,289 s
0,083 s2
Mit Schutz
5,240 s
0,296 s
0,087 s2
Tab. 6.3: Arithmetisches Mittel, Standardabweichung und empirische Varianz.
109
24 x
20 x
16 x
12 x
8x
s
0
6,
5,
5
5,
0
s
s
s
4,
0
4,
5
s
s
5
3,
s
0
3,
2,
5
s
4x
Abb. 6.9: Konfidenzintervall beider Messungen.
L
x̄
U
Ohne Schutz
2,764 s
2,821 s
2,879 s
Mit Schutz
5,181 s
5,240 s
5,298 s
Tab. 6.4: Konfidenzintervall zum Konfidenzniveau 95 %.
die Stabilität von Sipdroid nicht unter diesem Konzept. Dieses ist genauso streuungsarm wie
Sipdroid selbst.
6.4.2 Akzeptanz
Das hier vorgestellte Konzept sorgt für eine Reduzierung des Direct-IP-SPIT-Eingangs. Der
beste Schutz ist natürlich ein generelles Verbot von Direct-IP-Call. Wird sie erlaubt, kann
dies ein Wettbewerbsvorteil für den Anbieter sein. Für eine Akzeptanz in der Praxis, muss
es jedoch zusätzlich wirtschaftlich sein.
Dieser Schutz erwirtschaftet jedoch keinen direkten Gewinn. Ein finanzieller Vorteil lässt
sich hier nur indirekt zuordnen. Hierbei können verschiedene Gesichtspunkte berücksichtigt
werden [ITU-2008, S. 13–14], die je nach Einsatzgebiet unterschiedlich schwer wiegen.
Als unmittelbarer Schaden tritt der Verlust durch Betrug oder illegalen Aktivitäten
im Allgemeinen auf. Gibt ein Teilnehmer seine Bankdaten an einen Spammer weiter, weil er
110
6.4. Bewertung
durch einen Vishing-Anruf getäuscht wird, ist in der Regel ein direkter Geldverlust die Folge.
Entdeckt der Teilnehmer den Betrug nicht, kann der Ruf des Unternehmens darunter leiden.
Liegt ein Betrugsfall oder etwas Ähnliches vor, fallen in der Regel Anwalts- bis Gerichtskosten an. Wird SPIT unterbunden, können diese Kosten gänzlich vermieden werden.
Die Kosten für die Infrastruktur können mit diesem Ansatz gesenkt werden. Erlaubt
der Betreiber Direct-IP-Calls und ermöglicht somit Direct-IP-SPIT, gehen die Anrufer nicht
mehr durch sein Netz. Somit entfallen die Kosten für die Vermittlung, Übertragung und
Filterung. Die Kosten werden effektiv auf den Kunden ausgelagert. Es verbleiben nur die
Kosten für die Verarbeitung des SUBSCRIBE-Requests.
Gerade wenn die Kosten der Filterung usw. auf den Kunden übertragen werden, ist es für
den Betreiber äußerst wichtig einen SPIT-Schutz zu bieten. Tritt zu viel SPIT auf, kann dies
zu einem Wettbewerbsnachteil (z. B. Rufverlust) für den Betreiber führen.
Mit einem Blick auf empirische Untersuchungen (vgl. Abb. 6.10, S. 111) zeigt sich, dass
die weit größten Kosten der drohende Produktivitätsverlust sind. Demnach werden die
weltweiten Kosten für Spam im Jahr 2009 auf ungefähr 130 Mrd. $ prognostiziert [Jen-2009].
85 % dieser Kosten und somit 110,5 Mrd. $ resultieren aus dem Produktivitätsverlust. Diese
Kosten können in der Zukunft weiter steigen. Zum Vergleich betrugen die Gesamtkosten für
Spam vor vier Jahren 50 Mrd. $ [Fer-2005, S. 6].
10 %
5%
Produktivitätsverlust
Kosten für den Help Desk
Soft- und Hardwarekosten
85 %
Abb. 6.10: Verteilung der Spamkosten für das Jahr 2009 [Jen-2009].
Darüber hinaus, gibt es gegenwärtig der Europäischen Union (EU) oder in der Bundesrepublik kein explizites Anti-Spam-Gesetz. Wird ein derartiges Gesetz eingeführt, können
die ISP dazu verpflichtet werden, für Schutzmaßnahmen zu sorgen.
6.4.3 Sicherheit
Die Arbeitsweise des Prototyps kann durch einen Angreifer negativ ausgenutzt werden. Beispielsweise kann er mehrere INVITE-Requests aussenden und somit einen Denial of Service
(DoS) auslösen. Der angegebene Name ist gefälscht, jedoch einem existierenden Teilnehmer
zugeordnet und registriert. Dadurch werden alle UAs zunächst viele SUBSCRIBE-Requests
an das IMS und anschließend OPTIONS-Requests an den angegebenen Teilnehmer senden.
Der wahre Angreifer bleibt unerkannt, da er die Prototypen als Relay benutzt.
111
Der Prototyp selbst kann gegen diese DoS-Angriffe nichts unternehmen, derselbe Request
geht doppelt ein. In solch einem Fall kann der Prototyp eine erneute Bearbeitung ausschließen. Ansonsten ließe sich nur betreiberseitig eine Abwehr realisieren. Durch den Einsatz von
Intrusion Detection kann das unnatürlich hohe Aufkommen an SUBSCRIBE-Requests auf
einen Presence-Status erkannt und blockiert werden. Da der Prototyp keine positive Antwort
vom IMS erhält, lehnt er den Anruf ab, ohne den OPTIONS-Request auszusenden.
6.5 Zusammenfassung
Um Direct-IP-SPIT abwehren zu können, musste ein Konzept entwickelt werden, das die
Echtheit des SIP URI überprüfen kann. Durch diesen Schritt kann verhindert werden, dass
Spammer ihre Identitäten beim Versand des SPIT verschleiern. Ohne verschleierte Identität,
so die Annahme, neigen Spammer weniger zum Versand von SPIT.
Die Idee für das Konzept war, die angegebene Identität über nur zwei Nachrichtenwechsel zu verifizieren. Einerseits wird beim Betreiber die Existenz des angeblichen Anrufers
überprüft, andererseits wird eine Nachricht zum angegebenen Anrufer gesendet.
Um das Konzept zu testen, wurde eine Machbarkeitsstudie entwickelt. Aufgrund verschiedener Anforderungen ist hierfür das Smartphone-Betriebssystem Android und der SIPClient Sipdroid ausgewählt worden.
Für die Überprüfung des Teilnehmers beim Betreiber wurde das Presence Event Package
genutzt. Dieses Event teilt Sipdroid bei einem erfolgreichen Abonnement den Status und
somit die Existenz des Teilnehmers mit. Um eine Nachricht zum angeblichen Anrufer zu senden, wird ein OPTIONS-Request gesendet. Werden alle Nachrichten erfolgreich ausgetauscht,
gilt der Anrufer als valide und wird angenommen. Ab diesem Punkt darf das Endgerät des
angerufenen Teilnehmers anfangen zu klingeln.
Die mit diesem Prototyp durchgeführte Analyse hat gezeigt, dass dieses Verfahren nur
einen additiven Faktor für die Verarbeitungsdauer bedeutet. Nach drei Sekunden ist mit
einer positiven Antwort zu rechnen. Bei diesem Wert sind rund 0,400 s Übetragungsdauer
für zwei Nachrichten nach und von Denver enthalten.
Der beste Schutz gegen Direct-IP-SPIT ist nach wie vor, das Verbot von Direct-IP-Calls.
Will der Betreiber seinen Kunden diesen Service trotzdem bieten, ist der vermiedene Produktivitätsverlust durch den Schutz der finanziell größte Bonus. Daher lohnt sich der
Einsatz dieses Konzeptes für die Betreiber und Endkunden.
Dank des in diesem Kapitel vorgestellten Konzeptes kann der Anrufer ohne große Rechenleistung verifiziert werden. Um dieses Verfahren effektiv einzusetzen, muss der Betreiber
jedoch starke Identitäten sicher stellen. Ist dies nicht der Fall, ist das hier vorgestellte Konzept
wirkungslos.
112
Kapitel
7
Zusammenfassung
Spam over Internet Telephony (SPIT) ist eine ernste Bedrohung für den Voice over IP (VoIP)Dienst. Da die Belästigung deutlich höher ist, als beim herkömmlichen E-Mail-Spam, müssen
Gegenmaßnahmen ergriffen werden. Dafür gilt es, zunächst die Funktionsweise des SPIT zu
verstehen.
Um SPIT durchführen zu können, ist der Spammer darauf angewiesen valide Adressen zu sammeln. Dieser Schritt betrifft das IMS zwar nicht direkt, kann jedoch bei der
SPIT-Bekämpfung nicht außer acht gelassen werden. Aus diesem Grund werden präventive
Abwehrmaßnahmen vorgestellt. Wird verhindert, dass der Spammer valide Adressen erhält,
wird somit das SPIT-Aufkommen generell reduziert.
Da nicht davon auszugehen ist, dass Spammer durch diese Maßnahmen an gar keine Adressen mehr gelangen, ist eine zusätzliche Abwehr des gesendeten SPIT notwendig. Das
Filtern des Nachrichteninhalts erweist sich bei SPIT jedoch als nutzlos. Eine Filterung ist
erst möglich, nachdem das Telefon des Opfers geklingelt und dieser abgenommen hat. Das
Klingeln des Endgerätes ist jedoch zu verhindern.
Aus diesem Grund werden identitätsbasierte und interaktive Abwehrmaßnahmen beschrieben. Die identitätsbasierten Maßnahmen können hierbei für eine rechenleistungsschonende
Vorsortierung der Anrufe dienen. Die übrig gebliebenen unklaren Anrufe können anschließend einem interaktiven Verfahren unterzogen werden. Insbesondere die Kombination aus
Whitelists und Turingtests erweist sich hier als besonders effizient.
Damit diese Maßnahmen aussagekräftig und somit wirksam sind, muss das IMS für starke
Identitäten sorgen. Wenn der Spammer in der Lage ist, beliebige Absendeadressen anzugeben, kann er somit leicht diese Verfahren umgehen.
Um starke Identitäten zu gewähren, bietet das IMS verschiedene Sicherheitsverfahren.
Jeder Teilnehmer, der sich am IMS registriert, muss mindestens mittels HTTP Digest Authentication verifiziert werden. Um das Erspähen von ausgetauschten Identitätsdaten zu verhindern, empfiehlt sich darüber hinaus der Einsatz weiterer Verfahren. Die Nutzdaten können
113
Kapitel 7. Zusammenfassung
beispielsweise durch den Einsatz von Session Initiation Protocols (SIPs) vor dem Mitlesen
geschützt werden.
Die problematischste Bedrohung ist jedoch der Einsatz von Direct-IP-SPIT. Dieser
ist seitens der Betreiber nicht abzuwehren, da die Nachrichten zwischen den Endgeräten
direkt ausgetauscht werden. Die einzige Möglichkeit besteht darin, direkte Anrufe generell zu
unterbinden. Für den Endkunden ist sicherlich der Einsatz einer speziellen Abwehrmaßnahme
angenehmer.
Aus diesem Grund wird ein Konzept beschrieben, das clientseitig für einen SPIT-Schutz
sorgt. Durch zwei Nachrichtenwechsel versucht es, die Identität des Anrufers zu verifizieren.
Die Annahme dahinter ist, dass Spammer Direct-IP-SPIT einsetzen, weil sie keinen validen
Account haben, um nicht entdeckt werden zu können. Doch kann das Konzept nur eingesetzt
werden, wenn die Betreiber starke Identitäten sicherstellen können. Ist dies nicht der Fall,
bringen die gesammelten Informationen keinen Mehrwert. Der Spammer bräuchte nur falsche
Identitätsdaten vortäuschen, um den Schutz zu umgehen.
7.1 Fazit
Werden alle Ansätze verfolgt, kann das Aufkommen von SPIT deutlich reduziert werden
(vgl. Abb. 7.1, S. 114). Selbstverständlich ist die Behauptung, SPIT wird dadurch gänzlich
verschwinden, zu weit gegriffen. Ein 100%iger Schutz gegen SPIT wird es vermutlich analog
zum E-Mail-Spam nie geben. Das liegt an mehreren Gründen:
1. Es darf zu keinen falschen Positiven kommen.
2. Es liegt im Voraus kein Wissen über den Inhalt der Nachricht vor.
3. Spammer werden aufgrund schlechter Passwörter und Ähnlichem immer in der Lage
sein, Botnetze usw. einzusetzen.
Spammer
Gesamtes SPIT
Abwehrmaßnahmen
SPIT mit falscher Identität
Sicherheitsmaßnahmen
Verbleibendes SPIT
Opfer
Abb. 7.1: Reduktion von SPIT via Proxy.
114
7.2. Ausblick
Eine Reduzierung des Aufkommens ist bereits ein wichtiger Schritt. Je weniger SPIT durchgestellt wird, je weniger attraktiv wird das Medium VoIP für Spammer.
Da der Einsatz von Direct-IP-SPIT alle serverseitigen Abwehrmaßnahmen umgeht, ist
diese Form des Spams besonders kritisch. Das für dieses Problem entwickelte Konzept bietet
einen ersten Schutz. In Kombination mit Whitelists und starken Identitäten kann hiermit
von vertrauenswürdigen Anrufern ausgegangen werden.
Die Betreiber der IMS dürfen jedoch nicht warten, bis SPIT ein Massenproblem
wird. Um es wirklich einzudämmen, muss jetzt gehandelt werden.
7.2 Ausblick
Durch die Umsetzung des Konzeptes ist ein erster Schutz vor Direct-IP-SPIT möglich. Dieser
Mechanismus ist jedoch weiter ausbaufähig.
Bisher setzt der Prototyp keine Whitelists ein. Eine derartige Erweiterung ist jedoch sehr
wichtig, da Whitelists eine sehr gute Vorfilterung liefern. Hierdurch kann auf den Einsatz des
Direct-IP-SPIT-Schutzes verzichtet werden, was die Aufbauphase um rund drei Sekunden
beschleunigt. Diese Vorfilterung kann selbstverständlich nur erfolgen, wenn starke Identitäten
garantiert sind.
Außerdem ist denkbar, das Dialog Event Package zu implementieren, um dem Nutzer
eine Auswahl zu ermöglichen. Alternativ kann auf diese Verfahren gewechselt werden, falls
das Presence Event Package nicht unterstützt wird.
Ein Problem für das Konzept ist der Anruf eines anonymen Teilnehmers. Ruft ein
Teilnehmer anonym an, wird er in jedem Fall abgewehrt. Da das UE nicht verpflichtet ist,
anonyme Anrufe zu verarbeiten, ist dies prinzipiell kein Problem [RFC-5079, S. 2]. Dem
Anrufer kann dies mit einem 433 Anonymity Disallowed-Response signalisiert werden. Um
dem Anwender von Sipdroid die Wahl zu lassen, kann der Schutz parametrisiert werden.
Dann können jedoch ebenso Spammer den Schutz umgehen, indem sie anonym anrufen.
115
Kapitel 7. Zusammenfassung
116
Abkürzungsverzeichnis
AH
Authentication Header.
AKA
Authentication and Key Agreement.
AS
Application Server.
AUTN
Authentication Token.
B2BUA
Back to Back User Agent.
BCC
Blind Carbon Copy.
BSI
Bundesamt für Sicherheit in der Informationstechnik.
CAPTCHA
Completely Automated Public Turing Test to Tell Computers and Humans Apart.
CK
Cipher Key.
CPT
Conditional Probability Table.
CSCF
Call Session Control Function.
117
Glossary
DERIVE
Dialog Event for Identity Verification.
DNS
Domain Name Service.
DoS
Denial of Service.
ENUM
E.164 Number Mapping.
ESP
Encapsulating Security Payload.
EU
Europäischen Union.
GPLv2
GNU General Public License Version 2.
GPLv3
GNU General Public License Version 3.
GPRS
General Packet Radio Service.
GSM
Global System for Mobile Communications.
HSC
Hughes Systique Corporation.
HSS
Home Subscriber Server.
HTML
Hypertext Markup Language.
HTTP
Hypertext Transport Protocol.
HTTPS
Hypertext Transport Protocol Security.
118
Glossary
I-CSCF
Interrogating Call Session Control Function.
IANA
Internet Assigned Numbers Authority.
IETF
Internet Engineering Task Force.
IK
Integrity Key.
IM
Instant Messaging.
IMC
IMS Credentials.
IMPI
IP Multimedia Private User Identity.
IMPU
IP Multimedia Public User Identity.
IMS
IP Multimedia Subsystem.
IP
Internet Protocol.
IPsec
Internet Protocol Security.
IPv4
Internet Protocol Version 4.
IPv6
Internet Protocol Version 6.
ISDN
Integrated Service Digital Network.
ISIM
IP Multimedia Services Identity Module.
ISP
Internet Service Provider.
119
Glossary
ITU-T
International Telecommunication Union - Telecommunication Standardization Sector.
KI
Künstlichen Intelligenz.
KMU
kleinere und mittlere Unternehmen.
LiMo
Linux Mobile.
MD5
Message Digest 5.
NAI
Network Access Identifier.
NextFactor
Next Generation Telecommunication Factory.
NFC
Near Field Communication.
NGN
Next Generation Network.
NIST
National Institute of Standards and Technology.
OCR
Optical Character Recognition.
OSI
Open Systems Interconnection.
P-CSCF
Proxy Call Session Control Function.
PIDF
Presence Information Data Format.
PKI
Public-Key-Infrastruktur.
120
Glossary
PSTN
Public Switched Telephone Network.
QoS
Quality of Service.
RAND
Random Challenge.
RES
Response.
RFC
Request for Comments.
RTP
Real-time Transport Protocol.
S-CSCF
Serving Call Session Control Function.
S/MIME
Secure/Multipurpose Internet Mail Extensions.
SA
Sicherheitsassoziationen.
SCTP
Session Control Transmission Protocol.
SDP
Session Description Protocol.
SHA-1
Secure Hash Algorithm 1.
SHA-3
Secure Hash Algorithm 3.
SIM
Subscriber Identity Module.
SIP
Session Initiation Protocol.
121
Glossary
SIP URI
Session Initiation Protocol Uniform Ressource Identifier.
SIPS
Session Initiation Protocol Security.
SIPS URI
Session Initiation Protocol Security Uniform Ressource Identifier.
SLF
Subscription Locator Function.
R
SPAM
R
Spiced Ham.
SPI
Security Parameter Index.
SPIM
Spam over Instant Messaging.
SPIT
Spam over Internet Telephony.
SPPP
Spam over Presence Protocol.
SQN
Sequence Number.
TCP
Transmission Control Protocol.
THIG
Topology Hiding Inter-network Gateway.
TLS
Transport Layer Security.
TTCN-3
Testing and Test Control Notation Version 3.
TTL
Time to Live.
122
Glossary
UA
User Agent.
UAC
User Agent Client.
UAS
User Agent Server.
UCE
Unsolicited Commercial E-Mail.
UDP
User Datagram Protocol.
UE
User Equipment.
UICC
Universal Integrated Circuit Card.
URI
Uniform Ressource Identifier.
USIM
Universal Mobile Telecommunications System Subscriber Identity Module.
VoIP
Voice over IP.
VPN
Virtual Private Network.
W-LAN
Wireless Local Area Network.
XRES
Expected Response.
123
Glossary
124
[3GP-2009] 3rd Generation Partnership Project: TS 45.-series specifications. http:
//www.3gpp.org/ftp/Specs/html-info/45-series.htm, zuletzt besucht am
30. 09. 2009.
[Aba-2003] Abadi, Martı́n et al.: Bankable Postage for Network Services. In: Advances in
Computing Science – ASIAN 2003 Bd. 2896/2003, Springer, 2003, S. 72–90
[Ahn-2003] Ahn, Luis von et al.: CAPTCHA: Using Hard AI Problems For Security. In: In
Proceedings of Eurocrypt 2003 Bd. 2656, 2003, S. 294–311
[Aud-2008] Audet, Francois: The use of the SIPS URI Scheme in the Session Initiation
Protocol (SIP). 2008. – Internet-Draft
[Ble-2005]
Bless, Roland et al.: Sichere Netzwerkkommunikation: Grundlagen, Protokolle
und Architekturen. 1. Auflage. Berlin Heidelberg, Deutschland : Springer, 2005
[BMJ-2008a] Bundesministerium der Justiz (Hrsg.): Gesetz gegen den unlauteren Wettbewerb. 2008
[BMJ-2008b] Bundesministerium der Justiz (Hrsg.): Telemediengesetz. 2008
[BMJ-2009a] Bundesministerium der Justiz (Hrsg.): Bundesdatenschutzgesetz. 2009
[BMJ-2009b] Bundesministerium der Justiz (Hrsg.): Bürgerliches Gesetzbuch. 2009
[BMJ-2009c] Bundesministerium der Justiz (Hrsg.): Gesetz über Unterlassungsklagen
bei Verbraucherrechts- und anderen Verstößen. 2009
[BMJ-2009d] Bundesministerium der Justiz (Hrsg.): Strafgesetzbuch. 2009
[BMJ-2009e] Bundesministerium der Justiz (Hrsg.): Telekommunikationsgesetz. 2009
[Bru-2003] Bruns, Holger:
Die Verwundbarkeit der Microsoft Software.
http://www.
heise.de/tp/r4/artikel/15/15329/1.html, erstellt am 05. 08. 2003, zuletzt
besucht am 30. 09. 2009.
125
[BSI-2005] Topf, Jochen et al. ; Bundesamt für Sicherheit in der Informationstechnik (Hrsg.): Antispam - Strategien: Unerwünschte E-Mails erkennen und
abwehren. 1. Auflage. Köln, Deutschland : Bundesanzeiger Verlag, 2005
[BSI-2009] Bundesamt für Sicherheit in der Informationstechnik (Hrsg.): Lagebericht 4. Quartal 2008. 2009
[Bul-2008] Bulk Email Software Superstore:
Address Lists - Buy.
Email Mailing Lists - Email
http://www.americaint.com/bulk-email-lists/
buy-email-lists.html, erstellt am 06. 10. 2008, zuletzt besucht am
30. 09. 2009.
[Bun-2009] Bundesnetzagentur:
Zertifizierungsdiensteanbieter (ZDA).
http:
//www.bundesnetzagentur.de/enid/1f39643c254eb4a5d1a22d3531f9c644,
0/ph.html, erstellt am 17. 06. 2009, zuletzt besucht am 30. 09. 2009.
[CDT-2003] Center for Democracy & Technology (Hrsg.): Why Am I Getting All
This Spam. 2003
[CGM-2008] Camarillo, Gonzalo ; Garcı́a-Martı́n, Maguel A.: The 3G IP Multimedia
Subsystem (IMS): Merging the Internet and the Cellular Worlds. 3. Auflage.
Chichester, England : Wiley, 2008
[Cis-2008]
Cisco Systems (Hrsg.): Cisco 2008 Annual Security Report: Highlighting global
security threats and trends. 2008
[Del-2000]
Dellarocas, Chrysanthos: Immunizing Online Reputation Reporting Systems
Against Unfair Ratings and Discriminatory Behavior. In: EC ’00: Proceedings
of the 2nd ACM conference on Electronic commerce. New York : ACM, 2000, S.
150–157
[Dix-2008] Dix, Alexander ; Berliner Beauftragter für Datenschutz und Informationsfreiheit (Hrsg.): Bekämpfung von SPAM: Ratgeber zum Datenschutz
9. 2008
[Dud-2006] Dudenredaktion (Hrsg.): Duden: Das Fremdwörterbuch. 9., aktualisierte Auflage. Mannheim, Deutschland : Bibliographisches Institut, 2006
[Ecl-2004]
Eclipse Foundation (Hrsg.): Eclipse Public License - v 1.0. 2004
[Egg-2005] Eggendorfer, Tobias: No Spam!: Wie Spam gar nicht erst entsteht. 1. Auflage.
Frankfurt, Deutschland : Software & Support, 2005
[ElB-2006] El Baker Nassar, Mohamed et al.: Intrusion detection mechanisms for VoIP
applications. In: The 3rd Annual VoIP Security Workshop, ACM, 2006
126
[ElK-2008] El Khayari, Rachid: SPAM over Internet Telephony and how to deal with it,
Technische Universität Darmstadt, Diplomarbeit, 2008
[ENI-2007] European Network and Information Security Agency (Hrsg.): Botnets
- The Silent Threat. 2007
[EPR-2002] Europäisches Parlament und der Rat (Hrsg.): Richtlinie 2002/58/EG.
2002
[Fer-2005]
Ferris, David ; Jennings, Richi ; Williams, Chris: The Global Economic
Impact of Spam, 2005 / Ferris Research. 2005. – Bericht
[FHG-2009] Fraunhofer FOKUS NGNI: The Open Source IMS Core Project. http://
www.openimscore.org/, erstellt am 16. 09. 2009, zuletzt besucht am 30. 09. 2009.
[Fin-2009]
Finjan: Cybercrime Intelligence Report. 2009 (2). – Forschungsbericht
[GW-2008] Graumann, Sabine ; Wolf, Malthe:
11. Faktenbericht 2008: Eine Se-
kundärstudie der TNS Infratest Business Intelligence. 1. Auflage. München,
Deutschland : BMWi, 2008
[Han-2006] Hansen, Markus et al.: Developing a Legally Compliant Reachability Management System as a Countermeasure against SPIT. In: Proceedings of the Third
Annual VoIP Security Workshop, Berlin, 2006
[Hof-2009] Hoffstadt, Dirk et al.:
SPAM over Internet Telephony (SPIT) und Ab-
wehrmöglichkeiten. 2009
[HSC-2009] Corporation, Hughes S.: Sipdroid - Project Hosting on SIP/VoIP client for
Android. http://www.sipdroid.org/, zuletzt besucht am 30. 09. 2009.
[IAN-2009] The Internet Assigned Numbers Authority:
tocol (SIP) Event Types Namespace.
Session Initiation Pro-
http://www.iana.org/assignments/
sip-events, erstellt am 23. 04. 2009, zuletzt besucht am 30. 09. 2009.
[ICQ-2009] Mirabilis: ICQ. http://www.icq.com/, zuletzt besucht am 30. 09. 2009.
[ISO-1996] International Organisation for Standardization (Hrsg.): International Standard 7498-1: Information technology – Open Systems Interconnection –
Basic Reference Model: The Basic Model. 2. Auflage. 1996
[ITU-2004] International Telecommunication Union - Telecommunication Standardization Sector (Hrsg.): Y.2001: Global Information Infrastructure, Internet Protocol Aspects and Next-Generation Networks. 2004
127
[ITU-2005] International Telecommunication Union - Telecommunication Standardization Sector (Hrsg.): E.164: The international public telecommunication numbering plan. 2005
[ITU-2006a] Bueti, Cristina ; ITU (Hrsg.): ITU Survey on Anti-Spam Legislation Worldwide. 2006
[ITU-2006b] International Telecommunication Union - Telecommunication
Standardization Sector (Hrsg.): G.723.1 : Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s. 2006
[ITU-2008] Bauer, Johannes M. et al. ; ITU-T Study Group 3 (Hrsg.): Financial Aspects
of Network Security: Malware and Spam. 2008
[Jen-2009] Jennings, Richi:
Cost of Spam is Flattening.
http://www.ferris.com/
2009/01/28/cost-of-spam-is-flattening-our-2009-predictions/, erstellt
am 28. 01. 2009, zuletzt besucht am 30. 09. 2009.
[Kar-2006] Karge, Sven et al. ; Hessisches Miniterium für Wirtschaft, Verkehr
und Landesentwicklung (Hrsg.): Anti-SPAM: Ein Leitfaden über und gegen
unverlangte E-Mail-Werbung. 1. Auflage. Wiesbaden, Deutschland : HA Hessen
Agentur, 2006
[Kut-2008] Kuthan, Jiri et al.: Dialog Event foR Identity VErification. 2008. – InternetDraft
[LG-2008]
Landgericht Hamburg (Hrsg.): Aktenzeichen: 327 O 493/08. 2008
[LiM-2008] LiMo Foundation (Hrsg.): LiMo Foundation Platform Architecture White
Paper. 2008
[Man-2009] ManyBrain: Mailinator - Let Them Eat Spam! http://www.mailinator.
com/, zuletzt besucht am 30. 09. 2009.
[Mas-2008] Massoth, Michael: Next Generation Telecommunication Factory NextFactor“.
”
2008. – Forschungsantrag
[Mas-2009] Massoth, Michael:
Masterprojekt Systementwicklung I + II, SS 2009.
http://www.fbi.h-da.de/organisation/personen/massoth-michael/
masterprojekt-systementwicklung-i-ii-ws-200910.html, zuletzt besucht
am 30. 09. 2009.
[McA-2009] McAfee (Hrsg.): The Carbon Footprint of Email Spam Report. 2009
[McD-2009] McDonald, Cameron et al.: Differential Path for SHA-1 with complexity
O(252 ) / International Association for Cryptologic Research. 2009. – Bericht
128
[Mes-2009] MessageLabs (Hrsg.): MessageLabs Intelligence: Q2/June 2009 “Cutwail’s
bounce-back; Instant messages can lead to instant malware”. 2009
[Mon-2009] Monty Python Pictures: SPAM. http://pythonline.com/node/18297641,
erstellt am 23. 03. 2009, zuletzt besucht am 30. 09. 2009.
[Moo-1965] Moore, Gordon E.: Cramming more components onto integrated circuits. In:
Electronics, 38 (1965), Nr. 8, S. 114–117
[Mos-2009] Moss-Pultz, Sean: Open for Opportunities. In: OpenExpo 2009 Bern, 2009
[Mun-2008] Munakata, Mayumi ; Schubert, Shida ; Ohba, Takumi: Guidelines for Using
the Privacy Mechanism for SIP. 2008. – Internet-Draft
[Nic-2007]
Niccolini, Saverio et al.: SIP Extensions for SPIT identification. 2007. –
Internet-Draft
[NIS-2007] Kayser, Richard F.: Announcing Request for Candidate Algorithm Nominations
for a New Cryptographic Hash Algorithm (SHA-3) Family. In: Federal Register
Notice 72 (2007), Nr. 212, S. 62212–62220
[NIS-2008] National Institute of Standards and Technology (Hrsg.): Secure Hash
Standard (SHS). 2008. – FIPS PUB 180-3
[Nok-2009] Nokia: Qt Software discontinues Qt Extended. http://qt.nokia.com/about/
news/qt-software-discontinues-qt-extended, erstellt am 26. 03. 2009, zuletzt besucht am 30. 09. 2009.
[OHA-2009a] Open Handset Alliance: Android. http://www.openhandsetalliance.
com/android_overview.html, zuletzt besucht am 30. 09. 2009.
[OHA-2009b] Open Handset Alliance: Members. http://www.openhandsetalliance.
com/oha_members.html, zuletzt besucht am 30. 09. 2009.
[OLG-2006] Oberlandesgericht Düsseldorf (Hrsg.): Aktenzeichen: I-15 U 45/06. 2006
[Ope-2009] Openmoko: Openmoko Om 2008. http://www.openmoko.com/download.html,
zuletzt besucht am 30. 09. 2009.
[Ord-2007] Ordoñez,
end
Was
Roderick:
Hot
Like
CAPTCHA
Me?
Wish
Your
Girlfri-
http://blog.trendmicro.com/
captcha-wish-your-girlfriend-was-hot-like-me/, erstellt am 27. 10.
2007, zuletzt besucht am 30. 09. 2009.
[Sch-1997] Schaller, Robert R.: Moore’s law: past, present, and future. In: IEEE Spectrum
34 (1997), Nr. 6, S. 52–59
129
[Sis-2009]
Sisalem, Dorgham et al.: SIP Security. 1. Auflage. Chichester, England : Wiley,
2009
[sno-2009]
snom technology: snom 870. http://www.snom.com/uploads/pics/snom_
870_links_hoch_perspektive_800px_06.jpg, zuletzt besucht am 30. 09. 2009.
[Sym-2009] Symbian Foundation:
Home of the Symbian Foundation.
http://www.
symbian.org/, zuletzt besucht am 30. 09. 2009.
[TIS-2008] Telecommunications and Internet converged Services and Protocols for Advanced Networking: Feasibility study of prevention of unsolicited communication in the NGN / European Telecommunications Standards
Institute. 2008 (TR 187.009 V2.1.1). – Technical Report
[TIS-2009] Telecommunications and Internet converged Services and Protocols for Advanced Networking: NGN Functional Architecture / European
Telecommunications Standards Institute. 2009 (ES 282.001 V3.4.1). – ETSI
Standard
[TNG-2006] Rohwer, Thomas et al. ; The Net Generation (Hrsg.): White Paper: Abwehr
von Spam over Internet Telephony“(SPIT-AL). 2006
”
[Tro-2009] Trolltech: Qt Extended. http://qtextended.org/modules/developers/,
zuletzt besucht am 30. 09. 2009.
[Tsc-2008] Tschofenig, Hannes et al.: Completely Automated Public Turing Test to Tell
Computers and Humans Apart (CAPTCHA) based Robot Challenges for SIP.
2008. – Internet-Draft
[TSG-2009a] Technical Specification Group Services and System Aspects: 3G security; Access security for IP-based services / 3rd Generation Partnership Project. 2009 (TS 33.203 V9.1.0). – Technical Specification
[TSG-2009b] Technical Specification Group Services and System Aspects: Characteristics of the IP Multimedia Services Identity Module (ISIM) application
/ 3rd Generation Partnership Project. 2009 (TS 31.103 V8.1.0). – Technical
Specification
[TSG-2009c] Technical Specification Group Services and System Aspects: IP
Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message
contents / 3rd Generation Partnership Project. 2009 (TS 29.228 V8.6.0). –
Technical Specification
130
[TSG-2009d] Technical Specification Group Services and System Aspects: IP
Multimedia Subsystem (IMS); Stage 2 / 3rd Generation Partnership Project.
2009 (TS 23.228 V9.1.0). – Technical Specification
[TSG-2009e] Technical Specification Group Services and System Aspects: Network architecture / 3rd Generation Partnership Project.
2009 (TS 23.002
V9.1.0). – Technical Specification
[TSG-2009f] Technical Specification Group Services and System Aspects: Vocabulary for 3GPP Specifications / 3rd Generation Partnership Project. 2009 (TR
21.905 V10.0.0). – Technical Report
[Tur-1950] Turing, Alan M.: Computing Machinery and Intelligence. In: Mind 59 (1950),
Nr. 236, S. 433–460
[TW-2007] Trick, Ulrich ; Weber, Frank: SIP, TCP/IP und Telekommunikationsnetze
Next Generation Networks und VoIP-konkret. 3., Überarbeitete und erweiterte
Auflage. München, Deutschland : Oldenbourg, 2007
[W3C-1999] World Wide Web Consortium: HTML 4.01 Specification. http://www.w3.
org/TR/1999/REC-html401-19991224/, erstellt am 24. 12. 1999, zuletzt besucht
am 30. 09. 2009.
[W3C-2001] World Wide Web Consortium: XHTMLTM 1.1 - Module-based XHTML.
http://www.w3.org/TR/2001/REC-xhtml11-20010531/, erstellt am 31. 03.
2001, zuletzt besucht am 30. 09. 2009.
[Wan-2004] Wang, Xiaoyun et al.: Collisions for Hash Functions MD4, MD5, HAVAL128 and RIPEMD. In: Bericht auf der 24. Annual International Cryptology
Conference, 2004
[Wes-2007] Weschkalnies, Nick: Spam konservieren. In: Visual-X 17 (2007), S. 26–30
[Yan-2006] Yan, Hong et al.: Incorporating Active Fingerprinting into SPIT Prevention
Systems. In: Third annual security workshop (VSW’06), ACM Press, 2006
[Zdz-2005] Zdziarski, Jonathan A.: Ending Spam: Bayesian Content Filtering and the
Art of Statistical Language Classification. 1. Auflage. San Francisco, USA : No
Starch Press, 2005
[Zie-2009]
Ziemann, Frank: Hoax-Info Service: Über Computer-Viren, die keine sind (sog.
”Hoaxes”) und andere Falschmeldungen und Gerüchte.
http://hoax-info.
tubit.tu-berlin.de/, erstellt am 01. 09. 2009, zuletzt besucht am 30. 09. 2009.
131
132
[RFC- 768] Postel, Jon: User Datagram Protocol. RFC 768 (1980)
[RFC- 793] Postel, Jon: Transmission Control Protocol. RFC 793 (1981)
[RFC-1321] Rivest, Ronald L.: The MD5 Message-Digest Algorithm. RFC 1321 (1992)
[RFC-1945] Berners-Lee, Tim et al.: Hypertext Transfer Protocol – HTTP/1.0. RFC 1945
(1996)
[RFC-2401] Kent, Stephen ; Atkinson, Randall: Security Architecture for the Internet
Protocol. RFC 2401 (1998)
[RFC-2402] Kent, Stephen ; Atkinson, Randall: IP Authentication Header. RFC 2402
(1998)
[RFC-2406] Kent, Stephen ; Atkinson, Randall: IP Encapsulating Security Payload (ESP).
RFC 2406 (1998)
[RFC-2486] Aboba, Bernard ; Beadles, Mark A.: The Network Access Identifier. RFC
2486 (1999)
[RFC-2616] Fielding, Roy T. et al.: Hypertext Transfer Protocol – HTTP/1.1. RFC 2616
(1999)
[RFC-2617] Franks, John et al.: HTTP Authentication: Basic and Digest Access Authentication. RFC 2617 (1999)
[RFC-2818] Rescorla, Eric: HTTP Over TLS. RFC 2818 (2000)
[RFC-3174] Eastlake, Donald E. ; Jones, Paul E.: US Secure Hash Algorithm 1 (SHA1).
RFC 3174 (2001)
[RFC-3261] Rosenberg, Jonathan et al.: SIP: Session Initiation Protocol. RFC 3261 (2002)
133
[RFC-3263] Rosenberg, Jonathan ; Schulzrinne, Henning: Session Initiation Protocol
(SIP): Locating SIP Servers. RFC 3263 (2002)
[RFC-3265] Roach, Adam: Session Initiation Protocol (SIP)-Specific Event Notification.
RFC 3265 (2002)
[RFC-3310] Niemi, Aki ; Arkko, Jari ; Torvinen, Vesa:
Hypertext Transfer Proto-
col (HTTP) Digest Authentication Using Authentication and Key Agreement
(AKA). RFC 3310 (2002)
[RFC-3323] Peterson, Jon: A Privacy Mechanism for the Session Initiation Protocol (SIP).
RFC 3323 (2002)
[RFC-3325] Jennings, Cullen et al.: Private Extensions to the Session Initiation Protocol
(SIP) for Asserted Identity within Trusted Networks. RFC 3325 (2002)
[RFC-3428] Campbell, Ben et al.: Session Initiation Protocol (SIP) Extension for Instant
Messaging. RFC 3428 (2002)
[RFC-3436] Jungmaier, Andreas ; Rescorla, Eric ; Tuexen, Michael: Transport Layer
Security over Stream Control Transmission Protocol. RFC 3436 (2002)
[RFC-3588] Calhoun, Pat R. et al.: Diameter Base Protocol. RFC 3588 (2003)
[RFC-3761] Faltstrom, Patrik ; Mealling, Michael: The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application
(ENUM). RFC 3761 (2004)
[RFC-3851] Ramsdell, Blake (Hrsg.): Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. RFC 3851 (2004)
[RFC-3856] Rosenberg, Jonathan: A Presence Event Package for the Session Initiation
Protocol (SIP). RFC 3856 (2004)
[RFC-3966] Schulzrinne, Henning: The tel URI for Telephone Numbers. RFC 3966 (2004)
[RFC-3986] Berners-Lee, Tim et al.: Uniform Resource Identifier (URI): Generic Syntax.
RFC 3986 (2005)
[RFC-4168] Rosenberg, Jonathan et al.:
The Stream Control Transmission Protocol
(SCTP) as a Transport for the Session Initiation Protocol (SIP). RFC 4168
(2005)
[RFC-4235] Rosenberg, Jonathan ; Schulzrinne, Henning ; Mahy, Rohan (Hrsg.): An
INVITE-Initiated Dialog Event Package for the Session Initiation Protocol
(SIP). RFC 4235 (2005)
134
[RFC-4346] Treese, Win ; Rescorla, Eric ; Dierks, Tim (Hrsg.) ; Rescorla, Eric
(Hrsg.): The Transport Layer Security (TLS) Protocol Version 1.1. RFC 4346
(2006)
[RFC-4566] Handley, Mark et al.: SDP: Session Description Protocol. RFC 4566 (2006)
[RFC-4648] Josefsson, Simon: The Base16, Base32, and Base64 Data Encodings. RFC
4648 (2006)
[RFC-4960] Steward, Randall (Hrsg.): Stream Control Transmission Protocol. RFC 4960
(2007)
[RFC-5039] Rosenberg, Jonathan ; Jennings, Cullen: The Session Initiation Protocol
(SIP) and Spam. RFC 5039 (2008)
[RFC-5079] Rosenberg, Jonathan: Rejecting Anonymous Requests in the Session Initiation
Protocol (SIP). RFC 5079 (2007)
135

SPIT und Privacy im Kontext des IMS

Transcrição

Documentos relacionados

Targa WR500

070 Tuning-News

Strategien gegen Spam

Vespa-GTS.de - Gran-Turismo-S.de

GXP1610 - Grandstream

Spam und Gegenmaßnahmen

Internet Telefonie (SIP) HOWTO

Anleitung Alcatel Omni PCX Office

BT Wholesale VoIP

PDF / 33 kB - Forschungszentrum Jülich