Sicherheit in vernetzten Systemen - RRZ UniversitÃ¤t Hamburg

Weitere Magazine

Empfehlungen

Info

KAPITEL 5. KRYPTOGRAPHISCHE VERFAHREN heimnis. Alice sendet h zusammen mit M an Bob. Bob, der G kennt, kann ebenfalls H´MGµ bilden und das Ergebnis mit h vergleichen. Wenn die Werte übereinstimmen, weiß Bob, daß die Nachricht M wirklich von Alice geschickt wurde. Da nur er und Alice das Geheimnis G kennen, hätte niemand außer Alice den Hashwert h generieren können, und da H eine Einweg-Hashfunktion ist, ist es für dritte auch trotz der Kenntnis von h und M unmöglich G zu berechnen. Bob weiß außerdem, daß der Text M unverändert angekommen ist. Hätte eine dritte Partei die Nachricht M durch eine andere Nachricht M ¼ ersetzt, wäre der resultierende Hashwert h ¼ H´M ¼ Gµ unterschiedlich zu dem mitgeschickten h H´MGµ. Diese Art der Authentifizierung findet u.a. bei IPSec Verwendung. Der Nachteil dieses Verfahrens ist es, daß es dritten gegenüber keine Authentifizierung bietet (“nonrepudiation”). Alice kann sich zwar von der Identität Bobs überzeugen, hat aber keine Möglichkeit, einer dritten Person Clara zu beweisen, daß die Nachricht tatsächlich von Bob stammt, da Clara weder das Geheimnis G kennt, noch, bei Offenlegung des Geheimnisses, aus G auf Bob schließen kann. Der Geburtstagsangriff Der Geburtstagsangriff beruht auf dem sogenannten Geburtstagsparadoxon und verdeutlicht, warum man darauf achten sollte, keine Einweg-Hashfunktion mit zu kleinem Hashwert zu benutzen. Mit dem Geburtstagsparadoxon hat es folgende Bewandtnis: Die kleinste Anzahl an Personen in einem Raum, so daß die Wahrscheinlichkeit, daß eine dieser Personen den selben Geburtstag wie man selbst hat, größer als 50% ist, beträgt 253. Doch die kleinste Anzahl an Personen, die in einem Raum sein müssen, so daß die Wahrscheinlichkeit, daß zwei dieser Personen am selben Tag Geburtstag haben, größer als 50% ist, beträgt nur 23. Dieses erklärt sich durch die Tatsache, daß man mit 23 Personen 253 verschiedene Paare bilden kann. Diesen Umstand macht sich der Geburtstagsangriff zu nutze: Der gewöhnliche Brute Force Angriff auf einen Hashwert ist, daß man für einen Hashwert H´Mµ einen Text M ¼ sucht mit H´M ¼ µH´Mµ. Bei einer Hashlänge von 64 Bit sind so bis zu 2 64 Hashwerte zu berechnen. Bei einer Rechenleistung von 1.000.000 Berechnungen pro Sekunde wäre die Dauer eines solchen Angriffs 600.000 Jahre. Der Geburtstagsangriff verschiebt die Aufgabenstellung des Angriffs ein wenig. Anstatt daß zu einem existierenden H´Mµ ein M ¼ gefunden werden soll, werden hier zwei Dokumente M und M ¼ gesucht, die den selben Hashwert ergeben. Dieses geschieht i.a. so, daß am Anfang zwei Texte existieren, die so modifiziert werden sollen, daß sie am Ende den gleichen Hashwert ergeben. Dieses geschieht, indem an beiden Dokumenten unauffällige, nur bei eingehender Untersuchung der Dokumente erkennbare Veränderungen vorgenommen werden (z.B. Einfügen von Leerzeichen oder ähnliches). Die Hashwerte für die verschiedenen Versionen der beiden Dokumente werden berechnet und zwischengespeichert. Nun haben wir die Situation, in der wir nur ein Paar mit gleichem Hashwert benötigen. Im allgemeinen sind bei einem Hashwert von 64 Bit nicht mehr als 2 32 Hashwerte zu berechnen, bis zwei passende Versionen gefunden sind. Bei einer Rechenleistung von 1.000.000 Berechnungen pro Sekunde wäre die Dauer eines solchen Angriffs etwa eine Stunde. Also sollte man von Hashfunktionen mit einem Hashwert, der kleiner als 128 Bit ist, Abstand nehmen. Bedenkt man weiterhin, daß in vielen kryptographischen Protokollen, die zum Abschließen von Verträgen dienen, nicht der eigentliche Text des Vertrags signiert wird, sondern nur der Hashwert des Vertrags, ist es in solchen Fällen ratsam, bevor man den Vertrag unterzeichnet, eine kleine unmerkliche Veränderung an dem Dokument vorzunehmen und den Hashwert neu zu bilden. Wenn man nun diesen Hashwert unterzeichnet, kann man sicher sein, daß der Vertragspartner nicht noch einen weiteren, mittels des Geburtstagsangriffs generierten, Vertrag in der Hinterhand hat, der über denselben Hashwert verfügt, aber einen anderen Inhalt hat. Denn im nachhinein wäre dann nicht mehr festzustellen, welcher der beiden Verträge unterzeichnet wurde. 84 SS 99, Seminar 18.416: Sicherheit in vernetzten Systemen
5.6. WEITERE NOTWENDIGE ALGORITHMEN Beispiele für Einweghashfunktionen Hier nun noch eine kurze Erwähnung von zwei verbreiteten Einweghashfunktionen, die als weitgehend sicher gelten: Secure Hash Algorithm, SHA1 (NIST, 1994): SHA1 ist als Teil des DSA (siehe 5.6.1) von der NSA entwickelt worden und berechnet einen Hashwert von 160 Bit. RIPE-MD 160, Europäische Union: RIPE-MD 160 ist eine sichere Weiterentwicklung von MD4 und berechnet 160 Bit große Hashwerte. Digitale Signaturen Für viele Kommunikationsprotokolle hätte man gerne ein elektronisches Äquivalent zur menschlichen Unterschrift, also eine Möglichkeit, digitale Dokumente zu unterzeichnen. Die exakten Anforderungen an eine sogenannte digitale Signatur lassen sich wie folgt auflisten: Authentizität: Der Empfänger kann sich von der Identität des Unterzeichners überzeugen (Es muß für jede Person problemlos möglich sein festzustellen, von wem die digitale Signatur erstellt wurde. Die digitale Signatur identifiziert ihren Ersteller eindeutig). Fälschungssicherheit: Nur dem Unterzeichner ist es möglich, die Signatur zu erzeugen. Überprüfbarkeit: Eine dritte Partei kann jederzeit die Signatur verifizieren. Keine Wiederverwendbarkeit: Die Signatur bezieht sich nur auf das unterzeichnete Dokument und kann keinesfalls für andere Dokumente verwendet werden. Keine Veränderbarkeit, Integrität: Nachdem das Dokument unterzeichnet ist, kann es nicht mehr verändert werden. Es ist ersichtlich, daß, wenn alle diese Forderungen erfüllt sind, Vorgänge wie digitales Unterzeichnen von Verträgen und ähnliches möglich sind. Digitale Signaturen kann man weiterhin zur Authentifizierung von Kommunikationspartnern oder Autoren digitaler Dokumente einsetzen. Digitale Signaturen mittels asymmetrischer Chiffren Vorausgesetzt die Reihenfolge der Anwendungen des geheimen und öffentlichen Schlüssels ist unerheblich, eignen sich asymmetrische Chiffren gut, um digitale Signaturen zu erstellen. Dabei wird wie folgt vorgegangen: Alice chiffriert das betreffende Dokument mit ihrem geheimen Schlüssel. Danach sendet sie das so unterzeichnete Dokument an Bob. Bob dechiffriert das Dokument mit Alices öffentlichem Schlüssel. Betrachten wir kurz, ob alle unsere Anforderungen an digitale Signaturen bei einem derartigen Vorgehen erfüllt werden: Authentizität: Da Alices öffentlicher Schlüssel den Klartext ergibt, weiß Bob, daß das Dokument von Alice stammt. Fälschungssicherheit: Nur Alice kennt ihren geheimen Schlüssel. Niemand anderes hätte die Signatur erstellen können. SS 99, Seminar 18.416: Sicherheit in vernetzten Systemen 85
Seite 1 und 2:
Fachbereich Informatik der Universi
Seite 3 und 4:
Zusammenfassung Der vorliegende Ban
Seite 5:
Vorwort Die Motivation zur Durchfü
Seite 9 und 10:
Inhaltsverzeichnis 1 Grundlagen: In
Seite 11 und 12:
INHALTSVERZEICHNIS 4 Policy, Vorfal
Seite 13 und 14:
INHALTSVERZEICHNIS 8 Hochgeschwindi
Seite 15:
INHALTSVERZEICHNIS 11.6Portscanner-
Seite 18 und 19:
KAPITEL 1. GRUNDLAGEN: INTERNET-PRO
Seite 20 und 21:
Seite 22 und 23:
Seite 24 und 25:
Seite 26 und 27:
Seite 28 und 29:
Seite 30 und 31:
Seite 32 und 33:
Seite 34 und 35:
Seite 36 und 37:
LITERATURVERZEICHNIS 1.5 vorgestell
Seite 38 und 39:
KAPITEL 2. SICHERHEITSPROBLEME 2.2
Seite 40 und 41:
KAPITEL 2. SICHERHEITSPROBLEME daß
Seite 42 und 43:
KAPITEL 2. SICHERHEITSPROBLEME Netz
Seite 44 und 45:
KAPITEL 2. SICHERHEITSPROBLEME Eine
Seite 46 und 47:
KAPITEL 2. SICHERHEITSPROBLEME PING
Seite 48 und 49:
KAPITEL 2. SICHERHEITSPROBLEME ein
Seite 50 und 51: KAPITEL 2. SICHERHEITSPROBLEME Clie
Seite 52 und 53: KAPITEL 2. SICHERHEITSPROBLEME Date
Seite 55 und 56: Kapitel 3 Übersicht über Lösungs
Seite 57 und 58: 3.3. PERSONELLE SICHERHEIT Da auch
Seite 59 und 60: 3.4. HOSTSICHERHEIT Diese Schutzma
Seite 61 und 62: 3.4. HOSTSICHERHEIT 3.4.7 Verschlü
Seite 63 und 64: 3.5. NETZWERKSICHERHEIT Eine Firewa
Seite 65 und 66: 3.6. POLICY Proxy-Server können f
Seite 67 und 68: 3.7. ZUSAMMENFASSUNG 3.7 Zusammenfa
Seite 69 und 70: Kapitel 4 Policy, Vorfallsbearbeitu
Seite 71 und 72: 4.2. AUFBAU EINER POLICY Um nun die
Seite 73 und 74: 4.2. AUFBAU EINER POLICY „Herr Sc
Seite 75 und 76: 4.3. ZUSÄTZLICHE DOKUMENTE Eine m
Seite 77 und 78: 4.4. ERSTELLUNG UND UMSETZUNG Der e
Seite 79 und 80: 4.4. ERSTELLUNG UND UMSETZUNG Die M
Seite 81 und 82: 4.4. ERSTELLUNG UND UMSETZUNG Beson
Seite 83 und 84: 4.5. GESCHICHTE UND ENTWICKLUNG DER
Seite 85 und 86: Kapitel 5 Kryptographische Verfahre
Seite 87 und 88: 5.2. GRUNDLEGENDE BEGRIFFE 5.2.3 De
Seite 89 und 90: 5.3. SYMMETRISCHE CHIFFREN man den
Seite 91 und 92: 5.3. SYMMETRISCHE CHIFFREN funktion
Seite 93 und 94: 5.3. SYMMETRISCHE CHIFFREN entweder
Seite 95 und 96: 5.4. ASYMMETRISCHE CHIFFREN OFB (Ou
Seite 97 und 98: 5.4. ASYMMETRISCHE CHIFFREN Sicherh
Seite 99: 5.6. WEITERE NOTWENDIGE ALGORITHMEN
Seite 103 und 104: 5.7. SCHLUSSBEMERKUNG die Verschlü
Seite 105 und 106: Kapitel 6 Keymanagement und Kommuni
Seite 107 und 108: 6.2. VERFAHREN ZUR ABSICHERUNG VON
Seite 109 und 110: 6.3. KEYMANAGEMENT-PROTOKOLLE Modif
Seite 111 und 112: 6.3. KEYMANAGEMENT-PROTOKOLLE Proto
Seite 113 und 114: 6.3. KEYMANAGEMENT-PROTOKOLLE Das T
Seite 115 und 116: LITERATURVERZEICHNIS Nach erfolgrei
Seite 117 und 118: Kapitel 7 „Klassische“ Firewall
Seite 119 und 120: 7.2. ELEMENTE EINES FIREWALLS 3. TC
Seite 121 und 122: 7.3. FIREWALL-ARCHITEKTUREN Clients
Seite 123 und 124: 7.3. FIREWALL-ARCHITEKTUREN Eine we
Seite 125 und 126: 7.3. FIREWALL-ARCHITEKTUREN Vor- un
Seite 127 und 128: 7.4. FIREWALL-ARCHITEKTUREN IN DER
Seite 129: LITERATURVERZEICHNIS ¯ Firewalls b
Seite 132 und 133: KAPITEL 8. HOCHGESCHWINDIGKEITS-FIR
Seite 141 und 142: Kapitel 9 „Active Content“ und
Seite 143 und 144: 9.2. ACTIVE CONTENT Im Gegensatz zu
Seite 145 und 146: 9.2. ACTIVE CONTENT JavaScript Bei
Seite 147 und 148: 9.2. ACTIVE CONTENT Im Rahmen diese
Seite 149 und 150: 9.2. ACTIVE CONTENT Andere Angriffe
Seite 151 und 152:
9.2. ACTIVE CONTENT Allerdings sind
Seite 153 und 154:
9.2. ACTIVE CONTENT On-Access-Viren
Seite 155 und 156:
9.2. ACTIVE CONTENT Erlaubt man die
Seite 157 und 158:
9.3. MOBILER CODE (AGENTEN) ihm nac
Seite 159 und 160:
9.4. FAZIT Die Autoren wenden das b
Seite 161 und 162:
Kapitel 10 Public-Key-Zertifizierun
Seite 163 und 164:
10.2. EINFÜHRUNG IN PUBLIC-KEY-VER
Seite 165 und 166:
10.3. PUBLIC-KEY-ZERTIFIZIERUNG 10.
Seite 167 und 168:
10.4. ZERTIFIZIERUNGSINSTANZEN 10.4
Seite 169 und 170:
10.5. PUBLIC-KEY-INFRASTRUKTUREN de
Seite 171 und 172:
10.5. PUBLIC-KEY-INFRASTRUKTUREN ei
Seite 173 und 174:
10.6. PKI-PRAXIS des ITU-Standards
Seite 175 und 176:
10.6. PKI-PRAXIS die Zertifikate f
Seite 177 und 178:
10.7. AUSBLICK 10.7.1 Entwicklungsr
Seite 179:
LITERATURVERZEICHNIS [TLS] Dierks,
Seite 182 und 183:
KAPITEL 11. CRACKER-TOOLS AM BEISPI
Seite 184 und 185:
Seite 186 und 187:
Seite 188 und 189:
Seite 190 und 191:
Seite 192 und 193:
Seite 194 und 195:
Seite 196 und 197:
Seite 198 und 199:
Seite 200 und 201:
Seite 202:
LITERATURVERZEICHNIS [Cert] http://
Alle anzeigen

Sicherheit in vernetzten Systemen - RRZ UniversitÃ¤t Hamburg

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?