2

Ich erkl¨ are hiermit ehrenw¨ ortlich, daß ich die vorliegende Arbeit selbst¨ andig verfaßt und außer der im Literaturverzeichnis angef¨ uhrten Werke keine Hilfen in Anspruch genommen habe.

Diese Arbeit wurde noch keiner Pr¨ ufungskommission vorgelegt.

Florian Fuchs

Inhaltsverzeichnis

1  Einleitung  11

2  Grundbegriffe  13

2.1  Authentizit at  13

2.2  Integrit at  13

2.3  Vertraulichkeit  13

2.4  Beweisbarkeit  14

2.5  Anonymit at  14

2.6  Verf ugbarkeit  15

2.7  Symmetrische Verschl usselung  15

2.8  Asymmetrische Verschl usselung  16

2.9  Hashfunktionen  18

2.10  Zufallszahlen  18

2.11  Covert Channels  19

2.12  Auditing  19

2.13  Digitale Signaturen  20

3  OSI Referenz Modell  23

3.1  Physical Layer  23

3.2  Data Link Layer  23

3.3  Network Layer  24

3.4  Transport Layer  25

3.5  Session Layer  25

3.6  Presentation Layer  26

3.7  Application Layer  26

3.8  TCP/IP Reference Model  27

3.8.1  Host-to-Network Layer  27

3.8.2  Internet Layer  27

3

4 INHALTSVERZEICHNIS

3.8.3 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.8.4 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Allgemeine Sicherheitsprobleme 29

4.1 Denial-of-Service Attacke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2 Man-in-the-middle Attacke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.5 Trojanische Pferde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.6 Viren und W¨ urmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Bedeutende Angriffe in der Vergangenheit 33

5.1 Internetwurm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.2 Melissa-Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3 Distributed Denial-of-Service-Attacken . . . . . . . . . . . . . . . . . . . . . . . . 38 5.4 Echelon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6 Netzwerkprotokolle und deren Sicherheitsbedrohungen 45

6.1 IP Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.2 ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.3 PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.4 ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.4.1 Authentizit¨ atsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.4.2 Verf¨ ugbarkeitsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.5 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.5.1 Authentifizierungsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.5.2 Integrit¨ ats- und Vertraulichkeitsprobleme . . . . . . . . . . . . . . . . . . 54 6.5.3 Verf¨ ugbarkeitsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.5.4 Beweisbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.5.5 Anonymit¨ at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.6 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.7 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.8 Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.9 rlogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.10 FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.10.1 Authentizit¨ ats- und Integrit¨ atsprobleme . . . . . . . . . . . . . . . . . . . 65 6.10.2 Verf¨ ugbarkeitsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

INHALTSVERZEICHNIS 5

6.10.3  Weitere Sicherheitsprobleme  67

6.11  SMTP  67

6.11.1  Authentizit atsprobleme  69

6.11.2  Integrit atsprobleme  70

6.11.3  Vertraulichkeitsprobleme  70

6.11.4  Weitere Sicherheitsprobleme  70

6.12  HTTP  70

6.12.1  Authentifizierungsprobleme  74

6.12.2  Integrit ats- und Vertraulichkeitsprobleme  75

6.12.3  Anonymit atsprobleme  75

6.13  NFS  76

6.13.1  Authentizit atsprobleme  77

6.13.2  Integrit ats- und Vertraulichkeitsprobleme  78

7  Sicherheitsmaßnahmen  79

7.1  Firewalls  79

7.1.1  Paketfilter  80

7.1.2  Application Gateways  81

7.1.3  Bastion Host  82

7.1.4  DMZ oder Perimeternetz  83

7.1.5  Personal Firewalls  84

7.2  VPN  84

7.3  Intrusion Detection Systeme  85

8  Verbesserte Protokolle  91

8.1  PPTP  91

8.1.1  Authentifizierung in Microsofts PPTP  91

8.1.2  Vertraulichkeit in Microsofts PPTP  93

8.2  IPv6 und IPSec  94

8.2.1  Encapsulating security payload  94

8.2.2  Authentication Header (AH)  96

8.2.3  Internet key exchange  96

8.3  SSL  99

8.4  SSH  103

8.5  S/MIME  105

8.6  Kerberos  111

8.7  Anonyme Kommunikation  117

6  INHALTSVERZEICHNIS  

8.7.1  Anonyme Proxyserver  117

8.7.2  Crowds  118

8.7.3  Onion Routing  119

9  Schlußwort  123

A  Abk urzungen  125

Literaturverzeichnis   129

Abbildungsverzeichnis

2.1 Beispiel f¨ ur asymmetrische Verschl¨ usselung . . . . . . . . . . . . . . . . . . . . . 17

3.1 OSI-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2 ¨ Ubertragung mit falscher Reihenfolge . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3 TCP/IP Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1 Distributed Denial-of-Service-Attacken (nach [CER99]) . . . . . . . . . . . . . . . 38

6.1 ARP-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.2 ARP-Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.3 PPP-Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.4 TCP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.5 UDP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.6 DNS-Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.7 DNS-Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.8 DNS-Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.9 FTP-Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.10 FTP-DoS Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.11 SMTP-Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.12 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.13 NFS-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.1 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.2 IP Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.3 Bastion Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 7.4 Perimeternetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 7.5 Virtual Private Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8.1 Unterschied IP-Paket mit und ohne ESP . . . . . . . . . . . . . . . . . . . . . . . 95 8.2 ESP Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7

8  ABBILDUNGSVERZEICHNIS  

8.3  IKE: Main Mode  98

8.4  IKE: Aggressive Mode  98

8.5  IKE: Quick Mode  98

8.6  SSL Architektur  100

8.7  SSL Protokoll  101

8.8  SSH Version 1  103

8.9  hybride Verschl usselung  106

