Sicherheitsprotokolle im Internet

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Die Entwicklung des Sicherheitsproblems im Internet

2 Der TCP/IP-Protokollstack
2.1 Die Netzwerkschicht
2.1.1 Internet Protocol (IP)
2.1.2 Internet Control Message Protocol (ICMP)
2.1.3 Address Resolution Protocol (ARP)
2.2 Die Transportschicht
2.2.1 Transmission Control Protocol (TCP)
2.2.2 User Datagram Protocol (UDP)

3 Kryptographische Basisverfahren
3.1 Verschlüsselungsverfahren
3.2 Kryptographische Prüfsummen und digitale Signaturen
3.3 Zertifikate

4 Sicherheitsprotokolle im Internet
4.1 Internet Protocol Security (IPSec)
4.1.1 Security Association Database
4.1.2 Authentication Header (AH)
4.1.3 Encapsulation Security Payload (ESP)
4.2 Secure Sockets Layer (SSL)
4.2.1 Das Handshake Protokoll
4.2.2 Das Record Protokoll
4.3 Secure Electronic Transaction (SET)
4.3.1 In SET benötigte Zertifikate und Verschlüsselungsalgorithmen
4.3.2 Der SET-Zahlungsprozess

5 Zusammenfassung und Ausblick

Literaturverzeichnis

Anhang
A Well-Known Port Numbers
B Port-Nummern von mit SSL gesicherten Anwendungen

Abbildungsverzeichnis

Abb. 2.1: Der TCP-IP Protokollstack

Abb. 2.2: Nachrichtentransport im TCP/IP-Protokollstack

Abb. 3.1: Schlüsselzertifikat im X.509-Format

Abb. 4.1: Einordnung der Sicherheitsprotokolle in den TCP/IP-Protokollstack

Abb. 4.2: Der Authentication Header (AH)

Abb. 4.3: Der Encapsulation Security Payload (ESP) Header

Abb. 4.4: Anwendungsfälle für die ESP-Modi

Abb. 4.5: Der Encapsulation Security Payload Header im Tunnelmodus

Abb. 4.6: SSL-Handshake

Abb. 4.7: Ablauf der Funktionen des Record-Protokolls

Abb. 4.8: Nachrichtenaustausch in SET

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Die Entwicklung des Sicherheitsproblems im Internet

Anfang der 70er Jahre entwickelte das amerikanischen Department of Defense (DoD) das ARPANet^[1], ein Netzwerk, dass heute als Internet bekannt ist. Dieses Netzwerk sollte Leitungsausfälle erkennen und automatische alternative Übertragungswege suchen. Die Lösung bestand darin, ein Netzwerk ohne zentrale Vermittlungsstelle aufzubauen, so dass bei einem Ausfall eines Netzwerkknotens die übrigen Rechner trotzdem weiter miteinander kommunizieren konnten. Diese Aufgabe erfüllte das dafür entwickelte Internet Protocol (IP), das eine verbindungslose und paketorientierte Kommunikation ermöglicht. Da nur das Militär Zugriff auf dieses damals noch geschlossene Netzwerk hatte, machte man sich um Sicherheitsfragen wie Authentizität, Integrität und Vertraulichkeit keine Gedanken. Auch als Mitte der 70er Jahre Universitäten, Bildungs- und Forschungseinrichtungen an das ARPANet angeschlossen wurden, kümmerte man sich nicht groß um Sicherheitsaspekte, da die paketorientierte Vermittlung selbst noch ein Experiment war. Erst als Anfang der 90er Jahre die Zahl der angeschlossenen Rechner explosionsartig stieg und vor allem der E-Commerce seinen Durchbruch hatte, waren Sicherheitsanforderungen dringend notwendig. Das Sicherheitsproblem bestand dabei für eine Person nicht nur aus dem Einbruch in seinen privaten Rechner, sondern auch aus dem Einbruch in einen Router, wodurch direkt mehrere Kommunikationsverbindungen abgehört werden konnten. Das erste Auftreten von so genannten Internet-Würmern in dieser Zeit verstärkte den Ruf nach sicheren Kommunikationsnetzen. Diese Probleme gelten auch heute noch, so dass Sicherheitsprotokollen eine große Bedeutung zukommt.^[2]

Um den Ablauf der Kommunikation im Internet zu verstehen, werden zunächst in Kapitel 2 die wichtigsten Protokolle des TCP/IP-Protokollstacks erklärt. In Kapitel 3 werden dann grundlegende kryptographische Verfahren erläutert, die in den in Kapitel 4 vorgestellten Sicherheitsprotokollen zum Einsatz kommen. Abschließend wird in Kapitel 5 eine Zusammenfassung und ein Ausblick gegeben.

