IT-Sicherheit für TCP/IP- und IoT-Netzwerke: Grundlagen, Konzepte, Protokolle, Härtung [2 ed.] 9783658334222, 9783658334239

Citation preview

Steffen Wendzel

IT-Sicherheit für TCP/IP- und IoT-Netzwerke Grundlagen, Konzepte, Protokolle, Härtung 2. Auflage

IT-Sicherheit für TCP/IP- und IoT-Netzwerke

Steffen Wendzel

IT-Sicherheit für TCP/IP- und IoT-Netzwerke Grundlagen, Konzepte, Protokolle, Härtung 2., aktualisierte und erweiterte Auflage

Steffen Wendzel Fachbereich Informatik, Hochschule Worms Worms, Deutschland

ISBN 978-3-658-33422-2 ISBN 978-3-658-33423-9  (eBook) https://doi.org/10.1007/978-3-658-33423-9 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018, 2021 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Planung/Lektorat: Sybille Thelen Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Meinen Eltern gewidmet.

Vorwort

Die Betrachtung der IT-Sicherheit von Netzwerken ist an sich kein grundlegend neues Thema. Im Gegenteil, es ist bereits seit Jahrzehnten ein ausgereiftes Forschungs- und Arbeitsgebiet für viele Menschen. Durch die immer weiter fortschreitende Durchdringung von IT-Technologie in unserem Alltag und die damit verbundene Verbreitung von Netzwerken und die zunehmende Interaktion zwischen bestehenden Netzwerken sind TCP/IP- und IoT-Netzwerke jedoch potenziell einer stetig steigenden Anzahl an Angreifern ausgesetzt. Derlei Angriffe stellen auch deshalb eine aktuelle und permanente Herausforderung dar, da ihre Perfektionierung zunimmt. Dieses Buch setzt sich mit den Grundkonzepten von TCP/IP- und IoT-Netzwerken und der zugehörigen IT-Sicherheit auseinander. Es erläutert Angriffe und Schutzmechanismen. Weiterhin führt das Buch in einige Vertiefungsthemen ein und verfolgt das Ziel, sowohl praxisrelevantes Know-how als auch grundlegende und aktuelle Forschungsideen in einem Werk zu vereinen. Aus Gründen der Lesbarkeit habe ich im Text auf eine permanente Unterscheidung hinsichtlich der Ausgereiftheit von erwähnten Methoden verzichtet. Das heißt, manch ein Schutzmechanismus mag bereits in vorhandene Netzwerkkomponenten und Netzwerkbetriebssysteme integriert sein, andere Schutzmechanismen wurden bisher hingegen nur unter Laborbedingungen erprobt und spiegeln den aktuellen Forschungsstand wider. Passend zum Buch gibt es eine Webseite, auf der Sie Zusatzmaterial, insbesondere Vorlesungsunterlagen, Links und Errata finden: https://linuxbuch.blogspot.com/ Ein mehrere hundert Seiten umfassendes Werk ist mit Sicherheit nie völlig frei von Fehlern. Eine Liste der aktuell bekannten Fehler finden Sie auf der oben genannten Webseite. Sollten Sie selbst einen Fehler finden, der nicht in der Fehlerliste der Buchwebseite enthalten ist, so würde ich mich über eine entsprechende E-Mail freuen, damit ich den Fehler bekanntmachen und für zukünftige Auflagen bereinigen kann. Einer Reihe von Menschen bin ich zu Dank verpflichtet. In erster Linie ist dies Sybille Thelen, meiner Lektorin vom Springer-Verlag. Sie hat mitten in der Manuskripterstellung einer Themenanpassung des Buchs zugestimmt und mir die dafür notwendige

VII

VIII

Vorwort

zusätzliche Schreibzeit gewährt. Ich danke Ralf Borchers, der die sprachliche Durchsicht des Manuskripts vornahm. Außerdem danke ich meinen Studentinnen und Studenten, die in meinen Vorlesungen durch Fragen und Hinweise halfen, Inhalte zu perfektionieren, was insbesondere dienlich war, um fehlende Annahmen zu explizieren und Illustrationen didaktisch zu verfeinern. Ich wünsche Ihnen bei der Lektüre dieses Buches viel Freude und hoffe, dass es Ihrer Begeisterung für das spannende Gebiet der TCP/IP- und IoT-Sicherheit zuträglich sein wird. Worms Mai 2021

Steffen Wendzel

Vorwort zur 2. Auflage

Für die zweite Auflage dieses Buches wurden sämtliche Inhalte aktualisiert und erweitert, wofür über 200 Änderungen vorgenommen wurden. Die bisher nur für Dozenten zugänglichen Lösungen zu selektierten Übungsaufgaben befinden sich nun zudem im Anhang des Buchs. Außerdem konnte ich dank der Rückmeldungen meiner Leserinnen und Leser einige Fehler korrigieren. Insbesondere sei an dieser Stelle erneut meinen Studierenden gedankt, sowie Sebastian Schön, meiner Doktorandin Frau Laura Hartmann und meinen Kollegen Prof. Dr. Christian Baun (HS Frankfurt), Prof. Dr. Zdravko Bozakov (HS Worms) und Prof. Dr. Herbert Thielen (HS Worms). Worms Mai 2021

Steffen Wendzel

IX

Inhaltsverzeichnis

1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Kapitelüberblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Für wen dieses Buch geschrieben wurde. . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Über den Autor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Teil I  Grundlagen 2

Grundlagen der Netzwerktechnik. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1 Reichweite von Netzwerken. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2 Netzwerktopologien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.3 Netzwerkarchitekturen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Datenpakete, Einkapselung und die Entwicklung von TCP/IP. . . . . . . 12 2.2.1 Einige Worte zum OSI-Modell. . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.2 OSI- vs. TCP/IP-Modell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.3 Das Hybridmodell von Tanenbaum. . . . . . . . . . . . . . . . . . . . . 15 2.3 Grundzüge des TCP/IP-Modells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.1 Link Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.2 Internet Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3.3 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.3.4 Application Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.3.5 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.4 Die wichtigsten Protokolle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.5 Link Layer: ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.5.1 Reverse-ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.5.2 Proxy-ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

XI

XII

Inhaltsverzeichnis

2.6

2.7

2.8 2.9

2.10 2.11 2.12

2.13 2.14

2.15

2.16

Internet Layer: IPv4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.6.1 IP-Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.6.2 Fragmentierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Internet Layer: ICMPv4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.7.1 ICMP-Types 0 und 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.7.2 ICMP-Type 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.7.3 ICMP-Type 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.7.4 ICMP-Type 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.7.5 ICMP-Types 9 und 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.7.6 ICMP-Type 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.7.7 ICMP-Type 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.7.8 Weitere ICMP-Typen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Internet Layer: IGMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.8.1 Der IGMPv2-Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Internet Layer: IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.9.1 IPv6-Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.9.2 IPv6 Header Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Internet Layer: ICMPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Transport Layer: UDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.11.1 Der UDP-Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Transport Layer: TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.12.1 TCP-Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.12.2 Sende- und Empfangspuffer. . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.12.3 Flusskontrolle (Flow-Control). . . . . . . . . . . . . . . . . . . . . . . . . 52 2.12.4 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.12.5 Kommunikationsphasen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Application Layer: DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Application Layer: HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.14.1 Aufbau des HTTP-Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.14.2 HTTP/2 und HTTP/3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Application Layer: DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2.15.1 Resource Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 2.15.2 Resolving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 2.15.3 Der DNS-Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.15.4 DNS-Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Application Layer: E-Mail- und Usenetprotokolle . . . . . . . . . . . . . . . . 70 2.16.1 POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 2.16.2 IMAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2.16.3 SMTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 2.16.4 NNTP (Usenet). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Inhaltsverzeichnis

XIII

2.17 Application Layer: sonstige Protokolle. . . . . . . . . . . . . . . . . . . . . . . . . 79 2.18 Ausblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 2.19 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 2.20 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 2.21 Übungsaufgaben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 3

Grundlagen der IT-Sicherheit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.2 Schutzziele der IT-Sicherheit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 3.3 Schwachstellen, Verwundbarkeiten und Co. . . . . . . . . . . . . . . . . . . . . . 90 3.4 Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.4.1 Discretionary Access Control (DAC). . . . . . . . . . . . . . . . . . . . 92 3.4.2 DAC-Erweiterungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 3.4.3 MAC und DAC: Das Bell-LaPadula-Modell. . . . . . . . . . . . . . 93 3.5 Authentifizierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.6 Privatsphäre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.6.1 Anonymität und Pseudonymität. . . . . . . . . . . . . . . . . . . . . . . . 97 3.6.2 Verkettbarkeit und Verfolgbarkeit . . . . . . . . . . . . . . . . . . . . . . 98 3.6.3 Überwachung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3.7 Schadsoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 3.7.1 Arten von Schadsoftware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 3.7.2 Schadsoftware-Mechanismen . . . . . . . . . . . . . . . . . . . . . . . . . 104 3.8 IT-Sicherheit: ein Trade-off samt Vorschriften. . . . . . . . . . . . . . . . . . . . 105 3.9 Science of Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 3.10 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.11 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 3.12 Übungsaufgaben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Teil II  Kryptografie 4

Einführung in die Kryptografie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 4.1 Einführung und Grundbegriffe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 4.2 Grundlegende Begriffe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.2.1 Verschlüsselung und Entschlüsselung als Abbildungen. . . . . . 116 4.2.2 Kryptografische Schlüssel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.2.3 Kryptosysteme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 4.2.4 Symmetrische und Asymmetrische Kryptografie. . . . . . . . . . . 118 4.2.5 Grundlegendes Angreifermodell . . . . . . . . . . . . . . . . . . . . . . . 118 4.3 HistorischeVerfahren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

XIV

Inhaltsverzeichnis

4.3.1 Transpositionschiffre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.3.2 Die Caesar-Chiffre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 4.3.3 Die Vigenère-Chiffre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.3.4 Die Vernam-Chiffre (One-Time-Pad). . . . . . . . . . . . . . . . . . . . 121 4.4 Kryptoanalyse für historische Chiffren . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.4.1 Skytale-Chiffre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.4.2 Caesar-Chiffre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.4.3 Kryptoanalyse der Vigenère-Chiffre . . . . . . . . . . . . . . . . . . . . 124 4.4.4 Kryptoanalyse der Vernam-Chiffre . . . . . . . . . . . . . . . . . . . . . 126 4.4.5 Weitere Anmerkungen zu historischen Chiffren . . . . . . . . . . . 127 4.5 Stromchiffren und Zufallszahlengeneratoren. . . . . . . . . . . . . . . . . . . . . 127 4.5.1 Zufallszahlengeneratoren (PRNG). . . . . . . . . . . . . . . . . . . . . . 127 4.5.2 Der RC4-Algorithmus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 4.5.3 Die A5/1- und A5/2-Algorithmen . . . . . . . . . . . . . . . . . . . . . . 130 4.6 Blockchiffren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 4.6.1 Der Data Encryption Standard (DES) . . . . . . . . . . . . . . . . . . . 131 4.6.2 Der Advanced Encryption Standard (AES). . . . . . . . . . . . . . . 137 4.6.3 Blockchiffren-Betriebsmodi. . . . . . . . . . . . . . . . . . . . . . . . . . . 138 4.7 Informationstheorie und Kryptografie. . . . . . . . . . . . . . . . . . . . . . . . . . 140 4.7.1 Grundzüge der Informationstheorie. . . . . . . . . . . . . . . . . . . . . 140 4.7.2 Informationstheorie in der Kryptografie . . . . . . . . . . . . . . . . . 143 4.7.3 Redundanz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 4.7.4 Sicherheit eines Kryptosystems. . . . . . . . . . . . . . . . . . . . . . . . 144 4.7.5 Abschätzung der Spurious Keys . . . . . . . . . . . . . . . . . . . . . . . 145 4.7.6 Unizitätsdistanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 4.8 Kryptografische Hashfunktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 4.8.1 Einweg-Hashfunktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 4.8.2 Kollisionsresistenz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 4.8.3 Geburtstagsangriff und Substitutionsattacke. . . . . . . . . . . . . . 149 4.8.4 Hashwertlänge im Kontext von Angriffen. . . . . . . . . . . . . . . . 150 4.8.5 Wörterbuchangriff (Brute-Force-Angriff). . . . . . . . . . . . . . . . 151 4.8.6 Hashwerttabellen und Regenbogentabellen. . . . . . . . . . . . . . . 151 4.8.7 Sicherheit von Hashfunktionen . . . . . . . . . . . . . . . . . . . . . . . . 153 4.8.8 Aufbau einer typischen Hashfunktion. . . . . . . . . . . . . . . . . . . 154 4.8.9 Message Authentication Codes (MAC). . . . . . . . . . . . . . . . . . 154 4.8.10 Hashfunktionen und Unix-Passwortdateien. . . . . . . . . . . . . . . 156 4.8.11 Hashfunktionen und Filesystem Intrusion Detection. . . . . . . . 157 4.8.12 Hashfunktionen und Software Ports. . . . . . . . . . . . . . . . . . . . . 157 4.8.13 Hashfunktionen und Hashbäume. . . . . . . . . . . . . . . . . . . . . . . 158 4.9 Asymmetrische Kryptografie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 4.9.1 Schlüsselaustausch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 4.9.2 Rivest-Shamir-Adleman-Algorithmus (RSA). . . . . . . . . . . . . 162

Inhaltsverzeichnis

XV

4.10 Digitale Signaturen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 4.11 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 4.12 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 4.13 Übungsaufgaben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 5

Weiterführende Themen der Kryptografie. . . . . . . . . . . . . . . . . . . . . . . . . . . 171 5.1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 5.2 Public Key Infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 5.2.1 Digitale Zertifikate und PKI-Bestandteile. . . . . . . . . . . . . . . . 172 5.2.2 Vertrauensmodelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 5.3 Virtuelle Private Netzwerke. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 5.3.1 IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 5.3.2 Transport Layer Security (TLS). . . . . . . . . . . . . . . . . . . . . . . . 183 5.4 Anonymität und Onion-Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 5.4.1 Grundzüge der Mixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 5.4.2 Angriffe gegen Anonymisierungssysteme. . . . . . . . . . . . . . . . 187 5.5 Visuelle Kryptografie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 5.6 Secure Multi-Party Computation und homomorphe Verschlüsselung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 5.6.1 Dining Cryptographers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 5.7 Geteilte Geheimnisse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 5.8 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 5.9 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 5.10 Übungsaufgaben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Teil III  Netzwerksicherheit 6

Einführung in die Netzwerksicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 6.1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 6.2 Angriff. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 6.2.1 Scanning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 6.2.2 Wireless Wardriving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 6.2.3 Protocol Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 6.2.4 Sniffer und Promiscuous Mode. . . . . . . . . . . . . . . . . . . . . . . . 199 6.2.5 Man-in-the-Middle- und Spoofing-Angriffe . . . . . . . . . . . . . . 199 6.2.6 Redirects (Routing-Angriffe). . . . . . . . . . . . . . . . . . . . . . . . . . 200 6.2.7 Denial-of-Service (DoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 6.2.8 Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 6.2.9 Social Engineering und Advanced Persistent Threats. . . . . . . 203 6.3 Verteidigung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 6.3.1 Firewalls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

XVI

Inhaltsverzeichnis

6.3.2 Intrusion Detection und Prevention. . . . . . . . . . . . . . . . . . . . . 206 6.3.3 Honeypots und Honeynets. . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 6.3.4 Sandboxing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 6.3.5 Threat Intelligence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 6.3.6 Social Engineering verhindern. . . . . . . . . . . . . . . . . . . . . . . . . 213 6.4 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 6.5 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 6.6 Übungsaufgaben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 7

Angriffe auf TCP/IP-Netzwerkprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 7.1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 7.2 Angriffe auf der Netzzugangsschicht. . . . . . . . . . . . . . . . . . . . . . . . . . . 218 7.2.1 Angriffe mit physikalischer Grobeinwirkung . . . . . . . . . . . . . 218 7.2.2 Jamming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 7.2.3 Eavesdropping (Sniffing). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 7.2.4 Falsche Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 7.2.5 Sicherheit von ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 7.3 Angriffe auf der Internetschicht. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 7.3.1 Reconnaissance (Aufklärung) . . . . . . . . . . . . . . . . . . . . . . . . . 222 7.3.2 IP-Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 7.3.3 Denial-of-Service-Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 7.3.4 Angriffe auf Basis von IP-Fragmenten . . . . . . . . . . . . . . . . . . 228 7.3.5 Grundlegende Angriffe auf das IP-Routing. . . . . . . . . . . . . . . 229 7.3.6 Weitere Anmerkungen zur Sicherheit von IPv6. . . . . . . . . . . . 233 7.3.7 Sicherheit von ICMPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 7.4 Angriffe auf der Transportschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 7.4.1 Sicherheitsaspekte von UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 234 7.4.2 Sicherheit von TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 7.4.3 Portscans mit TCP und UDP. . . . . . . . . . . . . . . . . . . . . . . . . . 236 7.5 Angriffe auf der Anwendungsschicht. . . . . . . . . . . . . . . . . . . . . . . . . . . 239 7.5.1 Anmerkungen zur Reconnaissance . . . . . . . . . . . . . . . . . . . . . 239 7.5.2 HTTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 7.5.3 DNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 7.5.4 E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 7.5.5 Angriffe auf DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 7.5.6 Telnet, R-Dienste und SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 7.5.7 NNTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 7.5.8 FTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 7.5.9 Sonstige historische Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . 249 7.5.10 Zusammenspiel mehrerer Protokolle. . . . . . . . . . . . . . . . . . . . 250 7.6 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Inhaltsverzeichnis

XVII

7.7 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 7.8 Übungsaufgaben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 8

Absicherung der Netzwerkschichten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 8.1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 8.2 Absicherung auf der Netzzugangsschicht . . . . . . . . . . . . . . . . . . . . . . . 255 8.2.1 Zutrittskontrolle und physikalischer Netzwerkzugang . . . . . . 256 8.2.2 Erwerb and Integration von Produkten/Dienstleistungen . . . . 256 8.2.3 Verfügbarkeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 8.2.4 Komponentenverwaltung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 8.2.5 MAC-Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 8.2.6 Denial-of-Serivce-Eindämmung . . . . . . . . . . . . . . . . . . . . . . . 260 8.2.7 Virtuelle LANs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 8.2.8 Absicherung des ARP-Caches. . . . . . . . . . . . . . . . . . . . . . . . . 261 8.2.9 IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 8.2.10 Kryptographische Sicherung von WLANs. . . . . . . . . . . . . . . . 263 8.3 Absicherung auf der Internetschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 8.3.1 Härtung des IPv4/IPv6-Stacks. . . . . . . . . . . . . . . . . . . . . . . . . 265 8.3.2 Firewalls für die IP-Kommunikation. . . . . . . . . . . . . . . . . . . . 265 8.3.3 SEND: Secure Neighbor Discovery Protocol . . . . . . . . . . . . . 266 8.3.4 Anmerkungen zu Internet-DDoS-Angriffen . . . . . . . . . . . . . . 267 8.4 Absicherung der Transportschicht. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 8.4.1 Firewalls und Angriffserkennung für TCP und UDP. . . . . . . . 267 8.4.2 Portscan-Detektion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 8.4.3 TCP-Härtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 8.5 Absicherung der Anwendungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . . 272 8.5.1 Generelle Anmerkungen zur Anwendungsschicht. . . . . . . . . . 272 8.5.2 Proxyserver und Co.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 8.5.3 HTTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 8.5.4 DNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 8.5.5 E-Mail-Protokolle: SMTP, IMAP und POP3. . . . . . . . . . . . . . 281 8.5.6 Absicherung von DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 8.5.7 NNTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 8.6 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 8.7 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 8.8 Übungsaufgaben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

XVIII

Inhaltsverzeichnis

Teil IV  Vertiefung 9 Netzwerksteganografie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 9.1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 9.2 Methoden der Netzwerksteganografie. . . . . . . . . . . . . . . . . . . . . . . . . . 294 9.2.1 Grundlegende Taxonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 9.2.2 Versteckmuster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 9.2.3 Spezifische Versteckmethoden. . . . . . . . . . . . . . . . . . . . . . . . . 298 9.3 Gegenmaßnahmen zur Netzwerksteganografie. . . . . . . . . . . . . . . . . . . 300 9.3.1 Detektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 9.3.2 Limitierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 9.3.3 Unterbindung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 9.4 Exkurs: Linguistische Steganografie. . . . . . . . . . . . . . . . . . . . . . . . . . . 306 9.5 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 9.6 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 9.7 Übungsaufgaben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 10 Sicherheit im Internet der Dinge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 10.1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 10.2 Schuld sind die anderen – der Cycle of Blame . . . . . . . . . . . . . . . . . . . 320 10.3 Standardisierung (und Zertifizierung) im IoT . . . . . . . . . . . . . . . . . . . . 321 10.4 Software-Updates (Patching). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 10.5 Smart Homes und Smart Buildings. . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 10.5.1 Kommunikationsprotokolle. . . . . . . . . . . . . . . . . . . . . . . . . . . 325 10.5.2 Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 10.5.3 Angriffsdetektion und Härtung . . . . . . . . . . . . . . . . . . . . . . . . 329 10.6 Industriesteueranlagen (Industrial Control Systems). . . . . . . . . . . . . . . 331 10.6.1 Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 10.6.2 Angriffsdetektion und Härtung . . . . . . . . . . . . . . . . . . . . . . . . 333 10.7 Stand der Verwendung von Kryptografie in IoT-Protokollen. . . . . . . . . 336 10.8 Generische IoT-Protokolle der Anwendungsschicht . . . . . . . . . . . . . . . 338 10.8.1 CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 10.8.2 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 10.9 IT-Sicherheit weiterer IoT-Domänen. . . . . . . . . . . . . . . . . . . . . . . . . . . 345 10.9.1 Mobile IoT-Systeme (Smart Cars und Co.). . . . . . . . . . . . . . . 345 10.9.2 Electronic Healthcare (eHealth). . . . . . . . . . . . . . . . . . . . . . . . 346 10.9.3 Landwirtschaft und Handwerk. . . . . . . . . . . . . . . . . . . . . . . . . 348 10.9.4 Altequipment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 10.10 Digitale Forensik für das IoT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 10.11 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

Inhaltsverzeichnis

XIX

10.12 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 10.13 Übungsaufgaben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Anhang A: Wichtige wissenschaftliche Zeitschriften und Tagungen. . . . . . . . . . 359 Anhang B: Ausgewählte Lösungen zu Übungsaufgaben. . . . . . . . . . . . . . . . . . . . 363 Stichwortverzeichnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Abkürzungsverzeichnis

ACL Access Control List AES Advanced Encryption Standard AH Authentication Header APT Advanced Persistent Threat ARP Address Resolution Protocol ARS Anti Replay Service BACnet Building Automation Control Networks BAN Body Area Network BAS Building Automation System BFR BACnet Firewall Router BLP Bell-LaPadula-Modell BSC Binary Symmetric Channel BSI Bundesamt für Sicherheit in der Informationstechnik CA Collision Avoidance - Certificate Authority CARP Common Address Redundancy Protocol CBC Cipher Block Chaining CCM Counter with CBC-MAC CFM Cipher Feedback Mode CGA Cryptographically Generated Address CoAP Constrained Application Protocol CoRE Constrained RESTful Environments (Link Format) CPS Cyber-physical System CS Carrier Sense CSMA Carrier Sense Multiple Access CSMA/CA CSMA/Collision Avoidance CSMA/CD CSMA/Collision Detection CTR Counter Mode CUING Criminal Use of Information Hiding (Initiative) DAC Discretionary Access Control XXI

XXII

DDC Direct Digital Control DEA Data Encryption Algorithm DES Data Encryption Standard DH Diffie-Hellman DHM Diffie-Hellman-Merkle DNS Domain Name System EAP Extensible Authentication Protocol ECB Electronic Code Book ECN Explicit Congestion Notification ECU Electronic Control Unit EDC Error Detection & Correction EIB European Interface Bus ESP Encapsulating Security Payload FDDI Fiber Distributed Data Interface FTP File Transfer Protocol GCM Galois/Counter Mode GMAC Galois Message Authentication Code GNU GNU is Not Unix (rekursives Akronym) GnuPG GNU Privacy Guard GPS Global Positioning System GSM Global System for Mobile Communications HAS Home Automation System HIDS Host-based Intrusion Detection System HMI Human Machine Interface HSRP Hot Standby Router Protocol HTTP Hyper-text Transfer Protocol ICMP Internet Control Message Protocol ICS Industrial Control System ICT Information and Communication Technology ICV Integrity Check Value IDS Intrusion Detection System IGMP Internet Group Management Protocol IKE Internet Key Exchange IoT Internet of Things IP(v4) Internet Protocol, version 4 IPS Intrusion Prevention System IPv6 Internet Protocol, version 6 IRC Internet Relay Chat ISN Initial Sequence Number (für das TCP-Protokoll) KNX Konnex LAN Local Area Network LTE Long-Term Evolution

Abkürzungsverzeichnis

Abkürzungsverzeichnis

MA Multiple Access MAC Medium Access Control - Message Authentication Code - Mandatory Access Control MIME Multipurpose Internet Mail Extensions MitM Man-in-the-Middle MLS Multilevel Security MQTT Message Queuing Telemetry Transport NIDS Network Intrusion Detection System NRU No Read-up NTP Network Time Protocol NWD No Write-down OFM Output Feedback Mode OSI Open Systems Interconnected OTP One-time Pad - One-time Password PAC Physical Access Control PC Protocol Channel PCAW Protocol (Switching Covert) Channel-aware Active Warden PDoS Permanent Denial-of-Service PGP Pretty Good Privacy PHB Per-hop Behavior PHCC Protocol Hopping Covert Channel PLC Programmable Logic Controls PSCC Protocol Switching Covert Channel PSK Pre-shared Key PRNG Pseudo Random Number Generator RARP Reverse Address Resolution Protocol RBAC Role-based Access Control RC4 Ron’s Code 4 RFC Request for Comments RIP Routing Information Protocol RNG Random Number Generator RSA Rivest, Shamir and Adleman RTP Real-time Transport Protocol RTU Remote Terminal Unit SA Security Association SBB Smart Building Botnet SCADA Supervisory Control And Data Acquisition SDP Session Description Protocol SEND Secure Neighbor Discovery SIP Session Initiation Protocol

XXIII

XXIV

Abkürzungsverzeichnis

SMC Secure Multi-Party Computation, auch mit SPMC abgekürzt SNMP Simple Network Management Protocol SOA Start of Authority SPMC Secure Multi-Party Computation, auch mit SMC abgekürzt SPI Security Parameter Index SRTP Secure Real-time Transport Protocol TCP Transmission Control Protocol TCPCT TCP Cookie Transactions TLD Top-level Domain TTL Time to Live UDP User Datagram Protocol USV Unterbrechungsfreie Stromversorgung UUCP Unix-to-Unix-Copy VCS Visual Crypto System VLAN Virtual Local Area Network VoIP Voice over IP VoLTE Voice over LTE VRRP Virtual Router Redundancy Protocol WEP Wired Equivalent Privacy WFP Website Fingerprinting WPA Wi-Fi Protected Access XCBC Extended CBC XMPP Extensible Messaging and Presence Protocol

1

Einführung

Unfortunately, many journalists and writers have been fooled into using the word ,hacker‘ to describe crackers; this irritates real hackers no end. The basic difference is this: hackers build things, crackers break them. – Eric Steven Raymond (2017) Zusammenfassung

Dieses Kapitel führt in die Thematik des Buches ein und motiviert die Auseinandersetzung mit der Thematik. Es gibt ferner einen Überblick über die einzelnen Kapitel.

1.1 Motivation Egal, ob Sie studieren, Freizeit-Autodidakt sind oder sich des Berufes wegen mit der Thematik dieses Buches auseinandersetzen. Egal, ob Sie Anwender, Spezialist oder Wissenschaftler sind. Unsere Gesellschaft befindet sich seit einigen Jahrzehnten im digitalen Umbruch, der uns alle betrifft. In den vergangenen zehn Jahren stieg die Bedeutung der digitalen Infrastruktur, insbesondere der Netzwerke, kontinuierlich an. Künstliche Intelligenz, Automation sowie die Fähigkeit, IT-Technologie anzuwenden und zu modifizieren, sind treibende Kräfte, die mit beeinflussen, welche geografischen Regionen florieren und welche destabilisiert werden oder unter einem Brain-Drain leiden werden [1, 2]. Parallel steigen die Fälle bekannt gewordener Angriffe auf Organisationen, samt zugehöriger Skandale um verlorengegangene (oft sensitive) Daten, stetig an. Kritische Infrastrukturen und Rüstungsunternehmen aus dem In- und Ausland sind oftmals sogar Ziele staatlich finanzierter Akteure. Vom jugendlichen Freizeitakteur bis zu ausgeklügelter Industriespionage findet sich derweil ein breites Spektrum © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-33423-9_1

1

2

1 Einführung

von Akteuren auf diesem weltweiten, digitalen Schlachtfeld. Heute sind Staaten, Unternehmen und Gesellschaften von digitaler Infrastruktur abhängig. Diese Abhängigkeit wird mit der Einführung neuer Technologien wie beispielsweise Holografie, Internetbasierter und Roboter-gesteuerter OPs in Krankenhäusern und autonomer Fahrzeuge weiter steigen. Doch ohne verlässliche, sichere Netzwerke können diese Technologien nicht problemfrei betrieben, angepasst und weiterentwickelt werden. Dies gilt für das Internet der Dinge nicht weniger als für traditionelle Netzwerke. Dieses Buch verfolgt den Anspruch, Ihnen das Kenntnis- und Verständnisfundament für diese Thematik zu liefern. Es enthält viele Verweise auf weiterführende Literatur sowie Übungsaufgaben, die den Lernprozess unterstützen.

1.2 Kapitelüberblick Im ersten Teil dieses Buches befassen wir uns zunächst mit den Grundlagen der Netzwerktechnik (Kap. 2). Betrachtet werden dabei insbesondere die wichtigsten Protokolle der TCP/IP-Welt: ARP, IPv4, IPv6, ICMPv4, ICMPv6, TCP, UDP sowie einige Protokolle der Anwendungsschicht, vornehmlich DNS, HTTP und einige E-MailProtokolle. Kap. 3 führt anschließend in die Grundbegriffe und Konzepte der IT-Sicherheit ein. Es setzt sich mit dem Thema der Authentifizierung, der Zugriffskontrolle, den Grundlagen der Privatsphäre und mit Schadsoftware auseinander. Außerdem erläutert es, weshalb IT-Sicherheit immer mit einem Trade-off verbunden ist und betrachtet die Wissenschaftlichkeit von IT-Sicherheit. Leser, die sich bereits mit den Grundlagen der Netzwerke und der IT-Sicherheit befasst haben, können diesen Teil des Buches überspringen und bei Bedarf auf ihn zurückgreifen. Der zweite Teil zum Thema Kryptografie beginnt mit einem Grundlagenkapitel, das fast alle für dieses Buch wichtigen Themen der Kryptografie erläutert. Beginnend mit den grundlegenden Konzepten wie kryptografische Schlüssel und kryptografische Funktionen befasst sich das Kapitel anschließend mit historischen Chiffren und ihrer Sicherheit, da durch das Studium historischer Verfahren viel über moderne Verfahren gelernt werden kann. Anschließend werden wichtige Strom- und Blockchiffren, Hashfunktionen und Methoden der asymmetrischen Kryptografie betrachtet. Angewandte Themen der Kryptografie, nämlich Public Key Infrastructure, Virtuelle Private Netzwerke, Anonymität und Onion Routing sowie einige Spezialthemen, etwa verteilte Geheimnisse und visuelle Kryptografie, finden sich in Kap. 5. Teil drei des Buchs befasst sich mit der Netzwerksicherheit und baut auf den Grundlagen der ersten zwei Teile auf. Zunächst führt Kap. 6 in die wichtigsten Angriffstechniken und Verteidigungsmethoden für Netzwerke ein. Detailliert werden Angriffstechniken anschließend in Kap. 7, das sich mit jeder Schicht des TCP/IPModells separat befasst. Das Gegenstück zu Kap. 7 bietet Kap. 8: Es befasst sich schichtenweise mit der Sicherung der Netzwerkkommunikation. Sowohl Kap. 7 als auch Kap. 8 legen einen besonderen Fokus auf die jeweils eingesetzten Netzwerkprotokolle.

1.4  Über den Autor

3

Schließlich befasst sich der vierte Teil des Buches mit Vertiefungsthemen der Netzwerksicherheit. Kap. 9 führt zunächst in die Grundlagen der Netzwerksteganografie ein, beginnend mit der Terminologie und Taxonomie bis hin zu Verstecktechniken und einem Überblick über Möglichkeiten der Detektion, Limitierung und Verhinderung verdeckter Kommunikation. Eine ausführliche Betrachtung des Internet of Things liefert Kap. 10. Zunächst werden generelle Aspekte der IT-Sicherheit für das Internet of Things betrachtet und im Anschluss spezifische Gebiete im Detail betrachtet, nämlich Smart Buildings und Industriesteueranlagen. Die Sicherheit von Kommunikationsprotokollen in Automationsumgebungen und von typischen Protokollen des Internet of Things wird ebenfalls betrachtet. Das Kapitel schließt mit einer Einführung in die digitale Forensik für das Internet of Things. Im Anhang findet sich eine Liste bedeutsamer Fachzeitschriften und Fachtagungen aus dem Bereich der Netzwerk- und Internet-of-Things-Sicherheit. Es lohnt sich, periodisch einen Blick in derlei Organe zu werfen, da sie bereits in der Vergangenheit immer wieder bedeutsame Beiträge zur IT-Sicherheit lieferten und den jeweils aktuellen Stand der Forschung adressieren. Viele der im Buch verwendeten Quellen stammen aus diesen Fachzeitschriften und -tagungen. Ein weiterer Teil des Anhangs stellt Lösungen zu selektierten Übungsaufgaben vor.

1.3 Für wen dieses Buch geschrieben wurde Dieses Buch wurde so verfasst, dass ein breites Spektrum interessierter Personen von ihm profitieren kann, sowohl Praktiker, als auch Theoretiker. Vom Experten, der sich für einzelne Kapitel interessiert, bis hin zum Auszubildenden, der eine verständliche Einführung in die Thematik sucht, möchte es jedem Leser interessante Inhalte bieten. Für akademische Leser zu praktische Inhalte (etwa Details zu Konfigurationsdateien von Diensten) und für Professionals zu wenig bedeutsame (etwa stark mathematische/ formale) Inhalte wurden, wann immer es möglich war, ausgelassen.

1.4 Über den Autor Steffen Wendzel ist seit 2016 Professor für IT-Sicherheit und Netzwerke an der Hochschule Worms. Dort ist er zudem stellv. wissenschaftlicher Leiter des Zentrums für Technologie und Transfer (ZTT). Von 2013 bis 2016 leitete er ein Forschungsteam am Fraunhofer FKIE in Bonn und befasste sich dort mit der IT-Sicherheit von Smart Buildings. Er studierte Informatik (Dipl.-Inf. (FH), 2009) an der Hochschule Kempten. Im Anschluss promovierte und studierte er parallel an der FernUniversität in Hagen (Dr. rer. nat., 2013) und an der Hochschule Augsburg (M.Sc., 2011). Der Autor habilitierte sich im Jahr 2020 (ebenfalls an der FernUniversität in Hagen). Seine Forschungsarbeiten wurden in der nationalen und internationalen Presse besprochen. Steffen

4

1 Einführung

Wendzel veröffentlichte über 150 Werke, darunter sechs Fachbücher sowie diverse Tagungs- und Fachzeitschriftenbeiträge. Er ist Mitglied der Editorial Boards der Fachzeitschriften Frontiers in Computer Science, Journal of Universal Computer Science (J.UCS) und Journal of Cybersecurity and Mobility (JCSM). Zudem wirkt(e) er als Gasteditor für diverse Journale, etwa IEEE Trans. Industrial Informatics (TII), Elsevier Future Generation Computer Systems (FGCS) und IEEE Security & Privacy (S&P) sowie als Organisator diverser Tagungen. Die Webseite des Autors ist unter der Adresse https://www.wendzel.de zu finden.

Literatur 1. Ross, A.: The Industries of the Future. How the Next 10 Years of Innovation Will Transform Our Lives at Work and Home. Simon & Schuster, London (2016) 2. Frey, C.B.: Und tschüss, Mitarbeiter! DIE ZEIT Ausgabe 5 (2018)

Teil I Grundlagen

Dieser Teil führt Sie in die Grundlagen der Netzwerktechnik und in die Grundlagen der IT-Sicherheit ein. Er dient als Fundament für das Verständnis der folgenden Kapitel. Wenn Sie sich bereits mit diesen Themen befasst haben, dann können Sie diesen Teil des Buches überspringen und Einzelheiten bei Bedarf nachlesen.

2

Grundlagen der Netzwerktechnik

Today more than ever before, networking is a hot topic. – Christian Benvenuti (2006) Zusammenfassung

Dieses Kapitel befasst sich mit den Grundlagen der Netzwerktechnik. Insbesondere werden dabei selektierte Aspekte betrachtet, die zum Verständnis des restlichen Buches notwendig sind. Sie erhalten ein Verständnis für die Funktionsweise und die Fähigkeiten von diversen Netzwerkprotokollen. Zum einen ist dies notwendig, um Angriffe zu verstehen. Zum anderen, damit Schutzmechanismen nachvollziehbar sind.

2.1 Einführung Um1 die in den nächsten Kapiteln fokussierten Aspekte verstehen zu können, liefert Ihnen dieses Kapitel zunächst eine Einführung in die Grundlagen der Netzwerktechnik. Das Kapitel konzentriert sich dabei primär auf TCP/IP, da sich ein Großteil der Netzwerksicherheit auf TCP/IP konzentriert und TCP/IP in den folgenden Kapiteln immer wieder

Am Eingangszitat von Benvenuti hat sich in den letzten fünfzehn Jahren nichts geändert; dies gilt auch fór die anderen historischen Zitate, die Sie in diesem Buch finden werden. 1Einige

Inhalte dieses Kapitels basieren auf meinem Buch Tunnel und verdeckte Kanäle im Netz (Springer-Vieweg, 2012) [29]. Sie wurden für dieses Buch grundlegend überarbeitet, korrigiert und aktualisiert.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-33423-9_2

7

8

2  Grundlagen der Netzwerktechnik

aufgreifen wird. Für den Fall, dass Sie sich bereits mit TCP/IP auskennen, können Sie dieses Kapitel überspringen oder einzelne Abschnitte im Bedarfsfall nachlesen. Kommunikation kann als eine der zentralen Notwendigkeiten (moderner) Gesellschaften betrachtet werden. Rechnernetze (Computernetzwerke2) dienen dabei der Kommunikation von elektronischen Daten (Datenkommunikation) über physikalische Medien. Sie verbinden Computer (beliebiger Art) miteinander. Übertragen werden dabei Inhalte jedweder Art über unterschiedlichste Distanzen; sie können im Bereich von Zentimetern (Kreditkarte ↔ Kartenleser) oder Millionen von Kilometern (Erde ↔ Voyager) liegen. Rechnernetze benutzen verschiedenste Medien mit unterschiedlichen Eigenschaften (dies betrifft etwa die Datenrate und die Störanfälligkeit eines Mediums) zur Übertragung von Daten. Dabei kann es sich zum Beispiel um eine Funkverbindung, ein Kupferkabel oder eine Glasfaser-Verbindung handeln. Computer, die mit einem Netzwerk arbeiten sollen, benötigen entsprechend eine Netzwerkkarte, eine Verbindung zum Netzwerk über diese Netzwerkkarte (per Kupferkabel, Funk, …) und ein netzwerkfähiges Betriebssystem. Netzwerke unterscheiden sich in ihrer Reichweite, ihrer Topologie, Architektur, den ermöglichten Kommunikationsrichtungen und -relationen sowie weiterer Attribute.

2.1.1 Reichweite von Netzwerken Netzwerke können unterschiedliche Reichweiten aufweisen. Sogenannte Body Area Networks (BANs) sind nur im Bereich weniger Zentimeter bis etwa zwei Meter im Einsatz und werden beispielsweise bei Wearables, also tragbaren, oftmals in die Kleidung integrierten Computern verwendet. Local Area Networks (LANs) sind Netzwerke innerhalb eines Unternehmens beziehungsweise einer Organisation oder auch einer Wohnung/eines Hauses. Metropolitain Area Networks (MAN) sind bereits Netze, die sich über eine ganze Stadt ziehen können. Sie können etwa die Kommunikationsbasis zwischen den auf eine Stadt verteilten Gebäuden einer Hochschule darstellen. Wide Area Networks (WAN) kennen wiederum keine geografische Beschränkung und sind Netzwerke, die über die Grenzen einer Stadt oder Region hinausgehen. Ein WAN kann auch länder- und kontinentübergreifend sein. Das größte WAN – das Internet – umfasst den gesamten Globus sowie angrenzende Teile des Weltraums (Satelliten). Verbindungen mit höherer Distanz gibt es nur zu einigen Raumsonden.

2Es

gibt auch Netzwerke, die keine Computernetze sind, etwa Telegrafen-Netzwerke oder das Turnschuhnetzwerk von Tanenbaum [27], das heißt Daten werden (etwa auf USB-Sticks) „zu Fuß“ übertragen, statt über ein Computernetzwerk.

2.1 Einführung

9

Abb. 2.1   Klassische Netzwerktopologien: (a) Punkt-zu-Punkt-, (b) Bus-, (c) Ring-, (d) Stern-, (e) Mesh-Topologie

2.1.2 Netzwerktopologien Topologien beschreiben die Struktur eines Netzwerks. Grundlegend unterscheidet man zwischen Punkt-zu-Punkt-, Bus-, Ring-, Stern- und Mesh-Topologie (siehe Abb. 2.1). Die Punkt-zu-Punkt-Topologie ist die einfachste. Es gibt genau eine direkte Verbindung zwischen zwei Computern (auch Knoten oder Nodes genannt). Bei der Bus-Topologie führt ein zentrales Kabel zu allen Knoten. Neue Knoten werden gesondert und einzeln an dieses Kabel angeschlossen. Die Enden der Buslinien müssen terminiert werden (dadurch wird das Kommunikationssignal terminiert). Anders ist dies bei der Ring-Topologie. Jeder Knoten besitzt genau einen linken und einen rechten Nachbarn. Über diese Nachbarknoten ist jeder Knoten indirekt mit weiteren Knoten verbunden. Nachrichten werden jeweils weitergeleitet. Bei der Stern-Topologie besitzt jeder Knoten eine separate Verbindung zu einer zentralen Verteilereinheit (etwa ein Hub oder Switch). Diese Topologieform findet sich in einem Großteil der heutigen Netzwerke. In Mesh-Netzwerken kooperieren alle Knoten eines Netzwerks bei der Zustellung von Daten. Nachrichten werden entweder durch Flutung (Flooding, das heißt Weiterleiten an alle bekannten Nachbar-Knoten eines Knotens, außer dem, von der die Nachricht empfangen wurde) oder durch Routing (gezieltes Weiterleiten) zugestellt. Derartige Netze sind oftmals hochgradig dynamisch. So werden sie etwa zwischen fahrenden Autos spontan aufgebaut und sind entsprechend einer permanenten Veränderung unterworfen. Ebenfalls ist es machbar, mobile Mesh-Netzwerke zwischen Drohnen aufzubauen.

2.1.3 Netzwerkarchitekturen Neben den grundlegenden Topologien können Netzwerke auch in verschiedene Architekturtypen eingeteilt werden.

10

2  Grundlagen der Netzwerktechnik

2.1.3.1 Klassische Architekturen In der klassischen monolithischen Architektur gibt es einen zentralen Rechner (in der Regel eine sog. Mainframe, also einen Großrechner) mit angebundenen Terminals, die selbst keine Rechenkapazität aufweisen, und nur als Ein- und Ausgabegeräte für die Mainframe dienen. Durch diese Architektur konnten schon Mitte des 20. Jahrhunderts viele Benutzer gleichzeitig Gebrauch von einem zentralen Rechner machen. Hierfür war die Einführung von Multiuser-Multitasking-Betriebssystemen erforderlich. Heutige Betriebssysteme können so etwas mit Leichtigkeit umsetzen. Bei der insbesondere ab den 80er-Jahren und auch noch heute häufig vorkommenden Client-Server-Architektur erfolgt eine Verteilung der Zuständigkeiten im Netzwerk zwischen einem sog. Client und einem sog. Server. Der Client stellt dabei Anfragen an den Server, der diese Anfragen beantwortet. Server verfügen in der Regel über deutlich mehr Rechenkapazität und mehr Speicher als Clients. Server können ihre Ressourcen durch diese hohe Rechenleistung gleichzeitig vielen Clients zur Verfügung stellen, was diese Architektur relativ kostengünstig macht. Mehrere Clients können üblicherweise gleichzeitig auf einen Server zugreifen, d. h. ohne sich in eine Warteschlange einreihen zu müssen. Bei einem Webrowser wie Firefox handelt es sich beispielsweise um einen Client, der wiederum auf einen Webserver zugreift. Analog gilt dies etwa für MailClients und Mail-Server. Ein zentraler Vorteil des Verfahrens liegt zudem noch darin, dass Daten nicht auf jedem Client separat gehalten und aktualisiert werden müssen, weil sie an zentraler Stelle (also auf dem Server) liegen. Eine Webseite kann dadurch auf dem Server aktualisiert werden, und allen Clients wird automatisch die jeweils aktuelle Version dieser Webseite bereitgestellt. Nachteilig ist, dass ein Server hierbei der Single Point of Failure ist: fällt er aus, kann der entsprechende Dienst gar nicht mehr erbracht werden. Für solche Fälle gibt es jedoch vorbeugende Maßnahmen (Redundanz, Lastverteilung etc.) Während bei der monolithischen und der Client-Server-Architektur kein Gleichgewicht zwischen den teilnehmenden Geräten herrscht, ist dies bei der sog. Peer-to-PeerArchitektur (auch P2P-Architektur) anders. Bei dieser Architektur tragen alle Teilnehmer („Peers“) gleichberechtigt zum Netzwerk teil. Jeder Peer kann Anfragen an andere Peers stellen und selbst Anfragen von diesen erhalten und beantworten. Ein typisches Beispiel hierfür ist das Filesharing, bei dem Nutzer im Netzwerk gleichberechtigt Dateien austauschen (selbst bereitstellen und wiederum von anderen Peers herunterladen). 2.1.3.2 Cloud-, Edge- und Fog-Computing Bei der Cloud-Computing-Architektur wird ein Teil der Netzwerktechnik an eine externe Organisation ausgelagert. Die externe Organisation ist dabei in der Regel ein Provider, der mindestens Server im Netzwerk bereitstellt, die temporär von einem Kunden gemietet werden können. Der Vorteil dieser Architektur besteht grundlegend darin, dass dynamisch Ressourcen angemietet und wieder freigegeben werden können. Anders formuliert können sich Cloudlösungen relativ gut an sich dynamisch ändernde Bedarfe

2.1 Einführung

11

von Endnutzern anpassen. Müssen für umfangreiche Berechnungen etwa einige Server gemietet werden, so werden diese nach Beendigung der Berechnungen wieder freigegeben. Es existieren verschiedene Modelle dieser Architektur. Beim Infrastrukturbasierten Cloud Computing (sog. Infrastructure as a Service, IaaS) wird dem Benutzer eine Hardware mit Netzwerkanschluss bereitgestellt; der Nutzer spielt wiederum seine Systemsoftware (ggf. inkl. Betriebssystem) sowie restliche Software darauf auf. Beim Plattform-basierten Cloud Computing (Platform as a Service, PaaS) wird zusätzlich zur reinen Hardware auch ein vorkonfiguriertes Betriebssystem mit weiterer Systemsoftware und eine Softwareplattform, oftmals zur Softwareentwicklung in der Cloud, bereitgestellt. Zudem existiert ein Software-basiertes Modell (Software as a Service, SaaS), bei dem eine lauffähige Softwarelösung in der Cloud bereitgestellt wird, bspw. für eine Kundenverwaltung, Textverarbeitung oder einen Webshop. Im Kern basiert Cloud Computing auf der Client-Server-Architektur – Lösungen wie beispielsweise netzwerkbasierten Datenspeicher gab es bereits in den 80er Jahren. Im Vergleich zur Client-Server-Architektur wurden allerdings die Dienstleistungen präzisiert und nutzerorientierter gestaltet. Bei der Edge-Computing-Architektur wird versucht, einzelne Nachteile aus dem Cloud Computing zu eliminieren. Problematisch ist bei Cloudlösungen etwa, dass durch die Distanz zwischen einem Client und einem Cloudserver eine gewisse Verzögerung (Latenz) entstehen kann. Im Edge Computing wird hingegen versucht, Interaktionen, die zeitnah zwischen dem Endnutzer und einem Service (der sich ansonsten in der Cloud befinden würde) durchgeführt werden müssen, in der Nähe des Endnutzers zu platzieren. Nähe heißt hierbei, dass der Service nur wenige Routinghops entfernt ist. Entsprechend verringert sich die Latenz. So könnte etwa netzwerkbasierter Datenspeicher im lokalen Netzwerk des Endnutzers gehostet werden, während das System zur Datenspeicherung die Daten wiederum über eine (ggf. langsame) Verbindung nach und nach in die Cloud überträgt, um dort weitere Analysen durchführen zu lassen. Außerdem können solch zwischengelagerte Systeme auch Daten vorfiltern, das heißt, es müssen nicht sämtliche Daten in eine Cloud übertragen werden. Auch können bereits Vorberechnungen durchgeführt werden, die unabhängig von Cloudsystemen sind, und Resultate somit zeitnaher zur Verfügung gestellt werden. Populär ist die Edge-Computing-Architektur insbesondere für das Internet der Dinge, da viele kleine, aber oftmals rechenschwache Geräte ansonsten vollständig von Clouddiensten abhängig wären. Insbesondere bei Sensoren (etwa aus der Heimautomation oder bei Fitnesstrackern) sollten nicht permanent sämtliche Daten über viele Hops in die Cloud übertragen werden, wenn diese Daten durch Edge-Geräte aggregiert und voranalysiert werden können. Die Fog-Computing-Architektur überschneidet sich mit der Edge-ComputingArchitektur. Im Kern unterscheiden sich beide Ansätze nur darin, dass beim Fog Computing darauf geachtet wird, dass die Datenverarbeitung auf Edgesystemen stattfindet, an die die Daten des Endgeräts (also bspw. ein Temperatursensor oder ein Smartphone) gesendet werden. Beim Edge Computing kann ein Großteil der Datenverarbeitung hingegen direkt auf dem Endgerät stattfinden. In diesem Buch werden die Begriffe Edge Computing und Fog Computing synonym verwendet.

12

2  Grundlagen der Netzwerktechnik

2.2 Datenpakete, Einkapselung und die Entwicklung von TCP/IP Daten werden in Netzwerken in Form von Paketen oder Frames, das sind Einheiten einer definierten Größe und Struktur, übertragen. In diesen Paketen werden sowohl Steuerinformationen, als auch die eigentlichen Nutzdaten übertragen. Steuerinformationen (auch Metadaten) regeln und beschreiben die Netzwerkkommunikation. Sie legen etwa fest, welcher Knoten der Sender und welcher Empfänger eines Pakets ist oder wie viele Nutzdaten in einem Paket enthalten sind. Nutzdaten stellen aus Benutzersicht die eigentlichen Daten dar. Es handelt sich dabei etwa um Daten eines Downloads, einer Webseite, eines Videostreams oder einer Sprachübertragung. Auch der Inhalt einer E-Mail stellt Nutzdaten dar. Damit verschiedene Computer sich gegenseitig „verstehen“ können, müssen sie dieselbe „Sprache“ sprechen, denn sonst wüsste Computer A nicht, wie die Daten, die Computer B über das Netz an ihn sendet, zu interpretieren sind und wie auf diese Daten zu antworten ist. Geregelt werden die Kommunikationsabläufe und die Aufbauten der Datenpakete daher durch sogenannte Kommunikationsprotokolle. TCP/IP stellt eine Suite solcher Protokolle dar. Diese Protokollsuite ist das Resultat der ursprünglich für den militärischen Kontext angedachten Netzwerkprotokolle des ARPANET, dem Vorgänger des heutigen Internets. Die Entwicklung des ARPANET begann 1968 [28]. Die militärische Forschungsförderung ermöglichte damals die Entwicklung der TCP/IP-Protokolle, doch muss auch darauf hingewiesen werden, dass das Internet erst mit seiner Öffnung für den nicht-militärischen Bereich und durch kreative Entwickler der Universitäten und der freien Software Community sowie der privaten Industrie zum großen Erfolg wurde [14, 24]. Tatsächlich beruht ein überraschend großer Anteil der wichtigsten Entwicklungen des Internets auf Hobbyisten und Forschern [24]. Die TCP/IP-Protokolle sind durch sogenannte Request for Comments (RFC) spezifiziert. Zugriff auf jedes veröffentlichte RFC erhalten Sie unter [23]. Die Anzahl der TCP/IP-Protokolle ist mittlerweile relativ beachtlich und ein Großteil dieser Protokolle wurde standardisiert. Die Buchstaben TCP stehen dabei für das Transportprotokoll Transmission Control Protocol, die Buchstaben IP für Internet Protocol. TCP/IP verwendet eine Kommunikationsarchitektur mit mehreren Schichten. Diese Kommunikationsarchitektur ist dabei ähnlich wie das OSI-Modell3 der ISO,4 siehe Abschn. 2.2.1, aufgebaut (Abb. 2.2). Die Systeme, die das OSI-Modell implementieren, werden als Open Systems bezeichnet, da sie anderen Systemen zur Kommunikation „offen“ stehen – schließlich sind die verwendeten Protokolle publiziert und damit nicht geheim [26]. Im Gegen-

3Open

Systems Interconnection Reference Model. Organization for Standardization.

4International

2.2  Datenpakete, Einkapselung und die Entwicklung von TCP/IP

13

Abb. 2.2   Das TCP/IP- und das OSI-Modell

satz dazu wäre ein Closed System eines mit proprietären Netzwerkschnittstellen. Ein Closed System könnte nicht mit andersartigen Systemen kommunizieren. Heute sind primär Open Systems in Verwendung. Egal, ob iPhone, Android, Windows PC, LinuxServer, Supercomputer oder Embedded System: Die meisten Systeme können miteinander kommunizieren. Das OSI-Modell soll derlei offene Systeme, auch wenn sie verschiedenste Netzwerktechnologien einsetzen, miteinander verbinden.

Das oben dargestellte TCP/IP-Modell verwendet, wie auch das gesamte Buch, die englischen Begriffe der einzelnen Protokoll-Schichten (engl. Layer). Das hat ganz einfach den Grund, dass Sie durch Verwendung der englischen Begriffe auch weitere Bücher zum Thema TCP/IP einfacher verstehen werden, weil diese oft in englischer Sprache verfasst sind. Auch verwenden die zugehörigen Standards die englischen Bezeichnungen.

Jeder Layer kommuniziert dabei mit seinem logischen Gegenüber. Der Internet Layer eines Rechners A kommuniziert folglich nur mit dem Internet Layer des Kommunikationspartners B. Die Layer nutzen dabei jeweils die Dienste der unter ihnen liegenden Layer, sodass das Abstraktions-, aber auch das Fähigkeitsspektrum mit jedem Layer ansteigt. Der Vorteil dieses Ansatzes besteht darin, dass verschiedene Layer auch unterschiedliche Aufgaben übernehmen und ein einzelner Layer nicht die Verantwortung über die gesamte Kommunikation übernehmen muss.5

5Die

erste TCP-Implementierung hatte genau diese problematische Eigenschaft. Mittlerweile ist die Arbeitsfunktion von TCP jedoch auf den Transport Layer beschränkt worden.

14

2  Grundlagen der Netzwerktechnik

Abb. 2.3   Einkapselung von Layern in TCP/IP am Beispiel eines HTTP-Pakets

Für den Anwender sind diese Layer völlig transparent, er benötigt lediglich eine Endapplikation, um auf die ihm angebotenen Dienste eines Netzwerks zuzugreifen. Wichtig ist hierbei das Konzept der Einkapselung, wie sie in Abb. 2.3 dargestellt ist: Der Network Access Layer kapselt die Daten des Internet Layers in sich. Der Internet Layer kapselt wiederum die Daten des Transport Layers in sich, der die Daten vom Application Layer einkapselt, der wiederum die Nutzdaten (Payload) der jeweiligen Anwendung, also etwa Teile einer Bilddatei, enthält. In den folgenden Abschnitten werden das OSI-Modell und die einzelnen Layer des TCP/IP-Modells im Detail betrachtet.

2.2.1 Einige Worte zum OSI-Modell Das OSI-Referenzmodell hat zwar direkt nicht viel mit der TCP/IP-Suite zu tun, wird aber hin und wieder erwähnt und stellt praktisch eine andere Möglichkeit der Einteilung einer Netzwerkkommunikation in Layer dar, als es beim TCP/IP-Modell der Fall ist. Das OSI-Modell wurde 1983/84 standardisiert. Bestrebungen zur Entwicklung des Modells gehen allerdings bis in die späten 1970er-Jahre zurück. Die Layer des OSI-Modells sind primär eine andere Betrachtungsweise auf denselben Gegenstand. Genau wie bei den TCP/IP-Layern wird also nur eine logische Sicht auf real arbeitende Protokolle abgebildet. Die Protokolle sind dabei das eigentlich Interessante, und die wichtigste Netzwerkprotokollsuite (TCP/IP) wird in diesem Kapitel behandelt. Die Erläuterung der Layer wird Ihnen dabei helfen, die Funktionsweise der Protokolle zu verstehen. Der Physical Layer (auch Bitübertragungsschicht genannt) ist für die Zustellung einzelner Bits zuständig. Dabei übernimmt dieser Layer auch die Aufrechterhaltung einer Bitstrom-Verbindung. Außerdem gibt es den Datalink Layer (Sicherungsschicht). Auf dem Datalink Layer werden Datenüberprüfung und -korrektur sowie eine grundlegende Flusskontrolle durchgeführt. Physical Layer und Datalink Layer konzentrieren

2.2  Datenpakete, Einkapselung und die Entwicklung von TCP/IP

15

sich ausschließlich auf die Kommunikationsverbindung zwischen zwei direkt miteinander verbundenen Systemen, also etwa die Übertragung der Daten eines Smartphones zu einem WiFi-Router. Der Network Layer ist hingegen für die Zustellung von Daten zwischen den Verbindungsendpunkten zuständig, also etwa die Zustellung der Daten eines Smartphones über mehrere Router hinweg zu einem Zielsystem (etwa dem Server einer Suchmaschine). Der nächsthöhere Layer (Transport Layer) hat die Aufgabe, Daten für die nächsthöheren Layer transparent zu übertragen. Dies umfasst die Aufteilung von Daten in übertragbare Teile, das erneute Senden verlorengegangener Teildaten und das Sortieren von empfangenen Daten beim Empfänger. Auch laufen auf dem Transport Layer Funktionen zur Fehlerkorrektur ab. Auf dem Session Layer werden Aufbau und Abbau von Sitzungen (etwa bei TLS) sowie deren Aufrechterhaltung abgewickelt. Außerdem kümmert sich diese Schicht etwa um das Festlegen von Synchronisationspunkten und die Administration des Senderechtes. Die Unterteilung von Application Layer und Presentation Layer hat zur Folge, dass der Application Layer zwar ähnliche Aufgaben wie im TCP/IP-Modell übernimmt, jedoch Aufgaben, die die Datendarstellung betreffen, in den Presentation Layer ausgegliedert werden (er kümmert sich etwa um die Festlegung eines Zeichensatzes und um die Darstellung von Gleitkomma-Werten).

2.2.2 OSI- vs. TCP/IP-Modell Piscitello und Chapin weisen darauf hin, dass die TCP/IP-Entwicklungen das Design des OSI-Modells stark beeinflusst haben (und vice versa). Beide Modelle würden zudem an Acronymania (der intensiven Verwendung von Abkürzungen) leiden und würden teils unterschiedliche Begrifflichkeiten verwenden, um dasselbe zu bezeichnen [16]. Die Komplexität der sieben Schichten des OSI-Modells (und die damit verbundenen Kosten zur Integration eines solchen Modells) sowie die freie Zugänglichkeit der TCP/ IP-Standards haben maßgeblich zum Erfolg von TCP/IP beigetragen, das für die Mehrzahl der Netzwerkprotokolle ab der Vermittlungsschicht aufwärts das wichtigere Modell darstellt [28] und deshalb auch den Orientierungsrahmen für das vorliegende Buch liefert.

2.2.3 Das Hybridmodell von Tanenbaum Das sog. Hybridmodel ist ein Zwischenmodell zwischen dem OSI- und dem TCP/IPModell. Es wurde von Andrew Tanenbaum entwickelt und kennt fünf Schichten. Wie das TCP/IP-Modell verfügt das Hybridmodell nur über eine Anwendungsschicht anstelle von Anwendungs-, Präsentations- und Sitzungsschicht, wie sie im OSI-Modell vorliegen.

16

2  Grundlagen der Netzwerktechnik OSISchicht

Bezeichnung

TCP/IP-Schicht

HybridSchicht

7

Anwendungsschicht

6

Präsentaonsschicht

4 (Anwendungsschicht)

5 (Anwendungsschicht)

5

Sitzungsschicht

4

Transportschicht

3

4

3

Vermilungsschicht

2

3

2

Sicherungsschicht

1 (Netzwerkzugangsschicht)

2 (Sicherungsschicht)

1

Bitübertragungsschicht

1 (Bitübertragungsschicht)

Abb. 2.4   Vergleich der Schichten des TCP/IP-, OSI- und Hybridmodells.

Im Gegensatz zum TCP/IP-Modell kennt das Modell von Tanenbaum jedoch eine Bitübertragungsschicht (Physical Layer) und eine Sicherungsschicht (Data Link Layer), wie sie im OSI-Modell vorliegen. Tatsächlich sind die Verfahren auf den untersten beiden OSI-Schichten recht stark unterschiedlich, weshalb diese Unterscheidung sinnvoll ist. Abb. 2.4 stellt alle drei Schichtenmodelle vergleichend dar.

2.3 Grundzüge des TCP/IP-Modells Im Folgenden werden die einzelnen Layer des TCP/IP-Modells besprochen, beginnend mit dem untersten.

2.3.1 Link Layer Dieser Layer ist eine Zusammenfassung des Physical Layers und des Data Link Layers aus dem OSI-Modell. Er hat die Aufgabe, die einzelnen Bits über ein physikalisches Medium zum nächsten Netzwerkrechner (eines Netzwerkpfades) zu übertragen. Dies könnte zum Beispiel ein Crossover-Kabel sein, das an einer handelsüblichen EthernetNetzwerkkarte angeschlossen ist. Diese physikalischen Verbindungen werden als Links

2.3  Grundzüge des TCP/IP-Modells

17

bezeichnet und ein Layer-2-Gerät wird wiederum als Node bezeichnet. Typische Nodes des Link Layers sind: • Repeater: Signale (egal ob per Funk oder über Kabel) erreichen nicht immer vollständig und in ausreichender Qualität ihr Ziel. Manchmal sind Empfänger der Signale einfach zu weit entfernt, sodass das Signal beim Empfänger zu schwach wird. Repeater verstärken das Signal, damit es sein Ziel dennoch erreichen kann. Im Heimeinsatz finden sich bei größeren Wohngebäuden beispielsweise oft WLAN-Repeater. • Hubs: Repeating Hubs (auch: Multiport-Repeater) dienen der sternförmigen Verkabelung von Hosts in Netzen. Daten, die an einem Netzwerkport eines Hubs eintreffen, werden an sämtliche andere Ports weitergeleitet. • Switch: Switche analysieren die Daten, die an einem Port eintreffen. Sie überprüfen anhand der Zieladresse der Daten, an welchen Port sie weitergeleitet werden müssen. Entsprechend müssen Hosts im Netzwerk, an die bestimmte Daten nicht gerichtet sind, keine Rechenleistung aufwenden, um diese Daten zu verwerfen (das heißt, um zu überprüfen, ob sie überhaupt der Empfänger sind), da der Switch diese Arbeit abnimmt. Broadcast-Nachrichten werden dennoch an alle Teilnehmer des Netzes versendet (das heißt an alle Ports). Welche Hostadresse zu welchem Port gehört, lernt der Switch selbständig durch die permanente Überwachung des Netzwerks. Er speichert die gelernten Informationen in einer Tabelle. Manche Switche können Daten einer höheren Schicht verstehen und filtern. Sie unterstützten zudem Managementfunktionen für das Netzwerk, etwa das Bilden von Teilnetzen (sogenannte Virtual LANs, VLANs, die in späteren Kapiteln noch besprochen werden). Auf diesem Layer kommunizieren die Systeme in Form von Frames. Typische Medien sind neben Ethernet auch Wireless-LAN, Glasfaser-Verbindungen (FDDI) oder ISDNVerbindungen. Entsprechend wird von Ethernet-Frames, FDDI-Frames usw. gesprochen. Zu den Diensten des Link Layers gehören insbesondere das Framing, das ist die Einkapselung der Protokolle des Internet Layers in eine Frame, und die Zustellung der Daten an nächste Node. Weiterhin kümmert sich diese Schicht um den Link-Zugriff, auch Medium Access Control (MAC) genannt. Dabei handelt es sich um Zugriffsverfahren, die regeln, wann welcher Node für wie lang über ein Medium senden darf. Eine weitere Aufgabe dieser Schicht ist das fehlerfreie Übertragen von Daten und die damit verbundene Detektion von Fehlern (Error Detection & Correction, EDC).

2.3.1.1 Error Detection and Correction Ein Grundmodell für die Übertragung von Daten liefert die Informationstheorie. Sie beschreibt, in welchen Schritten Daten über einen Kommunikationskanal übertragen werden können (Abb. 2.5). Nachrichten werden aus einer Nachrichtenquelle gesendet (etwa der Text ‘HALLO’ in einem Chat von einem Benutzer). Danach werden die Informationen, die übertragen

18

2  Grundlagen der Netzwerktechnik

Abb. 2.5   Modell für einen Kanal

werden sollen, durch einen Quellenkodierer verdichtet, das heißt komprimiert. Die nun komprimierten Daten werden wiederum mit Zusatzinformationen versehen, die eine Fehlerdetektion beziehungsweise -korrektur ermöglichen. Hierfür ist der Kanalkodierer zuständig. Die nun fertig kodierten Daten werden über einen Kanal übertragen (gesendet). Dieser Kanal ist im Normalfall immer ein rauschender Kanal, das heißt, dass Daten nicht immer fehlerfrei über diesen Kanal übertragen werden. So könnte etwa gerade ein Fehler im Netzwerkkabel vorliegen, der einen Teil des übertragenen Signals verändert. Der Empfänger nutzt zunächst einen Kanaldekodierer. Dieser entfernt die redundanten Informationen, die zur Fehlerkorrektur und -detektion verwendet wurden. Wenn die Daten fehlerfrei sind beziehungsweise trotz Fehlern rekonstruiert werden können, werden sie durch den Quellendekodierer dekomprimiert. Die nun dekomprimierte Nachricht (‘HALLO’) wird der Nachrichtensenke (dem Empfänger) übergeben. Das einfachste Modell für einen solchen Kanal ist der binärsymmetrische Kanal (engl. binary symmetric channel, BSC, siehe Abb. 2.6). Ein BSC kann ausschließlich 0er und 1er Bits übertragen. Diese werden mit der Wahrscheinlichkeit p durch Rauschen modifiziert und empfangsseitig als das jeweils andere Bit interpretiert. Im Normalfall gilt, dass 0 ≤ p ≤ 1∕2. Wenn etwa eine von 1000 Nachrichten fehlerhaft übertragen wurde, dann ist p = 1∕1000 = 0,001. Wenn p = 0 ist, dann gilt der Kanal als rauschfrei (noise-free), andernfalls als rauschend (noisy). Doch wie funktionieren Kanalkodierer und Quellenkodierer beziehungsweise ihre jeweiligen Dekodierer? Im Folgenden werden einige grundlegende Verfahren besprochen.

Abb. 2.6   Der binärsymmetrische Kanal (BSC)

2.3  Grundzüge des TCP/IP-Modells

19

2.3.1.2 Quellenkodierer David A. Huffman (Preisträger der Hamming-Medaille von 1999) entwickelte ein nach ihm benanntes Kodierungsverfahren, das im Folgenden betrachtet wird und eine Form der Quellenkodierung darstellt. Ziel des Verfahrens ist es, zu sendende Nachrichten zu komprimieren, bevor sie an den Kanalkodierer weitergeleitet werden. Komprimierte Nachrichten sind weniger fehleranfällig (weil weniger lang) und lasten das Netzwerk weniger stark aus (Performancesteigerung). Erläutern lässt sich die Huffman-Kodierung am besten anhand eines Szenarios. Ein Sender möchte bestimmte Nachrichtensymbole (etwa alle deutschen Großbuchstaben) von einer Nachrichtenquelle (Quellensymbole) an einen Sender übertragen. Nachrichten, die diese Quellensymbole verwenden, sollen komprimiert werden. Für die HuffmanKodierung erzeugt der Sender zunächst einen Huffman-Tree. Ein Huffman-Tree ist ein Baum, der Quellensymbole beinhaltet. Die Quellensymbole werden im Baum gemäß ihrer relativen Häufigkeit eingebaut, mit der sie auftreten. Dabei gilt folgendes Vorgehen [9, 30]: 1. Der Sender ermittelt für jedes Zeichen (Quellensymbol) die Auftrittswahrscheinlichkeit und erstellt jeweils ein Blatt (ein Element des zukünftigen Baumes), an dem er diese Auftrittswahrscheinlichkeit notiert. 2. So lange, wie der Sender noch Teilbäume (Blätter) übrig hat: a. Wahl der beiden Teilbäume (Knoten) mit der geringsten Häufigkeit und Tiefe an der Wurzel (aus den bisherigen Teilbäumen und übrigen Quellensymbolen). b. Zusammenfassen dieser Bäume zu einem neuen Baum. c. An der Wurzel des neuen Baumes die Summe der Auftrittswahrscheinlichkeiten der enthaltenen Symbole notieren. 3. Jeder Kante wird ein Codesymbol zugeordnet (i. d. R. ein Binärwert, also 1 oder 0). 4. Anschließend liegt der finale Huffman-Tree vor.

Beispiel für den Aufbau eines Huffman-Trees

Der Sender möchte Nachrichten kodieren, die aus den Symbolen A, B und C bestehen (ein typisches Alphabet beinhaltet natürlich mehr Symbole, doch ist das Verfahren analog anzuwenden). Durch die Analyse typischer Texte der Sprache weiß der Sender, dass A das häufigste Symbol ist. Es tritt mit einer Wahrscheinlichkeit von 50 % auf. B tritt mit einer Wahrscheinlichkeit von 30 % und C mit einer Wahrscheinlichkeit von 20 % auf. Der Sender wählt nun zunächst die beiden Symbole mit der geringsten Auftrittswahrscheinlichkeit, also B und C, und fügt diese zu einem Baum zusammen. Das linke Blatt des Baums steht für das Symbol B und erhält den Wert 30 %. Das rechte Blatt des Baums steht für das Symbol C und erhält den Wert 20 %. Die Wurzel des Baums wird „BC“ genannt und erhält die Summe beider Werte (50 %). Nun sind zwei Teilbäume übrig: Das Blatt A und der Teilbaum, in den B und C integriert wurden. Der Sender wählt diese beiden Bäume und kombiniert sie zu einem neuen Baum.

20

2  Grundlagen der Netzwerktechnik

Abb. 2.7   Beispiel eines Huffman-Trees

Die linke Seite repräsentiert das Symbol A und ist mit dem Wert 50 % verbunden. Die rechte Seite des neuen Baums wird der zuvor erzeugte Baum „BC“. Die Wurzel des finalen Baums „ABC“ erhält den Wert 100 %. Den Baum sehen Sie in Abb. 2.7. Schließlich notiert der Sender noch Codesymbole am Baum. Die linke Seite erhält dabei immer 0er-Werte, die rechte 1er-Werte (dies kann auch umgedreht werden). Die linke Seite (A) des Baums bekommt folglich den Wert 0 zugewiesen. Die rechte Seite (BC) erhält den Wert 1. Selbiges Verfahren wird für den Teilbaum BC angewandt. Die linke Seite (B) erhält den Wert 0, die rechte Seite (C) erhält den Wert 1 (Abb. 2.7). ◄ Mithilfe des dabei erzeugten Baums kann der Sender Nachrichten kodieren. Er führt dazu die folgenden Schritte für jedes Quellensymbol aus und beginnt dabei mit dem ersten Quellensymbol seiner Nachricht: 1. Wahl des ersten beziehungsweise nächsten Quellensymbols. 2. Konkatenieren aller Codesymbole von der Wurzel des Huffman-Trees bis zum gewünschten Quellensymbol. 3. Sofern noch unkodierte Quellensymbole vorliegen: weiter mit Schritt 1. Die komprimierte Nachricht liegt anschließend in Form der notierten, aneinandergereihten Codesymbole vor. Beispiel für die Kodierung einer Nachricht mithilfe eines Huffman-Trees

Anhand des im vorherigen Beispiel erzeugten Huffman-Trees (Abb. 2.7) soll die Nachricht „AAABC“ kodiert werden. Ausgehend von der Wurzel des Baums müssen alle Kanten besucht werden, um zum ersten Quellensymbol der Nachricht („A“) zu gelangen. Hierzu muss die linke Kante besucht werden, die das Symbol „0“ aufweist. Da „A“ durch eine einzelne Kante erreicht werden kann, wird ausschließlich diese „0“ notiert. Analog wird mit den zwei weiteren „A“ verfahren, womit sich konkateniert bisher die Nachricht „000“ ergibt. Als nächstes muss das „B“ kodiert werden. Von der Wurzel ausgehend muss zunächst eine Kante mit der Beschriftung „1“ passiert werden, um zu „BC“ zu gelangen. Anschließend führt eine weitere

2.3  Grundzüge des TCP/IP-Modells

21

Kante mit der Beschriftung „0“ zu „B“. Das entsprechende Codesymbol ist also „10“ und wird zur Nachricht hinzugefügt (es ergibt sich „00010“). Analog wird für die Kodierung des Quellensymbols „C“ verfahren, das durch das Codesymbol „11“ kodiert wird, womit sich schließlich die kodierte Nachricht „0001011“ ergibt. ◄ Ein guter Kompressionsalgorithmus komprimiert oft verlustfrei (etwa HuffmanKodierung). Manchmal können Verluste allerdings auch toleriert werden (etwa bei MP3oder JPEG-Kompression). Die Effektivität von Kompressionsalgorithmen kann über die Kompressionsrate bestimmt werden [25]:

Kompressionsrate =

Gr¨oße der Ausgabedaten Gr¨oße der Eingabedaten

Je größer die Kompressionsrate, desto stärker wurden die Eingabedaten komprimiert. Hohe Kompressionsraten erzielen dabei nur Daten, die nicht bereits komprimiert sind (also beispielsweise keine JPEG-Dateien) und unverschlüsselt sind (weil sonst die Auftrittswahrscheinlichkeit für alle Symbole in etwa gleich hoch ist).

2.3.1.3 Kanalkodierer Während der soeben besprochene Quellenkodierer für die Verdichtung von Nachrichten zuständig ist, fehlt nun noch der Schritt, der für die Robustheit einer Nachrichtenübertragung sorgt. Dieser Schritt wird durch den Kanalkodierer durchgeführt. Die oben erwähnten EDC-Daten werden dabei in Form von Bits in zu übertragende Frames eingebettet. Der Sender schickt eine Frame, die aus zwei Komponenten besteht, den eigentlichen Framedaten und den EDC-Bits (|| steht für die Konkatenation, also das Aneinanderfügen): Frame := Datagramm || EDC Die Frame wird über einen Kanal übertragen und dabei eventuell verfälscht. Der Empfänger erhält letztlich ebenfalls eine Frame mit den Elementen Datagram′ und EDC′.

Frame’ := Datagramm’ || EDC’ Mithilfe der EDC′ kann der Empfänger allerdings Datagram′ überprüfen. Nur dann, wenn der Prüfwert der EDC-Bits mit den Daten des Datagramms übereinstimmt, wird das Datagramm als fehlerfrei betrachtet. Ansonsten wird versucht, es zu korrigieren, oder es wird verworfen. Falls der Sender eine Bestätigungsnachricht für den Empfang der Frame erwartet, wird diese Bestätigungsnachricht im Fehlerfall nicht gesendet.6

6Tatsächlich

kann auch eine Bestätigungsnachricht fehlerbehaftet sein oder verloren gehen. Dieses Problem nennt sich Two-Army-Problem.

22

2  Grundlagen der Netzwerktechnik

Paritätsbits: EDC-Bits können im simpelsten Fall mit sogenannten Paritätsbits (engl. parity bits) realisiert werden. Die Funktionsweise von Paritätsbits ist recht einfach. Für die zu übertragenden n Datenbits zählt man die Anzahl der auf „1“ gesetzten Bits. Ist diese ungerade, beträgt das entsprechende Paritätsbit 1, andernfalls 0. Das Paritätsbit wird an die eigentlichen Datenbits per Konkatenation angehängt. Der Empfänger prüft, ob die Anzahl der 1er-Bits mit dem Wert des Paritätsbits übereinstimmt. Beispielanwendung von Paritätsbits

Es seien die folgenden Bits zu übertragen: 001001101 Somit sind eine gerade Anzahl 1er-Bits enthalten. Das Paritätsbit wird entsprechend auf 0 gesetzt. Für die Daten 001001100 wäre das Paritätsbit hingegen 1. ◄ Problematisch ist hierbei, dass die Paritätsbits versagen, wenn sich in den Daten zwei Bits verändern. Schließlich würde der Wert des Paritätsbits dann wieder mit den zu prüfenden Bits übereinstimmen. Abhilfe schaffen hierbei mehrdimensionale Paritätsbits. Sie ermöglichen nicht nur eine begrenzte Fehlerdetektion, sondern erlauben auch die Korrektur einzelner Bits. Daten werden dazu in Abschnitte der Größe n geteilt. Für jeden Abschnitt wird das Paritätsbit separat berechnet. Diese Paritätsbits können als horizontale Paritätsbits betrachtet werden. Anschließend wird ein Paritätsbit für jedes erste Element jedes Abschnitts berechnet, dann das Paritätsbit für jedes zweite Element eines Abschnitts usw. Diese Paritätsbits können als vertikale Paritätsbits betrachtet werden. Schließlich wird noch das Paritätsbit aller vertikalen und aller horizontalen Paritätsbits berechnet. Beide Werte sollten gleich sein. Durch vertikale und horizontale Paritätsbits liegen nun zweidimensionale Paritätsbits vor. Denkbar wäre das Hinzufügen einer weiteren Dimension. Beispielanwendung von zweidimensionalen Paritätsbits

Es sollen die Daten 1 0 1 0 0 0 1 0 1 1 1 0 0 1 0 1 mit zweidimensionalen Paritätsbits übertragen werden. Die Abschnitte sollen 4 Bits umfassen. Entsprechend dargestellt ergeben sich vier Zeilen à 4 Bits: 1 0 1 0

0 0 1 1

1 1 1 0

0 0 0 1

2.3  Grundzüge des TCP/IP-Modells

23

Im zweiten Schritt werden die zweidimensionalen Paritätsbits hinzugefügt (fett gedruckt). Außerdem wird das Paritätsbit hinzugefügt, das über die vertikalen und horizontalen Paritätsbits berechnet wird (hier unterstrichen): 1 0 1 0 0

0 0 1 1 0

1 1 1 0 1

0 0 0 1 1

0 1 1 0 0

Die Daten werden anschließend übertragen und der Empfänger kann bei einem Übertragungsfehler durch Kreuzung des vertikalen und des horizontalen betroffenen Paritätsbits ein gekipptes Bit detektieren und korrigieren. Das oben unterstrichene Bit kann nur bei gleicher Anzahl an Zeilen und Spalten verwendet werden. Beispielanwendung von zweidimensionalen Paritätsbits (Fortsetzung)

Es seien erneut die Daten 1 0 1 0 0 0 1 0 1 1 1 0 0 1 0 1 zu übertragen. Auch diesmal sollen die Daten in Abschnitte der Größe 4 zerteilt werden. Dabei wurde das kursiv markierte Bit (dritte Zeile, zweite Spalte) fehlerhaft übertragen. 1 0 1 0 0

0 0 0 1 0

1 1 1 0 1

0 0 0 1 1

0 1 1 0 0

Der Empfänger sieht, dass das dritte vertikale und das zweite horizontale Paritätsbit nicht mit den vorliegenden Datenbits übereinstimmen und „kreuzt“ beide Positionen, um das fehlerhafte Bit zu ermitteln.

Hamming-Codes: Vorteilhafter sind hingegen sogenannte Hamming-Codes, die von Richard W. Hamming (Namensgeber der gleichnamigen Medaille der IEEE) erfunden wurden. Hamming-Codes haben die Länge 2r − 1, wobei r Bits für die Fehlerkorrektur verwendet werden und 2r − 1 − r Bits Nutzdaten sind. Das Verhältnis der beiden Werte wird auch als Tupel dargestellt. So bedeutet (7, 4) beispielsweise, dass 4 Nutzdatenbits und 3 Korrekturbits verwendet werden. Ein Paritätsbit ist bei Hamming-Codes immer von mehreren Nutzdatenbits abhängig, statt nur von einem einzigen. Je länger die zu übertragenden Daten sind, umso mehr

24

2  Grundlagen der Netzwerktechnik

Paritätsbits werden benötigt. Die Paritätsbits werden dabei zwischen die Nutzdatenbits integriert. Zur Konstruktion des Hamming-Codes wird wie folgt vorgegangen: Das n. te Paritätsbit berechnet sich über alle Bits, die an der n.ten Bitstelle 1 sind. Das erste Paritätsbit würde also beispielsweise über alle Bits, die an der ersten Bitstelle 1 sind, berechnet werden. In den Code werden die Paritätsbits an jeder Stelle 2n−1 eingefügt. Das heißt, Paritätsbit 1 steht an Stelle 1, Paritätsbit 2 steht an Stelle 2, Paritätsbit 3 steht an Stelle 4, Paritätsbit 4 steht an Stelle 8 usw. Beispiel für einen (7,4)-Hamming-Code:

Unsere Nutzdaten-Bits seien erneut die ersten vier der oben verwendeten Bits, also 1 0 1 0. An jeder Stelle 2n − 1 wird nun ein Paritätsbit platziert, somit: Position: 1 | 2 | 3 | 4 | 5 | 6 | 7 | ------------+----+---+----+---+---+---| Bit: p1 | p2 | 1 | p4 | 0 | 1 | 0 |

Paritätsbit p1 prüft jedes zweite Bit (von sich aus gerechnet, das heißt Bits 3, 5, 7). Dual haben diese Bits an letzter Stelle eine „1“ (000,001, 010,011, …). Der Kodierer zählt bei den betroffenen Bits (1, 0, 0) die Vorkommen des Wertes „1“ (dieser kommt nur einmal vor), womit er p1 = 1 setzt. Analog verfährt der Kodierer mit p2, das, von sich aus gerechnet, jeweils zwei Bits prüft, anschließend zwei Bits überspringt usw. Anders formuliert prüft es die Bits 3, 6, 7, denn dual betrachtet sind dies die Bits, die an zweiter Stelle eine „1“ haben (000, 001, 010, 011, 100, 101, 110, 111). Erneut klammert der Kodierer die Paritätsbits selbst aus, startet also mit dem dritten Bit. Aus den Bits (1, 1, 0) ergibt sich somit der Paritätswert 0. Das Paritätsbit p4 prüft jeweils Ketten von vier Bits (es ist unser drittes Paritätsbit und prüft also jedes Bit, das an dritter Stelle den Wert „1“ hat). Hier wären die Bits 4, 5, 6, 7 betroffen, wobei der Kodierer p4 wieder nicht einbezieht. Aus den Bits (0, 1, 0) ergibt sich der Paritätswert 1 und schließlich das folgende Ergebnis (Paritätsbits sind fett gedruckt): Position: 1 | 2 | 3 | 4 | 5 | 6 | 7 | ------------+---+---+---+---+---+---| Bit: 1 | 0 | 1 | 1 | 0 | 1 | 0 |

Für die Fehlererkennung kann der Dekodierer mithilfe des Hamming-Codes das fehlerhafte Bit lokalisieren (dazu sind hierbei weniger Bits als bei zweidimensionalen Paritätsbits notwendig).

2.3  Grundzüge des TCP/IP-Modells

25

Der Dekodierer prüft für alle vorhandenen Paritätsbits, ob der Ist-Wert des Paritätsbits mit dem Soll-Wert der Bitpositionen übereinstimmt. Angenommen p1 habe den Ist-Wert „1“ und den Soll-Wert „0“. Wenn nun zudem p2 den Ist-Wert „0“ und den Soll-Wert „1“ aufweist, dann kann der Dekodierer den exakten Fehler lokalisieren: Der Dekodierer addiert die Stellen der beiden Paritätsbits (1 + 2 = 3) miteinander und erhält dadurch das fehlerhafte Bit (3). Wären hingegen p2 und p4 auf Fehler zeigend, so wäre das sechste Bit fehlerhaft. Der Bitwert des jeweils fehlerhaften Bits muss invertiert werden, um ihn zu korrigieren. Ein weiterer Vorteil des Verfahrens liegt darin, dass, falls ein Paritätsbit fehlerhaft ist, auch die Paritätswerte uneinheitlich ausfallen: Es müssen immer mindestens zwei Paritätsbits einen Fehler in den Nutzdaten anzeigen, ansonsten kann ein Paritätswert selbst als fehlerbehaftet betrachtet werden.

2.3.1.4 Medienzugriff Übertragungsmedien werden von mehreren Systemen verwendet. Beispielsweise werden Luft und Kabel von mehreren Nodes gleichzeitig zum Senden benutzt. Das mögliche Resultat sind kollidierende Frames. Verschiedene Zugriffsverfahren adressieren dieses Grundproblem. Betrachtet werden im Folgenden die Verfahren ALOHA, SLOTTED ALOHA und CSMA/CD sowie CSMA/CA. Das Konzept von ALOHA ist simpel. Wenn Daten zum Senden bereit sind, dann erfolgt ein sofortiges Senden von Frames über das Medium. Falls eine Kollision mit einer anderen Frame stattfindet, wird die aktuelle Frame dennoch vollständig verschickt. Danach wird mit Wahrscheinlichkeit p ein neuer Sendeversuch unternommen. Andernfalls wird eine festgelegte Zeitspanne gewartet und danach wieder mit Wahrscheinlich p ein Sendeversuch unternommen. Dieser Vorgang des wahrscheinlichen Wartens wird so lange wiederholt, bis die Frame gesendet wurde. ALOHA wurde durch die Einführung von Zeitslots verbessert und Slotted ALOHA getauft. Zeitslots sollen dabei ein effizienteres Senden ermöglichen. Außerdem wird festgelegt, dass alle Frames dieselbe Länge l bekommen und ein Zeitslot groß genug ist, um eine Frame dieser Länge zu versenden. Während eines Zeitslots kann entweder gesendet werden (erfolgreich oder mit Kollision) oder es wird nicht gesendet. Gesendet wird nur zu Anfang eines Zeitslots, nicht mittendrin oder zum Ende. Es wird zudem nicht zeitslotübergreifend gesendet. Alle Systeme sind synchronisiert und benutzen daher dieselben Zeitslot-Aufteilungen. Wenn es zu einer Kollision kommt, wird auf einen anderen Zeitslot gewartet und dann mit Wahrscheinlichkeit p erneut gesendet. Auf diese Weise werden Kollisionen, die nur durch sich überlappende Frameteile entstehen, vermieden. Eine weiteres Verfahren für den Medienzugriff ist Carrier Sense Multiple Access (CSMA). Carrier Sense (CS) überprüft dabei, ob eine andere Node bereits sendet (und beginnt das Senden nicht, wenn dies der Fall ist). Multiple Access (MA) erlaubt es, dass mehrere Nodes über das Medium senden und empfangen. Außerdem werden Daten, die eine Node sendet, generell von allen anderen Nodes empfangen. CS ist nicht perfekt und Kollisionen sind nach wie vor möglich (zwei Nodes könnten gleichzeitig feststellen, dass keine andere Node sendet).

26

2  Grundlagen der Netzwerktechnik

CSMA wurde zu CSMA/CD und CSMA/CA weiterentwickelt und kommt in diesen Formen in aktuellen Netzen zum Einsatz. CSMA/CD verhält sich wie CSMA, allerdings wird zusätzlich Collision Detection (CD) eingesetzt. Falls eine sendende Node detektiert, dass eine andere Node ebenfalls sendet (das kann durch zeitliche Verzögerungen passieren), so wird das Senden abgebrochen und eine Zufallszeit gewartet, bevor erneut gesendet wird. CSMA/CA führt hingegen das Konzept der Collision Avoidance (CA) ein. Dieses Konzept kann auch als Listen before you talk (höre auf das Medium, bevor du selbst sendest) verstanden werden. Nodes prüfen vor dem Senden, ob eine andere Node derzeit sendet (Kollisionen sind nach wie vor durch zeitlich Überlappung möglich, aber weniger wahrscheinlich), führen also CS durch. Falls eine andere Node sendet: Sende selbst nicht. Anschließend warten Nodes zunächst eine Zufallszeit, bevor sie erneut senden. Dies verringert die Anzahl der Kollisionen. Neben diesen im Wesentlichen zufallsbasierten Zugriffsverfahren existieren auch deterministische Zugriffsverfahren, insbesondere das Master-Slave-Verfahren, bei dem ein Master feste Kommunikationszeiten mit untergeordneten Nodes (den Slaves) einhält. Master-Slave-Verfahren kommen insbesondere in Automationsumgebungen zum Einsatz. Ein Vertreter für das Master-Slave-Verfahren ist Master-Slave/Token-Passing (MSTP), das beim BACnet-Protokoll zum Einsatz kommt (siehe Kap. 10).

2.3.2 Internet Layer Der Internet Layer hat die Aufgabe, Daten mit Hilfe des Internet-Protokolls (IP), das später noch genauer betrachtet wird, zu versenden und zu empfangen. Dazu besitzt jeder Rechner eine eindeutige Adresse – die sogenannte IP-Adresse – die ihn eindeutig in einem Netzwerk identifiziert. Die IP-Adresse wird in der Form a.b.c.d geschrieben, wobei die Buchstaben jeweils durch Ziffern ersetzt werden. Anders als beim Link Layer erfolgt auf diesem Layer sogenanntes Routing.  Wegfindung in Netzwerken  Das Routing stellt sicher, dass Daten über verschiedene Netzwerke hinweg an das Ziel übertragen werden können. Dazu werden Informationen benötigt, die angeben, über welche Router man ein Zielnetzwerk erreichen kann. Dies ist vergleichbar mit einer Bahnfahrt. Um von München nach Frankfurt zu fahren, müssen Sie mehrere Stationen (analog zu den Routern) passieren, vermutlich Augsburg, Ulm, Stuttgart und Mannheim. Sie müssen an der jeweiligen Station jedoch nur wissen, in welchen Zug Sie steigen müssen beziehungsweise ob Sie im aktuellen Zug verbleiben können. So trifft analog auch jeder Router für ein weiterzuleitendes Paket jeweils die Entscheidung, über welchen Link das Paket gesendet werden muss, um das angegebene Ziel zu erreichen.

2.3  Grundzüge des TCP/IP-Modells

27

Die Informationen zur Wegfindung, also die Routinginformationen, werden dabei in den Routingtabellen der einzelnen Rechner abgelegt. Diese können entweder statisch vom Administrator konfiguriert oder dynamisch über Routingprotokolle verwaltet werden. Letztere Variante bietet je nach Routingprotokoll und verwendetem Routingalgorithmus diverse Angriffspunkte für Hacker, erleichtert aber das Management großer Netzwerke. Die Routingtabelle eines Systems können Sie über das route-Programm aufrufen und administrieren. Unter vielen Systemen kann zudem alternativ auch das netstatProgramm verwendet werden.7

Rechner und Netzwerke werden dabei durch IP-Adressen repräsentiert. Wie Sie sehen, ist für jedes Ziel ein Router (Gateway) angegeben. So erreichen der Rechner das Zielnetz 172.16.0.0 etwa über den Router mit der IP-Adresse 172.16.0.1. Das Ziel 0.0.0.0 steht für den Standardrouter – an ihn werden Datenpakete geschickt, damit er sie (hoffentlich) an das Ziel weiterleiten kann, auch wenn der sendende Host selbst nicht weiß, wie der Pfad zum Zielnetz aussieht. Ohne diesen Standardrouter bräuchte jeder mit dem Internet verbundene Rechner eine Routingtabelle, die die Routingdaten des gesamten Internets beinhaltet. Dank diesem Router muss ein Router beziehungsweise ein Host allerdings meist nur wenige Einträge in seiner Routingtabelle vorhalten. Der Standardrouter hat in seiner Routingtabelle wiederum entsprechende Informationen, um das Paket an den nächsten Router in Richtung des Zieles beziehungsweise direkt an das Ziel zu senden. Auf diese Weise werden die Pakete von einem zum nächsten Router weitergereicht, bis sie schließlich am Ziel ankommen. Neben dem Ziel und dem Router, der verwendet werden soll, um dieses Ziel zu erreichen, werden noch weitere Informationen zum Pfad (etwa die Netzmaske oder die zu verwendende Netzwerk-Schnittstelle) angegeben, was in diesem einführenden Kapitel allerdings nicht von Bedeutung ist. In diesem Buch werden die Begriffe Gateway und Router zwar synonym verwendet, jedoch sind beide nicht exakt gleich definiert. Ein Router leitet Pakete auf dem Internet Layer weiter, ein Gateway verwendet dazu auch durchaus einen anderen Layer und kann

7Bei

Verwendung des netstat-Programms benötigen Sie für die Routingtabelle den Parameter -r (aktiviert die Ausgabe der Routingtabelle).

28

2  Grundlagen der Netzwerktechnik

Protokolle übersetzen, um Netzwerke, die unterschiedliche Protokolle verwenden, interoperabel zu machen. Der Internet Layer nutzt den darunter liegenden Network Access Layer. Nur über diesen können die Pakete über das Kabel versendet werden. Dass die Pakete dazu in eine Frame gepackt werden, ist auch eine logische Konsequenz. Beim Empfänger wiederum entpackt der Network Access Laer die Frame und reicht das erhaltene Paket unverändert an den Internet Layer weiter – wie ein Ei, das erst geschält werden muss. Der Unterschied zum Ei besteht nun im Besonderen darin, dass jede Schicht erst ihre „Schale“ entfernen muss, bevor dem Benutzer die relevanten Daten zur Verfügung stehen. So betrachtet können Sie sich das zuvor erläuterte Prinzip der Einkapselung auch als Zwiebelschalenmodell vorstellen, dessen äußerste Schale das Protokoll des Network Access Layers ist, und dessen innerste Schale das Protokoll des Application Layers darstellt.

2.3.3 Transport Layer Die nächsthöhere Schicht, der Transport Layer, hat die Aufgabe, die durch den Internet Layer zum Zielrechner beförderten Daten an die richtigen Anwendungen auszuliefern. Anwendungen werden dabei sogenannten Ports zugeordnet. Jede „Verbindung“ zwischen dem Sender und dem Empfänger hat auf Anwendungsebene jeweils zwei Ports: einen Quellport (dieser gehört zum Sender) und einen Zielport (dieser gehört zum Empfänger). Ein Paar aus Quell- und Zielport erlaubt die eindeutige Zuordnung der Verbindung zu den jeweiligen Rechnern.8 Somit hat der Transport Layer die Hauptaufgabe des Multiplexings inne, da er zwischen Sender und Empfänger der Vermittler für eine Vielzahl an möglichen Anwendungen und ihren zugehörigen Verbindungen ist (Abb. 2.8). Das Verfahren des Multiplexings funktioniert ähnlich wie frühe Telefonanlagen, bei denen Steckverbindungen mit Anschlüssen (Ports) verbunden wurden. Dadurch wurde sichergestellt, dass ein bestimmter Teilnehmer mit einem anderen ausgewählten Teilnehmer sprechen kann, nicht jedoch mit einem beliebigen Teilnehmer. Analog soll heute die Kommunikation von einem Mail-Client zu einem Mail-Server nicht einfach bei einem anderen Dienst auf demselben Empfänger (etwa einem Webserver) landen (Abb. 2.8). Dieser Layer stellt neben einzelnen Spezialprotokollen (wie etwa dem Routingprotokoll OSPF (Open Shorted Path First)) im Prinzip nur zwei herausragende Protokolle, nämlich TCP (Transmission Control Protocol) und UDP (User Datagram Protocol) bereit.

8Die

Verbindungen werden den Rechnern wiederum über ihre Quell- und Ziel-IP-Adressen zugeordnet, doch dies ist die Aufgabe des Internet Layers.

2.3  Grundzüge des TCP/IP-Modells

29

Abb. 2.8   Portbasiertes Multiplexing des Transport-Layers: Senderseitige Daten der Anwendungen der Anwendungsschicht werden, obwohl sie sich ein Kommunikationsmedium teilen können, dennoch an die korrekten Anwendungen des Empfängers geleitet

Während TCP eine etwas größere Datenlast pro Paket als UDP verursacht (da es einen größeren Header (also Protokollkopf mit Metadaten) verwendet), verfügt es über ausgefeiltere Fehlerkorrekturmechanismen, die die Auslieferung zu übertragenden Dateneinheiten (Segmente genannt) gewährleisten soll. UDP hingegen kümmert sich nicht darum, ob die über dieses Protokoll transferierten Dateneinheiten (Datagramme genannt) überhaupt ankommen. UDP wird daher für Systeme eingesetzt, die hohes Datenaufkommen bei ständig wechselnden, aber prinzipiell gleichen Daten verursachen.9 Diese beiden Protokolle werden selbstverständlich noch detaillierter besprochen. Ein weiterer Unterschied zwischen TCP und UDP ist der, dass TCP verbindungsorientiert arbeitet. Eine Verbindung besteht dabei aus vielen Segmenten. Das bedeutet, dass eine Verbindung vor der Kommunikation zunächst aufgebaut und am Ende wieder geschlossen werden muss. Auch muss eine Verbindung verwaltet werden. Bei UDP hingegen wird jedes Datagramm losgelöst von den vorherigen und nachfolgenden Datagrammen betrachtet.

2.3.4 Application Layer Der Application Layer, zu Deutsch die Anwendungsschicht, wird von den einzelnen Netzwerkprogrammen und -diensten verwendet. Die Anwendungen (Applications) stellen einen Dienst auf einem Port zur Verfügung (beziehungsweise greifen auf diesen zu) und können über diesen Port senden und empfangen. Solche Applikationen benötigen jeweils ihre eigenen, in der Regel glücklicherweise standardkonformen Protokolle. Die wichtigsten davon sind Hypertext Transfer Protocol (HTTP) für die

9Dies

kann beispielsweise bei Statusdaten, die einmal pro Sekunde komplett übertragen werden, oder bei Internet-Telefonie der Fall sein.

30

2  Grundlagen der Netzwerktechnik

Kommunikation zwischen Webserver und Browser, Domain Name System (DNS), primär für die Auflösung von Hostnamen in IP-Adressen, sowie das Simple Mail Transfer Protocol (SMTP) zum Versenden/Ausliefern von E-Mail und das Internet Message Access Protocol (IMAP) zum Abrufen von E-Mails. Auf dem Application Layer spricht man meistens nicht mehr von Paketen beziehungsweise Segmenten, sondern von Messages (Nachrichten) (UDP-basierte Kommunikation) und Streams (TCP-basierte Kommunikation).

2.3.5 Zusammenfassung Ein Programm, das mit einem anderen Programm auf einem entfernten Rechner kommuniziert, benötigt ein Protokoll. Das Protokoll wird benötigt, damit die Kommunikation fehlerfrei funktionieren kann – und eigentlich ist ohne ein wie auch immer geartetes Protokoll auch keine Art von Kommunikation möglich. Schließlich können sich auch nicht zwei Menschen unterhalten, die keine gemeinsame (ggf. nonverbale) Sprache sprechen. Das Programm baut dazu eine Verbindung mit dem anderen Rechner auf, indem es Daten an einen Port des Zielrechners sendet. Die Transportschicht kümmert sich um die Zustellung der Daten des Programms an das entsprechende Programm des Zielrechners. Die Daten der Transportschicht nutzt wiederum das IP-Protokoll und damit den Internet Layer, um sicherzustellen, dass die Pakete auch ihr Ziel finden. Erst der Network Access Layer bringt die zwiebelförmig verpackten Daten auf das Kabel.

2.4 Die wichtigsten Protokolle Im Folgenden werden die wichtigsten Protokolle, beginnend mit denen des niedrigsten Layers, besprochen. Mit „wichtig“ sind hier Protokolle gemeint, die besonders relevant für die IT-Sicherheit von Netzwerken sind. Dieses Kapitel beginnt jedoch nicht mit der Erläuterung von Ethernet- oder PPP-Frames, sondern mit ARP, und wendet sich anschließend IPv4, ICMPv4, IPv6 und ICMPv6 zu. Danach werden TCP und UDP als Transport-Layer-Protokolle besprochen. Zum Abschluss des Kapitels werden die wichtigsten Application-Layer-Protokolle betrachtet (insbesondere DNS und HTTP).

2.5 Link Layer: ARP In Netzwerken kommunizieren Hosts über die oben erwähnten Frames miteinander. Diese Frames beinhalten eine Ziel- und eine Absenderadresse. Diese Adressen nennen sich MAC-Adressen (für Media Access Control, dt. Hardwareadressen) und sind zum Beispiel bei Ethernet-Netzwerken 48 Bit lang. MAC-Adressen sind in die

2.5  Link Layer: ARP

31

­ etzwerkkarten eingebrannt, aber einige Betriebssysteme ermöglichen es auch, diese N Adressen manuell und zumindest virtuell zu ändern. Doch woher weiß ein Rechner, welche MAC-Adresse ein anderer Host hat? An dieser Stelle kommt ARP, das Address Resolution Protocol, zum Einsatz. ARP wurde bereits 1982 durch RFC 826 spezifiziert [17]. ARP hat die Aufgabe, die für eine IP-Adresse zugehörige MAC-Adresse herauszubekommen. Jeder Rechner, der eine ARP-Anfrage (den sogenannten Request) versendet, behält die darauf enthaltene Antwort eines anderen Rechners – in dieser Antwort steht die Zuordnung von IP- zu MAC-Adresse – in seinem lokalen Speicher, dem ARP-Cache. Der ARP-Cache kann sowohl unter WindowsSystemen als auch unter Unix mit dem arp-Kommando abgefragt werden. Angenommen der Rechner mit dem Namen eygo.sun verwendet die IP-Adresse 192.168.0.1 und soll einen ping (das ist eine Art Test-Paket, das von einem Empfänger einfach nur mit einer gleichen Nachricht beantwortet wird) an den Host yorick.sun mit der IP-Adresse 192.168.0.5 senden. Und weiterhin angenommen, dass diese beiden Hosts bisher keinen Kontakt miteinander pflegten oder der letzte Kontakt schon so lange zurückliegt, dass die gegenseitigen ARP-Einträge bereits gelöscht wurden. (Tatsächlich werden die dynamischen ARP-Einträge nach einer gewissen Zeit aus dem ARP-Cache gelöscht.) In diesem Fall muss eygo.sun zunächst herausbekommen, welche MAC-Adresse der Host mit der IP-Adresse 192.168.0.5 besitzt. Er sendet eine Ethernet-BroadcastNachricht mit ARP-Request, das heißt eine Nachricht an alle Hosts im Netz, in der er nach der gewünschten MAC-Adresse fragt. Diese Nachricht beantworten aber jeweils nur solche Hosts, die eine Antwort auf diesen Request geben können. eygo.sun bekommt schließlich die Antwort, beispielsweise, dass 192.168.0.5 die MAC-Adresse 0:0:cb:59:fd:be hat. Diese Antwort nennt sich ein „ARP Reply“ und wird nicht mehr an die Broadcast-Adresse, sondern direkt an den Host gesendet von dem der ARP-Request ausging. Zur Verdeutlichung soll eine Betrachtung dieses Vorgehens mit dem Programm tcpdump unter dem OpenBSD-Betriebssystem dienen. Das Programm zeichnet den Datenverkehr im Netzwerk auf und ne3 ist hierbei schlicht die Bezeichnung der Netzwerkschnittstelle, auf der Netzwerkpakete aufgezeichnet werden. Der Parameter -vvv sorgt für eine detaillierte Ausgabe.

ARP-Cache auf demselben Rechner kann mithilfe des arp-Programms angezeigt werden und listet nun die beiden Kombinationen aus IP- und MAC-Adressen (IP- und MAC-Adresse der eigenen Netzwerkschnittstelle waren dem Rechner sowieso bekannt):

32

2  Grundlagen der Netzwerktechnik

Auf dem zweiten Host (ein Windows-PC) wurde der ARP-Cache ebenfalls aufgebaut:

2.5.1 Reverse-ARP Die Gegenfunktion zum ARP bietet das Reverse Address Resolution Protocol, kurz RARP. Im Gegensatz zum ARP löst es nicht IP- in MAC-Adressen, sondern MAC- in IP-Adressen auf. RARP benötigt einen zugehörigen Server, der die Anfragen der – meist plattenlosen – Clients auflöst. Wie Sie wohl schon erahnen, ist die Hauptaufgabe von RARP die Zuweisung von IP-Adressen an Thin-Clients. Allerdings ist zu sagen, dass RARP von BOOTP und DHCP praktisch komplett verdrängt wurde, da diese Protokolle einen besseren Funktionsumfang bieten.

2.5.2 Proxy-ARP Mittels Proxy-ARP kann ein Subnetz gespalten beziehungsweise zusammengefügt werden. Zwischen beiden Netzen fungiert eine Proxy-ARP-Einheit sozusagen als Router für ARP-Anfragen. Zudem sendet es die Pakete zwischen beiden Netzteilen hin und her. Proxy-ARP sollte jedoch nicht verwendet werden, da es sehr leicht ist, SpoofingAngriffe gegen dieses Protokoll durchzuführen.

2.6 Internet Layer: IPv4 Der Internet Layer arbeitet – wie bereits erwähnt – paketorientiert: die Frames des Link Layers mit ihren Signalisierungsmechanismen werden abstrahiert und die im Link Layer eingekapselten Dateneinheiten als Pakete bezeichnet. Die Aufgabe des Internet Layers besteht darin, Pakete von ihrer Quelle zum Ziel zu übertragen und dabei einen Weg über zwischengeschaltete Systeme (Hops) zu finden. Die Wegfindung ist die Aufgabe von

2.6  Internet Layer: IPv4

33

Routern. Eine weitere Aufgabe des Internet Layers ist die Adressierung und die Fehlerbehandlung. Im Folgenden werden die wichtigsten Protokolle dieser Schicht betrachtet, das sind IPv4 und IPv6 sowie ihre zugehörigen Protokolle, und dabei mit IPv4 begonnen. Das Internet Protocol Version 4 (IPv4) ist das derzeit noch immer wichtigste Netzwerkprotokoll des Internet Layers. Es wurde ursprünglich in den 1970er-Jahren als IENStandard und später durch RFC 760 spezifiziert [20]. Diese Spezifikation wurde in den folgenden Jahrzehnten immer wieder aktualisiert. Jedes IPv4-Paket beinhaltet einen mindestens 20 Byte großen Header, der in Abb. 2.9 dargestellt ist. Die einzelnen Headerbestandteile haben, der Reihenfolge ihres Auftretens nach, die folgenden Funktionen: • Version: Die IPv4-Protokollversion (valide ist nur Version 4 (beziehungsweise Version 6 für IPv6); Version 5 war ein experimentelles Protokoll). • Internet Headerlänge (Internet Header Length, IHL): Dieses Feld gibt die Anzahl der 32-Bit-Wörter des Headers an, entsprechend wird die Größe der eingekapselten Daten höherer Layer nicht mit eingerechnet. Im Normalfall beinhaltet der IPv4-Header 5 × 32 Bit an Daten. Da der IPv4-Header um Optionen erweitert werden kann, ist es möglich, in diesem Feld größere Werte als 5 zu erhalten. • Type of Service (ToS), Teil 1 (DSCP): Das Feld Differentiated Services Code Point (DSCP) implementiert Quality of Service (QoS), dabei handelt es sich um Qualitätsanforderungen für Pakete. In [7] lässt sich lesen: Diffserv uses six bits of the IPV4 or IPV6 header to convey the Diffserv Codepoint (DSCP), which selects a PHB. PHB steht für Per Hop Behavior und signalisiert, wie ein Paket behandelt wird, wenn es einen Router passiert. Der Standardwert für die PHB ist 000000 und bedeutet, dass (nach Möglichkeit) ein schnelles Weiterleiten des Pakets erfolgen soll. Die restlichen Werte (‘Codepoint-IDs’) werden von der Internet Assigned Numbers Authority (IANA) zugewiesen [8]. Typische Anforderungen für DSCP sind ein

Abb. 2.9   Aufbau des IPv4-Headers (jede Zeile entspricht 32 Bit)

34

2  Grundlagen der Netzwerktechnik

schneller Verbindungsaufbau, zuverlässige Datenübertragung mit wenig Störungen und hohe Verbindungsstabilität. Tanenbaum nennt verschiedenste Beispiele für die anwendungsabhängige Wahl dieser Anforderungen [27], etwa benötigt eine Videokonferenz eine geringe Zuverlässigkeit, weil es nicht schlimm ist, wenn einzelne Bild-Frames verlorengehen, stattdessen gibt es hierbei hohe Anforderungen hinsichtlich der Verzögerung einer Verbindung und ihrer Bandbreite. Bei einer Dateiübertragung gibt es hingegen eine hohe Anforderung an die Zuverlässigkeit einer Verbindung, doch ist die Anforderung an die Verzögerung von Paketen relativ gering. • ToS, Teil 2 (ECN, Explicit Congestion Notification): Die ECN-Bits werden nur benutzt, falls Empfänger und Sender sich auf die Nutzung derselben einigen. Anstatt Routerüberlastung nur durch Paketverlust zu detektieren, kann mit ECN eine drohende Überlastung signalisiert werden [8]. • Gesamtlänge (Total Length): Im Gegensatz zur zuvor besprochenen ‘Internet Header Length’ (IHL) repräsentiert dieses Feld die gesamte Größe des Datenpakets (IPv4Header samt Payload) in Bytes. Valide Werte liegen im Bereich von 20 Bytes bis 0 × 65535 Bytes. Die 20 Bytes ergeben sich aus der Minimalgröße des IPv4-Headers. • Identification (ID, auch IPID): Dieses Feld dient als Identifikationswert für ein Paket, es wird zur Wiederzusammensetzung nach einer Fragmentierung verwendet (siehe „Flags“ und Abschn. 2.6.2). • Flags: (3 Bits): Bit 0 hat immer den Wert 0 (es ist für die zukünftige Verwendung reserviert). Bit 1 verbietet das Fragmentieren (also Aufteilen des Pakets in mehrere kleine Pakete) und nennt sich Don’t Fragment-Flag (DF). Bit 2, das More Fragments-Flag (MF), signalisiert hingegen, dass dieses Paket ein Teilpaket eines ehemals größeren, aber nun fragmentierten, Pakets ist und weitere Fragmente folgen. Die weiteren Fragmente werden benötigt, um die finale Wiederzusammensetzung eines fragmentierten Pakets zu ermöglichen. • Fragment Offset: Dieses Feld zeigt an, an welcher Stelle im Empfangspuffer die im Paket enthaltenen Daten eines Fragments platziert werden müssen. Das heißt, das Fragment Offset gibt an, welcher Teil eines fragmentierten Pakets vorliegt und wo dieses Fragment eingesetzt werden muss, damit es, ähnlich einem Puzzlestück, zum ursprünglichen Gesamtpaket beiträgt. Es gibt 213 mögliche Fragment-Offset-Werte (das heißt: maximal 8.192 Fragmente pro Datenpaket). Jedes Fragment muss ein Vielfaches von 8 Bytes ausmachen. Damit gilt: 213 × 8 = 65.535 Bytes. Abzüglich der Header-Länge sind somit mehr Payload-Daten adressierbar, als ein unfragmentiertes Paket beinhalten kann. • Time to Live (TTL, 8 Bit): Dieser Wert wird von jedem Router, den ein Paket passiert, um 1 verringert (dekrementiert). Erreicht die TTL den Wert 0, wird das Paket verworfen. Bei den meisten Implementierungen wird für ein neues Paket der Wert 255 vergeben. Auf diese Weise können Routing-Loops verhindert werden, bei denen Pakete zwischen Routern unendlich lang im Kreis verschickt werden. • Protocol: Das Protocol-Feld spezifiziert das eingekapselte Netzwerkprotokoll und die Werte des Feldes sind standardisiert. Die häufigsten Werte sind: 1 (ICMP), 2 (IGMP),

2.6  Internet Layer: IPv4

•

• •



35

6 (TCP) und 17 (UDP). Außerdem wird über dieses Feld IPv4-Tunneling ermöglicht.10 Checksum: Dieses Feld speichert eine Prüfsumme über den Header und dient der Fehlererkennung. Dieses Feld wird von jedem passierten Hop neu berechnet, da sich jeweils die TTL verändert. Source IP Address und Destination IP Address (Quell- und Zieladresse des Datenpakets): Hierbei handelt es sich um einen jeweils 32 Bit großen Adressierungswert. Options: Dieses Feld wird nur in Spezialfällen verwendet (die zuvor besprochene IHL muss entsprechend erhöht werden, da sich durch Hinzufügen von Options-Bereichen die Headergröße erhöht). Die Options waren ursprünglich zur Weiterentwicklung von IP gedacht und in einem einzelnen IPv4-Paket können mehrere Options hintereinander untergebracht werden. Das Ende der Options muss mit einem EOL-Wert (End of Options List, Wert 0) signalisiert werden. Folgende Options sind aus IT-Sicherheitssicht von Interesse; diese Optionen wurden ursprünglich zur Netzwerkanalyse entwickelt und werden nun dazu verwendet, Angriffe durchzuführen beziehungsweise vorzubereiten: – Loose Source Routing: Hierbei werden Hosts angegeben, die von einem IP-Paket passiert werden müssen. Zwischen den angegebenen Hops können auch Hops liegen, die nicht angegeben werden. – Strict Source Routing: Im Gegensatz zur Loose Source Route wird hierbei eine exakte Vorgabe einer Route verwendet. Das Passieren nicht explizit festgelegter Hosts ist nicht zulässig. – Record Route: Hierbei wird eine passierte Route zu Diagnosezwecken aufgezeichnet. Jeder passierte Router fügt dabei seine eigene IP-Adresse an das Ende der Options hinzu.

Hinter dem IPv4-Header folgen die eingekapselten Daten (aus Sicht vom Internet Protocol handelt es sich dabei um Payload, tatsächlich jedoch um Transport LayerDaten). Entsprechend folgt in einem Netzwerkpaket direkt hinter dem letzten Byte des IP-Headers beispielsweise ein UDP- oder ein TCP-Header.

2.6.1 IP-Adressen Die bereits erwähnten 32-Bit-IP-Adressen dienen der eindeutigen Adressierung von Netzwerkrechnern in einem IP-Netzwerk (etwa einem lokalen Netzwerk oder dem Inter-

10Tunneling

bezeichnet die Einkapselung eines Protokolls gleicher oder niedrigerer Schicht in ein anderes Protokoll. Tunnel kommen etwa zum Einsatz, um von IPv4 auf IPv6 zu migrieren. Ein anderes Anwendungsgebiet stellen virtuelle private Netzwerke (VPNs), also private und zugleich gesicherte Netzwerkverbindungen zwischen Hosts beziehungsweise Netwerken, dar [29].

36

2  Grundlagen der Netzwerktechnik

Tab. 2.1  Für die Privatverwendung vorgesehene IP-Adressbereiche Adressbereich

Netzbits

Hostbits

Adressen

10.0.0.0 – 10.255.255.255

8

24

224 (ca. 16,7 Mio.)

172.16.0.0 – 172.32.255.255

12

20

220 (ca. 1 Mio.)

192.168.0.0 – 192.168.255.255

16

16

216 (ca. 65.500)

net).11 Zwar lässt sich einiges über IP-Adressen und ihre Vergabe12 schreiben, doch sind diese Themen für dieses Buch nur von begrenzter Relevanz. IP-Netzwerke können in Teilnetze (Subnetze) gegliedert werden. Subnetze sind Bereiche aufeinander folgender IP-Adressen. Definiert werden Subnetze mit einer Subnetzmaske, die aus einem 32-Bit-Wort besteht. Die Subnetzmaske besteht genauer gesagt aus 1er-Bits, gefolgt von 0er-Bits. Dadurch gibt die Subnetzmaske an, wie viele Bits einer IP-Adresse das Netzwerk spezifizieren (1er-Bits) und wie viele Bits in diesem Netzwerk für den Host verwendet werden (0er-Bits). Die Schreibweise zur Angabe eines Netzwerks samt Subnetz ist a.b.c.d/n, wobei a.b.c.d die IP-Adresse und n die für das Netzwerk verwendeten Bits angeben. Es verbleiben folglich 32 − n Bits für die Adressierung von Hosts in diesem Netzwerk. Zum Beispiel würde 7.0.0.0/8 uns verdeutlichen, dass acht Bits für das Netzwerk und 24 Bits für Hosts (also 224 IP-Adressen) verwendet werden. Üblicherweise ist die erste Adresse in einem Netzwerk die Adresse des Netzwerks selbst, im obigen Fall also 7.0.0.0. Der erste adressierbare Host ist die nächste IP-Adresse (das Bit mit der geringsten Wertigkeit wird inkrementiert, das heißt 7.0.0.1). Der letzte Host im Netzwerk erhält die vorletzte IP-Adresse im Subnetz (7.255.255.254) und die letzte Adresse dient als Broadcast-Adresse (hier also 7.255.255.255). Zudem gibt es einige für die Privatverwendung vorgesehene IP-Adressbereiche, die jeder Nutzer verwenden darf und die nicht im Internet geroutet werden (siehe Tab. 2.1). Localhost: Um mit dem eigenen Rechner (dem Localhost) zu kommunizieren gibt es die IPv4-Adressen im Bereich 127.0.0.1–127.255.255.255. Somit steht jedem Rechner das Subnetz 127.0.0.0/8 zur Verfügung.

11Anm.:

Es gibt Techniken, wie Network Address Translation (NAT), die eine eindeutige Identifizierung von Netzwerkrechnern für Systeme außerhalb eines internen Netzes verhindern. 12Die Vergabe der IP-Adressen erfolgte ursprünglich durch die IANA. Später vergab die IANA nur noch Adressen an Regional Internet Registry-Organisationen (RIRs), etwa APNIC (Asia-Pacific Network Information Center) oder RIPE (Réseaux IP Européens Network Coordination Centre).

2.6  Internet Layer: IPv4

37

Die Darstellung einer IP-Adresse in der Form a.b.c.d ist nur eine von vielen Möglichkeiten, die 32 Bits der Adresse darzustellen. Alternativ könnten auch 32 Nullen und Einsen zur Darstellung der binären Form dienen. Auch kann die Adresse Hexadezimal oder mit weniger Dezimalpunkten getrennt dargestellt werden. So lässt sich 127.0.0.1 beispielsweise auch als 0x7F000001 oder 127.1 darstellen.

2.6.2 Fragmentierung Für Netzwerkverbindungen existieren Limits hinsichtlich der maximalen Größe an Daten, die durch eine Frame des Link Layers übertragen werden können, die sogenannte Maximum Transmission Unit (MTU). Die MTU bezieht dabei nicht die Frame des Network Access Layers ein, sondern ausschließlich die Daten ab dem Internet Layer.13 Für Ethernet- und WLAN-Verbindungen beträgt die MTU meist 1500 Bytes. Die MTU eines Rechners lässt sich unter unixartigen Systemen mit ifconfig und unter Windows mit ipconfig abfragen:

Verschickt ein Rechner, wie in Abb. 2.10 dargestellt, ein zu großes Paket über eine Route, die mehrere Netzwerkverbindungen passieren muss, so muss das Paket aufgeteilt (fragmentiert) werden. Angenommen, das Ausgangspaket sei 1600 Bytes groß und hat die Fragment ID 123. Für die Fragmentierung kommen die oben bereits erwähnten IP-Felder Identification, Flags und Fragment-Offset zum Einsatz. Das 1600 Bytes große Paket soll nun zur Verdeutlichung des Verfahrens über eine Verbindung mit einer MTU von 1492 Bytes übertragen werden. Zunächst wird der erste Teil des Pakets (20 Bytes für den IP-Header samt den ersten 1472 Bytes des Payloads) über die Verbindung übertragen und das More Fragments-Flag gesetzt. Das Abschneiden nach den ersten 1472 Bytes ist notwendig, denn 1492 Bytes MTU – 20 Bytes für den IP-Header ergeben den Maximalwert für den anhängbaren Payload (also 1472 Bytes). 1472 Bytes sind gleichzeitig ein Vielfaches von

13Beziehungsweise

dem Network Layer im OSI-Modell.

38

2  Grundlagen der Netzwerktechnik

Abb. 2.10   Beispiel für die Fragmentierung durch IPv4. Ein 1600 Bytes großes Paket muss über eine Verbindung mit einer MTU von 1492 Bytes übertragen werden

8 Bytes und somit ein valider Wert für das Fragment-Offset des folgenden Paketes (das Fragment-Offset des ersten Paketes ist 0). Die restlichen Payload-Daten (1600 Bytes abzüglich 20 Bytes für den ursprünglichen Header und 1472 Bytes an bereits übertragenem Payload, also 108 Bytes an Payload) werden in ein zweites Paket gepackt, welches denselben Header, wie das erste Fragment erhält (auch der Identifier-Wert 123 ist derselbe). Im zweiten Fragment wird das Fragment-Offset angepasst und erhält den Wert 184 (= 1472 Bytes aus Fragment 1, dividiert durch Vielfache von 8 Bytes). Außerdem wird im zweiten Fragment das More Fragments-Flag nicht mehr gesetzt, da keine weiteren Fragmente mehr folgen. Nachdem das zweite Paket übertragen wurde, kann der Empfänger es verarbeiten. Die Wiederzusammensetzung eines Pakets erfolgt ausschließlich beim Empfänger und wird von keinem zwischengeschalteten Router vorgenommen, da einzelne Fragmente in IPNetzen unterschiedliche Pfade passieren können. Es ist aus diesem Grund auch nicht sichergestellt, dass ein Router jedes Fragment eines Paketes erhält. Basierend auf dem Wert des Fragment-Offsets kann der Empfänger selbst dann die Payload-Bestandteile der einzelnen Fragmente in der richtigen Reihenfolge zusammensetzen, wenn diese in einer Reihenfolge ankamen, in der sie gar nicht verschickt wurden.14

14Wie bereits erwähnt, können einzelne Pakete (somit also auch Fragmente, die an sich wieder Pakete sind) unterschiedliche Pfade zum Ziel nehmen. Ein Weg über Pfad A kann länger benötigen, als ein Weg über Pfad B oder C, womit Paketreihenfolgen vertauscht werden können, weil sich Pakete während der Zustellung gegenseitig überholen.

2.7  Internet Layer: ICMPv4

39

Abb. 2.11   Aufbau des ICMPv4-Headers

2.7 Internet Layer: ICMPv4 ICMP (Internet Control Message Protocol) wurde 1981 in RFC 777 spezifiziert [21]. Es dient, wie sein Name schon verrät, der Kontrolle des IP-basierten Datenverkehrs. Genauer gesagt dient es der Fehleranalyse, der Informationserstattung und der Konfiguration von IP-Hosts und -Netzen. Der Standardaufbau des ICMPv4-Headers ist simpel und in Abb. 2.11 zu sehen. Der ICMP-Type spezifiziert die gewünschte Hauptfunktion eines ICMP-Pakets, die durch den ICMP-Code genauer spezifiziert werden kann. Die Prüfsumme hat dieselbe Funktion wie im IP-Header. Nach den ersten 32 Bytes des ICMP-Headers folgen Inhalte, die vom jeweiligen ICMP-Type abhängen. Die IANA (Internet Assigned Numbers Authority) hat eine offizielle Liste der ICMPTypes und zugehöriger ICMP-Codes veröffentlicht [10]. Die wichtigsten dieser ICMPTypen sollen im Folgenden besprochen werden.

2.7.1 ICMP-Types 0 und 8 Die wohl bekanntesten ICMP-Typen sind Type 0 und Type 8. Ersterer ist der sogenannte Echo Reply, letzterer der Echo Request. Diese beiden ICMP-Typen werden in der Regel zur Feststellung der Erreichbarkeit eines Hosts verwendet. Man spricht bei diesem Test auch von einem Ping. Eine ICMP-Echo-Nachricht besteht aus einem 16-Bit-Identifer sowie einer 16-BitSequenznummer zur Identifikation der Datagramme. Optional können noch Daten an das Paket angehängt werden, um die Netzlast zu erhöhen. Dies ergibt besonders bei Performance-Tests Sinn, denn die Datagramme müssen inklusive Payload bestätigt werden. Ein Ping funktioniert folgendermaßen: Host A sendet einen Echo Request an Host B, Host B antwortet darauf mit einem Echo Reply. Alternativ kann A den Echo Request auch per Broadcast an ein Netzwerk senden und erhält anschließend eine Antwort der Hosts im Netzwerk.

40

2  Grundlagen der Netzwerktechnik

2.7.2 ICMP-Type 3 Der ICMP-Type 3 (Destination Unreachable) wird immer dann versendet, wenn ein Datagramm nicht zugestellt werden konnte. Genauere Information zum Grund der Fehlzustellung gibt der ICMP-Code an. Es gibt folgende Möglichkeiten: • Code 0 (Net Unreachable): Das Zielnetzwerk ist nicht erreichbar. Dies kann zum Beispiel auf fehlende Einträge in der Routingtabelle zurückzuführen sein. • Code 1 (Host Unreachable): In diesem Fall ist zwar das Netzwerk, jedoch nicht der Host erreichbar. Entweder wurde die falsche Adresse angegeben oder der Host hat technische Probleme beziehungsweise ist ausgeschaltet. • Code 2 (Protocol Unreachable): Bekommt man diese Fehlermeldung, ist das Protokoll, an das das Datagramm weitergereicht werden soll, nicht erreichbar. • Code 3 (Port Unreachable): Diese Meldung wird ausgesandt, wenn das Datagramm – im Transport Layer also ein TCP-Streampaket oder eine UDP-Message – nicht an den entsprechenden Port weitergereicht werden konnte. Portscanner benötigen, je nach Scan-Technik, Port Unreachable-Nachrichten, um festzustellen, ob ein bestimmter Port erreichbar ist. • Code 4 (Fragmentation Needed, DF Flag Set): Diese Meldung wird ausgesandt, wenn ein Datagramm mit dem gesetzten Bit Don’t Fragment (DF) versandt wurde, aber zu groß für die MTU eines Netzes ist. Dieser Code wird in Verbindung mit der PathMTU-Discovery15 und der Fragmentierung (siehe Abschn. 2.6.2) verwendet. • Code 5 (Source Route Failed): Wurde ein IP-Datagramm mit einer Loose- oder StrictSource-Route-Option versandt, wird diese Meldung im Falle einer nicht gangbaren Route gesandt. • Code 6 (Destination Network Unknown): Ist ein Netzwerk gar nicht vorhanden, wird diese Nachricht versandt. • Code 7 (Destination Host Unknown): Ist ein einzelner Host gar nicht vorhanden, wird diese Nachricht versandt. • Code 8 (Source Host Isolated): Dieser Typ findet normalerweise gar keine Verwendung und gilt als obsolet. • Codes 9 und 10 (Communication with Destination Network/Host Administratively Prohibited): Die Kommunikation zum Netzwerk beziehungsweise Host wurde vom Administrator untersagt.

15Path-MTU-Discovery bedeutet, dass ein Host künstlich zu große Pakete an dasselbe Ziel sendet, die er so lange verkleinert, bis er keine ICMP Meldungen mit Type 3, Code 4 mehr erhält. Die daraus resultierende Paketgröße ist die größte für den Pfad nutzbare und wird für die Kommunikation mit einem Ziel verwendet, um Fragmentierungen zu verhindern. Das ist nicht perfekt, da es insbesondere schlecht auf Situationen reagieren kann, bei denen sich Routingpfade zwischenzeitlich ändern.

2.7  Internet Layer: ICMPv4

41

• Codes 11 und 12 (Network/Host Unreachable for Type of Service): Diese Meldung wird versandt, wenn das Zielnetzwerk beziehungsweise der Zielhost nicht für den angegebenen Type-of-Service (siehe oben) erreichbar ist. • Code 13 (Communication Administratively Prohibited by Filtering): Die Kommunikation zum Zielsystem ist nicht möglich, da ein Firewall-System den Datenverkehr blockt. Der Header dieser Nachricht ist nach dem statischen Headerteil mit einem 32 Bit langen und ungenutzten Bereich versehen. Anschließend folgt der IP-Header des ursprünglichen Datagramms samt, gegebenenfalls gekürzten, Payload. Der Grund für diesen Anhang liegt in den besseren Diagnosemöglichkeiten, die sich aus den zusätzlichen Informationen ergeben.

2.7.3 ICMP-Type 4 ICMP-Type 4 (Source Quench) wird von einem Empfänger versandt, wenn zu viele Pakete bei ihm eintreffen. Der Sender dieses Types teilt dem Empfänger mit, dass dieser seine Aussenderate drosseln soll. Diese Funktionalität wird in Verbindung mit dem TCPProtokoll ermöglicht. Dieses Verfahren trägt zur Flusskontrolle bei. Die Hauptaufgabe besteht darin, überlastete Prozessoren und Netzwerkschnittstellen zu verhindern.

2.7.4 ICMP-Type 5 ICMP-Type 5 (Redirect) wird zur Umlenkung von Routen verwendet. Wird ein Router verwendet, um ein Paket zuzustellen, und kennt dieser Router zusätzlich einen besseren Pfad zum Ziel als den, der über ihn selbst führt, so kann der Router zum Absender des betreffenden Pakets eine ICMP-Redirect-Nachricht senden. Der Absender wird daraufhin die eigene Routingtabelle so abändern, dass er seine Pakete über den vom Router empfohlenen „besseren“ Router sendet. Alternativ kann der Absender die RedirectMeldung ignorieren. Via ICMP Redirect können Datagramme zu einem Host (Code 1), zu einem Netzwerk (Code 0) oder Type-of-Service-basierend für einen Zielhost (Code 3) oder ein Zielnetzwerk (Code 2) umgeleitet werden.

2.7.5 ICMP-Types 9 und 10 ICMP-Type 9 (Router Advertisement) wird zur Bekanntgabe von Routern verwendet, während Type 10 (Router Solicitation) diese Meldung anfordert. So kann ein Host sich

42

2  Grundlagen der Netzwerktechnik

über die im Netzwerk befindlichen Router informieren und seine Routingtabelle selbst konfigurieren.

2.7.6 ICMP-Type 11 Eine Nachricht vom Type 11 (Time Exeeded for Datagram) wird versandt, wenn die TTL eines IP-Datagramms abgelaufen ist. Der Host, bei dem die TTL den Wert 0 erreicht, versendet diese Nachricht an den ursprünglichen Absender des Datagramms. Im Normalfall ist der ICMP-Code dann 0. Kommt jedoch eines (oder mehrere) von mehreren Fragmenten nicht an, so wird der ICMP-Code auf den Wert 1 gesetzt. Wird zum Beispiel versucht, dem Host www.google.de ein Echo Request zu senden, das mit einer TTL von 1 versehen ist, so wird dieses Datagramm (wenn man sich nicht gerade im entsprechenden Subnetz des Hosts befindet) sein Ziel nicht erreichen. Stattdessen wird der nächste Router, der die TTL auf den Wert 0 dekrementiert, ein ICMPType-11-Datagramm zu dem Host zurücksenden, der das ICMP-Echo-Paket gesendet hat. Eine Betrachtung der zwei Pakete verrät mehr Einsicht:

Zu sehen ist hier, dass der Host 192.168.0.1 ein ICMP-Echo-Request an den Host 216.239.59.104 sendet. Dies jedoch kommt nur bis zum Router des lokalen Subnetzes (in diesem Fall ist dies der Router mit der IP-Adresse 192.168.0.2). Der Router 192.168.0.2 sendet nun die Meldung an den Host 192.168.0.1 zurück, dass die TTL des ICMP-Datagramms abgelaufen ist.

2.7.7 ICMP-Type 12 Ein Parameter Problem (ICMP-Type 12) liegt vor, wenn im Optionsbereich des IPHeaders ein dem Host unbekannter Parameter gefunden wurde. Der Host verwirft dieses Datagramm und sendet ICMP-Type 12 zum Sender zurück.

2.8 Internet Layer: IGMP

43

2.7.8 Weitere ICMP-Typen Es gibt noch einige weitere ICMP-Typen, doch sollten an dieser Stelle nur die wichtigsten von ihnen besprochen werden. Eine vollständige Liste aller ICMP-Parameter erhalten Sie bei der IANA unter http://www.iana.org/assignments/icmp-parameters [10].

2.8 Internet Layer: IGMP Das Internet Group Management Protocol (IGMP, Protokollnummer 2) wird zur Verwaltung von IPv4-Multicast-Gruppen verwendet. Die aktuelle Version IGMPv3 wurde 2002 durch RFC 3376 standardisiert. IGMP verwendet explizit für Multicast vorgesehene IP-Adressen (Bereich 224.0.0.1–239.255.255.255 [11]), um die Adressierung einer Multicast-Gruppe zu ermöglichen. Die Möglichkeit des MulticastSendens ist besonders bei Radio- und Videoübertragungen von Belang.

2.8.1 Der IGMPv2-Header Der Einfachheit halber betrachtet dieses Kapitel primär IGMPv2. Der IGMPv2-Header ist recht simpel aufgebaut. Im Folgenden werden die einzelnen Felder des Headers besprochen (Abb. 2.12). Das Type-Feld kann einen der folgenden Werte enthalten: • • • •

Membership Query (0 × 11) Version 1 Membership Report (0 × 12) Version 2 Membership Report (0 × 16) Version 2 Leave Group (0 × 17)

Ein Multicast-Router sendet Membership Querys zu den Hosts seines Netzwerks. Dies hat den Zweck herauszufinden, welche Multicast-Gruppen welchem lokalen Teilnehmer zugeordnet sind. Dabei unterscheidet man zwischen einer generellen Query, die an alle

Abb. 2.12   Aufbau des IGMP-Headers

44

2  Grundlagen der Netzwerktechnik

Gruppen gerichtet ist, und einer gruppenspezifischen Query, welche sich an eine einzelne Gruppe richtet. Dabei wird die Zieladresse 224.0.0.1 verwendet. Ein Host sendet darauf als Bestätigung ein Reply-Paket und verwendet dabei als Zieladresse die Adresse der Multicast-Gruppe, die er zudem auch im Feld Group Address des IGMP-Headers angibt. Ein Host kann an eine Gruppe senden, in der er selbst kein Mitglied ist, und kann gleichzeitig Mitglied in verschiedenen Gruppen sein. Die Maximum Response Time ist nur in Querys gesetzt und gibt die Zeitspanne (in Zehntelsekunden) an, die der Router auf einen Membership Report wartet, bevor er den Host aus der Verteilerliste der Gruppe entfernt. Das Feld Checksum sollte Ihnen bereits von IP und ICMP bekannt sein. Das Feld Group Adress enthält die Adresse einer Multicast-Gruppe, an die ein IGMP-Paket versendet wird. In den oben erwähnten „generellen“ Querys wird die Gruppenadresse mit Nullen überschrieben. In IGMPv3 werden im Header zusätzlich die Senderquellen samt eines Adressvektors und Robustness-Werten übertragen, wodurch der Headeraufbau komplexer wird. Im Kontext dieses Buches sind diese Features allerdings nicht von Bedeutung.

2.9 Internet Layer: IPv6 Der Nachfolger der Internet Protokollversion 4 wurde Version 6. Sie wurde bereits im Dezember 1995 in RFC 1883 beschrieben [4] und – wie wohl alle wichtigen Protokollstandards – erfuhr der Standard in den folgenden Jahren wiederholt Überarbeitungen. Erste IPv6-Netze existierten seit 1996 (insbesondere das „6Bone“-Netz). Es gab verschiedene Gründe dafür, eine neue Version des Protokolls zu entwickeln. Der wohl bekannteste Grund ist der, dass der Adressraum (es gibt über 4 Milliarden IPv4Adressen) knapp wurde. Zu Anfang ging man recht großzügig mit der Vergabe der IPAdressen um, und einige große Institutionen und Firmen in den Vereinigten Staaten bekamen gleich ganze Class-A-Netze zugeteilt. Europa kam bei der Verteilung der Adressen noch relativ gut weg, doch Asien und Afrika leiden unter Adressknappheit. Eine Maßnahme gegen die stetig schwindende Anzahl verfügbarer IPv4-Adressen ist die Network Address Translation (NAT), bei der viele private IP-Adressen wenige öffentliche IP-Adressen gemeinsam nutzen. Doch auf Dauer wird dies nicht mehr ausreichend sein – besonders nicht, wenn immer mehr mobile Geräte wie Handys und diverse Hausgeräte (Kühlschränke etc.) miteinander vernetzt werden. Ein weiterer wichtiger Grund für die Einführung von IPv6 ist die zumindest leicht verbesserte IT-Sicherheit im Vergleich zu IPv4. So ist IPSec Bestandteil von IPv6, und der Aufbau des Headers ist logischer und flexibler. Weiterhin unterstützt IPv6 eine Autokonfiguration der Netzwerkverbindungen ähnlich der des Dynamic Host Configuration Protocols (DHCP), Quality of Service (QoS), Mobile IP und Multicast. Anders formuliert macht IPv6 einige bisherige Protokolle überflüssig.

2.9  Internet Layer: IPv6

45

Abb. 2.13   Aufbau des IPv6-Headers

In Abb. 2.13 sehen Sie den IPv6-Header. Wie bei IPv4 werden die ersten 4 Bits zur Angabe der Versionsnummer (Version) verwendet. Die nächsten 8 Bits stellen die Traffic Class dar. Diese Traffic Class dient der Prioritätsangabe, etwa wie beim DSCP-Feld des IPv4-Headers. Die folgenden 20 Bits (Flow Label genannt) dienen der Identifikation eines Datenstroms – hiermit sollen auch Performancezuwächse in Routern möglich sein, da diese über einen Hash auf diese Zahl eventuelle Fragmente schneller zusammensetzen können. Die Länge des Payloads (Payload Length) wird in den nächsten 16 Bits angegeben. Hierbei ist zu beachten, dass mögliche zusätzliche IPv6-Headererweiterungen als Payload gelten. Der Payload berechnet sich also aus den IPv6-Erweiterungsheadern (dazu später mehr) plus den Headern der höheren Protokolle plus dem Payload des Protokolls der höchsten eingekapselten Schicht. Zum Beispiel kann die Payload Length eines HTTP-Pakets die Summe aus der Größe eines optionalen IPv6-Headers, des TCPHeaders, des HTTP-Headers und des HTTP-Payloads sein. Das Feld Next Header gibt an, wie der nächste Header auszuwerten, besser gesagt, an welchen Protokollhandler das Paket weiterzugeben ist. Typische Werte sind 6 (TCP) oder 17 (UDP). Unter IPv4 heißt dieses Feld Protocol. Dieses Feld wird aber auch zur Angabe der IPv6-Extension Header verwendet. Das sogenannte Hop Limit hat die gleiche Funktion wie das Feld Time to Live bei IPVersion 4. Es wird ebenfalls durch einen 8 Bit langen Wert (vom Typ unsigned integer) repräsentiert, dessen Wert bei jedem Hop um 1 verringert wird. Erreicht das Feld den Wert 0, wird das Paket verworfen. Typische Werte (wie auch bei IPv4) werden bei heutigen Betriebssystemen nicht mehr auf 255, sondern auf einen Wert ≥64 gesetzt. Routen über das Internet sind in den meisten Fällen nicht länger als 32 Hops [31]. Es folgenden zwei jeweils 128-Bit lange IPv6-Adressen für Sender und Empfänger der Nachricht.

46

2  Grundlagen der Netzwerktechnik

2.9.1 IPv6-Adressen IPv6 hat im Vergleich zu IPv4 genau viermal so große Adressen. IPv6-Adressen werden dabei in Hex-Form zu jeweils 16 Bit mit getrennten Doppelpunkten dargestellt.16 Ein Beispiel für eine IPv6-Adresse wäre etwa: 1234:1234:2342:2342:1234:1234:2342:2342 Folgen ein oder mehrere 16-Bit-Gruppen, die den Wert 0000 haben, aufeinander, kann dies durch zwei Doppelpunkte dargestellt werden. Die Adresse 1234:1234:2342:0000:0000:0000:2342:2342 könnte also auch folgendermaßen dargestellt werden: 1234:1234:2342::2342:2342. Es ist immer nur eine einzige Doppelpunkt-Gruppe bei der Darstellung durch zwei Doppelpunkte pro Adressangabe erlaubt. Damit Sie einen Eindruck davon bekommen, wie viele Adressen es theoretisch gibt: Es sind ganze 2128 = 340.282.366.920.938.463.463.374.607.431.768.211.456 Stück. IPv6-Adressen können automatisch für Netzwerk-Interfaces generiert werden. Hierzu wird aus der Hardware-Adresse (MAC-Adresse, 48 Bit) eine IPv6-Adresse berechnet. Dieses Schema ist durch den IEEE EUI-64-Standard spezifiziert, doch werden heute meist andere Verfahren verwendet. Alternativ können Adressen mit der IPv6-Version von DHCP (DHCPv6) und ICMPv6 vergeben und bekanntgegeben werden. Weiterhin besteht mit Cryptographically Generated Addresses (CGA) eine Möglichkeit, Signaturen öffentlicher, kryptografischer Schlüssel in IPv6-Adressen einzurechnen (siehe Abschn. 8.3.3). Localhost: Um mit dem eigenen Rechner zu kommunizieren, gibt es die IPv6Adresse ::1, sie verwendet das Subnetz ::1/128.

2.9.2 IPv6 Header Extensions Ein IPv6-Header besteht im Minimalfall nur aus dem Basis-Header. Diesen lernten Sie bereits oben kennen. Doch neben diesem Header gibt es noch die folgenden weiteren Header (wobei die Reihenfolge der tatsächlichen Reihenfolge der Aneinanderkettung entspricht, diese kann nämlich nicht willkürlich gewählt werden): • Hop-by-Hop Options und Destination Options: Hier können Optionen für jeden Host, den ein Paket passiert (Hop-by-Hop) oder für das Ziel des Pakets (Destination) festgelegt werden. RFC 2460 definiert zunächst nur 2 Bits (also 4 Kombinationen) der 8 Bits mit Funktionen, die insgesamt zur Verfügung stehen. Dabei kann eine Option entweder übergangen (0) oder das Paket (mit einer Bedingung) verworfen werden (1–3). 16Selbstverständlich sind auch andere Repräsentationen von IPv4-Adressen möglich, etwa als HexDarstellung. Die Adresse 127.0.0.1 kann entsprechend als 0x7f000001 dargestellt werden.

2.10 Internet Layer: ICMPv6

47

Abb. 2.14   Aneinanderreihung der IPv6-Extension Headers

• Routing: Routing-Optionen ähnlich denen von IPv4; es kann eine Liste von Hops festgelegt werden, die das Paket passieren soll. • Fragment: Dieser Header bietet eine ähnliche Funktionalität wie die FragmentFelder des IPv4-Headers – auch dieser besteht aus dem Fragment-Offset, dem MoreFragments-Bit und einem Identifikationsfeld. • Authentication: Der Authentication-Header (kurz AH) gewährleistet die Authentizität eines Datenpakets. In Abschn. 5.3.1 wird dieses Thema genauer besprochen. Der Authentication-Header kann auch in Verbindung mit dem ESP-Header verwendet werden. • Encapsulation Security Payload: Der Encapsulation-Security-Payload-Header (kurz ESP) wird in Abschn. 5.3.1 detailliert erläutert. Er sichert sowohl Authentizität als auch Vertraulichkeit. ESP kann mit dem AH kombiniert werden. • Destination Options: Optionen für das Ziel eines eingekapselten Pakets. Jeder Extension Header sollte nur ein einziges Mal in einem IPv6-Paket vorkommen. Die einzige Ausnahme ist der Header Destination Options, der bis zu zweimal vorkommen darf. Ihnen dürfte vielleicht aufgefallen sein, dass die Destination Options oben zweimal gelistet sind. Dies liegt daran, dass nur das erste Vorkommen der Destination Options für das eigentliche IPv6-Paket gilt. Das zweite Vorkommen bezieht sich auf ein eingekapseltes IPSec-Paket. Jeder Header gibt bei IPv6 den nächsten Header an (über das Feld Next Header). Die Aneinanderreihung der Header ist in Abb. 2.14 dargestellt. Wenn ein IPv6-Paket beispielsweise aus einem IPv6-Header, einem Routing Header und einem TCP-Segment besteht, dann gibt das Next-Header-Feld im Basis-Header an, dass es sich beim folgenden Header um einen Routing Header handelt. Der Routing Header gibt wiederum an, dass der folgende Header ein TCP-Header ist. Der Wert 59 im Feld Next Header gibt an, dass dem aktuellen Header kein weiterer Header folgt.

2.10 Internet Layer: ICMPv6 Wie auch bei IPv4, so wurde auch für IPv6 ein ICMP-Protokoll entwickelt. Ursprünglich wurde ICMPv6 in RFC 1885 spezifiziert [2]. Das Protokoll bekam die Protokollnummer 58 und ist ähnlich zu seinem Vorgänger ICMPv4 aufgebaut. Jeweils 8 Bit stellen den ICMP-Type und -Code dar. Es folgen eine 16-Bit Checksum und die typabhängigen Daten.

48

2  Grundlagen der Netzwerktechnik

Seit Version 6 des ICMP-Protokolls sind die ICMP-Typen in zwei Bereiche unterteilt: Fehlermeldungen und Informationsmeldungen. Den Fehlermeldungen wurde der Typbereich von 0 bis 127, den Informationsmeldungen der Bereich 128 bis 255 zugewiesen. Zudem verfügt die neue ICMP-Version nun auch über Multicast-Fähigkeiten, wie sie das IGMP-Protokoll zur Verfügung gestellt hat, und Möglichkeiten zur automatischen Adressvergabe (DHCP-Ersatz), Routingkonfiguration und der Neighbour Discovery (ARP-Ersatz17). Es gibt folgende ICMPv6-Fehlermeldungen: • 1. Destination Unreachable: Das Zielsystem ist aus einem Grund, der im Code genauer spezifiziert wird, nicht erreichbar. • 2. Paket too big: Das Paket ist zu groß für einen Netzabschnitt, weil es größer als die zulässige MTU ist. Diese Meldung wird nur versandt, wenn das DF-Flag gesetzt war. • 3. Time Exeeded: Das Hop-Limit erreichte den Wert 0 und das Datagramm wurde verworfen. • 4. Parameter Problem: Der Header des Paketes enthielt Fehler und konnte daher nicht korrekt ausgewertet werden. Außerdem gibt es folgende ICMPv6-Informationsmeldungen: • 128. Echo Request: Eine ICMP-Echo Anforderung (analog zum ICMPv4 Echo Request). • 129. Echo Reply: Die Antwort auf obige Anforderung (analog zum ICMPv4 Echo Reply). • 130. Group Membership Query: Hierbei handelt es sich um eine Funktionalität, wie sie bereits von IGMP Queries bekannt ist. • 131. Group Membership Report: Hierbei handelt es sich um eine Funktionalität, wie sie bereits vom IGMP Reports bekannt ist. • 132. Group Membership Reduction: Dieser Typ wird zum Austritt aus einer Multicast-Gruppe verwendet (analog zu IGMP Leave Group). • 133. Router Solicitation: Anfrage nach einem Router (analog zu ICMPv4). • 134. Router Advertisement: Router-Bekanntmachung (analog zu ICMPv4). • 135. Neighbour Solicitation: Anfrage nach der MAC-Adresse eines anderen Hosts im Netz. Diese Funktionalität ersetzt das Adress Resolution Protocol. • 136. Neighbour Advertisement: Dieser ICMP Type gibt die MAC-Adresse einer Schnittstelle bekannt und ist analog zu einem ARP-Reply zu sehen. • 137. Redirect: Dieser Typ ist ebenfalls schon von ICMPv4 bekannt und wird zur Umleitung von Routen verwendet.

17Für Neighbour Discovery kommt das sogenannte Neighbour Discovery Protocol (NDP) als Teil von ICMP zum Einsatz.

2.11  Transport Layer: UDP

49

2.11 Transport Layer: UDP Die Abkürzung UDP steht für User Datagram Protocol. UDP wurde in RFC 768 spezifiziert [19]. UDP-Pakete werden als Datagramme bezeichnet. Bei UDP handelt es sich um ein verbindungsloses Transport-Layer-Protokoll. Das heißt, für UDP müssen keine Verbindungen auf-, abgebaut und verwaltet werden. Datagramme werden unabhängig voneinander betrachtet. Da UDP nur über minimale Funktionalitäten bezüglich der Fehlerkorrektur – nämlich eine Checksum – verfügt, bleibt die Prüfung des Datenflusses, falls dieser kontrolliert ablaufen muss, dem Application Layer überlassen. Aufgrund dieser Eigenschaft verfügt UDP zwar über einen recht kleinen Header, wird aber generell nicht in Applikationen eingesetzt, bei denen eine gesicherte Nachrichtenübertragung gewährleistet sein muss. Einsatzgebiete für UDP sind in der Regel solche, bei denen Datagramme in periodischen Abständen (Aktualisierungs-)Nachrichten übertragen sollen oder beim Verlust einer Nachricht keine Schwierigkeiten auftreten, da Anfragen einfach wiederholt werden (etwa bei DNS oder DHCP).

2.11.1 Der UDP-Header Der UDP-Header ist, wie bereits angesprochen, nicht sonderlich groß, da er nur die für den Kernel des Betriebssystems wichtigsten Informationen beinhaltet. Der UDP-Header ist in Abb. 2.15 dargestellt und hat eine Größe von 8 Bytes (zum Vergleich: der TCPHeader hat eine Größe von 20 Bytes). Die ersten 32 Bits bestehen aus dem Source Port (Quellport) und dem Destination Port (Zielport). Es folgen die Längenangabe des gesamten Datagramms (Header plus Payload; der Standard verlangt eine Angabe in Oktetten) und die Checksum zu jeweils 16 Bits. Da jeweils 16 Bits pro Port zur Verfügung stehen, was auch beim TCP-Protokoll der Fall ist, können also maximal 65.535 verschiedene Ports adressiert werden, da der Null-Port nicht verwendet wird. Generell gilt: Die ersten (meist 1024) Ports sind in dem Sinne „privilegierte“ Ports, als dass sie nur über administrative Rechte gebunden werden können. Die Portanzahl ist dabei betriebssystemspezifisch. Folglich kann

Abb. 2.15   Der UDP-Header

50

2  Grundlagen der Netzwerktechnik

ein Webserver an Port 80 nur mit Root-Rechten gebunden werden. Unter den meisten gängigen Systemen ist es möglich, die UDP-Checksum zu vernachlässigen. Sie kann mit Kommandos wie sysctl abgeschaltet werden, was sich auf stark belasteten Systemen positiv auf deren Performance auswirken kann, allerdings auf Kosten der Verbindungsqualität. Die Checksum berechnet sich (und dies ist, wie Sie später sehen werden, auch beim TCP-Protokoll der Fall) aus dem Protokoll-Header, dem Payload und einem sogenannten Pseudoheader. Der Pseudoheader beinhaltet die Source- und Destination-Adresse aus dem Internet Layer, die Protokoll-Nummer aus dem Internet Layer und die Länge von UDP-Header (beziehungsweise TCP-Header) sowie Payload. Typische UDP-Dienste sind das Domain Name System (DNS), (zumindest ältere) Implementierungen des Network Filesystems (NFS), DHCP und das Network Time Protocol (NTP).

2.12 Transport Layer: TCP Das Transmission Control Protocol (TCP, ursprünglich in RFC 761 spezifiziert [18]) ist das wohl meistgenutzte Transport-Layer-Protokoll der TCP/IP-Protokoll-Suite. TCP wurde durch RFC 793 spezifiziert. Es gibt eine große Anzahl von Anwendungen, deren Protokolle auf TCP aufbauen. Die bekanntesten von ihnen sind wohl die folgenden (die Portangaben sind Standardports; sie können variieren): • WWW (Protokolle: HTTP (Port 80), HTTPS (Port 443)) • E-Mail (Protokolle: SMTP (Port 25), POP3 (Port 110), IMAP (Port 143), IMAPS (Port 993)) • sicheres Arbeiten auf einem entfernten Rechner (Protokoll: SSH (Port 22)) • Dateiserver (Protokoll: FTP (Port 21 sowie Port 20 (DATA-Port)) und SFTP (in der Regel gemeinsam mit SSH über Port 22))

2.12.1 TCP-Reliability TCP-Datenpakete (man bezeichnet diese als Segmente) werden, im Gegensatz zu UDPDatagrammen, nicht als einzelne Nachricht (Message), sondern als Datenstrom (Stream) versendet. Dieser Datenstrom muss kontrolliert werden, sodass die Reihenfolge der Daten in diesem Stream nicht verfälscht wird. Hierfür wird die sogenannte Sequenznummer (Sequence Number) verwendet. Jedes Segment kann durch diese Sequence Number in die richtige Position des Streams eingeordnet werden. Die Seite, die das Segment empfängt, bestätigt die empfangenen Daten anschließend mit der sogenannten Bestätigungsnummer (Acknowledgement Number). Diese gibt aber auch die nächste, vom empfangenden Host erwartete Sequence Number an. Stimmen die erwartete und

2.12  Transport Layer: TCP

51

Abb. 2.16   Ein Beispiel für TCP-Reliability

die empfangene Sequence Number nicht überein, kann TCP auf ein verlorengegangenes Segment schließen und sendet das verloren geglaubte Segment erneut aus. Auf diese Weise stellt TCP sicher, dass Datensegmente nicht verlorengehen und in der richtigen Reihenfolge ankommen. In Abb. 2.16 versendet Host A Daten an Host B. Host B empfängt und bestätigt diese. Darauf sendet Host A erneut Daten. Diese jedoch gehen unterwegs auf Grund von Netzwerkproblemen verloren, sodass Host B keine Bestätigung an Host A für die empfangenen Daten versendet. Daraufhin versendet Host A diese Daten erneut, in der Hoffnung, dass diese nun ankommen.18 Werden nun noch Sequenznummern und Bestätigungsnummern in die Betrachtung der Verbindung integriert, so gilt Folgendes: Ein Paket mit einer Sequenznummer X muss mit einer Bestätigungsnummer X+n bestätigt werden, wobei n das neue Datenoffset ist, das sich aus der Anzahl der übertragenen Bytes ergibt. Die Bestätigungsnummer ist dabei die für das folgende Paket erwartete Sequenznummer. Die erste Sequenznummer einer Verbindung wird von jedem der beiden Hosts, die miteinander

18Die Zahlen hinter den Rauten entsprechen der Paketnummer, sie sind nicht mit der Sequence Number oder der Acknowledgement Number zu verwechseln.

52

2  Grundlagen der Netzwerktechnik

kommunizieren, selbst gewählt (randomisiert) und wird als Initial Sequence Number (ISN) bezeichnet. Dabei hat jede Seite der Verbindung eine eigene ISN, weil TCP jede Kommunikationsrichtung separat verwaltet. Es lässt sich zum Thema TCP-Reliability klärend anmerken, dass das Ziel für TCP also nicht darin besteht, einzelne Pakete ans Ziel zu bringen (dies ist die Aufgabe von IP). Stattdessen besteht die Aufgabe darin, den gesamten Payload zuverlässig zu liefern [6]. Dabei kann es vorkommen, dass die Inhalte mehrerer kleiner, aber verlorengegangener, Pakete anschließend durch ein einziges Paket mit dem Gesamtpayload verschickt werden, wenn dies im Sinne der Reliability durchführbar ist [6].

2.12.2 Sende- und Empfangspuffer TCP arbeitet mit sogenannten Sende- und Empfangspuffern. In diesen werden, wie sich wohl bereits erahnen lässt, die empfangenen beziehungsweise versendeten Daten gespeichert. Doch wozu speichert man diese überhaupt zwischen? Die wichtigsten Gründe hierfür sind, dass TCP Daten nur ab einer bestimmten Anzahl von Bytes im Sendepuffer versendet beziehungsweise nur eine gewisse Anzahl von Daten pro Applikation im Empfangspuffer zwischenspeichert, bevor die Applikation die Daten abholen muss. Es gibt einige Ausnahmeanwendungen (wie das Telnet-Protokoll, das ein unsicheres Arbeiten auf entfernten Rechnern ermöglicht), die diese Funktion nicht nutzen. Wird die Pufferung nicht benutzt, dann verursacht dies allerdings weitaus höhere Verbindungskosten. Ein TCP-Header ist im Normalfall 20 Bytes groß. Er baut wiederum auf einem IP-Header (ebenfalls 20 Bytes) auf. Und wenn nun ein einzelnes Zeichen via Telnet in einem eigenen Paket versendet wird, dann werden auch jedes Mal diese 40 Bytes großen Headerdaten pro Paket übertragen. Die Geschwindigkeit von großen Datenübertragungen wäre bei dieser Übertragungsart sehr wahrscheinlich eine Katastrophe. Bei Anwendungen wie Telnet (oder SSH), bei denen sofort auf jedes eingetippte Zeichen reagiert werden muss, führt an einer solchen Umsetzung allerdings kein Weg vorbei.

2.12.3 Flusskontrolle (Flow-Control) Wie Sie weiter unten sehen werden, verwendet TCP im Header ein Feld mit der Bezeichnung Window Size. Dieses teilt dem Empfänger mit, wie viele Daten der Sender im Empfangspuffer noch aufnehmen kann. Der Empfänger sendet daraufhin maximal so viele Daten, wie angegeben wurden, an den Sender zurück. Dieses Feature bezeichnet man auch als Receive Window Sizing. Sliding Receive Windows ermöglicht wiederum das dynamische Anpassen des Receive Windows an aktuelle Umstände. So sind kleine Empfangsfenster bspw. bei einer schlechten Verbindungsqualität besser. Wenn sich die Verbindungsqualität jedoch wieder

2.12  Transport Layer: TCP

53

verbessert, kann auch das Receive Window vergrößert werden. Generell wird beim Receive Window Sizing nicht abgewartet, bis die Bestätigung eines bereits versendeten Segments eintrifft, sondern es wird – in der Hoffnung, dass eine Bestätigung schon noch kommen wird – bereits vorsorglich das nächste Segment abgeschickt. Dies kann die Verbindungsperformance steigern. Weitere bedeutsame Verfahren zur Flusskontrolle, etwa Slow Start, existieren, sind aber für dieses Buch nicht von zentraler Bedeutung.

2.12.4 Header Viele der oben angesprochenen Informationen werden Sie – zumindest indirekt – im Header wiederfinden (Abb. 2.17). Wie bei UDP werden die ersten 32 Bits des Headers für die jeweils 16 Bit langen Felder Source Port und Destination Port verwendet. Es folgt eine 32 Bits lange Sequenznummer (Sequence Number), die die Position des Payloads im Datenstream angibt. Die Startnummer wird dabei als Initial Sequence Number (ISN) bezeichnet und bei gesetztem SYN-Flag im Three-Way-Handshake übergeben (dazu gleich mehr). Als ISN wird je nach Implementierung ein Zufallswert oder 1 verwendet; anschließend wird aufwärts gezählt. Hinter der Sequence Number folgt eine ebenfalls 32 Bits lange Bestätigungsnummer (Acknowledgement Number), die bereits die empfangenen Daten angibt. Dadurch, dass beide Systeme, zwischen denen eine TCP-Verbindung besteht, diese beiden Nummern verwalten, kann festgestellt werden, ob auch alle Datenpakete tatsächlich angekommen sind und welche verlorengingen und demzufolge neu gesendet werden müssen.

Abb. 2.17   Der TCP-Header

54

2  Grundlagen der Netzwerktechnik

Das nächste Feld (Offset, 4 Bits) gibt die Headerlänge in Wörtern (je 32 Bits) an. In der Regel beträgt dieser Wert 5 und wird bei der Verwendung der optionalen Felder (etwa TCP-Timestamps) erhöht. Bei den nächsten vier Bits handelt es sich um einen reservierten Bereich, der mit Nullen überschrieben wird. Für die Flags stehen 8 Bits zur Verfügung. Jedes gesetzte Bit hat eine spezielle Funktionalität, wobei zu beachten ist, dass es sich bei TCP um ein Protokoll handelt, dass beide Kommunikationsrichtungen (A → B und B → A) separat verwaltet, was im Zusammenhang mit dem Management der Verbindung, wie Sie im nächsten Abschnitt sehen werden, wichtig ist: • 0 × 01 (FIN): Der Sendevorgang des Kommunikators (Sender) zum Rezipienten (Empfänger) wird beendet. • 0 × 02 (SYN): Die Verbindung vom Kommunikator zum Rezipienten wird aufgebaut. • 0 × 04 (RST): Verbindungsreset. • 0 × 08 (PSH): Die Payload wird direkt an den Applikation Layer weitergereicht und nicht im Sendepuffer beziehungsweise Empfangspuffer zwischengespeichert (PUSH), siehe Abschn. 2.12.2. • 0 × 10 (ACK): Sofern dieses Bit gesetzt ist, ist die Acknowledgement Number gültig. • 0 × 20 (URG): Der Dringlichkeitszeiger (Urgent Pointer) ist gültig. • 0 × 40 (ECE) und 0 × 80 (CWR): Die Flags Explicit Congestion Notification und Congestion Window Reduced sind eine Erweiterung des TCP-Protokolls zum Umgang mit Netzwerküberlastungen. Die ECN-Bits des IP-Headers (siehe Abschn. 2.6) stehen hiermit in Verbindung. Das Empfangsfenster (Window) enthält die Anzahl an Bytes, die der Absender noch in seinem Receive Window aufnehmen kann. Kann der Empfänger beispielsweise noch 1410 Bytes in seinen TCP-Buffer aufnehmen, beträgt der Wert des Empfangsfensters 1410. Die TCP-Checksum wird auf dieselbe Art und Weise wie beim UDP-Protokoll (nämlich mit einem zusätzlichen Pseudo-Header) berechnet. Der Urgent Pointer zeigt auf vorrangig zu behandelnde Daten in der Payload. Er ist jedoch nur gültig, wenn das URG-Flag gesetzt ist.

2.12.5 Kommunikationsphasen TCP-basierte Kommunikation besteht im Wesentlichen aus drei Phasen, dem Verbindungsaufbau, der Verwendung einer aufgebauten Verbindung und dem Abbau der eingerichteten Verbindung. Verbindungsaufbau: Ein Host, der von sich aus eine Verbindung einleitet, führt ein Active Open aus, und der Host, der die Verbindung akzeptiert, führt ein Passive Open aus. Das heißt, bei einem Passive Open bietet ein Host auf einem bestimmten Port seinen

2.12  Transport Layer: TCP

55

Abb. 2.18   SYN- und ACK-Flags beim Three-WayHandshake

TCP-basierten Dienst an. Ein Host, der diesen Dienst nutzen möchte, verbindet sich mit dem jeweiligen Host aktiv mit dem jeweiligen Port. Eine Verbindung wird durch einen sogenannten Three-Way-Handshake eingeleitet. Dieser Three-Way-Handshake wird deshalb so betitelt, weil er drei TCP-Segmente benötigt, um eine Verbindung beidseitig zu initialisieren. Beim ersten Paket jeder Seite wird dabei das SYN-Flag gesetzt. Dies wird von der Gegenseite jeweils mit einem gesetzten ACK-Flag bestätigt. Da die Seite, die ein Passive Open ausführt (in Abb. 2.18 der Empfänger), die Bestätigung des SYN-Segments gleich mit in das eigene Segment zum Verbindungsaufbau einbringen kann, werden von dieser Seite keine zwei, sondern lediglich ein einziges Segment versendet. Beim Initialisieren einer Verbindung wird das Verfahren einfacher ersichtlich. Der Host yorick.sun verbindet sich im folgenden Listing mit dem Host eygo.sun auf Port 22. Die Ausgabe stammt von den Paketen, die der Host eygo.sun auf seiner Netzwerkschnittstelle sendet und empfängt:

56

2  Grundlagen der Netzwerktechnik

tcpdump zeigt uns an, welche Flags gesetzt sind. In den ersten beiden Paketen ist das SYN-Flag (S) gesetzt. ACK-Flags werden nicht dargestellt und sind durch ack ‹Nummer› gekennzeichnet. Ist kein von tcpdump explizit gekennzeichnetes Flag gesetzt, wird ein Punkt ausgegeben – so wie im dritten Paket. Aufmerksamen Lesern wird bereits aufgefallen sein, dass es sich bei den Nummern hinter dem SYN-Flag um die Sequence Number handelt. Die ersten zwei Pakete beinhalten die ISN. Das zweite Paket gibt die eigene ISN von eygo.sun an und bestätigt die ISN von yorick zudem noch mit der Acknowledgement Number (ISN von yorick + 1). Datenkommunikation: Ist die TCP-Verbindung beidseitig eingerichtet, können beide Seiten mit dem Datentransfer beginnen. Dabei bestätigen sich beide Seiten gegenseitig die empfangenen Daten mit den Acknowledgement Numbers. Im Falle des folgenden Listings wurde telnet.exe auf yorick.sun zum Verbindungsaufbau verwendet. Dabei wird jedes von Hand eingegebene Zeichen an den Server als Extra-Segment versendet und mit einem PSH-Flag (P) versehen. Längere Meldungen, die auf einmal übertragen werden, etwa Fehlermeldungen, können allerdings in einem Paket (statt in vielen separaten) gesendet werden. PSH erlaubt die sofortige Übertragung von Tastatureingaben und die sofortige Anzeige einer etwaigen Aktion (etwa das Erscheinen eines eingegebenen Buchstabens auf dem Bildschirm durch das Paket des Servers).

Das erste Segment beinhaltet eine 22 Zeichen lange SSH-Versionsangabe und ein Newline-Zeichen, insgesamt also 23 Zeichen. Die Bestätigung erfolgt mit einem ACK von yorick.sun und der Acknowledgement Number 24, weil die ersten 23 Bytes empfangen wurden und als nächstes das Byte mit der Nummer 24 erwartet wird. Nach der Eingabe von Return (auf yorick, Nachrichtenlänge: 2 Bytes) wird die Eingabe seitens eygo mit einem Protocol mismatch „bestätigt“ – eine Fehlermeldung die daher kommt, dass die Return-Eingabe nicht vorgesehen war, und, wie Sie gleich sehen werden, die Verbindung geschlossen. Entsprechend der vorherigen Return-Eingabe wird für diese Kommunikationsrichtung die Acknowledgement Number 3 gesetzt.

2.12  Transport Layer: TCP

57

Abb. 2.19   FIN- und ACK-Flags beim TCPVerbindungsabbau

Verbindungsabbau: Beim Verbindungsabbau sendet die Seite, die das Senden von Daten einstellen will, ein Segment mit gesetztem FIN-Flag an die Gegenseite. Die Gegenseite bestätigt dieses Segment mit einem ACK. Da TCP Full-Duplex ist, kann die Seite, die das FIN bestätigte, noch immer Daten senden. Man spricht beim Schließen einer Verbindung analog zum obigen Three-Way-Handshake von einem Active Close beziehungsweise einem Passive Close. In Abb. 2.19 führt der Sender einen Active Close und der Empfänger einen Passive Close durch. Es zeigt sich analog zu Abb. 2.19 folgender Datenaustausch, wobei die vorherige Verbindung weitergeführt wurde, weshalb auch die Sequence Numbers und Acknowledgement Numbers weiterhin bestehen:

58

2  Grundlagen der Netzwerktechnik

Alternativ kann eine Verbindung selbstverständlich auch durch gesetzte RST-Flags terminiert werden; in solch einem Fall erfolgt ein abrupter Verbindungsabbruch.

2.13 Application Layer: DHCP Das Dynamic Host Configuration Protocol (DHCP) dient der Konfiguration von Hosts in Netzwerken. Es wird in UDP eingekapselt, weshalb es als Protokoll des Application Layers besprochen werden muss. Die Hauptfunktion von DHCP ist die Vergabe von IPAdressen. Neben der IP-Adresse gibt es allerdings weitere Konfigurationsmöglichkeiten (etwa den zu verwendenden Standardrouter und DNS-Server). DHCP funktioniert gemäß einem einfachen Verfahren. Ein DHCP-Client erhält seine Konfiguration dabei von einem DHCP-Server. Zunächst sendet ein DHCP-Client ohne IP-Adresse eine sogenannte DHCP-DISCOVER-Nachricht per Broadcast in das lokale Netzwerk. Ein (oder mehrere) DHCP-Server antworten daraufhin mit einer DHCPOFFER-Nachricht (sie enthält eine IP-Adresse). Der DHCP-Client wählt einen der empfangenen DHCP-OFFER-Nachrichten aus und versendet daraufhin eine DHCPREQUEST-Nachricht an den ausgewählten DHCP-Server. Der DHCP-Server bestätigt mit einem DHCP-ACK und einer sogenannten Lease Time den DHCP-REQUEST des Clients. Alternativ kann der DHCP-Server auch mit einem DHCP-NAK eine Ablehnung der Anfrage signalisieren, etwa weil eine angebotene IP-Adresse in der Zwischenzeit bereits an einen anderen DHCP-Client vergeben wurde. Die Lease Time gibt an, wie lang ein DHCP-Konfiguration gültig ist. Anschließend verwendet der Client die zugewiesene IP-Adresse (und restliche Konfigurationsparameter) bis zum Ablauf der Lease Time beziehungsweise bis er diese nicht mehr benötigt (in letzterem Fall informiert der DHCP-Client den DHCP-Server mit einer sogenannten DHCP-RELEASE-Nachricht). Nach Ablauf der Lease Time muss sich der Client erneut an den Server wenden, um eine Konfiguration zugewiesen zu bekommen.

2.14 Application Layer: HTTP Zur Übertragung von Webseiten über das Internet und andere Netzwerke wird das zustandslose Protokoll HTTP (Hyper-text Transfer Protocol) verwendet. Bei HTTP handelt es sich um ein Klartext-Protokoll, das verschiedene Anfragen (sogenannte Methods) unterstützt, die vom Client an den Server gestellt werden können: • GET: Anfrage einer Ressource (optionale Parameter können mit meist stark begrenzter Länge über die Adresse übertragen werden). Eine Ressource kann beispielsweise eine HTML-Datei oder eine Bilddatei sein.

2.14  Application Layer: HTTP

59

• POST: Anfrage mit (textuellem oder binärem) Inhalt seitens des Clients an eine Ressource des Servers (etwa Übertragen von Eingabedaten oder Dateien). • HEAD: Mit HEAD kann, wie bei GET, eine Ressource angefragt werden. Anstelle der gesamten Response erhält der Client hierbei nur die Metainformationen, also den HTTP Response-Header als Antwort (und keinen Payload, also etwa HTML- oder Bilddaten). • OPTIONS: Anfragen, welche Anfragetypen vom Server unterstützt werden. • CONNECT: Verbinden mit einer weiteren Instanz; der HTTP-Server spielt dabei den Vermittler, der die Daten weiterleitet (HTTP-Proxy). • PUT: Upload von neuen Ressourcen durch den Client. • DELETE: Löschen einer Ressource auf dem Server. • TRACE: Zurücksenden einer Anfrage zu Debugging-Zwecken, um diese auf Veränderungen hin zu überprüfen. Die derzeit noch gängigste HTTP-Version ist 1.1 und wird von allen wichtigen Browsern implementiert. Die Schreibweise für die HTTP-Version ist „HTTP/Version“, also etwa „HTTP/1.1“.  Alte HTTP-Versionen  HTTP/1.1 erfordert gegenüber der Vorgängerversion HTTP/1.0 die Angabe eines „Host:“-Headers, womit virtuelle Hosts (das sind mehrere Hosts auf einem Server mit derselben IP-Adresse) ermöglicht werden, was insbesondere für Cloud Computing relevant ist. Weitere Änderungen zwischen Version 1.0 und 1.1 existieren, sind aber für die dieses Buch nicht von Relevanz. Die Vorgängerversion von HTTP/1.0 war übrigens HTTP/0.9 von 1991.

2.14.1 Aufbau des HTTP-Headers Beim Aufbau des HTTP-Headers wird zwischen Request und Response unterschieden. Der Client sendet dabei immer in einer ersten Zeile folgenden Aufbau an den HTTP-Server: [METHODE] [URL] [HTTP-VERSION] Eine minimale HTTP/1.0-Anfrage sieht beispielsweise wie folgt aus: GET /index.html HTTP/1.0 Für HTTP/1.1 müsste die Anfrage wie folgt aussehen: GET /index.html HTTP/1.1 Host: www.example.com

HTTP-Requests werden mit zwei Zeichensequenzen, die jeweils Carriage Return und Linefeed enthalten (also ‘∖r∖n∖r∖n’), abgeschlossen.

60

2  Grundlagen der Netzwerktechnik

Eine HTTP-URL setzt sich, gemäß RFC 2068, aus den folgenden Bestandteilen zusammen: http://Host[:Port]/Pfad, also beispielsweise: http://www.wendzel.de:80/index.html Die Angabe des Ports (also etwa :80) kann bei Verwendung des Ports 80 (dieser ist der Standardport für HTTP) ausbleiben, sodass die Anfrage einer URL wie http:// www.wendzel.de/index.html völlig korrekt ist. Der HTTP-Server antwortet auf Anfragen (Requests) mit einer Response der Form: [HTTP-Version] [Statuscode] [Status-Bezeichnung], also etwa HTTP/1.1 200 OK für die erfolgreiche Ausführung (Code 200, Bezeichnung „OK“) eines HTTP/1.1-Requests. Status-Codes im Bereich von 100–199 sind Statusmeldungen (etwa „102 Processing“), im Bereich von 200–299 Erfolgsmeldungen (etwa „200 OK“), im Bereich von 300–399 Umleitungen (etwa „301 Moved Permanently“), im Bereich von 400–499 clientseitige Fehlermeldungen (etwa „404 Not Found“ für eine vom Client angefragte Ressource, die nicht auf dem Server existiert) und im Bereich von 500–599 serverseitige Fehlermeldungen (etwa „500 Internal Server Error“). Bei einer Response werden zudem einige weitere Parameter an den Client geliefert. Dazu zählen etwa Informationen über die Webserver-Software (Produkt, gegebenenfalls dessen Version und geladene Module), ein Timestamp, Informationen zur Länge des Payloads (Content), zum Verbindungsverhalten (dazu gleich mehr) und zur Art des Contents (Content-Type) sowie seiner Länge (Content-Length) und Codierung (etwa „text/html, charset=UTF-8“ für UTF-8 kodierten HTML-Text). Wie gerade erwähnt, wird der Client vom Server über das Verbindungsverhalten einer HTTP-Verbindung informiert. Dabei liefert der Server entweder den Wert „close“ oder „keep-alive“ zurück. Keep-Alive-Verbindungen werden vom Server nicht sofort nach der Response terminiert, um weitere HTTP-Anfragen ohne erneutes Verbinden zu erlauben (etwa für die in einer HTML-Datei verlinkten/eingebetteten Ressourcen, wie Bilder). Close-Verbindungen werden hingegen direkt terminiert. Keep-Alive-Verbindungen sind performanter, weil sie die Auf- und Abbauvorgänge der TCP-Verbindungen überflüssig machen. Einige Beispielanfragen sollen den Aufbau von HTTP-Requests und HTTPResponses verdeutlichen. Zunächst sollen HTTP/1.0-Methoden abgefragt werden, die der Webserver der Hochschule Augsburg unterstützt. Der Server antwortet mit den entsprechenden Methoden (Zeile „Allow“), Informationen zu seiner Software und weiteren Daten. Die Content-Length ist 0, da keine weiteren Inhalte (etwa Bilder oder eine Webseite) übertragen wurden.

2.14  Application Layer: HTTP

61

Als nächstes soll dieselbe Anfrage über HTTP/1.1 gestellt werden, wozu der Parameter „Host“ angegeben werden muss.

Nun soll mit einer GET-Methode die Startseite von www.wendzel.de abfragt werden. Man erhält als Antwort (hier gekürzt dargestellt) den HTML-Code der Seite mit einer Gesamtlänge von 10217 Bytes.

62

2  Grundlagen der Netzwerktechnik

Bei POST-Anfragen werden zusätzlich Werte an den Server übertragen (in separaten Zeilen). Die HTTP-Methoden PUT, DELETE und CONNECT sind in der Regel nicht verfügbar, da sie sicherheitskritisch beziehungsweise nicht für die Erbringung eines typischen Webdienstes notwendig sind.

2.14.2 HTTP/2 und HTTP/3 Die sich aktuell langsam durchsetzende HTTP-Version 2.0 soll an dieser Stelle ebenfalls kurz Erwähnung finden. HTTP/1.1 ist bereits seit vielen Jahren im Einsatz und genügt nicht mehr in jeglicher Hinsicht aktuellen Anforderungen an das Web. Unter anderem können HTTP/1.1-Header relativ schnell groß werden, weil diese unkomprimiert in Klartext übertragen werden. Außerdem kennt HTTP/1.1 keine Priorisierung von Anfragen an Ressourcen und kann nicht gut mit parallelen Verbindungen umgehen. Die HTTP/2-Syntax ist abwärtskomatibel zu HTTP/1.1. Im Wesentlichen bietet HTTP/2 effizientere Netzwerkübertragungen, eine verringerte Wahrnehmung der Latenz durch Kompression der Header-Felder, und erlaubt es, mehrere Datenaustausche gleichzeitig über dieselbe Verbindung durchzuführen.

2.15  Application Layer: DNS

63

Zur Verwendung von HTTP/2 wird ein HTTP/1.1-Request durchgeführt, der ein Upgrade auf Version 2 beinhaltet. Das zentrale Element ist hierbei der Befehl upgrade, der etwa h2c (Klartextverbindung für HTTP/2) verlangen kann. h2 entspreche hingegen einer TLS-verschlüsselten HTTP/2-Verbindung. Darauf folgen Details zur HTTP/2-Verbindung, die mit dem Base64-Verfahren19 kodiert werden (HTTP2-Settings).

In Kürze wird das Protokoll HTTP/3 zum Einsatz kommen. Es wird insbesondere das neue Transportlayer-Protokoll QUIC verwenden. Zum Zeitpunkt des Verfassens dieses Kapitels (Januar 2021) handelt es sich bei HTTP/3 noch um einen Standardentwurf der IETF (sog. Internet-Draft).

2.15 Application Layer: DNS Hauptaufgabe des Domain Name Systems (DNS) ist die Übersetzung von Hostnames in IP-Adressen (und vice versa). DNS ist ein hierarchisches System, dessen Ausgangspunkt als ‘.’ (ein Punkt) bezeichnet wird. Die hierarchische Organisation erfolgt in sogenannten Domains, die durch Punkte getrennt werden, etwa www.openbsd.org (Host www unter der Domain openbsd unter der Domain org), siehe Abb. 2.20. Hinter der Domain de kann ebenfalls ein Punkt stehen, der aber optional ist. Entsprechend ist die Domain www.hs-worms.de. korrekt angegeben. Außerdem gibt es Umlautdomains (etwa müller.de). Domainnamen müssen mit einem Buchstaben beginnen, können maximal 63 Zeichen beinhalten und dürfen Buchstaben, den Bindestrich (‘-’) und Zahlen beinhalten. Es können bis zu 127 Domainlevel erstellt werden. DNS-Namen dürfen nur einmalig vergeben werden. Die obersten Domains der Hierarchieebene werden dabei als Top Level Domains (TLDs) bezeichnet, wobei verschiedene Arten solcher Top Level Domains existieren [27]: • Länder: .de (Deutschland), .at (Österreich), .us (Vereinigte Staaten), .nz (Neuseeland), .au (Australien) usw. • Organisationsformen: .com (kommerzielle Domains), .org (Organisationen), .gov (Regierungsorganisationen), .mil (militärische Organisationen), .edu (Bildungseinrichtungen) usw. 19Beim Base64-Verfahren werden Eingabedaten in Byteschritten in druckbaren ASCII-Zeichen kodiert.

64

2  Grundlagen der Netzwerktechnik

Abb. 2.20   Hierarchie der DNS-Domains

• Seit 2000: .biz (Business), .info (Informationen), .name (Namen von Personen), .pro (freie Berufe), .aero (Luftfahrtindustrie), .museum etc. • Mit Beschluss der ICANN vom Juni 2011: Unternehmenseigene Top-Level-Domains (diese können von der ICANN nach Prüfung abgelehnt werden und sind äußerst kostspielig) [15]. Die Organisation von DNS ist dezentral: Server sind für einen Bereich (eine sogenannte Zone) zuständig und gelten damit als Authoritative Server). DNS-Server können aber auch die Informationen anderer Server zwischenspeichern (DNS-Caching). Obwohl DNS dezentral organisiert ist, gibt es in der Hierarchie eine oberste Instanz: Die sogenannten Rootserver. Es gibt mehrere Rootserver-Adressen, die durch Anycasting über zahlreiche physikalische Systeme repräsentiert werden können. Dabei teilen sich mehrere Rootserver die gleiche IP-Adresse und ein DNS-Client landet bei einem regionalen Server, der diese IP verwendet. Dadurch wird die Last auf die Rootserver verteilt und DNS etwas weniger anfällig gegenüber Angriffen. Jeder Client darf diese Rootserver direkt anfragen. Aus Gründen der Stabilität laufen die Rootserver mit unterschiedlichen Betriebssystemen (meistens unixartig, etwa BSD oder Linux) und unterschiedlicher Serversoftware (oftmals mit der Software Bind). Die meisten RootNameserver stehen in den USA. Rootserver verteilen die Adressen der DNS-Server für die Top-Level-Domains.

2.15  Application Layer: DNS

65

2.15.1 Resource Records DNS kennt sogenannte Resource Records. Diese sind in vier Klassen organisiert, wobei nur die Klasse IN (Internet) für dieses Buch relevant ist. Es können dabei bis zu 65.536 verschiedene Resource Records (RRs) in DNS definiert werden. Die wichtigsten sind: • A: IPv4-Adresse für einen gegebenen Hostname • AAAA: IPv6-Adresse für einen gegebenen Hostname • CNAME: kanonischer Hostname (Alias) • DNSKEY: öffentlicher Schlüssel einer Zone für DNSSec20 • MX: Mail Exchange für die Angabe der Mail-Server einer Domain samt ihrer Priorität • NAPTR: Erweiterung der A-Records um zusätzliche Funktionalität, etwa Angabe des verwendeten Protokolls eines Servers • NS: Nameserver einer Domain • PTR: Umwandlung einer IP-Adresse in einen Hostname (Gegenstück zu A und AAAA) • RRSIG: Dieser Resource Record ermöglicht die Signatur anderer Resource Records und ist ebenfalls Bestandteil von DNSSec. • SOA: Start of Authority, enthält Informationen zur zuständigen Zone eines DNSServers (Kontaktinformation zum Administrator, Standard-Lebenszeitspanne der Resource Records, Refresh-Time und weitere Werte). • TXT: Freitext

2.15.2 Resolving Jeder Rechner beinhaltet einen lokalen Resolver. Unter unixartigen Systemen wird ein Resolver über die Datei /etc/resolv.conf konfiguriert, in der die IP-Adressen von Nameservern angegeben werden, die ein Client ansprechen soll, um einen Resource Record abzufragen. Dabei wird bei den Nameservern eine Unterscheidung hinsichtlich ihres Auflösungsverfahrens (Resolving) getätigt: • Iteratives Resolving: Der Namserver A fragt den ihm bekannten Nameserver B der nächsthöheren Instanz nach den gewünschten DNS-Informationen. Sollte der Nameserver B diese Informationen nicht kennen, leitet A die Anfrage an den hierarchisch nächsthöheren Nameserver C weiter usw., bis er am Ende einen Rootserver anfragt.

20Bei DNSSec

handelt es sich um eine Erweiterung des DNS, die die Nachrichten-Authentizität und -Integrität sicherstellen kann. DNSSec kümmert sich also, anders formuliert, darum, dass Nachrichten nicht manipuliert werden und darum, dass Nachrichten tatsächlich vom gewünschten Absender stammen. Mehr zu DNSSec erfahren Sie in Abschn. 8.5.4.

66

2  Grundlagen der Netzwerktechnik

• Rekursives Resolving: Nameserver A fragt Nameserver B nach den gewünschten DNS-Informationen. Hat Nameserver B diese Informationen nicht, fragt B selbst den nächsthöheren Server an. Das weitere Vorgehen für den Fall, das eine Antwort nicht erhalten wurde, läuft rekursiv. Rekursives Resolving hat den Vorteil, dass jedes Element in der Kette der Nameserver die finale Antwort zwischenspeichern kann, was erneutes Abfragen der gleichen DNS-Information beschleunigt.

2.15.3 Der DNS-Header Der DNS-Header gliedert sich in folgende Bereiche, die in Abb. 2.21 dargestellt sind: die Header Section (das ist der eigentliche Protokollheader), die Questions Section (gestellte Fragen nach Resource Records), Answer Section (Antworten für gestellte Fragen), Authority Section (Hinweise zu alternativen, zuständigen DNS-Servern für eine gestellte Anfrage) und Additional Section (zusätzliche Hinweise in Form weiterer Resource Records). Ein in UDP eingekapselter DNS-Request kann maximal 512 Bytes groß sein. Für TCP können Streams versendet werden, die nicht unter diese Beschränkung fallen. Während alle Sections, bis auf die Header Section, nur Resource Records beinhalten, ist die Header Section nach einem bestimmten Schema aufgebaut. Sie enthält neben einer ID zur Zuordnung von Anfragen und Antworten folgende Bestandteile (ebenfalls in Abb. 2.21 dargestellt): • QR-Bit. Das QR-Bit gibt an, um welche Art DNS-Nachricht es sich handelt; ein 0erBit steht für eine Anfrage (Query) und ein 1er-Bit für eine Antwort (Response).

Abb. 2.21   Der DNS-Header

2.15  Application Layer: DNS

67

• Opcode. Der Opcode gibt die Art der DNS-Anfrage an. Es handelt sich dabei entweder um eine Standardabfrage (Standard Query), eine inverse Abfrage (Inverse Query), die für die Umkehrung (also Negierung) des eigentlichen Requests verwendet wird, um eine Abfrage des Server-Zustands (Server Status Request, eine Benachrichtigung (Notification) oder um eine Aktualisierung (Update). • DNS-Flags. Weiterhin enthält der DNS-Header eine Reihe möglicher Flags: – AA: Dieses Flag (Authoritative Answer) ist gesetzt, wenn der angefragte DNSServer für die Resource Records der abgefragten Zone zuständig ist. Ein Server, der eine Anfrage für eine fremde Zone beantwortet (für diese Zone also etwa nur als Caching-Server fungiert), darf dieses Flag nicht setzen. – TC (Truncated): Nur die ersten 512 Bytes der Response sind enthalten und die restlichen Daten sind abgeschnitten. Dieses Bit dient als Hinweis für den DNS-Client, dass weitere Daten über eine TCP-basierte Anfrage bereitgestellt werden können. – RD (Recursion Desired): Zuvor haben Sie den Unterschied zwischen iterativem und rekursivem Resolving kennengelernt. Setzt ein Client in einer Anfrage das RD-Bit, so fordert er ein rekursives Resolving an. – RA (Recursion Available): Da rekursives Resolving nicht immer verfügbar sein muss, kann ein Server mit dem RA-Flag signalisieren, dass er rekursives Resolving unterstützt. – Z-Bit: unbenutzt und für zukünftige Verwendung reserviert. – Die beiden Flags AD (Authenticated Data) und CD (Checking Disabled) stehen im Kontext von DNSSec. Mit gesetztem AD-Flag signalisiert ein DNS-Server, dass eine Überprüfung des Resource Records stattfand – die enthaltenen Informationen sind authentisiert. Das CD-Flag wird hingegen vom Client verwendet, um dem Server zu signalisieren, dass nicht überprüfte Antworten akzeptiert werden (der Client muss jedoch noch eigenständig Überprüfungen der Resource Records durchführen, weshalb er mit gesetztem CD-Flag dem Server die Arbeit ersparen kann) [1]. • Rcode. Dieser Wert gibt den Response-Code an. Die IANA definiert eine Liste möglicher Werte für den Rcode [12]. Die wichtigsten Werte sind: – 0 (No Error, es lag kein Fehler vor) – 1 (Format Error, die Nachricht ist nicht interpretierbar) – 2 (Server Failure, ein serverseitiges Problem liegt vor) – 3 (Non-existent Domain, die angefragte Domain existiert nicht) – 4 (Not Implemented, eine angefragte Funktionalität ist nicht verfügbar21) – 5 (Refused, die Anfrage wurde abgelehnt) • Total Questions, 16 Bit: Anzahl der enthaltenen Anfragen an den Server • Total Answers, 16 Bit: Anzahl der enthaltenen Antworten vom Server an den Client

21Es ist beispielsweise möglich, dass kein rekursives Resolving verfügbar ist, der Client aber in einer Anfrage das RD-Flag setzte.

68

2  Grundlagen der Netzwerktechnik

• Total Authority Resource Records, 16 Bit: Anzahl der enthaltenen Hinweise auf authorisierte Server in einer Antwort • Total Additional Resource Records, 16 Bit: Anzahl der enthaltenen zusätzlichen Resource Records in einer Antwort

2.15.4 DNS-Tools Den Umgang mit DNS erleichtern einige Tools, insbesondere dig und nslookup. Mit beiden können Sie gezielte Abfragen von Resource Records an DNS-Server stellen. Bei nslookup geben Sie den Typ der Abfrage mit set type= an, wobei die oben eingeführten Typen (etwa A, AAAA oder PTR) verwendet werden können.

2.15  Application Layer: DNS

69

Oben wurde zunächst der Nameserver av2.rz.fh-augsburg.de festgelegt. Anschließend wurde die IP-Adresse (A) des Hosts www dieser Domain abgefragt und selbiges mit der IPv6-Adresse (AAAA) getan. Im Anschluss wurde der Hostname für die IP-Adresse 141.82.16.242 (hierbei ist die umgekehrte Schreibweise zu beachten) und für den kanonischen Namen für den Hostname www.rz.fh-augsburg.de (dieser ist wwwrz.rz.fh-augsburg.de) sowie den Mailexchanger (MX), der zwei Mail-Server für die Domain liefert, abgefragt. dig fragt ebenfalls derlei Informationen an. Dabei erfolgt der Aufruf in der Form dig @server name type, wobei server für den Nameserver, name für den angefragten Wert (etwa einen Hostname) und type für die Art des Resource Records stehen. Die folgende Beispielausgabe wurde gekürzt, um die Lesbarkeit zu steigern.

70

2  Grundlagen der Netzwerktechnik

Wie ersichtlich ist, wurde der A-Record der Domain hs-worms.de abgefragt. In der Antwort wurde die entsprechende IP-Adresse zurückgegeben. Weiterhin enthielt die Antwort Verweise auf drei Nameserver (NS) sowie auf zusätzliche IPv4- (A) und IPv6Adressen (AAAA) dieser Server. IN bedeutet Internet-Klasse (heute der Standard) und der Wert 3600 beziehungsweise 22965 entspricht der Vorhaltezeit (TTL) für den entsprechenden Eintrag.

2.16 Application Layer: E-Mail- und Usenetprotokolle Das Mailsystem hat die Aufgabe, E-Mails zum Empfänger zu übertragen, eine Abholmöglichkeit für den E-Mail-Empfänger zu bieten (Postfach) und E-Mails zu speichern.

2.16  Application Layer: E-Mail- und Usenetprotokolle

71

Es kommen dabei verschiedene Protokolle zum Einsatz, insbesondere das Simple Mail Transfer Protocol (SMTP), das Post Office Protocol (POP) und das Internet Message Access Protocol (IMAP). In allen drei Fällen handelt es sich um Protokolle, die – ähnlich wie bei HTTP – Klartextnachrichten verwenden. Die Befehle für diese Protokolle sind nicht case-sensitive (Groß- und Kleinschreibung spielt also keine Rolle), außerdem nutzen alle drei Protokolle TCP. Das E-Mail-System besteht dabei aus drei zentralen Komponenten: 1. Mail User Agent (MUA), das ist der Mail-Client eines Benutzers, etwa Microsoft Outlook oder Mozilla Thunderbird. 2. Mail Transfer Agent (MTA), das ist der Mail-Server, der E-Mails für die Weiterleitung entgegennimmt (etwa Sendmail). 3. Mail Delivery Agent (MDA), das ist die Software, die E-Mails ausliefert und diese etwa filtert und sortiert (ein Beispiel hierfür ist Procmail). Der MUA steht dabei üblicherweise am Anfang und am Ende eines Mailtransfers zur Zieldomain. Beispielsweise könnte ein Benutzer von example.com eine E-Mail an einen Benutzer von hs-worms.de versenden. In diesem Fall würde sich der MUA mit dem MTA von example.com verbinden; hierbei kommt das SMTP-Protokoll zum Einsatz. Der MTA von example.com verbindet sich mit dem MTA von hs-worms.de, der die E-Mail annimmt. Der MDA wird die entsprechende E-Mail anschließend in das Postfach des jeweiligen Empfängers von hs-worms.de einsortieren. Sobald der dortige Benutzer mit seinem MTA eine Verbindung (mit POP oder IMAP) zum lokalen Server herstellt, kann er die in seinem Postfach eingetroffenen E-Mails sichten.

2.16.1 POP3 Das Post Office Protocol (POP) liegt derzeit in der Version 3 (POP3) vor. Es verwendet standardmäßig den Port 110 und dient dem Abholen von E-Mails von einem Mailpostfach. Die Befehle sind simpel. Eine Anmeldung erfolgt mittels USER und PASS (siehe nachstehendes Listing). Die Liste aktuell vorhandener Nachrichten wird mit LIST abgefragt und Nachrichten werden mit RETR und DELE ) abgefragt beziehungsweise vom Server gelöscht. QUIT beendet eine POP3-Verbindung. Das folgende Beispiel illustriert das Anmelden an einem Mail-Server und ein Szenario, in dem keine neuen E-Mails vorliegen.

72

2  Grundlagen der Netzwerktechnik

2.16.2 IMAP Das Internet Message Access Protocol (IMAP) arbeitet ähnlich wie POP3, verfügt allerdings über einige bedeutsame Funktionen, die POP3 nicht aufweist. Die aktuelle Version von IMAP ist 4 (Revision 1) und in RFC 3501 beschrieben [3]. Außerdem wurden einige Erweiterungen des Standards publiziert. Unter anderem unterstützt IMAP das serverseitige Durchsuchen einer Mailbox. Außerdem kann das Protokoll erweitert werden. Weiterhin unterstützt IMAP eine hierarchische Mailbox-Struktur (in Form von Ordnern). Im einfachsten Fall gibt es normalerweise einen Ordner für gesendete (Sent), für empfangene (Inbox), für gelöschte (Trash) und für in Arbeit befindliche E-Mails (Drafts). Weiterhin können E-Mails als „bereits gelesen“ und „bereits beantwortet“ markiert werden. IMAP wird über TCP übertragen und nutzt Port 143. Die folgende Beispielsitzung illustriert den Umgang mit IMAP. In IMAP stellt der Client jedem Befehl ein Tag voran (im folgenden Listing a001 bis a006), wobei es sich um einen Identifizierungscode für den jeweiligen Befehl handelt. Die Antwort des Servers bezieht sich jeweils auf dieses Tag. Nach dem Verbindungsaufbau des Clients teilt der Server dem Client mit, dass er IMAPv4 in der Revision 1 nutzt und verschiedene Module für die Authentifizierung und Verschlüsselung unterstützt. Der erste Befehl des Clients (a001 login  ) meldet den Benutzer am Server an. Der Server akzeptiert die Anmeldung (gekürzte Darstellung).

2.16  Application Layer: E-Mail- und Usenetprotokolle

73

Als nächstes wählt der Client eine Mailbox (einen Ordner) aus, und zwar den Nachrichteneingang (Inbox). Der Server teilt dem Client unter anderem mit, dass 111 Nachrichten in der Mailbox vorliegen und die Nachricht 105 die erste der noch nicht angesehenen Nachrichten ist.

Befehl a003 holt die Kopfzeilen (Header) der Nachricht mit der Nummer 111 ab. Dort ist zu sehen, dass die Nachricht von „Max Sender“ ([email protected]) an [email protected] gesendet wurde (Darstellung gekürzt). Außerdem sehen wir, dass der Nachrichtenbetreff „Hallo, Welt!“ ist und, dass das E-Mail-Programm Mozilla Thunderbird verwendet wurde. Es handelt sich um eine Text-Nachricht (text/

74

2  Grundlagen der Netzwerktechnik

plain), also keine HTML-E-Mail. Die Nachricht verwendet eine englischsprachige Kodierung und wurde am 5. März 2018 um 16:39 versendet.

Um nun den eigentlichen Nachrichteninhalt zu lesen, wird erneut fetch bemüht, allerdings wird diesmal nicht der Header (body[header]), sondern der Nachrichtentext (body[text]) abgefragt. Der Inhalt der Nachricht ist „Hallo! Nachrichtentext.∖r∖n“.22 Schließlich meldet sich der Client mit logout vom Server ab.

beiden Escapesequenzen ∖r und ∖n bedeuten schlicht, dass am Ende der Nachricht eine leere Zeile stand. 22Die

2.16  Application Layer: E-Mail- und Usenetprotokolle

75

Es gibt zahlreiche weitere Befehle für IMAP, doch soll dieser Einblick erst einmal genügen.

2.16.3 SMTP SMTP dient zum Versenden von E-Mails und nimmt standardmäßig Verbindungen auf Port 25 entgegen. Mit HELO beziehungsweise EHLO erfolgt die Bekanntgabe der eigenen Domain am SMTP-Server. SMTP unterstützt zudem Authentifizierungen. Mails werden in zwei Schritten versendet. Zunächst werden zentrale Headerbestandteile einer E-Mail (Absender und Empfänger) gesendet: mit MAIL FROM: und RCPT TO: . Anschließend leitet der Befehl DATA den restlichen Teil der E-Mail ein. Dabei können zeilenweise zunächst optionale Headerbestandteile (etwa der E-Mail-Betreff mit Subject: ) übertragen werden. Anschließend sendet der Client eine Leerzeile gefolgt von der eigentlichen Nachricht. Die Nachricht wird mit einem einzelnen Satzpunkt abgeschlossen, der in einer separaten Zeile stehen muss. QUIT terminiert die Verbindung schließlich. Das folgende Beispiel zeigt, wie eine E-Mail von [email protected] an erika. [email protected] verschickt werden kann. Die Nachricht hat den Betreff „Hallo, SMTP-Server“ und wurde vom Mailprogramm „Mailprogramm/1.0“ (die Versionsangabe erfolgt analog zu der von HTTP) versendet.

76

2  Grundlagen der Netzwerktechnik

2.16.4 NNTP (Usenet) Das Network News Transfer Protocol (NNTP [5]) wird im sogenannten Usenet verwendet – einem Vorläufer heutiger Web-Foren. Es handelt sich um ein altes Netzwerkprotokoll, das in diesem Buch verwendet wird, um erstens ein Verständnis für historische Protokolle der Anwendungsschicht zu unterstützten, und zweitens, um zu zeigen, dass auch historische Protokolle sicherheitsrelevant sind. Mehr zur Historie von NNTP findet sich unter anderem in einem lesenswerten Aufsatz von Raymond [22]. Selbstverständlich sind auch IPv4, TCP und Co. alte Protokolle. Im Gegensatz zu NNTP werden sie allerdings noch intensiv verwendet. Einige Universitäten betreiben zwar nach wie vor Usenet-Server, doch hat NNTP keine vergleichbare Bedeutung mehr, wie die zuvor genannten Protokolle. Es lohnt sich dennoch, einen Blick in die spannende Historie von Netzwerkprotokollen zu werfen. Darunter auch Protokolle wie UUCP oder GOPHER.

2.16  Application Layer: E-Mail- und Usenetprotokolle

77

Sie können diese Protokolle noch immer verwenden und jedes dieser Protokolle lässt Sie implizit etwas Zusätzliches über heutige Protokolle und das Internet erlernen.23 Diskussionsforen heißen im Usenet Newsgroups und sind hierarchisch organisiert. So würde sich etwa die Newsgroup de.comp.os.linux.misc auf Deutsch (de) mit dem Thema Computer/Informatik (comp), genauer mit Betriebssystemen (os), und zwar dem Betriebssystem Linux (linux) und nicht näher definierten und sonst nirgends abgedeckten Themen (misc, Kurzform für miscellaneous) befassen. Dieses in die Jahre gekommene Protokoll ist auch deshalb für uns interessant, da es, falls es irgendwo zum Einsatz kommt, aus Sicht eines Angreifers interessant ist, um viele Informationen über eine Organisation zu erlangen. NNTP dient der Übertragung von Nachrichten zwischen einem Usenet-Client und einem Usenet-Server sowie zur Kommunikation zwischen Usenet-Servern (zum Abgleich von Nachrichten). NNTP ist ebenfalls ein Klartextprotokoll und funktioniert ganz ähnlich wie SMTP und POP3, hat allerdings etwas komplexere Befehle. NNTP wird über TCP betrieben und verwendet standardmäßig Port 119. Mit dem Befehl HELP liefert ein NNTP-Server eine Liste der vom Server unterstützten Befehle samt Parameter. Eine Übersicht über vorhandene Newsgroups liefert der Befehl LIST. Der Befehl liefert zudem die geringste und höchste Nachrichtennummer in einer Newsgroup sowie Daten darüber, ob das Senden von Nachrichten (das Posten) in die jeweilige Newsgroup erlaubt (y) beziehungsweise nicht erlaubt ist (n). Die Liste der Nachrichten wird mit einem Punkt in einer separaten Zeile abgeschlossen.

Um eine Nachricht an eine Newsgroup zu schicken, wird der Befehl POST verwendet. Analog zu SMTP wird hier zunächst ein Header definiert und nach einer Leerzeile der Nachrichteninhalt übertragen. Statt einem E-Mail-Empfänger wird allerdings eine Liste der Zielnewsgroups (in der Regel ist dies nur eine einzige Newsgroup) angegeben

23Dies gilt im Übrigen auch für historische Betriebssysteme, deren Konzepte viel über die heutigen Betriebssysteme berichten können und zum Teil unverändert angewandt werden.

78

2  Grundlagen der Netzwerktechnik

(Newsgroups: ), Newsgroups werden dabei durch Kommas voneinander getrennt).

Nachdem eine Nachricht gepostet wurde, erhöht sich entsprechend die Anzahl der Nachrichten in einer Newsgroup (in diesem Fall stieg die höchste Nachrichtennummer in alt. test von 4 auf 5).

Mit dem Befehl GROUP kann eine Newsgroup selektiert werden. Innerhalb dieser Newsgroup können dann beliebig Nachrichten abgerufen werden. XOVER liefert eine Übersicht über gepostete Nachrichten (als Parameter wird eine Nachrichtennummer/ID oder ein Bereich von Nachrichtennummern angegeben). HEAD liefert den Header einer Nachricht, BODY die eigentliche Nachricht. STAT fragt den Status einer Nachricht ab und ARTICLE lädt eine gesamte Nachricht herunter, das heißt Header und Body. Alle vier Befehle erwarten eine Nachrichtennummer als Parameter. Einzelne Headerbereiche (etwa der Nachrichtenbetreff (subject)) können mit XHDR abgefragt werden, das analog zu XOVER verwendet wird. Wie üblich werden Verbindungen mit QUIT terminiert.

2.17  Application Layer: sonstige Protokolle

79

2.17 Application Layer: sonstige Protokolle Es gibt noch eine Vielzahl weiterer, teils recht bedeutsamer, Protokolle auf dem Application Layer, die an dieser Stelle allerdings nicht im Detail betrachtet werden können.

80

2  Grundlagen der Netzwerktechnik

So dient Telnet beispielsweise dazu, sich mit anderen Computern zu verbinden und dort Befehle auszuführen, teils zur Administration, teils um Netzwerkdienste zu testen. Das File Transfer Protocol (FTP) dient der Bereitstellung und Abfrage von Dateien über einen Server; einem Vorgänger von Cloudspeicher, der noch immer verlässlich funktioniert. Secure Shell (SSH) samt Secure Copy (scp-Programm) dient der sicheren Fernadministration von anderen Rechnern und der sicheren Übertragung und Bereitstellung von Dateien. SSH und Secure Copy sind wesentlich sicherer als Telnet und FTP; sie ersetzen diese beiden älteren Protokolle. Das Network Time Protocol (NTP) dient der netzwerkweiten Konfiguration von Uhrzeiten auf Rechnern. Weitere Protokolle sind etwa die Chatprotokolle Internet Relay Chat (IRC) und Extensible Messaging and Presence Protocol XMPP oder das Simple Network Management Protocol (SNMP), das zur Überwachung von Netzwerkkomponenten dient. Weitere bedeutsame Protokolle sind solche, die für die Übertragung von Multimediainhalten zuständig sind. Das Session Initiation Protocol (SIP) dient der Steuerung von Multimediaübertragungen. SIP verwendet in der Regel zusätzlich das Session Description Protocol (SDP), das – eingekapselt in SIP – die eigentlichen Multimediaparameter, etwa zu verwendende Audiocodecs, zwischen den Teilnehmern aushandelt. Die eigentliche Übertragung von Audio- und Videostreams kann wiederum mit dem (Secure) Real-time Transport Protocol ((S)RTP) erfolgen. Verschiedene bedeutsame Netzwerkprotokolle für das Internet der Dinge werden in Kap. 10 besprochen, darunter MQTT und CoAP. Diese Protokolle dienen insbesondere der Kontrolle von steuerbaren Geräten (Aktoren) und der Überwachung messbarer Geräte (Sensoren).

2.18 Ausblick Waren klassische Anforderungen an Netzwerke noch relativ überschaubar, so stieg der Bedarf an Übertragungskapazität, Sicherheit und Verlässlichkeit in Netzwerken kontinuierlich an, insbesondere getrieben durch immer anspruchsvollere Dienste. Genügte es früher beispielsweise, eine unformatierte Nachricht von A nach B zu senden, so werden heute hochauflösende Video- und Audioinhalte gestreamt – an tausende Benutzer gleichzeitig. Die Anforderungen vieler moderner Netzwerkdienste, etwa die Steuerung autonomer Fahrzeuge oder das Durchführen Internet-gestützter medizinischer Operationen, verlangen hohen Durchsatz in Kombination mit minimalen Verzögerungen und extrem hoher Verfügbarkeit. Zudem dürfen derlei Dienste, von denen die Sicherheit von Menschen abhängt, nicht manipulierbar sein; übertragene Daten müssen vor dem Schutz durch Unberechtigte gesichert sein. Zukünftige Netzwerke müssen zudem für die zunehmend mobile Arbeit ausgelegt und dynamisch konfigurierbar konzipiert werden, um an variierende Anforderungen angepasst werden zu können.

2.21 Übungsaufgaben

81

2.19 Zusammenfassung Protokolle des TCP/IP-Modells sind in einer Schichtenarchitektur organisiert. Die Aufgaben der Schichten unterscheiden sich stark. Die unterste Schicht ist für die physikalische Datenübertragung und die darüber liegende Schicht für das Routing verantwortlich. Die dritte Schicht stellt Multiplexing bereit und die oberste Schicht beinhaltet anwendungsspezifische Funktionen. Es gibt, grob betrachtet, zwei Arten von Netzwerkprotokollen: solche mit binärem Header (etwa IPv4, IPv6, DNS) und solche mit Klartext-Header (etwa HTTP oder POP3). Die wichtigsten Protokolle der TCP/IP-Suite sind das ARP-Protokoll zur Übersetzung zwischen IP-Adressen und Hardware-Adressen, das Internet Protocol (IP) samt einem Steuerprotokoll (ICMP) sowie die neueren Versionen IPv6 und ICMPv6, die sich auf dem Internet Layer befinden, sowie UDP und TCP auf der Transportschicht, und verschiedene Protokolle der Anwendungsschicht (insbesondere HTTP, DNS, SMTP und IMAP). Viele weitere Protokolle existieren, sind aber im Rahmen dieses Buches nicht von nennenswerter Bedeutung oder werden aufgrund ihres IoT-Bezugs erst in Kap. 10 eingeführt.

2.20 Weiterführende Literatur Dieses einführende Kapitel kann ein so komplexes Thema wie Computernetze nur grob betrachten. Entsprechend hat es insbesondere solche Themen dargestellt, die für das Verständnis des restlichen Buches von besonderer Relevanz sind. Eine hervorragende und zugleich ausführliche Einführung in die Computernetze bietet etwa der Klassiker von Tanenbaum [27]. Empfehlenswert ist zudem das Buch Computer Networking: A Top-Down Approach von Kurose und Keith [13]. Zum Verständnis von Netzwerkprotokollen der TCP/IP-Suite empfiehlt sich aber insbesondere das Lesen der jeweiligen RFCs.

2.21 Übungsaufgaben 1. Erläutern Sie die vier Schichten des TCP/IP-Modells. 2. Wie funktioniert die Fragmentierung bei IPv4. Gehen Sie dabei auf die relevanten Headerbestandteile ein. Weshalb wird Fragmentierung benötigt und welche Rolle spielt dabei die MTU? 3. Ein IPv4-Paket mit folgenden Headerwerten trifft auf einem Router ein: IHL=5, Identifier=0x7f7f, DF=0, MF=1, Offset=256 Werden weitere Fragmente für das Paket folgen? (Falls ja: Wird der Router diese unter allen Umständen erhalten, wenn es keine Übertragungsfehler gibt?)

82

2  Grundlagen der Netzwerktechnik

4. Der Router muss das Paket aus der vorherigen Aufgabe erneut fragmentieren. Erläutern Sie, was dabei passieren würde (welche Auswirkung hat dies auf die Felder Identifier, MF und Offset bei einer von Ihnen frei wählbaren MTU?). 5. Internetrecherche: ICMP kennt den ICMP-Type 8 (Echo Request). Wie sieht der Payload dieses Requests unter Windows beziehungsweise Linux aus? 6. Ermitteln Sie die IP-Adresse Ihres Rechners und senden Sie einem anderen Rechner ICMP Echo Requests. Verwenden Sie zum Senden der Echo Requests den pingBefehl. Aufruf: ping , etwa: ping 127.0.0.1. 7. Wozu dient der ICMP-Type Parameter Problem (Type 12)? 8. Wozu dient der ARP-Cache? 9. Welche Headerfelder wurden in IPv6 eliminiert, die IPv4 noch besaß? 10. Wie sieht die IPv6-Adresse fe80::d497:fff1:85e2:7242 unkomprimiert aus? 11. Weshalb kann IPv6 im Standardheader auf ein DF-Flag verzichten, wie es in IPv4 integriert ist? 12. Welcher OSI-Schicht gehört IPv6 an? 13. Was bedeutet ::1/128? 14. Was ist die Standardroute (der Default Gateway) Ihres Rechners? (Verwenden Sie netstat oder route zur Lösung dieser Aufgabe.) 15. Mit dem Befehl traceroute (Linux) beziehungsweise tracert (manche Versionen von Windows) können Sie Routen nachverfolgen. Wie viele Hops liegen zwischen Ihrem Rechner und dem Webserver der Hochschule Worms? Wie viele Hops sind es bis zu www.google.de und wie viele Hops sind es bis zu www.waikato.ac.nz? 16. Wie funktioniert traceroute/tracert? 17. Worin bestehen die primären Unterschiede zwischen den Protokollen UDP und TCP? 18. Erklären Sie das Konzept der Reliability von TCP. 19. Welche Aufgabe hat der Urgent Pointer von TCP? 20. Wie groß ist ein IP-Paket, das aus einem Standard-IP-Header, einem Standard-TCPHeader und einem Payload von 120 Bytes besteht? 21. Wie groß wäre ein solches Paket bei Verwendung des Protokolls UDP anstelle von TCP? 22. Gibt es genauso viele UDP- wie TCP-Ports? (Ziel- und Quellports) 23. Ermitteln Sie die Anzahl offener TCP-Verbindungen und alle offenen TCP-Ports Ihres Rechners mit dem Tool netstat. 24. Welche Mail-Server hat die Domain heise.de und welche Prioritäten weisen diese auf? Hinweis: Nutzen Sie hierfür das Programm nslookup unter Windows oder Linux. 25. Zu welcher Organisation gehört die IP-Adresse 83.243.49.161? Hinweis: Diese IP gehört einer europäischen Organisation und für europäische Adressen ist die bereits erwähnte Organisation RIPE.net zuständig.

Literatur

83

26. Verwenden Sie das Programm telnet, um eine HTTP-GET-Anfrage an den Host www.prolinux.de zu senden (Port 80). Telnet wird wie folgt aufgerufen: telnet  . Welche Antwort bekommen Sie von diesem Host geliefert?

Literatur 1. Arends, R., Austein, R., Larson, M., et al.: Protocol Modifications for the DNS Security Extensions – RFC 4035, März (2005) 2. Conta, A., Deering, S.: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification – RFC 1885. Network Working Group (1995) 3. Crispin, M.: Internet Message Access Protocol – Version 4rev1 – RFC 3501. Network Working Group (2003) 4. Deering, S., Hinden, R.: Internet Protocol, Version 6 (IPv6) Specification – RFC 1883. Network Working Group (1995) 5. Feather, C.: Network News Transfer Protocol (NNTP) – RFC 3977. Network Working Group (2006) 6. Giffin, J., Greenstadt, R., Litwack, P., Tibbetts, R.: Covert messaging through TCP timestamps. In: Proceedings of 2nd International Conference on Privacy Enhancing Technologies, S. 194–208 (2003) 7. Grossman, D.: New Terminology and Clarifications for Diffserv – RFC 3260, Apr. 2002 8. Hagen, S.: IPv6. Grundlagen, Funktionalität, Integration, 2. Aufl. Sunny Edition (2009) 9. Herold, H., Lurz, B., Wohlrab, J.: Grundlagen der Informatik. Pearson Studium, München/ Boston (2007) 10. Internet Assigned Numbers Authority: Internet Control Message Protocol (ICMP) Parameters, Version vom 26. (2018). https://www.iana.org/assignments/icmp-parameters/icmp-parameters. xhtml. Zugegriffen am 18.01.2021 11. Internet Assigned Numbers Authority: IPv4 Multicast Address Space Registry, Version vom 20 (2018). https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml. Zugegriffen am 18. Jan. 2021 12. Internet Assigned Numbers Authority: Domain Name System (DNS) Parameters, Version vom 8. (2018). http://www.iana.org/assignments/dns-parameters. Zugegriffen am 18. Jan. 2021 13. Kurose, J., Keith, R.: Computer Networking: A Top-Down Approach (Global Edition), 7. Aufl. Prentice Hall, Harlow (2016) 14. Laurent, A.: Understanding Open Source and Free Software Licensing, Kapitel 2. O’Reilly, Beijing/Sebastopol (2004) 15. Linux Magazin. Meldung zur ICANN-Abstimmung für neue TLDs (2011). http://www.linuxmagazin.de/NEWS/ICANN-stimmt-fuer-neue-Generic-Top-Level-Domains. Zugegriffen am 18. Jan. 2021 16. Piscitello, D.M., Chapin, A.L.: Open Systems Networking. Addison-Wesley, Wokingham/ Reading (1993) 17. Plummer, D.C.: An Ethernet Address Resolution Protocol – or – Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware – RFC 826. Network Working Group (1982) 18. Postel, J. (Hrsg.): DoD Standard – Transmission Control Protocol – RFC 761. University of Southern California (1980) 19. Postel, J.: User Datagram Protocol – RFC 768 (1980)

84

2  Grundlagen der Netzwerktechnik

20. Postel, J. (Hrsg.): DoD Standard Internet Protocol – RFC 760. University of Southern California (1980) 21. Postel, J.: Internet Control Message Protocol – RFC 777. Network Working Group (1981) 22. Raymond, E.S.: Things Every Hacker Once Knew (2017). http://www.catb.org/~esr/faqs/ things-every-hacker-once-knew/. Zugegriffen am 18. Jan. 2021 23. RFC Editor: Webseite (2018). https://www.rfc-editor.org/. Zugegriffen am 18. Jan. 2021 24. Ridley, M.: The Evolution of Everything. Fourth Estate, London (2015) 25. Salamon, D., Motta, G.: Handbook of Data Compression. Springer, London (2010) 26. Schneider, J.M.: Protocol Engineering. A Rule-Based Approach, Vieweg Advanced Studies in Computer Science. Vieweg Verlag Wiesbaden, Wiesbaden (1992) 27. Tanenbaum, A.S.: Computernetzwerke, 4. überarb. Aufl. Pearson Studium, München (2003) 28. Weitzel, T., Westarp, F.V.: From QWERTY to nuclear power reactors: historic battles for the standard. In: Geihs, K., et al. (Hrsg.) Networks. Standardization, Infrastructure, and Applications, pp. 33–61. Physica-Verlag, Heidelberg (2002) 29. Wendzel, S.: Tunnel und verdeckte Kanäle im Netz. Springer-Vieweg, Wiesbaden (2012) 30. Wikipedia: Eintrag zum Thema „Huffman-Kodierung“ (2018). https://de.wikipedia.org/wiki/ Huffman-Kodierung. Zugegriffen am 18. Jan. 2021 31. Zander, S.: Performance of Selected Noisy Covert Channels and Their Countermeasures in IP Networks. Dissertation, Faculty of Information and Communication Technologies, Centre for Advanced Internet Architectures, Swinburne University of Technology (2010)

3

Grundlagen der IT-Sicherheit

For generations, people have defined and protected their property and their privacy using locks, fences, signatures, seals, account books, and meters. These have been supported by a host of social constructs ranging from international treaties through national laws to manners and customs. This is now changing, and quickly. – Ross Anderson (2001)

Zusammenfassung

Dieses Kapitel führt die Grundlagen der IT-Sicherheit ein. Es betrachtet die wichtigsten Begriffe samt Schutzzielen, zentrale Aspekte von Authentifizierung und Zugriffsschutz, das Thema Privatsphäre sowie Schadsoftware. Außerdem gibt es einen Einblick in nicht-technische Bereiche, die mit der IT-Sicherheit in Verbindung stehen. Das Kapitel schließt mit einem Einblick in die Wissenschaftlichkeit der IT-Sicherheit (Science of Security).

3.1 Einführung Eine Bildersuche bei Google nach den Begriffen „IT-Sicherheit“ und „Netzwerksicherheit“ führt zu ganz unterschiedlichen Eindrücken. Oftmals sitzen maskierte Personen vor einem Computer, manchmal wird ein Netzwerkkabel sinnfreier Weise durch ein Schloss geführt. Unabhängig von diesen medial wirksamen Vorstellungen hat das Thema ITSicherheit seit vielen Jahren an Bedeutung gewonnen und eine Umkehr dieses Trends ist noch nicht absehbar. Zutreffend ist dies auch auf den Stellenwert der IT-Sicherheit in der Ausbildung und Hochschullehre [9]. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-33423-9_3

85

86

3  Grundlagen der IT-Sicherheit

Dieses Buch betrachtet die IT-Sicherheit von TCP/IP- und IoT-Netzwerken. Das heißt, es bezieht IT-Sicherheit auf die netzwerkseitigen Aspekte von IT-Systemen. Nicht netzwerkseitig sind zum Beispiel Themen wie das sichere Programmieren oder der Speicherschutz in Betriebssystemen. Ein Studium der Netzwerksicherheit beinhaltet auch das Studium der Unsicherheit von Netzwerken und die Absicherung von Netzwerken. Es beinhaltet sämtliche Phasen des Lebenszyklus von Netzwerken – von der Planung, über die Inbetriebnahme, dem Betrieb samt Wartung, bis hin zur Außerbetriebnahme. Weiterhin beinhaltet dieses Studium Aspekte auf technischer sowie – zum gewissen Teil – auf organisatorischer Ebene. Was ist zunächst einmal unter dem zugrunde liegenden Begriff der IT-Sicherheit zu verstehen? Eckert schreibt in ihrem Standardwerk zur IT-Sicherheit: Definition 3.1 IT-Sicherheit hat die Aufgabe, Unternehmen und deren Werte (Knowhow, Kundendaten, Personaldaten) zu schützen und wirtschaftliche Schäden, die durch Vertraulichkeitsverletzungen, Manipulation oder auch Störung der Verfügbarkeit von Diensten des Unternehmens entstehen können, zu verhindern [13]. Hierbei könnte der Begriff „Unternehmen“ auch durch „Organisation und Individuen“ ersetzt werden. Neben Werten wäre dann auch die Privatsphäre schützenswert. Außerdem wären neben wirtschaftlichen Schäden sicherlich auch staatlich-hoheitliche oder persönliche Schäden durch Schaffung von IT-Sicherheit zu vermeiden. Gemeinhin wird IT-Sicherheit auch als Zustand betrachtet, nämlich der Zustand, in dem die ITInfrastruktur exakt den Zweck erfüllt, für den sie vorgesehen ist. Ungewünschte Zwecke wären folglich nicht vorgesehen. In [26] relativierten wir diese Aussage jedoch sogleich, da die verwendeten Begriffe „Zweck“ und „IT-Infrastruktur“ nicht exakt definiert sind. Dennoch ist diese prägnante Definition hilfreich. Wenn ein Angreifer dafür sorgt, dass die IT-Infrastruktur nur einen Teil des vorbestimmten Zwecks abdeckt (weil beispielsweise Daten gelöscht wurden) oder zusätzliche Aufgaben durchführt (etwa Spam versenden), dann erfüllt sie nicht mehr „exakt den Zweck …für den sie vorgesehen“ wurde. Sicherheit kann auch mehrseitig betrachtet werden. Mehrseitige Sicherheit (engl. Multilateral Security) berücksichtigt die Sicherheitsanforderungen aller Beteiligten. Rannenberg et al. merken an, dass sich bei offenen Kommunikationssystemen [nicht alle Beteiligten] per se vertrauen [und sich daher] als potentielle Angreifer [sehen] können [27]. Eine Definition von mehrseitiger Sicherheit gibt Pfitzmann: Definition 3.2 Mehrseitige Sicherheit bedeutet die Einbeziehung der Schutzinteressen aller Beteiligten sowie das Austragen daraus resultierender Schutzkonflikte, etwa beim Entstehen einer Kommunikationsverbindung [24]. Er führt weiter an, dass diese Beteiligten jeweils Individualziele verfolgen und Teil unterschiedlicher Gemeinschaften sein können. Dabei können sie nicht nur legitime

3.1 Einführung

87

Rechte und Ansprüche an die Gemeinschaften, sondern Gemeinschaften [können] auch [Ansprüche] an ihre Mitglieder haben. Nicht immer sind die Ziele aller Beteiligten miteinander vereinbar und nicht immer kann eine für alle Beteiligten akzeptable Kommunikation realisiert werden [24]. Zur Definition des Zustands Netzwerksicherheit lässt sich obige Aussage leicht abändern, indem statt von einer IT-Infrastruktur von einem Rechnernetz gesprochen wird. Das heißt: Definition 3.3 Netzwerksicherheit, das heißt die IT-Sicherheit von Rechnernetzen, ist der Zustand, in dem ein Rechnernetzwerk samt seiner Komponenten exakt den vom Netzwerkbetreiber angedachten Zweck erfüllt, für den es vorgesehen ist. Der Zweck kann dabei verschiedene Teilaspekte aufweisen, etwa E-Mails zu versenden und Daten verteilt zu speichern. Der Zweck kann zudem erweitert werden und ändert sich mit seiner Erweiterung. Eine illegitimer Zweck (beispielsweise das Versenden von Spam über ein Netzwerk) würde den angedachten Zweck hingegen erweitern oder verändern. Das heißt, ein Angriff – etwa durch Löschen von Daten – würde einen angedachten Zweck unmöglich machen. Da in der obigen Definition von „exakt dem angedachten Zweck“ die Rede ist, wäre der Zweck nicht mehr realisiert und die Netzwerksicherheit nicht mehr gegeben. Exkurs: Sabotage außerhalb von IT-Systemen

Anfang 1944 gab das amerikanische Office of Strategic Services (OSS), der Vorläufer der heutigen CIA, ein Sabotage-Handbuch für seine Agenten heraus [23]. Mittlerweile ist das Handbuch frei im Internet verfügbar und nicht mehr geheim. Das Handbuch beschreibt den Umgang mit gewöhnlichen Bürgern, die zur Sabotage angestiftet werden sollen, insbesondere im Dritten Reich. Die Lektüre des Handbuchs ist auch für Studierende und Professionals der IT-Sicherheit relevant, da es einen Blick über den Tellerrand der eigentlichen Disziplin wirft und sich dem Leser Parallelen zwischen hochtechnlogischen Angriffen und traditionellen Sabotagekonzepten aufzeigen. Ein Großteil der Angriffe würde auch bei heutigen Unternehmen Früchte tragen und viele der dargestellten Sabotageakte sind eher subtil und bestehen ganz und gar nicht darin, große Explosionen zu verursachen. So besteht eine Überlegung etwa darin, unschöne Situationen in Organisationen des Feindes zu schaffen und langsam die Moral von Mitarbeitern oder Bürgern zu untergaben. Es kann sich dabei etwa darum handeln, dass Saboteure Prozesse verzögern, weil sie bestimmte Dokumente schlicht zu spät bearbeiten. Es spielt letztlich nur eine sekundäre Rolle, ob eine derartige Sabotage zur Kriegszeit mit Papier oder heutzutage mit einem Computer durchgeführt wird. Auch Denial-of-Service-Angriffe lassen sich im Handbuch finden. So besteht ein Angriff etwa darin, die Toiletten mit zusammengerolltem Toilettenpapier, Haaren

88

3  Grundlagen der IT-Sicherheit

und anderen Gegenständen zu verstopfen. Auch die Entflammbarkeit von Gebäuden kann durch Saboteure begünstigt werden. Weitere Angriffe konzentrieren sich beispielsweise auf Kühlsysteme, elektrische Motoren, den Schienenverkehr, Telegraphen, die Stromversorgung oder das simple Verteilen von Nägeln auf der Straße. Das heute in der IT-Welt vorhandene Social Engineering lässt sich in den 1940er-Jahren ebenso finden. So wird etwa vorgeschlagen, die Moral von Arbeitern zu untergraben, indem solche Arbeiter, die es in keiner Weise verdient haben, vor den Augen der anderen befördert werden.

Somit stellt sich auf Basis der obigen Definition die Frage nach den primären Zielen von IT-Sicherheit und damit auch der IT-Sicherheit von Netzwerken. Bishop nennt drei Ziele [8], nämlich: 1. die Prävention von Angriffen (prevention of attacks), 2. die Angriffsdetektion (detection of attacks) und 3. die Systemwiederherstellung (recovery), die er wiederum in zwei Teilaspekte gliedert: a. stattfindende Angriffe stoppen und die Reperatur des Systems durchführen b. sowie die Funktionsfähigkeit eines Systems während einem laufenden Angriffs gewährleisten. Diese Ziele sind verwandt mit den sogenannten Schutzzielen der IT-Sicherheit, die im nächsten Abschnitt betrachtet werden. Genauer gesagt handelt es sich bei den von Bishop genannten Zielen um solche, die zur Erfüllung der Schutzziele beitragen können. So kann das Ziel Systemwiederherstellung etwa zum Schutzziel Verfügbarkeit beitragen. Die von Bishop genannten Ziele sind allerdings nicht hinreichend, um sämtliche Schutzziele unter jeder Bedingung zu erreichen. Exkurs: Hacker, Cracker und Co.

Der Begriff Hacker bezeichnet jemanden, der kreativ mit (technischen) Dingen umgeht beziehungsweise ein sehr fähiger Programmierer ist, es kann sich aber beispielsweise auch um einen fähigen Musiker handeln. Raymond beschreibt einen Hacker wie folgt: Definition 3.4 There is a community, a shared culture, of expert programmers and networking wizards that traces its history back through decades to the first time-sharing minicomputers and the earliest ARPAnet experiments. The members of this culture originated the term ‘hacker’. Hackers built the Internet. Hackers made the Unix operating system what it is today. Hackers make the World Wide Web work. If you are part of this culture, if you have contributed to it and other people in it know who you are and call you a hacker, you’re a hacker [28].

3.2  Schutzziele der IT-Sicherheit

89

Hacker stehen insbesondere mit der Bewegung um freie Software in Verbindung [17, 22]; sie entwickelten bedeutsame Software, die auf fast jedem heute verwendeten Computer zum Einsatz kommt, etwa Linux, BSD und diverse Bibliotheken, siehe unter anderem [17, 22, 34]. Ein Grundkonzept der HackingCommunity ist das Teilen von Wissen, Erkenntnissen und Werkzeugen. Erst später wurde aus dem Hacker durch diverse Publikationen und Medienbeiträge ein böswilliger Angreifer gemacht. Diese Begriffsverwendung ist allerdings nicht korrekt. Wenn in diesem Buch von einem Hacker die Rede ist, dann ist ein kreativer Angreifer auf ein IT-System gemeint, der die Sicherheit eines Systems überprüft oder erhöht. Der Begriff wird ohne Bezug auf ein Geschlecht verwendet und soll primär die Kompetenz des Angreifers betonen. Oftmals werden Hacker in White hats und Black hats (oder Crackers) eingeordnet, also in solche die hacken, um Systeme zu sichern (Sicherheitslücken finden, ausbessern oder neue Sicherheitssysteme entwickeln) und solche, die hacken, um in Systeme einzudringen beziehungsweise diese sonstig negativ zu beeinflussen [4]. Dies ist konträr zur Auffassung von Raymond, der schreibt hackers build things, crackers break them; Black hats wären demnach folglich keine Hacker. Individuen, die nicht klar als White hat oder Black hat einzuordnen sind, werden oft Grey hats genannt. Neben Hackern gibt es die als unfähig betrachteten Individuen, die etwa nur in der Lage sind, fertige Angriffstools zu verwenden, aber diese nicht verstehen und nicht selber entwickeln können. Diese Art von Angreifer nennt sich Script Kiddie – im Sinne von Kindern, die mit bösartigen Skripten herumspielen. Der primäre Unterschied zwischen Hackern und Script Kiddies liegt folglich im Kompetenzniveau und in den Absichten.

3.2 Schutzziele der IT-Sicherheit Es gibt drei wesentliche Schutzziele der IT-Sicherheit. Diese Schutzziele werden auch als CIA-Triade bezeichnet [6]. Das Kürzel CIA ergibt sich aus den Anfangsbuchstaben der drei englischen Bezeichnungen dieser Schutzziele. Dabei handelt es sich um Vertr aulichkeit(confidentiality), das heißt es gibt keine unautorisierte Informationsgewin nung;Integrität(integrity), das heißt es ist Subjekten nicht möglich, die zu schützenden Daten unatorisiert und unbemerkt zu manipulieren; und Verfügbarkeit(availability), das heißt authentifizierte und autorisierte Subjekte werden in der Wahrnehmung ihrer Berechtigungen nicht unautorisiert beeinträchtigt [13]. Auch die Authentizität(authenticity) stellt ein Schutzziel dar. Sie ist gegeben, wenn durch geeignete Kontrollmaßnahmen sichergestellt wird, dass Daten und Informationen wirklich aus der angegebenen Quelle stammen und dass die Identität eines Benutzers oder eines angeschlossenen Systems korrekt ist, sie wird auch als Echtheit bezeichnet [6]. Zudem existiert das Schutzziel Verbindlichkeit (non-repudiation oder auch

90

3  Grundlagen der IT-Sicherheit

­ icht-Abstreitbarkeit und Unleugbarkeit). Verbindlichkeit bedeutet, dass von Subjekten N durchgeführte Aktionen nachgewiesen und im Nachhinein nicht geleugnet werden können und das Daten/Dokumente Quellen zugeordnet werden können [6]. Verbindlichkeit kann beispielsweise durch digitale Signaturen erzielt werden. Weitere Schutzziele sind etwa die Anonymität und die Unverkettbarkeit, die in Abschn. 3.6 genauer betrachtet werden.

3.3 Schwachstellen, Verwundbarkeiten und Co. Die zuvor besprochenen Schutzziele können durch Bedrohungen beeinträchtigt werden, doch worum handelt es sich dabei genau? Zunächst einmal muss definiert werden, was eine Schwachstelle (engl. Weakness) ist. Eine Schwachstelle ist eine Schwäche in einem System, etwa ein Drucker mit alter, fehlerhafter Software, der alle zwei Wochen eine leicht blasse Seite druckt. Diese Schwachstelle ist zunächst einmal ärgerlich, aber noch nicht sicherheitsrelevant. Diese Tatsache entspricht meist nicht dem Grundverständnis des Begriffs: In Debatten außerhalb der Sicherheits-Community wird der Begriff Schwachstelle nämlich gern mit Verwundbarkeit gleichgesetzt. Eine Verwundbarkeit (engl. Vulnerability) ist eine Schwachstelle, die durch einen Angreifer zu seinem Vorteil und zum Nachteil des zu schützenden Systems werden kann. Beispielsweise könnte der oben genannte Drucker einen Codeabschnitt besitzen, der es ermöglicht, ein Verzeichnis auszulesen, das Daten anderer Druckaufträge beinhaltet (Schutzziel: Vertraulichkeit). Die Verwundbarkeit kann wiederum zu einer Bedrohung (engl. Threat) werden, wenn ein Weg existiert, mit dem ein Angreifer die Verwundbarkeit tatsächlich ausnutzen kann. Zum Beispiel könnte es sein, dass die Verwundbarkeit des Druckers ausnutzbar wäre, wenn HTTP-Zugriff auf einen Webservice des Druckers existiert. Ein Angreifer könnte dann über HTTP eine Anfrage stellen, die die Verwundbarkeit (den besagten Codeabschnitt) ausnutzt, und somit ein Verzeichnis auslesen. Wäre dieser Webservice jedoch deaktiviert, dann wäre keine Bedrohung, sondern nur eine Verwundbarkeit gegeben. Wenn der Webservice hingegen aktiviert wäre, und der Angreifer die Verwundbarkeit mit einer entsprechenden HTTP-Anfrage ausnutzen kann, dann liegt eine Bedrohung vor. Zu schützende Werte (etwa vertrauliche Kundendaten) werden als Assets bezeichnet. Diesen Assets kann ein individueller Wert zugewiesen werden. Bei einem Bankhaus wird der Wert von Bankdaten der VIP-Kunden beispielsweise höher ausfallen, als der Wert von Daten, die Werbetexte beinhalten. Wenn sowohl den Assets (A), als auch den zugehörigen Verwundbarkeiten (V ) und Bedrohungen (B) Werte zugewiesen werden, dann lässt sich das Risiko (engl. Risk, R) berechnen. Üblicherweise werden hierbei Werte von 1–5 verwendet. Summiert man die drei Werte und subtrahiert den Wert 2, dann erhält man eine Skala von 1–13 [31].1

R=A+V +B−2 1Andernfalls

würde die Skala unschönerweise bei 3 beginnen.

(3.1)

3.4 Zugriffskontrolle

91

Alternativ lässt sich das Risiko auch so ausdrücken, das die Eintrittswahrscheinlichkeit eines Schadens (PE, wobei 0 ≤ PE ≤ 1) mit den damit verbundenen Kosten (Schadenshöhe, SE, wobei 0 ≤ SE ≤∞) kombiniert wird [13, 21].

R = PE · S E

(3.2)

Dabei sollte beachtet werden, dass sich die Eintrittswahrscheinlichkeit eines Schadens abhängig von der Bedrohungslage ändern kann. Wenn beispielsweise kaum Angriffsmöglichkeiten für einen bestimmten Browser verfügbar wären, nun aber ein neues Programm auftaucht, dass eine besonders schwerwiegende Verwundbarkeit ausnutzt und diese durch die Medien kommuniziert wird, steigt die Eintrittswahrscheinlichkeit deutlich an. Eine Risikobetrachtung kann aufwendig sein, da oftmals viele Assets (beliebig feingranular) identifiziert werden können. Zudem gibt es pro Asset meistens mehrere mögliche Szenarien (verschiedene Angriffe, Hardwareausfall, Probleme durch Fehlverhalten), die identifiziert werden sollten. Die Zuweisung von Werten kann dabei durch Abschätzung und auf Basis von Erfahrung umgesetzt werden. Letztlich sollten nach Möglichkeit jene Risiken zuerst adressiert werden, die die höchsten Werte erhalten haben (bei denen also kombinierter Schaden und Eintrittswahrscheinlichkeit am größten sind). Risiken können selbstverständlich noch einer Kosten-Nutzen-Rechnung unterzogen werden, um über die Möglichkeit und Reihenfolge ihrer Bearbeitung zu entscheiden. Ein relativ hohes Risiko mit extrem hohen Kosten fällt bei einer solchen Betrachtung eventuell in einen finanziell unmöglich realisierbaren Bereich. Hingegen könnte ein moderates Risiko, dessen Reduktionskosten minimal sind, in einem Ranking schließlich eine Top-Priorität erhalten.

3.4 Zugriffskontrolle Ein grundlegendes Problem der IT-Sicherheit ist der Schutz des Zugriffs auf Ressourcen. Hiermit sind also mindestens die Schutzziele der Vertraulichkeit und Integrität verbunden. Es geht um Autorisierung und dabei werden primär zwei Modelle unterschieden: • Discretionary Access Control (DAC) – benutzerbasierte und -bestimmbare Zugriffskontrolle; Zugriff auf Daten wird anhand einer Identität getroffen. • Mandatory Access Control (MAC) – Zugriffskontrolle auf Basis von Regeln und Attributen, etwa einem bestimmten ‘Label’. DAC und MAC werden im Folgenden detaillierter betrachtet. Sie lernen Beispielansätze zur Umsetzung dieser Modelle kennen.

92

3  Grundlagen der IT-Sicherheit

3.4.1 Discretionary Access Control (DAC) DAC ist das bekannteste und grundlegendste Modell und lässt sich durch eine Zugriffskontrollmatrix abbilden, bei der Spalten und Zeilen die Objekte und Benutzer (und in einer weiteren Matrix die Objekte und Gruppen) abbilden. Für jede Art Zugriffsrecht wird dabei eine separate Matrix definiert. So kann eine Matrix etwa das Leserecht abdecken, eine andere das Schreib- und eine weitere das Ausführungsrecht für Dateien. Weitere Rechte, etwa für das Hinzufügen von Inhalten an eine Datei (Append) können nach Bedarf definiert werden. Illustration: Ein Zugriff auf ein Verzeichnis, für das ein Benutzer – wie im folgenden Listingbeispiel – keine Berechtigung hat, wird durch das Attribut Benutzer (und seiner Gruppenzugehörigkeit) überprüft. Der Benutzer „hsw“ und die Gruppe „hsw“ haben keinen Zugriff auf das Objekt /root.

3.4.2 DAC-Erweiterungen Nun ist es nicht immer praktikabel – insbesondere bei einer großen Anzahl an Benutzern –, jedes Zugriffsrecht für jeden Benutzer und jedes Objekt zu definieren. Aus diesem Grund wurde das DAC-Modell erweitert. Das klassische Modell für Zugriffsrechte unter Unix (Eigentümer, Gruppe und andere Benutzer, siehe etwa [38]) wurde insofern erweitert, dass Zugriffsrechte für mehrere Benutzer (statt nur für den assoziierten Eigentümer) und mehrere Gruppen (statt nur für die assoziierte Gruppe) geregelt werden können. Dieses Verfahren nennt sich Access Control Lists (ACL). Es können neben Lese-, Schreib- und Ausführungsrecht weitere Rechte definiert werden. Alle gängigen Betriebssysteme für Server und Workstations unterstützten ACL in unterschiedlichen Varianten. Role-based Access Control (RBAC) erlaubt hingegen den Zugriff eines Benutzers auf ein Objekt nicht mehr durch die Identität des Benutzers, sondern auf Basis der Zugehörigkeit des Benutzers zu einer bestimmten Rolle. So könnte beispielsweise die Rolle Entwickler-P1 für die Entwickler des Projekts P1 definiert werden. Anstatt jedem Benutzer nun die nötigen Zugriffsrechte zu geben, wird ein Entwickler nur noch der Rolle zugewiesen. Zugriffsrechte werden wiederum der Rolle gegeben. RBAC bringt allerdings das Problem mit sich, dass es statisch ist. Das heißt, dass dynamische Rechteänderungen nicht vorgesehen sind, die aber in lebendigen Organisationen oft vorkommen können,

3.4 Zugriffskontrolle

93

weil ein Mitarbeiter etwa die Aufgaben eines im Urlaub befindlichen Kollegen übernehmen muss und daher entsprechende Zusatzrechte benötigt. Schlegel schlägt daher ein dynamisches RBAC-Zugriffsmodell vor, das für derartige Situationen ausgelegt ist [30].

3.4.3 MAC und DAC: Das Bell-LaPadula-Modell Es2 gibt sogenannte Multilevel Security-Richtlinien (MLS-Richtlinien). Bei diesen Richtlinien werden verschiedene Sicherheitslevels, etwa „Geheim“ oder „Streng Geheim“ vergeben. Das BLP-Modell sichert die Vertraulichkeit von Daten im Kontext eines MLSSystems und wurde 1973 von Bell und LaPadula vorgestellt. Das BLP-Modell enthält eine Menge von Sicherheitslevels. Eine höhere Klassifikation wird durch einen höheren Sicherheitslevel ausgedrückt und entspricht dabei auch einer höheren Datensensitivität. Jedes Subjekt s hat eine Security Clearance L(s), etwa L(John) = confidential, dies entspricht dem maximalen Sicherheitslevel des Subjekts. Jedes Objekt o ist einer Classification zugeordnet: L(o), beispielsweise L(Dateix) = secret. Clearance und Classification beziehen sich auf dieselben Sicherheitslevels. Der Unterschied besteht darin, dass ein Subjekt seinen Sicherhitslevel zu einem Sicherheitslevels unterhalb seiner Clearance reduzieren kann. Objekte können dies nicht tun. Das BLP-Modell realisiert DAC-Zugriff basierend auf einer Access Control Matrix (Zugriffsmatrix), beinhaltet darüber hinaus aber zwei „Mandatory“-Regeln (für MAC zuständig), die unbedingt eingehalten werden müssen. Es gibt zwei dieser MandatoryRegeln: • •

Simple Security Condition (oder: No Read-up, NRU): Ein Subjekt s kann nur lesend auf ein o zugreifen, wenn L(s) ≥ L(o). *-Property (oder No Write-down, NWD): Ein Subjekt s kann nur schreibend (Write/Append) auf o zugreifen, wenn gilt L(s) ≤ L(o).

Jeweils muss zusätzlich DAC-basierter Zugriff für s auf o erlaubt sein, andernfalls wird der Zugriff verweigert.

3.4.3.1 Kategorien im BLP-Modell Das BLP-Modell kennt zudem sogenannte Kategorien, die spezifische Zugriffsberechtigungen auf Basis von beispielsweise Projekten oder Organisationseinheiten erlauben. Kategorien können sowohl Subjekten als auch Objekten zugewiesen werden. Auch hierbei muss jeweils noch DAC-basierter Zugriff für s auf o erlaubt sein.

2Dieser Abschnitt

basiert auf [37] und wurde für dieses Buch ins Deutsche übersetzt und erweitert.

94

3  Grundlagen der IT-Sicherheit

Beispiel  In einer Organisation existieren die Kategorien accounting, development, und support. John hat die Clearance (confidential, {accounting, support}). Der erste Parameter gibt in dieser Schreibweise den eigentlichen Sicherheitslevel an, der zweite die Kategorien. Man bezeichnet die Kombination beider Parameter jedoch ebenfalls als Sicherheitslevel oder auch Compartment. Das Objekt filex sei hingegen klassifiziert als (secret, {accounting}). Die sogenannte dom-Relation (für domination) erlaubt nun die Nutzung der Compartments. Das Compartment (L, C) hat den Sicherheitslevel L und die Kategorie C. (L, C) dom (L′, C′) gilt, wenn L′≤ L und C′⊆ C [8]. Lesezugriff auf ein Objekt wäre also nicht möglich, wenn das Objekt einen Sicherheitslevel hätte, der höher als der des Subjekts ist, selbst dann, wenn der Zugriff über die Kategorien gegeben wäre [8]. Die bisherigen beiden Mandatory-Regeln NRU und NWD können nun wie folgt modifiziert werden, um mit Kategorien zu arbeiten: • Lesezugriff für s auf o ist nur erlaubt, wenn s dom o gilt und DAC-basierter Lesezugriff für s auf o gegeben ist (NRU-Regel). • Schreibzugriff für s auf o ist nur erlaubt, wenn o dom s gilt und DAC-basierter Schreibzugriff für s auf o gegeben ist (NWD-Regel).

Beispiel  Die Subjekte Alice and Bob möchten auf das Objekt databasex lesend zugreifen (siehe Abb. 3.1). Es liegt folgende Situation zugrunde: • (L,C) für Alice: (secret, {accounting,research}) • (L,C) für Bob: (confidential, {accounting, support}) • (L,C) für databasex: (confidential, {support}) Alice würde in diesem Fall keinen Zugriff auf databasex erhalten, obwohl L(Alice) > L(databasex) hat. Doch Alice hat keinen Zugriff auf die Kategorie support, das heißt Alice  ¬dom databasex. Bob würde diesen Lesezugriff hingegen erhalten, denn L(Bob) = L(databasex) und {support}⊂{accounting,support}, folglich Bob dom databasex.

Abb. 3.1   Beispielszenario für das BLP-Modell.

3.5 Authentifizierung

95

MLS-Zugriffsschutz ist unter Linux beispielsweise durch SELinux möglich. SELinux unterstützt im Übrigen auch Role-based Access Control (RBAC), das heißt dass Subjekte basierend auf ihren Rollen Zugriff auf Objekte erhalten.

3.4.3.2 Tranquility und Weak Tranquility Das Konzept der Tranquility besagt gemäß Bishop, dass Subjekte und Objekte ihre Sicherheitslevel nicht im Nachhinein ändern können. Weniger restriktiv ist das Konzept der Weak Tranquility, das den Wechsel von Sicherheitslevels unter der Bedingung erlaubt, dass die Sicherheitsrichtlinie nicht gebrochen wird [8]. Zur Umsetzung von Weak Tranquility wird ein vertrauenswürdiger Dritter benötigt, der den Sicherheitslevel anpasst [8]. 3.4.3.3 BLP und verdeckte Kanäle Wenn ein Zugriff so passiert, dass die Regeln NRU oder NWD verletzt werden (MLSKontext) beziehungsweise generell eine Sicherheitsrichtlinie verletzt wird, repräsentiert die zugehörige Kommunikation einen sogenannten verdeckten Kanal (engl. covert channel). Covert Channels wurden in den frühen 1970ern von Lampson eingeführt. Viele der frühen Kanäle funktionierten über die Ausnutzung von Systemressourcen, insbesondere Hardware. Da verdeckte Kanäle auch in Netzwerken vorliegen, werden diese in Kap. 9 ausführlich behandelt.

3.5 Authentifizierung Der Fokus des vorherigen Abschnitts lag auf der Zugriffskontrolle. Wie aber identifizieren Systeme Benutzer, um Zugriffskontrolle zu ermöglichen? An dieser Stelle kommt die Authentifizierung ins Spiel, sie ist der Prozess der Überprüfung auf Authentizität (Echtheit) eines Subjekts durch ein System. Unterschieden werden müssen hierbei zwei Verben. Ein Benutzer authentisiert sich gegenüber einem System (beispielsweise durch Angabe eines Passworts). Das System wiederum überprüft anschließend die Korrektheit des Passworts (es authentifiziert den Benutzer). Ein System speichert im simpelsten Fall nur Tupel (Benutzername, Passwort) lokal ab. Dadurch kann es bei der Anmeldung eines Benutzers überprüfen, ob Benutzer samt Passwort miteinander verbunden sind. Ein Passwort P sollte jedoch nicht im Klartext gespeichert werden. Eine sogenannte Hashfunktion H(P) speichert ein Komprimat (Prüfsumme) des Passworts. Ein sicheres Komprimat ist nicht zurückrechenbar, das heißt, H ist nicht umkehrbar, sodass selbst mit hohem Rechenaufwand nicht auf das Originalpasswort geschlossen werden kann. Es liegt folglich nicht der Klartext des Passworts vor. Anschließend wird überprüft, ob das Komprimat des von einem Benutzer angegebenen Passworts PA mit dem Komprimat eines tatsächlichen Passworts PB übereinstimmt, das heißt, ob H(PA) = H(PB) gilt. Diverse Hashfunktionen existieren; sie werden in Abschn. 4.8 besprochen.

96

3  Grundlagen der IT-Sicherheit

Stärkere Formen der Authentifizierung existieren, etwa die Mehrfaktorenauthentifizierung, bei der mehrere Authentifizierungsmechanismen kombiniert werden – oftmals zwei, man spricht in diesem Fall von einer Two Factor Authentication (2FA). Eine weitere Möglichkeit, ist die Verwendung von Einmalpasswörtern (One-time Passwords, OTP). Dabei erhält ein Benutzer eine Liste mit Passwörtern und jedes dieser Passwöter darf nur einmalig verwendet werden. Nachdem eine Liste (weitestgehend) aufgebraucht wurde, erhält der Benutzer eine neue Liste an Passwörtern. Auch verbreitet sind Challenge-Response-Verfahren. Bei diesen bekommt ein Benutzer bei der Anmeldung von einem System eine Aufgabe (engl. Challenge) von selbigem gestellt. Diese Challenge muss der Benutzer korrekt beantworten. Die Beantwortung (engl. Response) ist nur möglich, wenn der Benutzer über geheimes Wissen verfügt. Oftmals werden hierbei Zufallszahlen als Challenge verwendet. Als Response kann etwa verlangt werden, die Zufallszahl mit einem bestimmten kryptografischen Schlüssel zu verschlüsseln. Genereller formuliert kann eine solche Zufallszahl auch als Parameter für eine mathematische Funktion dienen; das Ergebnis der Funktion muss anschließend als Response zurückgesendet werden. Eine Kombination aus Einmalpasswörtern und Challenge-Response-Verfahren sind TAN-Verfahren, bei denen ein Benutzer eine Liste von Nummern (TANs) erhält, die alle nur einmalig nutzbar sind. Die Challenge besteht darin, dass bei der Anmeldung an einem System (etwa Onlinebanking) eine TAN-Nummer verlangt wird. Als Response muss der Benutzer die TAN mit dieser Nummer aus der Liste heraussuchen und eingeben. Außerdem gibt es die Möglichkeit einer biometrischen Authentifizierung. Zum Einsatz kommen können dabei unter anderem Fingerabdrucksensoren, Irisscaner, Retinascanner, Geräte zur Erkennung von Mustern der Venen und Gesichtserkennung. Derartige Sensorik für verschiedene Bestandteile des menschlichen Körpers kann außerdem zu der erwähnten Mehrfaktorauthentifizierung kombiniert werden. Eine biometrische Mehrfaktorauthentifizierung kann sinnvoll sein, um Angriffe zu erschweren, bringt allerdings einen höheren Aufwand für Benutzer mit sich. Angreifer könnten beispielsweise versuchen, einen Fingerabdruck mithilfe von Fettrückständen eines eingelesenen Fingerabdrucks, den eine Person hinterlassen hat, zu reproduzieren (derlei Angriffe wurden in der Vergangenheit erfolgreich durchgeführt und können zum Beispiel durch eine Lebenderkennung erschwert werden). Wenn zusätzlich weitere Sensorik getäuscht werden muss (etwa ein Irisscaner), kann ein Angreifer allein durch den Angriff auf einen Sensor nicht zum Erfolg gelangen. Dabei ist zu beachten, dass manche Sensortypen fälschungssicherer sind als andere. Dies hängt damit zusammen, dass sich Sensoren hinsichtlich ihrer Genauigkeit, Fehlerraten bei der Identifikation und ihren Toleranzbereichen unterscheiden. Die Speicherung biometrischer Daten gilt als hochgradig sensitiv. Insbesondere bei biometrischen Merkmalen, die über die Lebensspanne von Menschen hinweg konstant bleiben, kann eine einmalige Entwendung biometrischer Daten auch zur Kompromittierung zukünftiger Systeme und zu Identitätsdiebstahl führen. In Kap. 8 werden selektierte protokollspezifische Authentifizierungsverfahren, etwa IEEE 802.1X, betrachtet.

3.6 Privatsphäre

97

3.6 Privatsphäre Privatsphäre (engl. Privacy) ist gemäß Duden eine Sphäre, ein ganz persönlicher Bereich. Tatsächlich existieren diverse Möglichkeiten, Privatsphäre zu definieren, die von Porsch und Pieschl zu folgender Definition zusammengeführt wurden: Definition 3.5 Privatsphäre ist ein individueller Zustand der Abgeschiedenheit und Intimität […], der seiner stetigen Regulierung von Zuviel und Zuwenig Privatsphäre unterliegt […], wobei sich zu jedem Zeitpunkt vier verschiedene Privatsphärendimensionen unterscheiden lassen: informationale, soziale, psychische Privatsphäre [35]. Im Kontext des vorliegenden Buches ist insbesondere die informationale Dimension der Privatsphäre von Interesse. Exkurs: Ein Auszug aus A Cypherpunk’s Manifesto [18] (1993):

Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn’t want the whole world to know, but a secret matter is something one doesn’t want anybody to know. Privacy is the power to selectively reveal oneself to the world. […] We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy […]. We must defend our own privacy if we expect to have any […]. […] We know that someone has to write software to defend privacy, and since we can’t get privacy unless we all do, we’re going to write it.

3.6.1 Anonymität und Pseudonymität Ein zentraler Begriff im Rahmen der Privatsphäre ist die Anonymität. Pfitzmann und Köhntopp definieren diesen Begriff wie folgt: Definition 3.6  Anonymity is the state of being not identifiable within a set of subjects, the anonymity set [25]. Das heißt, Anonymität ist nur möglich, falls genügend viele andere Individuen (Subjekte) eine gleiche/ähnliche Aktion ausführen könnten (Anonymity Set) und bedeutet, dass ein Subjekt innerhalb dieser Menge nicht identifizierbar ist. Anonymität nimmt mit der der wachsenden Größe des Anonymity Sets zu.

98

3  Grundlagen der IT-Sicherheit

Eine abgeschwächte Form der Anonymität ist die Pseudonymität, bei der Subjekte Pseudonyme anstelle von Identitäten verwenden. Pseudonyme lassen unter Umständen allerdings Rückschlüsse auf die dahinter verborgene Identität zu. Definition 3.7 Pseudonymity is the use of pseudonyms as IDs. […] The subject that may be identified by the pseudonym is the holder of the pseudonym [25]. Anonymität kann für Rechner und Benutzer auf Netzwerkebene hergestellt werden. Anonymisierungsdienste auf der Basis von Mixen (Abschn. 5.4) sind hierfür ein geläufiger Ansatz. Allerdings existieren Gegenmaßnahmen, die eine Deanonymisierung ermöglichen. Auch für die Pseudonymisierung gibt es viele Anwendungsfelder, etwa bei der Verarbeitung personenbezogener Daten, die IP-Adressen oder Namen beinhalten. Aus juristischen Gründen werden derlei Daten, wenn sie etwa veröffentlicht werden, so modifiziert, dass Attribute, die der Identifikation von Subjekten dienen könnten, ersetzt werden (durch Pseudonyme). So können offizielle IP-Adressen beispielsweise durch für den Privatgebrauch vorgesehene IP-Adressen ersetzt werden.3

3.6.2 Verkettbarkeit und Verfolgbarkeit Verkettbarkeit bedeutet, dass Ereignisse, die in einem Zusammenhang und einer Abfolge stehen, miteinander verbunden werden können. Unverkettbarkeit (engl. Unlinkability) ist ein weiteres Schutzziel der IT-Sicherheit und das Gegenteil von Verkettbarkeit. Sie wird wie folgt definiert: Definition 3.8  Unverkettbarkeit von Subjekten, Objekten oder Aktionen [bedeutet], dass durch Beobachtungen des Szenarios die Wahrscheinlichkeit einer Relation zwischen enthaltenen Elementen unverändert bleibt [6]. Bedner und Ackermann führen an, dass die Nicht-Verfolgbarkeit (engl. Untraceability) eng mit der Unverkettbarkeit verwandt ist, sich im Gegensatz zu dieser aber nicht auf die allgemeine Möglichkeit des Verkettens, sondern auf das Nachverfolgen von Aktionen einzelner Personen bezieht.

3Diese

Pseudonymisierung wäre für Netzwerkdaten allerdings nur bedingt nützlich, da neben IPAdressen auch weitere Inhalte entfernt und ersetzt werden müssten.

3.6 Privatsphäre

99

3.6.3 Überwachung Das Schutzziel der Unbeobachtbarkeit (engl. Unobservability) ist gewährleistet, wenn sich nicht erkennen lässt, wer Daten sendet oder empfängt [6]. Wenn eine Überwachung des Verhaltens eines Subjekts auf einem IT-System möglich ist, wäre die Unbeobachtbarkeit entsprechend verletzt, ferner wäre eine Überwachung möglich. Überwachung wird, wie von Bernard ausführlich in [7] beschrieben, durch erkennungsdienstliche Technologien ermöglicht, die heute in Smartphones, Wearables und sonstigen IoT-Geräten integriert sind. Die Präzision und Durchdringung der Überwachung, die durch derlei Geräte ermöglicht wird, war noch vor einigen Jahren nur in schwerwiegenden Kriminalfällen denkbar; man denke etwa an das Aufzeichnen der Aufenthaltsorte von Personen durch eine elektronische Fußfessel oder durch mobil genutzte Apps sozialer Netzwerke [7]. In den vergangenen Jahren konnte wie in einer Schleife beobachtet werden, dass Folgendes passierte: Ein fatales Ereignis (etwa ein terroristischer Anschlag) fand statt. Die Ermittlungen ergaben oft, dass die jeweiligen Attentäter sich über soziale Netzwerke, etwa Facebook, koordinierten. Politiker forderten daraufhin das immer Gleiche: eine stärkere Überwachung des Internets durch Ermittlungsbehörden und Geheimdienste. Verwendeten Attentäter eine verschlüsselte Kommunikation, etwa WhatsApp, so verlangte die Politik zudem Hintertüren in der entsprechenden Software, sodass Geheimdienste und Polizei Auswertungen vornehmen können. Auf den ersten Blick sind derlei Forderungen verständlich, doch werfen sie, auf den zweiten Blick, große Schatten auf die Privatsphäre der Bevölkerung: • Es ist nie ausgeschlossen, dass eine Datensammlung beziehungsweise Überwachung legitimer Nutzer von sozialen Medien und des Internets an sich stattfinden wird. Bei Ansätzen wie der Vorratsdatenspeicherung ist dies praktisch unumgänglich. • Hintertüren können erstens nie perfekt geheim gehalten werden und zweitens auch durch Gegenspieler (etwa feindliche Staaten, deren Geheimdienste oder beliebige Cyberkriminelle/Cracker) gefunden und somit ausgenutzt werden. • Es ist niemals ausgeschlossen, dass ein einmal entsprechend ermächtigter Geheimdienst beziehungsweise eine Polizeibehörde eines demokratischen Staates immer unter dessen – beispielsweise parlamentarischer – Kontrolle verbleibt, und, dass das Parlament auf ewig als Kontrollorgan verbleibt. Die Möglichkeit, dass Diktatoren die Macht in demokratischen Staaten ergreifen, ergibt Szenarien wie sie durch den Nationalsozialismus im Dritten Reich oder die Stasi in der DDR reichlich bekannt wurden. • Bekanntlich tauschen kooperierende Geheimdienste Daten untereinander aus. Dieser Austausch kann grenzübergreifend geschehen. Daten legitimer Benutzer sind auf diese Weise, sobald sie einmal in der Hand ausländischer Geheimdienste sind, nicht

100

3  Grundlagen der IT-Sicherheit

mehr löschbar. So könnten exfiltrierte biometrische Daten etwa dazu verwendet werden, Identitäten von unwissenden Bürgern anzunehmen. • Aufgezeichnete Daten könnten nachträglich verwendet werden, um Personen auszumachen, die einer aktuellen politischen Führung gegenüber nicht als konform gelten, etwa Dissidenten. Wären Facebook und Co. etwa dazu gezwungen, Suchbegriffe von Benutzern zugänglich zu machen, ergäben sich Szenarien wie das vom Journalisten Charles Arthur im Guardian beschriebene [3]: The problem is this: things can be done, but they open a Pandora’s box. The British government could insist that the identities of people who search for certain terror-related words on Google or YouTube or Facebook be handed over. But then what’s to stop the Turkish government, or embassy, demanding the same about Kurdish people searching on „dangerous“ topics? Exkurs: Dumpster Diving

Der Begriff Dumpster Diving deckt sich auf den ersten Blick stark mit dem Begriff Containern: das Durchsuchen von Müll, etwa zum Auffinden von Nahrungsresten. Dumpster Diving spielt allerdings auch für die IT-Sicherheit eine Rolle. Weggeforfene Dokumente im Müll von Unternehmen können Accountnamen, IPAdressen, Informationen über verwendete Software und sonstige relevante Daten enthalten, die zur Vorbereitung auf einen IT-Angriff dienen können. Diese Phase der Angriffsvorbereitung nennt sich auch Reconnaissance. Bekannt wurde das Dumpster Diving unter anderem durch den Film Hackers (dt. Hackers – Im Netz des FBI) von 1995. Dieser Film enthält zudem weitere Hinweise auf Techniken und Literatur (etwa die Rainbow Series [36] des U.S. Department of Defense) der damaligen Hacker-Subkultur.

Die Überwachung des Datenverkehrs kann als Teilkomponente beziehungsweise als eine Grundlage der Internetzensur, also der gezielten Blockade unerwünschter Kommunikationsverbindungen, betrachtet werden. Potenziell können Staaten Individuen bewerten, wie es etwa derzeit in China umgesetzt werden soll, und auf Basis solcher Bewertungen Zensurmechanismen individualisiert anwenden. Bereits in den 90erJahren wurden in einigen Staaten umfangreiche Überwachungssysteme etabliert. Bekannt wurde insbesondere das ECHELON-Projekt, das von den USA, Großbritannien, Australien, Kanada und Neuseeland eingerichtet wurde. ECHELON überwacht(e) die internationale Satellitenkommunikation, unter anderem auch von Bayern aus [14]. Allerdings hat auch China schon vor zehn Jahren große Anstrengungen unternommen, um Überwachung und Zensur umzusetzen [5]. Durch diverse in den vergangenen zehn Jahren bekannt gewordene Überwachungssysteme, deren Möglichkeiten hochgradig ausgefeilt sind und die von gut ausgestatteten Einheiten diverser Nachrichtendienste betrieben werden, wurde klar, dass ein Großteil der international stattfindenden Kommunikation nicht nur mitgelesen werden kann, sondern auch tatsächlich mitgelesen

3.7 Schadsoftware

101

und für den späteren Bedarf gespeichert wird. Besonders stark in der Öffentlichkeit diskutierte Überwachungssysteme der vergangenen Jahre sind insbesondere TEMPORA (Großbrittanien), PRISM (USA) sowie die dritte Ausbaustufe des russischen SORM. Weitere Programme wie RAMPART-A dienen der Überwachung von Glasfaser- oder speziell Unterseekabeln. Viele der über derlei Projekte verfügbaren Informationen wurden erst durch Whistleblower, also Personen, die geheime Informationen enthüllen, bekannt, etwa Edward Snowden. Neben Überwachungsprogrammen kamen zudem diverse Skandale ans Licht, die zeigten, dass auch Politiker nicht miteinander verfeindeter Staaten, etwa die deutsche Bundeskanzlerin, überwacht wurden. Auch wurde die Vermutung bestätigt, dass diverse Staaten ihre eigenen Bürger überwachen. Dem interessierten Leser sei an dieser Stelle der Spiegel-Beitrag zu PRISM [32] sowie eine prägnante Chronik der Ereignisse bis 2016 aus der ZEIT [41] empfohlen. Überwachung kann im Übrigen auch unabsichtlich ermöglicht werden. So kann ein IoT-Gerät, etwa eine Sprachsteuerung für eine Wohnung, potenziell auch Mitbewohner oder ggf. Nachbarn, die sich im Flur eines Gebäudes aufhalten, wahrnehmen, ohne, dass diese davon erfahren. Im Falle der Sprachsteuerung wäre denkbar, dass die Stimmen der Personen sogar auf Cloudservern (u. U. im Ausland) verarbeitet werden, womit sich auch die Frage nach dem Data Ownership (Datenbesitz) stellt [10]: wem gehören die erzeugten Daten welcher Person? Derlei juristische Aspekte stehen in diesem technischen Buch nicht im Vordergrund. Sie sind aber von Bedeutung für die Schaffung legitimer Rahmenbedingungen zum Einsatz von insbesondere vernetzter Software.

3.7 Schadsoftware Schadsoftware (engl. Malware) ist Software, die vom Benutzer unerwünschte Funktionen ausführt, etwa Daten löscht, exfiltriert, einem Angreifer Zugang zu einem Rechner verschafft, einen Benutzer überwacht oder ihn erpresst. Es existieren verschiedene Arten von Schadsoftware. Schadsoftware samt Hintertüren kann sich in praktisch allen Komponenten eines Computers befinden, sei es im Mikrocode oder der Firmware von Chips, im BIOS, im Betriebssystemcode, in Treibern, in Bootsektoren von Speichermedien, oder in Programmcode. Die erste bekannte Schadsoftware namens Creeper wurde bereits 1971 bekannt und verbreitete sich über das damalige ARPANET. Zur Bereinigung der mit Creeper infizierten Systeme wurde Reaper entwickelt, das sich ebenfalls im ARPANET verbreitete und Creeper von befallenen Systemen entfernte.

3.7.1 Arten von Schadsoftware Viren weisen die Eigenschaft auf, sich zu reproduzieren. Die Reproduktion erfolgt dadurch, dass sie kontinuierlich neue Dateien suchen, die sie so modifizieren können, dass der Virus sich in diese neue Datei integriert. Beim neuen Virus handelt es sich im

102

3  Grundlagen der IT-Sicherheit

einfachsten Fall um ein exaktes Replikat des Virus, der die neue Datei infiziert hat. Die Übertragung und Infektion wird in der Regel mithilfe eines Benutzers umgesetzt. Beispielsweise könnte ein Benutzer ein mit einem Virus infiziertes Programm per E-Mail an einen anderen Benutzer senden, der das Programm auf seinem Rechner startet, womit Dateien seines Computers ebenfalls vom Virus infiziert werden. Der Virus wird dabei vom Empfänger in der Regel unbemerkt ausgeführt (es sei denn, eine böswillige Absicht unterliegt dieser Ausführung). Die sonstigen Funktionen eines Virus können beliebiger Art sein, so können etwa Dateien gelöscht oder verändert werden. Frühe Viren für MS-DOS infizierten oft Bootsektoren (von Disketten und Festplatten) oder Startskripte (insbesondere wurde die Datei autoexec.bat modifiziert), um das Hochfahren eines Rechners zu verhindern oder sonstige Aktionen während des Startvorgangs auszuführen. Ein äußerst bekannter Virus aus dem Jahr 2000 war ILOVEYOU, der sich über E-Mail-Anhänge mit dem Betreff „ILOVEYOU“ verbreitete. Die notwendige Benutzerinteraktion zur Verbreitung bestand darin, dass der Nutzer einen E-MailAnhang öffnen musste. Das Öffnen brachte wiederum ein Skript zur Ausführung. Dieses Skript enthielt den Viruscode und übernahm dessen Weiterverteilung über die E-MailKontakte eines Nutzers. Da der Virus sich allerdings selbst an weitere Systeme (Nutzer dieser Systeme) senden konnte, kann er auch als Wurm definiert werden. Würmer sind, ähnlich wie Viren, Programme, die sich replizieren. Im Gegensatz zu Viren können Würmer die Vervielfältigung selbst übernehmen, während eine von einem Virus infizierte Datei zunächst auf einen anderen Computer übertragen werden muss (etwa per USB-Stick oder E-Mail-Anhang). Würmer nutzen zur Vervielfältigung Netzwerkschnittstellen aus und infiltrieren neue Systeme dadurch, dass sie deren Verwundbarkeiten ausnutzen. Der obig erwähnte Creeper war der erste bekannte Wurm. Dieses Programm kopierte sich selbst auf andere Systeme (ohne Zutun eines Nutzers). Trojanische Pferde sind als legitime Software getarnte Schadsoftware, die nach der Installation – je nach Definition – wie ein Virus oder in einem schlicht unerwünschten Sinne arbeitet, dabei aber in der Regel universell ist, das heißt, durch den Angreifer (etwa über ein Netzwerk) steuerbar ist. Sie können zudem transitiv sein, das heißt in der Lage sein, selbst wieder eigene trojanische Pferde zu erzeugen [24]. Bei über eine Netzwerkverbindung steuerbaren trojanischen Pferden spricht man auch von Remote Access Trojanern (RATs). Eine Logic Bomb (dt. logische Bombe) ist eine Schadsoftware, die ihre schädliche Funktion nur unter bestimmten Bedingungen auslöst, etwa einem bestimmten Zeitpunkt oder infolge einer bestimmten Eingabe. Sie kann illegitimer Teil einer ansonsten legitimen erscheinenden Software sein. Eine spezielle Form von Schadsoftware, die sich nicht unbedingt replizieren können muss, ist solche, die die Ressourcen eines Systems möglichst vollständig konsumiert, um ein System unnutzbar zu machen. Eine Fork Bomb erzeugt etwa in einer Endlosschleife so viele Prozesse, dass ein Betriebssystem nur noch mit der Prozessverwaltung beschäftigt ist und nicht mehr produktiv verwendet werden kann. Die frühe

3.7 Schadsoftware

103

Schadsoftware Rabbit (1974) kopiert sich selbst so oft, bis ein System nicht mehr funktionsfähig war, weil sämtlicher Speicher beansprucht wurde. Ransomware (dt. Erpressungssoftware) infiziert einen Computer (üblicherweise über das Netzwerk) und macht die Daten des Systems unzugänglich, indem sie etwa verschlüsselt werden oder das Betriebssystem nicht gestartet werden kann. Erst wenn der Benutzer einen bestimmten Betrag (Lösegeld, engl. Ransom) zahlt, wird der Zugriff auf den Rechner – mit viel Glück – wieder freigegeben. Ein Programm, das eine Schwachstelle ausnutzt, um erweiterte Zugriffsrechte auf einem System zu erhalten oder sonstige negative Effekte zu ermöglichen, die einem Nutzer sonst verwährt blieben, wird als Exploit bezeichnet. Exploits sind oftmals Teil von anderen Schadsoftwarearten, etwa Würmern und Rootkits. Rootkits ermöglichen einen – üblicherweise hochprivilegierten – Zugriff auf ein System. Ihr Name leitet sich von root (Superuser unter Linux/Unix/BSD) und kit (Werkzeug) ab. Diesen Zugriff können Rootkits etwa in Form einer Hintertür realisieren, die verdeckt bleibt, indem Modifikationen im Kernel des Betriebssystems vorgenommen werden. So können beispielsweise Inhalte eines Verzeichnisses mit einem Exploitprogramm nicht vollständig angezeigt werden, wenn ein Angreifer den entsprechenden Syscall zum Auslesen von Verzeichnisinhalten patcht. Bei Bots handelt es sich um fernsteuerbare Schadsoftware. Werden viele gleiche Bots zu einem Netzwerk zusammengeschlossen, dann bilden sie ein sogenanntes Botnetz (engl. Botnet). Botnetze werden durch einen sogenannten Botmaster gesteuert. Ein Botmaster steuert Bots üblicherweise über eine Internetanbindung und kann Bots weltweit verteilen. Bots können von ihm etwa den Befehl erhalten, weitere Systeme zu suchen, die potenzielle Opfer darstellen, und diese Systeme anschließend zu infiltrieren. Die Infiltration von Opfern erfolgt dabei auf Basis von Exploits. Ausgefeilte Bots bekommen von ihren Entwicklern zudem die Fähigkeit, mehrere Exploits und mehrere Verwundbarkeiten gleichzeitig ausnutzen zu können, was ihre Bekämpfung erschwert [15]. Dabei wird der Bot, ähnlich wie ein Wurm, dafür sorgen, dass er auf dem jeweiligen System ein Replikat von sich installiert. Bots können sich meistens selbständig beim Botmaster melden, um ihn über eine erfolgreiche Installation auf einem neuen Opfersystem zu informieren. Die Kommunikation erfolgt dabei in der Regel verschlüsselt, teils auch mithilfe von Steganografie versteckt, über einen Kommunikationskanal, der sich Command and Control Channel (C&C Channel) nennt. Ein C&C-Channel kann Standardprotokolle wie HTTP, IRC oder FTP ausnutzen. Bots wenden dabei das sogenannte Beaconing (auch Polling genannt) an: Sie fragen periodisch eine vom Botmaster bereitgestellte Informationsressoure an, die neue Anweisungen für die Bots enthalten kann. Alternativ kann der Botmaster seine Befehle auch direkt an seine Bots senden. Ein Botnetz kann dann wiederum verwendet werden, um auf Befehl des Botmasters Angriffe durchzuführen. Verbreitet sind insbesondere Denial-of-Service-Angriffe (siehe Abschn. 6.2.7) auf entsprechende Ziele sowie das massenhafte Versenden von Spam-EMails. Oftmals vermieten Botmaster den zeit- oder ressourcenbeschränkten Zugang zu

104

3  Grundlagen der IT-Sicherheit

einem Botnetz an Auftraggeber oder führen selbst gegen Bezahlung einen Angriff auf bestimmte Ziele aus. Große Botnetze können hunderttausende Bots beinhalten. Keylogger sind Schadsoftware (manchmal in Kombination mit einer Hardwarekomponente), die Tastatureingaben aufzeichnen und in eine geheime Datei abspeichern. Der Einsatzzweck von Keyloggern kann etwa das Aufzeichnen von Passwörtern sein. Keylogger verbleiben unbemerkt am Einsatzort und können etwa in Form eines kleinen USB-Sticks oder USB-Zwischengeräts, das zwischen Tastatur und USB-Port des Computers platziert wird, vorkommen. Spyware verfolgt das Ziel, Informationen über ein System und seine Nutzer zu sammeln. Es kann sich dabei etwa um Tastatureingaben (über Keylogger) oder besuchte Webseiten, Bankdaten oder E-Mail-Kontakte handeln. Die gesammelten Daten werden wiederum an einen Masterserver gemeldet und können beispielsweise für zielgerichtete Werbeeinblendungen verwendet werden [20]. Da diverse populäre Software, etwa Browser oder Apps für Smartphones, ebenfalls Daten zum Browsingverhalten sammelt, kann diese prinzipiell auch als Spyware betrachtet werden.

3.7.2 Schadsoftware-Mechanismen Schadsoftware ist heutzutage nicht mehr nur in Form eines Programms vorliegend, das mit einem Debugger in kurzer Zeit analysiert werden kann. Stattdessen kommen Techniken für das Anti-Debugging beziehungsweise für die Anti-Forensik [12] zum Einsatz. Stellt eine Schadsoftware fest, dass sie in einem Debugger ausgeführt wird, reagiert sie anders, als wenn sie außerhalb eines Debuggers liefe. Insbesondere interessant ist Polymorphie. Polymorphie bedeutet, dass eine Schadsoftware einen Teil ihres Codes modifizieren kann. Software zur Detektion von Schadsoftware (etwa AntivirenProgramme) können somit nicht mehr auf eine statische Signatur zur Identifikation einer Schadsoftware aufsetzen. Die Software wird dabei teils verschlüsselt und entschlüsselt sich selbst zur Laufzeit, sie kann allerdings auchobfuskiert4 werden und sich zur Laufzeit deobfuskieren. Zudem kann eine Kombination aus Verschlüsselung und Obfuskation vorliegen. Etwas weiter reicht das Konzept der Metamorphie, bei der der Code (insbesondere für jede neue Version der Schadsoftware) stark modifiziert wird. Dabei kann sich der Code insbesondere selbst modifizieren und seine Größe, Struktur und Funktionsweise ändern [33]. Die Detektion metamorpher Schadsoftware ist entsprechend herausfordernd und Gegenstand aktueller Forschung. Außerdem kann Schadsoftware kryptografische Techniken, vorwiegend Verschlüsselung, einsetzen, um die Kommunikation zwischen weiteren Instanzen der Schadsoftware (bei

4Bei der Obfuskation werden im Wesentlichen Charakteristika und Semantik des Codes verschleiert, um eine Analyse zu erschweren.

3.8  IT-Sicherheit: ein Trade-off samt Vorschriften

105

Botnetzen) oder die Fernsteuerung (bei Trojanischen Pferden) geheim zu halten. Der Einsatz von Steganografie bei Schadsoftware ist ebenfalls möglich und wird derzeit von der CUING-Initiative (www.cuing.org) untersucht. Steganografie erlaubt das Verstecken des geheimen Nachrichtenaustauschs von Malware. In diesem Buch werden sowohl Kryptografie als auch Steganografie behandelt. Die Mechanismen von Schadsoftware greifen zudem zunehmend Virtualisierungssysteme und Hardwarekomponenten inklusive Firmware an, weshalb Gegenmaßnahmen auch auf all diesen Ebenen benötigt werden. Problematisch ist in dieser Hinsicht zudem, dass PC- und Laptophersteller oft Komponenten von Zulieferern verbauen, die keinerlei Firmwareupdates erhalten (können) bzw. diese nicht kryptografisch-sicher überprüfen. Somit sind derlei Komponenten auch anfälliger für Schadsoftware.

3.8 IT-Sicherheit: ein Trade-off samt Vorschriften IT-Sicherheit ist kein rein technisches Unterfangen, bezieht es doch Endnutzer, Operatoren, Angreifer und deren Organisationen, Managemententscheidungen, Entwickler, Anbieter und Organisationsabläufe ein. Collins merkt in [11] an, dass IT-Sicherheit von Benutzern akzeptiert werden muss, aber einen Trade-off darstellt. Auf der einen Seite wird in Kauf genommen, dass Performance, Funktionalität oder Benutzerfreundlichkeit durch Sicherheitsmaßnahmen reduziert werden; auch können undurchdachte Sicherheitsmaßnahmen potenziell wiederum ausgenutzt werden, um ein System anzugreifen. Außerdem entstehen Kosten und ein Mehraufwand durch den Betrieb der Sicherheitsmaßnahmen. Auf der anderen Seite erhält der Endnutzer für diese Nachteile ein höheres Maß an eben dieser Sicherheit. Dabei merkt Collins auch an, das Benutzer als kreative Elemente betrachtet werden sollten, die Lösungen zur Umgehung von Sicherheitsmechanismen finden, um sich das Arbeiten mit diesen Systemen zu erleichtern. Ein klassisches Beispiel dafür, dass vorhandene, kostenfreie Sicherheitsmaßnahmen nicht von der breiten Masse der Benutzer verwendet werden, ist sicherlich die E-MailVerschlüsselung. Jedermann kann sie mittlerweile relativ komfortabel einsetzen, doch eben nur relativ komfortabel. Außerdem funktioniert zumindest die klassische E-MailVerschlüsselung mit PGP auch nur dann, wenn sich der Empfänger ebenfalls explizit daran beteiligt, womit sich ein Henne-Ei-Problem ergibt: Sender nutzen die Verschlüsselung nicht, weil Empfänger sie nicht benutzen. Die Empfänger benutzen die Verschlüsselung wiederum nicht, weil die Sender sie nicht benutzen. Das Gebiet der benutzbaren IT-Sicherheit (engl. Usable Security) wurde in den vergangenen zehn Jahren immer stärker untersucht. Diverse Wissenschaftler befassen sich auf renommierten Tagungen mit dem oben genannten Trade-off und mit der Usable Security. Eine gute Einführung in die psychologischen Hintergründe der IT-Sicherheit findet der interessierte Leser in [2].

106

3  Grundlagen der IT-Sicherheit

Ein weiterer nicht-technischer Aspekt der IT-Sicherheit ist die Gesetzeslage. Unternehmen unterliegen gesetzlichen Vorgaben zur Sicherstellung von IT-Sicherheit, darunter fallen Themen wie das Fernmeldegeheimnis und die Bereitstellung von IT-Sicherheitsbeauftragten. Außerdem dürfen nicht einfach Angriffe auf fremde IT-Systeme durchgeführt werden. Ein damit verbundener Bereich sind Gegenangriffe – auch wenn ein Netzwerk von außen attackiert wird, darf ein Angreifer nicht einfach mit einem Gegenangriff von seinem Angriff abgehalten werden. Dies mag auf den ersten Blick verwundern, doch lässt sich leicht zeigen, weshalb Gegenangriffe eine schlechte Idee sind: Viele Angreifer verschleiern ihre tatsächliche Herkunft (IP-Adresse), indem sie gehackte Systeme ausnutzen. Oftmals sitzen die Angreifer sogar in anderen Ländern als die von ihnen ausgenutzten Hosts. Auch die oben genannten Botnetze fallen unter dieses Szenario. Ein Gegenangriff auf Bots würde die Systeme unwissender Dritter betreffen. Weiterhin ist aus juristischer Perspektive anzumerken, dass die Gesetzeslage je nach Land unterschiedlich ist und Datenverarbeitung oft international abgewickelt wird. In solchen Fällen müssen von den jeweiligen Unternehmen mehrere jeweils nationale Gesetzeslagen beachtet werden. In Konsequenz heißt dies, dass auch Software gemäß länderspezifischer Datenschutzvorgaben arbeiten muss.

3.9 Science of Security Mit der IT-Sicherheit als Wissenschaft kann man sich auch auf einer Metaebene befassen: Science of Security, zu deutsch etwa „Wissenschaft über die Sicherheitswissenschaft“, befasst sich mit den wissenschaftlichen Grundlagen der IT-Sicherheit [16]. Dies bezieht wissenschaftstheoretische wie wissenschaftspraktische Fragestellungen ein. In der Science of Security werden Fragen danach gestellt und versucht zu beantworten, wie überhaupt Erkenntnisse im Sicherheitsbereich gewonnen werden können. Hinsichtlich der theoretischen Aspekte wird insbesondere auf der philosophischen Erkenntnistheorie aufgebaut. Hinsichtlich der praktischen Erkenntnisse wird hingegen insbesondere auf den Naturwissenschaften aufgebaut. Ich möchte das Thema an dieser Stelle anhand einiger eigener Arbeiten illustrieren. Zunächst stellten wir vor einigen Jahren fest, dass es im Bereich der Steganografie in Netzwerken eine uneinheitliche Terminologie und Taxonomie gibt, die wir in einigen Publikationen, insbesondere in [39], bereinigt haben (siehe Abschn. 9.2.2). Befasst man sich nur intensiv genug mit der Terminologie oder Taxonomie in einem Bereich, dann wird man sicherlich auch in anderen Bereichen Ungereimtheiten finden. Eine uneinheitliche Terminologie und Taxonomie bremst den Erkenntnisgewinn des jeweiligen Wissenschaftsgebiets aus, führt zu Re-Inventions (Neuerfindungen bereits bestehender Dinge, teils unter Verwendung anderer Begriffe) und erschwert zudem den Einstieg in eine Forschungsdomäne. Zu viele Versuche, die Terminologie und Taxonomie zu vereinheit-

3.10 Zusammenfassung

107

lichen, können sich allerdings auch wieder negativ auf die Zugänglichkeit einer Domäne auswirken. Einen „Wildwuchs“ an Begrifflichkeiten gilt es daher zu vermeiden. Ein weiteres Thema der Science of Security ist die Beschreibung von wissenschaftlichen Methoden. So sind gleichartige Methoden immer wieder unterschiedlich beschrieben worden. Dies erschwert die Vergleichbarkeit von diesen Methoden. Wir haben in [40] beispielsweise eine Grundlage für eine einheitliche Beschreibung von Versteckmethoden aus der Steganografie gelegt. Science of Security befasst sich zudem damit, wie Gutachterverfahren ablaufen sollten. In der Wissenschaft sind diese in der Regel double blind gehalten, das heißt, die Autoren eines Aufsatzes wissen nicht, wer die Menschen sind, die ihren Aufsatz beurteilen. Gleichzeitig wissen die Gutachter nicht, wer die Autoren des Aufsatzes sind, den sie beurteilen sollen. Hierzu werden Aufsätze anonym eingereicht. Außerdem werden Gutachterprozesse von vertrauenswürdigen Dritten koordiniert – in der Regel die Organisatoren einer akademischen Tagung, die Editoren eines Buches oder einer (Ausgabe einer) Fachzeitschrift. Über die Qualitäts- und Gütekriterien der Beurteilung lässt sich trefflich debattieren. Ein ebenfalls bedeutsamer Gegenstand von Science of Security sind wissenschaftliche Experimente. Wie sollten Experimente in der IT-Sicherheit konzipiert, durchgeführt, beurteilt und beschrieben werden? In den Naturwissenschaften ist die Replizierbarkeit von Experimenten von fundamentaler Bedeutung. Die Reproduzierbarkeit kann in der IT-Sicherheit manchmal mit der Publikation von Quellcode ermöglicht werden. Oftmals werden allerdings auch die im Experiment verwendeten Daten (etwa Aufzeichnung von Netzwerkverkehr) benötigt, um Experimente tatsächlich reproduzieren zu können. Auch hier kann die Netzwerksteganografie als Beispiel dienen. In [19] haben wir ein Testbed entwickelt, dass der internationalen wissenschaftlichen Community zugänglich ist, um Experimente durchzuführen und in einer einheitlichen Umgebung zu reproduzieren.

3.10 Zusammenfassung IT-Sicherheit ist ein umfassendes Themengebiet und von „der“ IT-Sicherheit eines Systems zu sprechen ist relativ unpräzise. Stattdessen sollte unterschieden werden, von welchem Schutzziel (etwa Vertraulichkeit oder Verfügbarkeit) gesprochen wird. Es gibt verschiedene Ansätze, IT-Sicherheit zu gewährleisten, etwa Authentifizierung und Autorisierung, von denen die Grundkonzepte in diesem Kapitel behandelt wurden. Von zentraler Bedeutung – insbesondere im heutigen Internet und dem Internet der Dinge – ist auch die Privatspähre. Das Ende des Kapitels lieferte einen Blick auf die verschiedenen Arten von Schadsoftware und besprach IT-Sicherheit im Kontext eines Tradeoffs – IT-Sicherheit kostet schließlich etwas, beispielsweise Benutzerfreundlichkeit oder Performance. Das Gebiet der Science of Security befasst sich mit den wissenschaftlichen Grundlagen der IT-Sicherheit.

108

3  Grundlagen der IT-Sicherheit

3.11 Weiterführende Literatur Eine ausführliche Einführung in das Themengebiet der allgemeinen IT-Sicherheit bieten unter anderem Bishop [8] und Eckert [13]. Eine weitere Einführung, allerdings in das umfassende Thema Security Engineering, bietet das Werk von Anderson [2]. Anderson betrachtet dabei auch nicht-technische Aspekte (etwa Benutzbarkeit) und Anwendungsfelder (Banking, Telekommunikation). Bedner und Ackermann liefern in [6] eine wertvolle Zusammenfassung der Definition verschiedener Schutzziele, inklusive weiterführender Schutzziele, die in diesem Kapitel nicht betrachtet wurden. Für an der Hackerkultur interessierte Leser empfiehlt sich die Lektüre von Things Every Hacker Once Knew [29] sowie [17, 22, 28]. Empfehlenswert ist zudem das von Akhgar et al. herausgegebene Werk Cyber Crime and Cyber Terrorism Investigator’s Handbook [1], das sich mit der Cyberkriminalität, insbesondere aus Sicht von Ermittlungsbehörden, befasst.

3.12 Übungsaufgaben 1. Erläutern Sie den Unterschied zwischen dem Schutzziel Verfügbarkeit und Vertraulichkeit. 2. Was versteht man unter Integrität? 3. Was ist der Unterschied zwischen einer Schwachstelle und einer Verwundbarkeit? 4. Nennen Sie ein Beispiel dafür, dass aus einer Schwachstelle eine Verwundbarkeit und aus dieser wiederum eine Bedrohung werden kann. 5. Worin besteht der Unterschied zwischen Discretionary Access Control (DAC) und Mandatory Access Control (MAC)? 6. Welche typischen Sicherheitslevels (Geheimhaltungsstufen) gibt es in der BRD? 7. In Abschn. 3.4.3.1 wurde ein Beispiel für das BLP-Modell eingeführt. Bekäme Alice (secret, {accounting,research}) lesenden beziehungsweise schreibenden Zugriff auf Databasex, wenn gelten würde, dass (L,C) für Databasex auf (confidential, {research}) gesetzt wäre? 8. Nennen Sie mindestens drei Möglichkeiten, um eine Authentifizierung umzusetzen. 9. Recherchieren Sie, welche Fähigkeiten die Projekte TEMPORA und PRISM aufweisen. Nutzen Sie dazu insbesondere die Quellen [32] und [41]. 10. Recherchieren Sie die Funktionsweise von CAPTCHAs. Was verbirgt sich dahinter? Dienen CAPTCHAS der Authentifizierung oder dem Zugriffsschutz? 11. Was bedeutet es, wenn ein Trojanisches Pferd universell und transitiv ist? 12. Was wird unter einer Logic Bomb und was unter Ransomware verstanden? 13. Was versteht man bei Botnetzen unter dem Begriff Polling (Beaconing)? 14. Wozu dient der C&C-Channel bei Botnetzen und wofür werden Botnetze typischerweise eingesetzt? 15. Erläutern Sie den Unterschied zwischen Polymorphie und Metamorphie bei Schadsoftware.

Literatur

109

Literatur 1. Akhgar, B., Staniforth, A., Bosco, F. (Hrsg.): Cyber crime and cyber terrorism investigator’s handbook. Syngress, Waltham (2014) 2. Anderson, R.: Security engineering, 2. Aufl. Wiley, Indianapolis (2008) 3. Arthur, C.: ,Blame the internet‘ is just not a good enough response, Theresa May, erschienen In: The Guardian, 4. Juni 2017 4. Australian Anthill: (Borrett, L.): Hackers, Crackers, Script-Kiddies, Cyber-Spies: Can you spot the bad guy? (2010). http://anthillonline.com/hackers-crackers-script-kiddies-cyber-spiescan-you-spot-the-bad-guy/. Zugegriffen: 18. Jan. 2021 5. Becker, K.-B.: Internetzensur in China. Aufbau und Grenzen des chinesischen Kontrollsystems. Vieweg-Springer Research (2011) 6. Bedner, M., Ackermann, T.: Schutzziele der IT-Sicherheit. Datenschutz und DatensicherheitDuD 34(5), 323–328 (2010). Springer 7. Bernard, A.: Komplizen des Erkennungsdienstes. Das Selbst in der digitalen Kultur, Fischer (2017) 8. Bishop, M.: Computer security. Art and science. Addison Wesley, Boston (2003) 9. Brenner, W., Broy, M., Leimeister, J.M.: Auf dem Weg zu einer Informatik neuer Prägung in Wissenschaft, Studium und Wirtschaft. In: Informatik Spektrum, Bd. 40(6), S. 602–606. Springer, Berlin/Heidelberg (2017) 10. Camp, J., Henry, R., Kohno, T. et al.: Towards a secure internet of things: directions for research, IEEE security & privacy, July/August 2020, 28–37, IEEE (2020) 11. Collins, M.: Network Security Through Data Analysis, 2. Aufl. O’Reilly, Beijing (2017) 12. Day, D.: Seizing, imaging, and analyzing digital evidence: step-by-step guidelines. In: Akhgar, B., Staniforth, A., Bosco, F. (Hrsg.) Cyber Crime and Cyber Terrorism Investigator’s Handbook. Syngress, Waltham (2014) 13. Eckert, C.: IT-Sicherheit, 9. Aufl. De Gruyter, München (2014) 14. Federrath, H.: Überwachung in einer vernetzten Welt: Das Ende der Privatheit? In: Blick in die Wissenschaft – Forschungsmagazin der Universität Regensburg, Bd. 19, S. 18–24 (2007) 15. FortiGuard SE Team: Swarming IoT Attacks, Cryptojacking, and Ransomware Drive Dramatic Spike in Malware (2018). https://blog.fortinet.com/2018/02/20/swarming-iotbotnets-cryptojacking-and-ransomware-drive-dramatic-spike-in-malware. Zugegriffen: 18. Jan. 2021 16. Herley, C., van Oorschot, P.C.: Sok: Science, security and the elusive goal of security as a scientific pursuit. In: Proceedings of IEEE Symposium on Security and Privacy (S&P), S. 99–120. IEEE (2017) 17. Himane, P.: Die Hacker-Ethik und der Geist des Informations-Zeitalters. Riemann Verlag, München (2001) 18. Hughes, E.: A Cypherpunk’s Manifesto (1993). 19. Keidel, R., Wendzel, S., Zillien, S., Conner, E.S., Haas, G.: WoDiCoF – a testbed for the evaluation of (parallel) covert channel detection algorithms. J. Univers. Comput. Sci. (J.UCS) 24(5), 556–576 (2018) 20. Kirda, E., Kruegel, C., Banks, G., Vigna, G., Kemmerer, R.A.: Behavior-based Spyware Detection. In: Proceedings of 15th USENIX Security Symposium, S. 273–288 (2006) 21. Kühle, C.P., Lange, B., Pacholski, S.: Alternative Risikoformel für den Bereich IT-Sicherheit, Diskussionspapier. In: Proceedings of 2. Workshop IT-Sicherheitsmanagement, FHTW Berlin (2008). http://wi.f4.htw-berlin.de/users/messer/LV/Globals/ISM-Workshops/Workshop-SS08/ IT-Risiko-Bewertung.pdf. Zugegriffen: 18. Jan. 2021 22. Moody, G.: Die Software-Rebellen. Mi-Wirtschaftsbuch (2001)

110

3  Grundlagen der IT-Sicherheit

23. Office of Strategic Services (OSS)/W.J. Donovan: Simple Sabotage Field Manual, Strategic Services Field Manual No. 3 (1944). 24. Pfitzmann, A.: Datensicherheit und Kryptographie, Skript aus dem WS2000/2001, TU Dresden (2000) 25. Pfitzmann, A., Köhntopp, M.: Anonymity, unobservability, and pseudonymity – a proposal for terminology. In: Designing Privacy Enhancing Technologies, S. 1–9. Springer, Berlin/Heidelberg (2001) 26. Plötner, J., Wendzel, S.: Praxisbuch Netzwerksicherheit, 2. Aufl. Galileo Press, Bonn (2007) 27. Rannenberg, K., Pfitzmann, A., Müller, G.: Sicherheit, insbesondere mehrseitige IT-Sicherheit, it-Information Technology 38(4), S. 7–10 (1996) 28. Raymond, E.S.: How To Become A Hacker (2011) (aktuelle Version von 2017). http://catb. org/~esr/faqs/hacker-howto.html. Zugegriffen: 18. Jan. 2021 29. Raymond, E.S.: Things Every Hacker Once Knew (2017). http://www.catb.org/~esr/faqs/ things-every-hacker-once-knew/. Zugegriffen: 18. Jan. 2021 30. Schlegel, M.: Analyse und Simulation dynamischer RBAC-Zugriffssteuerungsmodelle. In: Proceedings of D-A-CH Security 2015, syssec (2015) 31. Shepherd, C., Petitcolas, F.A.P., Akram, R.N., Markantonakis, K., Fischer-Hübner, S., Lambrinoudakis, C.: An exploratory analysis of the security risks of the internet of things in finance. In: Proceedings of Trust, Privacy and Security in Digital Business (TrustBus), Lyon, S. 164–179. Springer International Publishing (2017) 32. Spiegel Online (Kremp, M., Lischka, K., Reißmann, O.: Projekt Prism US-Geheimdienst späht weltweit Internetnutzer aus (2013). http://www.spiegel.de/netzwelt/netzpolitik/projektprism-nsa-spioniert-weltweit-internet-nutzer-aus-a-904330.html. Zugegriffen: 18. Jan. 2021 33. Ször, P., Ferrie, P.: Hunting for metamorphic, Virus Bulletin Conference, S. 123–144 (2001). http://crypto.stanford.edu/cs155old/cs155-spring10/papers/viruses.pdf. Zugegriffen: 18. Jan. 2021 34. Torvalds, L., Diamond, D.: Just For Fun. Wie ein Freak die Computerwelt revolutionierte, Hanser Fachbuch (2001) 35. Trepte, S., Dienlin, T.: Privatsphäre im Internet. In: Porsch, T., Pieschl, S. (Hrsg.) Neue Medien und deren Schatten. Mediennutzung, Medienwirkung und Medienkompetenz, S. 53–79. Hogrefe (2014) 36. U.S. Department of Defense: Rainbow Book Series (1988–1995). https://fas.org/irp/nsa/ rainbow.htm. Zugegriffen: 18. Jan. 2021 37. Wendzel, S.: Novel approaches for network covert storage channels. Dissertation, FernUniversität in Hagen (2013) 38. Wendzel, S., Plötner, J.: Einstieg in Linux, 8. Aufl. Rheinwerk Verlag (2019) 39. Wendzel, S., Zander, S., Fechner, B., Herdin, C.: Pattern-based survey and categorization of network covert channel techniques, Computing Surveys (CSUR), Bd. 47(3). ACM (2015) 40. Wendzel, S., Mazurczyk, W., Zander, S.: Unified description for network information hiding methods. J. Univer. Comput. Sci. (JUCS) 22(11), 1456–1486 (2016) 41. ZEIT Online (Beuth, P.): Snowden-Enthüllungen: Alles Wichtige zum NSA-Skandal (2016). http://www.zeit.de/digital/datenschutz/2013-10/hintergrund-nsa-skandal. Zugegriffen: 18. Jan. 2021

Teil II Kryptografie

Der erste Teil dieses Buches führte in die Grundlagen der Netzwerktechnik und in zentrale Begriffe und Konzepte der IT-Sicherheit ein. Der zweite Teil baut auf diesem Wissen auf und erläutert zunächst zentrale Fundamente der Kryptografie. Im Anschluss werden anwendungsnahe Gebiete der Kryptografie, etwa Public-Key-Infrastruktur (PKI) und Virtuelle Private Netzwerke (VPN), besprochen.

4

Einführung in die Kryptografie

Cryptography is fascinating because of the close ties it forges between theory and practice, and because today’s practical applications of cryptography are pervasive and critical components of our information-based society. – Ron Rivest (1997) Zusammenfassung

Dieses Kapitel stellt eine Einführung in die Kryptografie dar. Es behandelt Grundbegriffe sowie historische Verfahren (Caesar, Vigenère, Vernam) und deren Kryptoanalyse (Friedman-Angriff und Kasiski-Test). Anschließend vermittelt es die Funktionsweise bedeutsamer Strom- und Blockchiffren ((3)DES und AES) sowie die Grundlagen von Zufallszahlengeneratoren und Hashfunktionen. Es führt ferner in informationstheoretische Grundlagen ein und befasst sich mit asymmetrischen Verfahren (Schlüsselaustausch über einen unsicheren Kommunikationskanal sowie RSA).

4.1 Einführung und Grundbegriffe Zunächst einmal muss geklärt werden, was sich hinter dem Begriff Kryptografie verbirgt. Der Begriff stammt aus dem Griechischen: kryptós (verborgen) und gráphein (schreiben). In den weit verbreiteten Büchern finden sich einige Definitionen des Begriffs: • Spitz et al. definieren Kryptografie als die Wissenschaft der Verschlüsselung von Informationen durch Geheimschriften beziehungsweise Chiffren [28]. Rivest verfasste das Vorwort zum Buch Handbook of Applied Cryptography von Menezes et al., dem das Eingangszitat entnommen wurde. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-33423-9_4

113

114

4  Einführung in die Kryptografie

• Beutelspacher et  al. schreiben hingegen, die Kryptografie ist eine öffentliche mathematische Wissenschaft, in der Vertrauen geschaffen, übertragen und erhalten wird [6]. • Bishop schreibt in seinem Werk Computer Security. Art and Science: Cryptography is a deep mathematical subject […] it is the art and science of concealing meaning [7]. In diesem Buch wird nicht streng zwischen Kryptografie und Kryptologie unterschieden. Jedoch umfasst Kyptologie letztlich die Kryptografie (Entwurf von kryptografischen Verfahren) und die Kryptoanalyse (Analyse von kryptografischen Verfahren) [6]. Dieses Kapitel betrachtet beide Teilaspekte der Kryptologie, die Kryptografie und die Kryptoanalyse. Ohne Kryptoanalyse können Sie Kryptografie nicht bewerten und verstehen, da Sie ohne kritische Betrachtung von Verschlüsselungsverfahren gar nicht wüssten, wie gut ein solches Verfahren überhaupt ist. Einsatzgebiete der Kryptografie

Die Einsatzgebiete der Kryptografie sind zahlreich. Hier einige Beispiele: • Verschlüsselung von Browsing-Aktivitäten und Downloads (HTTPS, SFTP, …) • Schutz von Integrität und Vertraulichkeit im Rahmen von eCommerce und Online-Banking • E-Mail-Verschlüsselung und Signatur von E-Mails • Verschlüsselung von Audio- und Videoübertragungen • Verschlüsselung von lokalen Dateien • Verschlüsselung des Datenverkehrs zwischen Liegenschaften eines Unternehmens, um Wirtschaftsspionage zu erschweren • Schaffung von Anonymität • Umsetzen von nicht abstreitbaren Transaktionen jedweder Art • Realisierung elektronischer Währungen (etwa Bitcoin) • Sicherung von eGovernment-Diensten • Umsetzung von Smart Contracts (auf Blockchain-Basis)

Kryptografie ist ein sogenanntes Dual-use Good. Es kann für „gutartige“ Zwecke verwendet und für „bösartige“ Zwecke missbraucht werden. Hier einige Beispiele für bösartige Einsatzgebiete der Kryptografie: • Verschlüsselung von Daten auf einer Festplatte durch einen Erpressungstrojaner. • Verschlüsselung des E-Mail-Verkehrs eines Terroristen zum Schutz vor einem Lauschangriff. Laut einem gemeinsamen Bericht des Europol European Cyber-crime Centers (EC3) und Eurojust wird Kryptographie zunehmend von Kriminellen verwendet [11]. Dies hat zwei Gründe:

4.1  Einführung und Grundbegriffe

115

1. Die Kriminellen von heute sind mit IT-Technologie aufgewachsen. 2. Verschlüsselungstechnologien sind heute deutlich einfacher einsetzbar, als noch vor wenigen Jahrzehnten. Europol EC3’s Decryption Platform wurde bereits für mehrere Kriminalfälle zur Dechiffrierung eingesetzt, unter anderem in den Bereichen Cybercrime, Missbrauch von Kindern, Kreditkartenbetrug, Waffenschmuggel, Drogenschmuggel, Geldwäsche, Terrorismus und Schleuser-Kriminalität (Migranten). Basierend auf diesen Szenarien stellen sich Fragen wie diese: Sollte Kryptografie nicht einfach verboten werden, damit Terroristen sie nicht missbrauchen, um Anschläge zu planen? Tatsächlich gibt es politische Bestrebungen in verschiedenen Ländern dieser Welt, um Kryptografie entweder zu verbieten oder ihren Einsatz zu limitieren. Dabei geht es insbesondere um den bösartigen Einsatz der Kryptografie. Die Unterscheidung zwischen „gutartig“ und „bösartig“ hängt hierbei maßgeblich vom Betrachter ab. Bei Kriegsparteien dürfte die jeweils andere Seite wohl unter den Bereich „bösartige“, die eigene Seite unter den Bereich „gutartige“ Verwendung der Kryptografie fallen. Darüber hinaus dürfte ein Verbot von Kryptografie bei Angreifern mit ernsten Absichten nur wenig bezwecken, da die Verwendung von Kryptografie nur sehr begrenzt kontrolliert werden kann, insbesondere bei sicherheitsaffinen Benutzern. Exkurs: Crypto Wars?

Laut Wikipedia handelt es sich bei Crypto Wars um an unofficial name for the U.S. and allied governments’ attempts to limit the public’s and foreign nations’ access to cryptography strong enough to resist decryption by national intelligence agencies (especially USA’s NSA). Dieser Satz kann mittlerweile sicherlich nicht mehr ausschließlich auf die USA und ihre Verbündeten beschränkt werden. Crypto Wars gibt es weltweit, etwa auch in China. Der erste bekannte Crypto War fand 1975 zwischen den beiden Kryptologen Diffie und Hellman auf der einen und dem National Buero of Standards (NBS, jetzt NIST) sowie der NSA auf der anderen Seite statt. Dabei ging es um die Schlüssellänge von DES, die Diffie und Hellman als zu kurz erachteten, sowie später um die Veröffentlichung des Diffie-Hellman-Schlüsselaustauschverfahrens [15]. Als Leseempfehlung für das Thema Crypto Wars sei auf eine Publikation von Baranetsky [4] sowie auf einen Vortrag von Opsahl mit dem Titel Crypto Wars Part II – The Empires Strike Back verwiesen, der im Rahmen des Chaos Communication Congress 2015 (32C3) stattfand. Dieser Vortrag ist kostenfrei unter der Adresse https://media.ccc.de/b/congress/2015 abrufbar.

116

4  Einführung in die Kryptografie

4.2 Grundlegende Begriffe Zunächst müssen einige Grundbegriffe betrachtet werden. Diesen Abschnitt können Sie optional überspringen, und im späteren Verlauf des Kapitels immer dann hierhin zurückblättern, wenn Ihnen einer der Begriffe unklar erscheint.

4.2.1 Verschlüsselung und Entschlüsselung als Abbildungen Es gibt eine Menge aller Klartexte M und eine Menge aller Chiffretexte C. Eine geheime Nachricht m ∈ M wird bei einer Verschlüsselung in eine chiffrierte Nachricht c ∈ C überführt: f : M → C, m ∈ M, c ∈ C. Bei der Entschlüsselung hingegen wird die Umkehrfunktion benötigt: f−1 : C → M, c ∈ C, m ∈ M. Das heißt, f muss eindeutig umkehrbar sein (bijektiv, s. Box), sodass zu einem gegebenen Chiffretext der ursprüngliche Klartext zugeordnet wird, c = f(f−1(c)) und m = f−1(f(m)). Es gilt |C| = |M|. Exkurs: surjektive, injektive und bijektive Abbildungen

Gegenstand der Betrachtung ist eine Abbildung f : A → B, das heißt eine Abbildung, die einem Element einer Menge A (Definitionsbereich) ein Element der Menge B (Wertebereich) zuweist. f ist surjektiv, wenn y = f(x) für jedes y ∈ B mindestens eine Lösung x ∈ A besitzt, wenn also ∀y ∈ B gilt ∃ x ∈ A : y = f(x). f ist injektiv, wenn y = f(x) für jedes y ∈ B kein oder genau eine x ∈ A besitzt, wenn also ∀x1, x2 ∈ A : f(x1) = f(x2) ⇒ x1 = x2. f heißt bijektiv, falls f injektiv und surjektiv ist.

4.2.2 Kryptografische Schlüssel Kryptografische Algorithmen sind in der Regel publiziert (mit wenigen Ausnahmen, etwa aus dem Bereich der geheimen Datenverarbeitung1). Mit Kenntnis eines Algorithmus wäre somit jede Ver- und Entschlüsselung von Nachrichten möglich. Daraus ergibt sich die Notwendigkeit einer geheimen Zusatzinformation, dem kryptografischen Schlüssel, der für Ver- und Entschlüsselung verwendet wird.

1Der

Libelle-Algorithmus, https://de.wikipedia.org/wiki/Libelle_(Kryptografie), ist beispielsweise vom BSI für den Schutz von Verschlusssachen (VS) der Sicherheitsstufe „streng geheim“ zugelassen.

4.2  Grundlegende Begriffe

117

 Prinzip von Kerckhoffs  Das Prinzip von Kerckhoffs besagt, dass die Sicherheit eines kryptografischen Algorithmus’ nicht im Geheimhalten des Algorithmus, sondern nur im Geheimhalten des Schlüssels liegen sollte. Durch Befolgung des Prinzips werden Analysen (Bewertungen und sich daraus ergebene Verbesserungen) von Algorithmen durch die wissenschaftliche Community möglich. Außerdem ist es extrem schwierig, einen Algorithmus auf Dauer und bei wechselnden Personenkreisen (Mitarbeiter kündigen, neue werden eingestellt) tatsächlich geheim zu halten. Algorithmen müssen oft durch verschiedene Bündnispartner/Unternehmen implementiert werden, womit sich die Kenntnis des Algorithmus verteilt. Die Algorithmen A5 (anonymer Hinweis) und Comp128 (Reverse Engineering) konnten beispielsweise nicht geheim gehalten werden [6]. Außerdem gelten Algorithmen, die nicht durch möglichst viele anerkannte Wissenschaftler analysiert wurden, als unsicher. Aus diesem Grund werden auch geheime Algorithmen eher als unsicher betrachtet. Der kryptografische Schlüssel k wird aus einer Menge möglicher Schlüssel K selektiert. Er wird für Ver- und Entschlüsselung neben c und m benötigt: ..

Verschlusselung ..

Entschlusselung

c = f (k, m) = fk (m)

(4.1)

m = f −1 (k, c) = fk−1 (c)

(4.2)

Sie werden bei der Auseinandersetzung mit asymmetrischer Kryptografie sehen, dass für die Ver- und Entschlüsselung nicht notwendigerweise derselbe Schlüssel verwendet werden muss. Exkurs: Benutzergemeinde

Spitz et al. verweisen auf das Szenario der Benutzergemeinde [28]. Dabei gibt es eine Gruppe mit N Teilnehmern. Es soll dabei je eine mit einem separaten Schlüssel gesicherte Kommunikation zwischen allen Teilnehmern möglich sein. Damit stellt sich die Frage   nach der Anzahl benötigter Schlüssel. Tatsächlich werden für diesen Fall N2 = N·(N−1) Schlüssel benötigt [28] (dies ergibt sich aus 2 (N − 1) + (N − 2) + ...(N − N + 1)).

4.2.3 Kryptosysteme Nachdem Sie nun kryptografische Schlüssel kennen, können Sie die grundlegende Struktur kryptografischer Verfahren verstehen. Ein Kryptosystem ist gemäß Bishop [7] ein 5-er-Tupel: (E, D, M, K, C), mit M (Menge der Klartexte), K (Menge der Schlüssel), C (Menge der Chiffretexte), E : M × K → C (die Menge der Verschlüsselungsfunktionen) und D : C × K → M (die Menge der Entschlüsselungsfunktionen).

118

4  Einführung in die Kryptografie

4.2.4 Symmetrische und Asymmetrische Kryptografie Es gibt zwei Möglichkeiten für die Verwendung von Schlüsseln: Symmetrische Algorithmen: Sie verwenden zum Verschlüsseln und Entschlüsseln denselben Schlüssel k. Die (je nach Anzahl der Teilnehmer sehr vielen) Schlüssel müssen geheim gehalten werden. Asymmetrische Algorithmen: Sie verwenden zum Verschlüsseln einen öffentlichen Schlüssel (engl. Public Key) kpub und zum Entschlüsseln einen zugehörigen privaten Schlüssel (engl. Private Key) kpriv. Nur die privaten Schlüssel müssen geheim gehalten werden. Öffentliche Schlüssel können in Datenbanken/Verzeichnissen abgelegt werden. Entsprechend müssen die Funktionen zur Ver- und Entschlüsselung mit dem jeweiligen Schlüssel arbeiten: c = E(kpub, m) = Epub(m) und m = D(kpriv, c) = Dpriv(c), wobei E die Funktion zum Verschlüsseln (engl. Encrypt) und D die Funktion zum Entschlüsseln (engl. Decrypt) darstellen. Benötigt werden N Schlüsselpaare (kpub, kpriv) für N Teilnehmer.

4.2.5 Grundlegendes Angreifermodell Im Laufe des Buches wird immer wieder von folgendem Angreifermodell die Rede sein. Hierbei nutzen Alice und Bob die Kryptografie für eine sichere Kommunikation zwischen ihnen und Mallory wird versuchen, sie entweder daran zu hindern oder ihre Geheimnisse in Erfahrung zu bringen. Hierbei ist zu beachten, dass die Namen Alice, Bob und Mallory sowie einige weitere Namen, standardmäßig in der IT-Sicherheitsliteratur verwendet werden (Abb. 4.1). Ein Kryptoanalytiker geht davon aus, dass Mallory folgende Komponenten des Kryptosystems in jedem Fall kennt: D und E. Es ergeben sich dadurch unter anderem folgende Angriffe [12]: • Ciphertext-only-Angriff: Der Angreifer kennt einzelne Chiffretexte. Er versucht, zugehörige Klartexte beziehungsweise zunächst den verwendeten Schlüssel zu finden. • Known-plaintext-Angriff: Der Angreifer kennt einige Chiffretexte und zugehörige Klartexte. Er versucht den zugehörigen Schlüssel zu finden.

Abb. 4.1   Grundlegendes Angreifermodell mit den typischen Mitspielern

4.3  Historische Verfahren

119

• Chosen-plaintext-Angriff: Der Angreifer kann einige Klartexte selbst wählen und verschlüsseln lassen (etwa durch unbemerktes Unterschieben der Klartexte an Alice). Er erhält die zugehörigen Chiffretexte und möchte k finden. • Chosen-ciphertext-and-plaintext-Angriff:2 Der Angreiferkann Klartext verschlüsseln und erhält für diese Daten den Chiffretext. Sowohl Klartext als auch Chiffretext kann der Angreifer dabei selbst wählen. Außerdem kann der Angreifer Chiffretext entschlüsseln und erhält den zugehörigen Klartext. Er sucht den verwendeten Schlüssel. Weitere Angriffe existieren, sind aber im Rahmen dieses einführenden Kapitels nicht relevant.

4.3 HistorischeVerfahren Historische Chiffren sind insbesondere monoalphabetische Chiffren. Solche Chiffren verwenden nur ein einziges Schlüsselalphabet zur Ver- und Entschlüsselung. Polyalphabetische Chiffren können ebenfalls zu den historischen Chiffren gezählt werden, verwenden allerdings mehrere Schlüsselalphabete. Im Folgenden werden selektierte historische Verfahren betrachtet.

4.3.1 Transpositionschiffre Eine einfache Variante einer monoalphabetischen Chiffre und zugleich die älteste bekannte militärische Chiffre [17] ist die Skytale: Sender und Empfänger benötigen einen Stab gleichen Durchmessers. Sie wickeln ein Band aus Papyrus oder Leder um diesen Stab [17]; und zwar so, dass das Band sich nicht überlappt und keine freie Fläche zwischen dem Band entsteht. Der Sender beschreibt das Band zeilenweise. Anschließend wird das Band vom Stab entfernt und die darauf enthaltenen Buchstaben erscheinen unsortiert. Der Empfänger nimmt das Band entgegen und wickelt es auf die zuvor beschriebene Weise auf einen gleichen Stab. Somit wird auch dem Empfänger die geheime Nachricht ersichtlich. Es handelt sich bei der Skytale um eine Transpositionschiffre (oder: Permutationschiffre): Die Symbole des Klartexts werden verschoben, um den Chiffretext zu erzeugen. Der für eine Transpositionschiffre verwendete Schlüsselist eine Permutationsfunktion, die Auftrittswahrscheinlichkeit von Klartextbuchstaben bleibt daher unverändert und Symbole des Klartexts werden nicht durch andere Symbole ersetzt [7]. Aus „KATZE“ könnte beispielsweise „EZKTA“ werden, jedoch niemals „Q9$i%“.

2Eigentlich

heißt dieser Angriff Chosen-ciphertext-Angriff, doch weisen Ferguson et al. darauf hin, dass die oben genannte Bezeichnung passender ist [12].

120

4  Einführung in die Kryptografie

Abb. 4.2   Caesar-Chiffe mit k = 3

4.3.2 Die Caesar-Chiffre Bei Verschiebechiffren werden die Zeichen des Klartexts zyklisch verschoben. Eine äußerst bekannte Variante solcher Verschiebechiffren ist die monoalphabetische und einfach zu verstehende Caesar-Chiffre. Sie wurde nach Julius Caesar benannt, der diese Chiffre tatsächlich angewandt haben soll. Bei der Caesar-Chiffre werden Texte des lateinischen Alphabets um einen Wert k verschoben, um zu verschlüsseln.3 Eine Verschiebung um − k beziehungsweise 26 − k dechiffriert. Bei k = 3 würde aus ‚A‘ beispielsweise ‚D‘ werden (Abb. 4.2). Die Ver- und Entschlüsselungsfunktionen können mithilfe modularer Arithmetik beschrieben werden: • Verschlüsseln des Zeichens Z: Zc = (Zm + k) mod 26 • Entschlüsseln des Zeichens Z: Zm = (Zc − k) mod 26 Es gibt für die Caesar-Chiffre nur |Σ| mögliche Schlüssel für das Alphabet Σ. Beim lateinischen Alphabet gibt es folglich nur 26 mögliche Schlüssel (25 sinnvolle und k ∈ [0, 25]). Bei nur 26 möglichen Schlüsseln ist ein Angriff auf einen mit dem Caesar-Verfahren verschlüsselten Chiffretext daher recht einfach und durch Ausprobieren möglich. Die Caesar-Chiffre kann als Kryptosystem (E, D, M, K, C) wie folgt dargestellt werden [7]:

M = {alle Sequenzen lateinischer Buchstaben} C= M K = {i|i ∈ Z, 0 ≤ i ≤ 25} E = {Ek |k ∈ K, ∀m ∈ M, Ek (m) = (m + k) mod 26} D = {Dk |k ∈ K, ∀c ∈ C, Dk (c) = (26 + c − k) mod 26}

3Falls

k = 13 ist, nennt man diese Chiffre auch ROT13.

4.3  Historische Verfahren

121

Einschub: Modulare Arithmetik

Für a, b ∈ Z, m ∈ N∗ gilt: a ≡ b mod  m, wenn m die Zahl b − a teilt [13]. Oder anders formuliert: Wenn die beiden Divisionsreste 0 ≤ r1, r2 ≤ m − 1 bei Berechnung von a = q1m + r1 und b = q2m + r2 mit q1 , q2 ∈ Z gleich sind (r1 = r2), dann gilt a ≡ b mod m [13].

Wenn für die Caesar-Chiffre gesagt wird, dass Zc = (Zm + k) mod  26 ist, dann bedeutet dies folglich, dass Zc der Rest r aus der Rechnung (Zm + k) = gm + r, also Zc = r = (Zm + k) − gm ist.

4.3.3 Die Vigenère-Chiffre Im Gegensatz zur Caesar-Chiffre hat eine sogenannte polyalphabetische Chiffre nun allerdings mehr als nur einen angewandten Schlüssel. Die Vigenère-Chiffre ist eine solche polyalphabetische Chiffre und wurde 1585 von Blaise de Vigenère entwickelt. Sie wurde erst Mitte des 19. Jahrhunderts gebrochen. Die Vigenère-Chiffre ist eine verbesserte Caesar-Chiffre. Statt einem k ∈ K wird dabei eine Folge k0, …, kn−1 von n Schlüsseln mit ki ∈ K, 0 ≤ i ≤ n − 1 verwendet. Diese Schlüssel werden zyklisch angewandt. Die Nachricht M besteht aus m0…mn−1 mit mi ∈ Z, 0 ≤ mi ≤ 25 und der Chiffretext C besteht aus c0…cn−1 mit ci ∈ Z, 0 ≤ ci ≤ 25. Die Verschlüsselungsfunktion der Vigenère-Chiffre ist dabei sehr ähnlich zu der der Caesar-Chiffre, verwendet allerdings statt k jeweils ein ki. Selbiges gilt für die Entschlüsselungsfunktion. • Verschlüsselung von mi: ci = E(mi, ki) = (mi + ki) mod 26 • Entschlüsselung von ci: mi = D(ci, ki) = (ci − ki) mod 26. Wenn die Länge des Schlüssels kürzer der Länge des Klartextes ist, dann werden die Schlüssel so angewandt, dass sie zyklisch durchlaufen werden. Bei n Schlüsseln ist ki entsprechend ki mod n. Beispiel  Es soll die Nachricht „HALLO“ mit dem Schlüssel „AB“ chiffriert werden. Berechnet werden müssen dazu (Tab. 4.1): Somit ergibt sich der Chiffretext „HBLMO“.

4.3.4 Die Vernam-Chiffre (One-Time-Pad) Als letztes historisches Verfahren wird im Folgenden das 1917 eingeführte VernamChiffrierverfahren betrachtet. Diese nach Gilbert Vernam benannte Chiffre wurde tat-

122 Tab. 4.1  Beispielanwendung der Vigenère-Chiffre

4  Einführung in die Kryptografie mi

ki

ci

H

A

H

A

B

B

L

A

L

L

B

M

O

A

O

sächlich bereits 1882 von Frank Miller erfunden [1]; folglich handelt es sich hierbei um eine Wiedererfindung. Diese Chiffre findet sich (in ähnlicher Form) auch auf modernen Computern. Wenn das Vernam-Verfahren mit echten Zufallszahlen arbeitet (diese also in keiner Weise bestimmbar sind), wird das Verfahren auch als One-Time-Pad bezeichnet und bietet perfekte Sicherheit. One-Time-Pads funktionieren dennoch erstaunlich einfach. Zunächst erzeugt der Anwender des One-Time-Pads einen Schlüssel, mit |K|≥|M|. Im Gegensatz zur VigenèreChiffre darf der Schlüssel also keinesfalls kürzer als die zu verschlüsselnde Nachricht sein. Die Zeichen in K müssen zufällig gewählt sein. Sowohl Sender als auch Empfänger der Nachricht kennen K. Zur Gewährung der Sicherheit muss nach Verwendung (eines Teils) von K sowohl Sender als auch Empfänger der Nachricht (den verwendeten Teil von) K zerstören. Weiterhin gilt das One-Time-Pad nur dann als perfekt sicher, wenn Mallory keinen Zugriff auf K erlangen kann und K nicht mehrfach verwendet wird. Die Ver- und Entschlüsselungsfunktionen arbeiten ähnlich dem bekannten Schema. Zeichenweise (m ∈ M, k ∈ K, c ∈ C) funktionieren die Funktionen wie folgt: • Verschlüsselung: ci = mi + ki mod 26 • Entschlüsselung: mi = ci − ki mod 26. Bei bitweisen Operationen am Computer lässt sich das One-Time-Pad hingegen mit dem XOR-Operator (⊕ beziehungsweise in den meisten Programmiersprachen der ˆ-Operator) realisieren: • Verschlüsselung: ci = mi ⊕ ki • Entschlüsselung: mi = ci ⊕ ki. Jede Schlüsselsequenz ist gleich wahrscheinlich, womit jede Chiffretextsequenz gleich wahrscheinlich wird. Allerdings darf eine Schlüsselsequenz auf keinen Fall mehrfach verwendet werden.

4.4  Kryptoanalyse für historische Chiffren

123

4.4 Kryptoanalyse für historische Chiffren 4.4.1 Skytale-Chiffre Die Kryptoanalyse der Skytale gestaltet sich trivial und benötigt nur einen Kegel und die abgefangene Nachricht C: […] wrap the strip of parchment around a cone and slide it up and down until sense appears; the diameter of the cone at that point is the diameter of the skytale [17].

4.4.2 Caesar-Chiffre Wie Sie vielleicht schon ahnen, lässt sich eine Verschiebechiffre sehr einfach brechen, indem man alle möglichen Werte für k ausprobiert. Ein Ausprobieren aller möglichen Schlüssel wird auch als Brute-Force-Angriff bezeichnet. Es gibt jedoch auch eine effizientere Möglichkeit, eine Kryptoanalyse bei einem derartigen Verfahren durchzuführen. Kennen Sie vielleicht noch das Glücksrad? Beim Glücksrad geht es darum, durch Raten von Buchstaben eine Lösung für ein verdecktes Wort zu finden. Die Buchstaben des verdeckten Worts wurden mit jedem korrekt geratenen Buchstaben weiter aufgedeckt. Zu manchen Zeiten im Spiel konnten die Spieler eine Kombination aus einem Vokal und fünf Konsonanten wählen, um einige der verdeckten Buchstaben selektieren zu lassen. So wählten Spieler oft die Buchstaben „ERNSTL“ aus.4 Die Auswahl „ERNSTL“ der Glücksrad-Spieler war unter diesen Bedingungen gut, kommt der Buchstabe E doch am häufigsten in deutschen Texten vor (17,4 %), gefolgt von N (9,8 %), I (7,6 %, nicht in „ERNSTL“ enthalten, da nur ein Vokal erlaubt war), S (7,3 %) und R (7,0 %) [32]. Der duchschnittliche Buchstabe tritt mit einer Wahrscheinlichkeit von 3,7 % auf. Am seltensten tritt Q auf (0,02 %). Umlaute wurden als AE, OE, UE und ß als eigenes Zeichen (0,3 %) gezählt [32]. k kann nun bestimmt werden, indem angenommen wird, dass k die Differenz zwischen dem am häufigsten vorkommenden Buchstaben des Chiffretexts zum Buchstaben E ist. Beispiel einer Kryptoanalyse

Es soll versucht werden, k für den Chiffretext BJQHM JNS XHMTJSJW YFL zu finden. Zunächst muss herausgefunden werden, welcher Buchstabe am häufigsten auftritt, indem die Häufigkeitsverteilung analysiert wird (dies ist bei längeren Texten besonders zielführend):

4Diverse

Beispielvideos für das Glücksrad finden sich auf Videoplattformen im Internet und können dieses Vorgehen illustrieren.

124

4  Einführung in die Kryptografie

B:1 F:1 H:2 J:4 L:1 M:2 N:1 Q:1 S:2 T:1 W:1 X:1 Y:1 Offensichtlich tritt J am häufigsten auf. Nun kann die Stelle, die E im Alphabet einnimmt, von der Stelle subtrahiert werden, die J im Alphabet einnimmt. Somit ergibt sich k = ‚J‘ (9) - ‘E’ (4) = 5. Wenn dieser Versuch erfolgreich war, dann kann mit k = 5 eine Entschlüsselung des Chiffretexts durchgeführt werden: $ echo ’BJQHM JNS XHMTJSJW YFL’ | caesar $((26-5)) WELCH EIN SCHOENER TAG ◄ Da im vorherigen Beispiel ein plausibler Klartext erzeugt wurde, wurde mit hoher Wahrscheinlichkeit der richtige Wert für k und somit der korrekte Klartext gefunden. Tatsächlich können theoretisch mehrere k zu plausiblen Klartexten führen. Mehr zu diesem Sonderfall erfahren Sie im Abschn. 4.7.6. Sollte das korrekte k auf diese Weise nicht gefunden werden, kann angenommen werden, dass das Zeichen, das am zweit- oder dritthäufigsten vorkommt, das E ist, oder der Kryptoanalyst vom falschen Alphabet ausging.

4.4.3 Kryptoanalyse der Vigenère-Chiffre Für dieKryptoanalyse derVigenère-Chiffre ist zu beachten, dass es 26n (n ist dabei die Anzahl der Elemente von K, also die Schlüssellänge) mögliche Schlüsselperioden gibt. Es sind dabei zwei Fälle zu unterscheiden: 1. Die Schlüssellänge n ist bekannt: Da k periodisch angewandt wird, werden alle Buchstaben, die zueinander den Abstand n (Schlüssellänge) haben, mit demselben ki verschlüsselt. Für jedes Element von K kann somit die bereits erläuterte Kryptoanalyse durchgeführt werden, die für die Caesar-Chiffre verwendet wird. Allerdings muss hierbei der Chiffretext länger als bei der Caesar-Chiffre sein. Sonst können keine brauchbaren Häufigkeiten bestimmt werden. 2. n ist unbekannt: In diesem Fall ist zunächst die Anwendung des Kasiski-Tests oder des Friedman-Angriffs notwendig. Diese beiden Verfahren können n ermitteln. Anschließend wird wie im Fall 1 verfahren.

4.4.3.1 Vigenère-Kryptoanalyse mit dem Kasiski-Test Beim Kasiski-Testwird versucht, zunächst die Schlüssellänge n zu ermitteln. In einem Text kommen häufig gleiche Wörter vor. Beim Verschlüsseln der Texte aus diesem Kapitel wären das etwa Wörter wie Schlüssel, Verschlüsselung oder Kryptoanalyse. Im Normalfall werden diese Wörter mit unterschiedlichen Elementen von K verschlüsselt: Klartext : B A U M Schlüssel: A B C A

U N D B C A

B A U M B C A B

4.4  Kryptoanalyse für historische Chiffren

125

Es kann allerdings passieren, dass aufgrund günstiger Wortabstände und passender Schlüssellänge dasselbe Wort mit denselben Elementen von K verschlüsselt wird: Klartext : B A U M Schlüssel: A B C A

A N B C

B A U M A B C A

Im Beispiel wird „BAUM“ jeweils mit „ABCA“ verschlüsselt, was zum gleichen Chiffretext führt. Der Abstand zwischen den Mustern muss somit einem Vielfachen von n (=Schlüssellänge) entsprechen. Die Distanz zwischen den gleichen Chiffretexten sind sechs Symbole und somit muss n|6 (n teilt 6, das heißt es gibt ein x für das gilt: n ⋅ x = 6) gelten. Ein Kryptoanalyst kann nun also davon ausgehen, dass n|6, doch woher weiß er, welches n genau verwendet wurde? Um n zu bestimmen, wird eine Primfaktorzerlegung von n durchgeführt (6 = 2 ⋅ 3). Weitere Bestandteile des Chiffretextes werden auf potenziell mit gleichem Teilschlüssel verschlüsselte Wörter untersucht. Beispiel  Es ergeben sich die weitere Distanzen 12 und 15, die erneut einer Primfaktorzerlegung unterzogen werden (12 = 2 ⋅ 2 ⋅ 3 und 15 = 3 ⋅ 5). n muss hier ein gemeinsamer Teiler sein (hier: n = 3).  Euklidischer Algorithmus  Im vorherigen Beispiel wurde ein sehr geringer Abstand für die Worte gewählt, die gleich verschlüsselt wurden. Es ist allerdings denkbar, dass derlei Abstände sehr groß ausfallen. Statt 6, 12 und 15 könnten etwa die Abstände 789 und 456 vorliegen. Der euklidische Algorithmus kann den größten gemeinsamen Teiler (ggT) solcher Zahlen liefern. Vorgehen: Die größere Zahl muss durch die kleinere Zahl geteilt werden. Der Rest wird beibehalten und durch ihn wird geteilt, bis der Rest 0 ergibt. Der letzte Divisor ist zugleich der ggT. Beispiel  Berechnung des ggT(789, 456):

789 : 456 = 1, Rest : 333 456 : 333 = 1, Rest : 123 333 : 123 = 2, Rest : 87 123 : 87 = 1, Rest : 36 87 : 36 = 2, Rest : 15 36 : 15 = 2, Rest : 6 15 : 6 = 2, Rest : 3 6 : 3 = 2, Rest : 0

126

4  Einführung in die Kryptografie

Somit ergibt sich: ggT(789, 456) = 3. Falls der ggT von mehr als zwei Zahlen berechnet werden soll, ist die Mehrfachausführung des euklidischen Algorithmus möglich. ggT(a, b, c) kann wie folgt berechnet werden: ggT(a, ggT(b, c)). In N ist ggT assoziativ, das heißt ggT(a, b, c) = ggT(a, ggT(b, c)) = ggT(ggT(a, b), c).

4.4.3.2 Vigenère-Kryptoanalyse mit dem Friedman-Angriff Ein alternativer Kryptoanalyseansatz wurde von Friedman entwickelt und nach ihm benannt. Ziel ist (wie beim Kasiski-Test) die Bestimmung der Schlüssellänge ℓ, ausgehend von einem Chiffretext der Länge n. Diese kann über die folgende Formel berechnet werden [6]5: ℓ=

0, 0377n (n − 1) · I − 0, 0385n + 0, 0762

Die Werte 0,0377 und 0,0385 hängen von den charakteristischen Eigenschaften der verwendeten Sprache ab und sind in diesem Fall die Werte für deutsche Sprache und zufällige Buchstabenfolgen. Der Friedman’sche Koinzidenzindex I berechnet sich wie folgt [6]: 26 ni (ni − 1) I = i=1 n(n − 1) ni gibt an, wie häufig der Buchstabe i im Geheimtext vorkommt. Mit Kenntnis der Ausgangssprache sowie n und dem Auszählen der Häufigkeiten der Symbole lässt sich somit ℓ bestimmen.

4.4.4 Kryptoanalyse der Vernam-Chiffre Bei der Vernam-Chiffre sollte die Schlüsselsequenz auf keinen Fall mehrfach verwendet werden. Falls K nämlich mehrfach verwendet wird und zwei Chiffretexte C1 und C2 abgefangen werden können, weiß der Angreifer bereits etwas über diese beiden Nachrichten: Wenn sie nicht gleich sind, sind auch ihre jeweiligen Klartexte M1 und M2 nicht gleich. Bei perfekter Sicherheit (Einfachverwendung von K) ist ein derartiger Rückschluss nicht möglich. Weiterhin kann der Angreifer mit zwei abgefangenen Chiffretexten wie folgt vorgehen: Angenommen, C1 und C2 wurden beide mit denselben Werten aus K verschlüsselt, dann gilt:

C1 ⊕ C2 = M1 ⊕ K ⊕ M2 ⊕ K = M1 ⊕ M2 .

5In

(4.3)

Beutelspacher et al. [6] findet sich eine exzellente Beschreibung der Herleitung dieser Formel.

4.5 Stromchiffren und Zufallszahlengeneratoren

127

Klartexte unterliegen im Gegensatz zu Chiffretexten statistischen Eigenschaften der Ausgangssprache. Somit sind mit der Umformung in 4.3 statistische Angriffe denkbar, wenn K mehrfach verwendet wurde.

4.4.5 Weitere Anmerkungen zu historischen Chiffren Historische Chiffren wurden insbesondere in Kriegszeiten entwickelt. Vermutlich haben Sie bereits von der Enigma gehört, die im Zweiten Weltkrieg insbesondere von den Deutschen verwendet wurde. Dieses System wurde mehrfach verbessert. Das EnigmaNachfolgesystem Schlüsselgerät 41 (auch als Hitlermühle bekannt; erbaut von der Firma Wanderer aus Chemnitz) ist bereits weniger bekannt. Eine Auseinandersetzung mit diesen Chiffriermaschinen würde den Umfang dieses Kapitels allerdings sprengen. Eine detaillierte Auseinandersetzung mit der Geschichte der Kryptografie finden Sie in [17].

4.5 Stromchiffren und Zufallszahlengeneratoren Bei Stromchiffren (Abb. 4.3) werden alle Zeichen des Klartexts einzeln und nacheinander verschlüsselt (beispielsweise ⊕ mit einem Schlüssel). Hierzu wird ein Schlüsselstrom erzeugt, sodass die Bits m1…mn mit den Schlüsselbits k1…kn chiffriert werden, also E = ek1 (m1 )ek2 (m2 ) . . . ekn (mn ). Ein Beispiel einer Stromchiffre ist das VernamChiffrierverfahren. Zur Generierung eines solchen Schlüsselstroms müssen Wege gefunden werden, um möglichst zufällige Schlüsselbits zu erzeugen. Dies kann entweder auf dem Computer geschehen oder durch ein externes System erfolgen, dass die Zufallsbits an den Computer übergibt. Im Folgenden wird zunächst besprochen, wie Zufallsbits erzeugt werden können. Anschließend werden die unsicheren Algorithmen RC4 und A5/1 beschrieben.

4.5.1 Zufallszahlengeneratoren (PRNG) Ein System, das Zufallszahlen generiert, ist ein Zufallszahlengenerator (engl. Random Number Generator, kurz RNG). Wenn die Zahlen nicht echt zufällig sind, sondern mit Abb. 4.3   Konzept einer Stromchiffre

128

4  Einführung in die Kryptografie

künstlichen Mitteln nur möglichst nah am echtem Zufall sind, so spricht man auch von einem Pseudozufallszahlengenerator (engl. Pseudo Random Number Generator, PRNG). Die Sicherheit von Stromchiffren beruht fast ausschließlich auf dem PRNG: Wenn der PRNG nur Nullen produziert, dann ist C = M und wenn der PRNG-Output echt zufällig ist, ergäbe dies ein One-Time-Pad [25]. Schneier hält diesbezüglich fest: The reality of stream cipher security lies somewhere between the simple XOR and the onetime pad. The keystream generator generates a bit stream that looks random, but is actually a deterministic stream that can be flawlessly reproduced at decryption time [25].

Ein PRNG generiert möglichst zufällige Zahlen, die für die Schlüsselerzeugung verwendet werden können. Das heißt, die durch einen PRNG generierten Werte sollten möglichst nicht vorhersagbar sein. Ein Grundproblem hierbei besteht allerdings in der Tatsache, dass auch ein PRNG durch einen Algorithmus implementiert und damit deterministisch sein muss. Dieser Algorithmus wird mit einem möglichst zufälligen Wert, dem Seed, initialisiert. Der Seed dient letztlich als Startwert für die Generierung von Zufallszahlen und sollte daher selbst möglichst zufällig sein. Häufig werden für die Generierung des Seed Benutzereingaben verwendet, etwa Tastaturanschläge oder Mausbewegungen und -klicke. Leider sind diese Werte durchaus in gewissem Rahmen vorhersagbar und nicht einwandfrei für die Seed-Geneierung nutzbar. Als praktikable Lösung werden daher mehrerer solcher Werte sowie das Timing von bestimmten Hardwareevents (beispielsweise Interrupts) für die Seed-Generierung kombiniert. Beutelspacher et al. nennen das Beurteilungskriterium der Nicht-Vorhersagbarkeit für PRNGs: Ein PRNG erfüllt das Kriterium der Nicht-Vorhersagbarkeit, wenn die Erfolgswahrscheinlichkeit eines effizienten Angreifers, das i-te Bit vorherzusagen, nur unerheblich von 1∕2 abweicht [6]. Ferguson et al. weisen zudem darauf hin, dass ein PRNG als kryptografisch „stark“ gilt, wenn ein Angreifer viele der durch den PRNG generierten Daten sehen kann, und die Nicht-Vorhersagbarkeit trotzdem gilt, siehe dazu auch [12]. Unzählige akademische Publikationen adressieren dieses Problem. Bestehende PRNGs werden dabei untersucht, angegriffen und durch bessere PRNGs ersetzt. Hauptaspekt ist oft das Einbeziehen möglichst zufälliger Bits (beispielsweise echtes Rauschen oder Einbeziehen von User-Input), manchmal jedoch auch die Steigerung der PRNGPerformance [18]. Um echte Zufallsbits zu erhalten (nicht bloß „pseudo“-zufällige), gibt es verschiedene Wege. Menezes et al. nennen einige Beispiele in [21]: Hardware-Generatoren (Auswahl): • Mikrofon-Input • Luftwirbel in (alten) Festplatten • Auftreten von Partikeln bei radioaktivem Zerfall

4.5  Stromchiffren und Zufallszahlengeneratoren

129

Zudem kann Quantenkryptografie zur Generierung echter Zufallszahlen eingesetzt werden. Dazu werden Events auf subatomarer Ebene beobachtet, die nicht vorhersagbar sind. Mittlerweile können mehrere GBit/s an Zufallsdaten von portablen Quanten-RNGs produziert werden ([11]). Software-Generatoren nutzen folgende (halbwegs zufällige, aber beeinflussbare) Quellen (Auswahl): • Verwendung der aktuellen Uhrzeit (möglichst genau) • Zeitabstand zwischen Tastaturanschlägen • Mausbewegungen • Statistiken des Betriebssystems (CPU-Auslastung, Netzwerkstatistiken, Füllstände von Puffern)

4.5.2 Der RC4-Algorithmus RC4 wurde 1987 von Ronals Rivest (RC steht für Ron’s Code) für die Firma RSA Security entwickelt. RC4 wurde geheim gehalten, allerdings 1994 anonym veröffentlicht [28]. Der Algorithmus kommt etwa beim Verschlüsselungsverfahren WEP (siehe Abschn. 8.2.10) in Wireless-Netzwerken zum Einsatz. Ein PRNG liefert bei RC4 Zufallsbytes, die mit Klartextbytes via ⊕ verschlüsselt werden. Dieses Verfahren kennen Sie bereits vom One-Time-Pad. Interessant ist bei RC4 daher primär der PRNG. Im Wesentlichen basiert dieser darauf, dass zunächst eine 256 Byte lange Liste permutiert wird (abhängig vom Schlüsselinhalt). Für alle Bytes des Nachrichtenstroms werden zum Chiffrieren Zufallszahlen auf Basis der zuvor permutierten Liste erzeugt. Dabei werden im Wesentlichen zwei der pseudozufälligen Elemente aus der Liste herausgegriffen und summiert. Das Ergebnis e der Summierung wird wiederum als Index für die Liste verwendet, um den Wert des Elements, also Liste[e], herauszugreifen. Dieser Wert ist das Pseudozufallsbyte. Anschließend werden die beiden verwendeten Elemente der Liste erneut vertauscht, sodass mit der modifizierten Liste der nächste Zufallswert generiert werden kann.

4.5.2.1 Dechiffriererung bei RC4 Für die Entschlüsselung wird, anstelle von M, C als Input für den Algorithmus verwendet. Das beim Verschlüsseln verwendete M ⊕ K wird somit wie folgt einbezogen: C ⊕ K = (M ⊕ K) ⊕ K = M Dabei heben sich also die beiden ⊕ K auf, sodass M übrig bleibt. Dadurch, dass Sender und Empfänger dasselbe K verwenden, können zudem dieselben Zufallszahlen generiert werden, was die Entschlüsselung überhaupt erst ermöglicht.

130

4  Einführung in die Kryptografie

4.5.2.2 Sicherheit von RC4 RC4 kann keineIntegrität gewährleisten. Ein im Chiffretext verändertes Bit wird entsprechend auch im Klartext verändert.6 Außerdem konnte gezeigt werden, dass Angreifer einen Teil des Klartext mithilfe des Chiffretexts berechnen können, wenn TLS verwendet wird [3]. RC4 gilt als unsicher. Experten gehen davon aus, dass die NSA RC4 in Echtzeit brechen kann. Außerdem wurde der Einsatz teils durch Standardisierungsgremien für bestimmte Zwecke (etwa TLS [23]) verboten.

4.5.3 Die A5/1- und A5/2-Algorithmen A5/1 beziehungsweise die abgeschwächte Version A5/2 sind ähnlich aufgebaut wie RC4. Insbesondere unterscheiden sie sich durch ihre Zufallszahlengeneratoren von RC4. A5/1 und A5/2 werden zur Verschlüsselung von GSM (Mobilfunk) eingesetzt, um die Kommunikation zwischen Telefon und Base Station zu verschlüsseln [9] (die restliche Kommunikationsstrecke bleibt unverschlüsselt).7 Beide Algorithmen wurden ursprünglich geheim gehalten. Kryptoanalysten konnten die Algorithmen allerdings rekonstruieren. Die Neuerung des PRNG bei A5 liegt in der Verwendung sogenannter Schieberegister für die Generierung von Zufallsbits. Dabei handelt es sich um Register der Längen 19, 22 und 23 Bits. Die Register werden mit einem geheimen Schlüssel und der Nummer der aktuellen GSM-Übertragungsframe initialisiert. Bei jedem Takt werden alle oder ein Teil der Register um eine Stelle nach links verschoben8 und aus den in den Registern jeweils links stehenden Bits werden per ⊕ die Zufallsbits generiert. Die nun jeweils freie rechte Seite eines Registers wird wieder aufgefüllt. Das Auffüllen geschieht rekursiv mit Werten jeweils unterschiedlicher Positionen des jeweiligen Registers (erneut werden diese Werte per ⊕ miteinander verrechnet). Pro GSM-Frame (4,615 ms) und Kommunikationsrichtung werden 114 Zufallsbits benötigt.

4.5.3.1 Sicherheit von A5/1 A5 bietet keinen Integritätsschutz und kann mittlerweile in Echtzeit gebrochen werden. Es stellte sich die Frage, ob der Algorithmus mit Intention schlecht konzipiert wurde. An dieser Stelle soll ein Auszug aus der Wikipedia-Seite Aufschluss geben:

6Die

Gewährleistung von Integrität ist ein generelles Problem symmetrischer Algorithmen. Eingeschränkt trifft dieses Problem auch auf Blockchiffren zu, die allerdings in bestimmten Modi betrieben werden, um dem Problem Herr zu werden, siehe Abschn. 4.6.3. 7Anm.: Die Nachfolger A5/3 und A5/4 werden ebenfalls für den Mobilfunk eingesetzt und sind keine Stromchiffren. 8Dieser Vorgang wird durch sogenannte Taktkontrollbits gesteuert.

4.6 Blockchiffren

131

Der britische Wissenschaftler Ross Anderson vertrat 1994 die Meinung, es sei absichtlich eine schwache Chiffre ausgewählt worden, um den Nachrichtendiensten der NATO das Abhören von Gesprächen zu ermöglichen. Dies wurde später bestätigt.

Ursprünglich wurde eine längere Schlüssellänge für A5/1 vorgesehen (128 Bits). Wie der norwegische Aftenposten berichtete, einigte man sich auf Druck der britischen Regierung (diese wollte eine Schlüssellänge von 48 Bits) auf die Schlüssellänge von 54 Bits: Audestad says that the British were not very interested in having a strong encryption. And after a few years, they protested against the high security level that was proposed. They wanted a key length of 48 bit. We were very surprised. The West Germans protested because they wanted a stronger encryption to prevent spying from East Germany. The compromise was a key length of 64 bit – where the ten last bits were set to zero. The result was an effective key length of 54 bit [2].

4.6 Blockchiffren Bei Blockchiffren wird blockweise (das heißt immer n Zeichen pro Durchlauf) verschlüsselt. Es gibt eine Vielzahl an Algorithmen, die in diese Kategorie fallen, etwa: • Data Encryption Standard (DES) • Tripple-DES (3DES) • LUCIFER • LOKI • International Data Encryption Algorithm (IDEA) • Blowfish • Safer • Advanced Encryption Standard (AES) Betrachtet werden zunächst die Algorithmen DES und 3DES. Im Anschluss wird es um AES und Modi von Blockchiffren gehen.

4.6.1 Der Data Encryption Standard (DES) DES (auch Data Encryption Algorithm, kurz DEA oder DEA-1) war über Jahrzehnte der dominierende Standard für Kryptografie [25]. Der Algorithmus gilt nicht mehr als sicher genug, wird aber noch in vielen Bereichen von Altsystemen eingesetzt. DES wurde insbesondere entwickelt, um einen einheitlichen Verschlüsselungsalgorithmus zu besitzen, anstatt diverse Algorithmen für verschiedene Produkte zu verwenden. Letztlich ist DES ein Industriestandard des National Institut of Standards and Technology (NIST), entwickelt von IBM und beeinflusst von der NSA.

132

4  Einführung in die Kryptografie

Zunächst führte das NIST zwei öffentliche Ausschreibungen durch, bei denen Vorschläge für einen solchen Algorithmus eingereicht werden konnten. Geforderte DesignPrinzipien des NIST waren laut Schneier die folgenden [25]: • Der Algorithmus sollte ein hohes Maß an Sicherheit bieten. • Algorithmus sollte komplett spezifiziert und einfach zu verstehen sein. • Sicherheit vom Algorithmus sollte ausschließlich im Schlüssel liegen (keine „Security-by-Obscurity“). • Verfügbarkeit des Algorithmus für alle potenziellen Anwender. • Anwendbarkeit des Algorithmus im Rahmen diverser Anwendungsfelder. • Die Implementierung des Algorithmus in elektronische Geräte sollte wirtschaftlich sein. • Die Benutzung des Algorithmus sollte effizient sein. • Der Algorithmus sollte validierbar sein. • Es sollte erlaubt sein, den Algorithmus zu exportieren. IBM schlug 1974 einen etwas komplizierten Algorithmus vor, gewann damit allerdings trotzdem die Ausschreibung. Zur Beurteilung des Algorithmus zog das NIST die NSA zu Rate. Die NSA schlug eine modifizierte Version des Algorithmus vor. Die neue Version verwendete 56-bit-Schlüssel statt 128-bit-Schlüssel. Das NIST ließ daraufhin die NSAVersion auf mögliche Hintertüren untersuchen. Trotz Kritik wurde der DES Ende 1976 als nationaler Standard verabschiedet. DES blieb von 1977 bis 2002 der Kryptostandard der USA und einem Großteil der restlichen Welt [15]. Hintergrund zur Historie des DES

Weitere Details zur Geschichte und weshalb die NSA es bereute, das NIST bzgl. DES beraten zu haben, finden Sie im Buch von Schneier [25], Abschn. 12.1, Seiten 265–270.

4.6.1.1 DES: Funktionsweise DES verschlüsselt Daten in 64-bit-Blöcken (dies entspricht der Größe von M- und C-Blöcken) auf symmetrische Weise. Ein DES-Schlüssel ist 64 Bits lang, wovon allerdings jedes achte Bit ein Paritätsbit (siehe Abschn. 2.3.1.3) ist. Es bleiben folglich nur 56 Schlüsselbits übrig. DES verwendet im Prinzip zwei grundlegende kryptografische Techniken: Konfusion und Diffusion. Prinzip der Konfusion: Klartexte weisen die uns bekannten statistischen Eigenschaften auf und ermöglichen erst durch diese eine Vielzahl von Angriffen. Die Konfusion verfolgt das Ziel, derartige statistische Klartext-Eigenschaften (Redundanzen) zu verbergen.

4.6 Blockchiffren

133

Gearbeitet wird mit sich bei jedem Klartextbit ändernden Mechanismen, die Klartextblöcke durch Chiffretextblöcke substituieren. Ein typischer Ansatz ist, dass jedes Klartextbit von mehreren Schlüsselbits abhängig gemacht wird. Prinzip der Diffusion: Diffusion sorgt dafür, dass jede noch so kleine Veränderung in einem Klartext zu einem möglichst unterschiedlichen Chiffrat führt. Dies ist beispielsweise bei der Caesar-Chiffre nicht der Fall: Ein verändertes Klartextzeichen wird nur das entsprechende Zeichen im Chiffrat verändern. Diffusion sorgt hingegen dafür, dass auch eine solch kleine Veränderung zu möglichst großen Veränderungen im Chiffrat führt. Am Beispiel des Prüfsummenalgorithmus’ MD5 lässt sich die Fähigkeit der Diffusion leicht zeigen. Im Folgenden wird nur der erste Buchstabe von ‚k‘ auf ‚K‘ verändert (betroffen sind hierbei nur wenige Bits der Nachricht), doch ergibt sich daraus eine stark unterschiedliche Prüfsumme: $ md5sum katze 2f57741f6a1ce8ed633395fc4ece1550 $ md5sum Katze a958290d7d801e6a0a0f63c727f86bbe

-

-

4.6.1.2 Feistel-Netzwerke Wie gesagt verarbeitet DES den Klartext in Blöcken zu je 64 Bit.9 Zu diesem Zweck kommen sogenannte Feistel-Netzwerke (zumindest in modifizierter Form) zum Einsatz. Ein Feistelnetzwerk arbeitet rundenweise. Es spaltet den Klartext in einen linken und einen rechten Teil auf (Abb. 4.4). Dabei wird der rechte Teil (Ri) eines Klartextes zum linken Teil (Li+1) des Geheimtextes der jeweiligen nächsten Runde. Ri wird außerdem verwendet, um mit einer Verschlüsselungsfunktion, die den Schlüssel als Eingabe bekommt, verrechnet zu werden (Abb. 4.4). Das Ergebnis dieser Verrechnung mit f wird mit der linken Klartextseite per ⊕ verrechnet und zum rechten Teil Ri+1 dieser Runde. Ausgaben einer Runde i dienen dabei als Eingaben für die Runde i + 1. Anders formuliert passiert in einem Feistel-Netzwerk also Folgendes: Für die Verschlüsselung berechnen wir: Li = Ri−1 Ri = Li−1 ⊕ fi (Ri−1 , Ki )

9Dieser

Unterabschnitt basiert auf unserem vergriffenen Titel J. Plötner, S. Wendzel: Praxisbuch Netzwerksicherheit, Galileo Press, 2007, siehe [22]. Der Originaltext wurde stark überarbeitet.

134

4  Einführung in die Kryptografie

Abb. 4.4   Ein FeistelNetzwerk (Abb. aus [22])

Klartext R1

L1

f()

Li+1

Ki

Ri+1 Geheimtext

Für die Entschlüsselung wird hingegen Folgendes berechnet:

Li−1 = Ri ⊕ fi (Ri−1 , Ki ) Ri−1 = Li fi ist die Verschlüsselungsfunktion und Ki der Schlüssel der i-ten Runde. Bei n Runden ist (Ln, Rn) der finale Geheimtext. Bei DES ist n = 16. Für die Entschlüsselung wird allerdings nicht die inverse Funktion fi−1 benötigt. Die Begründung hierfür kennen Sie bereits, denn:

M =M ⊕K ⊕K =C⊕K =M Es sei an dieser Stelle erwähnt, dass die Klartextblöcke vor Runde 1 durch eine Eingangspermutation permutiert werden. Eine zugehörige Schlusspermutation macht diesen Vorgang am Ende des Algorithmus wiederum rückgängig. Schneier schreibt, dass diese Funktionen für die Sicherheit von DES irrelevant seien und nur implementierungstechnische Gründe hätten [25].

4.6.1.3 Modifiziertes Feistel-Netzwerk DES verwendet allerdings nicht das ursprüngliche Feistelnetzwerk, sondern eine Modifikation desselben (hervorgehobene Kästchen in Abb. 4.5). Schritt 1 (Expansion): Die Länge von Ri beträgt 32 Bits (das ist die Hälfte des 64-BitBlocks). Im ersten Schritt expandiert f die Länge von Ri auf 48 Bit, da später 48 Bits des Schlüssels verwendet werden und beide Werte mittels ⊕ verrechnet werden. Für die Expansion werden schlicht bestimmte Bits nach einer vorgegebenen Tabelle verdoppelt. Neben dieser Expansion führt die Funktion an dieser Stelle noch eine zusätzliche­

4.6 Blockchiffren

135

Abb. 4.5   Modifiziertes Feistel-Netzwerk bei DES

Permutation von Ri durch, wobei allerdings nur wenige Bits permutiert werden. In diesem ersten Schritt wird nichts verschlüsselt und es wird keine Sicherheit gewonnen. Das Ergebnis der Expansion wird schließlich mit Ki via ⊕ verrechnet. Schritt 2 (S-Box): Die aus der ⊕-Operation resultierenden 48 Bits werden bei DES durch acht S-Boxen (Substitutions-Boxen) geleitet. Jede dieser S-Boxen verfügt dabei über sechs Eingangs-Bits und vier Ausgangs-Bits („6 × 4-S-Box“). Somit machen die S-Boxen aus den 48 Eingangs-Bits 32 Ausgangs-Bits (Abb. 4.6). Jede der DES-S-Boxen verwendet eine unterschiedliche Tabelle mit je vier Zeilen und 16 Spalten. Von den sechs Eingangs-Bits werden Bits 0 und 5 zur Wahl der Zeile und Bits 1–4 zur Wahl der Spalte verwendet. Der Spaltenwert ist ein 4 Bits langer Wert für den Ausgang der S-Box. Beispiel  Die S-Box erhält die Eingabe „011101“. Dann ist die Zeile 01=1 (=2. Zeile) und die Spalte ist 1110=14 (=15. Zeile). Die Ausgabe wäre nun der 4-Bit-Wert an Position (2, 15) der Tabelle. Abb. 4.6   S-Boxen bei DES

136

4  Einführung in die Kryptografie

Die Tabellenwerte werden durch verschiedene mathematische Methoden, bei manchen Algorithmen aber auch einfach mit Zufallswerten, befüllt. Diese Werte sind für den Algorithmus statisch. S-Boxen erhöhen die Sicherheit von kryptografischen Algorithmen, da sie kein lineares Mapping zwischen Ein- und Ausgangsbits verwenden. Schneier verweist darauf, das S-Boxen umso sicherer werden, je größer sie ausgelegt sind, da ihre Größe die Kryptoanalyse erschwert [25]. Schritt 3 (Permutation): Schließlich werden die aus der S-Box resultierenden 32 Bits nach einem vorgegebenen Mapping (simple Tabelle) permutiert. f ist damit abgeschlossen und Li kann mit dem Ergebnis von f mittels ⊕ verknüpft werden. Es bleibt allerdings noch die Frage zu klären: Wie kommen die Bestandteile des Schlüssels (Ki) zu Stande? Schlüsselerzeugung: Wie bereits erwähnt, werden vom Schlüssel 56 Bits verwendet, die restlichen Bits sind Parity-Bits. Für jede der 16 DES-Runden wird aus dem 56-BitSchlüssel K ein 48-Bit-Schlüssel Ki generiert. Dabei wird folgende Vorgehensweise eingehalten [25]: 1. Zerlegung des 56-Bit-Schlüssels in zwei Teile zu je 28 Bit. 2. Je nach Runde werden die Teilschlüssel um 1 bis 2 Bits (weiter) verschoben (diese Entscheidung wird anhand einer Tabelle getroffen). 3. Anschließend wird eine Kompressionsfunktion ausgeführt: Sie selektiert 48 der 56 Bits durch Permutation. Diese 48 Bits bilden den Rundenschlüssel Ki. Dadurch werden in jeder Runde unterschiedliche Schlüsselbits verwendet.

4.6.1.4 DES: Angriffe DES ist insbesondere gegen Brute-Force-Angriffe verwundbar. Einige Zahlen: • DES kennt 256 = 72 Brd. mögliche Schlüssel. Brute-Force-Angriffe sind daher möglich. Hier kommt der NSA-Vorschlag für kürzere Schlüssel zum Tragen. • 1998: Die EFF baut den „Deep Crack“-Supercomputer. Er kann mit DES-CrackChips 88 Mrd. Schlüssel/s testen. • 1999: Mithilfe von Distributed Computing (100.000 Rechner!) konnten bereits 245 Mrd. Schlüssel/s getestet werden. • 2008: SciEngines GmbH (Erbauer des COPACOBANA-Projekts): 292 Mrd. Schlüssel/s, http://www.copacobana.org/docs.html. • Realistische momentane Crack-Dauer: ca. 20 h. DES besitzt verschiedeneSchwächen. Es gibt zum einen vier bekannte Schlüssel, für die gilt: EK(EK(M)) = M [24]. Diese Schlüssel werden allerdings einfach nicht verwendet.

4.6 Blockchiffren

137

Zudem gibt es sechs Schlüsselpaare (K1, K2), für die gilt: EK1 (EK2 (M)) = M [24]. Diese Schlüsselpaare werden ebenfalls nicht verwendet. Außerdem sind weitere Probleme bekannt. Letztlich bleibt auch noch einmal zu erwähnen, dass die Schlüssellänge des DES viel zu kurz für heutige Ansprüche ist.

4.6.1.5 Tripple DES Es sei kurz erwähnt, dass es möglich ist, die Sicherheit von DES durch das sogenannte Tripple DES-Verfahren (auch: 3DES) zu verbessern. 3DES ist die dreifache Anwendung von DES in der folgenden Form mit drei Schlüsseln K1, K2, K3 (EDE-(Encrypt-DecryptEncrypt)-Verfahren): C = EK1 (DK2 (EK3 (M))) und M = DK1 (EK2 (DK3 (C))) Man erhält somit 3 × 56 = 168 Bits Schlüssellänge. Durch die Charakteristika von DES ergeben sich effektiv allerdings nur 112 Bit [25].

4.6.2 Der Advanced Encryption Standard (AES) Da DES als unsicher gilt, wurde nach einem Nachfolger für DES gesucht. Diese Suche wurde im Rahmen eines Wettstreits durchgeführt, aus dem schließlich der Advanced Encryption Standard (AES) hervorging. Der Algorithmus, der diesen Wettstreit gewann, hieß eigentlich Rijndael, benannt nach seinen belgischen Entwicklern: Rijmen und Daemen. Bisher sind keine praktisch relevanten Angriffe gegen AES bekannt.

4.6.2.1 AES-Grobübersicht AES lässt sich am einfachsten erklären, wenn es zunächst vom zuvor besprochenen DES unterschieden wird. Grobe Unterschiede sind [6, 24, 28]: • Schlüssellänge: AES verwendet längere Schlüssel (128, 192 oder 256 Bit) statt 56 Bits bei DES. • Blockgröße: AES verwendet 128 Bits (Rijndael auch 192 und 256 Bit) statt 64 Bits DES. • Funktionsweise: Wie DES verwendet AES S-Boxen und eine Schlüsselexpansion, führt Permutationen und Substitutionen durch. AES verwendet kein Feistel-Netzwerk. • Art des Algorithmus: Sowohl AES als auch DES sind symmetrische Algorithmen. • Anzahl der Runden: Statt der 16 Runden des DES verwendet AES 10 (128-BitSchlüssel), 12 (192-Bit-Schlüssel) oder 14 (256-Bit-Schlüssel) Runden. • Betriebsmodi: Auch AES kennt die typischen Betriebsmodi (CBC, CFB etc.). Vorteilhaft ist an AES auch seine hohe Performance, weshalb AES im Bereich von Embedded Systems/Automation zum Einsatz kommt (etwa bei den Funk- und Busprotokollen BACnet, KNX und ZigBee). DES gilt allerdings ebenfalls als performant.

138

4  Einführung in die Kryptografie

4.6.2.2 Die Kernkonzepte von AES Bei AES erfolgen Permutation und Substitution im Wechsel. Eine Aufteilung von M in eine linke und eine rechte Seite, wie bei DES, gibt es bei AES nicht. Der Klartext wird in eine 4 × 4-Matrix (8 × 16 = 128 Bit) zerlegt und in jeder Runde werden die Daten der Matrix verarbeitet, sodass die finale Ausgabe letztlich C ist. Eine Runde besteht dabei aus den folgenden Funktionen [6, 24]: 1. SubBytes 2. ShiftRow 3. MixColumn 4. AddRoundKey Zum Start wird AddRoundKey durchgeführt. In allen Runden außer der letzten werden alle vier Funktionen durchlaufen. In der letzten Runde wird MixColumn durch ein weiteres AddRoundKey ersetzt. Bei SubBytes handelt es sich um eine S-Box (für Konfusion zuständig). Jedes der 16 Bytes der Matrix wird nach einer Ersetzungstabelle durch ein neues ersetzt. Entsprechend verfügt die Tabelle über 256 Bytewerte (für jeden möglichen Byte-Wert). ShiftRow ist für die Durchmischung der Zeilen der Matrix zuständig (Diffusion). MixColumn sorgt schließlich für die Durchmischung der Spalten der Matrix (ebenfalls für Diffusion zuständig) [6, 24]. MixColumn wird in der letzten Runde nicht aufgerufen, weil es für die Verschlüsselung nicht mehr nötig ist. Der Grund: MixColumns und AddRoundKey sind vertauschbar, womit das Ergebnis bereits nach AddRoundKey festehen würde, wenn AddRoundKey zuerst ausgeführt werden würde [24]. AddRoundKey führt ein bitweises ⊕ von Matrix-Elementen und dem Rundenschlüssel durch. Ein Rundenschlüssel ist 4 × 4 Bytes groß (Matrixgröße). AES erzeugt die Rundenschlüssel im Wesentlichen durch die in SubBytes verwendete S-Box, eine byteweise Linksrotation und ⊕-Operationen. Es werden so viele Rundenschlüssel benötigt, wie es Runden gibt. Zusätzlich wird vor der ersten Runde der eigentliche AES-Schlüssel für AddRoundKey verwendet, womit es also bei 10 Runden 11 Anwendungen des (Runden) Schlüssels gibt. Entschlüsselung: Die Entschlüsselung durchläuft – allerdings invertiert und in umgekehrter Reihenfolge – sämtliche Schritte der Verschlüsselung. So muss etwa die S-Box-Tabelle rückwärts angewandt werden.

4.6.3 Blockchiffren-Betriebsmodi DES, AES und weitere Blockchiffren kennen verschiedene sogenannte Betriebsmodi, von denen die folgenden besonders relevant sind

4.6 Blockchiffren

139

4.6.3.1 Electronic Codebook (ECB) ECB wird standardmäßig bei DES eingesetzt und verschlüsselt die bekannten (dort 64 Bits großen) Blöcke unabhängig voneinander, das heißt Ci = E(K, Pi) und Pi = D(K, Ci). Der letzte Block wird gegebenenfalls aufgefüllt (falls weniger als 64 Bits vorliegen). Eine Veränderung in einem Klartextblock führt zur Veränderung des entsprechenden Chiffreblocks. Gleiche Klartextblöcke resultieren in gleichen Chiffreblöcken. 4.6.3.2 Cipher Block Chaining(CBC) Vorherige Chiffreblöcke beeinflussen hierbei die folgenden Klartextblöcke (sie werden mit diesen durch XOR verrechnet): Ci = E(K, Pi ⊕ Ci−1 ) und:

Pi = D(Ci ) ⊕ Ci−1 C0 wird auf einen Initialwert gesetzt. Eine Änderung im Klartext kann sich daher durch weitere Chiffreblöcke ziehen.

4.6.3.3 Cipher Feedback Modus (CFM) Mithilfe der erzeugten Chiffreblöcke wird ein Schlüsselstrom erzeugt, der verwendet wird, um gemeinsam mit K den Rundenschlüssel Ki zu erzeugen. Der Rundenschlüssel ist somit vom vorhergehenden Chiffreblock abhängig, womit sich Veränderungen in M durchziehen: Ci = E(Ci−1 ) ⊕ Pi C0 wird auch hier zuvor auf einen Initialwert gesetzt.

4.6.3.4 Output Feedback Modus (OFM) Es wird ein Schlüsselstrom erzeugt (aus einem Initialwert), der durch eine Funktion zur Schlüsselgenerierung gemeinsam mit K zum Rundenschlüssel wird. Dieser Rundenschlüssel wird nicht nur für Ki ⊕ M verwendet, sondern dient in der Folgerunde neben K wieder als Eingabe für die Funktion zur Generierung des Rundenschlüssels Ki+1. 4.6.3.5 Counter Mode (CTR) Hierbei wird ein Zufallswert auf Basis eines Initialwerts und eines bei jedem Durchlauf inkrementierten Counters generiert. Dieser Zufallswert dient als Schlüssel: Ci = E(Initialwert||Counteri ) ⊕ Pi Es existieren weitere Blockchiffren-Modi, insbesondere in Verbindung mit Message Authentication Codes, die in Abschn. 4.8.9 erläutert werden.

140

4  Einführung in die Kryptografie

4.7 Informationstheorie und Kryptografie Bei Auseinandersetzung mit den theoretischen Aspekten der Kryptografie kommt irgendwann die Feststellung auf, dass Kryptografie in irgendeiner Form Informationen verschlüsselt und sichert. Es stellen sich somit grundlegende Fragen, etwa: Wie lässt sich Information messen? Welchen Bedeutung hat welche Art von Information für die Kryptografie? Bei der Beantwortung dieser Fragen liefert die Informationstheorie Abhilfe. Die Informationstheorie wurde von Claude E. Shannon begründet. Im Folgenden werden einige Grundbegriffe der Informationstheorie erläutert. Diese Grundlagen werden anschließend im Rahmen der Kryptografie betrachtet.

4.7.1 Grundzüge der Informationstheorie Die zentralen Grundbegriffe, die zum Verständnis der Informationstheorie benötigt werden, sind Entscheidungsgehalt, Informationsgehalt und Entropie.

4.7.1.1 Entscheidungsgehalt Ein Zufallsereignis stellt aus Sicht der Informationstheorie Information dar – etwa den Ausgang einer Sportwette. Ein [bit] repräsentiert dabei zwei gleich wahrscheinliche Ereignisse. In [bit] wird gemessen, wie viele Ja/Nein-Fragen benötigt werden, um den Ausgang eines Zufallsereignisses zu erfahren. Der sogenannte Entscheidungsgehalt H0 gibt an, wie viele [bit] benötigt werden, um n verschiedene Werte unterscheiden zu können: H0 = log2 (n).

(4.4)

Abb. 4.7 stellt dar, wie viele [bits] abhängig von der Anzahl der Ereignisse (Werte) benötigt werden. Für zwei verschiedene Ereignisse wird beispielsweise 1 [bit], für drei Ereignisse werden 1585 [bit] und für 16 Ereignisse werden bereits 4 [bit] benötigt. Einschub: Anmerkung zum Begriff bit/Bit:

In der Informationstheorie wird zwischen [bit] und [Bit] als Einheit unterschieden. Die Einheit [bit] hängt vom Logarithmus zur Basis 2 ab. Wird die Basis e verwendet, wird die Einheit [nat] verwendet, bei der Basis 10 die Einheit [hartley] oder [ban]. Der Unterschied zur Einheit [Bit] ist der, dass [Bit] für die binäre Darstellung verwendet wird. Ein [Bit] ist immer ganzzahlig. Für die Darstellung von n [bit] sind also mindestens ⌈b⌉ Bits notwendig. Diese Feinheit wird allerdings nicht von allen Autoren unterschieden. Aus diesem Grund wird im Folgenden einheitlich von „Bit“ beziehungsweise dem Plural „Bits“ gesprochen.

141

4.7  Informationstheorie und Kryptografie

l

l

Abb. 4.7   Entscheidungsgehalt H0, abhängig von der Ereignisanzahl

4.7.1.2 Informationsgehalt Der Informationsgehalt I eines Ereignisses i gibt an, wieviel Information durch Kenntnis über das Ereignis gewonnen wird. Je unwahrscheinlicher das Ereignis ist, umso mehr Information wird erzeugt. Dies ist auch plausibel. Angenommen, Sie wissen, dass Ihre Nachbarn nächsten Sonntag heiraten. Am Montag darauf fragen Sie Ihre Nachbarn, ob sie wirklich geheiratet haben. Wahrscheinlich wird die Antwort „Ja“ lauten, was sie nicht überraschen wird. Der weniger wahrscheinliche Ausgang „Nein“ wäre hingegen überraschender.   Ii = log2 p1i = − log2 (pi ), mit 0 < p ≤ 1 Ist I = 0, dann ist der Ausgang eines Ereignisses sicher, denn p = 1. Abb. 4.8 stellt die Werte von log2(1∕x) grafisch dar. Wie Sie sehen, sind besonders unwahrscheinliche Ereignisse mit einem besonders hohen Informationsgehalt versehen.

4.7.1.3 Entropie Die Entropie H ist der mittlere Informationsgehalt einer Menge von statistisch unabhängigen Ereignissen. Sie ist die Summe der Informationsgehälter, jeweils multipliziert mit der Auftrittswahrscheinlichkeit:   H(p) = ni=1 pi Ii = − ni=1 pi log2 (pi ). (4.5) Hierbei ist zu beachten, dass es zwei unterschiedliche Schreibweisen gibt:

H(p) = H(p1 , p2 , . . . , pn ).

(4.6)

142

4  Einführung in die Kryptografie 7

log(1/x)/log(2)

6

5

4

3

2

1

0

0

0.2

0.4

0.6

0.8

1

Abb. 4.8   Plot der Funktion log2(1∕x)

Angenommen, ein Proband soll einen von zwei symmetrischen Verschlüsselungsalgorithmen auswählen. Dazu soll ein Kleinkind auf eine von zwei Tasten drücken, von denen eine für DES und eine andere für AES steht. Das Kind wird diese Tasten mit ungefähr gleicher Wahrscheinlichkeit drücken, somit ist pDES = pAES = 0.5. Entsprechend ist H(p) = −2(0.5 · log2(0.5)) = 1. Wenn das Kleinkind nun durch einen Leser der vorherigen Abschnitte ersetzt wird, dann dürfte das Ergebnis hingegen mit deutlich höherer Wahrscheinlichkeit für AES ausfallen, etwa pDES = 0.05 und pAES = 0.95. Somit ergibt sich eine deutlich niedrigere Entropie: H(p) = 0.286. Abb. 4.9 stellt die Entropie für die zwei Ereignisse p und 1 − p dar. Angenommen, X und Y seien Zufallsexperimente und der Ausgang von Y würde X beeinflussen. In dieser Situation liegt eine bedingten Entropie vor. Es gilt, dass H(X|Y ) = H(X), falls X gar nicht von Y abhängig ist. Falls X hingegen völlig von Y abhängig ist, so gilt H(X|Y ) = 0. X und Y bestehen aus i beziehungsweise j Ereignissen. Auf Basis der bedingten Entropie lässt sich eine interessante Frage stellen: Wie unbestimmt ist eine Quelle nach dem Empfang von Nachrichten? Oder, im Kontext der Kryptografie betrachtet: Wie unbestimmt ist eine Klartextnachricht M noch, wenn der Chiffretext C empfangen wurde, das heißt H(M|C)? Anstelle von M kann auch K in diese Fragestellung eingesetzt werden.

4.7  Informationstheorie und Kryptografie

143

1 0.9 0.8 0.7

H(p, 1-p)

0.6 0.5 0.4 0.3 0.2 0.1 -(x*(log(x)/log(2)) + ((1-x)*(log(1-x)/log(2))))

0

0

0.2

0.4

0.6

0.8

1

p

Abb. 4.9   Entropiewerte für H(p, 1 − p)

Um in Erfahrung zu bringen, wie sich die bedingte Entropie für ein Ereignis yi aus Y auswirkt, muss H(X|Y = yi) bestimmt werden:  H(X|Y = yi ) = − ni=1 P(X = xi |yi ) log2 P(X = xi |yi ). (4.7) Für alle Ereignisse aus Y lässt sich dies ebenfalls berechnen10:  H(X|Y ) = m j=1 H(X|Y = yi )P(Y = yi ).

(4.8)

4.7.2 Informationstheorie in der Kryptografie Die Unsicherheit einer Nachricht wird im Folgenden mit H(X) bezeichnet. Das heißt H(X) repräsentiert die Anzahl der Klartextbits, die ein Angreifer wiederherstellen muss, um eine verschlüsselte Nachricht zu verstehen [25]: Wenn die verschlüsselte Nachricht ‚%_q)t‘ eine von zwei Haustiersorten repräsentiert, dann verbirgt sich hinter ihr folglich auch nur 1 Bit an Information, die der Angreifer wiederherstellen muss, auch wenn für die Darstellung als String mehrere Bytes benötigt werden [25].

10Die

Schreibweisen pi und P(X = xi) sind gleichbedeutend.

144

4  Einführung in die Kryptografie

4.7.3 Redundanz Informationsrate r (auch Coderate [27]) einer Sprache ist r = H(M) [25], wobei M die N Nachricht und N = |M|. N wird möglichst groß gewählt, sodass möglichst viel Text einer Sprache analysiert wird. Bei natürlicher Sprache ist r etwa im Bereich 1,0–1,5 Bits pro Buchstabe [25], wobei die Entropie mit der Länge der Nachricht abnimmt. Auch dies erscheint plausibel: Oft kann mit einer kurzen E-Mail dasselbe gesagt werden, wie mit einer langen Mail. In der Kürze liegt die Würze! Die absolute Informationsrate R ist log2(L), wobei L die Anzahl der Zeichen der Sprache ist [25]. R stellt die maximale Entropie sämtlicher Symbole der Sprache dar. Die Redundanz D einer Sprache ist somit: D = R − r [25]. Umgestellt nach H ergibt sich somit H(M) = N(R − D). Bei 26 Buchstaben liegt die absolute Informationsrate bei log226 = 4,7 Bits/Symbol [21]. Tatsächlich beinhaltet das Englische jedoch nur etwa einen Informationsgehalt von 1,3 Bits/Symbol. Das heißt, 3,4 Bits pro Buchstabe sind redundant [25]. Menezes et al. geben mit D = 3,2 (basierend auf einem Informationsgehalt von 1,5 Bits/Symbol) einen leicht unterschiedlichen Wert für die englische Sprache an [21]. Die meisten Sprachen, die auf dfem Lateinischen basieren, dürften grob einen Wert zwischen 3,0 − 3,5 liefern. Etwas Unterhaltung am Rande

Nun wissen Sie genug, um sich problemlos mit der Frage zu befassen, wie viele verschiedene Nachrichten auf Twitter gepostet werden können (ohne Redundanzen), und wie lang das Posten all dieser Nachrichten dauern würde, wenn es von Menschen durchgeführt wird. Eine Antwort hierauf finden Sie im Buch What If von Randall Munroe. Munroe ist übrigens auch Autor des unter Informatikern beliebten Web-Comics xkcd.

4.7.4 Sicherheit eines Kryptosystems EinemKryptoanalytiker ist oft die Art eines Klartexts bekannt. Damit ist ihm auch die verwendete „Sprache“ bekannt (beispielsweise Englisch, Perl oder die Struktur einer HTML-Datei). Sprache hat wiederum eine natürliche Redundanz.11 Neben Symbolen treten auch bestimmte Wörter nicht ganz frei auf; so enden deutsche Texte selten mit einem „Hallo“. Es gibt eine große Zahl möglicher Klartexte, aber eine geringe Zahl wahrscheinlicher Klartexte. Es gibt viel Redundanz und somit wenig Entropie. Aus diesem Grund sind statistische Angriffe auf Chiffretexte möglich.

11Siehe

auch Abschn. 4.4 zur Kryptoanalyse historischer Chiffren.

4.7  Informationstheorie und Kryptografie

145

Im Kontext dieser Redundanz stellt sich die Frage der perfekten Sicherheit des OneTime-Pads erneut. Die Anzahl möglicher Schlüssel war dabei größer als die Anzahl möglicher Nachrichten und C darf keinerlei Informationen über M erhalten. Somit ist folgende Bedingung erfüllt: H(M|C) = H(M) [31]. Entropie ist in der Kryptografie außerdem ein Maß für die Größe des Schlüsselraums [25] und H(|K|) =log2(|K|). Bei einem 8 Bits langen Schlüssel gibt es maximal 256 mögliche Schlüssel, weil log2(28) = 8 Bits; bei DES also beispielsweise H(256) = 56 Bits. Wenn die Schlüsselgenerierung nicht absolut zufällig ist, sinkt die Entropie. Daher ist log2(|K|) ohne Gewichtung der einzelnen Schlüssel mit pi eigentlich nur näherungsweise korrekt.

4.7.5 Abschätzung der Spurious Keys Wie viele Schlüssel gibt es, die einen Chiffretext der Länge N in lesbaren Klartext der Ausgangssprache überführen? Die Anzahl A dieser Schlüssel entspricht gemäß einem 1977 veröffentlichten Aufsatz von Hellman in etwa [14, 21, 25].

A = 2H(|K|)−N·D .

(4.9)

Die Ergebnisse von A sind manchmal unrealistisch. A ist letztlich nur eine Abschätzung. Die Herleitung für diese Formel ergibt sich über die Umstellung der Formel für D, also H(M) = N(R − D), wobei R in diesem Fall nicht benötigt wird, sondern nur D, wodurch − N ⋅ D übrigbleibt. Berechnet wird folglich: Entropie vom Schlüsselraum minus Länge vom Chiffretext multipliziert mit der Redundanz der Sprache. Die Berechnung erfolgt dabei mit einer Zweierpotenz (2x), weil die Schlüsselanzahl aus der Entropie abgeleitet werden soll (andernfalls würde nur mit der Anzahl der Schlüsselbits gerechnet werden). Dies ist plausibel, denn mit einem längeren N wird es schwieriger, plausible Klartexte zu finden. Je größer D (Redundanz) ist, umso geringer ist auch r, wodurch ebenfalls weniger plausible Klartexte möglich sind. N ⋅ D steht somit für die sinnlosen (Hellman: meaningless) Nachrichten, die von der Gesamtzahl an Nachrichten (H(|K|)) abgezogen werden. Übrig bleiben die sinnvollen (Hellman: meaningful) Nachrichten [14].

4.7.5.1 Illustration Es liege eine Caesar-Chiffre mit der Ausgangssprache Englisch und dem Chiffretext „EVF“ vor. Mit unterschiedlichen Werten für k ergeben sich die Klartexte „NEO“, „BSC“ (akademischer Grad) beziehungsweise „DUE“, also plausible englische Klartexte. Bei einer Vigenère-Chiffre wären zudem weitere Klartexte denkbar, wenn |K| >= 2, etwa „THE“, „MOM“, „DAD“ oder „NOT“. 4.7.5.2 Abschätzung der Spurious Keys Das heißt, es existieren mehrere mögliche k ∈ K, die aus C einen irgendwie Sinn ergebenden Text erzeugen, der aber nicht der Ursprungstext M sein muss. Ein Schlüssel, der ein plausibles M′≠ M erzeugt, wird auch Spurious Key genannt (davon gibt es entsprechend A − 1 Stück).

146

4  Einführung in die Kryptografie

Beispiel.

Ein Chiffrierverfahren verwendet einen Schlüssel der Länge 128 Bits. Der Chiffretext habe die Länge |C| = 40 und die Redundanz der Sprache sei etwa 3. Somit ist A = 2128−40⋅3 = 256 Schlüssel. Entsprechend gibt es in etwa A − 1 = 255 Spurious Keys. ◄

4.7.6 Unizitätsdistanz Die Unizitätsdistanz (engl. Unicity Distance) U ist ein Näherungswert für die Menge verschlüsselten Texts, die benötigt wird, damit der Erfolg von einem Brute-Force-Angriff in dem Sinne unwahrscheinlich ist, dass mehr als ein einziger möglicher Plaintext samt zugehörigem Schlüssel gefunden wird. Anders formuliert, ein Chiffretext, der länger als U Symbole ist, könnte wahrscheinlich nicht zu mehreren plausiblen Klartexten führen. Die Anzahl der Spurious Keys ist in diesem Fall wahrscheinlich Null. U kann hergeleitet werden, indem bei der Formel zur Berechnung der Spurious Keys der Exponent auf Null gesetzt wird, weil A = 20 = 1 ist und dieser eine Schlüssel der tatsächliche Schlüssel, also kein Spurious Key, ist:

H(|K|) − nD = 0 H(|K|) = nD n = H(|K|) = U. D Geht D (die bereits eingeführte Redundanz einer Sprache) gegen Null beziehungsweise ist |K| sehr groß, dann ist ein Kryptosystem recht sicher, da U sehr groß wird. Beispiel Vigenère-Chiffre mit 3-Zeichen-Schlüssel: Für eine Vigenère-Chiffre gibt es  maximal | ||K| Schlüssel (also 263 = 17576). Dann ist H(|K|) =log2(17576) = 14,1. Ein natürlicher Text hat etwa D = 3,5. Somit:

U =

14,1 3,5

= ca. 4 Zeichen

Wenn der Text länger ist, wird ein Brute-Force-Angriff wahrscheinlich kein plausibles M′≠ M mehr erzielen. Anders formuliert heißt das: Ein Brute-Force-Angriff führt sehr wahrscheinlich zum korrekten M, sobald die Nachricht ≥ 4 Zeichen lang ist. Beispiel One-Time-Pad: Die Anzahl der Schlüssel für ein One-Time-Pad ist unendlich [21], denn sie wächst mit steigender Nachrichtenlänge gegen unendlich [26], und daher gilt:

U=

log2 (26|M| ) → ∞. 3,5

4.8 Kryptografische Hashfunktionen

147

Es kann also maximal viel plausibler Klartext erzeugt werden, da eine Nachricht unendlich lang sein müsste, um einen aus Angreifersicht erfolgreichen Brute-Force-Angriff durchzuführen, das heißt um das echte M statt nur irgendein M′≠ M zu erhalten.

4.8 Kryptografische Hashfunktionen Hashfunktionen sind zunächst einmal nicht notwendigerweise zur Kryptografie gehörig. Sie wurden in der Mitte des vergangenen Jahrhunderts vom IBM-Mitarbeiter und 1896 in Deutschland geborenen Hans Peter Luhn erfunden [29].  Eine Hashfunktion H, enthält eine Eingabe des Alphabets beliebiger Länge (etwa eine Textdatei), also das Urbild, und erzeugt daraus einen Hashwert h fester Länge n = |h|, etwa ‚24988892bfc53b18b6d0fcc6ccbb9b59‘.

h:

∗

→

n

,n ∈ N

Der Hashwert ist ein Komprimat im Sinne einer Prüfsumme [34], wobei auch die Bezeichnung Hashsumme geläufig ist. Weitere mögliche Bezeichnungen für h sind Fingerabdruck (engl. Fingerprint) und Message Digest. Die typische Länge von n beträgt bei den meisten modernen Hashfunktionen zwischen 224–512 Bits.

4.8.1 Einweg-Hashfunktionen Ist H eine Einweg-Hashfunktion, dann bedeutet das, dass zu einem gegebenen M die Berechnung von H(M) einfach ist, umgekehrt aber die Berechnung von einem gegebenen h zu einem M, wobei wie oben h = H(M) gilt, schwierig ist. Entsprechend sind EinwegHashfunktionen nicht bijektiv. Zwar kann jeder Eingabe ein Hashwert zugewiesen werden, doch ist dieser Hashwert für verschiedene Eingaben identisch. Entsprechend kann aus dem Hashwert nicht auf die ursprüngliche Eingabe geschlossen werden, da für jeden Hashwert mehrere Eingaben infrage kommen. Anstelle des Wortes Einweg-Hashfunktion wird manchmal auch von einer kryptografischen Hashfunktion, einem Message Integrity Code, einem Manipulation Detection Code, einer Footprint-Funktion oder einem kryptografisches Prüfsummenverfahren gesprochen [24].

4.8.2 Kollisionsresistenz Es gibt noch einen weiteren wichtigen Begriff im Zusammenhang mit kryptografischen Hashfunktionen: Wenn es sehr schwierig ist, zu einem gegebenen M eine beliebige

148

4  Einführung in die Kryptografie

Nachricht M′ (wobei gilt: M ≠ M′) zu berechnen mit H(M) = H(M′), dann ist die Eigenschaft der Kollisionsresistenz erfüllt [25]. Schmeh erwähnt zwei wichtige Voraussetzungen für Kollisionen [24]: Probiert man alle Urbilder durch, dann sollte jeder Hashwert etwa gleich oft vorkommen. Der Hashwert sollte sich auch bei kleinen Änderungen des Urbilds ändern.

Ganz unbekannt ist Ihnen diese Anforderung nicht, da Sie sie bereits durch die Diffusion bei DES kennen. Wenn nur ein einziger Buchstabe von M verändert wird, verändert sich die gesamte Nachricht. Am Beispiel von MD5 lässt sich dies demonstrieren.

Die SHA1-Prüfsumme ist länger, als die von MD5, doch auch sie wird bei der kleinsten Änderung von M stark modifiziert:

Bei Buchmann [8] und Wätjen [34] wird die Kollisionsresistenz noch in die sogenannte schwache Kollisionsresistenz (engl. Second Preimage Resistant Function) und die sogenannte starke Kollisionsresistenz (engl. Collision Resistant Function) unterteilt. Der Unterschied liegt darin, dass es bei einer schwach kollisionsresistenten Funktion praktisch unmöglich seien muss, für ein gegebenes M ein M′ zu finden, für das gilt H(M) = H(M′), M ≠ M′). Bei einer starken Kollisionsresistenz muss es rechnerisch auch praktisch unmöglich sein, diese Bedingung mit einem beliebigen M zu erfüllen. Bei einem Chosen-Prefix-Angriff will ein Angreifer eine Hashkollision für die Originalnachricht p1 (sog. Prefix) mit der Falschnachricht p2 erzeugen. Dazu fügt er durch Ausprobieren möglichst viele Strings (s1 und s2) nach der eigentlichen Nachrichten an, sodass durch Ausprobieren irgendwann eine Kollision in der Form

H(p1 ||s1 ) = H(p2 ||s2 ) zustande kommt.

4.8  Kryptografische Hashfunktionen

149

4.8.3 Geburtstagsangriff und Substitutionsattacke Ein eng mit kryptografischen Hashfunktionen zusammenhängendes Problem der Statistik ist der sogenannte Geburtstagsangriff. Die Idee hierfür basiert auf dem mathematischen Geburtstagsparadoxon (auch bekannt als Geburtstagsproblem). Das Geburtstagsparadoxon basiert auf folgender Überlegung und Fragestellung: Angenommen es gibt einen Raum, in dem sich eine bestimmte Anzahl von Personen befindet. Wie viele Personen müssen in diesem Raum sein, damit mit einer Wahrscheinlichkeit von mindestens 50 % eine Person an einem bestimmten Tag Geburtstag hat? Es sind 253 Personen notwendig, denn die Wahrscheinlichkeit dafür, Geburtstag an Tag x zu haben, ist P = 1∕365 = 0, 274 %. Die Wahrscheinlichkeit dafür, nicht an Tag x Geburtstag zu haben ist entsprechend y = 1 − P = 0.99726. Und durch Ausprobieren ergibt sich leicht y253 = 49, 9948 %. An dieser Stelle ist weniger die Zahl an sich, als vielmehr ihr Verhältnis zu einer anderen Zahl von Bedeutung: Formuliert man die Frage nämlich leicht um, so dass man nicht mehr die nötige Personenzahl zu einem bestimmten Geburtsdatum sucht, sondern die Anzahl von Personen sucht, bei denen zwei Personen am gleichen Tag Geburtstag haben (dies kann nun jeder Tag des Jahres sein), dann werden nur 23 Personen benötigt [20]. Die Anzahl möglicher Geburtstagskombinationen bei n Personen ist m = 365n. Davon haben u = 365!∕(365 − n)! einen unterschiedlichen Geburtstag. Die Wahrscheinlichkeit für mindestens einen doppelten Geburtstag beträgt somit P = 1 − u∕m, womit sich für n = 23 eine Wahrscheinlichkeit von ca. 50 % ergibt [33]. Hashfunktionen werden unter anderem (allerdings in Verbindung mit weiteren kryptografischen Funktionen) zur Überprüfung von elektronischen Dokumenten verwendet. Auch hier spielt das Geburtstagsparadoxon eine Rolle: Angenommen, unsere Angreiferin Mallory möchte zu einem Kaufvertrag K eine Fälschung Q mit für sie günstigeren Konditionen erstellen. Beide Kaufverträge (Original und Fälschung) sollen denselben Hashwert liefern. Möglichkeit 1 (schwache Kollisionsresistenz): Mallory sucht ein Q, für das gilt: H(Q) = H(K) unter der Bedingung, dass Q ≠ K ist. Zu diesem Zweck führt Mallory einen Brute-Force-Angriff aus, das heißt sie probiert sämtliche Modifikationsmöglichkeiten durch, bis sie eine Kollision findet. Zu diesem Zweck führt sie möglichst subtile Modifikationen an K durch (beispielsweise Einfügen von Whitespaces). Bei einer guten Hashfunktion, wird es sehr schwierig, diesen Angriff erfolgreich durchzuführen. Möglichkeit 2 (starke Kollisionsresistenz): Mallory erstellt eine beliebige Anzahl entsprechend unsichtbar verschiedener Dokumente K1 bis Kn und versucht mit einer beliebigen Anzahl von unsichtbar modifizierten Dokumenten beziehungsweise geringfügig modifizierten Dokumenten (etwa durch unsichtbare Kommentare oder sinngemäß ersetzte Wörter [24]) Q1 bis Qm eine Kombination (Ki, Qj) zu finden, bei denen der Hashwert übereinstimmt. Er unterzeichnet anschließend das zum Qj passende Ki. Man spricht in diesem Fall von einer Substitutionsattacke [24]. Es muss also gelten: H(Ki) = H(Qj). Da – wie beim Geburtstagsparadoxon – nun eine höhere Anzahl an Hashwerten (beziehungsweise Geburtstagen) zur Wahl steht, gibt es auch eine höhere Anzahl von Dokumentenpaaren, bei denen die Hashwerte übereinstimmen.

150

4  Einführung in die Kryptografie

4.8.4 Hashwertlänge im Kontext von Angriffen Interessant sind im Kontext des Geburtstagsangriffs zwei historische Aussagen zur Hashwertlänge. Wätjen kam 2002 zu folgendem Schluss: Ein 40 Bits großer Fingerabdruck wäre sehr unsicher, da eine Kollision mit Wahrscheinlichkeit 1∕2 bei etwas über 220 (etwa einer Million) zufälligen Wahlen […] gefunden würde. Die minimale Größe eines Fingerabdrucks sollte schon 128 Bits sein […] [34].

Schneier kam bereits 1996 zu einem ähnlichen Fazit: Hashfunktionen mit 64 Bits sind einfach zu klein, um einem Geburtstagsangriff zu widerstehen. Die meisten Einweg-Hashfunktionen in der Praxis liefern Hashwerte mit 128 Bit. Das zwingt Angreifer, die mit einer Geburtstagsmethode arbeiten, 264 Dokumente zu untersuchen, um zwei mit dem gleichen Hashwert zu finden [25].

Schneier kam zudem zum Schluss, dass 128 Bits langfristig nicht genug seien. Nun stammen diese Aussagen von Wätjen und Schneier aus den Jahren 2002 und 1996. Mit der Zunahme an Rechenleistung ist es allerdings immer einfacher, Kollisionen bei Hashfunktionen zu finden. Entsprechend müssen Algorithmen und auch die Längen der Hashwerte kontinuierlich angepasst werden. Heute (Stand: Frühjahr 2018) gelten Hashfunktionen wie SHA-2 und SHA-3 mit Hashwertlängen ab 224 Bits als sicher. Das folgende Listing veranschaulicht Ihnen Beispielhashwerte der Algorithmen MD5, SHA1 und SHA2 (mit verschieden langen Hashwerten):

Die folgende Tab. 4.2 listet die wichtigsten Hashfunktionen samt der Länge ihrer Hashwerte auf. Manche Hashfunktionen gibt es in mehreren Varianten, sodass sie mehr als eine Hashwertlänge unterstützen. Kürzere Hashwerte benötigen weniger Speicher und Rechenleistung, was bei sehr großen Datenmengen oder leistungsschwachen

4.8  Kryptografische Hashfunktionen

151

Tab. 4.2  Hashwertlängen bedeutsamer Hashfunktionen Algorithmus

Hashwert-Länge

MD2 (Message Digest)

128 Bits

MD4

128 Bits

MD5

128 Bits

MD6

1-512 Bits (variabel)

SHA (Secure Hash Algorithm)

160 Bits

SHA-1

160 Bits

SHA-2

256, 384 und 512 Bits

SHA-3

224, 256, 384 und 512 Bits

RIPEMD-128

128 Bits

N-Hash

128 Bits

RIPEMD-160

160 Bits

Snefru

128 Bits

HAVAL

128, 160, 192, 224 und 256 Bit

Systemen einen Vorteil bieten kann. Wenn Speicher und Performance keine Rolle spielen, sollte die Wahl auf einen längeren Hashwert fallen.

4.8.5 Wörterbuchangriff (Brute-Force-Angriff) Beim Wörterbuchangriff, auch Brute-Force-Angriff genannt, wird versucht, ein einzelnes Wort beziehungsweise einen einzelnen String s1 zu einem gegebenen String s2 zu finden, sodass gilt: H(s1) = H(s2). Dieser Angriff führt speziell bei kurzen Zeichenfolgen oft zum erwünschten Erfolg, etwa bei kurzen Passwörtern in Passwortdateien unter Linux, BSD und Unix (siehe Abschn. 4.8.10). Um möglichst schnell auf ein verwendetes Passwort zu schließen, werden zunächst Wörterbücher mit besonders häufigen Passwörtern durchprobiert. Ein typisches Tool, das dabei zum Einsatz kommt, ist John the Ripper [16].

4.8.6 Hashwerttabellen und Regenbogentabellen Hashwerttabellen (engl., Hashtables, siehe Tab. 4.3) sind vorberechnete Tabellen, die Nachrichtentexte und Hashwerte gegenüberstellen [24]. Auf diese Weise ist es möglich, von Hashwerten mit vergleichsweise geringem Aufwand auf einen potenziellen ursprünglichen Nachrichtentext zu schließen.

152 Tab. 4.3  Beispiel: Auszug aus einer Hashwerttabelle

4  Einführung in die Kryptografie Klartext

Hashwert

aaa

3435h45g0q38fn

aab

4j03gj34h04faM

aac

vMng2Qxjvvjpi9

…

…

Da Hashwerte allerdings zahlreich und Klartextnachrichten ebenfalls zahlreich sind, ist zum einen viel Speicher und zum anderen nach wie vor viel Rechenzeit von Nöten, um mit dieser Methode einen erfolgreichen Angriff durchzuführen. Außerdem wird es keine Tabellen geben, die alle möglichen Klartextnachrichten samt deren Hashwerten beinhalten, da Nachrichten beliebig lang sein können. Hashwerttabellen eignen sich daher vielmehr als Alternative zu Brute-Force-Angriffen, wenn es darum geht, von Hashwerten zu kurzen Strings (etwa Passwörter) zu gelangen. Eine verbesserte Technik basiert auf der Generierung von sogenannten Regenbogentabellen (engl. Rainbow Tables). Diese Tabellen bestehen aus n Spalten und verwenden Reduktionsfunktionen. Die Reduktionsfunktion i wird im Folgenden mit Ri bezeichnet. Mallory berechnet aus dem Plaintext einen Hashwert, wendet danach die erste Reduktionsfunktion auf den Hashwert an, hasht das Ergebnis wieder usf. (siehe Tab. 4.4). Gespeichert werden nur die Spalten 1 und n: R ist dabei natürlich keine Umkehrfunktion von H. Stattdessen bildet R einen Hashwert h auf einen Plaintextwert ab. Beispielsweise kann R einfach die ersten acht Zeichen von h abschneiden. Gute Reduktionsfunktionen arbeiten allerdings möglichst kollisionsfrei. Die Werte einer Tabellenzeile werden als Kette oder Chain bezeichnet.

4.8.6.1 Vorgehen bei einem Angriff Schritt 1: Mallory durchsucht zunächst die letzte Spalte der Rainbow Table und vergleicht diese Spalte mit dem gesuchten Hashwert h. Ist der gesuchte Hashwert in der Spalte enthalten (in Tab. 4.5 ), berechnet sie durch den Wert von Spalte 1 (das heißt P1 derselben Zeile) alle Werte der Zeile bis zur vorletzten Spalte (in Tab. 4.5 ) und erhält somit den gesuchten Plaintext (dieser ist Pn, da offensichtlich gilt: H(Pn) = h). Schritt 2: Falls der gesuchte Hashwert nicht in der letzten Spalte gefunden wurde, ruft Mallory die letzte Reduktionsfunktion Rn−1 mit dem Hashwert h auf und prüft, ob der Hashwert von diesem Ergebnis (also H(Rn−1(h))) nun einem H(Pn) der Rainbow Table entspricht.12 Nun können zwei verschiedene Fälle eintreten:

12Anm.: Mallory geht also einen Schritt nach links in der Tabelle und muss die Tabellenwerte zunächst berechnen, da sie diese nicht gespeichert hat.

4.8  Kryptografische Hashfunktionen

153

Tab. 4.4  Beispiel einer Rainbow Table P1

h1 =  H(P1)

P2 =  R1(h1)

.. ..

Pn−1 =  Rn−2(hn−2)

hn−1 =  H(Pn−1)

Pn =  Rn−1(hn−1)

hn =  H(Pn)

aaaa

h3Gm

dEfg

..

v84b

m2uh

3hjk

MeR2

3y16

LK × G

1 × fg

..

mMJQ

jjQ1

UUqn

..

..

..

9 × 4B

..

..

..

..

..

Tab. 4.5  Rainbow Table von Mallory

1. Mallory findet ein passendes H(Pn), das ihrem H(Rn−1(h)) entspricht. Das heißt, der Hashwert befindet sich in der entsprechenden Zeile und entspricht hn−1. Sie berechnet nun analog zu Schritt 1 die Werte der Zeile ausgehend von P1, bis sie zum gesuchten Pn−1 kommt, das ihr H(Pn−1) = hn−1 = h liefert. Dieses Pn−1 ist ihr gesuchtes Passwort. 2. Falls der neue Hashwert erneut keinem H(Pn) entspricht: Schritt 2 analog wiederholen, indem sie die vorletzte Reduktionsfunktion geschachtelt aufruft und die Tabelle weiter „rückwärts“ (nach links) berechnet, also: H(Rn−1(H(Rn−2(h)))). Erneut testet sie, ob das Ergebnis einem H(Pn) entspricht. Falls dem nicht so ist, schachtelt sie die nächsthöhere Reduktions- und Hashfunktion wieder analog zu Schritt 2 usf., bis sie einen passenden Hashwert gefunden hat oder an der ersten Spalte angelangt ist (dann hätte sie alle vorhandenen Reduktionsfunktionen durchprobiert). 3. Falls Mallory die linke Seite der Tabelle erreicht hat und keinen passenden Wert gefunden hat, der letztlich h erzeugt, befindet sich das gesuchte Passwort nicht in der Rainbow Table. Effizienz von Rainbow Tables: Bei Rainbow Tables müssen deutlich weniger Daten gespeichert werden, als bei einem Hashtable. Die Rückberechnung erfolgt gegenüber einem Hashtable verhältnismäßig effizient. Das Suchen nach Passwörtern kann jedoch noch immer extrem viel Zeit in Anspruch nehmen. Typische Programme für Rainbow Tables sind RainbowCrack und DistrRTgen, letzteres verwendet sogar einen verteilten Rechenansatz.

4.8.7 Sicherheit von Hashfunktionen Für einige Hashalgorithmen sind zumindest teilweise kryptoanalytische Angriffe geglückt. Als regelrecht unsicher gelten N-Hash, Snefru und MD4. Auch MD2 gilt als

154

4  Einführung in die Kryptografie

unsicher. Für RIPEMD wurden Kollisionen beschrieben und MD5 gilt ebenfalls als hochgradig unsicher. Seit etwa 2005 gilt auch SHA-1 als unsicher. Doch insbesondere seit der Anfang 2017 veröffentlichten Kollision SHATTERED, die durch einen praktischen Angriff hervorgerufen wurde, ist klar, dass SHA-1 keine Verwendung mehr finden sollte. Im Rahmen von SHATTERED wurden zwei Dokumente erzeugt, die zum selben SHA-1-Hash führten, wofür allerdings noch immer einige Tausend CPU-Rechenjahre notwendig waren. Diese vielen Tausend Rechenjahre sind durch die Möglichkeiten des Parallel Computings (beispielsweise in einer Cloud) beziehungsweise durch die Ausnutzung von Bots in Botnetzen jedoch in den Bereich des Realistischen gerückt. Somit können viele Tausend Computer parallel an einer riesigen Aufgabe wie dem Finden von SHA1-Kollisionen arbeiten – in vertretbarer Zeit. Durchgeführt wurde das entsprechende Projekt von Wissenschaftlern der Universität Amsterdam und Google; sie schätzten die Kosten zum Auffinden einer SHA-1-Hashkollision auf etwa 75.000 bis 120.000 USD, weshalb das BSI den Einsatz von neueren Alternativen wie SHA-2 empfiehlt [9]. 2019 wurde dann ein Chosen-Prefix-Angriff (siehe Abschn. 4.8.2) für SHA-1 beschrieben und 2020 wurde bekannt, dass ein solcher Angriff auch experimentell durchgeführt wurde. Die Kosten lagen bei etwa 75.000 USD. SHA-2 gilt bisher noch als sicher und der Einsatz des Nachfolgers SHA-3 wird vom NIST empfohlen. SHA-3 wurde, wie AES, durch eine Ausschreibung des NIST bestimmt, bei dem (erneut) belgische Wissenschaftler eine Schlüsselrolle spielten.

4.8.8 Aufbau einer typischen Hashfunktion Viele Hashfunktionen (ausgenommen ist etwa SHA-3) basieren auf dem sogenannten Merkle-Damgård-Verfahren. Eine Nachricht wird dabei in n Blöcke gleicher Länge zerlegt (der letzte Block wird, falls notwendig, aufgefüllt). Die Hashfunktion wird mit einem Initialisierungsvektor I in Runde 0 initialisiert (H(0) = I) und anschließend wird rundenbasiert f aufgerufen. Dabei ist f eine Kompressionsfunktion, die meistens recht einfache Bitoperationen anwendet und die Nachricht auf eine feste Länge bringt. Das Ergebnis der Runde i − 1 wird mit Block M(i) zum Ergebnis der Runde i verrechnet:

H(i) = f (M(i), H(i − 1)). Diese Berechnung wird für alle n Blöcke durchgeführt.

4.8.9 Message Authentication Codes (MAC) Bei Message Authentication Codes (kurz MACs) handelt es sich um kryptografische Hashfunktionen, die von Schlüsseln abhängig sind. Die Verifizierung des Hashwertes

4.8  Kryptografische Hashfunktionen

155

Abb. 4.10   Funktionsweise eines MAC

Sehr geehrte Frau Schmitt, bitte überweisen Sie 75.000 EUR auf das Konto 7696813. MfG Max Musterchef

Sehr geehrte Frau Schmitt, bitte überweisen Sie 10.236 EUR auf das Konto 1234567. MfG Max Musterchef

K

H

082jcE9t

K

H

xzZAX900

ist entsprechend nur mit Hilfe des Schlüssels möglich. Mit MACs sind etwa Überprüfungen von Dateien auf Veränderungen möglich (siehe Abb. 4.10). Im Gegensatz zu Hashfunktionen muss einem Angreifer hierfür allerdings auch der entsprechende Schlüssel bekannt sein. Im Folgenden werden einige besonders bedeutsame MACFunktionen besprochen.

4.8.9.1 HMAC (Hashed MAC) Für HMAC wird HMACK(M) = H((K ⊕opad)||H((K ⊕ipad)||M)) berechnet, wobei K zum Erreichen der Blockgröße (64 Bytes) bei Bedarf mit Nullen aufgefüllt wird. Sollte K länger sein, wird es mit einer Hashfunktion (in RFC 2104 wurde MD5 verwendet [19], was in RFC 6151 schließlich nicht mehr vorgesehen wurde [30]) verkürzt. ipad und opad (inner und outer pad) sind Konstanten in Blockgröße (repetitiv 0 × 5c beziehungsweise 0 × 36), die so gewählt wurden, dass sie eine hohe Hamming-Distanz aufweisen [5]. 4.8.9.2 CBC-MAC (Chipher Block Chaining MAC) CBC-MAC verwendet eine Blockchiffriertechnik im CBC-Modus (siehe Abschn. 4.6.3 zu Betriebsmodi von Blockchiffren), die somit eine Verkopplung der zu verschlüsselnden Blöcke darstellt. CBC-MAC erstellt also einen MAC aus einer Blockchiffre. Als Initialisierungsvektor (IV) wird 0 verwendet (der erste Block von M wird folglich zunächst mit ⊕ 0 und anschließend mit ⊕ K verrechnet: c0 = (m0 ⊕ 0) ⊕ K). Im Anschluss wird das jeweilige ci mit dem folgenden mi+1 verrechnet, sodass ci = ((mi ⊕ ci−1) ⊕ K). 4.8.9.3 Counter Mode mit CBC-MAC (CCM/CCM*) Der CCM-Mode sichert neben der Vertraulichkeit auch die Integrität von Nachrichten. Dazu wird ähnlich wie bei CTR-Modus verfahren. Allerdings wird zusätzlich der CBCMAC-Algorithmus verwendet. Die Spezialvariante CCM* wird bei ZigBee eingesetzt.

156

4  Einführung in die Kryptografie

CCM* bietet zusätzlich die Option, entweder ausschließlich Integritätsschutz oder ausschließlich Vertraulichkeitsschutz zu nutzen.

4.8.9.4 Weitere MAC-Verfahren Es existieren noch einige weitere Modi für Blockchiffren, die teilweise auch in Verbindung mit Message Authentication Codes verwendet werden, insbesondere sind dies der Galois/Counter Mode (GCM, sichert die Authentizität und Vertraulichkeit übertragener Daten), die GCM-Variante Galois Message Authentication Code (GMAC), die ausschließlich die Authentizität übertragener Daten sichert, und XCBC-MAC (CBCMAC mit Erweiterungen, siehe RFC 3566). 4.8.9.5 MAC aus einer Einweg-Hashfunktion konstruieren Die Umwandlung von einer schlüssellosen Einweg-Hashfunktion in eine MAC ist dadurch möglich, dass man den Hashwert mit einem symmetrischen Algorithmus (…) chiffrier(t) [25], etwa DESk(H(M)). Auch die „Umwandlung“ einer MAC in eine Einweg-Hashfunktion ist theoretisch denkbar, dazu muss deren Schlüssel veröffentlicht werden [25].

4.8.10 Hashfunktionen und Unix-Passwortdateien Unter Unix-Systemen und unixartigen Systemen werden Passwörter in einer gesicherten Datei (meist /etc/shadow (etwa Linux, Solaris und die meisten anderen verwandten Systeme) oder /etc/master.passwd (etwa OpenBSD)) gespeichert. Jeweils eine Zeile der Datei definiert durch Doppelpunkte getrennte Attribute eines Benutzeraccounts. Eines dieser Attribute (im Normalfall der zweite Wert einer Zeile) ist der Hash des Benutzerpassworts. Solche Passwörter können meist recht schnell (wenige Stunden bis Tage an Rechenzeit) durch den oben beschriebenen Brute-Force-Angriff erraten werden. Passwörter werden durch das Hinzufügen von Zusatzzeichen (dem sogenannten Salt) und durch die Zunahme der Zeichenlänge schwerer zu erraten. Tatsächlich wird anstelle von H(Passwort) das Tupel (S, H(S, Passwort)) gespeichert, wobei S der Salt ist. Ohne Salt würden alle gleichen Passwörter auf jedem System die gleichen Hashwerte erzeugen, sofern die gleiche Funktion H verwendet würde. Auch die Verwendung von Einmalpasswörtern (One-Time-Passwords), etwa via S/ Key (vgl. [22]), oder auch das mehrfache Aufrufen einer Hashfunktion (Hash-Iteration, vgl. [24]) kann die Sicherheit von Passwörtern verbessern. Im Normalfall verwendet die dabei eingesetzte Funktion crypt(3) beispielsweise den AES-Algorithmus für Unix-Passwörter (der Schlüssel wird beim Funktionsaufruf übergeben). Werden die ersten beiden Zeichen des setting-Strings (beziehungsweise des salt-Parameters) entsprechend gewählt, so lässt sich ein Hashalgorithmus angeben, etwa “$1” für MD5, “$2a” für Blowfish, “$5” für SHA-256 und “$6” für SHA-512.

4.8  Kryptografische Hashfunktionen

157

4.8.11 Hashfunktionen und Filesystem Intrusion Detection Ein System zur Angriffserkennung für Dateisysteme wird als Filesystem Intrusion Detection System (FIDS) bezeichnet. Ein FIDS erkennt Veränderungen im Dateisystem. Veränderungen können unter Umständen die Folge von Angriffen sein. So könnte sich etwa ein neuer Benutzeraccount in der Passwortdatei eines Linux-Systems befinden. Typische Tools für FIDS sind etwa mtree, tripwire oder AIDE. Diese Tools bilden eine Datenbank sämtlicher Hashes von Dateien im Dateisystem, etwa mit den Hashalgorithmen Tiger, MD5, SHA-2 oder GOST, sowie zugehöriger Metainformationen (Dateigröße, Zeit der letzten Modifikation, des letzten Zugriffs und der Dateierzeuung). Veränderungen seit der letzten Überprüfung des Dateisystems werden dem Anwender aufgezeigt, sodass er die Möglichkeit hat, diese zu überprüfen. Das in Abb. 4.11 dargestellte Beispiel zeigt die grundlegende Verwendung des Tools mtree unter OpenBSD. Dabei werden zunächst mit dem SHA-2-Algorithmus die Metadaten des Verzeichnisses /etc eingelesen. Anschließend wird ein Angriff simuliert, indem eine leere Datei (touch exploit.sh) im Verzeichnis /etc/ppp versteckt wird. Beim nächsten Durchlauf des Programms wird die neue Datei sogleich detektiert (extra: ppp/exploit.sh). Außerdem wird von mtree angezeigt, dass das Verzeichnis ppp modifiziert wurde (da die neue Datei dort angesiedelt wurde).

4.8.12 Hashfunktionen und Software Ports Auch bei Port-Systemen werden Hashfunktionen eingesetzt. Ein Port ist in diesem Sinne keine Portierung einer Software, sondern ein Softwarepaket, das vom Anwender über Skripte/Programme auf seinem Rechner erstellt wird. Solche Port-Systeme gibt es etwa unter OpenBSD (ports), NetBSD (pkgsrc), FreeBSD und Gentoo-Linux. In einem Port sind Patches, Skripte, Abhängigkeiten und Parameter zum Kompilieren sowie Hashwerte der Quellpakete vorhanden. Stößt der Anwender das Erstellen eines Ports an, so wird das Quellarchiv (in der Regel vom Server des Anbieters, etwa http:// gnu.org für GNU-Software) heruntergeladen.

Abb. 4.11   Das Programm mtree findet Differenzen zwischen einem aufgezeichneten und einem aktuellen Zustand eines Verzeichnisses

158

4  Einführung in die Kryptografie

Um Manipulationen der Quellpakete auszuschließen, wird der in den Portinformationen enthaltene Hashwert mit dem Hashwert des soeben heruntergeladenen Quellarchivs verglichen. Nur dann, wenn beide Werte übereinstimmen, wird ein Buildvorgang fortgesetzt. OpenBSD etwa enthält für jeden Port eine distinfo-Datei, in der Hashwerte und Dateigröße eines Archivs hinterlegt sind. Früher wurden diverse Hashwerte kombiniert und nur dann, wenn alle Hashwerte überprüft wurden und übereinstimmen, wurde ein heruntergeladenes Paket entpackt. Mittlerweile wird nur noch SHA-2 mit einem Hashwert der Länge 256 Bits verwendet. SHA256 (asterisk-1.8.30.0.tar.gz) = XyW1X5OPqq6dwnmrryeO9ptk17OGUouOUx4jUuzBOnw= SIZE (asterisk-1.8.30.0.tar.gz) = 29540685

4.8.13 Hashfunktionen und Hashbäume Hashbäume werden mit dem Ziel eingesetzt, Performancegewinne bei der Überprüfung von Hashwerten großer Datenmengen zu gewinnen. Ziel ist es daher, möglichst wenige Vergleiche von Hashwerten durchführen zu müssen. Angenommen, Alice und Bob betreiben Replikas einer Datenbank und in der Datenbank von Alice ergab sich eine Änderung. Bob soll effizient überprüfen können, ob es auch in seiner Datenbank zu dieser Änderung kam. Die Lösung dieses Problems, der Hashbaum, sieht folgendermaßen aus: Alice erzeugt von jedem Datensatz D0 bis Dn einen Hashwert H0 = H(D0), …, Hn = H(Dn). Von den Hashwerten werden immer paarweise weitere Hashwerte erzeugt, sodass eine Hierarchie entsteht (Abb. 4.12). Letztlich wird in der höchsten Hierarchieebene nur noch ein finaler Hashwert erzeugt. Falls eine ungerade Zahl von Datensätzen vorliegt (und somit für den letzten Datensatz kein Hashwertpaar erzeugt werden kann), wird der letzte Hashwert auf Ebene 1 auf den Hashwert des letzten Datensatzes gesetzt [24].

Abb. 4.12   Schematischer Aufbau eines Hashbaums

4.9 Asymmetrische Kryptografie

159

Es könnte nun beispielsweise sein, dass sich in der Datenbank von Alice der Datensatz i verändert hat. Um nun effizient Datenbankänderungen zwischen Replikas auf Übereinstimmung zu prüfen, berechnet Alice die Hashwerte, die hierarchisch mit Datensatz i verbunden sind, neu. Am Ende dieser Berechnungen steht ein neuer, finaler Datensatz. Diesen sendet Alice an Bob (etwa in signierter Form, sodass der Hashwert nicht unbemerkt verändert werden kann). Ausgehend von dem auch in Bobs Datenbank modifizierten Datensatz i berechnet er die Hashwerte bis zum finalen Hashwert neu. Im finalen Schritt überprüft Bob letztlich, ob der eigene finale Hashwert dem erhaltenen Hashwert von Alice aus der Replika-Datenbank entspricht.

4.9 Asymmetrische Kryptografie Im Unterschied zu symmetrischen Verfahren, bei denen mit demselben Schlüssel verschlüsselt wie entschlüsselt wird, werden bei einem asymmetrischen Verfahren beide Schlüssel getrennt. Alice verschlüsselt eine Nachricht an Bob mit dem öffentlichen Schlüssel (Public Key) kpub von Bob. Mit dem privaten Schlüssel (Private Key) kpriv entschlüsselt Bob diese Nachricht wieder: C = E(Kpub, M) und M = D(Kpriv, C). Der öffentliche Schlüssel kann bekannt gegeben werden, während der private Schlüssel geheim bleibt. ein symmetrisches Verschlüsselungsverfahren mit N Teilnehmern werden N Für N·(N−1) = Schlüssel benötigt. Im Falle der Pubic-Key-basierten Kryptografie werden 2 2 hingegen nur N Schlüsselpaare benötigt – jeweils bestehend aus einem Private Key und einem Public Key. In der Regel benötigt Public-Key-Kryptografie allerdings längere Schlüssel und ist langsamer als symmetrische Kryptografie.

4.9.1 Schlüsselaustausch Bei einem symmetrischen Algorithmus schickt Alice ihren Schlüssel an Bob oder vice versa. Der Schlüssel kann dabei zum Beispiel ausgedruckt auf Papier, auf einer CDROM oder auf einem USB-Stick übergeben werden. Anschließend verwenden Alice und Bob denselben Schlüssel für die Ver- und Entschlüsselung der Kommunikation untereinander. Bei einem asymmetrischen Algorithmus schickt Alice ihren öffentlichen Schlüssel kAlice−pub an Bob und Bob schickt seinen öffentlichen Schlüssel kBob−pub an Alice. Die jeweils privaten Schlüssel bleiben geheim und somit jeweils nur ihrem Eigentümer zugänglich. Sowohl bei symmetrischen als auch bei asymmetrischen Algorithmen erfolgt der Schlüsselaustausch über irgendeinen Kanal. Dieser Kanal kann unsicher sein, der Schlüssel kann daher ggf. abgefangen oder manipuliert werden.

4.9.1.1 Diffie-Hellman-Schlüsselaustausch Whitfield Diffie und Martin Hellman haben 1976 einen Algorithmus zum Austausch eines geheimen Schlüssels über einen unsicheren Kanal mithilfe von Public-Key-Krypto-

160

4  Einführung in die Kryptografie

grafie vorgestellt. Heute bezeichnet man das zugehörige Verfahren als Diffie-HellmanSchlüsselaustausch, wobei auch oft die Abkürzung DH verwendet wird. Diffie-Hellman oder Diffie-Hellman-Merkle?

Laut Hellman sollte der Algorithmus eigentlich nicht als Diffie-Hellman-, sondern als Diffie-Hellmen-Merkle-Schlüsselaustausch bezeichnet werden. Das folgende Zitat aus einem Aufsatz von Hellman in Communications of the ACM (2017) erläutert dies: In May 1976, Diffie and I developed the first practical, unclassified system for public key exchange, publishing both it and the public key cryptosystem concept in our paper ,New Directions in Cryptography‘ in IEEE Transactions on Information Theory, November 1976. That public key exchange system is widely known as Diffie-Hellman Key Exchange, but somewhat ironically, it is an implementation of Merkle’s public key distribution system concept, not our public key cryptosystem concept. I therefore refer to it as the ”DiffieHellman-Merkle Key Exchange [15].

Tatsächlich reichte der damalige Student Merkle seinen Aufsatz bereits vor Diffie und Hellman zur Begutachtung bei einer Zeitschrift ein. Durch Verzögerungen wurde sein Aufsatz allerdings erst später publiziert.

Beim Diffie-Hellman-Schlüsselaustausch gehen Alice und Bob folgendermaßen vor: 1. Alice und Bob einigen sich auf eine nicht geheime Primzahl p, die möglichst groß sein sollte, und einen ebenfalls nicht geheimen Wert g. 2. Alice wählt eine Zufallszahl x und sendet X = gx mod p an Bob. 3. Bob wählt eine weitere Zufallszahl y und sendet Y = gy mod p an Alice. 4. Alice berechnet k1 = Yx mod p. 5. Bob berechnet k2 = Xy mod p. Nun sind x und y geheim (private Schlüssel) und (X, Y, g, p) öffentlich. Der Clou liegt darin, dass k1 = k2, denn k1 = k2 = Yx mod p = gxy mod p = Xy mod p. Die Sicherheit des Diffie-Hellman-Schlüsselaustauschs liegt darin, dass ein Angreifer, der alle Daten des unsicheren Kanals sieht, nur die Werte (X, Y, g, p) sehen kann, jedoch nicht (x, y). Die Berechnungen werden dabei in Zp ausgeführt. Ein effizienter Algorithmus, um x oder y aus diesen Werten zu berechnen, ist bisher nicht bekannt. Das Diffie-HellmanVerfahren entspricht in diesem Sinne einer Einwegfunktion: Die Exponentialfunktion modulo p (also X y mod p = X · X · . . . · X mod p) lässt sich leicht berechnen. Die Umkehrfunktion (der diskrete Logarithmus) hingegen nur äußerst ineffizient. Das klassische Anwendungsszenario für den Diffie-Hellman-Schlüsselaustausch ist das typisches Verschlüsselungsverfahren im Internet. Asymmetrische Kryptografie ist im Vergleich zu symmetrischen Verfahren recht langsam. Der

4.9  Asymmetrische Kryptografie

161

­ iffie-Hellman-Schlüsselaustausch wird in einem solchen Verfahren verwendet, um D einen Sitzungsschlüssel für eine schnelle symmetrische Verschlüsselung über einen unsicheren Kanal auszutauschen. Beispielsweise könnte das Verfahren von Diffie und Hellman eingesetzt werden, um einen AES-Schlüssel zu übertragen, der anschließend für die Verschlüsselung der Verbindung verwendet wird.

4.9.1.2 Finden von Primzahlen Ein Kernbestandteil des Diffie-Hellman-Algorithmus sind Primzahlen. Es stellt sich jedoch die Frage, wie auf einem Computer eigenltich Primzahlen gefunden werden können. Tatsächlich sind Primzahlen auch für andere Algorithmen bedeutsam, etwa für den RSA-Algorithmus. Aus diesem Grund ist es von Belang, sich zumindest grundlegend mit dem Finden von Primzahlen zu befassen. Eine einfache für die Primzahlgeneierung angewandte Vorgehensweise ist das Sieb des Eratosthenes. Das Verfahrengeht so vor, dass zunächst eine Liste s mit n = |s| Elementen angelegt wird. Jedes Element in s steht für eine Zahl. Element 1 steht dabei für die Zahl 1, Element 2 für die Zahl 2 usw. Potenziell gilt zunächst jede dieser Zahlen, außer die 1, als eine Primzahl. Beginnend mit der 2 wird jedes Element weitere Element in s dahingehend geprüft, ob es eine Primzahl ist (also durch eine Zahl außer sich selbst und 1 ohne Rest dividiert werden kann). Alle Vielfachen der gefundenen Primzahlen werden als nicht prim markiert. Beispiel  Angenommen, s habe in einem Programm n = 10 Elemente (1–10). Das Programm setzt jedes Element außer dem ersten auf den Wert 1. Ist ein Element mit einer 1 markiert, so bedeutet dies, dass es einer potenziellen Primzahl entspricht. Zum Start ist s = 0111111111. Die 2 ist eine Primzahl. Das Verfahren geht nun so vor, dass es mit der Zahl 2 beginnt. Jeden Wert von s, der sich durch 2 ohne Rest dividieren lässt, markiert das Programm als nicht prim. Entsprechend ist s nun 0110101010. Die nächste Zahl, die das Programm nun auf ihre Primzahleigenschaft testet, ist die 3. Da sie sich nicht durch die bereits gefundenen Primzahl (2) oder eine andere bereits getestete Zahl teilen lässt (also nicht 0 ist), ist 3 eine Primzahl . Erneut streicht das Programm jedes Vielfache von 3 aus s, womit s = 0110101000 übrig bleibt. Das Programm testet die 4, sie ist in s mit einer 0 markiert und daher nicht prim. Die Vielfachen von 4 (also die 8) wurden bereits als nicht prim markiert (Vielfache der Primzahl 2). Danach testet das Programm die 5, die durch keine der bereits gefundenen Primzahlen teilbar ist und somit selbst prim ist. Das einzige Vielfache von 5 in s (nämlich 10) wurde bereits als nicht prim markiert (als Vielfaches von 2). Die 6 ist ebenfalls als nicht prim markiert. Die 7 stellt sich als Primzahl heraus, doch es gibt aufgrund der geringen Größe von s kein Vielfaches von 7 zu markieren. Die Zahlen 8, 9 und 10 sind bereits als nicht prim markiert. Alle Primzahlen in s (2,3,5,7) sind nun markiert und bekannt.

162

4  Einführung in die Kryptografie

4.9.2 Rivest-Shamir-Adleman-Algorithmus (RSA) RSA (benannt nach Ron Rivest, Adi Shamir und Leonard Adleman) ist sicherlich eines der berühmtesten Verfahren der Public-Key-Welt. Bei RSA wird zunächst ein Schlüsselpaar pro Teilnehmer generiert und dann mithilfe dieses Schlüsselpaars sicher kommuniziert. Die Sicherheit von RSA beruht auf dem Problem der Primfaktorzerlegung bei sehr großen Primzahlen in endlichen Mengen. Diese ist nämlich äußerst aufwendig. Besondere Bedeutung kommt bei RSA der ϕ-Funktion zu. Die ϕ(n)-Funktion gibt für die Zahl n an, wie viele natürliche Zahlen aus dem Bereich 1…n − 1 teilerfremd zu n sind. Zum Beispiel ist ϕ(6) = 2, denn 1 und 5 sind teilerfremd. Entsprechend gilt ϕ(3) = 2, denn 1 und 2 sind teilerfremd. Für zwei teilerfremde Zahlen a und b gilt, dass ϕ(a) ⋅ ϕ(b) = ϕ(a ⋅ b) ist. Wenn n eine Primzahl ist, dann ist ϕ(n) = n − 1. Falls n = p ⋅ q mit p, q als Primzahlen, dann gilt ϕ(n) = (p − 1)(q − 1). Für a, n ∈ N, a < n gilt zudem: a1 mod ϕ(n) = a mod n und damit: ab = a mod n, wenn b − 1 ein Vielfaches von ϕ(n) ist [10, 24]. Für ein xa = b mod n gilt: Wenn a und ϕ(n) teilerfremd sind, dann kann mit dem erweiterten euklidischen Algorithmus c = a−1 mod ϕ(n) berechnet werden. c ist dabei die Inverse zu a für mod  ϕ(n). Dies lässt sich letztlich wiederum zu x = bc mod n umformen [24]. Beide Seiten können mithilfe von c erweitert werden: (xa)c mod ϕ(n) = bc mod ϕ(n) mod n. Anschließend lässt sich die rechte Seite zu (xa)c mod ϕ(n) = bc mod n vereinfachen [24]. Da ac = 1 mod ϕ(n), ergibt die linke Seite: x1 mod ϕ(n) = bc mod n, und dies ist wiederum x = bc mod n [24]. Wenn ggT(a, n) = 1 ist, dann gibt es ein x, das invers zu a ist und daher: x = a−1 mod n. Mithilfe des erweiterten euklidischen Algorithmus kann dieses x berechnet werden.

4.9.2.1 RSA-Schlüsselgenerierung Die Generierung der RSA-Schlüsselpaare erfolgt in fünf Schritten [10, 28]: Zunächstgeneriert Alice zwei große Primzahlen, üblicherweise als p und q bezeichnet. Um p und q zu generieren, verwendet Alice einen PRNG.13 Im zweiten Schritt berechnet Alice n = p ⋅ q sowie ϕ(n) = (p − 1)(q − 1) und im dritten Schritt wählt sie ein e ∈ Z mit 1  : R e c i p i e n t a d d r e s s r e j e c t e d : U s e r unknown i n l o c a l r e c i p i e n t t a b l e

EXPN (EXPaNd) erlaubt das Auflösen von Adressen, die zu Mailinglisten gehören. Somit können Angreifer ebenfalls Mailaccounts in Erfahrung bringen. Auf den meisten Mail-Servern sind sowohl VRFY als auch EXPN entsprechend deaktiviert. Für das IMAP-Protokoll ist analog laut RFC 3501 gefordert, dass die Server bei einer fehlgeschlagenen Authentifizierung keine Rückschlüsse auf Benutzernamen zulassen [20]. Ein vernünftiger IMAP-Server hält sich an diese Vorgabe und ein simpler Test mit falscher Anmeldung schafft Klarheit über das Verhalten einer eingesetzten Serversoftware.

8.5.6 Absicherung von DHCP Die im vorherigen Kapitel besprochenen Angriffe auf DHCP, das DHCP-Spoofing und der Starvation-Angriff, können mit bereits anderweitig besprochenen Methoden eingedämmt werden. Sollte ein Angreifer ein neuer Host bzw. ein Host an einem neuen Switch-Port sein, so ließe sich seine Kommunikation durch einen MAC-Filter bzw. einen Port-Filter eindämmen. Weiterhin kann ein Angreifer nicht VLAN-übergreifend agieren, weshalb auch VLANs die Auswirkungen beider Angriffe zumindest auf das jeweilige VLAN eindämmen können. Einige Switchhersteller haben in ihre Switche auch DHCP-Snooping integriert; dabei dürfen DHCP-Konfigurationen nur von solchen Ports verschickt werden, an denen die vorgesehenen DHCP-Server angeschlossen sind. Es handel sich daher um eine Variante des Port-Filterings. Ein Angreifer könnte entsprechend kein DHCP-Spoofing betreiben, wenn er nicht an einem dafür freigeschalteten Port hängt.

8.5.7 NNTP NNTP kann insbesondere für die Reconnaissance und für Social Engineering eingesetzt werden. Angriffe auf NNTP-Server sind eher unüblich und meist recht einfach gehalten (Erraten von Benutzername und Passwort). Zwar sind NNTP-Server nicht mehr sonder-

284

8  Absicherung der Netzwerkschichten

lich weit verbreitet, doch betreiben viele Universitäten noch eigene Server und so manch ein Unternehmen wickelt den Support ihrer Produkte und Dienstleistungen per NNTP ab. Entsprechend bedeutsam ist eine Zugriffskontrolle für NNTP. Ohne diese kann jeder Benutzer alle Postings in allen Newsgroups lesen und sich in jede Kommunikation einmischen. Es gibt zwei Verfahren zur Authentifizierung: AUTHINFO USER, gefolgt von AUTHINFO PASS (jeweils mit Benutzernamen beziehungsweise Passwort als Parameter) und AUTHINFO SIMPLE (gefolgt von Benutzername und Passwort). Sicher ist keines der beiden Verfahren, da die Daten im Klartext übertragen werden. Es gibt für den NNTP-Server von Windows noch eine Erweiterung, AUTHINFO GENERIC NTLM.10 Es handelt sich dabei um ein Microsoft-eigenes Authentifizierungsprotokoll, dass auf einem Challenge-Response-Verfahren aufsetzt und zumindest in der Vergangenheit für eine Reconnaissance ausgenutzt werden konnte [21]. In jedem Fall empfiehlt sich für NNTP die Aktivierung einer verschlüsselten Verbindung über TLS. Benutzern können auch bei NNTP unterschiedliche Berechtigungen zugewiesen werden, etwa mithilfe der bekannten Access Control Lists (ACL) und Role-based Access Control (RBAC). RBAC bietet hierbei den Vorteil, dass Zugriffe nicht benutzer-spezifisch konfiguriert werden muss. Stattdessen können Benutzer zu Gruppen zugewiesen werden, etwa alle Entwickler eines Projekts X einer entsprechenden Gruppe „Projekt X“. Dieser Gruppe kann anschließend Zugriff auf alle gewünschten Newsgroups gegeben werden, was komfortabler und weniger fehleranfällig ist, als jedem Benutzer einzeln sämtliche Zugriffsrechte zu erteilen. Möglich ist auch, sogenannte unsichtbare Newsgroups (invisible newsgroups) zu verwenden. Ein Benutzer bekommt beim Auflisten der Newsgroups in solch einem Fall nur die Newsgroups zu Gesicht, auf die er auch Zugriff hat. Über die Existenz anderer Newsgroups erfährt er zunächst nichts. Dieses Feature ist allerdings nicht perfekt, da NNTP Cross-Postings erlaubt, das heißt, dass ein Posting an mehrere Newsgroups gesendet werden kann. Diese Newsgroups tauchen wiederum allesamt im Header des NNTPPostings auf und somit können unter Umständen Newsgroups bekannt werden, die einem Benutzer verwehrt sind.

8.6 Zusammenfassung Die Absicherung von Netzwerken muss schichten- und protokollweise erfolgen. Es gibt zwar generell anwendbare Maßnahmen zur Sicherung eines Netzwerks, etwa eine physikalische Zutrittskontrolle oder das Schaffen von Redundanz, doch sind dies

10NT

LAN Manager.

8.7  Weiterführende Literatur

285

die Ausnahmen. Netzwerksicherheit beginnt bereits beim Erwerb von Hardwarekomponenten und beim Aufsetzen von Diensten. Viele Angriffe basieren darauf, dass Angreifer die Netzwerkidentität (etwa SenderMAC-Adresse oder Sender-IP-Adresse) eines Dritten übernehmen, um sich somit über Beschränkungen hinwegsetzen oder Daten mitlesen zu können, die nicht für sie bestimmt sind. Derlei Angriffe können mit Authentifizierungsverfahren und signierten Adressen erschwert werden. Das Mitlesen von Daten in unverschlüsselten Netzwerken kann durch Verschlüsselung (WPA-2, IPSec, TLS) und das Manipulieren der Daten durch Integritätsschutz (ebenfalls IPSec und TLS) sichergestellt werden. Betriebssysteme bieten in der Regel diverse Einstellungen, die zur Absicherung des Netzwerkstacks dienen. Beispielsweise können nicht benötigte Protokollfunktionen, wie die Annahme von ICMP-Redirect-Nachrichten, deaktiviert werden. Netzwerkscans können mithilfe von Intrusion Detection Systemen erkannt werden. Die Absicherung der Anwendungsschicht ist besonders protokollspezifisch – ein SMTPServer kann völlig anders angegriffen werden als ein DNS-Server. Dennoch sollte nicht ausschließlich das jeweilige Netzwerkprotokoll, sondern auch der verwendete Netzwerkdienst (etwa Bind oder Apache) abgesichert werden. Zusätzliche Programme (etwa Sicherheitsscanner für Webserver oder Programme zur Verschlüsselung und Signatur von E-Mails wie PGP) können ebenfalls zur Sicherung der Anwendungsschicht verwendet werden.

8.7 Weiterführende Literatur Viele Bücher konzentrieren sich auf die Absicherung von Netzwerken aus der Sicht eines Administrators. Diese Bücher sind in der Regel spezifisch für eine Plattform verfasst, etwa Juniper- oder Cisco-Router beziehungsweise Windows-Server, Linux-Systeme oder andere. Es empfiehlt sich, diese Bücher genau zu betrachten und die jeweils eingesetzten Plattformen zu härten. Zusätzliches Know-how liefern dienstspezifische Publikationen, etwa zum Apache-Webserver oder zum Bind-Nameserver. Diese gehen in der Regel weitaus detaillierter auf die Härtung eines entsprechenden Dienstes ein, als Bücher, die eine gesamte Plattform abdecken. Aus akademischer Sicht zeichnet sich ein ebenfalls interessantes Bild. Praktisch wöchentlich werden neue, experimentelle Maßnahmen zur Detektion und Abwehr von Angriffen publiziert. Größtenteils sind diese Maßnahmen nur unter Laborbedingungen einsatzbereit, doch gibt es manchmal auch brauchbare und erprobte Module samt Code, etwa für NIDS. Die meisten akademischen Publikationen zu Schutzmaßnahmen sind in der Regel etwas anspruchsvoller, decken dafür allerdings auch den State-of-the-Art ab und liefern Erkenntnisse, die in der Praxis erst in einigen Jahren in Produkte münden. Insofern kann die akademische Literatur auch für Praktiker von Interesse sein.

286

8  Absicherung der Netzwerkschichten

8.8 Übungsaufgaben 1. Was verbirgt sich hinter der Abkürzung PAC und wozu dient es? 2. Welche fünf „Ws“ sind bei der Beschaffung von Hardware zu beachten? 3. Wie funktioniert ein MAC-Filter? 4. Was versteht man in der Netzwerktechnik unter einem VLAN? Auf welcher OSISchicht kann es zum Einsatz kommen? 5. Können Switche DoS-Angriffe eindämmen? Falls ja: Wie? 6. Worum handelt es sich bei IEEE 802.1X? 7. Weshalb ist das Verfahren WPA-2 dem Verfahren WEP vorzuziehen? 8. Konfigurieren Sie auf Ihrem Notebook/PC ein NIDS, um Portscans zu detektieren. 9. Welche lokalen Dienste laufen auf Ihrem Computer? Hinweis: Nutzen Sie das Konsolenprogramm netstat, um sich einen Überblick über offene Ports zu verschaffen. 10. Wie funktionieren TCP SYN-Cookies? Aktivieren Sie SYN-Cookies auf Ihrem Computer. 11. Nennen Sie Maßnahmen zur Härtung des IP- und des TCP-Stacks. 12. Wie können DNS- und SMTP-Server gehärtet werden? 13. Welches Ziel verfolgt Rate Limiting bei DNS? Welche Nebenwirkungen bringt Rate Limiting mit sich? 14. Erläutern Sie die Funktionsweise von Greylisting. 15. Was bedeutet es, wenn ein Mail-Server Relaying betreibt und weshalb ist Relaying sicherheitsrelevant? 16. Angreifer können eine aktive Reconnaissance über SMTP mithilfe der Befehle VRFY und EXPN durchführen. Erläutern Sie, was diese beiden Befehle bewirken.

Literatur 1. Cutler B., et al.: Dunking the data center. Spect. IEEE 54, 26–31 (2017). IEEE 2. IEEE Spectrum-Redaktion: Cool Runnings. Spectrum IEEE, S. 14–15. IEEE (2017) 3. Guruprasad, A., Pandey, P., Prashant, B.: Security features in ethernet switches for access networks. In: Proceedings of the Conference on Convergent Technologies for the Asia-Pacific Region (TENCON 2003), Bd. 3, S. 1211–1214. IEEE, New York (2003) 4. Arkko, J. (Hrsg.), Kempf, J., Zill, B., Nikander, P.: SEcure Neighbor Discovery (SEND) – RFC 3971. IETF (2005) 5. Aura, T.: Cryptographically Generated Addresses (CGA) – RFC 3972. IETF (2005) 6. Gont, F.: Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery – RFC 6980. IETF (2013) 7. Osterweil E., Stavrou, A., Zhang, L.: 21 years of distributed denial-of-service: a call to action. Computer 53(8), 94–99 (2020). IEEE 8. Collins, M.: Network security through data analysis, 2. Aufl. O’Reilly, Sebastopol (2017) 9. Carrie Gates: Co-ordinated Port Scans: A Model, A Detector and An Evaluation Methodology, Dissertation, Dalhousie University (2006)

Literatur

287

10. Bernstein, D.J.: SYN cookies. http://cr.yp.to/syncookies.html (1996). Zugegriffen: 18. Jan. 2021 11. Simpson, W.: TCP Cookie Transactions (TCPCT) – RFC 6013. IETF (2011). Anm.: Dieses RFC wurde als „historic“ markiert, da der Ansatz laut RFC 7805 nicht weit verbreitet war und unter anderem durch RFC 7413 ein alternativer Ansatz besteht 12. Cheng, Y., Chu, J., Radhakrishnan, S., Jain, A.: TCP Fast Open – RFC 7413. IETF (2014) 13. Leech, M., Ganis, M., Lee, Y., et al.: SOCKS Protocol Version 5 – RFC 1928. IETF (1996) 14. Abhishta, van Rijswijk-Deij, R., Nieuwenhuis, L.J.M.: Measuring the impact of a successful DDoS attack on the customer behaviour of managed DNS service providers. In: Proceedings ACM SIGCOMM 2018 Workshop on Traffic Measurements for Cybersecurity (WTMC 2018). ACM, New York (2018) 15. Bernstein, D.J.: How to answer TCP queries (Abschnitt „What are zone transfers?“). https:// cr.yp.to/djbdns/tcp.html#intro-axfr (2003). Zugegriffen: 18. Jan. 2021 16. Herzberg, A., Shulman, H.: DNS security: past, present and future. In: Proceedings of the 9th Future Security – Security Research Conference, S. 524–531. Fraunhofer Verlag, Stuttgart (2014) 17. Klein, A., Kravtsov, V., Perlmuter, A., Shulman, H., Waidner, M.: Poster: X-Ray your DNS. In: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), S. 2519–2521. ACM, New York (2017) 18. Ramsdell, B., Turner, S.: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification – RFC 5751. IETF (2010) 19. Margolis, D., Risher, M., Ramakrishnan, B., et al: SMTP MTA Strict Transport Security (MTA-STS) - RFC 8461, IETF (2018) 20. Crispin, M.: Internet Message Access Protocol – Version 4rev1 – RFC 3501. Network Working Group (2003) 21. Cacak, J. und das Nmap-Projekt: File nntp-ntlm-info. https://github.com/nmap/nmap/blob/ master/scripts/nntp-ntlm-info.nse (2018). Zugegriffen: 18. Jan. 2021

Teil IV Vertiefung

Die bisherigen Kapitel haben Wissen der Netzwerktechnik, IT-Sicherheit, Kryptografie und Netzwerksicherheit vermittelt. Im letzten Abschnitt dieses Buches lernen Sie ausgewählte Vertiefungsthemen kennen. Insbesondere handelt es sich dabei um eine Einführung in die Netzwerkaspekte der Steganografie (insbesondere Covert Channels) und um eine ausführliche Betrachtung der Sicherheit im Internet der Dinge.

9

Netzwerksteganografie

Covert channel analysis can be viewed either as an arcane aspect of computer security having little to do with ,real‘ security issues or as the key to protecting nominally secure systems against a wide variety of both internal and external threats. – John Mc Hugh (1995).

Zusammenfassung

Dieses Kapitel führt in die Netzwerksteganografie und verdeckte Kanäle ein. Betrachtet werden dabei die grundlegende Terminologie sowie die bekannten Versteckmuster und selektierte Gegenmaßnahmen.

9.1 Einführung Steganografie ist die Wissenschaft des Versteckens von Nachrichten innerhalb von Objekten beziehungsweise innerhalb von anderen Nachrichten. Steganografie findet bereits bei den Griechen des Altertums Anwendung. So widmet sich Aineas der Taktiker bereits im 4. Jahrhundert v. Chr. dieser Thematik in seinem Werk Von der Vertheidigung der Städte [10]. Techniken zum Verstecken von Nachrichten gibt es zahlreiche. Beispielsweise kann ein geheimer Text in der ersten Spalte eines Textes stehen, wie Abb. 9.1 zeigt, in der die Nachricht „insecure“ eingebettet ist. Die sich mit der Einbettung von Nachrichten in Sprache befassende linguistische Steganografie kann auf beliebige Sprachen angewandt werden und sich dabei auch auf Satzzeichen, White-spaces, aber auch auf Vorkommen von Klein- und Großbuchstaben © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 S. Wendzel, IT-Sicherheit für TCP/IP- und IoT-Netzwerke, https://doi.org/10.1007/978-3-658-33423-9_9

291

292

9 Netzwerksteganografie Ich möchte diese Diskussion nicht auf die Spitze treiben. natürlich nicht. Doch sollte auch bedacht werden, dass sicherlich nicht jeder Teilnehmer des Kongresses einen erheblichen Anteil der BürgerInnen hinter sich weiß! Cuxhaven ist mehr, als nur eine Stadt! Es ist vielmehr unsere Stadt – im Wahlfieber! Wählen Sie Rolf Muster v. Regenstadt zum Bürgermeister! Mit ihm an der Spitze geht es wieder aufwärts!

Abb. 9.1   Eine simple Form der linguistischen Steganografie

In den letzten Monaten konnten wir durch Herrn Regenstadt viele Erfolge hinsichtlich der Gesamtziele verbuchen, die wir uns definierten. Es ist nun an mir, noch einmal an die Notwendigkeit derselben zu erinnern.

Abb. 9.2  Eine weitere Form der linguistischen Steganografie, bei der Großbuchstaben die geheime Nachricht „IM REGEN“ kodieren

(beispielhaft in Abb. 9.2 dargestellt), Silben, Redundanzen und sonstige sprachliche Merkmale konzentrieren. Auch für arabische und asiatische Sprachen sind steganografische Techniken bekannt. Zudem sind die Möglichkeiten der Kodierung vielseitig. Somit ist einem Gegenspieler nicht bekannt, ob ein bestimmter Buchstabe für sich selbst, für ein Bit, für ein Morse-Symbol oder für eine ganz andere Kodierung steht. Steganografische Nachrichten können allerdings nicht nur in Text, sondern auch in digitale Bilder, Audiodateien, Videos, Audio- und Videostreams eingebettet werden, ja sogar in ungenutzte Bereiche von Dateisystemen. Das „Versteck“, in dem die steganografischen Daten untergebracht sind, nennt sich Cover Object. Exkurs: Adressat Unbekannt

Die Briefnovelle Adressat Unbekannt spielt in den 1930er-Jahren. Auf weniger als 100 Seiten stellt das Buch von Kressman Taylor (im Original Address Unknown) eine Konversation per Post zwischen zwei Personen aus den USA und Deutschland dar. Der sich zuspitzende Konflikt zwischen den einstigen Freunden, von denen einer Jude und der andere Hitler-Anhänger wird, beinhaltet auch den vermeintlichen Einsatz von Steganografie. Dieser vermeintliche Einsatz führt gewissermaßen zum Finale des Buchs. Ich empfehle dieses spannende und zugleich politisch interessante Werk wärmstens.

9.1 Einführung

293

Exkurs: Die vielen Leben des Jan Six

Mit dem Buch Die vielen Leben des Jan Six legt der Autor Geert Mak die Geschichte einer Amsterdamer Dynastie vor. Im Buch kommt unter anderem zur Sprache, dass an einem Haus an der Herengracht der Spruch salvs pax hvic domvi (dt. Heil und Friede diesem Haus) angebracht wurde. Bei genauerer Betrachtung zeigen sich Buchstaben, die das Baujahr des Gebäudes verraten (saLVs paX hVIC DoMVI). Auch dies ist eine, wenn auch simple, Unterform der Steganografie.

Die Netzwerksteganografie ist nun wiederum diejenige Disziplin, die die Steganografie auf Netzwerkdaten anwendet [17]; sie kümmert sich darum, dass übertragene Daten legitim erscheinen, obwohl darin versteckte Botschaften enthalten sind. Definition 9.1  Ein verdeckter Kanal (engl. Covert Channel) ist ein nicht in einem System vorgesehener Kommunikationskanal [13], der eine Sicherheitsrichtlinie bricht [4]. Definition 9.2  Ein Seitenkanal (engl. Side Channel) ist ein verdeckter Kanal, der ohne Intention sendet [26]. Ein Beispiel für einen Seitenkanal ist etwa ein kryptografischer Algorithmus, der eine längere Laufzeit benötigt, wenn das erste Bit eines verwendeten Schlüssels 1 ist. Die Messung der Laufzeit des Algorithmus gibt einem Beobachter den Bitwert. Die Möglichkeit dieser Informationsübertragung wurde vom Entwickler des kryptografischen Algorithmus sehr wahrscheinlich nicht vorgesehen, womit der verdeckte Kanal ein Seitenkanal ist. In Netzwerken wird ein verdeckter Kanal von netzwerksteganografischen Methoden erzeugt [17]. Derartige Methoden betten steganografische Nachrichten in ein Cover Object ein (etwa ein UDP-Paket), das zum Empfänger übertragen wird. Die innerhalb des Cover Objects stattfindende verdeckte Kommunikation stellt den verdeckten Kanal dar. Auch Seitenkanäle gibt es in Netzwerken; beispielsweise können Angreifer die Dauer messen, die ein Server zur Beantwortung von Anfragen benötigt. Damit lassen sich unter Umständen Rückschlüsse auf sensible Daten ziehen [5]. Anwendung findet die Netzwerksteganografie etwa bei der Kommunikation von Botnetzen (C&C-Channel) und bei der Exfiltration vertrauenswürdiger Daten [39]. Es gibt auch positive Anwendungsfelder, die immer wieder genannt werden, wie die geheime Kommunikation von Journalisten, die mithilfe der Steganografie Internetzensur umgehen möchten. Die gutartige Verwendung der Steganografie ist allerdings aufgrund verschiedener, in [28] aufgeführter Gründe (etwa geringer Bekanntheit der Steganografie und technische Herausforderungen) schwierig. Leider sind keine Zahlen zu den gutartigen Fällen und kaum Zahlen zu den bösartigen Anwendungsfällen der Steganografie bekannt. Allerdings versucht die CUING-Initiative (www.cuing.org, siehe auch [16]) seit einigen Jahren, die Entwicklungen der kriminellen Nutzung von Steganografie

294

9 Netzwerksteganografie

zu protokollieren und analysieren. Tendenziell steigt dabei die Anzahl der Fälle, in denen (Netzwerk-)Steganografie für kriminelle Zwecke angewandt wurde. Ein weiteres bekanntes Anwendungsfeld ist die Überwachung von Smartphones. Hierfür kommt Spähsoftware wie etwa FinFisher von Gamma International zum Einsatz, dessen Ausführung Fin-Spy Mobile eine Live-Überwachung von SMS- und MMS-Nachrichten, E-Mails, Anrufen, Aufenthaltsort und Blackberry-Nachrichten ermöglicht. Diese Daten werden per verdeckter Kommunikation an ein „Master“-System gemeldet [36].

9.2 Methoden der Netzwerksteganografie Die ersten Publikationen zur Netzwerksteganografie reichen zurück in die späten 80erJahre des vergangenen Jahrhunderts [16, 17]. Die Verfahren der Netzwerksteganografie sind dabei bijektiv, das heißt ein Klartext kann in ein eindeutiges steganografisches Objekt eingebettet, aber auch wieder eindeutig aus diesem herausgelesen werden. Girling und Wolf präsentieren damals die ersten Verfahren, mit denen in lokalen Netzwerken unbemerkt Daten über verdeckte Kanäle übertragen werden können. Dies geschah etwa 15 Jahre, bevor man begann, den Begriff Netzwerksteganografie überhaupt zu verwenden. Auch in der heutigen Forschung und in diesem Kapitel ist der zentrale Begriff für versteckte Übertragungen im Netzwerk noch der oben eingeführte verdeckte Kanal. An dieser Stelle sei erwähnt, dass eine einheitliche Beschreibungsmethodik für verdeckte Kanäle in Netzwerken existiert [34].

9.2.1 Grundlegende Taxonomie Die frühen Autoren stellten zwei grundverschiedene Ansätze vor, nämlich zeit- und speicherbasierte Kommunikation. Neben der Unterscheidung in zeit- und speicherbasierte Kanäle existieren weitere Unterscheidungsmerkmale für verdeckte Kanäle, etwa zwischen passiven und aktiven, sowie zwischen rauschenden und rauschfreien; außerdem wird zwischen aktiven und passiven verdeckten Kanälen unterschieden [26]. Für das vorliegende Kapitel ist allerdings insbesondere die erstgenannte Unterscheidung wichtig. Zeitbasierte verdeckte Kanäle nennen sich auch Timing Channels oder schlicht Zeitkanäle und speicherbasierte werden als Storage Channels (Speicherkanäle) bezeichnet. Timing Channels signalisieren Daten durch die Manipulation zeitlicher Abfolgen von Netzwerkevents. Dies geschieht zum Beispiel dadurch, dass sie die Intervallzeiten zwischen Netzwerkpaketen modulieren, um dadurch unterschiedliche Symbole (die Elementareinheit geheimer Informationen, wie etwa Striche und Punkte bei MorseNachrichten oder die Buchstaben des Alphabets für deutsche Texte) übertragen zu können. Beispielsweise könnte eine Intervallzeit von 0,1 s für ein 1er-Bit und eine Intervallzeit von 0,2 s für ein 0er-Bit stehen.

9.2  Methoden der Netzwerksteganografie

295

Speicherbasierte Kanäle sind hingegen solche, die verdeckte Daten in Speicherbereichen zu übertragender Pakete (beziehungsweise Frames, Datagramme oder Segmente) unterbringen. So kann etwa ein ungenutztes Bit im IPv4-Header mit einer 0 oder einer 1 versehen werden. Während Storage Channels immer von einem bestimmten Netzwerkprotokoll abhängen, sieht dies bei Timing Channels anders aus. 2016 führten wir deshalb in [17] eine neue Taxonomie für dieselben ein, bei der zwei Untergruppen für Timing Channels definiert wurden – protkollspezifische (engl. protocol-aware) und protokollunabhängige (engl. protocol-agnostic). Protokollunabhängig können etwa Durchsatz von und Intervallzeiten zwischen Paketen umgesetzt werden – es ist schließlich egal, ob ein TCP- oder UDP-Paket für mehr Datendurchsatz sorgt, solange dieser Durchsatz irgendwie die verdeckte Nachricht kodieren kann. Die andere Kategorie von Timing Channels arbeitet hingegen mit der Reihenfolge von Nachrichten, etwa der Reihenfolge, in der TCPSegmente versendet werden, oder anderen Ansätzen, die protokollspezifisch realisiert werden müssen. Doch auch für Storage Channels gibt es eine weitere Unterteilung: Sie können entweder Nutzdaten modifizieren (z. B. HTML-Inhalte, die in einer HTTP-Antwort enthalten sind) oder das Protokoll an sich (Metadaten/Header) [33]. Für das vorliegende Buch sind insbesondere Modifikationen der Protokollmetadaten interessant, da sie spezifisch für Netzwerksteganografie sind. Metadaten von Protokollen können wiederum so modifiziert werden, dass sich die Struktur der Daten ändert oder so, dass die Struktur erhalten bleibt [33]. Diese Varianten werden structure-modifying beziehungsweise structure-preserving genannt.

9.2.2 Versteckmuster Alle verdeckten Kanäle können Versteckmustern (engl. Hiding Patterns) zugeordnet werden, die in [33] eingeführt und in [17] leicht weiterentwickelt wurden. Es existieren hunderte von Techniken zur Erzeugung von verdeckten Kanälen in Netzwerken. Einer der Vorteile von Hiding Patterns ist der, dass von diesen Einzeltechniken und von spezifischen Protokollen abstrahiert wird. Hiding Patterns lassen sich leichter verstehen und vermitteln, weil sie die Kernideen von Verstecktechniken darstellen. Praktischerweise sind etwa 70 % aller Verstecktechniken mit nur vier Hiding Patterns beschreibbar, da sich die Ideen vieler Autoren im Laufe der Zeit äußerst ähnlich waren [33, 33]. Insgesamt gibt es derzeit 15 uns bekannte Patterns, wobei ihre Anzahl zunehmen kann, wenn neue Patterns entdeckt werden. Die bisher bekannten Patterns werden analog zu Abb. 9.3 besprochen. Das heißt, es werden erst Timing Channel Patterns (zunächst protocol-aware, dann protocol-agnostic) und anschließend Storage Channel Patterns (structure-modifying und schließlich structure-preserving) erläutert. Die Beschreibung ist prägnant gehalten, sodass die wichtigsten Aspekte der jeweiligen Patterns deutlich werden. Eine ausführliche Darstellung der Patterns findet sich in [17, 33].

296

9 Netzwerksteganografie

Abb. 9.3   Die grundlegende Taxonomie für verdeckte Kanäle, die in [33] vorgeschlagen und durch [17] erweitert wurde

9.2.2.1 Timing Channel Patterns Es existieren drei bekannte Hiding Patterns für Timing Channels, die protocol-agnostic sind: 1. Rate/Throughput: Hierbei wird Datenverkehr zwischen Sender und Empfänger mit einer unterschiedlichen Datenrate übertragen. Verschiedene Datenraten kodieren unterschiedliche geheime Symbole. 2. Interpacket Times: Bei diesem Pattern signalisieren unterschiedlich lange Intervallzeiten zwischen zwei aufeinanderfolgenden Netzwerkpaketen die geheimen Symbole. Die Intervallzeiten werden auch als Inter-arrival Times (IAT) oder Inter-packet Gaps (IPG) bezeichnet. 3. Message Timing (auch Message Sequence Timing): Die zeitliche Abfolge von Nachrichten kann protokollunabhängig manipuliert werden. Dieses Pattern signalisiert durch derlei Manipulationen verdeckte Daten. Zum Beispiel kann eine Antwort eines Servers künstlich verzögert werden (oder nicht), um verschiedene geheime Bits zu signalisieren. Weiterhin gibt es sechs Timing Channel Patterns, die protocol-aware sind: 1. Artificial Loss: Protokolle, in denen Pakete Reihenfolgen aufweisen, etwa Sequenznummern für TCP-Segmente, können so manipuliert werden, dass ein künstlicher Paketverlust vorgetäuscht wird. Die Tatsache, ob ein Paket in einer Liste von empfangenen Paketen fehlt, kodiert das geheime Symbol. 2. Retransmission: Alternativ kann ein Sender Pakete auch mehrfach senden, was aber nur dann möglich ist, wenn ein Protokoll das Mehrfachsenden unterstützt. Die Reliabilität von TCP ist hierfür ein klassisches Beispiel: Wenn die Logik von TCP entscheidet, dass ein Segment verlorenging (da eine Empfangsbestätigung ausblieb), dann wird dieses Segment erneut gesendet. Ein verdeckter Kanal kann sich derartiges Verhalten zu Nutze machen und selbst für das erneute Versenden von Paketen sorgen. 3. Message Ordering: Manche Protokolle – auch hier ließe sich wieder TCP anführen – kennzeichnen zu übertragende Pakete (Segmente) mit einer Nummer. Pakete können in der korrekten oder einer manipulierten Reihenfolge versendet werden, wodurch der Empfänger im Fall dieses Patterns ein unterschiedliches geheimes Symbol erhält.

9.2  Methoden der Netzwerksteganografie

297

4. Frame Collisions: Moderne Netzwerkschnittstellen sind in der Lage, Kollisionen von Frames zu erkennen. Ein Angreifer kann eine solche Kollision künstlich hervorrufen; selbstverständlich kann auch hierdurch verdeckt signalisiert werden. 5. Temperature: Ein Spezialfall der verdeckten Kanäle sind solche, die auf der Beeinflussung einer messbaren Temperatur basieren. Ein Sender muss die Temperatur einer dem Empfänger zugänglichen Einheit beeinflussen, damit dieser selbige auslesen kann – sei es direkt oder indirekt. Der Temperaturwert kodiert das geheime Symbol. Das einzige bekannte Verfahren hierbei benötigt einen zwischengeschalteten Host, den Sender und Empfänger ausnutzen, und funktioniert auf indirekte Weise; außerdem benötigt er ein Protokoll, das möglichst genaue Zeitstempel verwendet [17]. Der Empfänger beeinflusst durch die Anzahl seiner an den zwischengeschalteten Host gestellten Anfragen die Temperatur auf selbigem. Die Temperatur beeinflusst wiederum den Taktversatz (engl. clock skew) auf diesem System, der indirekt über Zeitstempel durch den Empfänger (dieser fragt ebenfalls den zwischengeschalteten Host ab) festgestellt werden kann und letztlich einen Rückschluss auf die Temperatur (und damit das geheime Symbol) ermöglicht. Die Übertragungsrate für einen solchen Kanal ist bisher sehr gering. 6. Artificial Reconnections: Ein Sender beeinflusst die Verbindungen von Netzwerkrechnern und zwingt diese dazu, sich neu mit einem Drittsystem zu verbinden. Der Empfänger überwacht die Reihenfolge, in der die neuen Verbindungen eingeleitet werden [2].

9.2.2.2 Storage Channel Patterns Es existieren drei bekannte Storage Channel Patterns, die als structure-modifying zu kategorisieren sind: 1. Size Modulation: Die Größe von Paketen wird (durch Hinzufügen/Entfernen optionaler Headerelemente) moduliert und repräsentiert das geheime Symbol. 2. Sequence Modulation: Die Reihenfolge von Headerelementen/Protokollbefehlen wird moduliert; beispielsweise kann beim SMTP-Protokoll zuerst der Befehl NOOP gefolgt von MAIL FROM gesendet werden – oder andersherum. 3. Add Redundancy: Bei diesem Pattern fügt der Sender redundante Datenbereiche innerhalb eines Pakets beziehungsweise innerhalb eines Headerelements hinzu. Beispielsweise kann der IPv4-Header um Optionsheader erweitert werden, wodurch ein Mehr an – allerdings nicht zu verarbeitender und inhaltlich nicht relevanter – Information vorliegt. Im Gegensatz zum Pattern Size Modulation wird nicht die Größe eines Pakets, sondern das Vorhandensein redundanter Daten geprüft. Weiterhin sind drei Storage Channel Patterns bekannt, die als structure-preserving zu kategorisieren sind: 1. Random Value: Diverse Protokolle besitzen Felder, die (Pseudo-)Zufallswerte beinhalten, etwa die ISN von TCP. Ein verdeckter Kanal kann diese Werte durch geheime Symbole ersetzen.

298

9 Netzwerksteganografie

2. Reserved/Unused: Fast jedes Protokoll beinhaltet unbenutzte beziehungsweise als „für die zukünftige Nutzung reserviert“ beschriebene Elemente. Diese können verwendet werden, um geheime Symbole darin unterzubringen. 3. Value Modulation: Bei diesem Pattern werden zugelassene Werte eines Headerelements verwendet, um geheime Symbole zu kodieren. Im Gegensatz zum Pattern Random Value stellen diese Werte allerdings keinen Zufallswert dar und im Gegensatz zum Pattern Reserved/Unused handelt es sich nicht um reservierte oder unbenutzte Elemente. Stattdessen muss ein Sender für jedes Paket einen aus n erlaubten Werten für ein Headerelement selektieren, während bestimmte andere Werte aus beliebigen Gründen nicht erlaubt sind. Ein solcher Grund könnte etwa sein, dass eine ProtokollSpezifikation verletzt würde, wenn ein bestimmter Wert gesetzt wird. Zum Beispiel sind IPv4-Pakete mit gesetzten „reserved“-Bit nicht protokollkonform. Ein Beispiel für eine Value Modulation sind ICMP-Nachrichten, bei denen das Type-Feld ausgewertet wird. Da nur bestimmte ICMP-Typen (und ihre zugehörigen Werte) definiert sind, können nur diese verwendet werden.

9.2.3 Spezifische Versteckmethoden Verdeckte Kanäle gibt es für eine Vielzahl von Netzwerkprotokollen, prinzipiell sogar für alle praktisch verwendbaren Protokolle. In den vergangenen Jahrzehnten wurden diverse Kanäle für Protokolle sämtlicher Schichten des TCP/IP-Modells gezeigt, darunter Standardprotokolle wie IPv4 [1], TCP [19], IPv6 [14] sowie VoIP-Protokolle [15] und IPSec [9]. Einen Überblick über die Vielzahl der einzelnen Techniken bieten unter anderem [39] und [33] (Letztere ordnet die Verstecktechniken den oben eingeführten Patterns zu). Neben den grundlegenden Patterns gibt es noch Hybridmethoden [17]. Hybridmethoden manipulieren sowohl das zeitliche Verhalten von Datenübertragungen, wie auch Speicherbereiche. Hybride Methoden kombinieren im Wesentlichen mehrere vorhandene Patterns zu einer umfassenderen Verstecktechnik. Beispielsweise kann ein Sender gleichzeitig einen Zeitkanal durch Manipulation der Intervallzeiten zwischen Paketen umsetzen und die in den Paketen eingebetteten reservierten Bits von Headerelementen für verdeckte Symbole nutzen. Wenn mehrere Patterns miteinander kombiniert werden – unabhängig davon, ob sie, wie bei Hybridmethoden explizit Storage- und Timing-Patterns verwenden, liegt eine Pattern Combination vor [33]. Ein Fall von Pattern Combination kann beispielsweise auch die Patterns Reserved/Unused mit Size Modulation kombinieren. Ein weiterer Ansatz besteht darin, Patterns abzuwechseln und nennt sich Pattern Hopping [33]. Dabei wird für jedes neu zu übertragende Fragment der geheimen Nachricht ein Pattern ausgewählt, mithilfe dessen das Fragment übertragen soll. Für jedes neue Fragment kann sich folglich auch das verwendete Pattern ändern. Die Idee basiert auf Protocol Hopping Covert Channels, die verschiedene Versteckmethoden für jedes

9.2  Methoden der Netzwerksteganografie

299

neue Fragment wählen können, dabei allerdings nicht patternbasiert vorgehen [29]. Wird einer der bei Pattern Hopping oder Protocol Hopping Covert Channels verwendeten verdeckten Kanäle detektiert, so bleiben die anderen Kanäle nach wie vor unentdeckt. Selbiges gilt für den Fall, dass einer der verdeckten Kanäle blockiert wird; die anderen Kanäle funktionieren nach wie vor [29]. Eine ähnliche Idee zu Protocol Hopping Covert Channels stellen sogenannte Protocol Switching Covert Channels, auch Protocol Channels genannt, dar. Sie kodieren eine verdeckte Nachricht durch Netzwerkprotokolle [30]. Zum Beispiel kann das ICMPProtokoll ein geheimes 1er-Bit symbolisieren, während ein UDP-Paket ein 0er-Bit symbolisiert. Wird dann beispielsweise ein UDP-Paket, gefolgt von zwei ICMP-Paketen übertragen, so entspräche das der geheimen Nachricht „011“. Yarochkin et al. haben einen adaptiven verdeckten Kanal vorgestellt [38]. Dabei prüfen Sender und Empfänger, welche Protokolle für eine verdeckte Kommunikation verwendet werden können, um in diesen Protokollen Daten zu verstecken. Außerdem prüfen sie, welche Protokolle aktuell geblockt werden. Da sich Firewallkonfigurationen und Routen von Paketen dynamisch ändern können, teilten die Autoren ihren Ansatz in zwei Phasen ein. In der Network Environment Learning Phase (NEL Phase) probieren Sender und Empfänger permanent, sich mit bestimmten Protokollen zu erreichen. Die Erfolgs- und Misserfolgsfälle werden kontinuierlich protokolliert, da die NEL Phase permanent abläuft. In der Communication Phase (COM Phase) werden die geheimen Symbole über die durch die NEL Phase als nutzbar erkannten Protokolle übertragen. Ein solches System kann hervorragend auf veränderte Umgebungen reagieren. Eine verbesserte Variante des Verfahrens von Yarochkin et al. wird in [27] erläutert. Wie sämtliche legitime Datenübertragungen, so können auch verdeckte Kanäle interne Protokolle (auch Mikroprotokolle genannt) verwenden [29]. Mikroprotokolle bieten umfassende Möglichkeiten; dazu zählen etwa dynamisches Routing, das Initiieren von Protokollwechseln für das Protokoll/Pattern Hopping und das Signalisieren von Start und Ende einer Übertragung sowie simple Maßnahmen zur Fehlererkennung und -korrektur wie Paritätsbits [17, 29].1 Verdeckte Kanäle existieren zudem nicht ausschließlich in klassischen Netzwerkprotokollen, sondern beispielsweise auch in Cloudumgebungen. 2017 stellten Spiekermann et al. einzelne Storage Channels für die Virtualisierungsprotokolle VXLAN, STT, GENEVE und NVGRE vor. Dabei konnten pro Protokollheader 37 Bits (VXLAN), 18 Bits (NVGRE), 80 + Bits (STT) und 18−142 Bits (GENEVE) platziert werden. Während dabei die bekannten Patterns zum Einsatz kamen, zeigten die Autoren allerdings auch einen interessanten Timing Channel: Durch Migration von virtuellen Maschinen an andere Rechenzentren auf der Welt verändert sich die Round Trip Time (RTT) zu diesen

1Fehlererkennung

und -korrektur sind auch Gegenstand von Steganografie, die nicht im Netzwerk stattfindet. Siehe dazu etwa Keller und Magauer [12].

300

9 Netzwerksteganografie

virtuellen Maschinen. Wenn nun schnell migriert wird, so kann die RTT verwendet werden, um verdeckte Informationen zu signalisieren [22]. Weitere Ansätze existieren für die verdeckte Datenübertragung in Mobilfunknetzen. Zhang et al. konnten zeigen, dass für Sprachübertragung über LTE (Voice over LTE, VoLTE) verdeckt signalisiert werden kann, indem geräuschlose Übertragungszeiten, in denen kein Beteiligter spricht, leicht verzögert beziehungsweise verlängert werden [40]. Xu et al. konnten zudem verdeckte Kanäle für LTE Advanced (LTE-A) umsetzen [37]. Auch sind verdeckte Kanäle für GSM bekannt [18]. In den vergangenen Jahren konnten erste Arbeiten zudem zeigen, dass Netzwerksteganografie auch in automatisierten Umgebungen beziehungsweise dem Internet der Dinge umgesetzt werden kann. Dabei können verdeckt Daten über IoT-Netzwerke übertragen oder IoT-Geräte ausgenutzt werden, um auf ihnen steganografische Symbole zu hinterlegen [35]. In diesem noch sehr jungen Gebiet existieren allerdings recht wenige Arbeiten, unter anderem wird das Thema zum Teil in einer Publikation von Tonejc et al. [24] und in einer Publikation von Tuptuk und Hailes [25] aufgegriffen, sowie in den Publikationen des Autors, insbesondere [35] (Speicherung von geheimen Daten im IoT) und [32] (damals erster Ansatz für verdeckte Kanäle in Automationsumgebungen). Ein weiterer Forschungstrend besteht in Air-gapped oder Out-of-band Covert Channels [3], das heißt in verdeckten Kanälen, die zwischen physikalisch separierten Systemen Daten übertragen können. Dazu kann etwa nicht hörbarer Schall oder Licht als Netzwerkmedium dienen. Hanspach und Götz zeigten, wie sich mit verdeckten akustischen Kanälen Mesh-Netzwerke realisieren lassen [7, 8]. Dass verdeckte akustische Kommunikation auch ohne Lautsprecher funktionieren kann, zeigen Guri et al. in [6] durch Nutzung von Ventilatoren, die eigentlich zur CPU- und Gehäusekühlung dienen.

9.3 Gegenmaßnahmen zur Netzwerksteganografie Gegenmaßnahmen werden im Kontext der Steganografie als Wardens bezeichnet. Sie können passiv sein (Passive Warden) oder aktiv sein (Active Warden). Active Wardens können zudem sogar bösartig agieren und nennen sich dann Malicious Wardens. Diesen Bezeichnungen liegt das sogenannte Prisoner’s Problem (Abb. 9.4) zugrunde, bei dem Alice und Bob in separaten Zellen untergebracht werden und nur über einen Wärter (engl. Warden) Nachrichten austauschen können. Trotz dieser widrigen Umstände wollen Alice und Bob einen Ausbruchsversuch planen, indem sie mithilfe von Steganografie geheime Nachrichten vom Warden übertragen lassen, ohne, dass dieser von der geheimen Kommunikation erfährt. Dieses Prisoner’s Problem geht auf Simmons zurück und wurde 1983 vorgestellt [20]. Gegenmaßnahmen können verschiedene Ziele verfolgen. Zander et al. [39] teilten Gegenmaßnahmen in solche ein, die

9.3  Gegenmaßnahmen zur Netzwerksteganografie

301

Abb. 9.4  Prisoner’s Problem. Die Aufgabe des Wardens ist es, geheime Nachrichten zu detektieren oder zu entfernen. Nicht dargestellt ist, dass der Warden auch eigene Nachrichten an Bob schicken und sich dabei als Alice ausgeben kann (Malicious Warden). Bob kann daher niemals sicher sein, ob eine Nachricht von Alice ihn erreicht und ob eine geheime Nachricht tatsächlich von Alice stammt

• ein Audit eines verdeckten Kanals vornehmen (dies schafft Bewusstsein über die potenzielle Existenz sowie Rahmenbedingungen eines verdeckten Kanals), • eine Detektion des verdeckten Kanals vornehmen (dies schafft Bewusstsein über die aktuelle beziehungsweise in der Vergangenheit liegende Präsenz eines verdeckten Kanals), • eine Limitierung des verdeckten Kanals vornehmen (das heißt, die Kanalkapazität des Kanals zu reduzieren) oder • versuchen, den verdeckten Kanal zu unterbinden (das heißt, die Existenz des Kanals unmöglich zu machen). Diese Kategorisierung wurde in [17] beibehalten. Bei Limitierung und Unterbindung verdeckter Kanäle handelt es sich um aktive (das heißt in den Datenverkehr eingreifende) Maßnahmen, also Active Wardens. Die Detektion ist hingegen eine passive (den Datenverkehr beobachtende und beurteilende) Maßnahme (Passive Wardens). Gegenmaßnahmen haben jeweils unterschiedliche Nebenwirkungen auf den Netzwerkverkehr (siehe [26] für eine detaillierte Analyse). So kann eine aktive Maßnahme beispielsweise Funktionalitäten eines Netzwerkprotokolls verringern. Angenommen, ein Element eines Protokollheaders kann verwendet werden, um darin versteckte Daten zu platzieren. Wenn eine Gegenmaßnahme dieses Element mit dem Wert Null überschreibt, ist es nicht mehr möglich, über dieses Element verdeckt zu kommunizieren. Gleichzeitig wird die eigentliche Protokollfunktionalität, die durch das Element signalisiert wird, unnutzbar. Eine passive Maßnahme kann hingegen zu falschen Detektionsresultaten führen. In solchen Fällen kann legitimer Datenverkehr etwa als verdeckt erkannt werden (und vice versa). Anders formuliert sind die False-Positive- und False-Negative-Raten

302

9 Netzwerksteganografie

eines Detektionsverfahrens in aller Regel nicht perfekt. Außerdem können viele Kanäle nicht sofort erkannt werden, sondern beispielsweise nur leicht zeitverzögert. Oftmals müssen mehrere Tausend Datenpakete ausgewertet werden, damit ein Detektionsalgorithmus überhaupt derart auf diesen Daten arbeiten kann, dass qualitativ brauchbare Resultate erzielt werden können. Kanäle, die mit geringer Datenrate senden, sind in der Regel schwieriger zu detektieren als solche, die mit einer höheren Datenrate senden. Dies lässt sich an einem Beispiel plausibel machen. Wenn etwa für die Inter-arrival Time die Intervallzeiten zwischen jedem Datenpaket ausgenutzt werden (Muster: Interpacket Times) und 50 Pakete pro Sekunde übertragen werden, dann ist innerhalb eines zu analysierenden Datenfensters (beispielsweise 2.000 Pakete) viel verdeckte Kommunikation enthalten, die zu entsprechenden Anomalien führen kann, da sie die statistischen Eigenschaften des Datenfensters beeinflussen kann. Wenn hingegen nur 1 aus 50 Paketen pro Sekunde verwendet wird, um durch eine manipulierte Inter-arrival Time Daten zu signalisieren, so ist die statistische Auswirkung jedes fünfzigsten Pakets auf das Datenfenster deutlich geringer. Je geringer die Datenrate gegenüber der Kanalkapazität eines verdeckten Kanals ist, umso schwieriger ist also die Detektion; anders formuliert steigt mit geringerer Ausnutzung der Kanalkapazität die Verdecktheit (engl. Covertness) an. Während [17, 26] und [39] jeweils ausführlich und aus verschiedenen Blickwinkeln auf, teils unterschiedliche, Gegenmaßnahmen eingehen, soll dieses Kapitel einige besonders wichtige Gegenmaßnahmen erläutern.

9.3.1 Detektion Für die Detektion von verdeckten Kanälen ist es essenziell, nützliche Metriken (beziehungsweise Features) zu wählen. Beispielsweise können die Anzahl von Paketen pro Sekunde, die Größe von einzelnen Netzwerkpaketen, die Anzahl unterschiedlicher Protokolle pro Sekunde, das Vorhandensein eines bestimmten gesetzten Bits in einem Protokollheader oder sonstige Werte einbezogen werden. Genauso können die Varianz, Standardabweichung oder Mittelwerte solcher Werte interessant sein. Für verdeckte Kanäle kann, wie bei NIDS (siehe Abschn. 6.3.2), ein signaturbasiertes, ein anomaliebasiertes Vorgehen oder ein spezifikationsbasiertes Detektionsverfahren umgesetzt werden. Ein simples spezifikationsbasiertes Verfahren könnte etwa darin bestehen, alle IPv4-Pakete dahingehend zu untersuchen, ob das „Reserved“-Bit gesetzt ist. Ist dem so, könnte ein verdeckter Kanal als detektiert gelten. Natürlich könnte es auch einen anderen Grund geben, weshalb dieses Bit gesetzt ist – etwa ein Übertragungsfehler. Signaturbasierte Verfahren zur Erkennung von verdeckten Kanälen finden sich teils in populären NIDS. Snort kann etwa erkennen, wenn im Nutzdatenbereich von ICMP Ping-Nachrichten ein bestimmter String vorkommt, der auf ein Tool namens Ping Tunnel schließen lässt, wobei es sich um ein Tool handelt, das verdeckte Kanäle in selbige Nutz-

303

9.3  Gegenmaßnahmen zur Netzwerksteganografie

Inter Protocol Gaps 9

Normal Traffic 3 Protocol Channel Bursts with Interrupts (pct) Download Traffic

8

IPG time (in sec)

7 6 5 4 3 2 1 0

0

500

1000

1500 2000 IPG number

2500

3000

3500

Abb. 9.5   Inter Protocol Gaps von normalem Traffic (blau), Protocol Switching Covert Channelduchsetztem Traffic (mit drei Pausen, rot) und HTTP-Download-Traffic (grau)

daten einbettet. Die entsprechende Erkennungssignatur wird in der Signaturdatenbank von Snort hinterlegt. Im Voraus ist es nicht immer trivial, die korrekten Werte auszuwählen und mit der entsprechenden Gewichtung in einen Detektionsalgorithmus einfließen zu lassen, zumal Detektionsalgorithmen praktisch für jeden Typ eines verdeckten Kanals neu entworfen werden müssen. Solche Metriken können sich aus verschiedenen anderen Werten zusammensetzen, wie das folgende Beispiel einer anomaliebasierten Erkennung illustriert. Für die Detektion der oben eingeführten Protocol Switching Covert Channels kann – aufbauend auf unterschiedlichen vorherigen Analysen – der Wert γ berechnet werden, der die verdeckten Kanäle mit einer akzeptablen Wahrscheinlichkeit detektieren kann [31]. Die zugrunde liegende Erkenntnis ist dabei jene, dass die sogenannten Inter-protocol Gaps (IPGs2), das sind die Zeitintervalle zwischen dem Wechsel von verwendeten Protokollen in Paketen, je nach Art des Datenverkehrs unterschiedlich ausfallen. Das heißt, dass sich die Anzahl der IPGs pro Tausend Paketen sowie die Zeitintervalle zwischen IPGs je nach Datenverkehr verändern. Abb. 9.5 verdeutlicht dieses

2Diese

Abkürzung ist nicht mit den Inter-packet Gaps zu verwechseln, die ebenfalls mit „IPG“ abgekürzt werden.

304

9 Netzwerksteganografie

Szenario anhand von normalem Datenverkehr eines Linux-PCs (5.000 Pakete), Datenverkehr eines Protocol Switching Covert Channels (auch Protocol Channel genannt) und HTTP-Downloadverkehr, der nur wenige IPGs aufweist, da eine große Anzahl an HTTPPaketen nur durch wenige andere Pakete unterbrochen wird (etwa durch ARP-Requests). Der Wert γ wird wie folgt berechnet, wobei die tri-Funktion letztlich nur dazu dient, die IPGs der Protocol Switching Covert Channels zu erfassen:     test q 1 − DDnormal  φ − (i−1)n i (9.1) · γ = tri , q ≥ 2, q−1 n/s i=2 wobei n die Anzahl der aufgezeichneten Netzwerkpakete (in unserem Fall 5,000) und i die Anzahl unterschiedlicher Protokolle in der Aufzeichnung darstellen (i erhält man durch simples Zählen). Man berechnet für legitimen Datenverkehr – basierend auf historischen Aufzeichnungen des jeweiligen Netzwerks – die durchschnittlichen Protokollwechsel pro Zeiteinheit (Dnormal) sowie die Anzahl der durchschnittlichen Protokollwechsel pro Zeiteinheit für den zu testenden Datenverkehr (Dtest). q wird auf die maximal angenommene Anzahl an gleichzeitig verwendeten Netzwerkprotokollen gesetzt, die ein Protocol Switching Covert Channel verwenden kann (im Normalfall ist q = 4). Der Parameter s dient einzig dazu, die Spreizung der tri-Funktion zu verändern und dient der Optimierung des Algorithmus und wurde nach einigen Tests auf den Wert 2 gesetzt. Generell spricht ein höherer γ-Wert auch für das wahrscheinlichere Vorhandensein eines Protocol Switching Covert Channels; die Genauigkeit einer γ-basierten Detektion kann allerdings mithilfe des C4.5-Klassifikationsalgorithmus und leicht veränderter Metrik übertroffen werden [31].

9.3.2 Limitierung Bei den Verfahren, die verdeckte Kanäle limitieren sollen, muss immer auch bedacht werden, welche Auswirkungen eine Limitierung auf legitimen Datenverkehr und legitime Prozesse hat. Ein klassischer Ansatz für die Limitierung von verdeckten Kanälen ist die Network Pump. Dieses von Kang et al. [11] entwickelte Verfahren reduziert die Anzahl der Empfangsbestätigungen pro Sekunde, die für eine Nachricht verschickt werden. Ein Timing Channel, der durch die Anzahl von Empfangsbestätigungen verdeckt signalisieren möchte (Message Timing/Sequence Pattern), wird dadurch zwar nicht eliminiert, aber kann weniger Symbole pro Sekunde übertragen. Eine Beurteilung des Verfahrens findet sich unter anderem in [26]; dort gehe ich auch auf verwandte Verfahren wie den ACKFilter, das Store-and-Forward-Protocol, Einweg-Links, den Upwards Channel und die Quantized Pump ein. Ein von uns entwickeltes Verfahren zur Limitierung der Bitrate von Protocol Switching Covert Channels ist der sogenannte Protocol Channel-aware Active Warden

9.3  Gegenmaßnahmen zur Netzwerksteganografie

305

(PCAW) [30]. Protocol Switching Covert Channels müssen das von ihnen verwendete Protokoll zwangsläufig oft wechseln. PCAWs setzen an diesem Punkt an und verzögern Pakete, die ein unterschiedliches Protokoll als vorherige Pakete aufweisen, minimal. Bei legitimem Datenverkehr ist dies kein Problem, da es wenige oder keine Abhängigkeiten zwischen verschiedenen Protokollen gibt und diese vorhandenen Abhängigkeiten3 kleine Verzögerungen problemlos tolerieren können. Bei Protocol Switching Covert Channels sorgt eine Verzögerung bei Protokollwechseln hingegen dafür, dass die Kodierung der geheimen Symbole zerwürfelt wird. Die Verzögerung kann dabei mit einem konstanten Wert d erfolgen oder für jedes neue Paket zufällig mit einem Wert dr im Bereich 0