GnuPG Anleitung - Seite 3

Wenn Public-Key Kryptografie wie bei GnuPG benutzt wird, um verschlüsselte Kommunikation zu betreiben, muss für die Anwender gewährleistet sein, dass

• die Echtheit eines öffentlichen Schlüssels überprüft und eindeutig festgestellt werden kann
• die Fälschung oder Manipulation eines öffentlichen Schlüssels zu erkennen ist

Dazu dient das Web of Trust oder „Netz von Vertrauensbeziehungen“ als Gesamtsystem. Gebildet wird das Web of Trust durch die eigene Zertifizierung der eigenen Benutzer-IDs (Eigenzertifikate), Zertifizierung der eigenen Benutzer-IDs durch vertrauenswürdige Personen oder Zertifizierungsstellen, die Zertifizierung der Benutzer-IDs fremder, öffentlicher Schlüssel nach gewissenhafter Überprüfung der Schlüssel auf Echtheit und die Zuordnung eines Vertrauensgrades zu Personen und Zertifizierungsstellen.

Anders als im normalen Sprachgebrauch wird hier begrifflich zwischen Signatur und Zertifikat unterschieden, auch wenn der technische Vorgang derselbe ist. Während mit Signatur das elektronische Unterschreiben von Daten über eine kryptografische 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 Benutzer-IDs der öffentlichen Schlüssel anderer Personen angebracht werden, um die Echtheit der Schlüssel zu „besiegeln“ oder zu „bezeugen“. Der Stellenwert, den diese „Signatur“ z. B. für das Web of Trust hat, kommt durch den Begriff „Zertifikat“ besser zum Ausdruck.

Beim Gpg4Win Projekt wird das OpenPGP Schlüsselpaar in Anlehnung an S/MIME/X.509 als „Zertifikat“ bezeichnet und Zertifikate unter Schlüssel als „Beglaubigungen“, während Signaturen von Daten und Kommunikationsinhalten Signaturen bleiben.

Bei der Erzeugung der Schlüssel werden die gleichzeitig erzeugten Benutzer-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.

gpg --keyid-format long --list-sigs --fingerprint test@test.de
 
pub   rsa4096/0x55D3988C3A77A274 2018-07-23 [C]
  Schl.-Fingerabdruck = 0924 AF9B 87F1 1E55 9D20  80E3 55D3 988C 3A77 A274
uid                [ ultimativ ] test test <test@test.de>
sig 3        0x55D3988C3A77A274 2018-07-23 niemals     test test <test@test.de>
sub   rsa4096/0xA7E06A74E7165D1F 2018-07-23 [S] [verfällt: 2043-07-17]
  Schl.-Fingerabdruck = F056 8B7D 8984 16AD 298B  0798 A7E0 6A74 E716 5D1F
sig          0x55D3988C3A77A274 2018-07-23 niemals     test test <test@test.de>

Wenn man sich einen Schlüssel näher anschaut, befinden sich unter dem Hauptsignierschlüssel [C] weitere Einträge. Nach dem Fingerabdruck als eindeutiger Kennung des Schlüssels folgt der uid Eintrag mit der Benutzer-ID, der sig 3 Eintrag mit dem Eigenzertifikat und sig Einträge für Zertifikate des eigenen Hauptschlüssels oder Fremdzertifikate anderer GnuPG Anwender. Die Benutzer-ID des eigenen Schlüssels wird von OpenPGP Anwendungen mit dem Eigenzertifikat selbst zertifiziert, um damit auszuweisen, dass ein Schlüssel mit Benutzer-ID A und Schlüssel-ID B mit dem richtigen und dazu passenden privaten Schlüssels unterschrieben wurde, d. h. der Schlüsseleigentümer die Angaben der Benutzer-ID und damit die Zuordnung des Schlüssels mit der Schlüssel-ID B zur Person mit der Identität laut Benutzer-ID A selbst bestätigt hat. Der gleichen „Besiegelung“ oder „Beurkundung“ dienen die Zertifikate, die fremde Personen oder Zertifizierungsstellen unter die eigenen Benutzer-IDs oder die wir unter die Benutzer-IDs fremder öffentlicher Schlüssel nach Überprüfung der Schlüsselmerkmale setzen.

