Kryptographie – Zertifikate und Zertifizierungsstellen – Anwendungsentwickler-Podcast #145

Dieser Beitrag ist Teil 3 von 4 in der Serie Kryptographie.

Die Fortsetzung zum Oberthema Kryptographie mit Zertifikaten und Zertifizierungsstellen gibt es in der einhunderfünfundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Probeabo bei Audible (Affiliate)

Inhalt

  • Wiederholung: Für die elektronische Signatur und die Verschlüsselung von Daten werden Paare aus öffentlichen und privaten Schlüsseln benötigt.
  • Probleme
    • Wer garantiert dem Absender, dass ein öffentlicher Schlüssel auch wirklich dem angegebenen Empfänger gehört?
    • Wie kann sichergestellt werden, dass ein öffentlicher Schlüssel nicht von einem Angreifer durch seinen eigenen ausgetauscht wurde?
  • Zertifikat
    • Mit einem Zertifikat bestätigt eine unabhängige dritte Partei die Echtheit des öffentlichen Schlüssels des Empfängers. Diese dritte Partei wird Zertifizierungsstelle genannt.
    • Die Zertifizierungsstelle (englisch Certificate Authority, abgekürzt CA) bestätigt die Authentizität des Schlüssels des Empfängers, indem sie z.B. dessen Adresse und Identität prüft.
    • Das kostet meistens Geld, je nachdem wie intensiv diese Prüfung gemacht wird. Das geht von „muss eine E-Mail-Adresse mit dieser Domain abrufen können“ bis hin zu „das Unternehmen existiert tatsächlich unter der postalischen Adresse“.
    • Wenn Alice statt dem öffentlichen Schlüssel von Bob ein Zertifikat erhält, kann sie es wiederum mit dem Zertifikat der CA prüfen. Sie weiß nun sicher, dass sie den korrekten öffentlichen Schlüssel nutzt und nicht einen kompromittierten.
    • Alice muss dafür allerdings dem Zertifikat der Zertifizierungsstelle selbst vertrauen, da auch diese kompromittiert werden kann. Es entsteht also eine Vertrauenskette, die irgendwo in einem Root-Zertifikat endet. Und diesem Zertifikat muss manuell vertraut werden.
    • Das „Urvertrauen“ in die verschiedenen CAs wird hergestellt, indem sie z.B. in Browser wie Firefox oder Chrome vom Hersteller fest „eingebaut“ und als vertrauenswürdig gekennzeichnet werden.
    • Sollte ein Zertifikat kompromittiert werden, gibt es sog. Certificate Revocation Lists (CRL), in die die nicht mehr validen Zertifikate eingetragen werden können. Dafür müssen diese Listen aber natürlich bei jeder Prüfung eines Zertifikats kontrolliert werden, was sehr aufwändig ist.
  • Technische Umsetzung
    • Zertifikate sind (Plain-Text-)Dateien, die verschiedene technische Informationen enthalten wie z.B. den Namen des Ausstellers, den zertifizierten öffentlichen Schlüssel des Empfängers, ein Ablaufdatum, die elektronische Signatur der ausstellenden CA.
    • Vereinfacht (!) gesagt, ist das Zertifikat der mit dem privaten Schlüssel der CA signierte öffentliche Schlüssel des Empfängers. Nur mit dem öffentlichen Schlüssel der CA kann diese Signatur geprüft werden. Und dieser öffentliche Schlüssel ist für alle wichtigen CAs im Browser hinterlegt.
    • Genauer gesagt werden alle Inhalte des Zertifikats signiert und vom öffentlichen Schlüssel des Empfängers nur der Hash. Und im Browser sind auch nicht nur die öffentlichen Schlüssel der CAs hinterlegt, sondern wiederum Zertifikate, die wiederum zertifizert sind usw.
    • Die Root-Zertifikate am Ende dieser Kette werden dann von der CA selbst signiert und heißen selbstsignierte Zertifikate. Dabei garantiert quasi die CA selbst, dass sie wirklich diese CA ist.
      Selbstsigniertes Root-Zertifikat von Verisign im Firefox
    • Der Aufbau der Dateien ist standardisiert, z.B. im Format X.509.
    • Aussteller und Zertifikatinhaber werden durch eine Reihe von Attributen beschrieben, z.B. den sog. Common Name (CN), Land und Ort.

Links

Probeabo bei Audible (Affiliate)

Navigation der Serie<< Kryptographie – Hashverfahren und elektronische Signatur – Anwendungsentwickler-Podcast #132Kryptographie – Funktionsweise von HTTPS – Anwendungsentwickler-Podcast #146 >>
Polyglot Clean Code Developer
About the Author
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

4 comments on “Kryptographie – Zertifikate und Zertifizierungsstellen – Anwendungsentwickler-Podcast #145

  1. Michael Neufing sagt:

    Nette Folge, schöner kurzer Ritt durch das Thema. Vielen Dank dafür!

    Die Prüfung der CRL ist in der Tat ein Problem. Inzwischen gibt es mit OCSP und OCSP-Stapling ja aber ganz gute alternativen.

    Wer in das Thema tiefer eintauchen möchte, kann ja hier mal reinhören: https://requestforcomments.de/archives/640

  2. Stefan Macke sagt:

    Moin Michael, danke für den Hinweis! Den RfC-Podcast kann ich uneingeschränkt weiterempfehlen! 😀

  3. Lukas Lotz sagt:

    Hi, super Reihe und sehr verständlich geschildert. Den Hinweis mit Let’s Encrypt als kostenlose trusted CA hasr du ja in der aktuellen Folge.

    Zu DigiNotar gibt es eine sehr empfehlenswerte Folge von Darknet Diaries mit einigen Hintergrundinfos und einem Einblick in den Aufwand, der betrieben werden muss, um eine CA zu hacken und daraus nutzen zu ziehen.
    https://darknetdiaries.com/episode/3/

  4. Stefan Macke sagt:

    Hallo Lukas, vielen Dank für das Feedback. Die Darknet Diaries kannte ich noch gar nicht. Vielen Dank für den Tipp! Da höre ich direkt mal rein! 🙂

Schreibe einen Kommentar

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

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax