Schlüssel-Zertifizierung
Eines der großen Probleme im Umgang mit Schlüsseln, wie sie bei der Mailverschlüsselung verwendet werden, ist das Vertrauen in einen erhaltenen Schlüssel. Die Schlüssel haben zwar eine Klartextbeschriftung, ähnlich wie ein Anhänger an einem realen Schlüssel. Typischerweise enthält diese Beschriftung mindestens den Namen und die E-Mail-Adresse der angeblichen Eigentümerin / des angeblichen Eigentümers. Aber stimmen diese Angaben? Die Schlüssel, incl. der Klartextbeschriftung, werden über das Internet ausgetauscht, die Echtheit der Angaben bleibt dabei erst einmal im Dunkeln!
Woher hat ein Empfänger also die Sicherheit, dass diese Angaben stimmen und der Schlüssel tatsächlich der angegebenen Person gehört bzw. insbesondere zu der angegebenen Mailadresse gehört?
Der Lösungsansatz ist bei den beiden gängigen Verfahren faktisch identisch! Es wird, wie z.B. bei einem Vertrag, eine Art digitaler Notar als dritte Person involviert - eine sogenannte "Certification Authority (CA)" oder "Stammzertifierungsstelle". Schlüsselinhaber wenden sich an eine CA, diese prüft, ob der Schlüssel tatsächlich zu der angegebenen Mail-Adresse gehört, und unterschreibt dann den eingereichten Schlüssel (incl. Klartextbeschriftung) in digitaler Form. Der Schlüssel erhält also eine digitale Signatur, in die der Schlüssel selbst, aber auch die Klartextinformationen eingerechnet sind.
Die Kombination aus a) Schlüssel, b) Klartextbeschriftung und c) digitaler Signatur einer Certification Authority / Stammzertifizierungsstelle, nennt sich "Zertifikat". Die Certification Authority hat die Echtheit der Angaben zertifiziert!
Zur Überprüfung eines Zertifikats wird der öffentliche Schlüssel der Certification Authority benötigt. Mit dessen Hilfe kann das ausgestellte Zertifikat automatisch überprüft werden. An dieser Stelle unterscheiden sich die beiden bei E-Mails verwendeten Verfahren.
-
Bei Verwendung von Zertifikaten nach dem X.509-Standard (SSL-/TLS-Schlüssel für Server, oder S/MIME-Schlüssel für Personen) sind die öffentlichen Schlüssel der weltweit agierenden Certification Authorities in System des Anwenders vorinstalliert, oder werden dynamisch aus dem Internet nachgeladen! Der Betriebssytemhersteller oder die Softwarefirma des verwendeten Produkts trifft also stellvertretend für den Anwender die Entscheidung welcher Certification Authority vertraut wird, und speichert die öffentlichen Schlüssel der CAs ("Stammzertifikate") im Zertifikatsspeicher.
Für Endanwender ist das durchaus komfortabel. Ohne eigenes Zutun werden Schlüssel automatisch, unter Verwendung der öffentlichen CA-Schlüssel im Zertifikatsspeicher, kontrolliert und ggf. akzeptiert.
Wird für die Zertifizierung eine CA verwendet, die von den Betriebssystem-/Softwareherstellern nicht unterstützt wird, müssen die Endanwender selbst entscheiden ob sie der CA ihr Vertrauen schenken, oder nicht. Das "Stammzertifikat" (entspricht dem öffentlichen Schlüssel der CA) muss dann selbst in den Zertifikatsspeicher des Systems integriert werden. Neben firmeneigenen CAs ist hier für Endanwender CAcert zu nennen.
-
Bei GnuPG funktioniert die Echtheitskontrolle prinzipiell genau so wie eben für X.509-Zertifikate beschrieben. Der zentrale Unterschied bei GnuPG ist, dass kein einziges Stammzertifikat im System vorinstalliert ist! Die Echtheit von Schlüsseln wird somit auch nicht standardmäßig vom System kontrolliert - vom Ablaufdatum des Schlüssels abgesehen.
Folge: Die Anwender müssen selbst entscheiden welcher Certification Authority für die Zertifikatsausstellung, und damit für die Echtheitskontrolle eines Schlüssels, vertraut wird. Gängige CA-Projekte im GnuPG-Umfeld sind z.B. die Krypto-Kampange von Heise, oder CAcert wie schon oben für X.509 genannt. Die öffentlichen Schlüssel dieser CAs sind manuell in die GnuPG-Schlüsselverwaltung aufzunehmen.
Historisch gesehen ist bei GnuPG keine Certification Authority vorgesehen. Im sogenannten "Web of Trust"-Verfahren übernimmt die Rolle einer Certification Authority in den meisten Fällen schlicht und ergreifend ein Bekannter / ein Freund des Schlüsselinhabers. In diesem Fall muss, bei der Überprüfung eines Schlüssels bzw. Zertifikats, selbst entschieden werden ob der zertifizierenden Person, und deren Gewissenhaftigkeit im Rahmen der Überprüfung, vertraut wird. Dies ist im allgemeinen eine fast unlösbare Aufgabe, da man wiederum die zertifizierenden Einzelpersonen nicht kennt. Im Normalfall ist dann sogar jeder Schlüssel von einer anderen Person zertifiziert. Zur Überprüfung der Unterschriften muss jeweils der öffentliche Schlüssel des Unterzeichners nachgeladen werden, ein Vorgang den dann viele GnuPG-Anwender schlicht und ergreifend unterlassen. Das blinde Vertrauen kann allerdings nicht die Lösung sein.