Das Eigenzertifikat beinhaltet außerdem weitere Daten zu Merkmalen des Schlüssels und des Zertifikats, z. B. der Zweck des Zertifikats (Zertifizierung einer Benutzer-ID, eines öffentlichen Schlüssels, eines Unterschlüssels), die Gültigkeitsdauer des zur Benutzer-ID gehörenden Schlüssels und des Zertifikats, bevorzugte Algorithmen und Schlüsselserver des Schlüsseleigentümers. Da die Eigenzertifikate des Schlüsseleigentümers über dessen privaten Schlüssel bzw. kryptografische Funktionen erzeugt werden, sind diese durch Fremde auch nicht zu editieren. So kann z. B. nur der Schlüsseleigentümer ein Zertifikat zurückziehen bzw. mit dem Merkmal „widerrufen“ versehen.

Ein zusätzliches Merkmal, dass alle Schlüssel aufweisen, ist der Fingerprint oder 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 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 Schlüssel-ID gebildet bzw. stellt die Schlüssel-ID bei Verwendung der Langform die letzten sechszehn Zeichen des Fingerabdrucks dar.

Ein weiteres Merkmal eines Schlüssels ist dessen Schlüssellänge, denn jeder Anwender kann im Rahmen der minimalen und maximalen Bitgröße die Länge seines Schlüssels selbst bestimmen.

Die Überprüfung eines Schlüssels fängt damit an, nachzuschauen, ob der Schlüssel ein Eigenzertifikat aufweist. Schlüssel ohne Eigenzertifikate sind per se nicht vertrauenswürdig. Über eine Option in der gpg.conf kann festgelegt werden, dass Schlüssel ohne Eigenzertifikat nicht in den öffentlichen Schlüsselring gelangen bzw. zu importieren sind:

no-allow-non-selfsigned-uid

Liegt danach ein Schlüssel vor, dem das Eigenzertifikat fehlt, fordert man vom Schlüsseleigentümer einen neuen bzw. selbstzertifizierten Schlüssel ein.

Über den 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üsseleigentümer über einen eindeutigen und sicheren Kommunikationskanal, sprich persönlich, per Telefon oder über eine als authentisch eingestufte Chat Session – allgemein über eine Verbindung, bei der der zukünftige Schlüsselbenutzer sicher ist, mit der richtigen Person, sprich dem realen Schlüsseleigentümer 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 ihm 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 Eigentümer dem Benutzer die Benutzer-IDs, die Schlüssellänge, das Erstellungsdatum und ggf. das Gültigkeitsende.

Zur Überprüfung eines Schlüssels kann man sich auch eine Prüfliste erstellen, die abgearbeitet wird:

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 zu kommunizieren bzw. mindestens Person A schon GnuPG für den Mailaustausch verwendet und natürlich, dass die miteinander per GnuPG kommunizierenden Personen keine Überprüfungen wie oben beschrieben vornehmen.

Jedem Angreifer mit den nötigen Kenntnissen ist es möglich, zu einem fremden, öffentlichen Schlüssel eine Benutzer-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 Benutzer-ID zur primären Benutzer-ID machen, weil es eine neue Benutzer-ID ist. Schlüssel mit falschen Benutzer-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 an sich 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.

In die Benutzer-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üsseleigentümer bezieht, sondern per Schlüsselserver oder den Schlüssel vom Angreifer per Mail erhält, die mit gefälschten Absenderangaben (die des eigentlichen Schlüsseleigentümers) 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 Benutzer-ID handelt, da er eventuell auch davon ausgeht, nur ein Schlüsseleigentümer könnte eine Benutzer-ID hinzufügen. Nach Bezug des manipulierten Schlüssels sendet der Anwender verschlüsselte Nachrichten an die angegebenen E-Mail Adressen der gefälschten Benutzer-ID. Der Angreifer erreicht nun, dass den eigentlichen Schlüsseleigentümer Nachrichten nicht mehr erreichen.

