Menu Close

Kryptologie (Vorlesung 12)

Skript-AnfangSkript – Seite 49
Skript-EndeSkript – 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

  1. Nutzer 1 signiert Dokument m mittels sk1 → Signatur s = sig(m, sk1)
  2. Nutzer 1 sendet m, s und C1 an N2
  3. Nutzer 2 verifiziert C1 mittels pkCA
  4. Nutzer 2 prüft Angaben zur Person, Schlüsselnutzung und Gültigkeit
  5. 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?

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahren Sie, wie Ihre Kommentardaten verarbeitet werden.

Index