8.10  Kerberos allgemein  112

8.11  Kerberos 4  114

8.12  Kerberos 5  116

8.13  Anonymer Proxyserver  118

8.14  Crowds  119

8.15  Onion Routing  120

Tabellenverzeichnis   

5.1  angebliche IXPs der NSA  42

6.1  ICMP Nachrichten Typen  49

6.2  g angige TCP Ports  51

6.3  TCP Flags  53

6.4  FTP Kommandos  63

6.5  FTP-Antworten  64

6.6  SMTP Kommandos  68

6.7  HTTP-Antworten  73

8.1  Ports f ur SSL Protokolle  99

8.2  S/MIME-Content Typen  107

8.3  base64 Alphabet  110

9

10 TABELLENVERZEICHNIS

Kapitel 1

Einleitung

Netzwerke gewinnen immer mehr an Bedeutung. W¨ ahrend noch vor einigen Jahren die meisten Heimcomputer nicht vernetzt waren, hat sich das mit der Verbreitung des Internets rasch ge¨ andert, aus ehemaligen Einzelplatzrechnern wurden Teilnehmer in einem großen Netzwerk. Auch viele Firmen haben ihre bestehenden Systeme in das Internet eingebunden. Dadurch ist aber auch das Sicherheitsbed¨ urfnis gestiegen. Heute ist es f¨ ur einen Angreifer kein Problem mehr zum Beispiel von Europa aus eine Firma in Australien erfolgreich zu attackieren und dieser einen großen wirtschaftlichen Schaden zuzuf¨ ugen. Aber auch im privaten Bereich gewinnt die Systemsicherheit immer mehr an Bedeutung, da Personen ihre Privatsph¨ are sch¨ utzen wollen.

In dieser Diplomarbeit m¨ ochte ich verschiedene Aspekte von Internet- und Intranetsicherheit be-handeln. In Kapitel 2 erkl¨ are ich die wichtigsten Grundbegriffe im Zusammenhang mit Systemsicherheit, damit auch Leser, die mit diesem Thema nicht so vertraut sind, die nachfolgenden Kapitel leicht verstehen k¨ onnen. Kapitel 3 beschreibt kurz das OSI- und das TCP-Modell und den allgemeinen Aufbau von Netzwerken. Anschließend werden in Kapitel 4 allgemeine Sicherheitsprobleme angef¨ uhrt, auf die in der Arbeit ¨ ofter eingegangen wird. Um dem Leser die Relevanz von Sicheheitsbedrohungen n¨ aher zu bringen, habe ich in Kapitel 5 einige bedeutende Angriffe beschrieben.

Auf Sicherheitsprobleme in bestehenden Netzwerkprotokollen gehe ich in Kapitel 6 n¨ aher ein. Dabei beschreibe ich zuerst einige Netzwerkprotokolle und gehe dann anschließend jeweils auf deren Sicherheitsprobleme ein. Die Protokolle wurden von mir so ausgew¨ ahlt, daß sie einerseits sehr bekannt sind und h¨ aufig eingesetzt werden, andererseits aber m¨ oglichst viele Sicherheitsprobleme aufwerfen. Einige Sicherheitsmaßnahmen, die getroffen werden k¨ onnen um Systeme zu sichern, stelle ich in Kapitel 7 vor. In Kapitel 8 zeige ich exemplarisch verbesserte Protokolle, die mehr Sicherheit bieten sollen. Einige von diesen weisen aber auch Schw¨ achen auf, die ich dann jeweils beschreibe. In Kapitel 9 bringe ich eine kurze Zusammenfassung, die die wesentlichen

11

12 Einleitung

Aspekte von Sicherheit im Internet und Intranet noch einmal betont.

Wesentlich ist jedoch, daß sich der Leser immer vor Augen h¨ alt, daß ”Sicherheit wie eine Kette ist, die so stark ist wie ihr schw¨ achstes Glied. Sicherheit ist ein Prozeß und kein Produkt” (vgl. [Sch00b], Seite xii). Damit ist gemeint, daß die Sicherheit eines Systems immer von mehreren Faktoren abh¨ angt, wobei sich die Faktoren zum Beispiel durch neue Erkenntnisse oder Anforderungen mit der Zeit ¨ andern k¨ onnen.

Kapitel 2

Grundbegriffe

In diesem Kapitel m¨ ochte ich einige Grundbegriffe in Zusammenhang mit Systemsicherheit auf einfache Weise erkl¨ aren. Die Liste ist nicht vollst¨ andig, soll aber dem Leser rasch einen ¨ Uberblick

liefern. Als weiterf¨ uhrende Literatur kann ich [Sch00b], [MOV97] und [RS92] empfehlen.

2.1 Authentizit¨ at

Die Authentizit¨ at garantiert dem Empf¨ anger einer Nachricht, daß die Daten tats¨ achlich von demjenigen sind, der vorgibt der Sender zu sein. Der Empf¨ anger kann sich also darauf verlassen, daß niemand anderer diese Nachricht geschickt hat.

2.2 Integrit¨ at

Die Integrit¨ at garantiert dem Empf¨ anger einer Nachricht, daß die Daten nicht ver¨ andert wurden. Zusammen mit der Authentizit¨ at gew¨ ahrleistet die Integrit¨ at, daß die Nachricht unver¨ andert vom Sender zum Empf¨ anger gelangt ist und daß diese auch tats¨ achlich vom Sender stammt.

2.3 Vertraulichkeit

Weder Authentizit¨ at noch Integrit¨ at garantieren allerdings, daß ein Angreifer die Nachricht nicht m¨ oglicherweise w¨ ahrend der ¨ Ubertragung gelesen hat. Erst die Vertraulichkeit bedeutet, daß die Nachricht tats¨ achlich nur von den daf¨ ur autorisierten Personen gelesen werden kann.

