Public-Key-Kryptographie

• Rainer Perske

• Westfälische Wilhelms-Universität
  Zentrum für Informationsverarbeitung
  Röntgenstraße 7-13
  48149 Münster

• perske@uni-muenster.de
  +49 251 83 31582 (fon)
  +49 251 83 31555 (fax)

Probleme bei der Nachrichtenübermittlung

• Egal, ob IP-Paket, E-Mail, WWW-Seite oder sonst etwas:

  • Die Nachricht kommt nicht beim Empfänger an

  • Die Nachricht wird unterwegs von Dritten gelesen

  • Die Nachricht wird unterwegs von Dritten verändert

  • Dritte senden eine gefälschte Nachricht ab

• Sender will:

  • (dass die Nachricht beim Empfänger ankommt)

  • Lesen/Verändern durch Unbefugte verhindern

• Empfänger will:

  • feststellen/beweisen, dass Nachricht unverfälscht

  • feststellen/beweisen, dass Nachricht vom angegebenen Sender

Problemlösung Kryptographie

• Verschlüsselung

  • verhindert Lesen durch Dritte

  • erschwert gezieltes Verändern durch Dritte

• Elektronische (digitale) Signatur

  • beweist die Identität des Absenders

  • beweist die Unverändertheit der Nachricht

  • auch gegenüber Dritten

• Hilft nicht gegen Verlust einer Nachricht

Symmetrische Kryptographie (Secret-Key-Systeme)

• Meist gleicher Schlüssel zum Verschlüsseln und Entschlüsseln

• Je zwei Teilnehmer benötigen einen Schlüssel

• Beide müssen Schlüssel streng geheim halten

• Anzahl Schlüssel wächst quadratisch mit der Teilnehmerzahl

Wie helfen Secret-Key-Systeme?

• Verschlüsseln verhindert Abhören

• Bei manchen Verfahren:

  • Erfolgreiches Entschlüsseln beweist Unversehrtheit

Eigenschaften von Secret-Key-Systemen

• Rechenoperationen sind schnell

• Beliebige Zahlen als Schlüssel (meistens)

  • 128-Bit-Schlüssel gelten als sicher (2¹²⁸ Möglichkeiten)

  • Weniger als 64 Bit sind unsicher (alle Schlüssel ausprobieren)

• Beispiele

  • Geheimschriften, DES, RC5, IDEA, CAST, Blowfish, Twofish, Rijndael (AES)

Asymmetrische Kryptographie (Public-Key-Systeme)

• Nicht Einzelschlüssel, sondern Schlüsselpaare

• Getrennte Schlüssel zum Verschlüsseln und Entschlüsseln

• Getrennte Schlüssel zum Signieren und Verifizieren

• Aus einem Schlüssel kann der andere nicht berechnet werden

  • Schlüssel zum Entschlüsseln und Signieren streng geheim

  • Schlüssel zum Verschlüsseln und Verifizieren öffentlich

• Pro Teilnehmer nur ein oder zwei Schlüsselpaare

• Anzahl Schlüssel wächst linear mit Teilnehmerzahl

Public-Key-Systeme: Wann welcher Schlüssel?

• Signieren (durch Sender):

  • darf nur der Sender können

  • also geheimer Schlüssel des Senders

• Verifizieren (durch Empfänger):

  • darf jeder, also öffentlicher Schlüssel des Senders

• Verschlüsseln (durch Sender):

  • darf jeder, also öffentlicher Schlüssel des Empfängers

• Entschlüsseln (durch Empfänger):

  • darf nur der Empfänger können

  • also geheimer Schlüssel des Empfängers

• Grafik: Signieren, Verschlüsseln, Entschlüsseln, Verifizieren (1)

Wie helfen Public-Key-Systeme?

• Nur ein bis zwei Schlüsselpaare pro Teilnehmer

• Verschlüsseln und Signieren unabhängig voneinander

• Verschlüsseln verhindert Abhören

• Verifizieren der Signatur beweist korrekten Absender

• Verifizieren der Signatur beweist Unversehrtheit

• Auch Dritte können Signatur verifizieren

• Neue Gefahr: Unterschieben falscher öffentlicher Schlüssel

Eigenschaften von Public-Key-Systemen

• Rechenoperationen sind meist sehr langsam (große Zahlen)

• Nur Zahlen mit bestimmten Eigenschaften als Schlüssel

• Systeme auf Basis großer Primzahlen

  • Beispiele: RSA, ElGamal/DH, Rabin, ...

  • 2048-Bit-Schlüssel gelten als sicher

  • 512-Bit-Schlüssel sind unsicher (Faktorisierung)