2 Der TCP/IP-Protokollstack

Die an das Internet angeschlossenen Rechner weisen zusammen eine sehr heterogene Netwerktopologie auf. Um Daten im Internet auszutauschen bzw. damit Anwendungen über das Internet kommunizieren können, ist es notwendig, Kommunikationsregeln zwischen den beteiligten Systemen festzulegen. Solche Kommunikationsregeln sind in Protokollen definiert. Ein so komplexes Kommunikationssystem wie das Internet kann allerdings nicht alleine durch ein einziges Protokoll beschrieben werden, das sämtliche Aufgaben abdeckt. Es existieren daher mehrere Protokolle für das Internet, die jeweils auf eine Aufgabe spezialisiert sind, und sich zu der TCP/IP-Protokollfamilie^[3] zusammenfassen lassen. Diese einzelnen Protokolle lassen sich in vier funktionale Schichten einteilen: Die Datensicherungs^[4] -, die Netzwerk^[5] -, die Transport- und die Anwendungschicht (Abb. 2.1).

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Vgl. Raepple, S. 29

Abb. 2.1: Der TCP-IP Protokollstack

In diesem TCP/IP-Protokollstack baut jede Schicht auf den Dienstleistungen auf, die von der darunterliegenden Schicht bereitgestellt werden. Dadurch steigt mit der Höhe der Schicht neben dem Leistungsumfang auch der Abstraktionsgrad. Anwender und Entwickler können somit direkt auf die bereitgestellten (abstrakten) Funktionen einer höheren Schicht zugreifen, ohne die Dienstleistungen darunterliegender Funktionen verstehen zu müssen.^[6]

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Vgl. Raepple (1998), S. 32f.

Abb. 2.2: Nachrichtentransport im TCP/IP-Protokollstack

Werden nun Daten von einem Rechner zu einem anderen übertragen (z.B. eine Datei via FTP), durchlaufen sie zunächst auf der Senderseite alle Schichten bzw. Protokollebenen in absteigender Reihenfolge. Dabei hängt jede Schicht ihren protokollspezifischen Header an die Nutzdaten, der dazu benötigt wird, die Daten auf der jeweiligen Schicht korrekt zu verarbeiten. Auf der Datensicherungsschicht bestehen die Daten somit aus den Nutzdaten, dem Anwendung-Header, dem TCP/UDP-Header, dem IP-Header und dem Datensicherungs-Header (Abb. 2.2). Auf der untersten Schicht – der Datensicherungsschicht – werden die Daten dann über ein physisches Medium zu dem anderen Rechner übertragen. Der Rechner des Empfängers interpretiert zunächst den Datensicherungs-Header auf der Datensicherungsebene, löscht ihn und gibt die übrig gebliebenen Daten (d.h. Nutzdaten, Andwendung-, TCP/UDP- und IP-Header) an die darüberliegende Netzwerkschicht weiter. Diese und die darüberliegenden Schichten arbeiten die Daten analog ab, bis sie schließlich als reine Nutzdaten auf der Benutzeroberfläche des Empfängers ankommen.^[7]

Um den Datentransfer – ohne Sicherheitsmechanismen – im Internet verstehen zu können, werden die Protokolle der Transport- und der Netzwerkschichten des TCP/IP-Protokollstacks in den folgenden beiden Kapiteln näher erläutert.

2.1 Die Netzwerkschicht

2.1.1 Internet Protocol (IP)

Auf der Netzwerkschicht werden die unterschiedlichen Hardwareadressen der physikalisch vorhandenen, heterogenen Netzwerke der Datensicherungsschicht unter eine einheitliche, virtuelle Struktur abgebildet. Der Benutzer hat dadurch die Illusion eines einzigen homogenen Netzwerkes, dem Internet. Erreicht wird dies durch die Zuordnung einer 32 Bit langen IP-Adresse, die jeder an das Internet angeschlossene Rechner erhält und ihn eindeutig kennzeichnet.^[8]

