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

Ein Dutzend alltäglicher Anwendungen

1. Homebanking:
   Gründliche Kontrolle des Server-Zertifikats und der Verschlüsselung

2. SSL/TLS-Verbindung zu Fuß ausprobieren:
   openssl s_client -connect pop.uni-muenster.de:995 -crlf
   openssl s_client -connect secmail.uni-muenster.de:25 -crlf -starttls smtp

3. Elektronischer Schlüssel/Ausweis (in Software):
   Beantragen eines eigenen Client-Zertifikats bei der WWUCA: http://ca.wwu.de
   Transfer des Client-Zertifikats in andere Programme

4. Elektronischer Schlüssel/Ausweis (in Hardware):
   eToken+SafeNetAuthenticationClient oder Smartcard+Kartenleser+Treiber
   Software: https://zivdav.uni-muenster.de/ddfs/Soft.ZIV/IVV/ ⇒ Security Devices (eToken, SmartCards)
   Beantragen eines eigenen Client-Zertifikats – privater Schlüssel auf eToken

5. Sich mit Client-Zertifikat ausweisen:
   verpflichtend für https://xsso.uni-muenster.de/MeinZIV/admin/
   (Verwendung für E-Mail siehe unten)

6. Verschlüsselte Verbindungen zu fremden Servern (Secure Shell):
   Verbindung aufbauen: ssh perske@zivsmp.uni-muenster.de
   Server akzeptieren, notiert Schlüssel in lokaler Datei .ssh/known_hosts

7. Ausweisen mit Public Key statt Passwort:
   Einmalig Schlüsselpaar erzeugen: ssh-keygen -t dsa -b 2048
   Einmalig Inhalt von .ssh/id_dsa.pub auf Server in .ssh/authorized_keys ablegen (im Webserverpark mittels MeinZIV)
   Nach jedem Workstation-Login (optional) Schlüsselpaar öffnen: ssh-add (benötigt laufenden ssh-agent)
   Verbindung aufbauen: ssh perske@zivsmp.uni-muenster.de

8. Ausweisen mit Zertifikat auf eToken statt Passwort (ab OpenSSH 5.4):
   Einmalig eToken öffnen und Public Key auslesen: ssh-add -s /usr/lib/libeToken.so ; ssh-add -L
   Verbindung aufbauen: ssh -I /usr/lib/libeToken.so perske@zivsmp.uni-muenster.de
   Eintippen von -I /usr/lib/libeToken.so ersparen:
   Eintrag PKCS12Provider=/usr/lib/libeToken.so in ~/.ssh/config einfügen
   Dann funktionieren auch scp, rsync usw. mit eToken (aber PIN-Abfrage nicht vermeidbar??)

9. SSH als Tunnel für ausgehende Verbindungen:
   ssh -L 11111:pop.uni-muenster.de:110 perske@zivsmp.uni-muenster.de
   POP3-Server localhost Port 11111 – telnet localhost 11111
   Verschlüsselt nur die Etappe durch den Tunnel!
   Nachträgliche Tunnel: [Enter]+[~]+[C], dann -L port:host:port usw. (-h für Hilfe)
   Manchmal hilfreich: SSH durch SSH-Tunnel durch SSH-Tunnel ...
   Manchmal hilfreich: SSH Agent Forwarding (Vorsicht!)

10. SSH als Tunnel für eingehende Verbindungen:
    ssh -R 55555:pop.uni-muenster.de:110 perske@zivsmp.uni-muenster.de
    POP3-Server zivsmp.uni-muenster.de Port 55555 – telnet zivsmp.uni-muenster.de 55555

11. SSH mit X11-Tunnel:
    ssh -X perske@zivsmp.uni-muenster.de -t xmessage Guten Morgen

12. SSH als universeller VPN-Ersatz:
    ssh -D 22222 perske@zivsmp.uni-muenster.de
    SOCKS5-Proxy 127.0.0.1:22222 in Firefox
    (Firefox-DNS-Abfragen durch Tunnel? Auf about:config network.proxy.socks_remote_dns auf true umschalten)
    https://gleitzeit.uni-muenster.de/webworkflow/ von zuhause
    Client muss SOCKS5-Protokoll sprechen, notfalls mittels tsocks, socksify o. ä.)

13. Dateien übertragen (auch rekursiv usw.):
    scp -pr localfile perske@zivsmp.uni-muenster.de:remotedir (oder) scp -pr perske@zivsmp.uni-muenster.de:remotefiles localdir

14. Und unter Windows? PuTTY!
    http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
    SCP ist pscp.exe, Eingabeaufforderung verwenden
    SSH in Eingabeaufforderung ist plink.exe
    Jedoch nicht eToken/Smartcard und X11

15. Dateibäume synchronisieren:
    rsync -auxvz --delete /local/path/ perske@zivsmp.uni-muenster.de:/remote/path/
    (wichtig: beide abschließenden Schrägstriche hinschreiben!)

16. Inkrementelles Backup (lokal oder übers Netz):
    rsync -auxvz --delete --backup --backup-dir=/remote/(Datum)/ /local/path/ perske@zivsmp.uni-muenster.de:/remote/path/
    Empfehlung: Backup-Dateisystem verschlüsseln (s. u.)

17. Verschlüsseltes inkrementelles Backup mit TSM:
    Eintrag in dsm.opt: include.encrypt /home/perske/.../*
    LC_ALL=en_US dsmc inc – verlangt Verschlüsselungspasswort

18. Windows: Filetransfer mit Filezilla (SFTP)

19. PuTTY und Filezilla kennen Pageant (ssh-agent für Windows)

20. Zum Terminalserver von 32bit-Linux mit Smartcard:
    rdesktop -g 1200x900 -r sound -r scard zivhwmon
    (Smartcard-Unterstützung funktioniert bei 64bit-Linux nicht richtig)
    (Neuere Software habe ich noch nicht ausprobiert)

21. SSL/TLS-Verschlüsselung beim Zugriff auf IMAP-Server
    wie bei Homebanking, aber IMAP statt HTTP
    analog bei POP3, NNTP u. v. a. m.

22. SSL/TLS-Verschlüsselung nach StartTLS beim Zugriff auf SMTP-Server
    unsichtbar: Verbindung erst unverschlüsselt, später umschalten mit StartTLS

23. E-Mail: mit OpenPGP signierte und/oder verschlüsselte E-Mail mit perMail

24. E-Mail: mit S/MIME signierte und/oder verschlüsselte E-Mail mit perMail

25. E-Mail: mit S/MIME signierte und/oder verschlüsselte E-Mail mit Thunderbird

26. Einbindung des LDAP-Servers der DFN-PKI im Thunderbird:
    Löst (fast) alle Probleme mit fehlenden Zertifikaten von Adressaten zu verschlüsselnder E-Mails
    Einstellungen | Verfassen | Adressieren | LDAP-Verzeichnisserver
    ldap.pca.dfn.de:389, Base-DN: O=DFN-Verein,C=DE
    Andere Programme siehe http://wiki.gwdg.de/index.php/LDAP-Verzeichnis_der_DFN-PKI

Das waren nur die, die ich selbst verwende bzw. verwendet habe ...

Äh, sagte ich ein Dutzend?

© 2000-2015 Rainer Perske und Universität Münster