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
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.