die raven homepage
Wenn Public-Key Kryptografie wie bei GnuPG/PGP benutzt wird, um verschlüsselte Kommunikation zu betreiben, muss für die Anwender gewährleistet sein, dass
Dazu dient das Web of Trust (Netz von Vertrauensbeziehungen) als Gesamtsystem. Gebildet wird das Web of Trust durch die eigene Zertifizierung der eigenen User-IDs (Eigenzertifikate), Zertifizierung der eigenen User-IDs durch vertrauenswürdige Personen und Zertifizierungsstellen, die Zertifizierung der User-IDs fremder, öffentlicher Schlüssel nach gewissenhafter Überprüfung der Schlüssel auf Echtheit und die Zuordnung eines Vetrauensgrades zu Personen und Zertifizierungsstellen.
Anders als im normalen und m. M. nach falschen Sprachgebrauch wird hier begrifflich zwischen Signatur und Zertifikat unterschieden, auch wenn der Vorgang derselbe ist.
Während mit Signatur das elektronische Unterschreiben von Daten über eine kryptographische Funktion und den privaten Schlüssel gemeint ist, um die Prüfung der Echtheit der unterzeichneten Daten oder die Zugehörigkeit der Daten zu einer bestimmten Person zu ermöglichen, wird in Abgrenzung dazu der Begriff Zertifikat für "Signaturen" verwendet, die unter die User-IDs der öffentlichen Schlüssel anderer Personen angebracht werden, um die Echtheit der Schlüssel und die Vertrauenswürdigkeit der Schlüsselbesitzer zu "besiegeln" oder zu "bezeugen" - egal, ob das Zertifikat von einer Person oder einer Zertifizierungsinstanz stammt. Der Stellenwert, den diese "Signatur" z. B. für das Web of Trust hat, kommt durch den Begriff "Zertifikat" besser zum Ausdruck.
Bei der Erzeugung der Schlüssel werden die gleichzeitig erzeugten User-IDs, die Angaben zur Identität des Schlüsselbesitzers wie Vor- und Nachname, Organisationsname, Ortsangaben und E-Mail Adresse enthalten, mit dem eigenen, privaten Schlüssel zertifiziert.
Wenn man sich einen Schlüssel näher anschaut, befinden sich unter dem Hauptsignierschlüssel zwei weitere Einträge. Der erste Eintrag steht für die User-ID, der zweite Eintrag, zumeist durch das Symbol einer Schreibfeder oder Stiftspitze angeführt, steht für ein Eigen- oder Fremdzertifikat.
Sieht man sich die Eigenschaften des eigenen, öffentlichen Schlüssels an, fällt eines auf: Sowohl die Schlüssel-ID ("Key-ID") als auch der Fingerabdruck des Schlüssels ("Fingerprint") sind bei dem Schlüsselpaar, der User-ID und dem Zertifikat gleich.
Die User-ID des eigenen öffentlichen Schlüssels wird von OpenPGP Anwendungen selbst zertifiziert, um damit auszuweisen, dass ein öffentlicher Schlüssel mit User-ID A und Key-ID B mit dem richtigen und dazu passenden privaten Schlüssels unterschrieben wurde, d. h. der Schlüsselbesitzer die Angaben der User-ID und damit die Zuordnung des Schlüssels mit der Key-ID B zur Person mit der Identität laut User-ID A selbst bestätigt hat.
Der gleichen "Besigelung" oder "Beurkundung" dienen die Zertifikate, die fremde Personen und Zertifizierungsstellen unter die eigenen User-IDs oder die wir unter die User-IDs fremder öffentlicher Schlüssel nach Überprüfung der Schlüsselmerkmale setzen.
Ein Zertifikat beinhaltet außerdem weitere Daten zu Merkmalen des Schlüssels und des Zertifikats, z. B. der Zweck des Zertifikats (Zertifizierung einer User-ID, eines öffentlichen Schlüssels, eines Unterschlüssels), die Gültigkeitsdauer des zur User-ID gehörenden Schlüssels und des Zertifikats, bevorzugte Algorithmen des Schlüsselbesitzers.
Da die Eigenzertifikate des Schlüsselbesitzers über dessen privaten Schlüssel, bzw. kryptographische Funktionen erzeugt werden, sind diese durch Fremde auch nicht zu editieren. So kann z. B. nur der Schlüsselbesitzer ein Zertifikat zurückziehen, bzw. mit dem Merkmal "widerrufen" versehen.
Ein zusätzliches Merkmal, dass alle v4 Hauptsignierschlüssel und die alten v3 Signier- und Verschlüsselungsschlüssel aufweisen, ist der digitale Schlüssel-Fingerabdruck. Für den Fingerabdruck wird eine Prüfsumme mit einem Hashalgorithmus erzeugt. Diesmal aber nicht über zu signierende Texte, sondern über die Daten des eigentlichen Schlüsselmaterials, aber ohne alle anderen Pakete und Zertifikate. Diese Prüfsumme, die bei v4 Schlüsseln aus einer Zeichenfolge mit 40 Zeichen, bzw. 10 Gruppen a 4 Zeichen besteht, ist unter der Annahme, dass jeder Schlüssel einmalig ist, ebenfalls einmalig und deshalb einem bestimmten Schlüssel eindeutig zuzuordnen. Aus dem Fingerprint wird die Key-ID gebildet, bzw. stellt die Key-ID die letzten acht, bei einer Anzeige der Langform der Key-ID die letzten sechszehn Zeichen des Fingerabdrucks dar.
Ein weiteres Merkmal eines Schlüssels ist dessen Schlüssellänge, denn jeder Anwender kann ja im Rahmen der minimalen und maximalen Bitgröße die Länge seines Schlüssels selbst bestimmen.
Über einen Abgleich aller relevanten Schlüsselmerkmale kann der Benutzer eines öffentlichen Schlüssels feststellen, ob er den richtigen, d. h. echten Schlüssel vorliegen hat.
Dazu kontaktiert er den Schlüsselbesitzer über einen eindeutigen und sicheren Kommunikationskanal, sprich persönlich, per Telefon oder über eine als authentisch eingestufte IM/Chat Session - allgemein über eine Verbindung, bei der der zukünftige Schlüsselbenutzer sicher ist, mit der richtigen Person, sprich dem realen Schlüsselbesitzer zu kommunizieren.
Über diesen direkten Kontakt lässt sich der Schlüsselbenutzer vom Kontaktierten den Fingerabdruck seines Schlüssels vorlesen und vergleicht ihn mit dem Fingerabdruck, der zu dem öffentlichen Schlüssel ausgegeben wird, der dem Benutzer vorliegt. Weicht der vorgelesene Fingerprint von dem ausgegebenen Fingerprint ab, ist das ein Indiz dafür, dass es sich um zwei verschiedene Schlüssel handelt, d. h. dass entweder der dem Benutzer vorliegende Schlüssel falsch ist oder der Benutzer - was unter der Prämisse des authentischen Kommunikationskanals eher unwahrscheinlich ist - während des Abgleichs mit dem Angreifer selbst kommuniziert.
Neben dem Fingerprint nennt der Besitzer dem Benutzer die Key-ID, die Angaben der User-IDs, die Schlüssellänge, das Erstellungsdatum und ggf. das Gültigkeitsende. Zusätzlich kann man sich vom Besitzer auch noch das Erstellungsdatum, Key-IDs und User-IDs der Zertifikate nennen lassen, die Zertifizierungsstellen und andere Personen bereits angebracht haben.
Zur Überprüfung eines Schlüssels kann man sich auch eine Checklist erstellen, die abgearbeitet wird:
| Schlüsselmerkmale | Vorliegender öffentlicher Schlüssel | Angaben der Kontaktperson |
| User-ID | ||
| Key-ID | ||
| Fingerprint | ||
| Schlüssellänge | ||
| Erstellungsdatum | ||
| Gültigkeitszeitraum/ende | ||
| User-ID n | ||
| Key-ID Zertifikat n zu User-ID n | ||
| User-ID Zertifikat n zu User-ID n | ||
| Validität / Trustlevel Schlüssel von Zertifikat n |
||
| Erstellungsdatum Zertifikat n zu User-ID n |
Aus der obigen Darstellung ergibt sich die Bedeutung, die den Angaben der User-ID, der Key-ID und dem Fingerprint, der Schlüssellänge, den Eigen- und Fremdzertifikaten, dem Datum der Erstellung und der Gültigkeitsdauer und dem "Gesamteindruck" der Kombination aller Merkmale zukommen.
Sie sind die Ansatzpunkte für den Anwender, um die Echtheit eines Schlüssels festzustellen - primär über einen direkten Abgleich mit dem Schlüsselbesitzer, sekundär über die Sichtung und Identifizierung der Fremdzertifikate von bereits als gültig anerkannten Schlüsseln und darüberhinaus über den Vergleich mit Informationen zu einem Schlüssel, die der Schlüsselbesitzer an anderer Stelle (z. B. der eigenen Website) hinterlegt hat. Auf der anderen Seite sind unter diesen Merkmalen Merkmale, an die ein Angreifer ansetzen wird, um einen Schlüssel zu manipulieren oder zu fälschen / imitieren.
Unter Manipulation wird die Veränderung von bestehenden Merkmalen eines oder das Hinzufügen von neuen Merkmalen zu einem fremdem, öffentlichen Schlüssel durch einen Angreifer verstanden, als Fälschung die Erstellung eines öffentlichen Schlüssel durch den Angreifer, der den öffentlichen Schlüssel einer anderen Person imitiert.
Zur Verdeutlichung wird angenommen, dass zwei Personen A und B beabsichtigen, miteinander per GnuPG/PGP zu kommunizieren, bzw. mindestens Person A schon GnUPG/PGP für den Mailaustausch verwendet und natürlich, dass die miteinander per GnuPG/PGP kommunizierenden Personen keine Überprüfungen wie oben beschrieben vornehmen, bzw.
Jedem Angreifer mit den nötigen Kenntnissen ist es möglich, zu einem fremden, öffentlichen Schlüssel eine User-ID hinzuzufügen, was eigentlich dem Schlüsselbesitzer vorbehalten ist.
Ein damit versehener öffentlicher Schlüssel wird von den Schlüsselservern anstandslos akzeptiert, die die falsche User-ID zur primären User-ID machen, weil es eine neue User-ID ist.
Schlüssel mit falschen User-IDs oder anderen falschen Angaben werden auch schon deshalb durch die Schlüsselserver befördert, weil es bis jetzt im Design der Schlüsselservern nicht angelegt ist, dass nur der Schlüsselbesitzer selbst eine Aktualisierung seines öffentlichen Schlüssels durchführen kann, weil allen Schlüsselservern ein Authentifizierungsschema fehlt. Anders ausgedrückt stellen Schlüsselserver nur ein Mittel zur Verteilung und Veröffentlichung von öffentlichen Schlüsseln dar, nicht aber eine vertrauenswürdige Quelle für öffentliche Schlüssel.
Das gilt prinzipiell auch für öffentliche Schlüssel, die zum Download auf Websites bereitstehen, denn ein Angreifer könnte bei einem ungesicherten Webserver den Schlüssel und die Angaben zum Schlüssel auf der Webpage ausgetauscht haben oder die über unsichere Mailverbindungen per E-Mail versendet werden.
In die User-ID setzt der Angreifer entweder eine E-Mail Adresse, die nicht erreichbar ist oder seine eigene E-Mail Adresse. Ein Anwender, der diesen Schlüssel nicht auf direktem Wege durch dem Schlüsselbesitzer bezieht, sondern per Schlüsselserver oder den Schlüssel vom Angreifer per Mail erhält, die mit gefälschten Absenderangaben (die des eigentlichen Schlüsselbesitzers) versehen ist und den Schlüssel ohne weitere Prüfung verwendet, könnte annehmen, dass es sich um eine authentische E-Mail Adresse einer richtigen User-ID handelt, da er eventuell auch davon ausgeht, nur ein Schlüsselbesitzer könnte eine User-ID hinzufügen. Nach Bezug des manipulierten Schlüssels sendet der Anwender verschlüsselte Nachrichten an die angegebenen E-Mail Adressen der gefälschten User-ID. Der Angreifer erreicht nun, dass den eigentlichen Schlüsselbesitzer die Nachrichten nicht mehr erreichen.
Der Angreifer könnte auch in die User-IDs Aufforderungen an Schlüsselbenutzer unterbringen, dass der Schlüssel nicht mehr benutzt (wofür eigentlich das Rückzugszertifikat des Schlüsselbesitzers dient) und stattdessen der gefälschte Schlüssel mit der Key-ID n benutzt werden soll, um einen leichtgläubigen Anwender auf seinen eigenen, gefälschten Schlüssel "umzuleiten".
Da der Angreifer nicht im Besitz des privaten Schlüssels ist, kann er diese User-ID nicht authentisch zertifizieren. D. h. die User-ID trägt kein Eigenzertifikat des realen Hauptsignierschlüssels, wie es eine User-ID aufweisen würde, die vom Schlüsselbesitzer hinzugefügt wurde, woran eine falsche User-ID auch erkennbar ist.
Um den Eindruck der Authentizität zu erhöhen, bzw. die Wahrscheinlichkeit einer erfolgreichen Täuschung eines unaufmerksamen Anwenders zu erhöhen, könnte der Angreifer die falsche User-ID mit Zertifikaten versehen, die er mit nachgemachten Schlüsseln von Zertifizierungsstellen oder von Personen, die unter Anwendern und im Web of Trust ein hohes Ansehen genießen, erstellt, die gleiche Angaben enthalten, wie die authentischen Schlüssel der Zertifizierungsstellen und Personen.
Oder aber er löscht unter alle User-IDs die Zertifikate, um einem unbedarften Anwender den Eindruck zu vermitteln, User-IDs würden keine Zertifikate tragen.
Der Angreifer erstellt zwei neue, öffentliche Schlüssel, die in den User-IDs reale Informationen von A und B enthalten, d. h. üblicherweise Vorname, Nachname, Organisationsname und E-Mail Adresse. Verwendet mindestens eine der beiden Personen bereits einen Schlüssel, kann der Angreifer laut comp.security.pgp FAQ den nachgemachten Schlüssel mit der gleichen Key-ID versehen, die der echte Schlüssel trägt und den Schlüssel so erstellen, dass er den gleichen Fingerprint aufweist, wie der echte Schlüssel.
Ein nachgemachter Schlüssel mit gefälschtem Fingerabdruck wird aber in der Schlüssellänge vom echten Schlüssel unterscheiden, was die Schlüssellänge als wichtiges Kriterium der Schlüsselüberprüfung verdeutlicht.
Um den Eindruck der Authentizität zu erhöhen oder bereits bestehende Zertifikate unter den User-IDs echter Schlüssel zu simulieren, kann er weitere Zertifikate unter die User-IDs falscher Schlüssel anbringen, die von ebenfalls vom Angreifer erstellten Schlüsseln stammen, die User-IDs von Zertifizierungsstellen (s. u.) oder Personen imitieren.
Der Angreifer muss sich nun zwischen die beiden Kommunikationspartner schalten, bzw. hört schon seit geraumer Zeit den E-Mail Verkehr zwischen A und B ab (was als Man-in-the-middle / MITM Angriff bezeichnet wird) und weiß so, dass beide Personen einen Austausch ihrer Schlüssel planen, bzw. wer bereits welchen Schlüssel und welche Schlüssel anderer Mailpartner verwendet.
Ein anderer Weg für den Angreifer wäre, über gefälschte Websites und IP Spoofing A und/oder B auf die Website zu leiten, wo der gefälschte Schlüssel zum Donwload bereitsteht, wenn in einer Mail mit der Aufforderung gearbeitet würde, Person A und/oder B "solle sich doch den Schlüssel auf der Website XYZ abholen" oder er arbeitet mit E-Mails mit gefälschten Absenderangaben. Es sind bestimmt weitere Täuschungsmethoden denkbar, beschränken wir uns aber wieder auf den Schlüsselaustausch per Mail.
Wenn sich nun die beiden Personen ihre öffentlichen Schlüssel gegenseitig zusenden, fängt der Angreifer die E-Mails mit den angehängten öffentlichen Schlüssel ab, ersetzt die echten Schlüssel durch seine gefälschten Schlüssel und setzt danach den Transport der E-Mails fort.
Ab diesem Zeitpunkt befindet sich also beim Angreifer der echte, öffentliche Schlüssel von A und B und der gefälschte, öffentliche und private Schlüssel für A und B, bei A der gefälschte, öffentliche Schlüssel für B und bei B der gefälschte, öffentliche Schlüssel für A.
Wenn A nun an B eine für B verschlüsselte und/oder von A signierte E-Mail sendet, verwendet A den gefälschten Schlüssel von B und zur Signatur seinen echten Schlüssel.
Der Angreifer fängt auch diese E-Mail wieder ab und da er im Besitz des privaten Schlüssels des falschen Schlüsselpaares für B ist, kann er die Mail entschlüsseln.
Er verarbeitet nun die gewonnenen Informationen für seine Zwecke weiter oder verfälscht den Inhalt der E-Mail. Hat A die Mail signiert, entfernt der Angreifer die Signatur und signiert mit dem gefälschten, privaten Schlüssel für A die Mail.
Anschließend verschlüsselt er die Mail neu mit dem echten, öffentlichen Schlüssel von B und setzt den Transport der E-Mail an B fort.
Ist die E-Mail bei B angekommen, kann B die E-Mail mit ihrem echten, privaten Schlüssel entschlüsseln, da der Angreifer ja die E-Mail auch mit dem echten Schlüssel von B wieder-verschlüsselt hatte. Die Signatur der E-Mail erscheint B als echt, weil B die Signatur mit dem gefälschten, öffentlichen Schlüssel für A überprüft, die ja vom Angreifer mit dem gefälschten, privaten Schlüssel für A angebracht wurde.
Der Man-in-the-middle Angriff ist aber für den Angreifer auch mit einem Risiko und einem fragwürdigen oder nur temporären Nutzen verbunden. Denn der MITM setzt voraus, dass der Angreifer alle Kommunikationskanäle der Opfer kontrollieren, bzw. ausschließen muss, dass es neben der verschlüsselten Kommunikation per E-Mail oder IM zu einem anderen Zusammentreffen der Opfer kommt, da eine Bezugnahme seitens eines der Opfer auf die Kommunikation mit dem Angreifer über diesen Kanal sofort den MITM Angriff enttarnen würde.
Deshalb wird ein MITM Angriff nur auf einen einmaligen oder kurzzeitigen Informationsgewinn für den Angreifer abzielen, birgt aber parallel die Gefahr in sich, dass der Angriff nach Aufdeckung die Opfer sensibilisiert und langfristige Informationsgewinne für den Angreifer ausschließt.
Weitere Informationen, welche Gefahren durch Fälschungsmöglichkeiten entstehen können, finden sich in der:
Die Echtheit ("Validity") eines öffentlichen Schlüssels wird durch die Zertifikate anderer User "besigelt". Wenn wir User-IDs eines anderen öffentlichen Schlüssels zertifizieren, wird dieser Schlüssel sogleich "valid", d.h. "gültig" oder "authentisch". Solange er nicht von uns zertifiziert ist, bleibt der Schlüssel grundsätzlich "ungültig" oder "nicht authentisch". Als Folge bleibt der Besitzer des Schlüssels auch als "untrusted" oder "nicht vertrauenswürdig" eingestuft.
Mit der Zertifizierung bezeugen wir, dass wir uns überzeugt haben, dass dieser öffentliche Schlüssel wirklich zur in der User-ID angegebenen Person gehört oder anders: Wir wissen mit 100% Sicherheit, dass der öffentliche Schlüssel echt ist, unabhängig davon, ob unter diesem Schlüssel bereits Zertifikate von Leuten stehen, denen wir vertrauen oder die uns bekannt sind.
Zu diesem Zweck überprüfen wir, wie oben angegeben, den vorliegenden Schlüssel auf Unstimmigkeiten und danach gleichen wir, wie oben dargestellt, persönlich / direkt mit dem vermeintlichen Schlüsselbesitzer die Merkmale des vorliegenden Schlüssels mit den Mermalen ab, die uns der vermeintliche Schlüsselbesitzer nennt.
Manche Anwender schließen nach einer erfolgreichen Überprüfungsprozedur noch eine abschließende Übermittlung einer mit dem überprüften Schlüssel verschlüsselten und signierten Testnachricht an den Schlüsselbesitzer an, deren Inhalt der Schlüsselbesitzer wieder verschlüsselt und signiert an den Schlüsselbenutzer zurücksenden muss.
Neben der "Validity" kommt eine interne "Trust"-Skala zum Einsatz, die sich auf unsere Einschätzung des Schlüsselbesitzers bezieht. Der "Trust" oder "Vertrauensgrad" gibt in verschiedenen Abstufungen an, inwieweit das Vertrauen in das verantwortliche Handeln und die Fähigkeit des Schlüsselbesitzers vorhanden ist, selbst wiederum für die "Validity" eines fremden, öffentlichen Schlüssels zeugen zu können.
Bekommt man einen öffentlichen Schlüssel, der mit dem Zertifikat einer Person versehen ist, deren Schlüssel man selbst mit einem hohen Trustlevel versehen, bzw. zertifiziert hat, wird der neue, öffentliche Schlüssel entsprechend als gültig eingestuft, auch wenn man diesen neuen Schlüssel selbst noch nicht zertifiziert hat. Der Vertauensgrad eines Anwenders kann erst höher als "unbekannt" oder "nicht vertrauenswürdig" eingestuft werden, wenn man den Schlüssel des Anwenders selbst zertifiziert hat. So hängt also das Vetrauen in einen Anwender von der Gültigkeit seines Schlüssels ab. Oder anders formuliert: Ein Schlüssel kann zwar echt, der Benutzer aber trotzdem "nicht vertrauenswürdig" sein.
Normalerweise müsste also jeder GnuPG/PGP Anwender, bevor er die öffentlichen Schlüssel seines Schlüsselrings benutzt und zertifiziert, jeden einzelnen Schlüssel mit dem Schlüsselbesitzer persönlich abgleichen und jeden Schlüsselbesitzer so gut kennen, dass er ihn hinsichtlich seines Umgangs mit GnuPG/PGP und der Gewissenhaftigkeit, mit der er seinerseits die Gültigkeit öffentlicher Schlüssel überprüft, einschätzen und ihm den entsprechenden Vetrauensgrad zuordnen, um seinen Zertifikaten trauen zu können, die sich unter öffentlichen Schlüsseln befinden. Das dies nicht möglich ist, ist angesichts der Vielzahl an E-Mail Kontakten und der globalen Ausdehnung der Kommunikation offensichtlich.
Stattdessen kann sich ein Anwender auf eine begrenzte Anzahl von Personen und Zertifizierungsstellen, bzw. deren öffentlichen Schlüsseln beschränken, die er prüft, deren Vertrauensgrad er einschätzen kann und die er mit einem Zertifikat versehen an die Schlüsselserver zurückgibt. Bekommt der Anwender später einen neuen Schlüssel eines neuen Kontakts, der bereits mit einem Zertifikat versehen ist, dass von einem Schlüssel stammt, den der Anwender selbst in der Vergangenheit zertifiziert hatte, kann der Anwender - abhängig vom damals ebenfalls zugeordneten Vetrauensgrad - auf die Gültigkeit oder den Echtheitsgrad des neuen Schlüssels und den Vertrauensgrad des Schlüsselbesitzers schließen.
Wobei der Schluß von den OpenPGP Anwendungen gezogen und grafisch oder symbolisch dargestellt wird.
Versieht der vom Anwender direkt zertifizierte Schlüsselbesitzer seinerseits wieder einen dritten Schlüssel und stuft dessen Schlüsselbesitzer als vertrauenswürdig ein und dieser Dritte prüft, bewertet und zertifiziert ebenfalls wieder einen ganz anderen Schlüssel, dient dem Anwender auch dessen Zertifikat als Ausweis der Gültigkeit des anderen Schlüssels, wenn der Anwender ebenfalls diesen Schlüssel benutzen will.
D. h. über eine verzweigte Kette geprüfter, öffentlicher Schlüssel und den Zertifikaten, die mit anderen, geprüften Schlüssel vernetzt sind, werden Echtheitsaussagen und Vetraueneinstufungen vom primär Zertifizierten über eine indirekte Kette von Zertifikaten "weitervererbt" bis sie - bis zu einer vorgegebenen Tiefe - auf den letzten Schlüssel "übergehen".
Dabei gilt, dass je länger der indirekte Zertifikats- und Vertrauenspfad zu einem öffentlichen Schlüssel ist, dessen Echtheit zweifelhafter wird als bei einem öffentlichen Schlüssel mit einem direkten oder kurzen Zertifikats- und Vertrauenspfad, weil bei einem längeren Pfad die Wahrscheinlichkeit höher ist, dass sich die Anzahl von Schlüsseln und Personen mit geringem oder nicht vorhandenem Vertrauensgrad erhöht.
Als Beispiel:
Hier wäre der Schlüssel von B als abolut echt einzustufen, weil er von mir selbst direkt zertifiziert wurde. Auch den schlüssel von C würde ich als echt einstufen, weil er von B zertifiziert wurde und ich B einen Vertrauensgrad zugeordnet habe, das Gleiche bei dem Schlüssel von D, weil ich weiß, dass B die gleichen Maßstäbe für den Schlüssel von C anlegt wie ich selbst. Ab einer bestimmten Entfernung zu meinem eigenen Schlüssel kann ich die Vertrauenswürdigkeit und die Echtheit von Schlüsseln wie denen von H und I nicht mehr einschätzen oder I ist ein oberflächlicher Anwender, der ohne Sorgfalt andere Schlüssel zertifiziert. Gelange ich nun an den Schlüssel von J, der nur von Z zertifiziert wurde, besitzt das Zertifikat von Z so gut wie keinen Aussagewert für mich, den Schlüssel von J kann ich ohne eigene Prüfung nicht als echt einstufen. Dazu müsste der Schlüssel von J noch ein zusätzliches Zertifikat eines Schlüssels tragen, der sich innerhalb der überschaubaren Vertrauenssphäre befindet, z. B. ein Zertifikat von B, C oder D.
Über das eigene Zertifikat, die gegenseitigen Zertifikate gültiger und vertrauenswürdiger Schlüssel unter anderen Schlüsseln und die verschiedenen Vertrauensgrade kann sich so bei breiter Anwendung der Zertifikate und gewissenhafter Befolgung der Regeln zur Prüfung und Zertifizierung durch alle Anwender ein fein abgestuftes und ausgedehntes Netz von Vertrauensbeziehungen und Gültigkeitsausweisen ergeben.
Eine Möglichkeit zur Visualisierung des Web of Trust und der Vertrauenspfade bietet das GPG/PGP Signature Path Tracing Script und der PGP Key Path Finder.
Die Übersichtlichkeit und Eindeutigkeit des Web of Trust gestaltet sich schwierig bis problematisch, wenn sich unter öffentlichen Schlüsseln Dutzende oder Hunderte von Zertifikaten befinden, ein Anwender nur wenige Schlüsselbesitzer im Web of Trust kennt und sich auf den Schlüsselservern alle möglichen Manipulationen und Fälschungen tummeln. Schlüsselserver, die Schutz- und Erkennungsmechanismen gegen manipulierte und gefälschte Schlüssel und Authentifizierungsfunktionen für Schlüssel Uploads einsetzen würden, wären in Verbindung mit der Beschränkung auf Zertifikate von staatlich unabhängigen, kontrollierbar strengen Policies folgenden und gegen Fremdeinwirkung abgesicherten Zertifizierungsstellen vielleicht eine Verbesserung.
Ein anderer Ansatz, um das Prozedere der gegenseitigen Überprüfung und Zertifizierung zu vereinfachen, bzw. das Sammeln von Zertifikaten für den eigenen Schlüssel abzukürzen und das Web of Trust über einen höheren "Gehalt" an Schlüsseln und Zertifikaten hoher Wertigkeit im Web of Trust auszudehnen, stellen die sogenannten "Keysigning-Parties" dar. Einfach ausgedrückt ist eine Keysigning Party das persönliche Zusammentreffen mehrerer Anwender anlässlich einer Messe, Konferenz, Vereinssitzung etc. zum Zweck der gegenseitigen Authentifizierung, Überprüfung der öffentlichen Schlüssel und Zertifizierung ihrer User-IDs.
Dazu senden alle Teilnehmer ihre öffentlichen Schlüssel an den Organisator der Party, der daraus einen Schlüsselring erstellt und von der Ausgabe der Auflistung aller Schlüssel mit deren Merkmalen (User-ID, Länge, Fingerprint usw.) Papierkopien anfertigt. Der gleiche Schlüsselring und die Kopie wird an jeden Teilnehmer direkt oder indirekt (auf Disketten, per SSH/FTP Server etc.) verteilt. Auf der Party selbst vergleicht jeder Teilnehmer die Angaben zu seinem Schlüssel, die er selbst mitbringt mit den Angaben auf der Kopie. Anschließend weist sich jeder Teilnehmer gegenüber allen anderen Teilnehmern mit einem Identifikationsdokument aus - zusätzlich können auch andere Teilnehmer als Bürgen/Bezeuger für einen Teilnehmer auftreten - und trägt den anderen Teilnehmern die Angaben seines Schlüssels vor. Die anderen Teilnehmer bestätigen danach auf ihrem Schlüsselringausdruck, dass die Identität des Teilnehmers geprüft wurde, die Angaben zum Schlüssel stimmen und die User-ID mit der Identität des Teilnehmers übereinstimmt. Abschließend zertifizieren alle Teilnehmer zuhause die Schlüssel der anderen Teilnehmer und laden die Schlüssel zu einem Schlüsselserver hoch.
Zusätzlich wäre es noch denkbar, dass jeder Teilnehmer vor der Party einen vom Organisator vorgegebenen String zuhause signiert und Ausdrucke oder Dateikopien auf der Party an die anderen Teilnehmer verteilt, so dass jeder nach der Party eine zusätzliche Verifizierung durchführen kann.
Eine Anleitung, wie man Keysigning Parties organisiert und durchführt, bietet das GnuPG Keysigning-Party HOWTO.
Dem Zweck, Zertifikate auf einfachem Wege für das Web of Trust zur Verfügung zu stellen und der Idee, statt einer bestimmten Menge an Zertifikaten vertrauenswürdiger und echter Schlüssel nur ein besonders vertrauenswürdiges Zertifikat als Ausweis der Echtheit des eigenen Schlüssels zu benötigen dienen die sogenannten Zertifizierungsstellen oder -instanzen ("Certification Authorities" - CAs).
Zertifizierungsstellen sind Institutionen, Organisationen, Firmen oder Vereine, die die Zugehörigkeit zwischen der Identität einer Person und ihres öffentlichen Schlüssels nach strengen Prüf- und Kontrollverfahren durch ihr Zertifikat "besiegeln".
Der Wert eines solchen CA Zertifikats ist an das Vertrauen der Anwender in die CA selbst geknüpft. Anders ausgedrückt: Der Anwender muss sich sicher sein können, dass die CA auf sicherem, verlässlichem, nachvollziehbarem und korrektem Wege Schlüssel überprüft und zertifiziert. Die CA muss dem Anwender detailliert nachweisen, in welchem organisatorischen und technischen Rahmen die CA arbeitet und nach welchen Kriterien die CA öffentliche Schlüssel zertifiziert. Die Arbeitsweise muss für jeden Anwender persönlich zu kontrollieren sein.
Ein wichtiges Kriterium zur Einschätzung einer CA ist ihre Policy.
In der Policy bzw. der Zertifizierungsrichlinie legt eine CA u. a. detailliert dar, wie die Rechner, auf denen die Zertifizierung der Schlüssel durchgeführt werden, gegen Fremdeinwirkung und Manipulation gesichert sind, wer für die Zertifizierung zuständig ist, bzw. Zugriff auf die Zertifizierungsrechner und die privaten Schlüssel der CA hat, nach welchen Regularien öffentliche Schlüssel zertifiziert werden, welche Bedingungen der Schlüsselbesitzer erfüllen muss, um ein CA-Zertifikat zu erhalten, ob es eine CA-Hierarchie aus Root-CA und Unter-CAs gibt und welche Zuständigkeiten die einzelnen CA-Gliederungen haben, mit welcher anderen CA die eigene CA cross-zertifiziert ist usw.
Je nach Gehalt der Policy, Arbeitsweise der CA, Reputation der CA Organisation oder Grad der Anerkennung durch andere CAs kann man nach Überprüfung des Root-CA Schlüssels und der Unter-CA Schlüssel, die Anwenderschlüssel zertifizieren, einem CA-Zertifikat einen hohen oder geringen Aussagewert beimessen.
Z. B. könnte theoretisch eine Person das Angebot an die GnuPG/PGP Anwender richten, ihre Schlüssel nach selbstbestimmten Bedingungen auf dem heimischen Rechner zu zertifizieren und sich Zertifizierungsstelle XYZ nennen. Eine Zertifizierungsstelle kann sich mit dem sogenannten Post-Ident Verfahren begnügen, wo ein Anwender das CA-Zertifikat erhält, wenn er eine Kopie seines Personalausweises an die CA schickt und einen verschlüsselten Prüfsatz entschlüsselt wieder an die CA zurücksenden kann oder sie kann an die Ausstellung des Zertifikats strengere Maßstäbe und Verfahrensweisen, ähnlich dem Prozedere der Keysigning Party, zur Festellung der Identität und der Zuordnung der Identität zum Schlüssel stellen.
Eine Zertifizierungsstelle kann für sich und unabhängig von anderen CAs operieren oder Mitglied in einem Verbund von CAs werden, die sich gegenseitig nach strengen Richtlinien zertifizieren, was dem Anwender wenigstens die Gewissheit gibt, dass die einzelne CA einem System gegenseitiger Kontrolle und Überprüfung unterworfen ist.
Dazu muss noch angemerkt werden, das im Sinn des Gesetzes über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz SigG) die Zertifikate der CAs keine "qualifizierten" oder "akkreditierten" Zertifikate, sondern einfache "digitale Signaturen" und die CAs keine "Zertifizierungsdiensteanbieter" sind. D. h. im Falle des Beweises der Echtheit eines Schlüssels, der von einer CA zertifiziert wurde oder einer Signatur, bzw. der Beurteilung ihres rechtlichen Werts reicht u. U. der Verweis auf das CA Zertifikat nicht aus, sondern erfordert Rechtsgutachten, zusätzliche Bewertungen von Sachverständigen und richterliche Einschätzungen, weil nur die qualifizierten Zertifikate rechtlich abgesichert sind und sich Gerichte am Signaturgesetz orientieren.
Die bereits weiter oben erwähnten Zertifizierungsdiensteanbieter, die u. a. nach dem von der Bundesregierung und der Europäische Union verabschiedeten Signaturgesetz und der Richtlinie 1999/93/EG des Europäischen Parlaments und des Rates vom 13. Dezember 1999 über gemeinschaftliche Rahmenbedingungen für elektronische Signaturen ihre Tätigkeit aufgenommen haben, werden auch als "TrustCenter" bezeichnet, die in eigener Regie und durch staatliche Lizenzvergabe für die Verwaltung und Herstellung digitaler Schlüssel zur Signierung und Verschlüsselung zuständig sind.
Die Anforderungen und Vorkehrungen, die von Trustcentern zur Absicherung der Vorgänge zur Schlüsselerstellung und Zertifizierung getroffen werden müssen und die Prozeduren, die Trustcenter zur Identitätsfeststellung des zukünftigen Schlüsselinhabers durchzuführen haben, sind in der Verordnung zur elektronischen Signatur (SigV) niedergelegt.
Nur die in einem solchen TrustCenter erzeugten und zertifizierten Schlüssel gelten vor dem Gesetz sofort als "echt" und können Signaturen erzeugen, die rechtlich der schriftlichen Unterschrift gleichgestellt sind, werden also die herausragende Rolle im elektronischen Geschäftsverkehr und in der elektronischen Kommunikation zwischen Bürger und Verwaltung spielen.
Das betrifft nicht die GnuPG/PGP Schlüssel, da diese nicht in staatlich anerkannten TrustCentern erzeugt werden, bzw. keine "qualifizierten" Signaturen erzeugen und sich die TrustCenter auf die Verschlüsselungstechnik nach den S/MIME / X.509 / PKCS Standards, bzw. der ISIS-MTT Spezifikation beschränken, in denen die OpenPGP Spezifikation keine Rolle spielen.
Die ISIS-MTT Spezifikation resultiert aus den Standards der MailTrusT (MTT) Arbeitsgruppe des TeleTrust Deutschland e. V., zu dem u. a. Bundesdruckerei, BKA, BSI, Deutsche Bank, DFN, D-Trust, Kobil, Microsoft, Rhode & Schwarz, RSA und Siemens gehören, aus der "Spezifikation zur Entwicklung interoperabler Verfahren und Komponenten nach SigG/SigV - Signatur-Interoperabilitätsspezifikation SiGI" des Bundesamtes für Sicherheit in der Informationstechnik (BSI) und aus dem "Industrial Signature Interoperability Standard" (ISIS) des T7 e. V., einer Arbeitsgemeinschaft der Trustcenterbetreiber, zu der u. a. D-Trust, SignTrust, TC-Trustcenter, Telesec und die Bundesdruckerei gehören.
In einigen Staaten wird im Zusammenhang mit TrustCentern die Hinterlegung eines "Generalschlüssels" bei staatlichen Stellen oder "Trusted Third Parties" (TTP), dem sogenannten "Key Escrow" (im Falle von GnuPG/PGP könnte man auch sagen: Hinterlegung von privaten Schlüsseln und Passphrase) angedacht, mit dessen Hilfe staatliche Organe wie Geheimdienste nach einem juristischen Genehmigungsverfahren verschlüsselte Dateien oder E-Mails bei Verdacht wieder entschlüsseln können oder mit Überlegungen zur staatlichen Registrierung von Verschlüsselungsprogrammen, die es erlauben würde, nur solche Kryptoprogramme zu erlauben, in denen Funktionen integriert sind, die eine Wiederherstellung des Klartextes über eine Berechung des Entschlüsselungsschlüssels ermöglichen, dem sogenannten "Key Recovery".
Eine Zwischenform stellen TrustCenter dar, die gleichzeitig die Merkmale der TTP's besitzen, d. h. das Schlüsselpaar wird im Trustcenter erzeugt und dem Antragsteller auf einer SmartCard ausgehändigt, der öffentliche Schlüssel wird in ein öffentliches Verzeichnis eingestellt, aber der private Schlüssel würde ebenfalls in der Zertifizierungsstelle bleiben.
Da nicht vorgesehen ist, das Schlüsselpaar beim zukünftigen Schlüsselbesitzer auf dessen SmartCard zu erzeugen, weil der Benutzer und das Umfeld als generell unsicher eingestuft wird, kann theoretisch jedes TrustCenter zur TTP umfunktioniert werden. Carl Ellison von der Firma CyberCash prägte deshalb in Bezug zu TrustCentern und TTPs die Formulierung "Govermental Access to Keys (GAK)".
Bei den Trustcentern Telesec, einer Tochterfirma der Telekom und dem Trustcenter SignTrust, einer Tochterfirma der Deutschen Post AG wird die Schlüsselerzeugung auf der SmartCard in einem tresorähnlichen, TEMPEST abgeschirmten Sicherheitsraum durchgeführt, in dem der Rechner steht, auf dem mit einem Zufallszahlengenerator das Schlüsselpaar erzeugt und mit einer Codiermaschine anschließend in den Chip der SmartCard gebrannt wird.
D. h. während der Schlüsselerzeugung bis die SmartCard aus der Codiermaschine fällt, ist auch in diesen Trustcentern der geheime, private Schlüssel präsent - auch wenn er nach der Aufbringung auf die SmartCard vernichtet wird…
Eine Darstellung der Unterschiede zwischen dem Modell der (Open) PGP Web-of-Trust PKI und der X.509 PKI finden sich in dem Aufsatz "Why OpenPGP's PKI is better than an X.509 PKI" von P. Zimmermann auf der Site der OpenPGP Allianz.
