9.8 Kryptographische Protokolle

Transkript

1 9.8 Kryptographische Protokolle Protokoll = Beispiel 1: Beispiel 2: Vereinbarung zwischen Kommunikationspartnern über Art, Inhalt und Formatierung der ausgetauschten Nachrichten sowie über das Wechselspiel bei der Abwicklung eines Dialogs Kommunikationsprotokolle in einem Rechnernetz Telefonieren: Angerufener: Anrufer: Angerufener:..... Anrufer: Angerufener: Löhr Hier ist Thomas Hallo Thomas; wie geht s? Danke. Mach s gut. Tschüss, Thomas

2 Kryptographische Protokolle: Nachrichten werden chiffriert/ dechiffriert, signiert/verifiziert,... 3 Protokoll-Klassen: einfach (self-enforcing) im täglichen Leben: 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) * vertrauenswürdige Instanzen! 9.8 2

3 9.8.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 9.8 3

4 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): Digitale Unterschrift: ( A,M,T, S A (M,T) ) S A (.) := D A [H[.]] A B empfängt (a,m,t,s) und verifiziert mit 1. H[(m,t)] = E A (s)? 2. t = aktuelle Zeit? 9.8 4

5 Problematisch: - Asynchronie der Uhren, - Laufzeit der Nachricht Empfänger speichert die Nachrichten und vergleicht mit gespeichertem Zeitstempel (virtuelle Zeit, z.b. Folgenumerierung, genügt) 9.8 5

6 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, S A (M,N) ) empfängt (m,s) und verifiziert mit H[(m,N)] = E A (s)? 9.8 6

7 Wechselseitige Authentisierung zweier Dialogpartner an einem unsicheren Kommunikationskanal A öffnet Verbindung zu B und wählt Nonce N1 (A,N1) (D B [N1], N2) B wählt Nonce N2 empfängt (x,n) und verifiziert E B [x] = N1? D A [n] empfängt y und verifiziert E B [y] = N2? 9.8 7

8 Achtung: mit symmetrischer Verschlüsselung ist das Verfahren u.u. nicht sicher! (Wir schreiben E AB, D AB für die Chiffrierung bzw. Dechiffrierung mit dem gemeinsamen Schlüssel K AB.) Angreifer C öffnet Verbindung zu B und C wählt Nonce N1 empfängt (x,n2) und eröffnet zweite Verbindung (A,N1) (E AB [N1], N2) (A,N2) B wählt Nonce N

9 C empfängt (E AB [N2], N3) und sendet über erste Verbindung (A,N2) (E AB [N2], N3) E AB [N2] B empfängt (A,N2) wählt Nonce N3 empfängt y und verifiziert D AB [y] = N2? 9.8 9

10 Sicherung von Verbindlichkeit = Beweisbarkeit bzw. Widerlegbarkeit von Sende/Empfangsvorgängen In jedem Fall gilt die 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 ... mit notariellem Protokoll und symmetrischer Chiffrierung: A N B (A, E AN [B,M]) erhält (a,z), verifiziert D an [z] = wohlgeformtes (b,m)? speichert (A,B,M) (N, E NB [A,M]) erhält (n,x) verifiziert D nb [x] = wohlgeformtes (a,m)? speichert (A,M)

12 Falls kein Replay seitens Dritter: Empfänger B Sender A + kann Empfangen und damit Senden beweisen + kann Empfangen nicht vorgeben kann Empfangen abstreiten + kann Senden/Empfangen nicht abstreiten kann Senden/Empfangen nicht beweisen

13 ... mit richterlichem Protokoll und asymmetrischer Chiffrierung: A (A, D A [A,T,M]) B empfängt (a,x) verifiziert E a [x] = wohlgeformtes (a,t,m)? mit t ok? speichert x Richter kann x überprüfen

14 Empfänger B Sender A + kann Empfangen und damit Senden beweisen + kann Empfangen nicht vorgeben kann Empfangen abstreiten + kann Senden/Empfangen nicht abstreiten kann Senden/Empfangen nicht beweisen... wie bei 1, aber einfacher und ohne Replay-Gefahr

15 9.8.2 Schlüsselverwaltung Probleme: Erzeugung Speicherung Austausch/Übermittlung von geheimen Sitzungsschlüsseln (symmetrisch) für effiziente Chiffrierung, öffentlichen Schlüsseln (asymmetrisch) für Authentisierung [ private Schlüssel (asymmetrisch) unproblematisch ]