Der Angreifer könnte auch Aufforderungen an Schlüsselbenutzer in die Benutzer-IDs unterbringen, dass der Schlüssel nicht mehr benutzt (wofür eigentlich das Rückzugszertifikat des Schlüsseleigentümer dient) und stattdessen der gefälschte Schlüssel mit der Schlüssel-ID N benutzt werden soll, um einen leichtgläubigen Anwender auf seinen eigenen, gefälschten Schlüssel „umzuleiten“.

Da der Angreifer aber nicht im Besitz des privaten Schlüssels ist, kann er die Benutzer-ID nicht authentisch zertifizieren. D. h. die Benutzer-ID trägt kein Eigenzertifikat des realen Hauptsignierschlüssels, wie es eine Benutzer-ID aufweisen würde, die vom Schlüsseleigentümer hinzugefügt wurde, woran eine falsche Benutzer-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 zusätzlich die falsche Benutzer-ID mit Zertifikaten versehen, die er mit nachgemachten Schlüsseln von Zertifizierungsstellen oder von Personen erstellt, die unter Anwendern und im Web of Trust ein hohes Ansehen genießen. Oder er löscht unter allen Benutzer-IDs die Zertifikate, um einem unbedarften Anwender den Eindruck zu vermitteln, Benutzer-IDs würden keine Zertifikate tragen.

Der Angreifer erstellt zwei neue, öffentliche Schlüssel, die in den Benutzer-IDs reale Informationen von A und B enthalten, d. h. üblicherweise Vorname, Nachname oder 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 Schlüssel-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 Benutzer-IDs echter Schlüssel zu simulieren, kann er weitere Zertifikate unter die Benutzer-IDs falscher Schlüssel anbringen, die von ebenfalls vom Angreifer erstellten Schlüsseln stammen, die Benutzer-IDs von Zertifizierungsstellen (s. u.) oder Personen imitieren.

Der Angreifer muss sich nun zwischen die beiden Kommunikationspartner schalten bzw. hört er schon seit geraumer Zeit den E-Mail Verkehr zwischen A und B ab, was als Man-in-the-middle-Angriff (MITM) bezeichnet wird. Er erfährt 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 MITM Angriff ist aber für den Angreifer mit einem Risiko und einem fragwürdigen oder nur temporären Nutzen verbunden. Denn der MITM Angriff setzt voraus, dass der Angreifer alle Kommunikationskanäle der Opfer kontrollieren kann und ausschließen muss, dass es neben der verschlüsselten Kommunikation per E-Mail oder Instant Messaging 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 den PGP Attacks FAQ und in A security analysis of Pretty Good Privacy.

Die Echtheit oder Gültigkeit eines öffentlichen Schlüssels wird hauptsächlich durch Zertifikate bereits gültiger Schlüssel „besiegelt“, die von Personen oder Organisationen stammen, denen bereits Vertrauen in ihre Rolle als Zertifizierer ausgesprochen wurde.

Mit der Zertifizierung der Benutzer-ID eines Schlüssels wird bezeugt, dass man sich davon überzeugt hat, dass der öffentliche Schlüssel wirklich zur in der Benutzer-ID angegebenen Person gehört oder anders: der Zertifizierende weiß mit 100% Sicherheit, dass der öffentliche Schlüssel echt ist, unabhängig davon, ob der Schlüssel bereits Zertifikate vertrauenswürdiger Personen oder Organisationen aufweist. Zu diesem Zweck werden – wie oben angegeben – vorliegende Schlüssel auf Unstimmigkeiten überprüft und danach die Merkmale vorliegender Schlüssel direkt mit den vermeintlichen Schlüsseleigentümern abgeglichen.

