Symmetrische Verschlüsselung

Verschlüsselung

Symmetrische Verschlüsselungsverfahren

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

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!

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

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äge 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)

• AES (Advances Encryption standard) (128‐Bit‐Blöcke)

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 

Verschlüsselung

Cipher‐Block‐Chaining (CBC)

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:

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 

Verschlüsselung

Asymmetrische Verschlüsselung

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 

möglich)

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

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

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!

Wozu ist das gut? → siehe gleich behandeltes neues Thema: Nachrichtenintegrität

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

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 Zer fikat 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]

DFN = Verein Deutsches Forschungsnetz zur Förderung der Rechnerkommunikation im Forschungskontext

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

Nachrichtenintegrität

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.

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  integre Nachrichten von Alice

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

Trudy

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

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)

Authentifizierung

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

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

Alice Ich bin Alice Bob

meine IP‐Adr Alice Bob

Trudy

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

Alice Ich bin Alice Bob

mein Passwort Alice Bob

Trudy

Trudy Recor

der

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

Alice Ich bin Alice Bob

K(Passwort) Alice Bob

Trudy

Trudy Recor

der

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  mit dem geheimen Schlüssel K verschlüsselter Nonce abgefragt wird.

Lösung mit symmetrischer Verschlüsselung

Alice Ich bin Alice Bob

R

K(R)

Bob wählt einen Nonce R

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

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)

Bob wählt einen Nonce R

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

KA+

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

Ansonsten:

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)

Bob wählt einen Nonce R

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

KT+

Schlimmer noch:

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

Erfordert sichere Zuordnung des öffentlichen Schlüssels!

Trudy Ich bin Alice Bob R

KT‐(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+

m KT+(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)

Internet‐Beispiele

Anwendungsschicht: Fallstudie Email

Hier am Beispiel PGP (Pretty‐Good‐Privacy); Plug‐In für alle gängigen Email‐User‐Agents PGP ermöglicht Nachrichtenverschlüsselung, Nachrichtenintegrität und End‐Point‐

Authentifizierung (durch Verwendung von Public‐Keys auf Vertrauensbasis) Es wird im Wesentlichen nach folgendem Schema verfahren

Alice

m

+

m

H(.) KA‐(.)

KA‐(H(m))

KS(.)

+ KB+(.)

KS

Internet

Anwendungsschicht: Fallstudie Email

Für jede Mail besteht die Möglichkeit: verschlüsseln und/oder signieren Message‐Digest (d.h. kryptographischer Hash): MD5 oder SHA

Symmetrische Verschlüsselung der Nachricht: CAST, 3DES, oder IDEA

Asymmetrische Verschlüsselung des Keys für die symmetrische Verschlüsselung: AES Optional: Nachrichtenkompression

Wie werden eigentlich Verschlüsselter Session‐Key, Signatur und ggf. weitere 

Informationen in der Mail von Alice nach Bob über reguläres SMTP kommuniziert? ‐> 

Erinnerung: MIME‐Header vor eigentlichem Nachrichteninhalt einer Mail

Anwendungsschicht: Fallstudie Email

Dies war eine Fallstudie [Ross/Kurose]. Ein weiterer wichtiger Standard ist S/MIME

• Kryptographische Grundfunktion von PGP und S/MIME ist gleich

• 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)

• Verfügbarkeit

• S/MIME ist häufig schon im User‐Agent drin und muss nur aktiviert werden

• PGP muss in der Regel als Plug‐In in den User‐Agent installiert werden

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)

SSL besteht aus drei Phasen: Handshake, Key‐Derivation und Data‐Transfer

Transportschicht: Fallstudie TCP

Bob Alice

TCP SYN TCP/SYNACK

TCPACK

SSL hello certificate

EMS=KA+(MS) Handshake

Reguläre TCP‐

Verbindungsherstellung  mit Alice

Verifikation des Users  Alice

Erzeuge Master‐Secret MS und  sende diesen verschlüsselt an  Alice; beide Nutzen diesen 

anschließend um daraus Session‐

Keys zu berechenen

Transportschicht: Fallstudie TCP

Key‐Derivation: aus dem Master‐Key werden vier separate Schlüssel für die Session  generiert:

EB = Session‐Key zum Versenden von Daten von Bob zu Alice

MB = Session‐MAC‐Key zur Gewährleistung der Integrität der Nachrichten von Bob zu Alice EA = Session‐Key zum Versenden von Daten von Alice zu Bob

MA = Session‐MAC‐Key zur Gewährleistung der Integrität der Nachrichten von Alice zu Bob

Daten‐Transfer:

TCP ist ein Byte‐Strom; wann sollte eigentlich die Integrität der Nachricht mittels MAC  gesichert werden?

Der Byte‐Strom wird in Records aufgeteilt. Jedem Record wird der MAC (d.h. 

kryptographische Hash‐Funktion angewendet auf Record‐Daten inklusive des MAC‐Keys)  des Records angehangen und diese werden dann verschlüsselt

Transportschicht: Fallstudie TCP

Wie sichert man aber einen Strom mit mehreren aufeinanderfolgenden Records vor  Vertauschen/Löschen/Duplizieren? (IP ist nicht verschlüsselt und könnte entsprechend  modifiziert werden, sodass diese Modifikation der Records prinzipiell möglich wäre) Lösung:

• Jeder Record erhält eine um eins inkrementierte Record‐Nummer (startend bei 0)

• Nummer wird bei Berechnung des MAC mitverwendet (d.h. Hash angewendet auf  Daten plus Sequenznummer)

• Alice trackt die Sequenznummern und wendet diese bei Überprüfung des MAC  ebenfalls an und kann damit oben genannte Angriffe detektieren

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)

Beide Protokolle Nutzen Handshaking, um eine unidirektionale logische Ende‐zu‐Ende‐

Verbindung auf Netzwerkebene herzustellen (genannt Security‐Association (SA)) SA ist durch 32‐Bit Kennung identifiziert: genannt Security‐Parameter‐Index (SPI) Jedes IP‐Paket einer SA wird mit diesem SPI abgestempelt

Zusammenfassung und Literatur

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 gesehen

–

Es gibt noch viele 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)

Literatur

• James F. Kurose, Keith W. Ross, „Computer 

Networking: A Top‐Down Approach“, 4th Edition,  2008

– 8.1 What Is Network Security?

– 8.2 Principles of Cryptography – 8.3 Message Integrity

– 8.4 End‐Point Authentication – 8.5 Securing E‐mail

– 8.6 Securing TCP Connections: SSL

– 8.7 Network‐Layer Security: IPsec

– 8.10 Summary