Kryptografie 2

Kryptografie
2
Seite 1
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Schlüsselverwaltung
Key-Management
sichere Schlüsselübertragung zw. Teilnehmern
Schlüsselverwaltungszentrum
unerwartet komplexes Problem
bei Kommunikation zwischen N Terminals
verschiedene Schlüssel zu verwalten
N⋅ N −1
2
verschiedene Verfahren
IBM
ISO 8732
in der Regel O(N) Schlüssel
Seite 2
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Schlüsselverwaltung
Schlüsselhierarchie
MasterTerminal- und
Sitzungsschlüssel
Schlüsselverwaltungszentrum
key distribution center
auch security center
geheimer Terminalschlüssel kt
geheime Nachrichten an Terminal
insb. Sitzungsschlüssel ks
Seite 3
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Schlüsselverteilung
Schlüsselverwaltungszentrum sendet
Sitzungschlüssel ks an beide Stationen
Seite 4
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Schlüsselverteilung
Schlüsselverwaltungszentrum sendet an eine Station
Sitzungschlüssel ks
verschlüsselten Sitzungschlüssel Ekt2(ks)
Seite 5
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Schlüsselverteilung
Authentifizierung von T1 gegenüber T2
Seite 6
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Schlüsselverteilung
Authentifizierung von T1 gegenüber Schlüsselzentrum
Seite 7
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Schlüsselverteilung
Authentifizierung von T2 gegenüber T1
Seite 8
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Schlüsselverteilung
Zeitmarken, um Sammeln von Schlüsseln zu verhindern
Seite 9
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Tamper Resistant Module
Verteilung der Terminal-Schlüssel
2 Master-Schlüssel
Seite 10
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Tamper Resistant Module
Verschlüsseln für Host
Seite 11
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Tamper Resistant Module
Entschlüsseln für Host
Seite 12
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Tamper Resistant Module
Dechiffrieren von ks, falls km0=km1.
Seite 13
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Tamper Resistant Module
Dechiffrieren von ks, falls km0≠km1.
Seite 14
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Schlüsselverteilung im Internet
ISAKMP (Internet Security Association and Key
Management Protocol, RFC 2408)
Rahmenwerk: Authentifizierung, Schlüsselaustausch
von speziellen Verfahren unabhängig
Oakley (RFC 2412)
mehrere Schlüsselaustauschverfahren für
Sicherheit,
Identitätsschutz
Authentifizierung
SKEME: Versatile Secure Key Exchange
IKE (Internet Key Exchange, RFC 2409)
Seite 15
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Schlüsselverteilung im Internet
ISAKMP
Oakley (RFC 2412)
SKEME: Versatile Secure Key Exchange
Anonymität,
Nachweisbarkeit
schnelle Schlüsselerneuerung
IKE (Internet Key Exchange, RFC 2409)
Erstellung authentifizierter Schlüssel
IPsec
bezieht sich auf Oakley und Teilen von SKEME
Seite 16
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Key-Management
Internet Key Exchange (IKE)
vereinfachtes Verfahren zum Aufbau sicherer,
authentifizierter Verbindungen
Modes, in denen Schlüssel ausgetauscht werden
eine oder zwei Phasen
1. Phase
sichere, authentisierte Verbindung
2. Phase
Schlüssel ausgetauscht
in verschiedenen Protokollen benötigt
einzelne Schlüssel von Masterschlüssel abgeleitet
Seite 17
Verschlüsselung
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IKE: Phase 1
sichere Verbindung zw. 2 Teilnehmern
aufgebauen
RFC 2409: ISAKMP Security Association (SA)
2 Modi
Hauptmodus (main mode)
drei Nachrichtenpaare
jeweils einer Anfrage und einer Antwort
1. Nachrichtenpaar handelt Verfahren aus
2. Nachrichtenpaar
öffentliche Werte für Diffie-Hellman-Verfahren
weitere Daten für Schlüsselaustausch
2. Nachrichtenpaar
Seite 18
authentisieren Diffie-Hellman-Daten
verschlüsselt
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IKE: Phase 1
Agressiver Modus (agressive mode)
ersten Paket gleichzeitig
Verfahren ausgehandelt
öffentliche Werte für Diffie-Hellman-Verfahren gesendet
Daten für Schlüsselaustausch
zur Identifizierung der Teilnehmer
Antwortnachricht umfasst
gleiche Daten
identifiziert zusätzlich Absender
dritte Nachricht
authentifiziert Initiator
belegt dessen Berechtigung
Seite 19
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IKE: Phase 2
Verwendet ISAKMP SA
handelt Security Association mittels sicherem Dienst aus
Für IPsec
Für irgendein anderer Dienstes
Informational Exchange
Daten
verschlüsselt
mit geeignetem Hash-Algorithmus vor Verfälschung geschützt
Seite 20
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Public-Key-Systeme
Nur ein Schlüssel verwenden
hoher Aufwand bei Schlüsselaustausch
Bote
Eigener Kanal (Post, Telefon, usw.)
Alternative
Mehrere Schlüssel verwenden
Public-Key-Systeme
Asymmetrische kryptografische Systeme
Mehrschlüssel-Systeme
Sicherheit in Rechnernetzen
Seite 21
Prof. Dr. W. Kowalk
Kryptografie
Grundlagen der Public Key-Systeme
1976 von Diffie und Hellman vorgestellt
Abstraktes Verschlüsselungskonzept
Öffentliche und private Schlüssel
Aus Schlüssel ks zwei Schlüssel ke und kd generiert
F: ks → ke: öffentlicher Schlüssel zum Verschlüsseln
G: ks → kd: privater Schlüssel zum Entschlüsseln
(privat = geheim)
kd nicht einfach aus ke ableitbar
Seite 22
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Grundlagen der Public Key-Systeme
Text H einfach durch Eke(H) verschlüsselbar
→ ke nicht einfach aus Klar- und Chiffretext generierbar
Ver- und Entschlüsselungsfunktionen D und E gleich
Dkd(Eke(H))=Eke(Dkd(H))=H,
Reihenfolge von Ver- und des Entschlüsselns vertauschbar
mit Potenzierungsfunktion Hx mod m realisierbar
Produkt H·H·…·H·H jeweils Modulo m
Umkehrung (Logarithmierung) dieser Funktion
Vorgabe von Hx mod m, m und x
m und x groß
ln m⋅ln ln m
≈e
nur lösbar in Zeit der Größenordnung
Bei ca. 500 Bit langen Zahlen m etwa 1020 Operationen
Seite 23
Sicherheit
in Rechnernetzen
Löst verschiedene
Probleme
Prof. Dr. W. Kowalk
Kryptografie
Schlüsselverteilung nach Diffie und Hellman
Ziel: Teilnehmern A und B Schlüssel bereitstellen
A und B wählen beliebige geheime Zahlen x und y
vereinbaren H und m öffentlich
Angreifer
kennt nur m, H und Hx bzw. Hy
Kann weder x noch y errechnen
somit auch nicht Hxy
Seite 24
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Schlüsselverteilung nach Diffie und Hellman
Ziel: Teilnehmern A und B Schlüssel bereitstellen
A und B wählen beliebige geheime Zahlen x und y
vereinbaren H und m öffentlich
A H ,m
x
H
 H y x