Manche Anwender schließen nach der erfolgreichen Überprüfungsprozedur eine abschließende Übermittlung einer mit dem überprüften Schlüssel verschlüsselten und signierten Testnachricht an den Schlüsseleigentümer an, deren Inhalt der Schlüsseleigentümer wieder verschlüsselt und signiert an den Zertifizier zurücksenden muss.

Neben der Echtheit kommt eine interne Vertrauens-Skala zum Einsatz, die sich auf die persönliche Einschätzung des Schlüsseleigentümers in seiner Rolle als Teilnehmer des Web of Trust bezieht. Der „Vertrauensgrad“ gibt in verschiedenen Abstufungen an, inwieweit das Vertrauen in das verantwortliche Handeln und die Fähigkeit des Schlüsseleigentümers vorhanden ist, selbst wiederum für die Echtheit eines fremden, öffentlichen Schlüssels zeugen zu können.

Normalerweise müsste also jeder GnuPG Anwender, bevor er die öffentlichen Schlüssel seines Schlüsselrings benutzt und zertifiziert, jeden einzelnen Schlüssel mit dem Schlüsseleigetnümer persönlich abgleichen und jeden Schlüsseleigentümer so gut kennen, dass er ihn hinsichtlich seines Umgangs mit GnuPG und der Gewissenhaftigkeit, mit der er seinerseits die Gültigkeit öffentlicher Schlüssel überprüft, einschätzen können, um ihm den entsprechenden Vertrauensgrad zuzuordnen und seinen Zertifikaten zu vertrauen. 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 oder Zertifizierungsstellen und ihren ö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 die Schlüssel neuer Kontakte, die mit Zertifikaten versehen sind, die von solchen Schlüsseln stammen, kann GnuPG auf die Gültigkeit bzw. den Echtheitsgrad des neuen Schlüssels schließen und dem Anwender das Resultat grafisch oder symbolisch darstellen.

Ein neuer öffentlicher Fremd-Schlüssel wird von GnuPG mit den GnuPG Standardoptionen als echt (gültig) eingestuft, auch wenn man ihn selbst noch nicht zertifiziert oder der Person einen Vertrauensgrad zugeordnet hat, wenn:

• der neue Schlüssel ein Zertifikat einer Person besitzt, die mit vollständigem Vertrauensgrad versehen ist und deren Schlüssel gültig ist.
• der neue Schlüssel drei Zertifikate dreier Personen besitzt, die mit marginalem Vertrauensgrad versehen sind und deren Schlüssel gültig sind.
• der neue Schlüssel ein Zertifikat einer Person besitzt, die nur mit absolutem Vertrauensgrad versehen wurde. I. d. R. besitzt nur der Anwender selbst diesen Vertrauensgrad und keine fremde Person oder Organisation.

Über das eigene Zertifikat, die gegenseitigen Zertifikate gültiger 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.

Beispiele für Vertrauenspfade

Ich (A) - zertifiziere + Trust: vollständig -> B
                                               B - zertifiziert -> C - gültig für -> (A)
 
Ich (A) - zertifiziere + Trust: marginal -> B
Ich (A) - zertifiziere + Trust: marginal -> C
Ich (A) - zertifiziere + Trust: marginal -> D
                                            B, C, D - zertifizieren -> E - gültig für -> (A)
 
Ich (A) - Trust: vollständig -> E <- zertifiziert von B, C, D
                                E - zertifiziert -> F - gültig für -> (A)
 
Ich (A) - Trust: absolut -> B
                            B - zertifiziert -> C - gültig für -> (A)