Das Internet Protocol (IP) bietet den übergeordneten Schichten eine verbindungslose und unzuverlässige Übertragung, die auf den IP-Adressen basiert. Mit unzuverlässig ist gemeint, dass keine Garantie für die Zustellung der Daten, die in dieser Schicht Datagramme genannt werden, übernommen wird. So kann es vorkommen, dass Datagramme verzögert beim Empfänger ankommen, sich gegenseitig überholen oder sogar verloren gehen. Der Empfänger und der Sender werden dabei nicht informiert; dies ist die Aufgabe von Protokollen höher gelegener Schichten. Bei der Übertragung von Datagrammen, die zu einer logisch zusammenhängenden Sequenz gehören, ist es möglich, dass sie verschiedene Wege vom Sender zum Empfänger nehmen. Dieses Konzept hat den Vorteil, dass beim Ausfall einer Leitung die Datagramme ohne große Zeitverzögerung umgelenkt werden können und somit dennoch ihr Ziel erreichen.^[9]

Die Aufgabe der Weiterleitung von Datagrammen übernehmen so genannte Router. Diese Rechner sitzen zwischen mindestens zwei unterschiedlichen Netzwerken der Datensicherungsschicht. Bei dem Eintreffen eines Datagramms prüfen sie zunächst, ob die Empfänger-Adressse über ein lokal angeschlossenes Netz erreichbar ist. Ist dies der Fall, wird das Datagramm zugestellt. Ist die Empfänger-Adresse dagegen nicht in dem lokal angeschlossenen Netz vorhanden, wird das Datagramm an einen anderen Router weitergeleitet. Dies wird so lange weitergeführt, bis es schließlich den Zielrechner erreicht.^[10]

Eine weitere wichtige Funktion des Internet Protocols besteht in der Fragmentierung. Dieses Verfahren ermöglicht den Transport von Datagrammen durch Netze, die eine Datenpaketlängenbeschränkung aufweisen. So darf beispielsweise die Größe eines Datenpakets in einem Ethernet, ein so genannter Ethernetrahmen, maximal 1,5 kByte betragen, wobei für ein Datagramm 64 kByte erlaubt sind. Ein Router zerlegt daher das Datagramm in so kleine Fragmente, dass diese die Größenbeschränkung des Netzwerkes erfüllen. Da diese Fragmente ebenso wie die Datagramme die Möglichkeit haben, verschiedene Wege zum Zielrechner nehmen zu können, erhält jedes Fragment den gesammten IP-Header. Zusätzlich erhält jedes Fragment eine ID (z.B. einen Zähler), damit die Netzwerkschicht auf der Empfängerseite in der Lage ist, die einzelnen Fragmente in der richtigen Reihenfolge wieder zu einem Datagramm zusammenzusetzen.^[11]

2.1.2 Internet Control Message Protocol (ICMP)

Das Internet Control Message Protocol (ICMP) hat die Aufgabe Status- und Fehlermeldungen für das Internet Protocol, sowie für die in der Transportschicht angesiedelten Protokolle User Datagram Protocol (UDP) und Transmission Control Protocol (TCP) zu transportieren. Die wichtigsten Meldungen, die in Datagrammen verschickt werden, sind die folgenden:^[12]

- Echo Request und Echo Reply: Diese Meldungen kommen z.B. bei dem Programm ping zum Einsatz, um die Erreichbarkeit von Rechnern zu testen.
- Network unreachable: Ist ein Zielnetzwerk nicht erreichbar, so sendet der entsprechende Router diese Nachricht an den Sender zurück.
- Redirect: Diese Meldung schickt z.B. ein überlasteter Router an den Sender, um ihm mitzuteilen, dass er die Datagramme zu einem anderen Router schicken soll.

2.1.3 Address Resolution Protocol (ARP)

Das Address Resolution Protocol (ARP) hat die Aufgabe, die IP-Adressen in die zugehörigen Hardwareadressen zu konvertieren. Bevor das Internet Protocol Datagramme an die Datensicherungsschicht übergibt, überprüft es mit Hilfe des ARP, ob die IP-Adresse vorhanden ist. Dazu sendet das Address Resolution Protocol an jeden am lokalen Netzwerk angeschlossenen Rechner die gesuchte IP-Adresse. Besitz ein Rechner diese IP-Adresse, so sendet dieser seine Hardwareadresse zurück. Diese IP-Hardware-Adressen-Zuordnung wird im ARP-Cache gespeichert, damit bei einer erneuten Anfrage die gewünschte Hardwareadresse direkt zurückgegeben werden kann.^[13] Ist die Zieladresse nicht am lokalen Netz angeschlossen, so wird zunächst die Hardwareadresse des entsprechenden Routers ermittelt, der wiederum die Hardwareadresse des nächsten Routers ermittelt usw., bis schließlich die IP- bzw. Hardwareadresse des Zielrechners gefunden wird.^[14]