• Systeme auf Basis elliptischer Kurven

  • 170-Bit-Schlüssel gelten als sicher

• Andere Systeme, auch Nur-Signier-Verfahren: DSS, ...

Kryptographische Essenzen (Fingerprints)

• Mathematische Hash-Funktion, Einweg-Funktion

• Rechenoperationen sind relativ schnell

• Erzeugt aus Texten (Daten) beliebiger Länge eine Essenz (Fingerabdruck)

• Essenz sehr kurz, 128 bis 512 Bit (16 bis 64 Byte)

• Aus einer Essenz kann der Text nicht berechnet werden

• Noch schärfer: Es ist unmöglich, ungleiche Texte gleicher Essenz zu finden

• Daher genügt es, die Essenz der Daten zu signieren

• Beispiele: MD5 (inzwischen fast geknackt), SHA-1, SHA-224, RIPE-MD, ...

• Demo: md5sum, sha1sum unter Linux

Misch-Systeme

• Vorteile beider Systeme nutzen

• Secret-Key-Systeme für große Datenmengen (Geschwindigkeit)

• Public-Key-Systeme für kleine Datenmengen (Schlüssel, Fingerprints)

• Kompression zur (Datenreduktion und) Redundanzbeseitigung

• Kryptografische Essenzen zur Datenreduktion

• Signieren:

  • Kryptographische Essenz (Hash-Wert) von Nachricht bilden

  • Essenz mit Public-Key-System signieren

• Verschlüsseln

  • Nachricht mit Secret-Key-System verschlüsseln, Zufallsschlüssel

  • Zufallsschlüssel mit Public-Key-System verschlüsseln

• Gefahr bleibt: Unterschieben eines falschen öffentlichen Schlüssels

Grafik: Signieren, Verschlüsseln, Entschlüsseln, Verifizieren (2)

Demo: Signieren und Verifizieren mit perMail

Demo: Verschlüsseln und Entschlüsseln mit perMail

Schlüsselverwaltung bei Public-Key-Systemen

• Persönliche Übergabe des öffentlichen Schlüssels nicht gewollt

• Notlösung: Treuhänder/Boten

• Teillösung: Key-Server (HTTP, LDAP, AD, ...) mit öffentlichen Schlüsseln

• Aber Gefahr: Untergeschobener Schlüssel mit falscher Identität

• Manchmal brauchbare Abhilfe: Fingerprint-Vergleich

  • z. B. telefonisch, wenn Stimme zuverlässig erkannt

• Lösung: Überprüfbare Beglaubigungen (Zertifikate)

Demo: Schlüsselübergabe mit perMail + Fingerprintvergleich + Gültigschaltung durch Schlüsselsignierung

Zertifikate

• Zertifikate sind elektronisch signierte Beglaubigungen

• Festgelegte Formate (OpenPGP, X.509, OpenSSH, ...)

• »Dieser öffentliche Schlüssel gehört zu dieser Identität«

• Weitere Angaben (Gültigkeitsdauer, ...)

• Dadurch automatisch verifizierbar

• Jeder kann Zertifikate ausstellen

  • Nicht obskuren Firmen Geld in den Rachen schmeißen!

Demo:

mkdir demoCA demoCA/newcerts; touch demoCA/index.txt; echo 01 >demoCA/serial
openssl req -x509 -newkey rsa:2048 -out CA.crt -keyout CA.key
openssl x509 -in CA.crt -noout -text

openssl req -new -nodes -out XY.req -keyout XY.key
openssl ca -days 10 -keyfile CA.key -cert CA.crt -in XY.req -out XY.crt
openssl x509 -in XY.crt -noout -text

Zertifikate prüfen

• Nichttechnisch: Aussteller vertrauenswürdig und kompetent?

  • Bewertung erfolgt durch Empfänger

  • Ohne Vertrauen das Zertifikat nicht akzeptieren

• Technisch: Fingerprint oder Signatur in Ordnung?

  • Signatur des Ausstellers verifizieren

    • Öffentlichen Schlüssel des Ausstellers aus sicherer Quelle besorgen!

  • Oder Fingerprint des einzelnen Zertifikats vergleichen

    • Fingerprint aus sicherer Quelle besorgen!

• Gängige Browser enthalten Schlüssel etlicher Aussteller

  • Bei X.509 sind Aussteller-Schlüssel immer auch wieder in Zertifikate verpackt

• Problem (Vorteil und Nachteil zugleich):

  • Diesen Ausstellern wird vom Browser automatisch vertraut

Demo: Zertifizierungsstellen im Firefox

Demo: Zertifikat bei WWUCA beantragen – mit eToken als Zertifikatspeicher

Zertifizierung