13

14 Grundbegriffe

2.4 Beweisbarkeit

Die Beweisbarkeit erm¨ oglicht es auch gegen¨ uber Dritten zu zeigen, daß eine Nachricht von einem bestimmten Sender stammt. Auf den ersten Blick mag dieser Punkt etwas verwunderlich erscheinen, da bereits die Authentizit¨ at zeigt, daß eine Nachricht tats¨ achlich von einem bestimmten Sender ist. Das ist aber, wie bereits in Abschnitt 2.1 beschrieben nur insofern richtig, als der Empf¨ anger sicher sein kann, daß die Nachricht tats¨ achlich von einem bestimmten Sender stammt. Der Empf¨ anger kann aber einem Dritten gegen¨ uber nicht beweisen, daß die Nachricht von diesem Sender verschickt wurde.

Das kann man mit einem einfachen Beispiel zeigen: Alice und Bob m¨ ochten einander Briefe schicken, bei denen die Authentizit¨ at gew¨ ahrleistet ist. Sie vereinbaren ein geheimes Codewort. Jede Nachricht, egal von wem sie stammt, muß dieses Codewort enthalten, denn dann wissen die beiden, daß die Nachricht vom anderen gesendet wurde. Zus¨ atzlich verschl¨ usseln sie die Nachricht, sodaß ein Angreifer, der die Nachricht abf¨ angt, das Codewort nicht erf¨ ahrt. Bekommt nun zum Beispiel Bob eine Nachricht, die das Codewort enth¨ alt, kann er sicher sein, daß diese von Alice ist, da nur sie und er das Codewort kennen. Er kann aber einem Dritten gegen¨ uber nicht beweisen, daß die Nachricht von Alice ist, selbst wenn er dem Dritten das Codewort verr¨ at. Er h¨ atte die Nachricht n¨ amlich auch selber schreiben k¨ onnen, da auch er das Codewort kennt.

Diese Form der Beweisbarkeit kann aber sehr entscheidend sein, wenn eine Nachricht einen rechtsverbindlichen Charakter haben soll. Ob die Nachricht dann tats¨ achlich rechtsverbindlich ist, h¨ angt von mehreren rechtlichen Faktoren ab (vgl. [Bre99] und [MSPS99]). Ein weiterer Aspekt der Beweisbarkeit ist, daß ein Sender beweisen k¨ onnen muß eine Nachricht an den Empf¨ anger geschickt zu haben. Diese Form der Beweisbarkeit wird bei der herk¨ ommlichen Briefpost meistens mittels Einschreiben realisiert, wobei bei Einschreiben der Inhalt einer Sendung nicht best¨ atigt wird (es wird nun best¨ atigt, daß eine Sendung abgeschickt wurde).

2.5 Anonymit¨ at

In der heutigen Zeit nimmt der Einsatz von Computern und Netzwerken st¨ andig zu. Dadurch wird es immer einfacher, genaue Profile von Menschen zu erstellen und viele sind der Ansicht, daß wir der von George Orwell beschriebenen Welt in seinem Werk ”1984” nicht mehr so fern sind.

Auf der anderen Seite ist es nat¨ urlich manchmal wichtig zu wissen, mit wem man kommuniziert. Beispielsweise haben die Betreiber von einigen Sites, die anonyme Proxies anbieten (siehe Abschnitt 8.7) bemerkt, daß ¨ uber ihr Service h¨ aufig Zahlungen mit gestohlenen Kreditkarten

geschickt wurden (vgl. [RR99]). Auch hat der Staat im Bereich der Verfolgung von Straftaten sicher ein berechtigtes Interesse herauszufinden, wer mit wem kommuniziert hat. Auch die Vertraulichkeit erlaubt etwas Anonymit¨ at, da die Nachricht nur von den daf¨ ur bestimmten Personen gelesen werden kann. Allerdings erkennt ein Angreifer trotzdem, wer mit wem kommuniziert, da er den Weg der Nachricht verfolgen kann. Das Wissen dar¨ uber, daß zwei Personen miteinander kommunzieren, reicht aber oft schon f¨ ur einen Angreifer aus, um f¨ ur ihn wichtige Schl¨ usse ziehen zu k¨ onnen.

2.6 Verf¨ ugbarkeit

Da wir uns heute immer mehr auf Computer und Netzwerke verlassen, spielt die Verf¨ ugbarkeit dieser Systeme eine sehr große Rolle. Es ist heute nicht mehr akzeptabel, daß Rechner in Atomkraftwerken, Flugzeugen, Banken, Rettungsleitstellen, etc. ausfallen, da davon Menschenleben oder die Wirtschaft abh¨ angen.

Um die Verf¨ ugbarkeit zu gew¨ ahrleisten muß man immer das gesamte System betrachten. Es macht keinen Sinn, wenn s¨ amtliche Rechner ausfallssicher sind, aber beispielsweise nicht an eine Notstromversorgung angeschlossen sind. Deshalb gehe ich in meiner Arbeit nur fallweise auf dieses Thema ein.

2.7 Symmetrische Verschl¨ usselung

Die symmetrische Verschl¨ usselung war lange Zeit die einzige Form der Verschl¨ usselung. Bei dieser Form der Verschl¨ usselung einigen sich Sender und Empf¨ anger auf einen gemeinsamen, geheimen Schl¨ ussel und einen gemeinsamen Verschl¨ usselungsalgorithmus.

Ein Beispiel f¨ ur einen ganz simplen Verschl¨ usselungsalgorithmus ist die sogenannte C¨ asar-Chiffre (benannt nach C¨ asar, weil dieser davon Gebrauch machte). Es handelt sich dabei um eine einfache Verschiebechiffre.