H ,m B
y
H
 H xy
Angreifer
kennt nur m, H und Hx bzw. Hy
Seite 25
Kann weder x noch y errechnen
in Rechnernetzen
somit auch nichtSicherheit
Hxy
Prof. Dr. W. Kowalk
Kryptografie
Authentisierung durch Passwörter
Angreifer kann sich dazwischen schalten
Auch z.B. 'geheimen Schlüssel' nach Diffie-Hellman
berechnen
→ keine sichere Identifierung
Seite 26
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Authentisierung durch Passwörter
A Ek  P A
Ek  P B B
Angreifer kann sich dazwischen schalten
Auch z.B. 'geheimen Schlüssel' nach Diffie-Hellman
berechnen
→ keine sichere Identifierung
Seite 27
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Authentisierung durch Passwörter
Passwort kann durch Angreifer vorgetäuscht werden
Z handelt Schlüssel mit A und B unabhängig aus
Ek  P A
A
E k  D k  E k  P A 
B
A
Dk  P B 
A
Seite 28
A
A
B
Z
E k  D k  E k  P B 
A
B
Dk  P A 
B
Ek  P B
B
B
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Authentisierung durch Passwörter
A und B senden abwechselnd Hälften der
verschlüsselten Passwörter Ek(PA)/ Ek(PB)
Passwort kann nicht vorgetäuscht werden
Seite 29
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Authentisierung durch Passwörter
A und B senden abwechselnd Hälften der
verschlüsselten Passwörter Ek(PA)/ Ek(PB)
A E k  P A links
E k  P A rechts
E k  P B
Seite 30
B
E k  P B links
E k  P A
E k  P B rechts
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Authentisierung durch Passwörter
Passwort kann nicht vorgetäuscht werden
Z
A E k  P A links
A
??
E k  P A rechts
A
??
Seite 31
D k  E k  P A links ?
A
??
? D k  E k  P B links 
E k  P B links
D k  E k  P A links ?
??
? D k  E k  P B links 
E k  P B rechts
B
A
B
B
A
B
B
Sicherheit in Rechnernetzen
B
B
Prof. Dr. W. Kowalk
Kryptografie
Authentisierung durch Passwörter
Passwort nach einmaligem Gebrauch 'verbrannt'!
Sende Passwort
Verschlüsselt
Gehasht
Mit Eimal-Tag
Zufallszahl
Datum, Uhrzeit
Angreifer kann Passwort nicht errechnen
Empfänger kann Passwort + Einmal-Tag neu hashen
Seite 32
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Geheimhaltung ohne Schlüssel
Seite 33
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Geheime Datenübertragung
Übertrage geheime Daten von A nach B
A
Ek
Seite 34
Bpublic
kB
H 
Dk
B
public
Bprivate
Sicherheit in Rechnernetzen
Ek
Bpublic
H 
Prof. Dr. W. Kowalk
Kryptografie
Authentisierte Datenübertragung
B will sicher sein, dass Information von A stammt
A k
A
Ek
Seite 35
public
Aprivate
H 
Dk
kA
Ek
public
Apublic
Sicherheit in Rechnernetzen
Aprivate
B
H 
Prof. Dr. W. Kowalk
Kryptografie
Geheime authentisierte Datenübertragung
A
kA
public
kB
public
kB
public
kA
public
C = E k  D k  H 
B
A
H =E k  D k C 
A
Seite 36
B
Sicherheit in Rechnernetzen
B
Prof. Dr. W. Kowalk
Kryptografie
Integre Datenübertragung
Daten nicht vorsätzlich verändert!
Verschlüsselung mit authentisiertem Schlüssel
Redundante Information
Zähler, Datum, Namen
A kA
Ek
Seite 37
public
Aprivate
H 
Dk
kA
Ek
B
public
Apublic
Sicherheit in Rechnernetzen
Aprivate
H 
Prof. Dr. W. Kowalk
Kryptografie
Integre Datenübertragung
Daten nicht vorsätzlich verändert!
Statt Daten auch Hashwert verschlüsselt
DSA
A kA
Ek
Seite 38
public
Aprivate
H 
Dk
kA
Ek
B
public
Apublic
Sicherheit in Rechnernetzen
Aprivate
H 
Prof. Dr. W. Kowalk
Kryptografie
Digital Signature Algorithm DSA
Zertifizierungsstellen
Person/Institution lässt öffentlichen Schlüssel zertifizieren
Zertifizierungsstellen Richtigkeit öffentlichen Schlüssels keA
Seite 39
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Digital Signature Standard DSS
National Institute of Standards and Technology NIST
Nummer PUB 186-2.
DSS ab 27. July 2000 gültig
von amtlichen Stellen in USA verwendet
Seite 40
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Schlüsselbildung bei Public-Key-Systemen
Public-Key-System zwei verschiedene Schlüssel
Zum Ver- und Entschlüsseln von Nachrichten
Schlüssel nicht auseinander ableitbar
immer wieder neue Algorithmen entwickelt
wichtigste und verbreitetste: RSA
RSA: Shamir, Adleman und Rivest
MIT 1978
Neueres Verfahren
Elliptische Funktion (Koblitz)
Seite 41
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Schlüsselbildung beim RSA-Verfahren
Grundlage
für sehr große Zahlen (mehrere hundert Dezimalstellen)
Aufwand für Zerlegung in Primfaktoren extrem hoch Exponentiation einer Nachricht H mit
Schlüssel e
reziprokem Wert d=e-1
Ee(H) = He mod m
Dd(He) = (He)d = He·d = H1 = H mod m
Aus m und e kann d berechnet
wenn m Primzahl einfach
Wenn m=p·q keine Primzahl schwierig
Seite 42
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Schlüsselbildung beim RSA-Verfahren
Lösung: zunächst Primfaktoren von m bestimmen
Zerlegung in Primfaktoren 'schwieriges' Problem
zeitaufwendig
für großes p und q praktisch nicht durchführbar
Auswahl/Berechnung des Schlüssels
Wählen zweier großer (>100 Stellen) Primzahlen p und q
Berechnung von m = p*q und r = KGV [p-1, q-1]
Zahl e, zu (p-1) und (q-1) relativ prim
Zahl d=e-1, so dass d·e=1 mod r
Seite 43
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Schlüsselbildung beim RSA-Verfahren
Verschlüsselungsverfahren
zu übertragende Information in Blöcke zerlegen
als Binärzahlen aufgefasst kleiner als m
erhebt Binärzahlen in e-te Potenz, Arithmetik modulo m Entschlüsselung analog
Blöcke zur d-ten Potenz erheben
Seite 44
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Schlüsselbildung beim RSA-Verfahren
Periode k
Hk+1=H für kleinstes k.
aus k und e reziproker Wert d=e-1 einfach bestimmbar
Ist m Primzahl, so ist Periode gleich m
m keine Primzahl,
Berechnung der Periode nur möglich, wenn Primfaktoren von m
bekannt
Seite 45
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Schlüsselbildung beim RSA-Verfahren
Primfaktorenzerlegung nur schwierig lösbar
bekanntes zahlentheoretisches Problem
bis heute noch nicht einfach gelöst
Sicherheit dieses Verfahrens basiert auf ungelöstem
mathematischen Problem!
RSA-Verfahren wurde patentiert
Patente mittlerweile ausgelaufen
Verfahren frei verfügbar ist
Seite 46
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Zero-Knowledge-Protokolle (Fiat-Shamir)
Alf
kenne Geheimnis s
will dies Bert beweisen, ohne Bert s zu nennen
Alf bereitet sein Geheimnis s folgendermaßen auf
wähle Modul m=p*q, p, q prim
veröffentliche m und v=s2 mod m
Alf geht folgendermaßen vor
Alf wählt eine zufällige Zahl r
Alf sendet deren Quadrat x=r2 mod m an Bert.
Bert
wählt zufällig ein der Zahlen von Alf
Seite 47
r oder
y=s/r mod m
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Zero-Knowledge-Protokolle
Alf geht folgendermaßen vor
Alf wählt eine zufällige Zahl r
Alf sendet deren Quadrat x=r2 mod m an Bert.
Bert
wählt zufällig eine der Zahlen von Alf
r oder
y=s/r mod m
Fordere Bert r
Bert kann prüfen, ob r Quadratwurzel von x=r2 mod m
Fordere Bert y
Bert prüft, ob y2*x=s2/r2*r2=v Quadrat des Geheimnisses
Vorgang wird solange wiederholt, bis Bert mit
ausreichender Wahrscheinlichkeit sicher ist, dass Alf
Geheimnis sSicherheit
kennt.
Seitedas
48
in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Zero-Knowledge-Protokolle
Sicherheit
zu v und einem beliebigen y einfach x=v/y2 berechnen, aber
aus x=r2 kann Alf nicht einfach r bestimmen;
zu beliebigem r einfach x=r2 bestimmen,
aber aus diesem x nicht einfach y bestimmen
Bert überprüft also, ob Alf wirklich
Quadratwurzel aus x kennt, und
ob y2*x=v ist.
Alf darf nicht gleichzeitig y und r senden
y=s/r kann einfach s berechnet werden
Daher folgt
Nur eine der beiden Zahlen r oder y kann gefälscht werden
Seite 49
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Zero-Knowledge-Protokolle
Bert kann sich durch zufällige Auswahl von
Richtigkeit einer dieser beiden Zahlen überzeugen
bei jedem Durchgang nur zu 50% überzeugt
Überprüfung jedoch mehrfach wiederholt
nach n Schritten kann Alf nur betrügen mit
Wahrscheinlichkeit 0,5n
nach 10 Schritten 0,1%,
nach 20 Schritten 0,0001% usw
Bert kann selbst bestimmen, mit welcher Sicherheit
er Alfs Legitimität nachweisen will
Seite 50
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Challenge-Handshake Authentication Protocol
(CHAP, RFC 1994, auch Challenge-Response)
Ziel: Person A identifizieren
A muss bestimmte Handlung vollführen
B kann Ergebnis nachprüfen
dritter kann aus Ergebnis Handlung selbst nicht erkennen
Handlung meist gemeinsam vereinbarte Berechnung
Challenge-Handshake Authentication Protocol
Seite 51
CHAP
RFC 1994
B (authenticator) will Identität von A nachweisen
In mehreren Phasen
abgewickelt
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Challenge-Response-Verfahren CHAP
Challenge-Handshake Authentication Protocol
1. B sendet Datensatz (challenge) an A.
2. A berechnet mittels "Ein-Weg-Hashfunktion" einen Wert
sendet diesen an B zurück
3. B überprüft Antwort anhand eigener Berechnung
Stimmen Ergebnisse überein,
Authensierung abgeschlossen
Stimmen die Ergebnisse nicht überein,
Authensierung schlug fehl
4. B sendet in zufälligen Abständen neue Anfragen an A,
A muss diese bestätigen
Seite 52
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Challenge-Response-Verfahren CHAP
Schutz gegen Playback-Angriffen durch A
wenn Datensatz (challenge) ständig verändert wird
B kann sich nach Belieben von Identität von A
überzeugen
Authentisierung hängt ab
von gemeinsamem Geheimnis
darf nur A und B bekannt sein
Authentisierung in beiden Richtungen
von B nach A und
von A nach B
Seite 53
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Challenge-Response-Verfahren CHAP
Nachteil
"Geheimnis" muss im Klartext vorliegen
keine Ein-Weg-verschlüsselte Passwortdatenbanken
Geheimnis muss bei A und B verwahrt werden
bei sehr großen Installation schwierig
Standard schlägt vor
Geheimnis an zentralem Server verwalten und überprüfen
→ Schlüsselzentrum oder Zertifizierungsstelle
möglicher Hash-Algorithmus: MD5 (obligatorisch)
auch andere Verfahren aushandelbar
Seite 54
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Challenge-Response Authentication
Mechanism (CRAM)
Erweiterungen von CHAP
Keyed-Hashing for Message Authentication
HMAC: (RFC 2104)
Abfrageprotokoll für E-Mail-Server
IMAP = Internet Message Access Protocol
- Version 4rev1, RFC 2060
Seite 55
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Hashen
Text auf Verfälschungen überprüft
üblicherweise Prüfsumme gebildet
statt Text die Prüfsumme überprüfen / signieren
Verfahren: Hashen
Prüfsumme:
Fingerabdruck (finger print)
auch Digest oder Message Digest
Anforderungen an Prüfsummen
rechentechnisch schwierig zu Fingerabdruck
entsprechende Nachricht finden
rechentechnisch schwierig, zwei verschiedene Texte
mit gleichem Fingerabdruck finden
Seite 56
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Hashen
Heute zwei Verfahren
MD5
Ronald L. Rivest
SHA-1
National Institute of Standards and Technology (NIST)
Beide Verfahren sehr ähnlich
basieren auf MD4-Verfahren von Ronald L. Rivest
Einfacher, weniger sicher
MD5 unsicher wegen kurzem Digests (128 Bits)
Geburtsangriff
HMAC
Digest aus gemeinsamem Schlüssel
Seite 57
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
SHA-1
verarbeitet Blöcke fester Länge
512 Bits oder
64 Bytes
Nachrichten aufgefüllt:
+1,0..0,+Nachrichtenlänge!
Puffer: ABCDE, H0H1H2H3H4
Seite 58
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
February 15, 2005 (Bruce Schneier)
SHA-1 has been broken
Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu
collisions in the the full SHA-1 in 269 hash operations,
brute-force attack of 280 hash operations
collisions in SHA-0 in 239 operations
collisions in 58-round SHA-1 in 233 operations.
build on previous attacks on SHA-0 and SHA-1,
no affect applications such as HMAC
where collisions aren't important
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
Seite 59
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
MD5-1
verarbeitet Blöcke fester Länge
512 Bits oder
64 Bytes,
MD5 scheint gebrochen zu sein
http://eprint.iacr.org/2004/199.pdf
http://passcracking.com/ (interaktiv)
Seite 60
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
HMAC: Verschlüsseltes Hashing
Verfahren zur Authentisierung ohne Public Key
RFC 2104
Hashwert von Schlüssel abhängig
Parteien kennen geheimen Schlüssel
Beweis der Unverfälschtheit einer Nachricht
bei Übertragung
bei Speicherung
nicht vorsätzlich von aktivem Angreifer verfälscht
Seite 61
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
HMAC: Verschlüsseltes Hashing
HMAC
fügt in Dokument geheimen Schlüssel ein
hashed das so entstandene neue Dokument
kann von Angreifer nicht nachvollzogen werden
könnte höchstens Hashwert fälschen
Seite 62
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
HMAC: Verschlüsseltes Hashing
RFC 2104 nennt folgende Entwurfsziele
1. Vorhandene Hash-Funktionen unverändert einsetzen
in Hardware oder Software
Code frei verfügbar
Schnelligkeit der Hash-Funktionen ausnutzbar
2. Schlüssel auf einfache Weise behandeln
3. gut verstandene kryptographische Analyse
vernünftige Annahmen der Hash-Funktionen
4. Hashfunktion einfach ersetzbar
schnellere oder sicherere Hashfunktionen
Seite 63
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
HMAC: Verschlüsseltes Hashing
HMAC
H: Hashalgorithmus,
B: Eingabeblocklänge des Hashalgorithmus H
z.B. 64 Bytes bei MD5 und SHA-1
L: Länge des Haswerts (Fingerabdrucks) des
Hashalgorithmus H
z.B. L=16 Bytes bei MD5 und L=20 Bytes bei SHA-1
S: Schlüssel der Länge k<B,
K=S+(0016)B-k, oder falls k>B: K=H(S)+(0016)B-L,
IPAD = (0011 01102)B = (3616)B, innerer Pad,
OPAD = (0101 11002)B = (5C16)B, äußerer Pad
Hashwert (digest)
Digest = H(K  OPAD + H(K  IPAD + text))
Seite 64
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
HMAC: Verschlüsseltes Hashing
HMAC gilt als sicher, falls
1. HMAC wird korrekt implementiert.
2. Die Schlüssel werden rein zufällig bzw. mit einem
kryptographischen Zufallszahlengenerator erzeugt.
3. Der Schlüsselaustauschmechanismus ist sicher.
4. Die Schlüssel werden häufig ausgewechselt.
5. Die Schlüssel werden sicher aufbewahrt
Seite 65
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Geburtstagsangriff
Geburtstagsparadoxon
In sehr kleiner Gruppe haben wenigstens zwei
Personen mit 50%iger Wahrscheinlichkeit am gleichen
Tag Geburtstag.
gefälschtes Dokument signieren
zwei Dokumente D und F erzeugen
Originaler und veränderter Text
Beide Dokumente durch unwesentliche Änderungen variiert
Leerzeichen, Backspaces, Tabs usw.
Hashwerte vergleichen bis zwei Dokumente mit gleichen
Fingerabdrücken gefunden
ein Dokument vorlegen
Hashwert signieren lassen
das andere vorlegen und auf Erfüllung pochen
Seite 66
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Geburtstagsangriff
Gegenmaßnahmen gegen Fälschung
Rechtsstreit Gegenteil behaupten, Original vorlegen
Dokumente gemeinsam redigieren
Dokumente von allen redundaten Teilen befreien
Möglichst nur ASCII-Text signieren
Alle Tabs, Leerzeichen, Backspaces, Linefeeds usw. soweit
überflüssig entfernen
Zeichensatz auf druckbare Zeichen + wenige Kontrollzeichen
beschränken
Seite 67
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Geburtstagsangriff
Geburtstagsparadoxon
alle Personen mit gleicher Wahrscheinlichkeit an 365 d
Geburtstage unabhängig (keine Zwillinge usw.)
P[nicht an einem von k Tagen Geburtstag] =(365-k)/365
{1 Person}: p1=1 keine zwei Personen mit gleichem Geburtstag
{2 Personen}: p2= p1∙(364/365)=364/365
{3 Personen}: p3= p2∙(363/365)=364/365
{N Personen}:
pN= pN-1∙(365/365)∙(364/365)∙(363/365)∙...∙(366-N/365)
p22= 0,52430469, p23= 0,49270277, 1-p23= 0,50729723.
bei Gruppe von 23 Personen Wahrscheinlichkeit, dass
mindestens zwei Personen am gleichen Tag Geburtstag
haben, über 50 %.
Seite 68
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Geburtstagsangriff
Geburtstagsparadoxon
Mit den obigen Bedingungen ergibt sich die
Wahrscheinlichkeit, dass keine von N Personen an einem
bestimmten Tag Geburtstag hat, offenbar zu qN=(364/365)N.
Für N=252 gilt:
1-q252=1-(364/365)252=0,4991,
1-q253=1-(364/365)253=0,5005
Es müssen mindestens 253 Personen anwesend sein, damit mit 50
% Wahrscheinlichkeit mindestens einer an einem bestimmten Tag
Geburtstag hat.
Seite 69
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Sicherheitsarchitektur für das Internet
IPsec
RFC 2401
Sicherheitsanforderungen für IPv4 und IPv6
Sicherheitsdienste
Seite 70
Zugangskontrolle (access control)
Datenintegrität (connectionless integrity)
Authentisierung (data origin authentication)
Schutz vor Wiederholung (protection against replays)
Vertraulichkeit durch Verschlüsselung
(confidentiality by encryption)
Verkehrflußvertraulichkeit
(limited traffic flow confidentiality)
IP-KompressionSicherheit
(IP compression)
in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Sicherheitsarchitektur für das Internet
Erweiterungsheader
Authentisierungsheader (Authentication Header)
Datenintegrität
Authentisierung
Schutz vor Wiederholung
Encapsulating Security Payload-Header (ESP)
Datenintegrität
Authentisierung
Schutz vor Wiederholung
Vertraulichkeit durch Verschlüsselung
Verkehrflussvertraulichkeit
Seite 71
Header zum Austausch kryptographischer Schlüssel
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Sicherheitsarchitektur für das Internet
Erweiterungsheader
Seite 72
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Sicherheitsarchitektur für das Internet
Sicherheitsanforderungen durch Kombination erreicht
Transportmodus
Dienst für Protokolle der höheren Schichten
Tunnelmodus
Dienst für getunnelte IP-Datagramme
Alternativen
zwischen zwei Knoten jede einzelne Verbindung verschlüsselt
alle Verbindungen laufen über gemeinsamen Tunnel
welche Dienste werden benutzt und in welcher
Kombination werden sie eingesetzt;
auf welche Verbindungen bzw. Gruppen von Verbindungen
(Granularität) werden Sicherheitsdienste eingesetzt;
welche Algorithmen werden verwendet.
Seite 73
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Sicherheitsarchitektur für das Internet
kryptographische Schlüssel verteilen
manuelle und automatische Verteilungsverfahren
IPsec spezifiziert eigenes Public-Key-Verfahren
IPsec unterstützt auch andere Verfahren zur
Schlüsselverteilung wie Kerberos.
IPsec kann implementiert werden in
Endgeräten
Transitgeräten wie Routern oder Firewalls
Seite 74
IPsec kann an verschiedenen Stellen im
Protokollstapel integriert werden
1. in die IP-Implementierung von IPSec
2. im Protokollstapel unterhalb Vermittlungsschicht (IP)
Bump-in-the-stack (BITS)
3. Integration von IPSec in Übertragungsleitung (Link),
Bump-in-the-wire
(BITW)
Sicherheit
in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
beschreibt um Umfang und Eigenschaften gesicherter
Datenübertragung
Sicherheitsverbindung
Simplexverbindung für Dienst
Authentisierung (durch AH)
Verschlüsselung (durch ESP)
Parameter
Sicherheitsparameterindex (Security Parameter Index, SPI),
IP-Zieladresse (IP Destination Address),
Sicherheitsdienstkennzeichnung (Security protocol identifier)
mehrere Sicherheitsdienste oder Duplexverbindungen
mehrere Sicherheitsverbindungen aufbauen
Seite 75
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
Zieladresse
Unicast- oder Multicastadressen zulässig
RFC 2401 konzentriert sich auf Unicastadressen
Transportmodus
verbindet zwei Hosts
auch Transitsystem kann endgültiger Empfänger von
Datagrammen (z.B. ICMP-Nachrichten) sein
Sicherheitsheader direkt zwischen IPv4-Header (mit Optionen) und
Header der Anwendungsschicht
Tunnelmodus
Seite 76
verbindet Transitsysteme und Endsysteme
äußerer IP-Header (adressiert Ende des Tunnels)
innerer IP-Header (adressiert eigentliche Zieladresse)
dazwischen Sicherheitsheader eingefügt
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
Kombination von Sicherheitsverbindungen
Verschachtelung der jeweiligen Sicherheitsdienste
SA-Bündel (SA bundle)
zwei prinzipielle Konzepte:
Transport Adjacency
iterierte getunnelte Verbindung (iterated tunneling)
Seite 77
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
Transport Adjacency
Verwendungen von zwei Sicherheitsverbindungen in einem
Datagramm
nur eine AH- und eine ESP-Sicherheitsverbindungen sinnvoll
Datagramm läuft beim gleichen Empfänger auf - es gibt nur eine
IP-Zieladresse - sind Anfangs- und Endpunkte gleich. Als
Reihenfolge wird IP-AH-ESP empfohlen
Authentisierung auf Teilen des IP-Headers sowie auf ESP
Seite 78
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
Iterierte getunnelte Verbindung (iterated tunneling)
mehrere Datagramme
enthalten gegebenenfalls ganze Datagramme
mehrere Zieladressen mögliche
Reihenfolge der SAs beliebig
abhängig von jeweiligen Sicherheitsanforderungen
mehrere Kombinationen denkbar
1. Beide Endpunkte aller Sicherheitsverbindungen gleich
Seite 79
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
Iterierte getunnelte Verbindung (iterated tunneling)
mehrere Kombinationen denkbar
2. Ein Endpunkt aller Sicherheitsverbindungen gleich
die anderen verschieden
3. Alle Endpunkt der Sicherheitsverbindungen verschieden
Seite 80
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
verschiedene Kombinationen von
Sicherheitsverbindungen
abhängig von Endpunkten
Beispiel:
zwischen Routern verschlüsselte Tunnelverbindungen
zu verschiedenen Endsystemen in jeweiligen lokalen Netzen
ungeschützte oder auch authentisierte Verbindungen
durch Verwendung verschachtelter Sicherheitsverbindungen jeder
Grad an Sicherheit erreichbar
Verschlüsselungsstärke verbesserbar durch verschachtelte ESPHeader (Produktchiffren)
zusätzliche Sicherheit fraglich (Meet-in-the-Middle Angriff)
Seite 81
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
vier Basiskonfigurationen von SAs definiert
müssen unterstützt werden
weitere optional
1. Sicherung der Ende-zu-Ende-Verbindung zweier Hosts
im Transport- oder Tunnelmodus
Seite 82
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
2. Sicherung der Gateway-Gateway-Verbindung im
Tunnelmodus
Seite 83
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
3.
Sicherung der Ende-zu-Ende-Verbindung zweier Hosts im
Transport- oder Tunnelmodus
gleichzeitige Sicherung der Gateway-Gateway-Verbindung im
Tunnelmodus
Seite 84
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
4. Zugang zu einem lokalen Netz über externe
Verbindung wie Internet oder Einwahlverbindung
Seite 85
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
SA und Schlüssel-Management
manuelle oder automatisierte Schlüsselverteilung und SAManagement,
manuelles Vorgehen mit einigen Nachteilen verbunden
kein Antireplaydienst
Zähler nicht zu synchronisieren
nur in kleinen, lokal beschränkten Netzen einzusetzen
manuell Kommunikation zwischen zwei oder wenigen Security
Gateways mit Tunneling aufzubaut
aus Sicherheits- und Effizienzgründen automatisches
Management sinnvoller
Seite 86
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Associations (SA)
SA und Schlüssel-Management
Seite 87
Automatisches SA- und Schlüsselmanagement benötigtfür
Antireplaydienst
Anwender kreieren und benutzen spontan neue SAs
IPsec führt Standard zum Schlüsselmanagement
IPsec erlaubt Verwendung weiterer Standards
erzeugen gemeinsame Schlüssel
aus einem einzelnen Bitstring ("Masterkey") abzuleiten
IPsec Standards zum Schlüsselmanagement sind
IKE: The Internet Key Exchange, RFC 2409.
ISAKMP: Internet Security Association an Key
Management Protocol, RFC 2408.
The Oakley Key Determination Protocol, RFC 2412.
The Internet IP Security Domain of Interpretation for
ISAKMP,
RFC 2407.
Sicherheit
in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Verarbeitung von IP-Datagrammen unter IPsec
Senden eines Datagramms
Entsprechenden Eintrag in SPD (Security Policy Database)suchen
kein passender Eintrag vorhanden: verwerfe Datagramm
Datagramm nicht durch IPsec zu schützen:
unverändert weiter reichen
im Tunnel-Modus wird innerer Header nur im Time to Live-Feld
(und Prüfsumme) verändert
äußerer und innerer Header können verschiedene Version haben
(IPv4 und IPv6)
...
Seite 88
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Verarbeitung von IP-Datagrammen unter IPsec
Senden eines Datagramms
...
ggf. muss Paket fragmentiert werden
überschreitet zusammen mit Erweiterungsheadern
vorgegebene Größe
danach entsprechend gewählter SA
Verschlüsselung und Authentisierung durchführen
entsprechende Header anlegen
mit berechneten Werten versehen
Paket an nächsten Router senden
Seite 89
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Verarbeitung von IP-Datagrammen unter IPsec
Empfangen eines Datagramms
eingehender Verkehr wird zunächst reassembliert
entsprechend Parametern in SA-Database einer SA zugeordnet
Paket wird authentisiert und entschlüsselt
anhand SPD wird Sicherheitsstrategie für Paket überprüft
u.U. mehrere Sicherheitsstrategien, passende finden
Paket an Anwendungsschicht oder anderen Router oder Host
weiter reichen
ggf. Information in bearbeiteten Headern entsprechend behandeln
Absender
Prüfungsreihenfolge
Seite 90
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Verarbeitung von IP-Datagrammen unter IPsec
ICMP-Nachrichten
im wesentlichen wie normale IPsec-Datagramme behandelt
in der Regel der Tunnel-Modus
Absender- und Empfängeradresse unverändert belassen
auch unauthentifizierte oder unverschlüsselte ICMP-Nachrichten
müssen verarbeitet werden können
ICMP-Nachrichten zur Bestimmung der maximalen Paketlänge auf
einem Pfad (PMTU, path maximum transport unit) müssen
gesondert behandelt werden
wichtige Information über maximale Paketgrößen
Information in der ICMP-Nachricht zur Bestimmung des
sendenden Routers
u.U. zu viele IPsec-Daten
Router auffordern, genauere Informationen zu senden. .
Seite 91
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Verarbeitung von IP-Datagrammen unter IPsec
bei Berechnung der PMTU muss Zusatzinformation durch IPsecHeader berücksichtigt werden
Fragmentierung nach Authentifizierung / Verschlüsselung
sonst zu kleine Datagramme
Multi-Level Security (MLS)
Sicherheitsanforderungen abhängig von Wichtigkeit e. Nachricht
ggf. Grad der geforderten Sicherheit als zusätzlicher Parameter
zusätzliche Bearbeitung der Datagramme
Seite 92
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Verarbeitung von IP-Datagrammen unter IPsec
IPsec fordert aufwendige Behandlung von Datagrammen
zusätzliche Bearbeitungszeit
zusätzlicher Speicher für Algorithmen und Sicherheitsdatenbanken
i.d.R. gegen absichtliche Verfälschung zu schützen
Bearbeitungszeitaufwand für Host soll nicht inakzeptabel hoch sein
Router bzw. Security Gateways können und sollten i.d.R. mit
spezieller Hardware ausgestattet werden.
Bandbreitenbelastung nimmt zu
zusätzliche Verzögerungen beim Aufbau einer SA
TCP sendet mehr als nötig SYN-Pakete
TCP bricht u.U. Verbindungsaufbau ab
UDP dürfte hier jedoch weniger Probleme bereiten.
Seite 93
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Verarbeitung von IP-Datagrammen unter IPsec
IPsec fordert aufwendige Behandlung von Datagrammen
langsame Datenverbindung
Telefonleitung
ohne Kompression sehr lange Verbindungszeiten
Kompression bereits vor Anwendungsschicht durchführen
verschlüsselte Daten kaum oder gar nicht komprimierbar
keine wiederholenden Strukturen
Seite 94
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
AH-Dienste
Authentifizierung für Daten und IP-Header
Integrität bei verbindungsloser Kommunikation
Schutz vor Replay von Daten
kann in IPv4 und IPv6 verwendet werden
unterstützt Transport- und Tunnelmodus
AH-Header eingefügt
hinter IP-Header und vor Header der oberen Transportschicht
im Tunnelmodus vor innerem IP-Header
Seite 95
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Seite 96
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Paketformat des IP Authentication Header
Wert 51 im Nextheader-Feld des vorhergehenden Pakets
Next Header
Typ der Payload-Daten
Transportprotokoll
Erweiterungsheader in Ipv6
Seite 97
kommt Sicherheit
in jedeminAH-Header
Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Paketformat des IP Authentication Header
Seite 98
Payload-Length
Länge des AH in 32 Bit-Worten minus 2
RESERVED
Hat den Wert null
Security Parameters Index (SPI)
32 Bit-Wert
identifiziert in Kombination mit Zieladresse und Protokoll AH
eindeutig SA für dieses Datagramm
gewisse Werte (1..255) dürfen i.d.R. nicht vergeben werden,
bzw. werden nur lokal (0) verwendet
Wert des SPI von Zielrechner beim Aufbau der SA festgelegt
Dieser Wert kommt in jedem AH-Paket vor
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Paketformat des IP Authentication Header
Sequenznummer
Ein 32 Bit-Wert
Antireplay-Wert
Sender muss Wert einfügen
beginnend bei 1 inkrementieren
Empfänger kann Wert auswerten, braucht es aber nicht
Wert darf nicht über Höchstwert 232-1 inkrementiert werden
wenn vom Empfänger ausgewertet
Dieser Wert kommt in jedem AH-Paket vor
Authentication Data
Authentisierung des gesamten Pakets
Länge abhängig vom Authentifizierungsalgorithmus
Dieser Wert ist optional
Seite 99
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Anordnung des IP-AH
Transportmodus
AH nach IP-Header und vor Daten der oberen Schichten
TCP
ICMP, usw.
Einkapselung eines TCP-Pakets in IPv4-Feld
Seite 100
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Anordnung des IP-AH
Transportmodus
Einkapselung eines TCP-Pakets in IPv6-Feld
Seite 101
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Anordnung des IP-AH
Tunnelmodus
innerer Header enthält Zieladressen
äußere IP-Header kann andere Adresse enthalten
Security-Gateway
Anordnung in typischem IPv4- und IPv6-Datagramm
Seite 102
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Funktionen beim Senden eines AH-Pakets
Seite 103
Punkt-zu-Punkt-Kommunikation
Eintrag in Security Policy Database weist AH-Paket aus
schlüsselbasierter Message Authentication Codes
DES
Hashfunktionen wie MD5 oder SHA-1
müssen implementiert sein
zunächst Paket mit eingefügtem AH konstruieren
Sequenznummer jeweils nächster Wert
Veränderbare Felder erhalten bei Authentisierung Wert null
Ipv4
Time to Live, Header Checksum, bestimmte Optionen
IPv6
Class, Flow Label oder Hop Limit
einige Felder
beiinSender
und Empfänger
vorhersehbar
Sicherheit
Rechnernetzen
Prof.
Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Funktionen beim Senden eines AH-Pakets
ggf. Authentisierungsdaten auf geeignete Länge bringen
Vielfaches von 32 Bits in IPv4
wird durch entsprechendes Paddingfeld gemacht
Wert beliebig
über gesamtes vorbereitete Paket wird
Integrity Check Value mit Authentifizierungsverfahren
in Feld Authentisierungsdaten eingefügt
ggf. können diese Pakete fragmentiert werden
beim Empfänger vor Prüfung wieder reassemblieren
Seite 104
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Funktionen beim Empfangen eines AH-Pakets
Eintrags in der Security Policy Database weist AH-Paket aus
Sequenznummernfeld überprüft, wenn SA das vorschreibt
eingehende Pakete können in beliebiger Reihenfolge eintreffen
Fensterverfahren vorgeschlagen
32 bis 64 Sequenznummer verifizieren
auf Duplikate überprüfen
dupliziertes Paket wird in Logdatei protokolliert
Seite 105
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Funktionen beim Empfangen eines AH-Pakets
Authentisierung
in AH-Paket die Authentisierungsdaten speichern
Feld Authentication Data auf null setzen
veränderbare Felder auf null bzw. vorhersehbaren Wert setzen
vereinbarten Algorithmus anwenden
Ergebnis mit Authentisierungsdaten vergleichen
Fehler in Logdatei protokollieren
SPI,
Empfangszeit,
Quell- und Zieladresse
Sequenznummer
Seite 106
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
IP Authentication Header (AH)
Funktionen beim Empfangen eines AH-Pakets
Auditable Events
zu protokollierende Fehler
in der Regel in Logdatei protokolliert
nicht jedes System muss Fehler protokollieren
wenn es protokoliert müssen die Mechanismen zum
Protokollieren von AH-Fehlern vorgesehen werden
Administrator muss dieses ein- bzw. ausschalten können
Empfänger ist nicht verpflichtet, Fehler an Absender zu
melden
verhindert Gefahr von Denial-of-Service-Angriffen
Seite 107
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
verschiedene Sicherheitsdienste
1. Vertraulichkeit
2. Datenquellenauthentisierung
3. Integrität bei verbindungsloser Kommunikation
4. Antireplay-Dienst
5. beschränkte Verkehrsflussvertraulichkeit
Diese Dienste hängen teilweise voneinander ab
mindestens einer der Dienste Vertraulichkeit oder Authentisierung
muss verwendet werden
in IPv4 und IPv6 verwendbar
unterstützt Transportmodus und Tunnelmodus
im Prinzip universell einsetzbar
ESP-Header eingefügt
Seite 108
hinter IP-Header und vor Header der oberen Transportschicht
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Paketformat
Wert 50 im Nextheader-Feld des vorhergehenden Pakets
Seite 109
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Paketformat
Security Parameters Index (SPI)
32 Bit-Wert
in Kombination mit Zieladresse und Protokoll ESP eindeutig
SA identifiziert
gewisse Werte (1..255) werden i.d.R. nicht vergeben,
nur lokal (0)
Wert des SPI von
Zielrechner bei
Aufbau der SA
festgelegt
Wert in jedem
ESP-Paket
Seite 110
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Paketformat
Sequenznummer
32 Bit-, Antireplay-Wert
Sender muss diesen Wert einfügen, beginnt bei 1
inkrementiert
Empfänger kann diesen Wert auswerten, braucht es aber
nicht.
Wert niemals über
Höchstwert 232-1
inkrementieren
Wert in jedem
ESP-Paket
Seite 111
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Paketformat
Payload-Data
Daten, Typ im Nextheader-Feld beschrieben
Initialisierungsvektor (Synchronisationsdaten) explizit
DES-CBC
Verschlüsselungsverfahren beschreibt eindeutig, wie
Synchronisationsdaten aus Payload-Datenfeld oder ESPHeader gewonnen werden können
Wert in jedem
ESP-Paket
Seite 112
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Paketformat
Padding
keine Bedeutung für übertragenen Payload-Daten
füllen Paket auf gewünschte Länge auf
bei Blockchiffren und ähnlichen Verschlüsselungsverfahren
können wahre Länge eines Datenfeldes verschleiern
Wert optional
kann null sein
Paddingfelder
initialisiert
explizit definiert
implizit definiert
1,2,3...
Seite 113
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Paketformat
Pad-Length
Anzahl der Padding-Oktette
0-255
kommt in jedem ESP-Paket vor
Seite 114
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Paketformat
Next Header
Typ der Payload-Daten
Transportprotokoll
Erweiterungsheader in Ipv6
Wert in jedem
ESP-Header
Seite 115
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Paketformat
Authentication Data
Authentisierung des ESP-Feldes
außer Authentisierungsdaten
Länge abhängig von Authentisierungsalgorithmus
Dieser Wert ist optional
Seite 116
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Anordnung des ESP-Headers
Transportmodus
ESP-Header nach IP-Header und vor entsprechenden Daten
TCP
ICMP, usw.
vollständiges IP-Paket verschlüsseln
ESP-Header vor innerem IP-Header angeordnet
Einkapselung eines TCP-Pakets
Seite 117
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Anordnung des ESP-Headers
Transportmodus
IPv6 kann Destination-Options-Header an verschiedenen
Stellen stehen
diesen ebenfalls mitverschlüsseln
hinter ESP-Header stellen
mehrere Destination-Options-Header möglich
Destination-Options-Header an verschiedenen Stellen
Seite 118
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Anordnung des ESP-Headers
Tunnelmodus
innerer Header enthält Zieladresse
äußere IP-Header kann andere Adresse enthalten
z.B. Security-Gateway
Anordnung des ESP-Headers im Tunnelmodus
Seite 119
gesamter innerer IP-Header (auch) Zieladresse verschlüsselt
Verkehrsflussvertraulichkeit
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Funktionen beim Senden eines ESP-Pakets
Seite 120
NULL-Algorithmus, keine Verschlüsselung
mindestens DES-CBC zur Verschlüsselung
Initialisierungsvektor im Payloadfeld abgelegt
weitere Verschlüsselungsverfahren möglich
zukünftige Erweiterungen einfach
sämtliche Parameter für Entschlüsselung in einem Block
expliziter Wert im Payloadfeld oder
aus ESP-Header ableitbar
Authentifizieren: Punkt-zu-Punkt-Kommunikation
schlüsselbasierten Message Authentication Codes wie DES
oder mit Hashfunktionen wie MD5 oder SHA-1
müssen implementiert sein
Null-Authentisierung
mindestensSicherheit
verschlüsseln
oder authentisieren
in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Funktionen beim Senden eines ESP-Pakets
Seite 121
ausgehendes Paket als ESP-Paket erkannt
aufgrund Eintrag in Security Policy Database
zunächst entsprechendes Paket im Klartext konstruiert
im Transportmodus aus höherem Protokoll
im Tunnelmodus aus dem gesamten IP-Datagramm
einschließlich IP-Header
Padding-Bytes, Pad-Länge und Next-Header-Feld anhängen
verlangt SA Verschlüsselung
Paket mit gewähltem Algorithmus verschlüsselt
explizite oder implizite Verschlüsselungsparameter
Initialisierungsvektor beim DES-CBC
in Payloadfeld an festgelegter Stelle eingefügt
oder aus ESP-Header nach festgelegtem Verfahren
berechnet
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Funktionen beim Senden eines ESP-Pakets
Grundsätzlich wird Sequenzzähler inkrementiert
in das entsprechende Feld übernommen
Überlauf des Zählers führt zu Alarm und Löschung der SA
verlangt SA Authentisierung
Sender berechnet Integrity Check Value (ICV) aus Paket
ohne Authentisierungsdaten
fügt ICV in Feld für Authentisierungsdaten ein
bei IPv6 vom Sender fragmentierbar
vor einer Entschlüsselung wieder reassemblieren
Seite 122
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Funktionen beim Empfangen eines ESP-Pakets
eingehendes Paket als ESP-Paket erkannt
aufgrund eines Eintrags in der Security Policy Database
zunächst Sequenznummernfeld überprüft
wenn SA das vorschreibt
eingehende Pakete können in beliebiger Reihenfolge eintreffen
Fensterverfahren vorgeschlagen
32 bis 64 Sequenznummern verifizieren
auf Duplikate überprüfen
dupliziertes Paket erkannt, in Logdatei protokolliert
Seite 123
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Funktionen beim Empfangen eines ESP-Pakets
Authentisierung
ESP-Paket ohne Authentisierungsdaten mit vereinbartem
Algorithmus prüft
gegen Authentisierungsdaten abgleichen
Fehler in Logdatei protokolliert
Angabe von SPI
Empfangszeit
Quell- und Zieladresse
Sequenznummer
Seite 124
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Encapsulating Security Payload (ESP)
Funktionen beim Empfangen eines ESP-Pakets
Seite 125
Dechiffrierung
ESP-Paket ohne Authentisierungsdaten mit vereinbartem
Algorithmus entschlüsseln
aus Klartext Paddingdaten extrahieren
überprüfen (1,2,.. bei impliziten Daten)
ursprüngliches Paket einschließlich IP-Header restaurieren
auch im Tunnelmodus
weiter an IP leiteten
Datenteil Transportprotokoll übergeben
im Tunnelmodus als neues IP-Paket weiterleiten
Auditable Events
zu protokollierende Fehler
in der Regel in Logdatei protokolliert
Protokollieren
optional
Sicherheit
in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Databases
Security Policy Database (SPD)
Administrator legt Sicherheitspolitiken fest
Security Association Database (SAD)
für jede aktive Assoziation verwendeten Parameter abgelegt
unterscheiden i.d.R zwischen ein- und ausgehenden
Verbindungen
verschiedenen SAs zugeordnet
Gateway besitzt i.d.R. mindestens eine SA zu entferntem Gateway
intern existiert keine SA
kein Eintrag in SPD vorhanden
kein Eintrag in der SAD erzeugt
Selector
Abbildung zwischen Datenverkehr und SAs
Seite 126
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Databases
Die Security Policy Database (SPD)
eigene Informationen
je Schnittstelle
je Kommunikationsrichtung (ein- und ausgehend)
drei Klassen von Nachrichten unterschieden
1. discard
2. bypass IPsec
3. apply IPsec.
Security Policy Database legt fest (durch Administrator)
welche Pakete zu welcher dieser Klassen gehören
welche Pakete wie bearbeitet werden
In Hostsystemen auch durch Benutzer veränderbar.
Seite 127
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Databases
Die Security Policy Database (SPD)
Seite 128
Selektoren
ordnen Paket bestimmte Verschlüsselungsfunktion zu
abhängig von bestimmten Parametern
Destination IP Address (IPv4 or IPv6): single, range of
addresses, address + mask, or a wildcard.
Source IP Address(es) (IPv4 or IPv6): single, range of
addresses, address + mask, or a wildcard.
Name: User ID (DNS), X.500 distinguished name, System
name (host, security gateway, etc.) (DNS, X.500)
Data sensitivity level: (IPSO/CIPSO labels)
Transport Layer Protocol: Obtained from the IPv4
"Protocol" or the IPv6 "Next Header" fields.
Source and Destination (e.g., TCP/UDP) Ports, port
values or
a wildcard
port: session-oriented
Sicherheit
in Rechnernetzen
Prof.keying
Dr. W. Kowalk
Kryptografie
IPsec
Security Databases
Die Security Policy Database (SPD)
Die folgende Tabelle stellt dieses noch einmal zusammen
Field Traffic Value SAD Entry SPD Entry
src addr
single IP addr
single,range,wild
single,range,wildcard
dst addr
single IP addr
single,range,wild
single,range,wildcard
xpt protocol*
xpt protocol
single,wildcard
single,wildcard
src port*
single src port
single,wildcard
single,wildcard
dst port*
single dst port
single,wildcard
single,wildcard
user id*
single user id
single,wildcard
single,wildcard
sec. labels
single value
single,wildcard
single,wildcard
Seite 129
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Databases
Security Association Database (SAD)
Jede aktive SA besitzt Eintrag in Security Association Database
zum Zeitpunkt des Aufbaus der jeweiligen Verbindung erstellt
Sender überprüft, ob Pakete gesendet werden dürfen
Empfänger entscheidet, wie Pakete zu behandeln
Eingehender Verkehr besitzt die folgenden Parameter
Outer Header's Destination IP address: the IPv4 or Ipv6
IPsec Protocol: AH or ESP: Spezifiziert das verwendete IpsecProtocol
SPI: 32 Bit-Wert zur Unterscheidung verschiedener SAs mit
gleichem Ziel, die das gleiche IPsec-Protocol verwenden.
Seite 130
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Databases
Security Association Database (SAD)
Abarbeitung eines Datagramms abhängig von Parametern
Sequence Number Counter
32 Bit-Wert zum Erzeugen der Sequenznummern in AH- oder
ESP-Headern
Sequence Counter Overflow
Warnung bei Überlauf des Sequence Number Counter
Anti-Replay Window
32 Bit-Zähler zur Entdeckung mehrfach gesendeter Paketen
(replay).
AH Authentication algorithm
Schlüssel usw.
Seite 131
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
IPsec
Security Databases
Security Association Database (SAD)
Abarbeitung eines Datagramms abhängig von Parametern
ESP authentication algorithm
Schlüssel usw. null, falls keine Authentisierung in ESP.
Lifetime of this Security Association
Beenden bzw. Erneuern einer SA, wenn Zeit abgelaufen
IPsec protocol mode
tunnel, transport or wildcard. Modus von AH bzw. ESP
Path MTU
any observed path MTU and aging variables.
Ende der Lebensdauer einer SA
1. Anzahl empfangener Bytes überschreitet festgelegte Grenze
2. Festgelegter Zeitpunkt.
3. Pakete nicht innerhalb jeweiligen Zeit verwerfen
Seite 132
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Sicherheitsarchitektur für das Internet
Kritikpunkte an IPsec
Komplexität des Protokolls
Verhindert korrekte Implementierung
Nicht vernünftig testbar
zu viele unterschiedliche Interessen
erhebliche Vertrauensunsicherheit
schlechte Dokumentation
Beweggründe für Entwurfsentscheidungen
zu viele Varianten
Schlüsselaustauschverfahren
Authentifizierungsheader + Transportmodus verzichtbar
Seite 133
Verringert Komplexität drastisch
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk
Kryptografie
Sicherheitsarchitektur für das Internet
Kritikpunkte an IPsec – 2
Sicherung auf Vermittlungsschicht widerspricht
verbindungslosem Kommunikationskonzept
Konzepte (Verbindungsdaten, Verbindungsstrategien) benötigt, die
in IP nicht vorhanden
natürlicher verbindungsorientiertem Protokoll zugeordnet
TCP
Anwendung (http, SMTP)
Verbindungsdaten sowieso vorhanden
Nur Geheimhaltung der Verkehrsbeziehung sinnvoll
Seite 134
Authentifizierung
überflüssig
Sicherheit in Rechnernetzen
Prof. Dr. W. Kowalk