Grundlagen der Rechnernetze

(1)

Grundlagen der Rechnernetze

Sicherheit in Rechnernetzen

(2)

Übersicht

• Motivation

• Verschlüsselung

– Einfache Verfahren und Anforderungsdiskussion – Symmetrische Verschlüsselungsverfahren

– Cipher-Block-Chaining (CBC)

– Asymmetrische Verschlüsselungsverfahren

• Nachrichtenintegrität

• Authentifizierung

• Internet-Beispiele

(3)

Motivation

(4)

Motivation

Sicherheit ist ein wesentlicher Aspekt bei der Vernetzung von Computern

Es gibt eine große Liste an Angriffsarten; z.B. gelistet in RFC 2828 (hier nur mal die Namen ohne weitere Diskussion): Exposure, Interception, Inference, Intrusion, Masquerade,

Falsification, Repudiation, Incapacitation, Corruption, Obstruction, Misappropriation, Misuse

In dieser Vorlesung nur ein kurzer ca. 60-Minuten-Einblick (bzw. Wiederholung) in eine Thematik, die eine ganze Vorlesung füllen kann

(siehe Veranstaltungen von Mauthe (z.B. Vorlesung Grundlagen der IT-Sicherheit) oder Jürjens (z.B. Vorlesung Kryptographische Mechanismen und ihre Verwendung in Software) Wir betrachten hier:

• Definition von Aspekten sicherer Datenkommunikation (folgende Folie)

• Kryptographie als wesentlicher Grundbaustein für Sicherheit in Computernetzen

• Nennen am Schluss drei typische Internet-Beispiele in denen auf Anwendungs-, Transport-, und Netzwerk-Layer Sicherheit eingebaut ist

(5)

Motivation

Aspekte der sicheren Datenkommunikation (nach Kurose/Ross)

• Confidentiality: Vertraulichkeit einer Nachricht; d.h. die Nachricht vor Einsicht durch Dritte schützen

• Integrity: Nachrichtenintegrität; d.h. Nachrichten vor Veränderungen durch Dritte schützen

• Endpoint-Authentification: Authentifizierung der Kommunikationsendpunkte; d.h.

sicherstellen, dass Sender und Empfänger die Identität des Gegenüber bestätigen können

• Operational Security: Operationale Sicherheit; d.h. Absichern einer vernetzen IT- Infrastruktur (Unternehmen, Uni etc.) vor Angriffen von außen (d.h. dem Internet) Oder die CIA-Dreiergruppe für Daten und Dienste (siehe z.B. Stallings)

• Confidentiality, Integrity, Availabilty (d.h. das System ist immer verfügbar und Dienste werden authorisierten Nutzern nicht verweigert)

• Ergänzt durch Authenticity und Accountability (d.h. Rückverfolgbarkeit der Verantwortlichen bei Verletzung von Regeln/Gesetzen)

(6)

Verschlüsselung

(7)

Eine offensichtliche Problemstellung

Die Art in welcher Beziehung die Schlüssel zueinander stehen unterscheiden wir zwischen

• Symmetrische Verschlüsselungsverfahren: Alice und Bob verwenden einen Schlüssel K (d.h. KA=KB), welcher keinem anderen bekannt sein darf

• Asymmetrische Verschlüsselungsverfahren: Alice verwendet zum Verschlüsseln

einen/den öffentlichen Schlüssel K1 von Bob. Der Schlüssel K2 zum Entschlüsseln darf nur Bob bekannt sein (d.h. (K1,K2) bilden ein Schlüsselpaar)

Schlüssel KA (Key)

Angreifer

Schlüssel KB (Key)

Alice Bob

Verschlüsselungs-

algorithmus Entschlüsselungs-

Algorithmus

Plain-Text m Cipher-Text

c = KA(m)

Trudy

Plain-Text m = KB(c) = KB(KA(m))

(8)

Verschlüsselung

Einfache Verfahren und Anforderungsdiskussion

(9)

Caesar-Chiffre

Eine der einfachsten Formen der Verschlüsselung; am Beispiel:

a b c d e f g h i j k l m n o p q r s t u v w x y z

↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ e f g h i j k l m n o p q r s t u v w x y z a b c d

Zum Beispiel: affe → ejji

D.h. der Schlüssel ist einfach der Offset k (im Beispiel k=4)

Diese Verschlüsselung ist natürlich einfach zu knacken; z.B. Brute-Force einfach 25 Versuche (bei Alphabet der Größe 26)

Verbesserung?

(10)

Monoalphabet-Chiffre

Verwende eine bijektive Abbildung stattdessen; zum Beispiel:

a b c d e f g h i j k l m n o p q r s t u v w x y z

↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ o r w u g q i a p f m v x d n l z b c y e t k j s h

Zum Beispiel: affe → oqqg

D.h. der Schlüssel ist eine Permutation des Alphabets

Es gibt hier 26 Fakultät viele Permutationen; damit ist eine Brute-Force-Attacke (d.h.

einfaches Duchprobieren aller 26! = 403291461126605635584000000 Möglichkeiten) hier nicht sinnvoll möglich

Ist das Verfahren damit mit sicher?

(11)

Lässt sich leicht angreifen

Statistische Analyse von Buchstabenhäufigkeiten

Beispiel Buchstabenhäufigkeiten der englische Sprache: e = 13%, t=9%, ...

Statistische Häufigkeit im Ciper-Text lässt Rückschlüsse zu, welchem Buchstaben dieser im Plain-Text entspricht

Zusätzlich lassen sich z.B. auch noch Buchstabenpaare oder Buchstabentripel statistisch analysieren und analog verfahren

Im Englischen z.B.: in, it, the, ing, ion, ...

Testen von möglichem Vorkommen eines Wortes im Plain-Text

Ist z.B. bekannt (oder vermutet), dass die Namen Alice, Bob im Plain-Text vorkommen, lassen sich Stellen im Cipher-Text auf vorkommen der Wörter „Alice“ und „Bob“ testen.

Falls wir richtig liegen ist der Teil der bijektiven Abbildung für die Buchstaben a, l, i, c, e, b, o auf einen Schlag ermittelt

Ist erst mal die Abbildung für einen Buchstaben gefunden, ist jedes Vorkommen des Buchstaben im Ciper-Text entschlüsselt!

(12)

Zwischenbilanz

Wir können folgende generelle Angriffsszenarien festhalten:

• Cipher-Text-Only: d.h. nur der Cipher-Text ist bekannt

• Known-Plain-Text: Teile des Plain-Textes sind bekannt (oder vermutlich vorhanden)

• Chosen-Plain-Text: Der Angreifer darf sogar Plain-Text verwenden und daraus Ciper- Text generieren

z.B. würde Eingabe des folgenden Plain-Text in den vorigen Verfahren den Schlüssel unmittelbar verraten: (warum?)

the quick brown fox jumps over the lazy dog

Problem der bisher betrachteten Chiffre: Plain-Text-Buchstabe wird immer auf denselben Cipher-Text-Buchstaben abgebildet.

Verbesserung: Polyalphabet-Verschlüsselung

(13)

Polyalphabet-Chiffre

Idee:

• verwende mehrere Mono-Alphabet-Verschlüsselungen (z.B. bezeichnet als C1, C2, C3,

… im Folgenden)

• Die Buchstaben-Position im Plain-Text bestimmt, welche der Abbildungen C1‚ C2, C3, ...

zu verwenden ist

• (z.B. das Muster: erster Buchstabe C1, zweiter Buchstabe C2, dritter Buchstabe C2, vierter Buchstabe C1, fünfter Buchstabe C1 sechster Buchstabe C2 und dann ab dem siebten Buchstaben wieder von vorne)

• Also kurz: C1 C2 C2 C1 C1 C2

Ein Beispiel mit einfachen Caesar-Chiffren

• C1: Caesar-Chiffre mit k=3

• C2: Caesar-Chiffre mit k=5

• und das Muster C1 C2 C1 C1 C2

• Der Schlüssel wäre hier z.B. wie folgt sinnvoll beschrieben: (C1: k=3, C2: k=5; Pattern:

C1 C2 C1 C1 C2)

(14)

Polyalphabet-Chiffre

Der Schlüssel (C1: k=3, C2: k=5; Pattern: C1 C2 C1 C1 C2), d.h.

Plaintxt: a b c d e f g h i j k l m n o p q r s t u v w x y z C1 (k=3): d e f g h i j k l m n o p q r s t u v w x y z a b c C2 (k=5): f g h i j k l m n o p q r s t u v w x y z a b c d e mit Pattern C1 C2 C1 C1 C2

ergibt zum Beipiel:

affe → dkij

(also hier z.B. zweimal Vorkommen von f im Plain-Text führt nicht zwangsläufig zu zweimal Vorkommen von f im Cipher-Text; und generell auch zweimal vorkommen des gleichen Buchstaben im Cipher-Text bedeutet nicht, dass beide demselben Buchstaben im Plain- Text entsprechen müssen)

(15)

Diskussion

Die bisherigen Beispiele:

• Motivation, um die vorliegende Verschlüsselungsproblematik zu illustrieren

• Wir haben auch nur die Idee der symmetrischen Verschlüsselung gesehen (d.h. Alice und Bob verwenden nur einen Schlüssel zum chiffrieren und dechiffrieren und der Schlüssel darf nicht preisgegeben werden!)

Jetzt: befassen uns (kurz) mit realen Verfahren:

• Zunächst symmetrische Verschlüsselungsverfahren

• dann asymmetrische Verschlüsselungsverfahren (sog. Public-Private-Key-Verfahren)

• des weiteren sehen wir, dass wir für sichere Kommunikation auch mehr als nur Verschlüsselung von Nachrichten benötigen

(16)

Verschlüsselung

Symmetrische Verschlüsselungsverfahren

(17)

Symmetrische Verschlüsselung

Generelles Unterscheidungsmerkmal: Stream-Verschlüsselung und Block-Verschlüsselung Im Folgenden besprechen wir nur Block-Verschlüsselung

Block-Verschlüsselung findet Anwendung in vielen Internet-Protokollen: z.B. PGP (Secure- Mail), SSL (Secure TCP-Connection), IPsec (Secure-Network-Layer)

Blockverschlüsselung bedeutet:

• Aufteilen der Bits des Plain-Textes in k-Bit-Blöcke

• Abbilden jedes Plain-Text-Blockes auf einen CiphertextBlock

(18)

Ein einfaches Beispiel

Abbildung von 3-Bit-Blöcken:

000 → 110 001 → 111 010 → 101 011 → 100 100 → 011 101 → 010 110 → 000 111 → 001

Also eine der hier 2^3! = 40.320 vielen möglichen Permutationen,

die mittels Brute-Force-Attacke allerdings schnell durchprobiert wären!

Folglich: k sollte wesentlich größer als 3 sein

Zum Beispiel k=64 (typische Blockgröße in realen Systemen; oder auch noch größer) k=64 bedeutet 2^64 Fakultät viele

Möglichkeiten (d.h. Schlüssel)

Somit: Brute-Force-Attacke nicht möglich Ein Problem bleibt: wie implementiert man k-Bit auf k-Bit Abbildung?

Einfache Tabelle mit 2^k (z.B. 2^64 =

18.446.744.073.709.551.616) Einträgen??

• Speicheraufwand!

• Kommunikationsaufwand, den

Schlüssel überhaupt erst mal (geeignet gesichert) auszutauschen!

(19)

Lösung: Simulation in Runden

Besser: Permutation wird durch eine Funktion bestehend aus vielen kleinen Permutationstabellen mit nachgeschaltetem Scrambler in n Runden simuliert.

8 Bit 8 Bit 8 Bit 8 Bit 8 Bit 8 Bit 8 Bit 8 Bit 64 Bit Eingabe

T1 T2 T3 T4 T5 T6 T7 T8

8 Bit 8 Bit 8 Bit 8 Bit 8 Bit 8 Bit 8 Bit 8 Bit 64 Bit Scrambler

64 Bit Ausgabe

n Mal

acht mal 8-auf-8

Permutations- tabellen

festes ver- tauschen der Bitpositionen

(20)

Diskussion

Wozu die Runden?

• Eine Runde bedeutet: ein Eingabebit kann höchstens 8 Ausgabebits beeinflussen

• n Runden bedeutet: ein Eingabebit beeinflusst möglicherweise (idealerweise) alle Ausgabebits

Was ist hier eigentlich der Schlüssel?

• Wenn der Scrambler in dem Verfahren fix ist, sind es die acht 8-auf-8-Bit- Permutationstabellen

• (d.h. 8 Tabellen mit 2^8=256 Einträgen pro Tabelle)

Wie eigentlich entschlüsseln? Verfahren einfach rückwärts laufen lassen (selber Schlüssel) Bekannte Verfahren aus der Praxis, die nach diesem Grundprinzip funktionieren:

• DES (Data Encryption Standard) (64-Bit-Blöcke)

• 3DES (Triple DES) (64-Bit-Blöcke)

(21)

Diskussion

Allerdings: Anstatt über Tabelle festgelegter Permutationen verwenden die genannten Verfahren

• geeignete Funktionen, die aus einem gegebenen

• Bit-String als Key als Eingabe der Funktionen, die Permutationen damit berechnen

Beispiel:

• DES verwendet 56-Bit-Key

• AES verwendet 128-, 192- oder 256-Bit-Keys

Je länger der Schlüssel desto aufwendiger wird natürlich eine Brute-Force-Attacke

Ein einfacher Vergleich: Was ist der Unterschied z.B. zwischen 56-Bit DES und 128-Bit AES?

• Annahme durchprobieren aller 2^56 Schlüssel sei mit gegebener Rechenleistung z.B. in in einer Sekunde möglich

• Man würde bei gleicher Rechenleistung zum Durchprobieren aller 2^128 AES-Schlüssel

(22)

Verschlüsselung

Cipher-Block-Chaining (CBC)

(23)

Cipher-Block-Chaining (CBC)

Was geschieht eigentlich, wenn wir „HTTP/1.1“ zweimal hintereinander mit 64-Bit-Block- Verschlüsselung versenden?

• „HTTP/1.1“ entspricht einem 64-Bit-Block

• Folglich taucht im Cipher-Text zweimal der identische verschlüsselte Block auf

• Wie in der Motivation am Anfang diskutiert (vgl. Diskussion Cesar-Chiffre) ist das problematisch

Lösung: Cipher-Block-Chaining (CBC)

• Seien m(i) der ite Plain-Text-Block

• c(i) der ite Cipher-Text-Block

• Sei: K(x) die Verschlüsselungsoperation angewendet auf Block x Wir verfahren wie folgt:

(24)

Cipher-Block-Chaining (CBC)

1. Generiere Zufallsbitstring in der Länge eines Blocks (z.B. 64 Bit-Block)

• Diesen bezeichnen wir als Initialisierungsvektor(IV) bzw. kurz c(0)

• Sende c(0) unverschlüsselt an den Empfänger der Blöcke 2. Erster versendeter Block

• c(1) = K( m(1) XOR c(0) ) 3. Alle weiteren versendeten Blöcke

• c(i) = K( m(i) XOR c(i-1) ) Entschlüsseln ist nach wie vor möglich

• c(0) ist bekannt

• c(1) → (m(1) XOR c(0)) XOR c(0) = m(1)

• c(2) → (m(2) XOR c(1)) XOR c(1) = m(2)

• ...

Zwei identische zu versendende Plain-Text-Blöcke werden als Cipher-Text-Blöcke so gut

(25)

Verschlüsselung

Asymmetrische Verschlüsselung

(26)

Grundprinzip

Gewährleistet muss dabei sein:

• Private-Key ist niemandem außer dem Besitzer des Public-Key bekannt

• Private-Key lässt sich nicht mit vertretbarem Aufwand aus dem bekannten Public-Key zurückrechnen

• (Brute-Force einfach alle Private-Keys mit vorgegebenem Plain-Text durchprobieren geht immer, ist aber bei entsprechender Schlüssellänge nicht mit vertretbarem Aufwand

Verschlüsseln Cipher-Text Entschlüsseln KB+(m)

Plain-Text m Plain-Text m =

KB-(KB+(m)) Private-Key KB- Public-Key KB+

Alice Bob

(27)

RSA-Algorithmus

Das etablierte Verfahren: RSA-Algorithmus (Rivest, Shamir, Adleman) Generieren des Schlüsselpaars:

• Wähle zwei große verschiedene Primzahlen p und q (z.B. Empfehlung RSA-Laboratories:

p*q sollte in der Größenordnung 1024 Bits sein)

• Setze n = p*q und z = (p-1)*(q-1)

• Wähle ein e < n, sodass e keinen gemeinsamen Faktor (mit Ausnahme 1) mit z hat (wir sagen e und z sind relativ prim zueinander)

• Finde d, sodass e * d -1 ohne Rest durch z teilbar ist Definiere die Keys K+ und K- wie folgt:

• Public-Key: K+ = (n,e)

• Private-Key K- =(n,d)

Verschlüsseln: c = m^e mod n (x mod n = x-(x DIV n)*n; DIV = ganzzahlige Division) Entschlüsseln: m = c^d mod n

(28)

Nachgerechnet

c^d mod n = (m^e)^d mod n = m^(e*d) mod n

[Ein hier wichtiges Resultat aus der Zahlentheorie: wenn p und q Primzahlen sind und n = p*q, dann ist x^y mod n = x^(y mod (p-1)*(q-1)) mod n]

Damit: m^(e*d) mod n = m^(e*d mod (p-1)*(q-1)) mod n

[e und d waren so gewählt, dass e*d - 1 durch (p-1)*(q-1) teilbar ist, bzw. e*d geteilt durch (p-1) (q-1) den Rest 1 erzeugt, d.h. e*d mod (p-1)*(q-1) = 1]

Somit: m^(e*d mod (p-1)*(q-1)) mod n = m^1 mod n = m (sofern die Nachricht m <= n ist)

Eine wichtige Beobachtung:

m = (m^e)^d mod n = m ^(e*d) mod n = (m^d)^e mod n

Somit: Nachricht kann auch mit dem privaten Schlüssel chiffriert und mit dem öffentlichen Schlüssel dechiffriert werden!

(29)

Public-Key-Zertifizierung

Asymmetrische Verschlüsselung hat ein Dilemma:

• Jeder kann Public-Private-Key-Paare generieren und den Public-Key bekannt machen

• Verwendet Bob den Public-Key von Alice, woher weiß Bob, dass es tatsächlich Alice ist, mit der er verschlüsselt kommuniziert

Es braucht einen Vertrauens-Mechanismus, anhand dessen sichergestellt ist, dass es sich bei Verwendung des öffentlichen Schlüssels eines Kommunikationspartners tatsächlich auch um den Kommunikationspartner handelt

D.h. Zertifizierung, mit der durch digitale Signatur einer Zertifizierungseinrichtung (Certification Authority (CA)) der öffentlichen Schlüssels inklusive der zugehörigen Authentifizierungsdaten als valide unterzeichnet ist. Beipieleinrichtungen:

• Bank

• Zertifizierungsunternehmen

• staatliche Einrichtung

(30)

Public-Key-Zertifizierung

In der Regel nutzt man Ketten von Zertifizierungen:

• Man nutzt ein unterzeichnetes Zertifikat einer Einrichtung B, deren Zertifikate man trauen kann, da B ein Zertifikat A→B einer Einrichtung A (auf höherer Ebene) hält, der schon vertaut wird

• Oder allgemein: wenn man A1 vertraut kann man mit A1 →A2 →... →An auch An vertrauen

Es gibt zwei Prinzipielle vorgehensweisen:

• Hierarchisch (X.509 Zertifikate): hierarchisches System von Zertifizierungs- und Registrierungsstellen

• Web-of-Trust (PGP): Schlüsselpaar erzeugen und sich über das Web-of-Trust mit Zertifikaten versorgen

Konkretes Beispiel: DFN-PKI (verwendet X.509 Zertifikate) über unser Uni-Rechenzentrum:

https://www.uni-koblenz-landau.de/de/koblenz/GHRKO/service/zertifikats-verwaltung

„Seit Oktober 2007 betreibt das Rechenzentrum eine eigene Zertifikats-Verwaltung, d.h. wir können Zertifikate für den verschlüsselten Zugriff auf Uni-eigene Webserver, Verschlüsselung von E-Mails (S/MIME) etc. ausstellen. Die Zertifikatskette dieser Zertifikate lässt sich über den DFN-Verein bis zu einer Zertifizierungsstelle der Deutschen Telekom verfolgen, deren root-Zertifikat in der Regel in der Standardausstattung vieler Programme schon vorhanden ist, so dass die Zertifikate ohne weiteres Zutun als korrekt angesehen werden.“ [GHRKO Webseite]

(31)

Weiteres

Asymmetrische Verschlüsselung ist „teuer“

• Verschlüsselungsoperationen sind um mehrere 10er-Potenzen langsamer als in z.B. in Hardware implementierte symmetrische Verfahren

• Somit wird häufig im Mix verfahren: Public-Key-Verfahren zum sicheren Austausch eines symmetrischen Schlüssels (den dann nur beide Kommunikationsendpunkte kennen) und Verwendung dieses temporären Schlüssels für diese Session

(32)

Nachrichtenintegrität

(33)

Kryptographische Hashfunktionen

Frage: wie stellt man sicher, dass eine Nachricht nicht verändert wurde?

Zunächst: kryptographische Hash-Funktionen

• Abbilden einer Nachricht m auf einen Bit-String H(m) fester Länge.

(Internet-Checksummen-Algorithmus oder CRC macht das doch auch?!?)

• und zusätzlich!: es ist nicht mit vertretbarem Rechenaufwand möglich, zu gegebener Nachricht x eine Nachricht y zu finden, sodass H(x) = H(y) gilt.

Ein Beispiel (nach Kurose/Ross) (Abkürzung IOU = I owe you) Bob sendet an Alice: IOU100.99BOB

4-Byte-Checksumme:

I O U 1 I O U 9 0 0 . 9 0 0 . 1 + 9 B O B + 9 B O B --- --- B2 C1 D2 AC = B2 C1 D2 AC

d.h. hier ist H(IOU100.99BOB)

= H(IOU900.19BOB) !!

Eine kryptographische Hash- Funktion sollte

H(IOU100.99BOB) !=

H(IOU900.19BOB) so gut wie sicher gewährleisten.

(34)

Kryptographische Hashfunktionen

Bekannte kryptographische Hash-Funktionen:

• MD5 (von Ron Rivest): 128-Bit-Hash

• SHA-1 (Secure Hash-Algorithm): 160-Bit-Hash

Frage: gewährleistet eine kryptographische Hash-Funktion schon Nachrichtenintegrität?

Solange Bob nicht feststellen kann, dass Trudy sich als Alice ausgibt, empfängt er angeblich

Alice Alice: (m, H(m)) Bob

Trudy

(35)

Kryptographische Hashfunktionen

Lösung: Alice und Bob brauchen ein geteiltes Geheimnis: Bit-String s; sog. Message- Authentication-Key (MAC)

Alice Bob

(m, H(m konkateniert mit s))

Message Authentication Code (MAC)

rechnet nach:

H(m konkatieniert mit s) und vergleicht mit

empfangenem MAC

Trudy

???

(m, H(m konkateniert mit ???))

Trudy kennt s nicht und kann damit MAC nicht erzeugen

(36)

Digitale Unterschrift

Asymmetrische Verschlüsselung kann auch genutzt werden

• um Nachrichtenintegrität sicherzustellen

• und um nachzuweisen, dass die Nachricht vom Besitzer des Private-Keys stammt

Verwende den privaten Schlüssel K-, um die Nachricht m zu verschlüsseln!

• Nur der Besitzer des Schlüssel K-, konnte die Nachricht in die Form K-(m) bringen, sodass K+(K-(m)) = m ergibt.

• Und: jede Änderung von m in m‘ ist unmittelbar nachweisbar, da K+(K-(m)) = m != m‘

Mit kryptographischen Hash-Funktionen genügt es auch nur den Hash H(m) der Nachricht m digital zu unterzeichnen, d.h. K-(H(m)).

Gültigkeit ist sofort nachweisbar; berechne K+(K-(H(m)) und vergleiche mit H(m)

(37)

Authentifizierung

(38)

Problemstellung: Alice (Client) möchte mit Bob (Server) kommunizieren und Server soll sicher sein, dass die Anfragen auch von Alice stammen.

Wir entwickeln schrittweise ein Authentifizierungsverfahren (Idee nach Kurose/Ross) 1. Versuch: sende eine Nachricht in der man sich als Alice ausgibt

Schrittweise Entwicklung eines Authentifizierungsverfahrens

Alice Ich bin Alice Bob

Alice Bob

Trudy

(39)

2. Versuch: nutze eine IP-Adresse, die für Alice steht

Problem: IP-Adressen können in den IP-Paket-Headern überschreiben werden

Es ist (zwar wünschenswert aber) nicht garantiert, dass Router solche gefälschten IP- Pakete automatisch verwerfen

Schrittweise Entwicklung eines Authentifizierungsverfahrens

meine IP-Adr Alice Bob

Trudy

(40)

3. Versuch: nutze ein Passwort, auf das sich Alice und Bob vorher geeinigt hatten

Das Problem besteht selbst, wenn Alice und Bob einen vorher vereinbarten geheimen Schlüssel K verwenden:

Schrittweise Entwicklung eines Authentifizierungsverfahrens

mein Passwort Alice Bob

Trudy

Trudy Recor

der

(41)

3. Versuch: Variante: nutze ein Passwort, auf das sich Alice und Bob vorher geeinigt hatten und verschlüssele mit dem vorher vereinbarten geheimen Schlüssel K

Den Angriff nennt man eine sogenannte Playback-Attacke

Schrittweise Entwicklung eines Authentifizierungsverfahrens

K(Passwort) Alice Bob

Trudy

Trudy Recor

der

(42)

4. Versuch und Lösung: nutze einen vorher vereinbarten geheimen Schlüssel K und einen sog. Nonce R

Damit ist eine Playback-Attacke nicht mehr möglich, weil beim nächsten mal ein anderer

Lösung mit symmetrischer Verschlüsselung

R

K(R)

Bob wählt einen Nonce R

(von Bob frei wählbare Nummer, die nur einmalig genuzt wird)

(43)

Voriges Protokoll verwendet symmetrische Verschlüsselung, d.h. Alice und Bob müssen sich vorher auf einen gemeinsamen geheimen Schlüssel geeinigt haben)

Das Prinzip funktioniert aber in einer Public-Key-Infrastruktur:

Lösung mit asymmetrischer Verschlüsselung

Alice Ich bin Alice Bob R

KA-(R)

KA+

Aber Achtung: das funktioniert nur, wenn der öffentliche Schlüssel auch (zertifiziert) Alice sicher zugeordnet werden kann.

Ansonsten:

(44)

Bei fehlender Zertifizierung gibt sich Trudy einfach fälschlicherweise als Alice aus:

Erfordert sichere Zuordnung des öffentlichen Schlüssels!

Trudy Ich bin Alice Bob R

KT-(R)

KT+

Schlimmer noch:

(45)

Fehlende Zertifizierung ermöglicht auch eine Man-in-the-Middle-Attacke:

Erfordert sichere Zuordnung des öffentlichen Schlüssels!

Trudy Ich bin Alice Bob

KT-(R)R Bob wählt einen Nonce R (von Bob frei wählbare Nummer, die nur einmalig genuzt wird)

KT+

Alice Ich bin Alice

R

KA+

KT+(m) m KA+(KT-(KT+(m))) =

KA+(m) m=KA-(KA+(m))

Für Alice und Bob ist nicht erkennbar, dass Trudy alles

mitlesen kann KA-(R)

(46)

Internet-Beispiele

(47)

Anwendungsschicht: Fallstudie Email

• PGP (Pretty-Good-Privacy): in der Regel als Plug-In im User-Agent zu installieren

• S/MIME: häufig schon im User-Agent vorhanden und muss nur aktiviert werden

• Kryptographische Grundfunktion von PGP und S/MIME ist gleich:

Nachrichtenverschlüsselung, Nachrichtenintegrität und End-Point-Authentifizierung (durch Verwendung von Public-Keys)

• Ein wesentlicher Unterschied ist die Gestaltung der Vertrauensbasis der Zertifikate:

• PGP: Web-of-Trust, d.h. der Nutzer entscheidet selbst, wem er vertraut und wem nicht; Vorteil: der Nutzer bleibt damit Autonom; Nachteil: Nutzer ist ggf.

überfordert, da er gar nicht weiß was er da tut

• S/MIME: Hierarchisch (X.509 Zertifikate), d.h. der Nutzer gibt die Kontrolle an Zertifizierungseinrichtungen ab; Vorteil: man muss nicht entscheiden, wem man vertraut; Nachteil: Nutzer ist abhängig von einem mächtigen CA-System (die entscheiden, wem getraut werden kann, wann ein Zertifikat abläuft und wieder erneuert werden muss, oder dass ein Zertifikat für ungültig erklärt wird)

(48)

Transportschicht: Fallstudie TCP

TCP erweitert mit Sicherheitsfeatures Vertraulichkeit, Datenintegrität und Endpunkt- Authentifizierung: Secure Socket Layer (SSL) und leicht modifiziertes SSLv3 genannt Transport Layer Security (TLS) (standardisiert durch IETF RFC 2246)

Unterstützung durch alle gängigen Browser und Webserver

(Verwendung durch Browser leicht erkennbar: https anstatt http) Aber ist nicht auf HTTP beschränkt

Generell: es wird dem Anwendungsprogrammierer basierend auf TCP im Application-Layer ein SSL-Sublayer und darauf ein SSL-Socket gesetzt (aus Sicht des

Anwendungsprogrammierer sind es Funktionen auf der Transportschicht)

(49)

Netzwerkschicht: Fallstudie IPsec

Komplexe Ansammlung von Protokollen für Sicherheit auf IP. (mehr als ein Dutzend RFCs) Es geht um Vertraulichkeit, Nachrichtenintegrität und End-Point-Authentifizierung

(letzteres verhindert IP-Spoofing, d.h. sich mit falscher IP-Adresse ausweisen) auf Ebene von IP-Nachrichten.

Header und Payload höherer Protokolle (TCP, UDP, ICMP etc.) werden wie üblich in IP- Paketen als Payload (verschlüsselt oder unverschlüsselt) behandelt

Es gibt bei IPsec zwei wesentliche Protokolle:

• Authentication Header (AH) Protocol: (Source-Authentifizierung und Nachrichtenintegrität)

• Encapsulation Security Payload (ESP) Protocol: (Source-Authentifizierung, Nachrichtenintegrität und Vertraulichkeit)

(50)

Zusammenfassung und Literatur

(51)

Zusammenfassung

• Wir besprachen ein paar wesentliche Punkte

– Nachrichtenverschlüsselung – Nachrichtenintegrität

– Endpunkt-Authentifizierung

• Betrachtete grundlegende Verfahren sind die Basisbausteine für konkrete Protokolle auf verschiedenen Ebenen

– Wir haben drei wichtige Internet-Beispiele genannt:

PGP bzw. S/MIME, SSL bzw. TLS und IPsec

– Es gibt noch einige weitere Beispiele, u.a. auch auf MAC-Ebene (z.B. WLAN)

• Sicherheitsfeatures auf allen Schichten sinnvoll

– Die Wahl der Schicht(en) hängt vom Anwendungskontext ab – Beispiele:

• E-Mail: Application-Layer für ausgewählte e-Mails

• Web, alle SMTP-Verbindungen: Transport-Layer (SSL, TLS)

• VPN: Netzwerk-Layer (IPsec)

• Funknetze: MAC-Layer (z.B. WLAN-Verschlüsselung)

• Wir haben hier Sicherheitsaspeke im Kontext von einzelnen Kommunikations-Sessions betrachtet

• Weitere Sicherheitsaspekte sind Schutz ganzer Netze/Systeme, d.h. Operationale Sicherheit (Firewalls, Intrusion-Detection-Systems)

Grundlagen der Rechnernetze