Bei der C¨ asar-Chiffre wurden die Buchstaben einfach um drei Zeichen verschoben, aus einem A wurde ein D, aus einem B ein E, aus einem Z ein C, usw.

Allgemeiner formuliert kann man den Verschl¨ usselungsalgorithmus so beschreiben: Jedem Buchstaben im Alphabet wird eine Zahl zugeordnet, beginnend bei A = 0 bis Z = 25. C = (E + k) mod 26, wobei C f¨ ur den verschl¨ usselten Buchstaben steht, E f¨ ur den Entschl¨ usselten und k f¨ ur den Schl¨ ussel. F¨ ur den Schl¨ ussel gilt allerdings, daß k < 26 sein muß, da bei k = 26 oder einem Vielfachen von 26 keine Verschl¨ usselung stattfinden w¨ urde und k > 26 keinen Sinn macht, da sich die Werte aufgrund der modulo-Division ohnehin nur zwischen 0 und 25 bewegen.

16 Grundbegriffe

Dieser Algorithmus ist nat¨ urlich sehr leicht zu brechen. Einerseits ist der Schl¨ usselraum (Anzahl der m¨ oglichen Schl¨ ussel) sehr klein, andererseits kann man mit Hilfe von H¨ aufigkeitstabellen die Nachrichten rasch brechen.

H¨ aufigkeitstabellen geben an, wie oft ein Buchstabe in einer bestimmten Sprache durchschnittlich vorkommt. Da bei einem Substitutionsverfahren jedes Zeichen immer genau durch ein anderes ersetzt wird, bleibt die Verteilung der Zeichen auch nach der Verschl¨ usselung enthalten. Da in der deutschen Sprache zum Beispiel der Buchstabe E der am h¨ aufigsten verwendete ist, wird mit ziemlich hoher Sicherheit auch im verschl¨ usselten Text das am h¨ aufigsten verwendete Zeichen ein E repr¨ asentieren.

In der Zwischenzeit sind die Verschl¨ usselungsalgorithmen wesentlich sicherer geworden. Bekannte Beispiele f¨ ur symmetrische Verschl¨ usselungsalgorithmen sind heute IDEA, Rijndael und 3DES (Triple DES).

2.8 Asymmetrische Verschl¨ usselung

Das Hauptproblem der symmetrischen Verschl¨ usselungsalgorithmen besteht darin, daß sich Sender und Empf¨ anger auf einen geheimen Schl¨ ussel einigen m¨ ussen. Um sich auf diesen Schl¨ ussel zu einigen, ben¨ otigen sie einen sicheren Kanal. In der Praxis heißt das, daß sie sich treffen m¨ ussen, um einen Schl¨ ussel zu vereinbaren. Ein weiteres Problem in diesem Zusammenhang ist, daß wenn jemand mit vielen Personen kommunizieren will, er mit jeder Person einen eigenen Schl¨ ussel vereinbaren muß. Diese Personen wiederum m¨ ussen ebenfalls mit s¨ amtlichen Personen Schl¨ ussel vereinbaren, mit denen sie kommunizieren wollen. Wollen also N Personen miteinander kommunizieren, m¨ ussen ingesamt N · (N − 1)/2 Schl¨ ussel vereinbart werden. Das Ziel der asymmetrischen Verschl¨ usselung ist, daß zwei oder mehrere Partner miteinander verschl¨ usselt kommunizieren k¨ onnen, ohne vorher einen gemeinsamen Schl¨ ussel vereinbart zu haben.

In [Sin00] wird ein Verfahren auf einfache Weise beschrieben, damit der Leser asymmetrische Verschl¨ usselung leichter versteht. Alice m¨ ochte Bob eine Nachricht schicken, die nur Bob lesen k¨ onnen soll (siehe Abbildung 2.1). Dazu steckt sie die Nachricht in eine Kiste und versperrt diese mit einem Vorh¨ angeschloß. Anschließend schickt sie die versperrte Kiste an Bob. Bob kann die Kiste nicht ¨ offnen, da er den Schl¨ ussel f¨ ur das Vorh¨ angeschloß nicht besitzt. Er h¨ angt selber ein eigenes Vorhangschloß dazu und schickt die nun mit zwei Schl¨ ossern versperrte Kiste an Alice zur¨ uck. Alice sperrt ihr eigenes Schloß auf und schickt die Kiste abermals an Bob zur¨ uck. Dieser kann nun sein eigenes Schloß ¨ offnen und die Nachricht in der Kiste lesen. Somit ist w¨ ahrend des Tranports die Kiste immer mit mindestens einem Schloß gesichert.

Damit wird das Problem gel¨ ost, daß sich Alice und Bob nicht auf einen gemeinsamen Schl¨ ussel

einigen m¨ ussen. Trotzdem gibt es bei dem Verfahren ein Problem. Alice kann nicht sicher sein, daß tats¨ achlich Bob und niemand anders die Nachricht empf¨ angt. Nehmen wir an Eve m¨ ochte die Nachricht an Bob abfangen und schafft es die Kiste vor Bob zu bekommen. Sie h¨ angt ihr eigenes Vorhangschloß auf die Kiste und schickt diese zur¨ uck an Alice. Alice glaubt, daß Bob sein Schloß auf die Kiste geh¨ angt hat, ¨ offnet ihr eigenes und schickt die Kiste zur¨ uck. Abermals f¨ angt Eve die Kiste ab, ¨ offnet ihr eigenes Schloß und kann die Nachricht, die eigentlich f¨ ur Bob bestimmt war, lesen. Alice hatte keine M¨ oglichkeit festzustellen, wessen Schloß dazugeh¨ angt wurde, weil die Authentizit¨ at von Bobs Schloß nicht gew¨ ahrleistet war. Genauso kann auch Bob nicht sicher sein, daß eine Nachricht tats¨ achlich von Alice stammt. Sie k¨ onnte genauso gut von Eve sein.