16 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 = c k mod p 2. p

17 A wählt a zufällig aus [0,p-1] B c a mod p wählt b zufällig aus [0,p-1] c b mod p berechnet K := (c a mod p) b mod p K := (c b mod p) a mod p K = c ab mod p K = c ab mod p

18 Sicherheit: f(x) = c x mod p wirkt als Einbahn-Funktion, denn Berechnung des diskreten Logarithmus erfordert exponentiellen Aufwand (vgl. DSA, ) Achtung: Das Diffie-Hellman-Verfahren allein garantiert keine Authentizität, weder von A noch von B Anwendung: Im Protokoll Secure Shell - SSH ( Netzsicherheit) (dort mit wechselseitiger Authentisierung)

19 Zentraler Schlüsseldienst für Sitzungsschlüssel (Needham/Schroeder 1978, verschiedene Varianten) Voraussetzung:Jeder Teilnehmer X hat Schlüssel K SX für Kommunikation mit dem Schlüsseldienst S A B (A,B) wählt K AB E SA [B,K AB,T,E SB [A,K AB ]] E SB [A,K AB ] Schwäche: Kein Schutz vor Wiedereinspielen der 3. Nachricht durch einen Angreifer, der zuvor den Schlüssel K AB geknackt hat

20 Zentraler Schlüsseldienst für Sitzungsschlüssel (Needham/Schroeder 1978, verschiedene Varianten) Voraussetzung:Jeder Teilnehmer X hat Schlüssel K SX für Kommunikation mit dem Schlüsseldienst S A B (A,B) wählt K AB E SA [B,K AB,T,E SB [A,K AB, T ]] E SB [A,K AB, T ] Schwäche: Kein Schutz vor Wiedereinspielen der 3. Nachricht durch einen Angreifer, der zuvor den Schlüssel K AB geknackt hat Zeitmarke T hinzufügen

21 Zertifikate für öffentliche Schlüssel Asymmetrische Chiffrierung: jeder erzeugt sein eigenes Schlüsselpaar und publiziert den öffentlichen Schlüssel Aber: wie erfährt B auf sichere Weise den öffentlichen Schlüssel von A?! Verhindern, dass X seinen eigenen öffentlichen Schlüssel als Schlüssel von A präsentieren kann! Öffentlicher Schlüssel muss authentisch sein Henne-und-Ei-Problem?

22 Direkter Kontakt mit B: a) persönliches Gespräch, Schlüssel aufschreiben (z.b 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[E A ] (Hashcode gemäß ) Im Netz steht A hat öffentlichen Schlüssel x Dies verifizieren mit H[x] = f?

23 Vertrauenswürdige Instanz heranziehen: Schlüsselbuch (wie Telefonbuch) auf Papier oder CD vertrauenswürdig? veraltet schnell! Instanz S wie Schlüsseldienst aus , deren öffentlicher Schlüssel bereits authentisch bekannt ist, teilt auf Anfrage den Schlüssel authentisch mit: D S [A, E A,.....] Diese signierte Schlüsselinformation heißt Zertifikat (certificate) und enthält weitere Informationen wie etwa Name des Ausstellers S, Gültigkeitsdauer etc

24 Praxis der Zertifikatsverwaltung: Zertifizierungsstelle (certification authority, CA, trust center) ist zuständig für Ausstellung von Zertifikaten, z.b. gemäß CCITT X.509 Publizieren der Zertifikate in öffentlichem Verzeichnis, z.b. X.500 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)