2.2 Die Transportschicht

2.2.1 Transmission Control Protocol (TCP)

Das Transmission Control Protocol (TCP) bietet – basierend auf dem verbindungslosen und unzuverlässigen Internet Protocol – einen verbindungsorientierten und zuverlässigen Kommunikationsdienst.

Dazu erzeugt TCP eine virtuelle Verbindung, die den miteinander kommunizierenden Anwendungen eine scheinbar permanente und exklusive Verbindung bietet. Auf Grund des Multiplexmechanismus von TCP ist es möglich, dass mehrere Anwendungen zweier Rechner parallel kommunizieren können. Um die verschiedenen Datenströme unterscheiden und sie den richtigen Anwendungen zuordnen zu können, werden den einzelnen Anwendungen so genannte Port-Nummern wahlfrei zugewiesen. Für bestimmte, häufig genutzte Anwendungen sind allerdings aus standardisierungsgründen feste Port-Nummern reserviert.^[15] Die Port-Nummer und die IP-Adresse des Rechners werden zu einem Socket zusammengefasst. Eine Verbindung zwischen den beiden Anwendungen zweier Rechner wird somit durch das Socket-Paar von Sender und Empfänger eindeutig gekennzeichnet.^[16]

Der kontinuierliche Datenstrom der Anwendungen wird in bis zu 64 kByte große Datenpakete aufgeteilt, die auf dieser Schicht Segmente genannt werden. Im Gegensatz zu den Datagrammen der Netzwerkschicht findet bei TCP eine Kontrolle über den richtigen Empfang der einzelnen Segmente statt. Dazu werden die Segment zunächst mit einer Sequenznummer versehen. Ist das erste Segment z.B. 100 Byte groß, erhält es die Sequenznummer 100. Ist das nächste Segment 23 Byte groß, erhält es die Nummer 123 usw. Der Empfänger quittiert jedes eingegangen Segment und kann anhand der Sequenznummern die Daten in der richtigen Reihenfolge an die entsprechende Anwendung weitergeben. Aus Durchsatzgründen muss allerdings nicht jedes Segment einzeln bestätigt werden. Es kann auch eine Bestätigung für einen Block aufeinander folgender Segmente versendet werden. Auf der Senderseite läuft für jedes verschickte Segment ein Timer. Sollte ein Segment verloren gehen, wird der Empfänger es nicht quittieren können und der Sender verschickt das Segment nach Ablauf des Timers einfach erneut.^[17]

Der Empfang eines fehlerhaften Segments wird mit Hilfe einer Prüfsumme^[18] erkannt. Dieser Wert wird vom Sender berechnet und in den Header des Segments eingetragen. Stimmt dieser Wert beim Empfang mit dem selbst errechneten nicht überein, ist das Segment verfälscht. Der Empfänger quittiert dieses Segment nicht und es wird ihm aufgrund des Timermechanismus erneut zugesendet.

Um den Empfänger vor Überlastung zu schützen und somit die Effizienz der Datenübertragung zu optimieren bietet das Transmission Control Protocol eine Flußsteuerung. Diese Flußsteuerung bietet die Möglichkeit den Datenfluß des Senders zu begrenzen, da ansonsten der Puffer des Empfängers überlaufen könnte. Dies ist z.B. notwendig, wenn die Anwendung des Empfängers die Daten nur recht langsam verarbeit. Der Puffer kann die Daten dann nicht schnell genug an die Anwendung weiterleiten, um Platz für den Empfang von neuen Daten zu schaffen. Bei einem vollen Empfangspuffer müssen neu ankommende Segmente verworfen und vom Sender erneut verschickt werden. Durch diese unnötige Sendewiederholung sinkt die Datenübertragungsrate. Um dies zu verhindern, kommt der Sliding-Window-Mechanismus zum Einsatz. Bei diesem Verfahren teilt der Empfänger dem Sender zunächst die Datenmenge mit, die er gerade bereit ist zu empfangen, d. h die aktuelle Puffergröße. Mit jedem versendeten Segment schließt sich das Fenster ein wenig, d.h. der Übertragungskredit des Senders sowie die freie Puffergröße des Empfängers sinken. Schrumpft der Kredit auf null, muss der Sender warten, bis das Fenster wieder geöffnet bzw. bis der Puffer wieder geleert wird. Die Erhöhung des Kredits geschieht durch den Empfänger. Sobald er ein empfangenes Segmente an die Anwendung weiterleitet kann, teilt er dem Sender die Größe des freien Pufferbereichs mit und erhöht somit wieder den Übertragungskredit.^[19]