Die Mathematik hinter asymmetrischen Verschl¨ usselungsalgorithmen ist eher kompliziert. Der interessierte Leser wird auf [MOV97] verwiesen.

Bekannte Beispiele f¨ ur asymmetrische Verschl¨ usselungsalgorithmen sind RSA (vgl. [RSA78]) und DH (vgl. [DH76]). Dabei verf¨ ugt jeder der Kommunikationspartner ¨ uber einen ¨ offentlichen

und einen privaten Schl¨ ussel. Der ¨ offentliche Schl¨ ussel kann jeder Person ¨ ubermittelt werden,

die jemandem etwas verschl¨ usselt schicken m¨ ochte. Entschl¨ usselt werden kann die Nachricht nur mit dem privaten Schl¨ ussel, der geheimhalten gehalten werden muß. Gegen¨ uber symmetrischen Verfahren sind asymmetrische wesentlich langsamer. Deshalb setzt man heute oft ein hybrides Verfahren, bestehend aus einem symmetrischen und einem asymmetrischen Algorithmus, ein. Dabei wird ein zuf¨ alliger Schl¨ ussel k generiert, mit dem die Nachricht m symmetrisch verschl¨ usselt wird. Der Schl¨ ussel k wird dann anschließend mit dem ¨ offentlichen Schl¨ ussel des Empf¨ angers verschl¨ usselt.

18 Grundbegriffe

Bei der Entschl¨ usselung muß der Empf¨ anger zuerst mit seinem privaten Schl¨ ussel k entschl¨ usseln, damit er dann anschließend mit Hilfe von k die Nachricht m dechiffrieren kann.

2.9 Hashfunktionen

Hashfunktionen k¨ onnen zu einer beliebig langen Nachricht einen Funktionswert bilden. Im Bereich der Kryptographie ist es außerdem wichtig, daß man von dem abgebildeten Wert keine R¨ uckschl¨ usse auf die urspr¨ ungliche Nachricht ziehen kann, selbst wenn der Angreifer weiß, welcher Algorithmus eingesetzt wurde.

Interessant sind Hashfunktionen im Bereich der Integrit¨ at. Man kann vor dem Versenden einer Nachricht den Hashwert h 1 dieser Nachricht berechnen. Anschließend schickt man h 1 und die Nachricht dem Empf¨ anger. Dieser kann den Hashwert h 2 f¨ ur die empfangene Nachricht ausrechnen. Sind h 1 und h 2 ident, dann wurde die Nachricht nicht ver¨ andert und die Integrit¨ at ist gew¨ ahrleistet (die Authentizit¨ at jedoch nicht, da auch h 1 bei der ¨ Ubertragung manipuliert werden k¨ onnte).

2.10 Zufallszahlen

Zufallszahlen spielen eine sehr wichtige Rolle in der Kryptographie. Sehr viele Protokolle basieren letztendlich auf der Qualit¨ at der Zufallszahlen. Nur wenn ein Schl¨ ussel tats¨ achlich zuf¨ allig gew¨ ahlt wurde (mit einer entsprechenden L¨ ange) kann er als sicher gelten. Auf ersten Blick wirkt die Generierung von Zufallszahlen trivial. Das Problem ist aber, daß der Computer eine deterministische Maschine ist. Das heißt in der gleichen Situation wird er immer gleich reagieren. Verwendet man beispielsweise die Uhr eines Computers um Zufallszahlen zu generieren, wirken die Ergebnisse auf den ersten Blick tats¨ achlich zuf¨ allig. Wer allerdings weiß wann die Zufallszahl generiert wurde, kann ganz leicht einen Schl¨ ussel herausfinden, der auf dieser Zufallszahl basiert.

Nehmen wir an ein Angreifer weiß, daß ein Schl¨ ussel ca. um 12:00 generiert wurde. Er braucht dann eigentlich nur s¨ amtliche Werte, die zwischen 11:50 und 12:10 durch den Zufallsgenerator erzeugt werden k¨ onnen, durchprobieren. Einer der Werte ist mit Sicherheit der Schl¨ ussel. Selbst eine große Schl¨ ussell¨ ange zu w¨ ahlen ist sinnlos, da in diesem Zeitfenster nur eine sehr begrenzte Anzahl an Werten generiert werden kann. Auch andere Verfahren, wie etwa die aktuelle Netzlast als Quelle f¨ ur Zufallszahlen heranzuziehen, sind nicht besser.

In Hochsicherheitsbereichen werden oft physikalische Prozesse, die sehr zuf¨ allig wirken, herangezogen, wie etwa das Rauschen von Funksendern. Im privaten Bereich werden oft Mausbe- wegungen oder die Abst¨ ande zwischen Tastenanschl¨ agen als Zufallswerte verwendet. Werden

viele Zufallswerte ben¨ otigt, wird mit Hilfe dieser Zufallswerte eine sogenannte ”seed” erzeugt, die dann f¨ ur die Generierung weiterer Zufallswerte herangezogen wird, die dann aber nur noch pseudo-zuf¨ allig sind, da sie wieder nach einem fixen Algorithmus errechnet werden. So lange die ”seed” geheim bleibt funktioniert diese Methode recht gut (vgl. [Sch00b]).

2.11 Covert Channels