25 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, entwickelt von Phil Zimmermann, jetzt standardisiert als OpenPGP mit verschiedenen Implementierungen, z.b. PGPi ( GnuPG ( GnuPP (GNU Privacy Project) (BM f. Wirtschaft und Technologie)

26 Verschlüsselung bei PGP IDEA für Chiffrieren der Nachricht mit ad-hoc erzeugtem, symmetrischen Sitzungsschlüssel K AB, RSA für Authentizität und sichere Übertragung des Sitzungsschlüssels K AB SHA-1 für Hashing

27 Geheimhaltung und Integrität: Verschlüsselten Sitzungsschlüssel und verschlüsselte Nachricht übertragen A B erzeugt K AB (E AB [M], E B [K AB ]) dechiffriert K AB mit D B, dechiffriert M mit D AB Authentizität: Nachricht und digitale Unterschrift übertragen A (M, D A [H[M]]) B verifiziert M mit E A

28 Geheimhaltung, Integrität und Authentizität: A B (E AB [M, D A [H[M]]], E B [K AB ]) signierte Nachricht wird verschlüsselt Warum nicht (E AB [M], E B [D A [K AB ]])? Weil dies die Möglichkeit ausschließt, die signierte Nachricht (M, D A [H[M]]) weiterzugeben

29 Schlüsselverwaltung bei PGP 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?

30 Speicherung des privaten Schlüssels bei PGP Privater Schlüssel wird verschlüsselt gespeichert: A erzeugt Schlüsselpaar (E A,D A ), wählt Passwort P ( Mantra ); dieses bestimmt IDEA-Schlüssel K = H[P] (= Hashcode von P); gespeichert wird K[D A ]. D A kann immer nur im Fluge benutzt werden entschlüsselt mit K nach Eingabe von P und liegt somit nur sehr kurzfristig unverschlüsselt vor

31 Schlüsselerzeugung bei PGP unter Verwendung von Pseudozufallszahlen und Zeitspannen zwischen Tastatureingaben des Benutzers RSA-Schlüssellänge kann vom Benutzer gewählt werden

32 9.8.3 Authentisierungsdienste übernehmen die Authentisierung von Netzteilnehmern und erlauben ihnen damit die Benutzung von Ressourcen/Diensten im Netz

33 Kerberos (MIT ) Authentisierungsdienst für lokales Netz (vgl. Zugangskontrolle ) benutzt Needham/Schroeder-Protokoll ( ) Autorisierung liegt in der Verantwortung des jeweiligen Dienstes! Idee: Authentisierungsdienst verwaltet Passwörter und vergibt nach einmaliger Authentisierung fälschungssichere Sitzungsschlüssel für die Benutzung des jeweils gewünschten Dienstes Verschiedene Versionen (bis Version 5) in verschiedenen Produkten eingesetzt (z.b. Sun NFS (8.3 ))

34 Ungefähr so: A uthentisierungs- D ienst B enutzer auf dienst Station C (Netzadresse) mit Passwort Bpw (B,C,D,Bpw) ticket = E AD [B,C,D] Sicherheit? Komfort? Kommunikation B D unsicher (B,C,ticket) Sitzungsschlüssel! Passwort Bpw ist abhörbar! Passwort-Prüfung im Klienten! (vgl ) Für jeden neu benötigten Dienst erneut Passwort-Eingabe! Separate Ticket-Vergabe!

35 Benutzer präsentiert einem Dienst Credentials ( Papiere ) - fälschungssicher im Gegensatz z.b. zu den uid/gid aus die aus Ticket und Authenticator bestehen: t XY = Ticket von X für Benutzer B auf Station C für Dienst Y, trägt den Sitzungsschlüssel für die Benutzung von Y durch B = E XY [K BY, Y, B, C, T, lifetime] K BY = Sitzungsschlüssel a BY = Authenticator von Benutzer B auf Station C für Dienst Y, beweist Kenntnis von K BY und damit Authentizität von B = E BY [B,C,T] K AB = H[Bpw] mit Einbahn-Funktion H (z.b. Hashfunktion)

36 Ticket Granting Server A G D B A kennt Schlüssel K AB = H[Bpw], erzeugt Sitzungsschlüssel K BG und ticket granting ticket E AG [K BG,G,...] (E AG [K BG,G,...], E AB [K BG ]) (B,G) (B,D, E AG [K BG,G,...], a BG ) dechiffriert Ticket, erhält damit K BG, dechiffriert Authenticator alles konsistent? erzeugt Sitzungsschlüssel K BD und Ticket E GD [K BD,D,...] Eingabe Bpw K AB := H[Bpw] K BG := D AB [E AB [K BG ]] a BG := E BG [B,C,T]

37 A G D B (E GD [K BD,D,...], E BG [K BD ]) (B, E GD [K BD,D,...], a BD ) (wie oben bei G) K BD := D BG [E BG [K BD ]] a BD := E BD [B,C,T] E BD [...] (sichere Kommunikation zwischen Dienst und Benutzer)

38 Sesame Secure European System for Applications in a Multi-Vendor Environment Schwachstelle bei Kerberos: Die Server könnten eventuell unter die Kontrolle eines Angreifers geraten. Kerberos Lokalnetz symmetrische Schlüssel Autorisierung durch Server Sesame Öffentliches Netz asymmetrische Schlüssel Autorisierungsdienst: Privilege Attribute Service vergibt Privilege Attribute Certificates (PAC) mit Assoziation zu Gruppen/Rollen