• Inhaber gibt öffentlichen Schlüssel »sicher« an Zertifizierer, z. B.

  • Öffentlichen Schlüssel per unsicherer E-Mail

  • Essenz (Fingerprint) des Schlüssels persönlich

• Zertifizierer kontrolliert gründlich die Identität des Inhabers

  • und vergleicht übergebenen Fingerprint mit dem des Schlüssels

• Zertifizierer erstellt mit seinem geheimem Schlüssel das Zertifikat

• Zertifizierer gibt Zertifikat »unsicher« an Inhaber (und veröffentlicht auf Wunsch)

• Inhaber präsentiert Zertifikat bei jeder Gelegenheit

Zertifizierungsstellen

• CA = Certification Authority

  • WWUCA = Zertifizierungsstelle der WWU

  • DFN-PCA = Zertifizierungsstelle des DFN

  • Deutsche Telekom Root CA 2 = Wurzelzertifizierungsstelle

• Zertifikate können unter Beachtung unterschiedlich hoher Sicherheitsanforderungen ausgestellt werden

• Je höher die Sicherheitsanforderung, desto höher die Vertrauenswürdigkeit (Beweiswert) der Zertifikate

• Sicherheitsanforderungen werden in einer Policy beschrieben

  • Qualität des Identitätsnachweises, Schutz des Zertifizierungsschlüssels, organisatorische Maßnahmen usw.

• Zertifizierungsstellen verpflichten sich, Zertifikate nur unter Beachtung der Policy auszustellen

Zertifizierungs-Ketten/-Hierarchien

• Nicht immer ist sichere Quelle für Aussteller-Schlüssel erreichbar

• Aber Aussteller-Schlüssel ist selbst durch Dritten zertifiziert

• Und dessen Schlüssel durch einen Vierten usw.

• OK, falls:

  • Erster Public Key der Kette (»Wurzelzertifikat«) aus sicherer Quelle erhalten

  • Alle Zertifikate erfolgreich verifiziert

  • Jedes Glied der Kette voll vertrauenswürdig

• Problem bei allen X.509-Implementierungen: Verordnetes Vertrauen

  • Nicht einstellbar, wem ich traue und wem nicht

  • Falls ich der Wurzel traue, traue ich zwangsweise allen Gliedern

Public-Key-Kryptographie im Internet

• E-Mail: OpenPGP (Pretty Good Privacy)

  perMail, GnuPG, Enigmail für Thunderbird, Mutt u.v.a.m.

• E-Mail: S/MIME (Secure Multipurpose Internet Mail Extensions)

  perMail, GnuPG, Outlook, Thunderbird, Evolution u.v.a.m.

• Verbindungen: SSL/TLS (Secure Sockets Layer, Transport Level Security)

  WWW (HTTPS), POP, IMAP, SMTP u.v.a.m.

• Dialog, Datenübertragung, Tunnel: SSH (Secure SHell)

  OpenSSH, PuTTY, Filezilla u.v.a.m.

• Bei SSL/TLS und bei SSH:

  • Häufig hat nur der Server ein Schlüsselpaar

  • Client-Schlüssel optional zum Identitätsnachweis

• Smartcard-Login, DNSsec, IPsec, neuer Personalausweis, u.v.a.m.

Verbindungsaufbau bei SSL und TLS

• Stark vereinfacht, Teile in (...) nur bei Verwendung von Client-Zertifikaten:

• Client: Hallo, ..., diese Methoden sind akzeptabel

  • Methoden: Public-Key-, Secret-Key-, Hash-, Kompressionsverfahren und ob Client-Zertifikat erlaubt/verlangt

• Server: Hallo, ..., diese Methoden wähle ich

• Server: Hier mein Zertifikate und ggf. Zwischenzertifikate

• Client überprüft alles, u. a.

  • Stimmt FQDN des gewünschten Servers mit Angabe im Zertifikat überein?

  • Sind Zertifikate in Ordnung?

  • Ggf. Nutzer fragen, ob Zertifikat akzeptabel

• (Server: Gib Zertifikat, diese Typen und diese CAs sind akzeptabel)

• (Client: Hier mein Zertifikat und ggf. Zwischenzertifikate)

• Client: Hier, mit deinem Public Key verschlüsselt, Zufallszahlen

• Beide berechnen Secret Key aus Zufallszahlen

• Umschaltung auf Secret-Key-Verschlüsselung

• Client: Hier meine Prüfsumme über alles Bisherige

• Server überprüft alles (inkl. Client-Zertifikat)

• Server: Hier meine Prüfsumme über alles Bisherige

• Client überprüft alles

• Jeder Fehler bis jetzt führt zu sofortigem Verbindungsabbruch

• Datenübertragung beginnt