”Unter Covert Channel (versteckte Kan¨ ale) versteht man einen Kommunikationskanal der einem Prozeß erlaubt Informationen auf eine Art zu ¨ ubertragen, die die Security Policy (die Sicherheitsregeln) verletzen.” ([RS92], Seite 409) Covert Channels sind ein großes Problem f¨ ur die Vertraulichkeit. Je geschickter ein Angreifer sie versteckt, desto schwieriger wird es sie zu verhindern. Theoretisch kann jede Information weitere versteckte Informationen enthalten, wenn vorher entsprechende Vereinbarungen bez¨ uglich der Codierung getroffen werden. Beispielsweise k¨ onnen zwei Spione vereinbaren, daß wenn einer von ihnen ein blaues Taschentuch eingesteckt hat, alles in Ordnung ist, wenn er hingegen ein rotes Taschentuch eingesteckt hat, ein Problem aufgetreten ist.

Auch bei Computern kann man ¨ ahnliche Vereinbarungen treffen. Beispielsweise kann eine Workload (Maß f¨ ur die momentane Auslastung des Rechners) von mehr als zwei auf einem Server bedeuten, daß alles in Ordnung ist, eine Workload darunter, daß es ein Problem gegeben hat.

2.12 Auditing

”Unter Auditing versteht man das Aufzeichnen, Untersuchen und Reviewen von sicherheitsrelevanten Aktivit¨ aten in einem vertrauensw¨ urdigen System.” ([RS92], Seite 128)

Auditing ist ein sehr wichtiger Bestandteil jedes Sicherheitskonzepts. Ohne Auditing ist es praktisch unm¨ oglich Angriffe zu erkennen und zur¨ uckzuverfolgen. Es ist jedoch erforderlich, die Logfiles, die beim Auditing erzeugt werden, abzuspeichern. Da diese Logfiles aber einfache Dateien sind, k¨ onnen sie von einem Angreifer leicht manipuliert werden, wodurch sie dann wertlos sind. Deshalb sollten Logfiles entweder auf Medien geschrieben werden, die nur einmal beschreibar sind oder es m¨ ussen andere Verfahren eingesetzt werden, wie zum Beispiel kryptographische Protokolle. Ein solches Protokoll wird unter anderem in [SK98] vorgestellt.

20 Grundbegriffe

2.13 Digitale Signaturen

Digitale Signaturen, im Signaturgesetz auch elektronische Signaturen genannt (vgl. [Bre99]), sollen die Authentizit¨ at, Integrit¨ at und Beweisbarkeit garantieren. Generiert werden digitale Signaturen mit Hilfe eines asymmetrischen Verfahrens. Erstellt wird eine Signatur von einer Signierungsfunktion, die diese aus der Nachricht selbst und dem geheimen Schl¨ ussel erzeugt. Um die Signatur zu pr¨ ufen errechnet der Empf¨ anger mittels einer Verifizierungsfunktion, die die Nachricht, den ¨ offentlichen Schl¨ ussel und die Signatur selbst heranzieht, ob diese korrekt ist. Damit der Empf¨ anger aber auch sicher sein kann, daß der ¨ offentliche Schl¨ ussel tats¨ achlich dem Sender geh¨ ort, ist dieser mit einem Zertifikat einer vertrauensw¨ urdigen Stelle (Certificate Au-thority) ausgestattet. Die Certificate Authority (CA) best¨ atigt, daß ein bestimmter Schl¨ ussel einer bestimmten Person geh¨ ort, indem sie vorher die pers¨ onlichen Daten der Person anhand von festgelegten Kriterien (zum Beispiel Lichtbildausweis) ¨ uberpr¨ uft hat.

Wenn der ¨ offentliche Schl¨ ussel mit einem Zertifikat einer CA ausgestattet ist und die Verifizierungsfunktion die Korrektheit der Nachricht festgestellt hat, sind Authentizit¨ at, Integrit¨ at und Beweisbarkeit garantiert.

Viele halten digitale Signaturen f¨ ur einen echten Ersatz herk¨ ommlicher Unterschriften. Das stimmt so allerdings nicht:

1. Mittels elektronischer Signaturen werden keine Inhalte signiert, sondern lediglich Bitfolgen. Wie diese Bitfolgen zu interpretieren sind (wie der Inhalt angezeigt werden muß) ist Sache der jeweiligen Applikation, mit der das signierte Dokument geschrieben wurde. Das heißt, man m¨ ußte die Applikation ebenfalls mitsignieren. Die Applikation wiederum l¨ auft unter einem bestimmten Betriebssystem, das eigentlich daf¨ ur zust¨ andig ist die Informationen an die Hardware weiterzuleiten. Somit m¨ ußte auch das Betriebssystem in die digitale Signatur miteinbezogen werden. Zum Schluß bleibt noch die Hardware, die die Informationen letztendlich erst anzeigt. Das heißt, auch die m¨ ußte mitsigniert werden. In der Praxis ist das aber nicht m¨ oglich.

2. Da man wie unter Punkt 1 beschrieben nicht alle Komponenten signieren kann, muß der Anwender letztendlich beim Signieren bzw. beim Verifizieren einer digitalen Signatur gewissen Komponenten vertrauen. Er muß sich sicher sein, daß die Software tats¨ achlich vor dem Signieren den Text anzeigt, den er signieren m¨ ochte und daß er nicht in Wirklichkeit einen anderen Text signiert. Auch beim Verifizieren einer Signatur muß er sich darauf verlassen k¨ onnen, daß das Ergebnis der Verifizierung korrekt ist. Das ist aber insofern problematisch, da die Signaturen oft mit herk¨ ommlichen PCs erstellt werden, die leicht manipuliert werden k¨ onnen, da auf ihnen praktisch jede beliebige Software und somit auch

trojanische Pferde (vgl. Abschnitt 4.5) und Viren (vgl. Abschnitt 4.6) laufen k¨ onnen.

