| Skript-Anfang | Skript – Seite 49 |
|---|---|
| Skript-Ende | Skript – Seite 55 |
Erinnerung
- Asymmetrisches Verfahren Öffentlichen Schlüssel / Public Key / PK → Verschlüsseln
- Geheimer Schlüssel / Secret Key / SK → Entschlüsseln
Daten authentizitieren (z.B. Signatur)
- SK → Daten signieren
- PK → Signatur verifizieren
Instanzauthentisierung (über Challenge Response)
- SK → Zufall (Challenge) signieren
- PK → Signatur verifizieren
Ziele
- Zuordnung des Schlüssels zum Schlüsselinhaber
- Für wen verschlüssle ich eigentlich?
- Wer hat Daten signiert?
- Wer authentisiert sich da gerade?
Schlüsselnutzung
- Für alle Verfahren verschiedene Schlüssel
- Wir haben Angriffe gesehen (Sende Dokument → Bekomme es signiert zurück → Fatal!)
- Etablieren einer gemeinsamen Sicherheitsinfrastruktur
- Wie sicher sind Schlüssel gelagert?
- Wie stark ist die Bindung zwischen Schlüssel und Schlüsselinhaber?
- Wie sieht ein Registrierungsprozess aus?
Erste Lösung
- 2 Personen → 1 Austausch
- 3 Personen → 3 Austausch
- 4 Personen → 6 Austausch
- n Personen → n(n-1)/2 Austausch
- Kommt eine neue Personen hinzu, muss diese mit allen anderen Personen den Schlüssel austauschen
Besser – Public Key Infrastrukturen
- Die öffentlichen Schlüssel aller Kommunikationspartner werden von einer zentralen vertrauenswürdigen Instanz verwaltet
- Jeder Nutzer erhält ein Zertifikat für seinen öffentlichen Schlüssel
- Zertifikat wird ausgestellt von der Certification Authority (CA)

Aufbau eines Zertifikats

Beispiel 10.1
- Nutzer 1 signiert Dokument m mittels sk1 → Signatur s = sig(m, sk1)
- Nutzer 1 sendet m, s und C1 an N2
- Nutzer 2 verifiziert C1 mittels pkCA
- Nutzer 2 prüft Angaben zur Person, Schlüsselnutzung und Gültigkeit
- Nutzer 2 nutzt pk1 (enthalten in C1), um s zu prüfen
Registration Authority (RA)
- Prüft Zertifizierungsanträge
- Legt Inhalte der Zertifikate fest
- Leitet Anträge an die CA weiter
- CA stellt die Zertifikate aus
Mehrstufige CA

Zurückziehe von Zertifikaten
- Eine Instanz (Teil CA oder ein Endnutzer) hält sich nicht an Sicherheitsvorgaben → Hierzu müssen Certification Revokation Lists (CRL) geführt werden
- Bei Sicherheitsvorfällen (z.B. bei Schlüsselkompromittierung, Algorithmus wird unsicher )
- Prüfung, ob Zertifikat in CRL enthalten ist
Certificate Policy und Certificate Practice Statement
- Alle Instanzen einer PKI (z.B: Root-CA, Teil-CAs und Endnutzer) müssen ein definiertes Maß an Sicherheit einhalten
- Root gibt dazu 2 Dokumente aus:
- Certificate Policy (Öffentliches Dokument) – Welche Sicherheitsvorgaben müssen eingehalten werden
- Certificate Practice Statement (Internes Dokument für Mitarbeiter) – Beschreibt, wie diese Sicherheitsvorgaben eingehalten werden
- Beispiel
- Schlüssel so gesichert sein, dass sie dritten nicht zugänglich sind
- Wir speichern Schlüssel in einem High Security Module
- RFC 3647 – Internet X509 Public Key Infrastructure Certificate Policy and Certification Practices Framework beschreibt Aufbau und Inhalte beider Dokumente
Klausur
Wie funktioniert die Erkennung gültiger Zertifikate und eines signierten Dokumentes von Benutzern, die zu einer anderen Teil-CA gehören?