Das Transmission Control Protocol bietet außerdem einen Duplexbetrieb. Anwendungen zweier Kommunikationspartner können dadurch gleichzeitig in beide Richtungen Daten austauschen.^[20]

Der Aufbau einer TCP-Verbindung wird mit Hilfe des „Three Way Handshakes“ durchgeführt, d.h. es werden drei Segmente zwischen dem Sender und dem Empfänger ausgetauscht, die dazu benötigt werden, die eigene Anfangssequenznummer dem jeweiligen Kommunikationspartner mitzuteilen:^[21]

1. Rechner A schickt Rechner B mit dem ersten Segment seine Startsequenznummer, die Port-Nummer seiner Anwendung und die Port-Nummer der Anwendung, mit der er kommunizieren möchte. Außerdem ist das SYN-Flag gesetzt, um zu signalisieren, dass eine Verbindung aufzubauen ist.
2. Rechner B bestätigt den Erhalt der Startsequenznummer durch das Senden einer Quittung. Zusätzlich wird das SYN-Flag gesetzt, um den Verbindungsaufbau zu bestätigen. Des Weiteren wird die Startsequenznummer von Rechner B mitgesendet.
3. Rechner A quittiert daraufhin den Erhalt der Startsequenznummer von Rechner B durch ein weiteres Segment. Beide Rechner kennen nun die Startsequenznummer des jeweils anderen Rechners und können mit dem Austausch von Datensegmente beginnen.

2.2.2 User Datagram Protocol (UDP)

Das User Datagram Protocol (UDP) bietet der übergeordneten Schicht im Vergleich zum Transmission Control Protocol lediglich die Möglichkeit, dass mehrere Anwendungen gleichzeitig miteinander kommunizieren können (Multiplexmechanismus). Dienste, wie die Datenflußsteuerung und die wiederholte Übertragung von verloren gegangenen oder fehlerhaft übertragenen Daten sind nicht vorhanden. Somit kann UDP keine Garantie für die korrekte Übertragung leisten und dem Empfänger wird ein möglicher Segmentverlust auch nicht mitgeteilt. Da die einzelnen Segmente nicht nummeriert sind und weder einzeln noch blockweise gesendet und quittiert werden, kann auch keine Garantie für die richtige Reihenfolge übernommen werden.^[22]

Der Vorteil von UDP liegt allerdings darin, dass empfangene Daten sofort an die Anwendung weitergegeben werden können, ohne dass sie überprüft und quittiert werden müssen. Dadurch können Realzeitkommunikationen schneller ablaufen.^[23]

[...]

^[1] Advanced Research Projects Agency Net

^[2] Vgl. Smith (1998) S. 34ff.; Raepple (1998) S. 3.

^[3] „TCP“ steht für „Transmission Control Protocol“ und „IP“ für „Internet Protocol“, den beiden Kernprotokollen des Internets.

^[4] Oft auch Netz-Zugangs-Schicht genannt; Vgl. Hein (1998), S. 66.

^[5] Oft auch Internet-Schicht genannt; Vgl. Hein (1998), S. 66.

^[6] Vgl. Raepple (1998), S. 28f.

^[7] Vgl. Raepple (1998), S. 31.

^[8] Vgl. Raepple (1998), S.33f.

^[9] Vgl. Raepple (1998), S. 38.

^[10] Vgl. Fuhrberg, Häger, Wolf (2001), S.15ff.

^[11] Vgl. Hein (1998), S. 115f.

^[12] Vgl. Fuhrberg, Häger, Wolf (2001), S17f.

^[13] Vgl. Hein (1998), S. 442.

^[14] Vgl. Braun (1999), S. 42ff.

^[15] Siehe Anh. A.1.

^[16] Vgl. Hein (1998), S. 245-249.

^[17] Vgl. Hein (1998), S. 256f.

^[18] Bei dieser Prüfsumme handelt es sich um einen sehr einfachen Algorithmus, der nicht die Eigenschaften der kryptographischen Prüfsumme (siehe 3.2) erfüllt.

^[19] Vgl. Hein (1998), S. 281-284.

^[20] Vgl. Raepple (1998), S. 40f.

^[21] Vgl. Busch, Wolthausen (2002), S. 87f.

^[22] Vgl. Raepple (1998), S. 41.

^[23] Vgl. Braun (1998), S. 39.