3. Aufgrund m¨ oglicher Manipulationen kann ein Empf¨ anger also eigentlich nicht wirklich sicher sein, daß tats¨ achlich der angegebene Signator ein bestimmtes Dokument signieren wollte. Aufgrund des Signaturgesetzes jedoch sind digitale Signaturen bis auf wenige Ausnahmen rechtlich bindend.

4. Die Algorithmen, die zur Erstellung digitaler Signaturen eingesetzt werden, gelten heute als sicher. Was aber passiert, wenn diese einmal gebrochen werden, ist nicht klar. Nehmen wir an, daß bestimmte Algorithmen nicht mehr sicher sind und jeder mit einfachsten Mitteln digitale Signaturen f¨ alschen kann. Nat¨ urlich werden diese Algorithmen zur Erstellung digitaler Signaturen nicht mehr zugelassen. Die Frage ist aber, was mit Dokumenten passiert, die in der Vergangenheit signiert wurden, zu einem Zeitpunkt, als die Algorithmen noch als sicher gegolten haben. In der Regel wird es dem Willen der Vertragspartner entsprechen, wenn ein Vertrag seine Rechtskraft beh¨ alt.

Problematisch wird es wenn jemand bestreitet den Vertrag signiert zu haben, denn dann fehlt letztendlich der Nachweis, daß das Dokument jemals signiert wurde, da die Algorithmen ja nicht mehr als sicher gelten. Zwar k¨ onnte man die digital signierten Dokumente zum Beispiel bei einem Notar hinterlegen lassen, aber das w¨ urde den Aufwand enorm erh¨ ohen und damit den digitalen Signaturen ihren Reiz, den elektronischen Gesch¨ aftsverkehr zu erleichtern, nehmen.

22 Grundbegriffe

Kapitel 3

OSI Referenz Modell

Netzwerkprotokolle werden in verschiedene Schichten unterteilt. Der Grund daf¨ ur ist, daß Netzwerke dadurch etwas an Komplexit¨ at verlieren. Zwar haben unterschiedliche Netzwerktypen verschiedene Schichten, aber trotzdem bieten eigentlich bei allen Netzwerkarten die darunterliegenden Schichten Services f¨ ur dar¨ uberliegende Schichten an. Das hat den Vorteil, daß man sich zum Beispiel als Entwickler einer Client-Server-Anwendung nicht mehr darum k¨ ummern muß, welche Hardware f¨ ur das Netzwerk eingesetzt wird oder wie die Pakete ihren Weg zum Ziel finden.

Das OSI Modell basiert auf einem Entwurf der International Standards Organization (ISO) (vgl. [DZ83]). Die Idee war, einen einheitlichen Standard f¨ ur Netzwerkprotokolle zu schaffen. Der Name OSI bedeutet ”Open Systems Interconnection”. Gew¨ ahlt wurde der Name, weil sich das Modell mit der Verbindung offener Systeme besch¨ aftigt, also mit Systemen, die offen sind, mit anderen Systemen zu kommunizieren (vgl. [Tan96], Seite 28).

3.1 Physical Layer

Der ”Physical Layer” (Bit¨ ubertragungsschicht) ist die unterste Schicht im OSI-Modell (vgl. Abbildung 3.1). Er definiert, wie Bits repr¨ asentiert werden. Beispielsweise wird festgelegt, welches Signal wie lange gesendet wird, um eine Eins darzustellen. Hier wird auch bestimmt, ob beide Seiten parallel eine ¨ Ubertragung durchf¨ uhren k¨ onnen.

3.2 Data Link Layer

Eine Schicht ¨ uber dem Physical Layer liegt der Data Link Layer (Verbindungssicherungsschicht). Aufgabe des Data Link Layers ist die ¨ Ubertragung von Daten zwischen zwei Punkten im Netzwerk. Das k¨ onnen unter Umst¨ anden zwei Rechner sein, aber auch ein Rechner und ein Router

23

oder zwei Router. Der Data Link Layer sorgt daf¨ ur, daß die Daten sicher beim anderen Punkt ankommen. Ist das nicht der Fall, k¨ onnen die Daten noch einmal geschickt werden. Zus¨ atzlich ist es Aufgabe des Data Link Layer daf¨ ur zu sorgen, daß Daten gepuffert werden, wenn der Empf¨ anger derzeit keine Daten annehmen kann.

F¨ ur diese Probleme gibt es verschiedene L¨ osungen, die jeweils ihre Vor- und Nachteile haben. Finden mehr Pr¨ ufungen statt, wird das Netzwerk langsamer. Werden weniger Pr¨ ufungen durchgef¨ uhrt, ist das Netzwerk zwar schneller, aber eventuell auftretende Fehler werden nicht oder erst auf h¨ oherer Ebene bemerkt und m¨ ussen dann dort korrigiert werden.

3.3 Network Layer

Der Network Layer (Netzwerkschicht) kontrolliert die Operationen in einem Subnetz. Wichtig ist hier, daß kontrolliert wird, wieviele Pakete zwischen Sender und Empf¨ anger verschickt werden. Die Routen zwischen Sender und Empf¨ anger k¨ onnen dabei statisch festgelegt oder auch dynamisch sein, sodaß jedes Netzwerkpaket auf einem anderen Weg zum Sender gelangt. Das kann zum Beispiel dann von Vorteil sein, wenn damit Engp¨ asse bei bestimmten Netzwerkteilen vermieden werden k¨ onnen. Der Nachteil dabei ist, daß Pakete m¨ oglicher Weise in der falschen

Reihenfolge ankommen k¨ onnen, da sie ¨ uber verschiedene Routen transportiert wurden.

