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

Podcast: Play in new window | Download (Duration: 36:05 — 17.0MB)

Abonnieren: Apple Podcasts | Spotify | RSS

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

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Public-Key-Zertifikat
• X.509
• Zertifikatsperrliste