Dabei gilt, dass je länger der Zertifikats- und Vertrauenspfad von (A) zu einem öffentlichen Schlüssel N 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 oder „Zwischenstationen“ erhöht, deren Gültigkeit und Vertrauenswürdigkeit sich nicht mehr zuverlässig einschätzen lässt. Deshalb sollte man neben der verantwortungsvollen Zertifizierung u. a. die Vergabe höherer Vertrauensgrade an „entferntere“ Personen, gestützt auf Kenntnis statt Vermutung, restriktiv handhaben. Die max-cert-depth Option dient wiederum dazu, die auszuwertenden Pfade auf die Länge zu beschränken, die man einschätzen und überschauen kann.

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 aber nur wenige Schlüsseleigentümer 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/gefälschte Schlüssel und Authentifizierungsfunktionen für Schlüssel Uploads einsetzen würden, wären in Verbindung mit einer größeren Nutzung von Trust-Zertifikaten bei größerer Relevanz von staatlich unabhängigen, kontrollierbar strengen Policies folgenden und gegen Fremdeinwirkung abgesicherten Zertifizierungsstellen vielleicht eine Verbesserung.

Mit den folgenden Optionen für die gpg.conf kann man selbst bestimmen, wie man das Web of Trust betrachtet und wie GnuPG seine Prinzipien „anwenden“ soll.

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 die Qualität des Web of Trust über einen größeren Anteil an Schlüsseln und Zertifikaten hoher Wertigkeit im Web of Trust zu erhöhen, 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 Benutzer-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 (Benutzer-ID, Länge, Fingerprint usw.) Papierkopien anfertigt. Der gleiche Schlüsselring und die Kopie wird an jeden Teilnehmer direkt oder indirekt 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 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 Benutzer-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 mit ihren Zertifikaten zu einem Schlüsselserver hoch.

Zusätzlich kann der Organisator der Party jedem Teilnehmer vor der Party einen vom Organisator vorgegebenen String zusenden, den jeder Teilnehmer zuhause signiert. Ausdrucke oder Dateikopien der signierten Strings werden dann auf der Party an die anderen Teilnehmer verteilt, so dass jeder während oder 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 Zertifizierungsinstanzen („Certification Authorities“ oder kurz CAs).

Zertifizierungsstellen sind Institutionen, Organisationen, Firmen, Vereine oder Unternehmen, die die Zugehörigkeit der Identität einer Person zu ihrem öffentlichen Schlüssel 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 sicher, verlässlich, nachvollziehbar und korrekt Schlüssel überprüft und danach 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 sind ihre Richtlinien („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. Zum Beispiel könnte theoretisch eine Person das Angebot an die GnuPG 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. Sie kann auch strengere Maßstäbe und Verfahrensweisen an die Ausstellung des Zertifikats binden.

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.

Für GnuPG gibt es zur Zeit nur die CA der Zeitschrift c't und die CA von CAcert.

Dazu muss angemerkt werden, das im Gesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz SigG) zwischen einfachen elektronischen Signaturen, fortgeschrittenen elektronischen Signaturen und qualifizierten elektronischen Signaturen unterschieden wird. Letztere können vom Anwender nur mit qualifizierten Zertifikaten über eine „sichere Signaturerstellungseinheit“ (sprich Smartcard-Lesegerät mit offizieller Signatur- bzw. eID-Smartcard) erzeugt werden, während das qualifizierte Zertifikat nicht vom Anwender selbst erzeugt und ausgestellt wird, sondern durch Zertifizierungsdiensteanbieter, die gleichzeitig die Rolle einer CA innehaben.

Im Sinn des SigG können GnuPG Schlüssel also keine qualifizierten Zertifikate und die mit ihnen erzeugten Signaturen keine qualifizierten Signaturen sein. Eine GnuPG Signatur kann nach den Definitionen im SigG als fortgeschritten gewertet werden, wenn der GnuPG Schlüssel einzigartig ist, die Benutzer-ID und weitere Attribute die reale Identität/Person des Schlüsseleigentümers widerspiegelt, die Zugehörigkeit von Identität/Person zum Schlüssel mit „kräftigen“ Zertifikaten seitens Dritter bestätigt wurde und der Schlüsseleigentümer beweisen kann, dass GnuPG Signaturen sicher und manipulationsfrei erstellt wurden. Für GnuPG kann das bedeuten, dass der Schlüssel mindestens auf einer Keysigning Party oder durch eine anerkannte CA zertifiziert und der Schlüssel auf einer OpenPGP Smartcard erzeugt wurde.