Eine wichtige Rolle spielt nat¨ urlich die Netzwerkadressierung, sprich wie eine bestimmte Komponente im Netzwerk angesprochen werden kann. Verwenden unterschiedliche Netzwerke unterschiedliche Netzwerkadressierungsarten, kann das zu großen Problemen f¨ uhren, da die Adressierung erst konvertiert werden muß.

3.4 Transport Layer

Der Transport Layer (Transportschicht) erh¨ alt seine Daten vom Session Layer. Er unterteilt die Daten, wenn notwendig, in mehrere Pakete. Diese werden unter Umst¨ anden auf verschiedenen Wegen zum Empf¨ anger geschickt. Dabei kann die Reihenfolge durcheinander geraten, wenn ein Netzwerkpaket, das sp¨ ater geschickt wurde, fr¨ uher ankommt als eines, das bereits fr¨ uher abgeschickt wurde (vgl. Abbildung 3.2). Bei einigen Protokollen, wie etwa bei TCP (Transmission Control Protocol) (siehe Abschnitt 6.5), ist es die Aufgabe des Transport Layers, die richtige Reihenfolge wiederherzustellen.

Der Transport Layer ist auch die erste Schicht, die sich nicht mehr um das Routing zwischen Sender und Empf¨ anger k¨ ummern muß. Sie kann direkt Kontakt zum Empf¨ anger aufnehmen.

3.5 Session Layer

Der Session Layer (Verbindungsschicht) richtet, wie der Name schon sagt, eine Session (Sitzung) ein. In einer Session kann zum Beispiel ein Dialog mit einem anderen Rechner durchgef¨ uhrt oder

auch eine Datei ¨ ubertragen werden. Der Session Layer bietet bestimmte Checkpoints an, bei denen eine ¨ Ubertragung im Falle eines Abbruchs fortgesetzt werden kann. Das ist besonders dann wichtig, wenn eine gr¨ oßere Datei ¨ ubertragen werden soll. Bricht die Verbindung beispielsweise in der Mitte der ¨ Ubertragung ab, w¨ are es sehr l¨ astig, wenn man die ¨ Ubertragung wieder von

Anfang an beginnen m¨ ußte. Dieser Layer ist auch f¨ ur die Benutzerauthentifizierung zwischen zwei Rechnern zust¨ andig.

3.6 Presentation Layer

Der Presentation Layer (Datendarstellungsschicht) legt fest, wie die Daten f¨ ur die ¨ Ubertragung

codiert werden. Hier k¨ onnen Daten aber auch verschl¨ usselt oder komprimiert werden.

3.7 Application Layer

Der Application Layer (Anwendungsschicht) kommuniziert mit den Anwendungsprogrammen. Programme wie FTP, Sendmail oder auch Netscape schicken ¨ uber diesen Layer ihre Daten.

3.8 TCP/IP Reference Model 27

3.8 TCP/IP Reference Model

Ein anderes Netzwerkreferenzmodell ist das TCP/IP Reference Model. Entstanden ist dieses Modell durch das ARPANET (Vorl¨ aufer vom Internet), das vom DoD (U.S. Department of Defense), dem amerikanischen Verteidigungsministerium, in Auftrag gegeben wurde. Ziel des ARPANETs war es ein Netzwerk zu schaffen, das auch einen Atomkrieg ¨ uberstehen w¨ urde.

Selbst wenn ein Teil des Netzwerkes ausfallen sollte, w¨ urden die Pakete auf anderen Wegen noch immer zu ihren Zielen gelangen.

Das erste Mal wurde das TCP/IP Reference Model von Cerf und Kahn 1974 definiert (vgl. [Tan96], Seite 35).

3.8.1 Host-to-Network Layer

Das TCP/IP Reference Model definiert diese Schicht eigentlich nicht genauer. In der Literatur wird sie kaum behandelt.

3.8.2 Internet Layer

Der Internet Layer entspricht dem Network Layer im OSI-Modell (vgl. Abbildung 3.3). Zust¨ andig ist er f¨ ur das Routing, also der Weiterleitung der Pakete zur Zieladresse. Im Internet Layer wurde ein eigenes Protokoll definiert, n¨ amlich das IP (Internet Protocol).

3.8.3 Transport Layer

¨ Uber dem Internet Layer befindet sich der Transport Layer. Hier sind zwei Protokolle definiert, das TCP (Transmission Control Protocol) und das UDP (User Datagram Protocol). TCP ist zuverl¨ assig und verbindungsorientiert. Bei diesem Protokoll ist sichergestellt, daß die Daten auch tats¨ achlich beim Empf¨ anger ankommen. Verbindungsorientiert bedeutet, daß die Verbindung so lange offen bleibt, bis sie explizit geschlossen wird.

UDP hingegen ist unzuverl¨ assig und nicht verbindungsorientiert. Es ist somit nicht garantiert, daß die Daten wirklich den Empf¨ anger erreichen und auch nicht, daß die Daten in der richtigen Reihenfolge ankommen. Ben¨ otigt wird dieses Protokoll vor allem dann, wenn es wichtiger ist, daß die Daten schnell ankommen und Zuverl¨ assigkeit keine große Rolle spielt.

3.8.4 Application Layer

Der Session und der Presentation Layer werden im TCP/IP Model nicht verwendet, da die Praxis gezeigt hat, daß dieser Layer kaum ben¨ otigt werden (vgl. [Tan96], Seite 37).

28 OSI Referenz Modell

Im Application Layer werden Protokolle wie Telnet (vgl. Abschnitt 6.8), FTP (vgl. Abschnitt 6.10) oder SMTP (vgl. Abschnitt 6.11) angewendet. Die Liste der im Application Layer angewendeten Protokolle wird allerdings mit der Zeit immer gr¨ oßer, da st¨ andig neue Protokolle definiert werden.