Sicherheit und Netze (Teil 4)

In dem Fach Sicherheit und Netze werden Schutzziele und Schutzmechanismen für die Kommunikation in Netzen behandelt. Im vierten Teil der Zusammenfassung wird erklärt, wie kryptographische Schlüssel verteilt werden und wozu man Public Key Infrastrukturen braucht.

Skript-Anfang	01EinfuehrungSicherheitUndNetze – Seite 1
Skript-Ende	15SicherheitTransportschicht – Seite 51

Verteilen kryptografischer Schlüssel

Ein Schlüsselaustauschprotokoll wird in der Kryptografie verwendet, um zwei oder mehreren Kommunikationspartnern einen gemeinsamen, geheimen Schlüssel zugänglich zu machen. Dies kann geschehen, indem jemand einen Schlüssel an alle beteiligten Partner überträgt oder indem während der Durchführung des Protokolls ein neuer Schlüssel erzeugt wird.

Anforderungen an Verteilkonzepte hängen vom Schlüsseltyp ab

Welche Ziele werden verfolgt?

• Authentisierung und Schlüsselverteilung

Welche Schlüsseltypen gibt es?

Schlüsseltyp	Beschreibung
Schlüssel für Authentisierung und Signaturen	Verschlüsselten Datenstruktur (z.B. PKCS#12)
Öffentliche Schlüssel	Zentrale Registratur mit Fälschungschutz
Asymmetrische Sitzungsschlüssel	Verteilung über asymmetrische Verfahren (1:1)
Symmetrische Sitzungsschlüssel	Zentrale Verteilung, da es sonst \( \frac{n*(n-1)}{2}\) Schlüssel gibt

Verteilung durch ein Key Distribution Center (KDC)

Wie funktioniert ein KDC?

• Vertrauenswürdiger Dritter wie die zentrale Autorität bei Signaturen
• Der KDC authentisiert Teilnehmer und verteilt Sitzungsschlüssel
• Jeder Teilnehmer vereinbart genau einen gemeinsamen symmetrischen Schlüssel mit dem KDC
• Durch die geheimen Schlüssel authentisieren sich die Teilnehmer beim KDC

Wie ist der grundlegende Ablauf?

• Alice schickt eine Anfrage zum KDC um den temporären Sitzungsschlüssel Alice-Bob zu bekommen
• Das KDC informiert Bob über die Anfrage
• Falls Bob zustimmt, wird der Session Key für beide erzeugt
• Ein sicheres Protokoll wird benutzt, um Alice und Bob den Schlüssel vertraulich zu übersenden

Wie sind Hierarchien aus KDCs aufgebaut?

• Lokale, nationale und internationale KDCs
• Anfragen werden an die lokale KDC gestellt
• Die KDCs „routen“ dann die Anfragen zum lokalen KDC des Empfängers weiter

Einfaches KDC-Protokoll

Welche Eigenschaften besitzt ein KDC-Protokoll?

• Implizite Authentisierung durch Kenntnisse der geheimen Schlüssel
• Anfällig für Replay-Angriffe, wenn keine Zeitstempel oder Nonces genutzt werden
• Nachrichten werden bei abgelaufenem Gültigkeitszeitraum verworfen
• Nonces werden zur temporären Identifizierung genutzt

Wie funktioniert ein einfaches KDC-Protokoll?

• Alice wählt einen Sitzungsschlüssel für Bob, verschlüsselt die Nachricht und informiert das KDC
• Der KDC entschlüsselt die Nachricht, entnimmt Bobs Identität und den Key K_S
• Der KDC schickt eine verschlüsselte Nachricht mit Alices Identität und dem Sitzungsschlüssel zu Bob

Wie greift man das einfache KDC-Protokoll an?

• Angreifer speichert Nachricht 3 und wiederholt diese zu einem späteren Zeitpunkt
• Angreifer muss dafür den Sitzungsschlüssel geknackt haben
• Funktioniert nur wenn der Sitzungsschlüssel unbegrenzt gültig ist
• Durch den Sitzungsschlüssel ist er automatisch authentisiert
• Mehr unter Replay-Angriffe

Needham-Schroeder Protokoll

Wie funktioniert es?

1. Alice kontaktiert unverschlüsselt den KDC (Bob und die Nonce: R_A)
2. KDC sendet das Ticket und die Daten verschlüsselt zurück zu Alice
3. Alice sendet das verschlüsselte Ticket und eine verschlüsselte zweite Nonce R_A2 an Bob
4. Bob berechnet R_A2-1 und verschlüsselt diesen mit dem Sitzungsschlüssel (Beweis des Besitzes von K_S)
5. Alice beweist nun ihrerseits den Besitz von K_S indem sie R_B-1 verschlüsselt sendet

Wie greift man das Needham-Schroeder Protokoll an?

• Replay-Angriffe werden durch Nonces und Challenge-Response-Verfahren abgewehrt
• Wenn ein Angreifer den Sitzungsschlüssel knackt, kann er Nachricht 3 wiederholen und sich als Alice ausgeben
• Mehr unter Replay-Angriffe

Kerberos

Wie ist Kerberos aufgebaut?

• Kerberos verwendet eine Variante des Needham-Schroeder-Protokolls
• Gewährt sicheren Zugriff auf Ressourcen im Netz
• Gute Synchronisation der Uhren wird vorausgesetzt
• Ticket-Granting-Server können Tickets füreinander ausstellen
• Authentication Server (AS) – Verifiziert Benutzer beim Login (wie ein KDC)
• Ticket-Granting Server (TGS) – Vergibt Identifikationstickets (User ist TGS authentisiert)
• Dienstleister – Verrichtet die von Alice gewünschte Arbeit
• Authentisierte Anwender fangen bei Schritt 3 wieder an
• Gewährte Rechte werden von den Dienstleistern bestimmt

Wie funktioniert es?

1. Alice gibt ihren Namen im Klartext an einer öffentlichen Workstation ein
2. AS liefert Session Key und Ticket TGS, beides mit KA verschlüsselt
3. Alice fragt Ticket für Bob an (t verhindert Replay-Angriffe)
4. TGS liefert den Sitzungsschlüssel Alice-Bob für Beide
5. Alice sendet den K_B()-Teil an Bob, um die Sitzung zu starten (t verhindert Replay-Angriffe)
6. Der Zeitstempel t+1 beweist, dass sie nun mit Bob redet

Verteilung ohne zentrale Instanz

Wie funktioniert es?

• Austausch symmetrischer Schlüssel über asymmetrisches Verfahren
• Verteilte Algorithmen wie Diffie-Hellman und SSL

Geheime Schlüssel vereinbaren nach Diffie-Hellman

Wie funktioniert Diffie-Hellman?

Wie greift man Diffie-Hellman an?

• Schlüssel knacken, wenn zu kleine a und b gewählt werden
• Man-in-the-middle, wenn die Nachrichten nicht signiert werden

Verteilung öffentlicher Schlüssel mittels Trusted Center

Was ist das Trusted Center?

• Öffentliche Schlüssel brauchen vertrauenswürdige Quellen und sichere Zustellung
• Das Trusted Center ist eine vertrauenswürdige öffentliche Stelle
• Verteilt öffentliche Schlüssel und die Namen der Besitzer
• Bei einer Registrierung wird Identität des Besitzers geprüft
• Das Trusted Center funktioniert wie eine CA
• Es ist ein single-point-of-failure und Flaschenhals

Certification authority (CA)

Was ist eine Zertifizierungsstelle?

• CAs sind hierarchisch aufgebaut
• Sie stellt Zertifikate aus
• In einem Zertifikat stehen die Identität und der öffentliche Schlüssel
• Das Zertifikat wird mit der Signatur der CA signiert
• Mehr unter Public Key Infrastructure

Public-Key-Infrastruktur (PKI)

Mit Public-Key-Infrastruktur bezeichnet man in der Kryptologie ein System, das digitale Zertifikate ausstellen, verteilen und prüfen kann. Die innerhalb einer PKI ausgestellten Zertifikate werden zur Absicherung rechnergestützter Kommunikation verwendet.

Zertifikate

Was sind Zertifikate?

• Werden nach Standard X.509 erzeugt
• Die digitale Signatur wird aus dem Hash des Zertifikats erzeugt
• Verbinden öffentlichen Schlüssel und die digitale Signatur
• Enthalten nützliche Benutzerattribute
• Enthalten Verweis auf eine Certificate Revocation List
• Gespeichert in den Dateiformaten DER und PEM

Wofür braucht man Zertifikate?

• Bereitstellung des öffentlichen Schlüssels
• Altersnachweis des Besitzers
• Einräumen von Rechten nach Authentisierung
• Nachweis des privaten Schlüssels über Challenge-Response

Was sind Schlüsselspeicher?

• Gemeinsame Ablage von Zertifikat und privatem Schlüssel
• Werden mit eigenem Passwort geschützt
• Ermöglicht den Transfer zu anderen Systemen
• Werden im PKCS#12-Format gespeichert

Welche Formate für Zertifikate gibt es?

• Distinguished Encoding Rules (DER) – Binäres Format für Zertifikate
• Privacy Enhanced Mail (PEM ) – Base64 verschlüsseltes Format für Zertifikate
• PKCS#7 – Basis für S/MIME zum Signieren und / oder Verschlüsseln von Nachrichten
• PKCS#8 – Format für verschlüsselte oder unverschlüsselte private Schlüssel
• PKCS#10 – Format der Nachrichten um die Zertifizierung eines Schlüsselpaares anzufordern (Certification Request Standard)
• PKCS#12 – Dateiformat, um private Schlüssel mit dem zugehörigen Zertifikat passwortgeschützt zu speichern (Personal Information Exchange Syntax Standard)

Aufbau einer Public Key Infrastructure

Welche Aufgaben hat eine PKI?

• Ausgabe, Erneuerung und Rückruf von Zertifikaten
• Stamm- und Benutzerzertifikat erstellen
• Schlüsselspeicherung und -aktualisierung
• Bereitstellung von Diensten für Protokolle
• Unterstützung von Zugangskontrollen
• Komponenten organisieren
• Standards für Dokumente und Protokolle definieren
• Benutzerzertifikate installieren und Anwendungen konfigurieren

Welche Komponenten hat eine PKI?

• Benutzer
• Zertifizierungsstellen (Certification Agency / Authority)
• Zertifikate
• (Öffentliche) Verzeichnissen

Wie funktioniert die Hierarchie?

• Die am höchsten stehende (Root-)CA zertifiziert untergeordnete CAs
• Sub-CAs, auch Regional Authorities (RA), überdecken eine geographische Region
• Sub-CAs stellen X.509 Zertifikate an Organisationen und Personen aus
• Die Root-CA stellt sich ein selbst signiertes, selbst ausgestelltes Zertifikat (mit privaten Schlüssel) aus
• Dieses Zertifikat ist der Trust Anchor (Vertrauensanker)
• Eine CA stellt einer Sub-CA das Zertifikat aus
• Dafür übermittelt die Sub-CA ihren öffentlichen Schlüssel in einem Certificate Request

Verifikation von Zertifikaten und Zertifizierungsstellen

Variante 1

• Alice benötigt Bobs öffentlichen Schlüssel
• Bob stellt das von CA5 signierte Zertifikat bereit
• Alice kennt CA5 nicht und benötigt deren Legitimierung
• CA5 stellt das von RA2 signierte Zertifikat bereit
• Alice prüft Bobs Zertifikat mit dem öffentlichen Schlüssel von CA5
• Alice kennt RA2 nicht und benötigt deren Legitimierung
• RA2 stellt das von Root-CA signierte Zertifikat bereit
• Alice prüft das Zertifikat von CA5 mit dem öffentlichen Schlüssel von RA2
• Alice vertraut der Root-CA und prüft das Zertifikat von RA2 deren öffentlichen Schlüssel
• Jetzt kann Alice sicher sein, dass sie über Bobs öffentlichen Schlüssel verfügt

Variante 2

• Bob stellt die Zertifikate von CA5 und RA2 und sich bereit
• Alice arbeitet sich von der Root-CA bis zu Bobs Zertifikat herunter

Verwalten von Zertifikaten in Anwendungen

Wie werden Zertifikate verwaltet?

• Zertifikate von Benutzern und von Zertifizierungsstellen werden in Anwendungen getrennt verwaltet
• Stammzertifikate werden bei der Installation als vertrauenswürdig gekennzeichnet
• Mit Stammzertifikaten werden die Integrität und Authentizität von Benutzerzertifikaten überprüft
• Liegt ein Stammzertifikat im Speicher vor, werden empfangene Benutzerzertifikat automatisch verifiziert
• Zur Überprüfung von Benutzerzertifikaten muss die Zertifikatskette bis zum Root-Zertifikat vorhanden sein

Angriffsszenarien

Szenario: Gefälschtes Zertifikat

• Trudy manipuliert Bobs Homepage und ersetzt das Zertifikat
• Alice holt sich das Zertifikat
• Beim Validieren sieht sie, dass Bobs Name nicht im Zertifikat enthalten ist

Szenario: Gefälschter Schlüssel

• Trudy manipuliert Bobs Homepage und ersetzt den öffentlichen Schlüssel
• Alice holt sich das Zertifikat
• Alice hasht das Zertifikat
• Der Hash passt nicht zur Signatur

Rückruf ungültiger Zertifikate

Wieso sollte man Zertifikate zurückrufen?

• Missbräuchliche Nutzung durch Benutzer oder Aussteller
• Privater Schlüssel wurde öffentlich
• Private Schlüssel der Zertifizierungsstelle wurde bekannt

Wie ruft man Zertifikate zurück?

• Im Zertifikat ist eine Certificate Revocation List (CRL) angegeben
• Die CRL enthält die Nummern aller widerrufenen Zertifikate
• In der CRL stehen nur Zertifikate, die noch nicht abgelaufen sind
• Um den Abruf der Liste muss sich jeder Benutzer selbst kümmern

Cross-Zertifikate

Was sind Cross-Zertifikate?

• Zwischen allen Root-CAs gibt es eine durch Zertifikate formalisierte Vertrauensbeziehung
• Jede Root-CA besitzt ihre eigene hierarchische Struktur
• Zertifikate zwischen den Root-CAs sind sogenannte Cross-Zertifikate
• Man braucht also n*(n-1) Zertifikate (Hier 12 Stück)

PKI für eine geschlossene Benutzergruppe

Welche Vorteile bieten PKIs in geschlossenen Gruppen?

• Eine eigene Root-CA, die Zertifikate erstellt und signiert
• In das Zertifikat der CA wird der Verwendungszweck „CA“ eingetragen
• Durch ein installiertes Stammzertifikat werden alle davon ausgestellten Benutzerzertifikate vertrauenswürdig
• Ansonsten ist es eine ganz normale PKI