Mit fortgeschrittenen GnuPG Signaturen können Dokumente, Verträge etc. elektronisch statt handschriftlich „unterschrieben“ werden, wenn Gesetze dafür keine qualifizierte Signaturen vorschreiben. Rechtssicher und beweiskräftig sind fortgeschrittene GnuPG Signaturen aber im Gegensatz zu qualifizierten Signaturen nur, wenn die obigen Kriterien auf Schlüssel und Signatur zutreffen. D. h. im Falle des Beweises der Echtheit eines Schlüssels oder einer Signatur bzw. der Beurteilung ihres rechtlichen Werts erfordern GnuPG Signaturen u. U. zusätzliche Rechtsgutachten, Bewertungen von Sachverständigen und richterliche Einschätzungen, weil nur die qualifizierten Zertifikate und ihre Signaturen rechtlich abgesichert sind und sich Gerichte am SigG orientieren.

Die bereits weiter oben erwähnten Zertifizierungsdiensteanbieter, die nach dem SigG 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, sind in eigener Regie, aber nur nach staatlicher Lizenzvergabe und Akkreditierung für die Verwaltung und Herstellung digitaler Zertifikate zur Signierung und Verschlüsselung zuständig. Trustcenter ist einerseits eine andere Bezeichnung für Zertifizierungsdiensteanbieter, andererseits wird mit dem Begriff der abgesicherte technische Bereich bezeichnet, in dem die Verwaltung und Herstellung digitaler Zertifikate stattfindet.

Die Anforderungen und Vorkehrungen, die von Zertifizierungsdiensteanbietern zur Absicherung der Vorgänge zur Schlüsselerstellung und Zertifizierung getroffen werden müssen und die Prozeduren, die sie zur Identitätsfeststellung des zukünftigen Schlüsselinhabers durchzuführen haben, sind in der Verordnung zur elektronischen Signatur (SigV) niedergelegt.

Beim Telesec Trustcenter, einer Tochterfirma der Telekom und dem SignTrust Trustcenter, einer Tochterfirma der Deutschen Post AG, wird z. B. 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 Kodiermaschine anschließend in den Chip der Smartcard gebrannt wird. Das bedeutet aber auch, während der Schlüsselerzeugung bis die Smartcard aus der Kodiermaschine fällt, ist in diesen Trustcentern der geheime, private Schlüssel präsent – auch wenn er nach der Aufbringung auf die Smartcard vernichtet werden muss.

Nur die von Zertifizierungsdiensteanbietern erzeugten und zertifizierten Schlüssel bzw. Zertifikate gelten vor dem Gesetz sofort als „echt“ und können qualifizierte Signaturen erzeugen, die rechtlich der schriftlichen Unterschrift vollständig gleichgestellt sind, werden also die herausragende Rolle im elektronischen Geschäftsverkehr und in der elektronischen Kommunikation zwischen Bürger und Verwaltung spielen. Das betrifft – wie oben erläutert – GnuPG Schlüssel nicht, da sie nicht von staatlich anerkannten Zertifizierungsdiensteanbieternn erzeugt werden bzw. keine qualifizierten Signaturen erzeugen und sich die Zertifizierungsdiensteanbieter auf die Verschlüsselungstechnik nach den S/MIME / X.509 / PKCS Standards bzw. der Common PKI (vormals ISIS-MTT) Spezifikation beschränken, in denen die OpenPGP Spezifikation keine Rolle spielt.

Die Common PKI (ISIS-MTT) Spezifikation resultierte 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 und Zertifizierungsdiensteanbieter, zu der u. a. D-Trust, SignTrust, TC-Trustcenter, Telesec und die Bundesdruckerei gehören.

In einigen Staaten wurde 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 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 TTPs 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üsseleigentümer 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)“.

Eine Darstellung der Unterschiede zwischen dem Modell des OpenPGP Web of Trust 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.

Inhalt | Seite 2 | Seite 4