Kryptographie und Zertifikate

Grundlagen und
> ein Dutzend alltäglicher Anwendungen

• 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)

• Falls das System selbst keine Schwachstellen aufweist:

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

  • Noch viel sicherer: 160-, 192-, 224- oder gar 256-Bit-Schlüssel

  • Jedes Bit mehr verdoppelt die Sicherheit

  • 64-Bit-Schlüssel 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

• Oft braucht nur eine Partei ein Schlüsselpaar zu besitzen
  (beim Nur-Signieren der Absender, beim Nur-Verschlüsseln der Empfänger)

• 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 (128 Bit, unsicher), SHA-1 (160 Bit, schwächelt), SHA-2 (256 bis 512 Bit, sicher), RIPEMD-160, ...

• Demo: md5sum, sha1sum unter Linux

Misch-Systeme 1

• Mehrere Komponenten, um Vorteile beider Systeme zu nutzen

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

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

  • Kompression zur Redundanzbeseitigung

  • Kryptografische Essenzen zur Datenreduktion

  • Echten Zufallsgenerator für Einmalschlüssel

• Signieren (geheimer Schlüssel Absender):

  • Kryptographische Essenz (Hash-Wert) von Nachricht bilden

  • Essenz mit Public-Key-System verschlüsseln = Signatur

• Verifizieren (öffentlicher Schlüssel Absender):

  • Kryptographische Essenz (Hash-Wert) von Nachricht bilden

  • Signatur entschlüsseln und mit Essenz vergleichen

Misch-Systeme 2

• Verschlüsseln (öffentlicher Schlüssel Empfänger):

  • Zufälligen Schlüssel für Secret-Key-System erzeugen

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

  • Zufallsschlüssel mit Public-Key-System verschlüsseln und beifügen

• Entschlüsseln (geheimer Schlüssel Empfänger):

  • Beigefügten Zufallsschlüssel mit Public-Key-System entschlüsseln

  • Nachricht mit Zufallsschlüssel mit Secret-Key-System entschlü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: vertrauenswürdige Treuhänder oder Boten

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

  • LDAP der DFN-PKI: ldap.pca.dfn.de:389, Base-DN: O=DFN-Verein,C=DE

  • Demo: Eintragen in Thunderbird

• S/MIME-Signaturen enthalten immer auch den öffentlichen Schlüssel

  • Dieser wird von E-Mail-Programmen automatisch gespeichert

  • Man kann an jeden verschlüsseln, von dem man jemals eine signierte Mail bekam

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

• Manchmal brauchbare Abhilfe: Fingerprint-Vergleich (telefonisch???)

• Demo: Nachschlagen Fingerprint in Thunderbird und perMail

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

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: Aufsetzen einer CA:
  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

• Demo: Schlüsselpaar und Request erzeugen:
  openssl req -new -nodes -out XY.req -keyout XY.key

• Demo: Zertifikat ausstellen:
  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

Zertifizierung

• Demo: ca.wwu.de – Zertifikat bei WWUCA beantragen – mit eToken als Zertifikatspeicher

• 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 fast allen X.509-Implementierungen: Verordnetes Vertrauen

  • Nicht oder schwierig einstellbar, wem ich traue und wem nicht

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

Public-Key-Kryptographie im Internet

• OpenPGP (Pretty Good Privacy):

  • E-Mail: perMail, GnuPG, Enigmail für Thunderbird, Mutt u.v.a.m.

  • Code Signing (fast alle Linuxe): signierte RPM- und DEB-Pakete u.v.a.m.

• X.509:

  • 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.

  • Code Signing: Java Applets, ActiveX-Controls, Windows-Software u.v.a.m.

  • Login: Smartcards, WWW Client-Auth (https://xsso), neuer Personalausweis u.v.a.m.

• SSH (Secure Shell): Dialog, Datenübertragung, Tunnel: OpenSSH, PuTTY, Filezilla u.v.a.m.

• Und viel, viel mehr: Kerberos, DNSsec, IPsec u.v.a.m.

• Oft hat nur der Server ein Schlüsselpaar, nicht der Client

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