Kryptographie – Zertifikate und Zertifizierungsstellen – Anwendungsentwickler-Podcast #145

Die Fortsetzung zum Oberthema Kryptographie mit Zertifikaten und
Zertifizierungsstellen gibt es in der einhunderfünfundvierzigsten
Episode des Anwendungsentwickler-Podcasts.
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