A,B

11 Kryptographische Protokolle
Protokoll =
Vereinbarung zwischen Kommunikationspartnern
über Art, Inhalt und Formatierung der ausgetauschten
Nachrichten sowie über das Wechselspiel bei der
Abwicklung eines Dialogs
Beispiel 1:
Kommunikationsprotokolle in einem Rechnernetz
Beispiel 2:
Telefonieren:
Angerufener:
Anrufer:
Angerufener:
.....
Anrufer:
Angerufener:
„Löhr“
„Hier ist Thomas“
„Hallo Thomas; wie geht‘s?“
„Danke. Mach‘s gut.“
„Tschüss, Thomas.“
Kryptographische Protokolle: Nachrichten werden chiffriert/dechiffriert,
signiert/verifiziert, .....
3 Protokoll-Klassen:
im täglichen Leben:
einfach
(self-enforcing)
z.B. Telefonieren, Sprechfunk,
Arbeitsvertrag per Post
notariell
(arbitrated)
z.B. Hauskauf
richterlich
(adjudicated)
z.B. Software-Kauf mit
anschließender Klage
(Richter wird nur im Streitfall benötigt)
11.1 Elementare Protokolle
gewährleisten bei Kommunikation zwischen 2 Partnern
eine oder mehrere der folgenden Sicherheitseigenschaften:
Geheimhaltung
Integrität
Authentizität
Originalität
Verbindlichkeit
Achtung:
Sabotage der Übertragung ist nicht verhinderbar
und u.U. nicht einmal entdeckbar
11.1.1 Zeitstempel und Nonces
werden zur Sicherung der Originalität eingesetzt,
d.h. kein Wiedereinspielen (replay) zuvor abgehörter
Nachrichten oder Nachrichtenteile
Zeitstempel T (time stamp):
A
( A,M,T, SA(A,M,T) )
B
SA(.) := DA[H[.]]
empfängt (a,m,t,s) und
verifiziert mit
1. H[(a,m,t)] = EA(s) ?
2. t = aktuelle Zeit ?
Problematisch: Asynchronie der Uhren, Laufzeit der Nachricht
¼
Empfänger speichert die Nachrichten
und vergleicht mit gespeichertem Zeitstempel
(virtuelle Zeit, z.B. Folgenumerierung, genügt)
Alternative:
Verwendung eines Nonce (dt. „aktueller Augenblick“),
(auch „challenge“)
A
A
B
N
wählt ad-hoc-Zufallszahl N (nonce)
und schickt sie an A
( M, SA(M,N) )
empfängt (m,s) und
verifiziert mit H[(m,N)] = EA(s) ?
Bei wechselseitigem Mißtrauen (mutual suspicion):
(hier mit Beschränkung auf Sicherung der Identität der Partner,
z.B. wenn anschließend über technisch sichere Verbindung übertragen wird)
A
wählt Nonce N1
(A,N1)
B
wählt Nonce N2
(DB[N1], N2)
empfängt (x,n) und
verifiziert EB[x] = N1 ?
DA[n]
empfängt y und
verifiziert EB[y] = N2 ?
Achtung:
mit symmetrischer Verschlüsselung
ist das Verfahren u.U. nicht sicher !
(Wir schreiben EAB, DAB für die Chiffrierung bzw. Dechiffrierung
mit dem gemeinsamen Schlüssel KAB.)
Angreifer C maskiert sich als A:
C
wählt Nonce N1
(A,N1)
B
wählt Nonce N2
(EAB[N1], N2)
empfängt (x,N2)
und eröffnet
zweite Verbindung
(A,N2)
(A,N2)
C
B
empfängt (A,N2)
wählt Nonce N3
(EAB[N2], N3)
empfängt (EAB[N2], N3)
und sendet
über erste Verbindung EAB[N2]
empfängt y
und verifiziert
DAB[y] = N2 ?
11.1.2 Sicherung von Verbindlichkeit
= Beweisbarkeit bzw. Widerlegbarkeit von Senden/Empfangen
Kausalität:
eine Nachricht, die empfangen wird, wurde auch gesendet,
aber:
nicht notwendig vom angegebenen Absender
und:
die Umkehrung gilt nicht – eine gesendete
Nachricht wird nicht notwendig empfangen
11.1.2.1 ... mit notariellem Protokoll und symmetrischer Chiffrierung
A
N
(A, EAN[B,M])
B
erhält (a,z),
verifiziert DaN[z]
= wohlgeformtes (b,m) ?
speichert (A,B,M)
(N, ENB[A,M])
erhält (n,x)
verifiziert DnB[x]
= wohlgeformtes (a,m) ?
Falls kein Replay seitens Dritter:
Empfänger B
+ kann Empfangen – und damit Senden – beweisen
+ kann Empfangen nicht vorgeben
– kann Empfangen abstreiten
Sender A
+ kann Senden/Empfangen nicht abstreiten
– kann Senden/Empfangen nicht beweisen
11.1.2.2 ... mit richterlichem Protokoll und asymmetrischer Chiffrierung
A
(A, DA[A,T,M])
B
empfängt (a,x)
verifiziert Ea[x]
= wohlgeformtes (a,t,m) ?
mit t ok
speichert x
Richter kann x überprüfen
Empfänger B
+ kann Empfangen nicht vorgeben
+ kann Empfangen – und damit Senden – beweisen
– kann Empfangen abstreiten
Sender A
+ kann Senden/Empfangen nicht abstreiten
– kann Senden/Empfangen nicht beweisen
11.2 Schlüsselverwaltung
Probleme:
Erzeugung
Speicherung
Austausch/Übermittlung
von
geheimen Sitzungsschlüsseln (symmetrisch)
für effiziente Chiffrierung,
öffentlichen Schlüsseln (asymmetrisch)
für Authentisierung
Zur Erinnerung: Schlüssel können nicht sicher verschlüsselt werden!
11.2.1 Schlüssel-Vereinbarung nach Diffie-Hellman
(Diffie/Hellman 1976)
Ziel:
Vereinbarung eines neu erzeugten, geheimen
Sitzungsschlüssels K zwischen zwei Partnern
– geht das überhaupt? JA !
Ausgangspunkt:
Beide Partner vereinbaren öffentlich
– eine große Primzahl p ,
– eine Zahl c mit 0 ≤ c < p
Empfohlen:
1. c = Generator von p , d.h. für jedes i aus [1,p-1]
gibt es ein k aus [0,p-1] mit i = ck mod p
2. p ≈ 10200
A
wählt a zufällig aus [0,p-1]
B
(A, ca mod p)
wählt b zufällig aus [0,p-1]
berechnet K := (ca mod p)b mod p
cb mod p
K := (cb mod p)a mod p
K = cab mod p
K = cab mod p
Sicherheit:
f(x) = cx mod p wirkt als Einbahn-Funktion, denn
Berechnung des diskreten Logarithmus erfordert
exponentiellen Aufwand (vgl. DSA, 10.6.3.5)
Achtung:
Das Diffie-Hellman-Verfahren allein garantiert
keine Authentizität, weder von A noch von B
11.2.2 Zentraler Schlüsseldienst für Sitzungsschlüssel
(Needham/Schroeder 1978, verschiedene Varianten)
Voraussetzung: Jeder Teilnehmer hat Schlüssel für
Kommunikation mit dem Schlüsseldienst
S
A
B
(A,B)
wählt KAB
ESA[B,KAB,T,ESB[A,KAB]]
ESB[A,KAB]
Schwäche:
Kein Schutz vor Wiedereinspielen der 3. Nachricht
durch einen Angreifer, der zuvor den Schlüssel
KAB geknackt hat
11.2.2 Zentraler Schlüsseldienst für Sitzungsschlüssel
(Needham/Schroeder 1978, verschiedene Varianten)
Voraussetzung: Jeder Teilnehmer hat Schlüssel für
Kommunikation mit dem Schlüsseldienst
S
A
B
(A,B)
wählt KAB
ESA[B,KAB,T,ESB[A,KAB, T ]]
ESB[A,KAB, T ]
Schwäche:
Kein Schutz vor Wiedereinspielen der 3. Nachricht
durch einen Angreifer, der zuvor den Schlüssel
KAB geknackt hat ¼ Zeitmarke T hinzufügen
11.2.3 Zertifikate für öffentliche Schlüssel
Asymmetrische Chiffrierung:
Aber:
jeder erzeugt sein eigenes Schlüsselpaar
und publiziert den öffentlichen Schlüssel
wie erfährt B auf sichere Weise den öffentlichen Schlüssel von A?
! Verhindern, daß X seinen eigenen öffentlichen Schlüssel als
„Schlüssel von A“ präsentieren kann !
¼ Öffentlicher Schlüssel muß authentisch sein
Henne-und-Ei-Problem ?
Direkter Kontakt mit B:
a) persönliches Gespräch, Schlüssel aufschreiben (z.B. 1024 Bits!);
b) besser Visitenkarte oder Diskette entgegennehmen;
c) noch besser: wie a) oder b), aber nur Fingerabdruck
(fingerprint) des Schlüssels übergeben
und Schlüssel z.B. im Netz nachschlagen:
Fingerabdruck f = H[EA] (Hashcode gemäß 10.6.3)
Im Netz steht „A hat Schlüssel x “
Dies verifizieren mit H[x] = f ?
Vertrauenswürdige Instanz heranziehen:
Schlüsselbuch (wie Telefonbuch) auf Papier oder CD
– vertrauenswürdig? veraltet schnell!
Instanz S wie Schlüsseldienst aus 11.2.2, deren
öffentlicher Schlüssel bereits authentisch bekannt ist,
teilt auf Anfrage den Schlüssel authentisch mit:
DS[A, EA, . . . . .]
Diese signierte Schlüsselinformation heißt Zertifikat
(certificate) und enthält weitere Informationen wie etwa
Name des Ausstellers S, Gültigkeitsdauer etc.
Praxis der Zertifikatsverwaltung:
Zertifizierungsstelle (certification authority, CA, trust center)
ist zuständig für
1 Ausstellung von Zertifikaten, z.B. gemäß CCITT X.509
2
Publizieren der Zertifikate in öffentlichem Verzeichnis, z.B. X.500
3
Speicherung der Zertifikate z.B. auf Chipkarte,
zusammen mit eigenem öffentlichen Schlüssel
und evtl. dem privaten Schlüssel des Teilnehmers
Öffentliche-Schlüssel-Infrastruktur (public-key infrastructure, PKI)
ist hierarchisch strukturiertes Netz von Zertifizierungsstellen,
z.B. zweistufige Hierarchie gemäß deutschem Signaturgesetz
(Regulierungsbehörde für Post und Telek. + Zertifizierungsstellen)
11.2.4 Schlüsselverwaltung bei PGP
(Zimmermann 1991)
PGP („pretty good privacy“) = Software für
Verschlüsselung,
Schlüsselerzeugung,
Schlüsselverwaltung (Bekanntmachung, Speicherung, ...)
Ursprünglich freie Software (GNU Public License),
übernommen in Standard OpenPGP mit verschiedenen Implementierungen,
z.B. GnuPP (GNU Privacy Project) (BM f. Wirtschaft und Technologie)
11.2.4.1 Verschlüsselung
IDEA
für Chiffrieren der Nachricht mit ad-hoc erzeugtem,
symmetrischen Sitzungsschlüssel KAB,
RSA
für Authentizität und sichere Übertragung
des Sitzungsschlüssels KAB
SHA-1 für Hashing
Geheimhaltung und Integrität:
Verschlüsselten Sitzungsschlüssel und
verschlüsselte Nachricht übertragen
A
erzeugt KAB
(EAB[M], EB[KAB])
B
dechiffriert KAB mit DB,
dechiffriert M mit DAB
Authentizität:
Nachricht und digitale Unterschrift übertragen
A
B
(M, DA[H[M]])
verifiziert M mit EA
Geheimhaltung, Integrität und Authentizität:
signierte Nachricht wird verschlüsselt
A
B
(EAB[M, DA[H[M]]], EB[KAB])
Warum nicht (EAB[M], EB[DA[KAB]]) ?
Weil dies die Möglichkeit ausschließt,
die signierte Nachricht (M, DA[H[M]]) weiterzugeben.
11.2.4.2 Schlüsselverwaltung
mit Zertifikat + Fingerabdruck
Keine offizielle PKI.
Kann ich dem Aussteller des Zertifikats vertrauen?
Privates („grass roots“) Vertrauensnetz wird aufgebaut (web of trust):
A stellt Zertifikat für B aus und übergibt es an guten Freund C.
C vertraut A und damit dem Zertifikat.
C gibt das Zertifikat an guten Freund D weiter.
Soll D dem Zertifikat vertrauen,
obwohl es nicht von C ausgestellt wurde?
11.2.4.3 Speicherung des privaten Schlüssels
Privater Schlüssel wird verschlüsselt gespeichert:
A erzeugt Schlüsselpaar (EA,DA),
wählt Paßwort P („Mantra“);
dieses bestimmt IDEA-Schlüssel K = H[P] (= hashcode von P);
gespeichert wird K[DA] .
DA kann immer nur „im Fluge“ benutzt werden
– entschlüsselt mit K nach Eingabe von P –
und liegt somit nur sehr kurzfristig unverschlüsselt vor.
11.2.4.4 Schlüsselerzeugung
unter Verwendung von Pseudozufallszahlen
und Zeitspannen zwischen Tastatureingaben des Benutzers
RSA-Schlüssellänge kann vom Benutzer gewählt werden.
Adressen zu PGP:
http://www.pgpi.org/
http://web.mit.edu/network/pgp.html
http://www.gnupg.org
http://www.gnupp.de
11.3 Authentisierungsdienste
übernehmen die Authentisierung von Netzteilnehmern
und erlauben ihnen damit die Benutzung
von Ressourcen/Diensten im Netz
11.3.1 Kerberos
(MIT 1983-88)
Authentisierungsdienst für lokales Netz
benutzt Needham/Schroeder-Protokoll (symmetrische Chiffrierung)
Autorisierung liegt in der Verantwortung des jeweiligen Dienstes!
Idee:
Authentisierungsdienst verwaltet Paßwörter und
vergibt nach Authentisierung nicht fälschbares Ticket
für die Benutzung des gewünschten Dienstes
Verschiedene Versionen (bis Version 5)
in verschiedenen Produkten eingesetzt (z.B. Sun Solaris, NFS (9.3.1!))
Ungefähr so:
A uthentisierungsdienst
D ienst
B enutzer auf
Station C (Netzadresse)
(B,C,D,pw)
ticket = EAD[B,C,D]
(B,C,ticket)
Sicherheit? Komfort?
Paßwort pw ist abhörbar!
¼
Paßwort-Prüfung im Klienten!
Für jeden neu benötigten Dienst erneut Paßwort-Eingabe!
¼
Separate Ticket-Vergabe!
Benutzer präsentiert einem Dienst Credentials
(„Beglaubigungsschreiben“), die aus Ticket und Authenticator bestehen:
tBD =
=
aBD =
=
KBD =
Ticket von Benutzer B auf Station C für Dienst D,
beweist D die erfolgte Authentisierung von B durch A
EAD[B,C,D,T,KBD,lifetime]
KBD = Sitzungsschlüssel
Authenticator von Benutzer B auf Station C für Dienst D,
beweist D, daß der Sender den Schlüssel KBD kennt
EBD[B,C,T]
chiffriertes Paßwort (Einbahn-Funktion X)
A
Ticket Granting Server
G
D
B
(B,G)
erzeugt Sitzungsschlüssel KBG
und ticket granting ticket tBG
(tBG, EAB[KBG])
(B,D, tBG, aBG)
KAB := X[pw]
KBG := DAB[EAB[KBG]]
aBG := EBG [B,C,T]
dechiffriert Ticket, erhält damit KBG ,
dechiffriert Authenticator
– alles konsistent?
erzeugt Sitzungsschlüssel KBD
A
G
D
B
(tBD, EBG [KBD])
KBD := DBG[EBG[KBD]]
aBD:= EBD [B,C,T]
(B,tBD, aBD)
(siehe oben bei G)
EBD [.....]
(Kommunikation zwischen Dienst und Benutzer)
11.3.2 Sesame
Secure European System for Applications
in a Multi-Vendor Environment
Kerberos
Sesame
Lokalnetz
Öffentliches Netz
symmetrische Schlüssel
asymmetrische Schlüssel
Autorisierung durch die Server Autorisierungsdienst:
Privilege Attribute Service vergibt
Privilege Attribute Certificates (PAC)
mit Assoziation zu Gruppen/Rollen
12 Themenvorschau Netzsicherheit
Geheimhaltung durch Einbettung:
Steganographie, Watermarking, Chaffing and Winnowing
Firewalls
SSL (Secure Socket Layer), SSH (Secure Shell)
VPN, IPsec
Web-(Un)Sicherheit
Sicherheit im E-commerce: SET, E-cash, Smartcards, ...
Pseudonymität, Anonymität, Unbeobachtbarkeit
usw. usf.